Weaponizing DHCP DNS Dynamic Updates for Unauthenticated Domain Compromise

TLDR: Active Directory environments often leave DHCP DNS dynamic updates enabled by default, creating a massive, unauthenticated attack surface. By spoofing DHCP requests, an attacker can force a server to register or overwrite DNS records, enabling NTLM relay attacks and traffic interception. Security teams should audit their DHCP configurations immediately and consider using static DNS records where dynamic updates are not strictly required.

Active Directory environments are built on a foundation of trust, but that trust is often misplaced in the protocols that keep the network running. While most researchers focus on Kerberoasting or BloodHound paths, the humble DHCP server remains a goldmine for anyone looking to pivot from an unauthenticated position to full domain control. The research presented at Black Hat 2023 on weaponizing DHCP DNS dynamic updates proves that we have been ignoring a critical, default-enabled attack vector for years.

The Mechanics of the Attack

At the core of this issue is the DNS Dynamic Update protocol, which allows network clients to register their own hostnames and IP addresses with a DNS server. In many Windows environments, this is tied directly to DHCP. When a client joins a network, it requests an IP address from the DHCP server. If the server is configured to perform DNS updates on behalf of the client, it sends a dynamic update request to the DNS server.

The vulnerability arises because the DHCP server does not verify the identity of the client requesting the update. If an attacker can reach the DHCP server, they can send a crafted DHCP request specifying an arbitrary Fully Qualified Domain Name (FQDN). The DHCP server, acting as a trusted entity within the domain, then performs the DNS update. Because the DHCP server is usually a domain-joined machine with high privileges, the DNS server accepts the update without question.

From Spoofing to Relay

This technique is not just about creating fake records. It is about weaponizing the trust the DNS server places in the DHCP server. During the research, it was demonstrated that an attacker can use this to perform NTLM relay attacks. By overwriting the DNS record of a legitimate file server or a domain controller, an attacker can redirect traffic intended for that server to their own machine.

When a victim attempts to connect to the "spoofed" server, the attacker’s machine intercepts the connection. If the victim’s machine attempts to authenticate using NTLM, the attacker can relay those credentials to a target service. The following command illustrates how one might use impacket’s ntlmrelayx.py to set up the relay listener:

python3 ntlmrelayx.py -smb2support -t 172.25.14.10

Once the relay is active, the attacker simply needs to wait for a victim to attempt a connection. Because the DNS record has been successfully overwritten, the victim’s machine believes it is talking to the legitimate server, providing the attacker with a perfect man-in-the-middle position.

Real-World Applicability

During engagement testing, this attack surface is surprisingly common. Monitoring data across thousands of networks shows that Microsoft DHCP is present in over half of them. In many of these cases, the default configuration allows for dynamic updates without any form of authentication.

For a pentester, this means that as soon as you gain a foothold on the local network, you can start scanning for DHCP servers. If you find one, you don't need to hunt for credentials or exploit a complex vulnerability. You simply need to send a DHCP request with a spoofed FQDN. The impact is immediate: you can redirect traffic, capture sensitive data, or even block access to security monitoring tools like SIEM or EDR servers by pointing their DNS records to a non-existent IP address.

Defensive Strategies

Defending against this requires a shift in how we view network services. The most effective mitigation is to disable DHCP DNS dynamic updates entirely if they are not strictly necessary for your environment. If you must use them, you should implement DNS Name Protection, which uses a unique DHCP client identifier (DHICD) to prevent unauthorized overwrites.

However, even with name protection, the risk remains if an attacker can spoof a DHCP release. The most robust defense is to move away from dynamic updates for critical infrastructure. Use static DNS records for servers, domain controllers, and any other high-value assets.

To help teams assess their exposure, the research includes the release of Invoke-DHCPCheckup, a PowerShell tool that scans your Active Directory environment to identify DHCP servers and check their DNS update configurations. Running this tool is the first step toward understanding how much of your network is currently vulnerable to this class of attack.

Do not assume that your internal network protocols are secure just because they are "internal." The trust model of Active Directory is often its greatest weakness. By auditing these configurations now, you can close a door that has been left wide open for far too long.