DnsAdmins: How DNS Admin Access Can Lead to Domain Compromise
DnsAdmins Group: How DNS Administration Can Lead to Domain Compromise
The DnsAdmins group was built to allow users to manage DNS without granting Domain Admin rights. In practice, however, the permissions can still create a path to domain takeover. A compromised DnsAdmins account can modify DNS configuration, alter records used throughout the domain, and in some configurations abuse DNS server plug-in functionality to place code in the context of the DNS service. Since Active Directory-integrated DNS commonly runs directly on domain controllers, unnecessary DnsAdmins membership deserves the same scrutiny as other Tier 0 administrative access.
Quick Summary
DnsAdmins membership grants substantial control over the Windows DNS Server service and Active Directory-integrated DNS data. In environments where DNS runs on domain controllers, compromise of one of these accounts can create a short path from delegated DNS administration to domain takeover.
| Priority | High |
| Risk | DnsAdmins members have broad control over DNS configuration and may be able to turn that access into elevated code execution |
| Impact | DNS manipulation, credential theft opportunities, privilege escalation, service disruption, and potential domain compromise |
| Exploitation | Attackers can point the DNS service at a malicious DLL and restart the service to run it as SYSTEM |
| Fix | Remove unnecessary DnsAdmins members, use narrower DNS delegation where possible, and treat any retained membership as Tier 0 access |
What is the DnsAdmins Group?
DnsAdmins is a built-in Active Directory security group used to delegate administration of Microsoft DNS Server without granting full Domain Admin rights. The group is created when the DNS Server role is installed, or has previously been installed, on a domain controller in the domain. By default, it has no members.
Members can administer DNS configuration, zones, and records. For Active Directory-integrated DNS, DnsAdmins normally has broad control over DNS data stored in the directory. That delegation is useful when a dedicated DNS team needs administrative access. The problem is that the role can carry far more security impact than its name suggests.
In many Active Directory environments, the DNS Server service runs directly on domain controllers. An account that can influence the configuration of that service is therefore administering software running on one of the most sensitive systems in the domain.
Why Populated DnsAdmins Membership Creates Risk
The DnsAdmins group is not inherently a misconfiguration. A legitimate DNS administrator may need the access. The risk appears when membership is broader than necessary, permanent, or assigned to accounts that are not protected like other privileged identities.
Common risks include:
- DNS configuration changes
Members can modify DNS settings and Active Directory-integrated DNS data. Malicious changes can redirect clients, interfere with authentication dependencies, or disrupt name resolution. - Privilege escalation
Certain DNS Server configuration capabilities have historically allowed DnsAdmins privileges to be converted into code execution in the DNS service context. - Domain controller exposure
When DNS runs on a domain controller, an escalation path against the DNS service is occurring directly on a Tier 0 asset. - Standing administrative privilege
DNS administrators often retain membership indefinitely even if elevated access is needed only occasionally. - Account compromise
A DnsAdmins account may receive less protection than Domain Admin accounts because the group does not appear as obviously dangerous to administrators reviewing access. - Service disruption
Incorrect or malicious DNS changes can affect authentication, application connectivity, service discovery, and general domain operations.
Real-World Context
The DnsAdmins privilege-escalation path has been publicly documented for years and is widely known in offensive Active Directory testing. What keeps it alive in real environments is how the group gets populated. A networking administrator might be added to the group to manage a few DNS zones and remain there for years. That same identity may use a normal workstation, browse the internet, receive email, and authenticate to systems outside the administrative tier.
The group also has no default members, which makes persistent membership worth questioning. Every account in DnsAdmins represents an explicit delegation decision, even if nobody remembers making it.
How Attackers Can Abuse DnsAdmins Membership
An attacker usually does not need to attack DNS directly if they can compromise an account that already has DnsAdmins rights.
A common escalation path looks like this:
- An account in DnsAdmins is compromised
The attacker obtains credentials or session access for any user, service account, or nested group member that belongs to DnsAdmins. - A malicious DLL is staged
The attacker builds a DLL and hosts it somewhere the domain controller can reach, commonly a network share. - The DNS service is pointed at the DLL
Using dnscmd or an equivalent method, the attacker sets the server-level plugin DLL configuration on the domain controller to reference their file. - The DNS service is restarted
DnsAdmins membership sometimes carries the rights needed to stop and start the DNS service, either directly or through an account that already has them. - The DLL executes as SYSTEM
On restart, the DNS service loads the configured plugin DLL and runs it in its own SYSTEM context on the domain controller. - The domain is compromised
From SYSTEM on a domain controller, the attacker can create a new Domain Admin, extract credentials, or take other malicious actions.
How to Detect DnsAdmins Group Membership
DnsAdmins membership is straightforward to review and should be included in normal privileged-access assessments.
PowerShell Method
Run the following command from an elevated PowerShell prompt:
# Review current members of the DnsAdmins group
Import-Module ActiveDirectory
Get-ADGroupMember -Identity "DnsAdmins"
# List effective DnsAdmins membership, including nested group members
Get-ADGroupMember -Identity "DnsAdmins" -Recursive |
Select-Object Name, SamAccountName, ObjectClass
What it does: The first command lists direct members of DnsAdmins. The second expands nested group membership to show effective users and other principals.
How to interpret results: Any account returned should be treated as a Tier 0 account. Confirm the owner, the business reason for membership, and whether the access is still needed. An empty result is the expected, healthy state.
Active Directory Users and Computers (ADUC)
For manual verification:
- Open Active Directory Users and Computers (dsa.msc).
- Navigate to the Users container.
- Locate the DnsAdmins group.
- Right-click, select Properties, and open the Members tab.
- Review every listed account or nested group.
The DnsAdmins group is located in the Users container by default and has no default members.
Monitoring DnsAdmins Group Changes
Because DnsAdmins is a domain local group, membership changes can be visible through Active Directory security auditing and should generate an alert when changed.
Relevant events include:
- Event ID 4732 – a member was added to a security-enabled local group
- Event ID 4733 – a member was removed from a security-enabled local group
Alerting should focus on changes involving DnsAdmins that occur outside an approved administrative request.
As an added precaution, DNS servers also deserve monitoring for unexpected changes under “HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters”. The ServerLevelPluginDll value is particularly important in environments that do not use custom DNS plug-ins.
Finding DnsAdmins Exposure with Insight Recon
Insight Recon’s Active Directory security assessment checks DnsAdmins membership across the domain automatically, alongside every other privileged group.
It also provides:
- Visibility into every account and nested group inside DnsAdmins
- Risk prioritization alongside other Tier 0 and privileged access findings
- Step-by-step remediation and validation guidance
- Historical tracking to confirm the group stays clean after remediation
This gives administrators a clear view of who has DNS administrative rights before those permissions are discovered through attacker reconnaissance.
How to Remove Users From DnsAdmins
The remediation goal is not to empty the group blindly. It’s to remove every membership that cannot be justified and protect any access that must remain.
Prerequisites
Before removing members:
- Domain Admin rights, or delegated rights to modify the DnsAdmins group.
- Confirm which members, if any, have a genuine, current need for delegated DNS administration.
- Obtain change control approval before removing any member.
PowerShell Method
You can remove reviewed accounts from DnsAdmins with PowerShell:
# Remove a single account from DnsAdmins. Replace <SamAccountName> with the reviewed account
Remove-ADGroupMember `
-Identity "DnsAdmins" `
-Members "<SamAccountName>" `
-Confirm:$false
# Remove multiple accounts listed in ApprovedObjects.csv. CSV must contain a SamAccountName column
$Items = Import-Csv -Path ".\ApprovedObjects.csv"
foreach ($Item in $Items) {
Remove-ADGroupMember `
-Identity "DnsAdmins" `
-Members $Item.SamAccountName `
-Confirm:$false `
}
Active Directory Users and Computers (ADUC) Method
To remove a member manually:
- Open Active Directory Users and Computers (dsa.msc).
- Navigate to the Users container.
- Locate the DnsAdmins group.
- Right-click, select Properties, and open the Members tab.
- Select the appropriate account and click Remove.
- Select Yes to confirm removal
- Click OK to save
Use Narrower DNS Delegation Where Possible
DnsAdmins grants broad DNS administration. That is often more access than an administrator needs. Active Directory-integrated DNS supports permissions at the zone and record level. Organizations can use separate groups and ACLs to delegate control over specific DNS zones rather than giving every DNS operator broad rights across the DNS service.
For example, an application team responsible for one internal DNS zone may need permission to manage that zone but have no reason to modify server-level DNS configurations. Reducing the scope of delegation removes an attack path while preserving the operational function.
Preventing DnsAdmins Membership from Becoming Standing Privilege
DnsAdmins should be managed as privileged access, not as an ordinary networking group.
- Keep DnsAdmins empty by default
If DNS is administered by existing administrators, such as Domain Admins, additional permanent DnsAdmins members provide little benefit. - Use scoped DNS permissions
Give administrators access to the zones or records they need rather than unrestricted DNS administration. - Protect retained members as Tier 0
Use dedicated administrative identities and hardened administrative workstations. Avoid using DnsAdmins accounts for email, web browsing, or routine workstation activity. - Review membership regularly
Include DnsAdmins in recurring privileged-access reviews alongside Domain Admins, Enterprise Admins, Schema Admins, and operator groups. - Monitor additions and removals
Alert on changes to DnsAdmins membership and verify each addition against an approved request. - Watch DNS Server configuration
Monitor unexpected changes to sensitive DNS settings, particularly the ServerLevelPluginDll configuration.
Quick Validation Checklist
Can you confidently answer “yes” to all of these?
✓ Do you know every direct and nested member of DnsAdmins?
✓ Are you monitoring additions and removals from this group?
✓ Would you detect an unexpected ServerLevelPluginDll configuration?
If any of these are unclear, your domain may have a standing path from a DNS delegation to full compromise.
Risk & Compliance Mapping
Business Impact: Successful abuse may lead to DNS manipulation, service disruption, privilege escalation, persistence, or domain-wide control.
| Framework | Reference |
|---|---|
| NIST CSF | PR.AA-05 (Access Permissions, Entitlements, and Authorizations) |
| CIS Controls | Control 5 (Account Management), Control 6 (Access Control Management) |
| MITRE ATT&CK / DEFEND | T1078.002 (Domain Accounts), T1098 (Account Manipulation) |
| Microsoft Security Baselines | Minimize privileged group membership, use tiered or just-in-time administration, and review privileged accounts regularly for activity, ownership, and necessity |
Frequently Asked Questions
Not always. Organizations with dedicated DNS administrators may have a legitimate reason to use it. Every member should have a documented requirement, and narrower DNS delegation should be used when it can accomplish the same job. Any membership present should be treated exactly like Domain Admins.
Yes. Active Directory-integrated DNS supports ACLs that can be used to delegate management of specific zones and records, reducing the need for broad server-level access.
That can be appropriate for some dedicated administrative accounts, but it should not be applied blindly. Protected Users changes authentication behavior and can break workflows that depend on NTLM, delegation, or other legacy authentication features.
The broader requirement is to treat retained DnsAdmins identities as Tier 0, protect their credentials, restrict where they can authenticate, and avoid using them for normal productivity work.
Not if the accounts performing DNS administration are already Domain Admins, which is the case in many environments observed. Confirm this before removing an account and test DNS management after the change.
Treat DNS Administration as Privileged Access
DnsAdmins doesn’t look like a Tier 0 group, which is exactly why it tends to stay populated after Domain Admins and Enterprise Admins have already been cleaned up. Insight Recon flags it alongside the other privileged groups most likely to get overlooked.
See exactly where your Active Directory is exposed and what to fix first.