NTLM Relay Attacks

NTLM relay is an architectural weakness in challenge-response authentication without mutual authentication or channel binding: the attacker’s machine sits between a victim and a target, forwarding the victim’s NTLM handshake messages to a different server, which authenticates the relayed credential as legitimate. No password is ever cracked — the victim’s NT hash never crosses the wire, only the challenge-response proof. Consistently a top-three finding in Active Directory penetration tests. 1

Attack chain

  1. Coercion — force a machine (ideally privileged) to authenticate to the attacker:
    • Responder (passive): answers LLMNR/NBT-NS/mDNS name queries, capturing broadcast auth
    • PetitPotam: MS-EFSRPC EfsRpcOpenFileRaw
    • PrinterBug: MS-RPRN RpcRemoteFindFirstPrinterChangeNotification (works against DCs with print spooler)
    • DFSCoerce: MS-DFSNM
  2. Relay — Impacket ntlmrelayx.py forwards the captured NTLM exchange to a target before it expires. NTLM tokens are protocol-agnostic: auth captured over SMB can be relayed to LDAP, HTTP, MSSQL, IMAP, SMTP.
  3. Impact — depends on the relay target:
    • LDAP on a DC: modify AD objects, add computer accounts, configure RBCD, dump domain
    • SMB on a file server: code execution / file access as the coerced machine account
    • AD CS web enrollment (ESC8): request a certificate as the victim → persistent access via PKINIT
    • Shadow credentials: write msDS-KeyCredentialLink via LDAP relay → TGT without password

See windows-server-2012-r2-security-assessment for detection/confirmation steps.

Key capabilities of ntlmrelayx (Impacket 0.9.21+)

  • Multi-relay: identifies the victim user first, then forces re-authentication (STATUS_SESSION_EXPIRED on SMB, HTTP 307 on HTTP v0.10.0+) to relay ONE victim connection to MULTIPLE targets simultaneously. Fails if the victim’s client enforces signing.
  • SOCKS mode (-socks): keeps relayed sessions alive for interactive tool reuse.
  • Cross-protocol: -t ldap://dc01 with -smb2support relays SMB-captured auth to LDAP.
  • AD CS: --adcs --template X --altname administrator@corp.local (ESC8; with ESC1/ESC6 misconfigurations, request certs as any user).
  • StartTLS bypass: plain LDAP (389) relay auto-upgrades to StartTLS; the attacker’s TLS channel mismatches the victim’s channel-binding token, but non-enforcing DCs (the default) ignore the mismatch. 2

Why defaults fail

ControlDefaultConsequence
SMB signingRequired only on DCs; workstations/member servers “if agreed”Relay to member machines works
LDAP signingNot requiredRelay-to-LDAP works
LDAP channel bindingDisabled (LdapEnforceChannelBinding=0)StartTLS bypass works
HTTP EPADisabled on IIS/Exchange/AD CSESC8 relay to /certsrv/ works

Signing protects the session after authentication, not the authentication exchange itself — but a relay attacker can’t sign (lacks the session key from the victim’s NT hash), so enforced signing breaks the relay. 3

Remediation (defense in depth — no single control suffices)

  1. SMB signing required, all machines: GPO ‘Microsoft network server: Digitally sign communications (always)’ = Enabled. Verify: Get-SmbServerConfigurationRequireSecuritySignature=True.
  2. LDAP signing required on DCs: ‘Domain controller: LDAP server signing requirements’ = Require signing.
  3. LDAP channel binding: HKLM\System\CurrentControlSet\Services\NTDS\Parameters LdapEnforceChannelBinding = 2 (registry only, no GPO).
  4. EPA on all HTTP services (IIS, Exchange, AD CS web enrollment).
  5. Disable LLMNR (GPO: DNS Client → ‘Turn off multicast name resolution’) and NBT-NS (NetbiosOptions=2 per interface, or DHCP option 001) — kills passive coercion.
  6. Restrict NTLM progressively: ‘Network security: Restrict NTLM’ (audit first).
  7. Harden AD CS: remove CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT from templates, disable EDITF_ATTRIBUTESUBJECTALTNAME2, manager approval on sensitive templates.
  8. Disable print spooler on DCs (kills PrinterBug); patch KB5005413 (partial PetitPotam only — authenticated EFS coercion and other techniques remain).

Deployment order: LLMNR/NBT-NS → LDAP signing → SMB signing on servers → workstations, piloting each layer. Audit SMBv1 clients first (Get-SmbConnection | ? Dialect -eq '1.0').

Detection

  • Event 4624 (logon type 3) from unexpected source IPs — machine accounts authenticating to unfamiliar IPs suggest Responder relay
  • Event 5145 — non-admin workstations accessing IPC$ on DCs (coercion indicator)
  • Event 31017 (SMBServer/Security) — signing negotiation failures after enforcement (legacy devices or relay attempts)
  • Events 4741 + 4728 — computer account created then immediately group-added (relay outcome)
  • Event 4776 on DCs — NTLM credential validation correlation; Defender for Identity Event 2013 (NTLM relay on AD CS)

Related: windows-server-2012-r2-security-assessment, ntlm-hashes, kerberos (the ticket-based successor to NTLM — relay attacks are the NTLM-side analogue of kerberoasting and golden-and-silver-ticket-attacks), impacket (ntlmrelayx.py is an Impacket example script), opc-ua-security (contrast: ICS/OT protocols face the same “built-in but not turned on” gap), cooperation-and-defection (defensive configuration as an institutional enforcement problem).

See Also

Sources

Additional reading

Footnotes

  1. SecureAuth — We Love Relaying Credentials: A Technical Guide to Relaying Credentials Everywhere

  2. SecureAuth — We Love Relaying Credentials: A Technical Guide to Relaying Credentials Everywhere

  3. Eric Bang (Decryption Digest) — SMB Signing Enforcement: How to Stop NTLM Relay Attacks

  4. I’m bringing relaying back: A comprehensive guide on relaying anno 2022 — TrustedSec