DNSAdmins
Members of the DnsAdmins group have access to DNS information on the network. The Windows DNS service supports custom plugins and can call functions from them to resolve name queries that are not in the scope of any locally hosted DNS zones. The DNS service runs as NT AUTHORITY\SYSTEM, so membership in this group could potentially be leveraged to escalate privileges on a Domain Controller or in a situation where a separate server is acting as the DNS server for the domain. It is possible to use the built-in dnscmd utility to specify the path of the plugin DLL. As detailed in this excellent post, the following attack can be performed when DNS is run on a Domain Controller (which is very common):
DNS management is performed over RPC
ServerLevelPluginDll allows us to load a custom DLL with zero verification of the DLL's path. This can be done with the
dnscmdtool from the command lineWhen a member of the
DnsAdminsgroup runs thednscmdcommand below, theHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters\ServerLevelPluginDllregistry key is populatedWhen the DNS service is restarted, the DLL in this path will be loaded (i.e., a network share that the Domain Controller's machine account can access)
An attacker can load a custom DLL to obtain a reverse shell or even load a tool such as Mimikatz as a DLL to dump credentials.
Let's step through the attack.
Leveraging DnsAdmins Access
Generating Malicious DLL
We can generate a malicious DLL to add a user to the domain admins group using msfvenom.
rednorth@htb[/htb]$ msfvenom -p windows/x64/exec cmd='net group "domain admins" netadm /add /domain' -f dll -o adduser.dll
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 313 bytes
Final size of dll file: 5120 bytes
Saved as: adduser.dllStarting Local HTTP Server
Next, start a Python HTTP server.
Downloading File to Target
Download the file to the target.
Let's first see what happens if we use the dnscmd utility to load a custom DLL with a non-privileged user.
Loading DLL as Non-Privileged User
As expected, attempting to execute this command as a normal user isn't successful. Only members of the DnsAdmins group are permitted to do this.
Loading DLL as Member of DnsAdmins
Loading Custom DLL
After confirming group membership in the DnsAdmins group, we can re-run the command to load a custom DLL.
Note: We must specify the full path to our custom DLL or the attack will not work properly.
Only the dnscmd utility can be used by members of the DnsAdmins group, as they do not directly have permission on the registry key.
With the registry setting containing the path of our malicious plugin configured, and our payload created, the DLL will be loaded the next time the DNS service is started. Membership in the DnsAdmins group doesn't give the ability to restart the DNS service, but this is conceivably something that sysadmins might permit DNS admins to do.
After restarting the DNS service (if our user has this level of access), we should be able to run our custom DLL and add a user (in our case) or get a reverse shell. If we do not have access to restart the DNS server, we will have to wait until the server or service restarts. Let's check our current user's permissions on the DNS service.
Finding User's SID
First, we need our user's SID.
Checking Permissions on DNS Service
Once we have the user's SID, we can use the sc command to check permissions on the service. Per this article, we can see that our user has RPWP permissions which translate to SERVICE_START and SERVICE_STOP, respectively.
Check out the Windows Fundamentals module for an explanation of SDDL syntax in Windows.
Stopping the DNS Service
After confirming these permissions, we can issue the following commands to stop and start the service.
The DNS service will attempt to start and run our custom DLL, but if we check the status, it will show that it failed to start correctly (more on this later).
Starting the DNS Service
Confirming Group Membership
If all goes to plan, our account will be added to the Domain Admins group or receive a reverse shell if our custom DLL was made to give us a connection back.
Cleaning Up
Making configuration changes and stopping/restarting the DNS service on a Domain Controller are very destructive actions and must be exercised with great care. As a penetration tester, we need to run this type of action by our client before proceeding with it since it could potentially take down DNS for an entire Active Directory environment and cause many issues. If our client gives their permission to go ahead with this attack, we need to be able to either cover our tracks and clean up after ourselves or offer our client steps on how to revert the changes.
These steps must be taken from an elevated console with a local or domain admin account.
Confirming Registry Key Added
The first step is confirming that the ServerLevelPluginDll registry key exists. Until our custom DLL is removed, we will not be able to start the DNS service again correctly.
Deleting Registry Key
We can use the reg delete command to remove the key that points to our custom DLL.
Starting the DNS Service Again
Once this is done, we can start up the DNS service again.
Checking DNS Service Status
If everything went to plan, querying the DNS service will show that it is running. We can also confirm that DNS is working correctly within the environment by performing an nslookup against the localhost or another host in the domain.
Once again, this is a potentially destructive attack that we should only carry out with explicit permission from and in coordination with our client. If they understand the risks and want to see a full proof of concept, then the steps outlined in this section will help demonstrate the attack and clean up afterward.
Using Mimilib.dll
As detailed in this post, we could also utilize mimilib.dll from the creator of the Mimikatz tool to gain command execution by modifying the kdns.c file to execute a reverse shell one-liner or another command of our choosing.
Code: c
Creating a WPAD Record
Another way to abuse DnsAdmins group privileges is by creating a WPAD record. Membership in this group gives us the rights to disable global query block security, which by default blocks this attack. Server 2008 first introduced the ability to add to a global query block list on a DNS server. By default, Web Proxy Automatic Discovery Protocol (WPAD) and Intra-site Automatic Tunnel Addressing Protocol (ISATAP) are on the global query block list. These protocols are quite vulnerable to hijacking, and any domain user can create a computer object or DNS record containing those names.
After disabling the global query block list and creating a WPAD record, every machine running WPAD with default settings will have its traffic proxied through our attack machine. We could use a tool such as Responder or Inveigh to perform traffic spoofing, and attempt to capture password hashes and crack them offline or perform an SMBRelay attack.
Disabling the Global Query Block List
To set up this attack, we first disabled the global query block list:
Adding a WPAD Record
Next, we add a WPAD record pointing to our attack machine.
Last updated