Windows Privilege Escalation: DnsAdmins to DomainAdmin

In this article, we will show you a method for Escalating Privilege on Windows-based Devices when it contains a compromised user of the DnsAdmins Group.

Table of Content

·         Introduction

·         Setting Up

·         Enumeration

·         Exploitation

·         Indicator of Compromise

·         Conclusion

Introduction

In our long series in search for methods to elevate privileges on Windows Devices. Today, we look at DnsAdmins. To able to understand this you need to understand the implantation of DNS on Windows by Microsoft. The Microsoft Team designing DNS integration decided to make the Domain Controller a DNS server by default. To manage that DNS service a group was created by the name of DnsAdmins. Then came the ability for the users of DnsAdmins to run code with elevated privileges that in their eyes was a feature. The DNS Management protocol lies on top of RPC. An executable by the name of dns.exe can be found under C:\Windows\System32\ in Domain Controllers. In an essence, on Domain Controller the DNS server runs as a server. As with every service, it is possible to manage it using an interface that can be found at the dnsmgmt.msc. If you search for all the operations that are required to be supported by the server a R_DnssrvOperation comes into light. It contains the pszOperation parameter. This parameter enables the user that is a part of the DnsAdmins group to load a DLL which it doesn’t even monitor for content. DnsAdmins users can execute this DLL with elevated privilege which makes them susceptible to Privilege Escalation.

Setting Up

To set up the conditions in our local environment for able to test the possibility of privilege escalation, we need to create a user. Then add that particular user to the DnsAdmins Group. In the demonstration, we have a domain controller that is all set up with a bunch of devices and users connected to it. We take the jeenali user and select the Add to a group option from the drop-down menu.

Clicking on Add to a group will open a new window that can enable the user to select the group they want to add their user to. Type in DnsAdmins in the Enter the object names to select field and click on Check names option. When It gets underlined as demonstrated, click on the OK button to add the user to that group.

Enumeration/Detection

The setup is complete with the jeenali user being a member of the DnsAdmins group. To verify in this case or case we do this demonstration from an attacker perspective to understand what would be the indicators that will point towards and the process through which the attacker would figure out if the target is vulnerable to this kind of privilege escalation. We connect to the jeenali user. We assume that the attacker has control or credentials for this user. After establishing a connection through Evil-WinRM we use the whoami command with the group parameter to enumerate for the groups that the current user i.e., belong to. We see that the jeenali user is a part of the DnsAdmins group. This verifies the setup we did earlier.

Exploitation

From the introduction, we know that the member of the DnsAdmins group can run the DLL file with elevated privileges. To exploit that privilege, we need to craft a malicious DLL file. We will be using msfvenom with the shell_reverse_tcp payload. We name the file raj.dll. The file we created is on our Kali machine. We use the smbserver.py python script from Impacket to host the /root directory as demonstrated below.

There are multiple ways to transfer the file to the target system, but there is always a chance that any Malware Scanner or Defender will detect the file and either quarantine it or remove it. Hence, we are hosting it on the smb server that makes it available for the Windows machine, and then we will directly interact with the DDL over the network. The executable we will use to pass the DLL code into the memory as SYSTEM is called dnscmd.exe. With the config and serverlevelplugindll parameters, we will pass the path of the DLL over the network as demonstrated below.

On the Kali machine on the SMB Server, it can be observed that a connection was made from the Domain Controller.

Here, at this stage, there are two specific tasks that the attacker needs to perform, to get the shell. First, the attacker needs to run a netcat listener on a new terminal on the same port that was mentioned while crafting the payload. Secondly, the DLL file was transferred but was not executed earlier. To make the DLL injected inside memory, we need to restart the DNS Service.

As soon as the service was restarted, a new connection was made on the netcat listener. After running the whoami command, it can be confirmed that the session was generated was as Administrator and not as a Jeenali user. This also confirms that the DLL was executed as SYSTEM when the user is a member of the DnsAdmins group.

Indicator of Compromise

When the attack using this method is performed, there is an indicator that can help identify the incident. During the attach when we run the command dnscmd.exe, it creates an entry in the Registry of the Target Machine. The same can be checked to obtain the IP address from which the attack was mounted and the DLL file that was used for the compromise.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters\ServerLevelPluginDll.

Conclusion

This article/demonstration presents the attacker with an opportunity to escalate its access after the initial foothold. Being a member of a group can provide direct exploitation to the SYSTEM. Hence, from Blue Teamer’s perspective, it is advised to always authorize proper permissions and make sure the users are not assigned groups that they are not supposed to access. Also, treating the DnsAdmins group with the same attention as the Administrator group.