Risks related to the DNSadmins group

Description of the assignment

In this article, we will explore the risks associated with the DNSAdmins group and why this group should be managed with great caution. This article is the first of a series dedicated to Active Directory and Azure security. The aim of these articles will be to raise awareness about topics where, during discussions or previous assessments, I have observed that many people were unaware of the associated risks.

To summarize, it began in 2017 with a Medium post by Shay Ber, which explained that privilege escalation from the DNSAdmins group to Domain Administrator was possible due to a feature allowing the loading of a DLL as SYSTEM. Several security articles have been published since then, and in 2021, a CVE-2021-40469 (a Remote Code Execution vulnerability) was published.

Now let’s dig a little bit into the subject.

DNS and DNSAdmins presentation

In an Active Directory environment, the DNS service is a critical component that ensures the proper functioning of Active Directory Domain Services (AD DS). AD DS relies on DNS as its domain controller location mechanism. Whenever key Active Directory operations such as authentication, updates, or searches are performed, computers use DNS to locate Active Directory domain controllers. Additionally, domain controllers rely on DNS to locate each other. When installing a new Active Directory forest and domain, DNS is automatically installed alongside Active Directory as the Global Catalog server for the forest and domain.

As for the DNSAdmins group, the Microsoft documentation indicates that “Members of the DnsAdmins group have access to network DNS information. The default permissions are Allow: Read, Write, Create All Child objects, Delete Child objects, Special Permissions. This group exists only if the DNS server role is or was once installed on a domain controller in the domain”. In other words, the DNSAdmins group has control over the DNS service and can perform actions such as configuring the DNS zones, managing records, and modifying DNS settings. This group is generally assigned to network administrators in charge of managing the network infrastructure (DNS, DHCP…) which make them good targets for attackers. This group is generally assigned to network administrators in charge of managing the network infrastructure (DNS, DHCP…).

The DNS service and the DNSAdmins group are both sensitive resources in an Active Directory environment which make them good targets for attackers.

Presentation of the attack

A summary of the DNSAdmins issue has been well detailed in a security blog post of adsecurity:

With all this information, we can now simulate a privilege escalation in a laboratory environment, demonstrating how an account that is part of the DNSAdmins group can escalate to Domain Administrator.

A new Active Directory forest has been set up with the DNS role. The patching detail of the server is the following:

drawing

We created a “Bob John” account and joined it to the DNSAdmins group. We will assume that this account has been compromised and use it to play out this scenario.

drawing

Then, we prepared our malicious DLL that will add our user “jbob” to the “Administrators” group on the Domain Controller.

drawing drawing

At this stage, we could assume that we have WinRM access to the Domain Controller and verify throught this WinRM connection that we are indeed in the DNSAdmins group.

drawing drawing

Now that we have access to the Domain Controller as jbob, we will use the “dnscmd.exe /config /serverlevelplugindll \\path\to\dll” command line to write our dll into the “ServerLevelPluginDll” Registry key.

drawing

The last action to perform is to restart the DSN service. It could be used with the dnscmd.exe command line as well.

drawing

After the restart of the DNS service, we could observe that the DLL has been executed with success and that our user jbob has been added to the Administrators group.

drawing

Now let’s have a look to the “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters\ServerLevelPluginDll” registry key and we could observe that the “ServerLevelPluginDll” entry has been added.

Before the exploitation:

drawing

After the exploitation:

drawing

Microsoft's Fix

In October 2021, Microsoft finally decided to release a fix which introduced a new registry key “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\InternalParameters” modifiable only by the administrators and were the “ServerLevelPluginDll” value has been moved.

Patches applied:

drawing

New registry key:

drawing

We tried to reproduce the attack after patching of the Domain Controller and we could observe that the exploitation is indeed not possible anymore.

drawing

To note that an effective way to detect this privilege escalation technique would be to monitor for changes on the registry path “HKLMSYSTEMCurrentControlSetServicesDNSParametersServerLevelPluginDLL” of the Domain Controller hosting the DNS service.

Synthesis of the analysis

We can conclude that this built-in feature could be an escalation opportunity for attackers and the DNSAdmins group should be treated carefully. Even with the security update, this functionality could still be reactivated and because the DNS is a critical service in an Active Directory environment it could be leveraged by an attacker to perform malicious actions in the domain (adding of arbitrary DNS name or even the replacing of a DNS entry to usurp an administration interface).

Finally, the following best practices should be followed to prevent the exploitation of this feature: