NTLM relay attacks in 2025: still devastating, still overlooked
NTLM relay remains one of the most powerful internal network attacks. Despite years of awareness, I still find it exploitable in ~70% of AD environments I test.
The attack
- Attacker coerces authentication from a privileged account (via LLMNR/NBNS poisoning, PetitPotam, PrinterBug, etc.)
- Relay the NTLM auth to a target that accepts it (LDAP, SMB, HTTP, MSSQL)
- Execute actions as the relayed identity
Why it still works
- NTLM not disabled (compatibility fears)
- LDAP signing not enforced
- SMB signing not required on all hosts
- EPA (Extended Protection for Authentication) not configured
Detection
Look for NTLM authentication from unexpected sources:
SecurityEvent
| where EventID == 4624
| where AuthenticationPackageName == "NTLM"
| where IpAddress != "127.0.0.1"
| summarize count() by IpAddress, TargetUserName
| where count_ > 50
Mitigation
- Enforce SMB signing on ALL hosts (GPO)
- Enforce LDAP signing and channel binding
- Disable NTLM where possible (start with auditing)
- Disable LLMNR and NBNS via GPO
- Enable EPA on all web services
The "compatibility fears" around disabling NTLM are mostly outdated. We disabled NTLMv1 entirely and restricted NTLMv2 to specific service accounts with monitoring. Breakage was minimal and easily fixable.
PetitPotam + NTLM relay to ADCS is still the fastest path from unauthenticated to domain admin I know. If you have unpatched ADCS with web enrollment enabled, you're one exploit away from full compromise.
For the detection query: also correlate with your network map. AlertMonitor's network mapping can show you which devices are using NTLM vs Kerberos, making it easier to build an NTLM decommission plan.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access