How to detect NTLM relay and coercion attacks

Threat snapshot

NTLM relay is one of the oldest credential abuse techniques in Active Directory environments, and one of the most persistently effective. Despite being well-documented for over two decades, it remains a reliable path to domain compromise in a significant percentage of enterprise networks because the underlying conditions that make it work, NTLM authentication being used where it should not be, are difficult to fully eliminate without careful planning.

The mechanics are straightforward. NTLM is a challenge-response authentication protocol: a client proves its identity by responding to a challenge with a hash derived from its password. An attacker who can position themselves between the client and the server can capture that challenge-response exchange and replay it to a different target server, authenticating as the client without ever knowing the actual password. The attacker does not crack the credential; they relay it in real time.

What has changed significantly in recent years is how attackers force authentication in the first place. Coercion techniques such as PetitPotam, PrinterBug, and DFSCoerce allow an attacker with nothing more than a low-privilege domain account to force a Domain Controller to authenticate outbound to an attacker-controlled machine. That forced authentication, relayed to the AD CS HTTP enrollment endpoint or to LDAP with signing disabled, can yield a domain administrator certificate or a shadow credential, enabling full domain compromise in minutes.

This page covers the full coercion-to-relay attack chain, maps each step to Log360's detection rules, and provides the investigation workflow for responding when these rules fire.

NTLM relay and coercion, at a glance

How NTLM relay attacks work

An NTLM relay attack has two phases that must happen in sequence: coercion (forcing a privileged machine to authenticate) and relay (forwarding that authentication to a target service). Neither phase alone is sufficient. Together they produce domain-level compromise in minutes.

Coercion: forcing NTLM authentication from a Domain Controller

The coercion phase exploits RPC interfaces that Windows exposes by default on domain-joined systems. PetitPotam abuses the EFS (Encrypting File System) RPC interface, specifically the EfsRpcOpenFileRaw function, to trigger an outbound NTLM authentication from any Windows host to an arbitrary IP. PrinterBug (also called SpoolSS) abuses the MS-RPRN print spooler RPC interface for the same purpose. DFSCoerce uses the MS-DFSNM (Distributed File System Namespace Management) interface. All three techniques require only a low-privilege domain account to execute and produce the same result: the targeted machine, typically a Domain Controller, authenticates outbound to the attacker's machine using its machine account credentials.

The critical property of machine account credentials in this context is their privilege level. A Domain Controller's machine account (DC$) has significant privileges within the domain, including the ability to request certificates with Client Authentication EKU via PKINIT. When a DC$ NTLM authentication is relayed to the AD CS enrollment endpoint, the CA issues a certificate for DC$, which the attacker then uses to obtain a Kerberos TGT for the DC account, effectively giving them Domain Admin-equivalent access.

Log signals: SMB named pipe access to \pipe\lsarpc, \pipe\efsr, \pipe\spoolss, or \pipe\netdfs from a non-DC machine to a DC (Sysmon Event 18 named pipe connection, or Windows Security Event 5145 for network share access). The PetitPotam detection rule specifically targets the EFS RPC coercion pattern.

Relay: forwarding captured authentication to a target service

Once the attacker's machine receives the NTLM authentication from the coerced DC, they forward it in real time to a target service. The relay must complete before the NTLM authentication session times out, typically within seconds. The three most impactful relay targets are AD CS (covered in the ADCS abuse use case), LDAP with signing disabled (enables adding shadow credentials or granting DCSync rights), and SMB to other domain-joined machines (enables remote command execution as the DC$ account).

The relay is performed by tools from the Impacket suite, primarily ntlmrelayx.py, or by ADCSPwn for AD CS-specific relay. These tools have distinctive process creation signatures that Log360's detection rules identify via Sysmon Event 1 logs. The relay itself is network-level and does not generate standard Windows authentication events on the attacker's machine, making tool-level detection the primary signal for the relay phase.

Log signals: Sysmon Event 1 (process creation) with Impacket, ntlmrelayx, ADCSPwn binary signatures. Network connections from the attacker's machine to the CA HTTP endpoint (port 80 or 443 to the CA server) or to LDAP (port 389/636) in the seconds following the coercion call.

Network-layer coercion: ARP spoofing and DHCP spoofing

Before RPC-based coercion techniques became widespread, attackers used network-layer attacks to intercept NTLM authentication that occurred naturally in the network. ARP spoofing poisons the ARP cache of target machines to redirect traffic through the attacker's host. DHCP spoofing serves a rogue DHCP response that sets the attacker's machine as the default gateway or DNS server. LLMNR and NBT-NS poisoning responds to broadcast name resolution queries with the attacker's IP, causing clients to authenticate to the attacker when attempting to access a non-existent share or host.

These techniques are older and generate more noise than modern RPC coercion, but they remain in use particularly in internal network assessments and in environments where RPC-based coercion is blocked at the host firewall. They are detectable at the network layer via ARP anomaly rules on perimeter devices and via network-based IDS signatures.

Log signals: ARP cache poisoning detected by perimeter devices (Barracuda, SonicWall), duplicate IP address alerts, DHCP lease anomalies, LLMNR/NBT-NS response from unexpected hosts.

Real-world campaigns

Ransomware pre-positioning: NTLM relay to AD CS for rapid domain compromise

Multiple ransomware operators, including Black Basta affiliates and Scattered Spider, have incorporated PetitPotam-to-AD CS relay into their standard pre-ransomware domain compromise workflow. After gaining initial access through phishing or credential stuffing, the group uses PetitPotam to coerce the nearest DC and relays the authentication to the AD CS enrollment endpoint using ADCSPwn or ntlmrelayx. The resulting DC$ certificate is used to perform a DCSync-equivalent credential dump via PKINIT-authenticated LDAP, yielding all domain credentials. From that point, ransomware deployment across the entire domain is typically accomplished within hours.

The operational appeal is speed and stealth: the entire coercion-to-relay-to-certificate chain can complete in under 60 seconds, generates no Event 4625 (failed logon) entries, and requires no prior knowledge of any user's password beyond the initial foothold account.

APT campaigns: LDAP relay for shadow credentials persistence

Several APT groups tracked by Microsoft and CrowdStrike have used NTLM relay to LDAP as a persistence mechanism rather than an initial compromise technique. After gaining domain access by other means, the group uses coercion and LDAP relay to write shadow credentials (the msDS-KeyCredentialLink attribute) to high-value accounts including domain administrators. Shadow credentials allow PKINIT authentication using an attacker-controlled certificate, providing persistent access that survives password resets and remains valid as long as the shadow credential entry persists in Active Directory.

CVE reference table

Business impact

• Domain compromise in under 60 seconds. Modern coercion-to-relay chains, particularly PetitPotam to AD CS, can produce domain administrator-equivalent access in under a minute from a single low-privilege domain account. The speed of the attack leaves almost no time for human-in-the-loop detection and response; automated detection rules that fire at the coercion phase are the only realistic intervention point.
• No password knowledge required. NTLM relay attacks do not require the attacker to know any user's password. They exploit the authentication protocol itself. Password complexity policies, regular password rotation, and even PAM solutions provide no protection against a relay attack. The only effective mitigations are protocol-level controls: SMB signing, LDAP signing, EPA on AD CS, and disabling NTLM where Kerberos is available.
• Enabling downstream attacks. NTLM relay is rarely the end goal. It is the mechanism for obtaining credentials, certificates, or shadow credentials that enable everything that follows: DCSync, Golden Ticket creation, ransomware deployment, and persistent access. Stopping the relay stops the entire downstream chain before any of those consequences materialize.
• Difficulty of post-compromise cleanup. When a coercion-to-relay attack succeeds and shadow credentials or a DC$ certificate are obtained, remediating the compromise requires not just revoking the certificate or removing the shadow credential, but also identifying and closing every persistence mechanism the attacker may have established in the minutes between the relay and detection. Full AD compromise requires full AD remediation, which can take weeks.

Detecting NTLM relay and coercion with Log360

Log360's 10 detection rules for this use case cover both phases of the attack: coercion (the RPC call that forces NTLM authentication from the DC) and relay (the tool-level execution and network-layer techniques used to intercept and forward that authentication). For the Windows-based rules to fire, Sysmon process creation logs (Event 1) and named pipe events (Events 17 and 18) must be forwarding to Log360 from domain-joined endpoints. For the network-layer rules, perimeter device logs from SonicWall, Barracuda, and Cisco must be configured as log sources in Log360.

RPC coercion detection

Relay tool detection

Network-layer relay and interception detection

Attack chain visibility

The detection rules above cover two distinct points in the attack chain: the coercion call (Petitpotam rule) and the relay tool execution (Impacket, ADCSPwn, SMB relay rules). Both firing within a short time window on related hosts is a confirmed active attack. The sequences below show what the log record looks like for the two most operationally significant variants.

Sequence A: PetitPotam to AD CS relay (ESC8)

Sequence B: ARP spoofing to SMB relay

Investigation playbook

NTLM relay investigations are time-critical. The coercion-to-relay chain can complete in under 60 seconds, and a successful relay that produces a DC$ certificate or shadow credential gives the attacker persistent domain-level access that survives the termination of the relay tool itself. By the time the detection rule fires, the relay may already be complete. The investigation goal is to determine whether the relay succeeded, what credential or certificate was obtained, and whether persistence has been established.

Step 1: Triage - determine which phase was detected

Step 2: Determine if the relay succeeded

• For AD CS relay: query the CA audit log for Event 4887 (certificate issuance) in the 5 minutes following the coercion event. Look specifically for certificates issued for machine accounts (accounts ending in $) with Client Authentication EKU from an HTTP enrollment request originating from an unexpected source IP. This is the definitive indicator of a successful ESC8 relay.
• For LDAP relay: check for changes to the msDS-KeyCredentialLink attribute on any AD object in the same time window. This attribute being written by an unexpected source is the shadow credentials persistence indicator. Query AD object modification events (Event 5136) on domain controllers.
• For SMB relay: check Event 4624 (Type 3, NTLM authentication) on target machines where the source IP is the attacker's relay host rather than the authenticated account's normal workstation.
• For PKINIT usage of a relay-obtained certificate: check Event 4768 (Kerberos TGT request) for certificate-based pre-authentication from an IP that matches the relay tool host. A TGT issued for DC$ from an unexpected IP is confirmation the relay produced a usable credential.

Step 3: Investigate using the Incident Workbench

• Click on the attacker's source IP or the affected DC hostname in the alert to open the Incident Workbench. Use the Process analytics tab on the host where Impacket, ADCSPwn, or SMB relay tools were detected. The process tree shows what spawned the relay tool, what commands followed it, and whether post-relay actions (DCSync, LDAP queries, certificate usage) occurred on that machine.
• Use Advanced Threat Analytics on the attacker's source IP to check threat feed risk scores. IPs used for coercion and relay attacks in production environments are frequently associated with known attack infrastructure or prior incident records.
• If the coercion originated from an internal host (indicating the attacker already has an internal foothold), open the Incident Workbench for the user or machine account associated with that host to understand the prior compromise chain.
• Save the Incident Workbench session to an incident. Preserve the process tree from the relay host and the CA audit log export as the primary evidence record.

Step 4: Assess persistence established

• If a DC$ certificate was issued, treat the certificate as a standing credential for domain-level access until it is explicitly revoked. Check the CA audit log for the certificate serial number and revoke it immediately using certutil -revoke <SerialNumber> followed by a CRL push.
• Query all AD objects for recent msDS-KeyCredentialLink attribute modifications (Event 5136, attribute OID 1.2.840.113556.1.4.2328). Any write to this attribute by a non-standard source is a shadow credential implanted for persistent access.
• Check whether any new user accounts, service accounts, or group memberships were created in the period following the relay, using the relay-obtained credential. DC$ machine account access can be used for AD object manipulation.
• Verify whether the attacker used the relay credential to modify Kerberos delegation settings or trust relationships on any AD objects, which would extend the persistence surface beyond the directly compromised accounts.

Step 5: Collect evidence and build the timeline

• Export the Sysmon Event 1 and Event 18 logs from the DC and the attacker's host covering the attack window. These are the primary forensic records showing the coercion call, the relay tool execution, and any post-relay process activity.
• Export the CA audit log (Events 4886 and 4887) for the investigation period. If a certificate was issued, the serial number, template, requesting identity, and source IP are all recorded here and are required for revocation and for proving scope of compromise.
• Export Kerberos Event 4768 logs from domain controllers for the period following the relay, filtered for certificate-based pre-authentication and for TGT requests from the attacker's IP.
• Export the investigation timeline from Log360 as the compliance artifact for NIST CSF DE.AE-5 (incident analysis) and PCI-DSS Requirement 10.7.

Response and remediation

Immediate containment

• Isolate the relay host from the network. The machine running the relay tool is the attacker's primary operational platform for this attack. Network isolation prevents completion of any in-progress relay and prevents the attacker from using a relay-obtained credential for subsequent access. Isolation should occur within seconds of the relay tool detection rule firing.
• Revoke any certificates issued during the attack window. Check the CA audit log for any certificates issued in the 5 minutes surrounding the coercion event. Revoke all suspicious issuances using certutil -revoke <SerialNumber> and publish an updated CRL immediately.
• Remove any shadow credentials implanted via LDAP relay. Query AD for recent msDS-KeyCredentialLink modifications and remove any attacker-added entries. This requires identifying the specific attribute value added by the relay and removing it from the affected AD object.
• Perform a double krbtgt password reset if domain-level access via a relay-obtained certificate or shadow credential is confirmed. Two resets within the Kerberos ticket lifetime window (typically 10 hours) are required to invalidate all Kerberos tickets issued using the compromised DC$ credential.

Response actions by trigger

Hardening

• Enable SMB signing on all domain-joined machines. SMB signing is the single most effective control against SMB relay attacks. With signing enforced, a relayed authentication cannot be used to establish an SMB session because the attacker cannot produce valid signatures. Configure via Group Policy: Microsoft network server: Digitally sign communications (always) set to Enabled.
• Enable LDAP signing and channel binding on all domain controllers. LDAP signing prevents NTLM relay to LDAP by requiring the authentication to be cryptographically bound to the LDAP session. Configure via Group Policy: Domain controller: LDAP server signing requirements set to Require signing.
• Enable Extended Protection for Authentication (EPA) on the AD CS HTTP enrollment endpoint. EPA binds NTLM authentication to the TLS channel, preventing relay to the certsrv endpoint. This directly closes the ESC8 attack path. Configure in IIS on the CA server by enabling Windows Authentication with Extended Protection set to Required.
• Disable the Print Spooler service on Domain Controllers. The Print Spooler service is the enabler of PrinterBug coercion. Domain Controllers do not need the Print Spooler service for their function, and disabling it eliminates one coercion vector entirely. Configure via Group Policy or directly via sc config spooler start=disabled on each DC.
• Block NTLM authentication to Domain Controllers via Conditional Access policies. Where Kerberos is available (which it should be for all internal domain resources), NTLM authentication to DCs can be blocked via the Group Policy setting: Network security: Restrict NTLM: NTLM authentication in this domain set to Deny all.

False positive tuning