DNSForge – Relaying with Force

Introducing a new attack mode for greater flexibility and customization.

Respond vs. Relay Mode

The original attacker tactic introduced with DNSForge facilitates a DNS poisoning attack that leverages ARP spoofing to achieve an adversary-in-the-middle condition. This initial attack mode (termed as “respond” mode) induces on-path hosts to treat the attacking host as the DNS server and route subsequent DNS requests accordingly. To achieve this, DNSForge issues ARP broadcasts advertising that the legitimate DNS server’s IP address is available at the attacking host’s MAC address. Once the attacking host receives a valid DNS request, DNSForge issues a DNS response based on validation parameters supplied by the operator. In this “respond” mode, DNSForge acts as a rogue DNS server and is expected to fulfill all requests from all DNS clients since the legitimate DNS server is no longer reachable by clients who accepted the spoofed ARP entry. Thereby, this mode expects the operator to set a legitimate DNS server’s IP address as the ARP spoofing target.

Figure 1. Traffic flow in respond mode.

This blog post introduces the “relay” mode that achieves interception of a victim client’s DNS response while it is on the way back to the client. In this mode, the ARP spoofing target is set to victim clients on the same subnet, which results in DNSForge issuing ARP broadcasts advertising that the victim clients’ IP addresses are available at the attacking host’s MAC address. These broadcasts poison the ARP cache of the gateway (in the case the DNS server resides outside the attacking machine’s subnet) and/or the DNS server when it resides on the same subnet as the attacking machine. Therefore, the DNS response that is on its way back from the server to the victim client is received by DNSForge on the attacking machine. At this stage, DNSForge performs modifications to the DNS response issued by the legitimate DNS server (such as the resolved IP address) and forwards the packet to the victim client.

Figure 2. Traffic flow in relay mode.

Attack Customization

The addition of the relay mode allows for greater flexibility given the operator’s situation and attack context. In some cases, this mode can provide greater efficiency and reduced network load as well.

For instance, when DNSForge runs in respond mode and the DNS server resides outside the attacking machine’s subnet, the ARP spoofing target is set to the gateway. The tool ensures that IP forwarding is enabled to prevent denial-of-service on the subnet as with the ARP spoofing target set to the gateway, all traffic that leaves the subnet is routed via the attacking machine. IP forwarding ensures network reliability for victim clients that reside on the same subnet as the attacking machine. Nevertheless, processing traffic for the entire subnet can overwhelm the attacking machine. Even more so, this approach may seem wasteful as DNSForge will only poison DNS requests that match validation parameters, which will be a small percentage of all observed network traffic.

However, with the newly introduced relay mode, DNSForge can simply be configured to perform ARP spoofing against victim clients and so the tool will intercept DNS responses on their way back from the DNS server. In this setting, an operator can specifically target one or more victim clients on the same subnet and only intercept traffic that’s destined for those clients. Therefore, in this scenario, the relay mode improves the efficiency of the attack.

In another example, an operator may use respond mode when the network landscape is relatively unfamiliar and hence impersonating a DNS server will achieve credential capture for all clients – this approach is synonymous to carpet bombing the entire subnet. On the other hand, an operator may use the relay mode when the details of on-path clients are well known and hence DNS requests from only a handful of clients need to be poisoned – this approach is synonymous to a precision airstrike on hand-picked targets. This customization allows operators to pick their specific goal with the added benefit of improving the stealthiness of the attack.

Relay Mode and ntlmrelayx

Finally, since the relay mode improves the consistency of credential interception, it can be effectively paired up with Impacket’s ntlmrelayx.py to perform credential relaying attacks. As compared to a pairing with Responder that simply captures hashed credentials, ntlmrelayx can relay authenticated inbound connections to one of many services that are available in an Active Directory environment such as SMB, LDAP/S or HTTP/S. This provides greater flexibility in environments where cracking captured hashes proves challenging. Relaying the credential allows the operator to assume authenticated access to the relayed service without having to crack the hash. Moreover, since DNSForge can target DNS requests for WPAD that result in interactions over HTTP, the inbound authentications can be relayed while bypassing SMB signing restrictions.

A sample attack scenario is as follows: an attacker identifies a client on the same subnet that is used by a network administrator who has a highly privileged active directory user account. This user has set an extremely complex and long password, which makes password cracking unrealistic and hence a credential relaying attack is more reasonable.

First, the attacker sets up DNSForge in relay mode to specifically target the identified client:

$ sudo dnsforge relay -i <interface> -p <attacker-ip> -t <client-ip> -q wpad

Next, the attacker sets up ntlmrelayx to first serve a PAC file and subsequently relay inbound HTTP connections to the LDAPS service on the domain controller. This will dump domain information such as users, groups, OUs, password policy and more. However, this command can be modified to perform other actions such as elevate privileges, add computer accounts and more.

$ impacket-ntlmrelayx -t ldaps://<domain-controller-ip> -wh <attacker-ip>

Note: If you previously ran Responder instead of ntlmrelayx to serve the PAC file to the client, it advertises the HTTP proxy on port 3128 as compared to port 80 used by ntlmrelayx. Hence, clients that have already registered the PAC file from Responder may not route connections via ntlmrelayx’s rogue proxy server at port 80 until the PAC file from ntlmrelayx is registered. To overcome this, ntlmrelayx can be configured to run the HTTP server on a custom port:

$ impacket-ntlmrelayx -t ldaps://<domain-controller-ip> -wh <attacker-ip> --http-port 3128

Conclusion

This blog post and updated tool provide additional capabilities to operators allowing greater customizability based on the network context and attack goals. The newly added “relay” mode allows for highly targeted attacks against specific clients – improving operational stealth and minimizing disruptions. The code for DNSForge can be found here: https://github.com/AonCyberLabs/DNSForge