Coercion and Relay Attack

Coercion and relay attacks are the most common high risk vulnerabilities that are not detected by scanners.

In internal network that utilize Active Directory, coercion and relay attacks are the most common exploitable vulnerability that has never been detected by a vulnerability scanner. These attacks have lead me to full domain compromise in many occasions in environments that have no other exploitable vulnerabilities. Worst of all, many of these vulnerabilities are enabled by default in Microsoft Active Directory networks.

In this blog, I am going to discuss how to locate and leverage a combination of coercion and relay attacks for domain exploitation. These attacks are often overlooked by penetration testers as many certifications only cover them at a high level or not at all. The most renowned practical certifications like OSCP and CRTP do not cover these techniques as they break the exam lab environments and therefore cannot be covered. You’d be surprised with just how much there is to these techniques! 

Table of Contents

Coercion

NTLM Coercion attacks involves forcing a target system to authenticate to an attacker’s controlled system. This can be achieved through various methods that exploit legitimate protocols and services. The most common form of coercion are:

  1. DNS Poisoning and Coercion
  2. RPC coercion
  3. Service Coercion
    1. WebDAV coercion
    2. WPAD coercion.

DNS Poisoning and Coercion

Exploit Theory: Poison DNS records and wait

DNS poisoning exploits the DNS resolution process to force a target to authenticate to an attacker-controlled system. This can be done by manipulating DNS responses to direct traffic to the attacker’s machine. If the victim machine performed the DNS query to locate another machine and make a connection to that machine over a service that requires credentials like SMB, the attacker can spoof a SMB service and harvest Net-NTLM credential hashes. This happens because the victim believe’s they are still connection to the correct server and sends the authentication when prompted, but in reality, the DNS record was poisoned and pointing to an attackers machine.

 

In-Practice: DNS poisoning via vulnerable networking protocols

So how can you poison DNS records? The most common way it to exploit services and protocols that relay on the local network for DNS resolution. Windows protocols like Link-Local Multicast Name Resolution (LLMNR), NetBIOS (NBT-NS), and Multicast DNS (mDNS) will all broadcast DNS requests to the local network without validating the results. This overly high trust on the local network can be abused by an attacker by responding to these requests with intentionally falsified information that directs the victim to the attacker controlled machine.

 

Wait Time: Minutes to Hours

During real life penetration tests, this process can take minutes to hours because successfully capturing a hash. Since the victim will need to be requesting DNS resolution in order to use a credentialed service, many of the poisoned DNS requests end up with no captured credentials. The exact time to success will greatly depend on how many hosts are sending broadcast DNS requests, but in my experience, most success will come before 15 minute with some instances being nearly instant.

It’s also important to realize the this is an “opportunistic” attack many hosts may be vulnerable but you will still have to wait to for the perfect request to come through before you can capitalize. Therefore, it’s also very difficult to get a full list of affected hosts as you are likely to miss any hosts that happened to not send local network DNS requests while you are listening.

 

Public Tooling: Responder and Inveigh

 

Share the Post:

Related Posts