Skip to content
Pwnversity

NTLM Relay

The NTLM authentication protocol is challenge-response: the client proves it knows the hash without sending it. The problem is that the proof isn’t bound to the server it’s aimed at. If an attacker captures (or coerces) a victim’s NTLM authentication attempt, they can forward it in real time to a third service and authenticate as the victim there, without knowing or cracking their password. That’s NTLM relay: you don’t steal the credential, you redirect it.

flowchart LR
    V[Victim] -->|"NTLM auth"| A[Attacker / relay]
    A -->|"forwards the auth"| T[Target server]
    T -->|"access as the victim"| A

Threat model

Section titled “Threat model”

NTLM lacks a strong binding between authentication and the target channel/service. The defense that breaks it is signing (SMB signing, LDAP signing + channel binding): if the service requires signing, the relay fails because the attacker can’t sign with the session key. Where signing isn’t required —and by default it isn’t always— relay works. The attacker chains coercion → relay → execution/escalation.

Red Team

Section titled “Red Team”

The flow

Section titled “The flow”
1. victim authenticates to the attacker (LLMNR/Responder, coercion, WPAD)
2. ntlmrelayx forwards that handshake to a target service
3. the target believes it's the victim -> attacker acts as them

Important: Responder and ntlmrelayx compete for ports 445/80; for relay you disable Responder’s SMB/HTTP (Responder.conf) and let ntlmrelayx receive.

Tools and relay targets

Section titled “Tools and relay targets”
# relay to SMB to execute or dump SAM where the victim is local admin
ntlmrelayx.py -tf targets.txt -smb2support
# relay to LDAP/LDAPS on the DC -> RBCD or shadow credentials
ntlmrelayx.py -t ldaps://<DC> --delegate-access
# relay to AD CS Web Enrollment (ESC8) -> certificate -> victim's TGT
ntlmrelayx.py -t http://<CA>/certsrv/certfnsh.asp -smb2support --adcs --template User

High-impact relay destinations:

  • SMB → run commands / dump SAM on a host where the relayed account is local admin.
  • LDAP(S) on the DC → write RBCD over a computer (Kerberos Delegation) or Shadow Credentials (Shadow Credentials) → then impersonate.
  • AD CS HTTP (ESC8) → request a certificate as the victim → use it to get their TGT (AD CS (Active Directory Certificate Services)). If the coerced victim is a DC, this is full domain compromise.
  • Internal MSSQL, HTTP.

Coercion (getting the victim to authenticate)

Section titled “Coercion (getting the victim to authenticate)”
  • PetitPotam (EFSRPC), PrinterBug/SpoolSample (MS-RPRN), DFSCoerce, ShadowCoerce, Coercer → force a server (including a DC) to authenticate to the attacker.
  • mitm6 (DHCPv6/WPAD) → force authentication via proxy.
  • UNC injection (\\attacker\x) in documents, LDAP fields, etc.

The combo PetitPotam (coerce DC) → relay to AD CS (ESC8) → DC certificate → DCSync is one of the strongest chains to Domain Admin.

Tools

Section titled “Tools”
  • impacket ntlmrelayx.py — the relay engine (SMB/LDAP/HTTP/AD CS/MSSQL).
  • Responder / Inveigh — LAN capture/coercion.
  • PetitPotam / Coercer / SpoolSample / DFSCoerce — forced coercion.
  • mitm6 — relay via IPv6.

Impact

Section titled “Impact”

Command execution, credential dumping, creating delegation paths (RBCD), and, chained with DC coercion + AD CS, full domain takeover without cracking a single password.

Blue Team

Section titled “Blue Team”

Detection

Section titled “Detection”
  • NTLM authentications where source and destination don’t fit the normal flow; a machine account (DC$) authenticating to odd hosts (sign of coercion+relay).
  • MS-EFSRPC/MS-RPRN calls toward non-server machines (PetitPotam/PrinterBug).
  • Anomalous certificate requests in AD CS (ESC8); unexpected msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD) writes.

Telemetry

Section titled “Telemetry”

Events 4624/4648 (NTLM logon), AD CS auditing (issued certificates), delegation-attribute changes on the DC, and coercion detection (RPC traffic to \pipe\efsrpc, \pipe\spoolss).

Hardening

Section titled “Hardening”
  • Require signing: mandatory SMB signing on all hosts, LDAP signing + LDAP channel binding on DCs (breaks LDAP relay).
  • EPA (Extended Protection for Authentication) on web services, especially AD CS Web Enrollment (mitigates ESC8); or disable HTTP enrollment.
  • Disable NTLM where possible (Kerberos only); Protected Users, Channel Binding.
  • Mitigate coercion: patches (PetitPotam), disable the Spooler on DCs, filter RPC.
  • Reduce/remove unused LLMNR, NBT-NS, WPAD, IPv6 (cuts the initial capture — see LLMNR / NBT-NS / mDNS Poisoning).

Response

Section titled “Response”

Identify the chain (coercion source, relayed service), isolate, revert malicious RBCD/shadow creds/issued certificates, rotate credentials (including the machine account/krbtgt if the DC was touched), and apply signing/EPA.

CVEs and real-world cases

Section titled “CVEs and real-world cases”
  • PetitPotam (CVE-2021-36942) + AD CS ESC8 → public DC-coercion-to-Domain-Admin chain; heavily exploited.
  • PrinterBug (MS-RPRN) and DFSCoerce — coercion without a reliable patch for years.
  • Drop the MIC (CVE-2019-1040) and CVE-2019-1166 — MIC bypasses that revived relays thought mitigated.
  • MITRE T1557.001 (relay) + T1187 (forced authentication); present in ransomware and APT playbooks.

Testing checklist

Section titled “Testing checklist”
  • SMB signing not mandatory on target hosts? (relay to SMB viable)
  • LDAP signing / channel binding not enforced on DCs? (relay to LDAP → RBCD/shadow)
  • AD CS Web Enrollment (HTTP) without EPA? (ESC8)
  • Coercion possible (PetitPotam/PrinterBug/DFSCoerce) toward a DC?
  • mitm6/IPv6 available to force auth?
  • Full chain coerce DC → relay AD CS → DCSync
  • Blue: MS-EFSRPC/MS-RPRN detection and signing applied?

References

Section titled “References”