Detect it by watching for unexpected authentication coercion from a target host to an attacker-controlled listener. Indicators include remote calls to coercion-prone services, followed by outbound SMB or NTLM authentication from the coerced system. Correlate this with print, EFS, or other remote service activity, and alert when a server that should not initiate such connections does so.
What makes NTLM coercion visible in telemetry
NTLM coercion is most detectable when you stop thinking about the exploit name and focus on the sequence it creates. A target host is induced to authenticate outward to an unusual listener, so the key signal is not the inbound trigger itself but the coerced outbound authentication, usually SMB or NTLM, from a system that should not have initiated it.
That means the most useful telemetry is relationship based: remote service invocation, followed by a network authentication event, followed by a destination that does not fit the server’s normal role. In practice, that pattern is easier to spot when you baseline which hosts normally talk SMB, which accounts normally authenticate from those hosts, and which management workflows legitimately trigger print, EFS, or similar remote service activity.
Detection also improves when you treat the coercion methods as a family rather than separate one-off signatures. PetitPotam, PrinterBug, and related techniques all try to force an authentication flow across a boundary, so a good hunt looks for unexpected remote procedure activity, then confirms whether the resulting authentication was user-initiated, service-initiated, or clearly out of profile for the asset.
How to build a reliable hunting pattern
The strongest hunts join host and network events instead of relying on a single alert source. Pair service activity, such as print spooler, EFSRPC, or other remote-management calls, with network telemetry that shows the same source immediately generating outbound SMB or NTLM traffic. If the listener is attacker-controlled or the destination is external, that combination becomes much more suspicious than either event alone.
Role context matters. A domain controller, file server, or application server that suddenly initiates authentication to a remote listener should be evaluated differently from an admin workstation running a known management tool. The question is whether the connection is expected for that host, at that time, and under that account. If the answer is no, treat it as a likely coercion path until you can explain it.
Timing and correlation are important because the attack is often brief. A small window between the remote call and the outbound authentication is enough to miss the relationship if your logs are siloed. Lateral Movement Guide is a useful companion when you are building detections around SMB, ntlm relay, and other movement patterns that often sit next to coercion activity.
What to validate before you trust an alert
Not every outbound NTLM event is malicious. Some environments still rely on legacy Windows services, print workflows, or administrative tooling that can create similar noise. The practical test is whether the initiating service, account, and destination align with an approved workflow. If they do not, look for coercion rather than assuming routine service behavior.
Once the pattern looks suspicious, validate whether the server had a path to influence authentication on another system, whether the destination was known, and whether the account involved had a reason to be exposed. Active Directory and Entra ID Hardening Guide helps frame that validation in terms of attack-path reduction, privileged exposure, and the kinds of service relationships attackers try to abuse after coercion succeeds.
If you are investigating a suspected case, preserve the evidence around the remote call, the outbound authentication, and any follow-on activity from the same host. Coercion is often a stepping stone to NTLM relay or credential capture, so the important question is not only whether the event happened, but whether it enabled anything else.
Risk and Threat Considerations
NTLM coercion is dangerous because it turns a trusted server into an authentication source for an attacker-controlled endpoint. That creates an exposure path even when the original host was not obviously compromised, and it can be used to feed relay attacks, capture challenge-response material, or expand access from a high-value system.
Failure mechanism: A coercion-prone remote service is invoked in a way that triggers the target to authenticate outward, allowing the attacker to harvest or relay the resulting NTLM traffic before defenders recognize the unexpected connection pattern.
Impact: The attacker may gain a reusable foothold into adjacent systems, reach services that accept NTLM, or move from detection evasion into broader lateral movement and privilege abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1187 — Forced Authentication | Captures NTLM coercion as forced authentication abuse. |
| T1021.002 — SMB/Windows Admin Shares | SMB is the common outbound channel after coercion and often the follow-on access path. | |
| Recommendation — Map coercion events to forced-authentication techniques and correlate them with relay or lateral-movement telemetry. Hunt for unexpected SMB authentication from servers that should not initiate it. | ||
| NIST CSF 2.0 | DE.AE-01 — Anomalies and events are detected | Detection depends on spotting anomalous authentication flow from an unusual source host. |
| DE.CM-01 — Networks and network services are monitored | Network monitoring is needed to observe the outbound connection created by coercion. | |
| Recommendation — Baseline normal service-initiated authentication and alert on out-of-profile outbound NTLM events. Correlate host events with monitored SMB and NTLM traffic to identify coercion sequences. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Alerting requires analyzing correlated logs from service calls and authentication events. |
| Recommendation — Correlate remote-service and authentication logs to flag coerced outbound connections. | ||
Practitioner Guidance
What to prioritise: Focus first on servers that should never initiate outbound SMB or NTLM as part of normal business flow, especially high-value assets that expose print, file, or directory-related services. Those are the systems where a single unexpected outbound authentication is most actionable.
What to verify: Confirm that your detection logic joins the remote service call, the outbound authentication, and the destination profile. A lone NTLM event is often too noisy, but a sequence that starts with coercion-prone activity and ends with outbound authentication from the wrong host is worth immediate triage.
Decision rule: If the host should not be initiating that connection, treat the event as a potential coercion attempt first and as benign legacy behavior only after you can tie it to an approved administrative or service workflow.
Practitioner takeaway: The most useful detector is not a signature for PetitPotam or PrinterBug by name, it is a correlation rule that proves an unexpected host initiated authentication after a coercion-prone service interaction.