DNSForge – Responding with Force

DNSForge – Responding with Force
Cyber Labs

04 of 20

This insight is part 04 of 20 in this Collection.

September 9, 2024 10 mins

DNSForge – Responding with Force

DNSForge – Responding with Force

Introducing DNSForge, a novel attacker tactic for responding to name resolution requests made to the authoritative DNS server in an internal network landscape, achieving interception and reuse of system credentials without user interaction. 

Background

Over the years, name resolution poisoning has become a prevalent attack vector for achieving adversary-in-the-middle capabilities within enterprise network environments. This vector has been primarily leveraged against Microsoft Windows systems since they employ a variety of protocols to service name resolution requests. A major victim of this attack has been the Link-Local Multicast Name Resolution (LLMNR) protocol that allows hosts on the same local link to perform name resolution for other hosts. This protocol is used as a fallback for name resolution when the configured DNS server cannot service the request.

Since LLMNR poses a significant threat to networked Windows systems, Microsoft released a patch (MS16-077) that permitted name resolution requests for critical components, such as Web Proxy Auto-Discovery (WPAD), to be solely serviced by the authoritative DNS server over the DNS protocol. This was a crucial patch because while poisoning regular name resolution requests does not result in interception of user credentials without user interaction, WPAD requests can be coerced to include the logged-on user’s credentials impromptu. Moreover, WPAD automatically attempts to fetch proxy configurations over the local network periodically or after the Windows system connects to a network, which makes the risk even more pronounced.

Soon after Microsoft published the patch, a new tool (mitm6) was released that attempts to take over the DNS server configured on Windows systems by replying to DHCPv6 messages. This tool circumvents the protections introduced in the patch as an attacker can readily respond to WPAD messages once the DNS server configured on the victim system points to an attacker-controlled address. However, this tool relies on a default configuration on Windows systems and can be rendered ineffective by simply disabling IPv6 across the network. Moreover, this tool also spams the network with Router Advertisements, which can be readily detected by security features such as Cisco’s IPv6 RA Guard or manually by a security operations team.

Introduction

DNSForge reveals a novel attacker tactic for responding to name resolution requests made to the authoritative DNS server. This tool is intended to run alongside Responder. The tool makes use of ARP spoofing to induce victims (that request name resolution) to redirect DNS requests to the attacker’s host. Once it observes a DNS request while sniffing local network traffic, DNSForge crafts a DNS response message that indicates that the requested name is resolved to the attacker’s IP address and subsequently issues the DNS response. After the victim accepts the poisoned IP address as the resolution for the intended hostname, it attempts to interact with the attacker’s host in one of many ways. This can include Web Proxy Auto-Discovery (in case of a WPAD resolution request), which takes place without user interaction or interacting with services like FTP, HTTP, SMB, etc. on the attacker’s host. Once an interaction is initiated, a victim user may be prompted to submit credentials or (in case of a WPAD request) the system will automatically submit hashed credentials for the logged-in user. This final segment is serviced by the Responder tool, which spins up servers for various services, serves a malicious Proxy Auto-Configuration (PAC) file and captures the password hash submitted as a result of the aforementioned interaction.

The novelty of DNSForge is realized when servicing name resolution requests that don’t fallback to a vulnerable protocol (such as LLMNR). Hence, WPAD requests (or other requests that would’ve otherwise been successfully serviced by the authoritative nameserver) make the perfect candidate for extracting maximum utility from this tool as it reveals attack surface for name resolution poisoning that was previously inaccessible. In case of WPAD requests, the attacker is granted immediate access to hashed credentials without any user interaction.

Attack Sequence

The attack scenario commences when an adversary has local network access to an internal network environment where Active Directory Domain Services are running, including Domain Controllers and domain-joined Windows servers and workstations. At this point, DNSForge can be used to effectively poison name resolution requests made over the DNS protocol.

The following is a typical attack scenario where the tool operates in default mode, intercepts a DNS WPAD request, and poisons the response to capture credentials without user interaction.

  1. Run DNSForge with the required parameters, which starts a packet capture on the selected network interface, filtering for DNS requests to UDP port 53.
  2. In a thread, DNSForge also broadcasts Address Resolution Protocol (ARP) messages for the supplied target (generally the authoritative nameserver) on the local network. This will induce the victim system (and other hosts on the same local link) to send any subsequent packets intended for the authoritative nameserver to the adversary system’s MAC address.

    Step 2: Adversary poisons ARP on the local network
  3. Next, run Responder and wait for the victim system to issue a name resolution request for WPAD, which will now be sent to the adversary system’s MAC address. Once DNSForge observes a matching DNS request on the network, it issues a response containing the attacker’s IP address.

    Step 3: Victim issues DNS request for WPAD and adversary responds with poisoned response
  4. As a result, the victim system accepts the poisoned response and requests the Proxy Auto-Configuration (PAC) file. Responder steps in and serves a malicious configuration, which forces authentication and subsequently captures credentials for the logged in user on the victim system.

    Step 4: Victim requests PAC and adversary responds with malicious PAC

Stealth Mode

DNSForge contains a stealth mode as well, which intends to mimic the DNS response exactly as it would be generated by the authoritative nameserver. This mode provides flexibility for high-stealth covert operations where there may be Intrusion Detection System (IDS) / Intrusion Prevention System (IPS) devices that are monitoring DNS poisoning attempts on the network.

Hence, with this mode enabled, the attack sequence above is preceded by a step where the tool requests the SOA record from the authoritative DNS server and appends the captured record to the issued DNS response when forging responses in step 3.

Stealth Mode: Adversary obtains SOA record from Authoritative Nameserver

Real-Life Scenario

DNSForge lent itself well on a recent cloud internal penetration test where all target servers had SMB signing enabled and IPv6 and LLMNR were disabled on the network via Group Policy Objects (GPOs). This configuration only allowed for name resolution poisoning via MDNS/NBT-NS and DNS – however, the domain implemented an extremely strict password policy, so cracking NetNTLMv2 hashes obtained via SMB was not time efficient. Conversely, NTLM relaying attacks provided a more realistic approach, but again, with SMB signing enforced, an interaction over HTTP was desired. At this point, historically, mitm6 would’ve been the ideal choice to poison over DNS, but with IPv6 disabled, that wasn’t possible either. Finally, DNSForge came to light and was able to respond to name resolution requests over DNS, leading to an interaction over HTTP due to WPAD and a credential relay to LDAP on the Domain Controller. This was leveraged to add a backdoor computer account and gain a domain foothold!

Limitations and Workarounds

This tactic relies on ARP spoofing to induce the victim into modifying its ARP table and subsequently forwarding packets intended for the authoritative nameserver to the attacker host’s MAC address. Therefore, any network environment that contains network security devices that block ARP broadcasts for ARP spoofing attempts will remain protected against this attack.

Moreover, ARP spoofing remains effective against devices within the same subnet as the attacking host. To work around this limitation, if the attacking host is on a sparse subnet and not yielding success from this attack, it may be beneficial to pivot to a denser subnet and try again.

Comparisons

At this point, you may be wondering what distinguishes this tool from Responder, which can itself respond to DNS queries. The distinction lies in the method adopted for interception of DNS requests – specifically, Responder starts a rogue DNS server that listens on UDP 53 for incoming DNS packets addressed (logically and physically) to the attacker’s host. On the other hand, DNSForge sniffs local network traffic and awaits to observe a DNS request matching the query name provided when running the tool.

With promiscuous mode and port mirroring disabled on most internal networks, the attacker host’s network adapter is only privy to packets that are addressed to its physical (MAC) address. Once ARP spoofing takes place, a victim client requesting name resolution addresses the DNS request packet to the attacker’s physical (MAC) address while including the authoritative DNS server’s logical (IP) address. As a result, this packet can be observed by DNSForge on the local network but not seen by Responder as the discrepancy between the logical and physical address means that the rogue DNS server never records an incoming DNS request.

While this discrepancy can be temporarily resolved by assigning a secondary IP address to the active network interface to match that of the authoritative DNS server, this approach can lead to IP address conflicts and can be cumbersome in environments with multiple authoritative DNS servers.

Conclusion

While LLMNR (and other vulnerable name resolution protocols) are enabled by default in Windows environments, they can be disabled to thwart name poisoning attacks on the local network. DNSForge reveals a novel tactic that allows forging of DNS responses such that they appear to originate from the authoritative nameserver as compared to LLMNR name poisoning, which doesn’t originate from a trusted source. As a result, this tool can circumvent existing mitigations against LLMNR and IPv6 for name resolution poisoning and more specifically, when used to forge DNS responses for WPAD, can lead to capturing of hashed credentials without any user interaction.

The code for DNSForge can be found here: https://github.com/AonCyberLabs/DNSForge

Aon’s Thought Leader
  • Apurva Goenka
    Senior Consultant, Security Testing, Cyber Solutions

About Cyber Solutions:

Cyber security services are offered by Stroz Friedberg Inc., its subsidiaries and affiliates. Stroz Friedberg is part of Aon’s Cyber Solutions which offers holistic cyber risk management, unsurpassed investigative skills, and proprietary technologies to help clients uncover and quantify cyber risks, protect critical assets, and recover from cyber incidents.

General Disclaimer

This material has been prepared for informational purposes only and should not be relied on for any other purpose. You should consult with your own professional advisors or IT specialists before implementing any recommendation, following any of the steps or guidance provided herein. Although we endeavor to provide accurate and timely information and use sources that we consider reliable, there can be no guarantee that such information is accurate as of the date it is received or that it will continue to be accurate in the future.

Terms of Use

The contents herein may not be reproduced, reused, reprinted or redistributed without the expressed written consent of Aon, unless otherwise authorized by Aon. To use information contained herein, please write to our team.

More Like This

View All
Subscribe CTA Banner