NTLM coercion attacks have become a reliable Active Directory attack path precisely because they exploit legitimate Windows authentication behaviour. The pattern: force a machine account to authenticate to an attacker-controlled host via a coercion technique (PetitPotam, DFSCoerce, PrinterBug), capture the Net-NTLM hash, and relay it somewhere useful — typically to LDAP for RBCD configuration, or to AD CS for certificate-based privilege escalation.

The March 2026 Metasploit update explicitly expanded SMB NTLM relay server capabilities, lowering the barrier for attackers. Detection teams need reliable coverage across the coercion and relay phases.

The Attack Chain

Phase 1 — Coercion: The attacker calls a Windows RPC method that triggers the victim machine to authenticate outbound. Common coercion techniques:

  • PetitPotam (MS-EFSR / EFS API): Calls EfsRpcOpenFileRaw or related methods to force NTLM authentication. Patched in CVE-2021-36942 but still effective against unpatched systems; patch bypass variants remain.
  • DFSCoerce (MS-DFSNM): Uses the Distributed File System Namespace Management protocol to trigger authentication.
  • PrinterBug / SpoolSS (MS-RPRN): Exploits RpcRemoteFindFirstPrinterChangeNotification in the Print Spooler service to coerce authentication.

Phase 2 — Relay: The captured authentication is relayed to a target, typically:

  • LDAP/LDAPS for Kerberos Resource-Based Constrained Delegation (RBCD) setup
  • AD CS HTTP enrollment endpoints for shadow credentials / certificate theft
  • SMB shares for file access or command execution

Detection: Coercion Tools

The most reliable detection is catching the tooling itself. Impacket’s ntlmrelayx.py, DFSCoerce, and PetitPotam have characteristic process creation signatures when run on the attacker host, but from the victim’s perspective you’re looking for unusual outbound authentication.

Sigma rule — PetitPotam MS-EFSR coercion via named pipe:

title: PetitPotam NTLM Coercion via MS-EFSR Named Pipe
id: a8a1f2c3-b4d5-6e7f-8901-234567890abc
status: test
description: Detects network connections to the EFSRPC named pipe associated with PetitPotam coercion
author: SOC Analyst Hub
date: 2026-05-29
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5145
    ShareName: '\\*\IPC$'
    RelativeTargetName|contains:
      - 'efsrpc'
      - 'lsarpc'
      - 'samr'
      - 'netlogon'
  filter_legit:
    SubjectUserName|endswith: '$'
    IpAddress: '127.0.0.1'
  condition: selection and not filter_legit
falsepositives:
  - Legitimate EFS operations
  - Administrative tooling accessing named pipes
level: medium
tags:
  - attack.credential_access
  - attack.t1187

Sigma rule — DFSCoerce MS-DFSNM coercion attempt:

title: DFSCoerce NTLM Coercion via MS-DFSNM Protocol
id: b9c2d3e4-f5a6-7b8c-9012-345678901bcd
status: test
description: Detects authentication coercion via the DFS Namespace Management protocol
author: SOC Analyst Hub
date: 2026-05-29
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5145
    ShareName: '\\*\IPC$'
    RelativeTargetName: 'netdfs'
    Accesses|contains: 'ReadData'
  filter_own:
    IpAddress: '127.0.0.1'
  condition: selection and not filter_own
falsepositives:
  - Legitimate DFS replication activity in environments using DFS Namespaces
level: medium
tags:
  - attack.credential_access
  - attack.lateral_movement
  - attack.t1187

Detection: Machine Account Authentication Anomalies

When coercion succeeds, the victim machine’s computer account (e.g., DC01$) authenticates outbound to the attacker’s host. This produces Event ID 4648 (explicit credential logon) or network logon events that deviate from baseline.

KQL — Azure Sentinel / Microsoft Sentinel: machine account authenticating to unusual hosts:

SecurityEvent
| where EventID == 4648
| where SubjectUserName endswith "$"
| where TargetServerName != ""
| where TargetServerName !endswith ".yourdomain.local"
| where TargetServerName !in ("dc01.yourdomain.local", "dc02.yourdomain.local")
| summarize
    AuthCount = count(),
    Targets = make_set(TargetServerName),
    SourceHosts = make_set(Computer)
    by SubjectUserName, bin(TimeGenerated, 15m)
| where AuthCount > 2
| project TimeGenerated, SubjectUserName, AuthCount, Targets, SourceHosts

Detection: NTLM Relay via ntlmrelayx

When the relay is to LDAP for RBCD configuration, look for msDS-AllowedToActOnBehalfOfOtherIdentity attribute changes on computer objects — this is the signature of a successful RBCD attack.

Sigma rule — RBCD attribute modification (LDAP relay success indicator):

title: RBCD Delegation Attribute Modified  --  Possible NTLM Relay Success
id: c1d4e5f6-a7b8-9c0d-1234-56789012cdef
status: experimental
description: |
  Detects modification of msDS-AllowedToActOnBehalfOfOtherIdentity on a computer object,
  which is the outcome of a successful NTLM relay to LDAP for RBCD configuration
author: SOC Analyst Hub
date: 2026-05-29
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5136
    AttributeLDAPDisplayName: 'msDS-AllowedToActOnBehalfOfOtherIdentity'
    OperationType: '%%14674'  # Value Added
  condition: selection
falsepositives:
  - Legitimate delegation configuration by administrators
  - Automated provisioning tooling
level: high
tags:
  - attack.privilege_escalation
  - attack.t1558
  - attack.lateral_movement

Detection: AD CS Relay

Relay to AD CS HTTP enrollment is harder to detect from the victim side, but the attacker’s machine certificate request against a non-standard CA enrollment endpoint is visible in Certificate Services logs.

Sigma rule — AD CS HTTP enrollment by machine account:

title: Suspicious Machine Account Certificate Enrollment via AD CS HTTP
id: d2e5f6a7-b8c9-0d1e-2345-67890123defg
status: test
description: |
  Detects certificate enrollment requests via HTTP/HTTPS to AD CS where the requester
  is a machine account  --  possible indicator of NTLM relay to AD CS for shadow credentials
author: SOC Analyst Hub
date: 2026-05-29
logsource:
  product: windows
  service: security
  definition: 'Requires Certificate Services audit logging (Event ID 4886/4887)'
detection:
  selection:
    EventID:
      - 4886
      - 4887
    RequesterName|endswith: '$'
  filter_auto_enroll:
    CertificateTemplateName|contains:
      - 'Machine'
      - 'Computer'
      - 'DomainController'
  condition: selection and not filter_auto_enroll
falsepositives:
  - Legitimate machine certificate enrollment for custom templates
level: high
tags:
  - attack.credential_access
  - attack.t1649

Hardening Recommendations

Detection is secondary to reducing the attack surface. The key mitigations:

Disable coercion where possible: If your environment does not require EFS, disable it via GPO. Disable the Print Spooler service on domain controllers — this eliminates PrinterBug entirely on your most sensitive assets.

Enable LDAP signing and channel binding: Required LDAP signing prevents NTLM relay to LDAP even if coercion succeeds. Configure via Group Policy: Network security: LDAP client signing requirements → Require signing. Complementary: Domain controller: LDAP server channel binding token requirements → Always.

Enable EPA on AD CS: Extended Protection for Authentication on the Certificate Enrollment Web Service prevents NTLM relay to AD CS HTTP endpoints.

Enable SMB signing: Required SMB signing prevents relay to SMB file shares. Default since Windows Server 2022 and Windows 11 24H2.

The coercion techniques themselves are old. The reason they persist is that LDAP signing and channel binding remain optional in most default environments — a gap that costs nothing to close and eliminates a large fraction of NTLM relay opportunity.