How can security teams detect PetitPotam attacks?

What PetitPotam Detection Actually Looks Like on a Live Network

PetitPotam is rarely a single event in logs. The useful signal is a short chain: a Windows host is induced to authenticate outward, usually after name-resolution or printer-related activity, and that authentication lands on an unexpected listener. Detection improves when teams treat it as a coercion-to-relay pattern rather than as one isolated packet or one failed login.

That means the first question is not “did we see the exploit name,” but “did an internal system begin an authentication flow that it should never have started on its own?” If the answer is yes, the surrounding host, destination, and timing become the evidence that matters.

Teams should correlate the coercion trigger with the follow-on behaviour. The most practical indicators are abnormal outbound authentication attempts, relay-like traffic immediately after the trigger, and later misuse of whatever was obtained through the relay path, especially certificate or account abuse. A single weak signal is often ambiguous; the pattern across name resolution, coercion, and downstream authentication is what raises confidence.

Where Teams Should Look First in Detection and Telemetry

The highest-value telemetry is whatever shows the coercion path before the authentication leaves the box. That includes DNS, LLMNR or other name-resolution oddities, printer-related activity, EFSRPC-style activity, and any event sequence where a workstation or server suddenly tries to authenticate to a listener that was not part of normal business flow. If you already monitor Windows lateral-movement primitives, Lateral Movement Guide is the most direct operational companion because PetitPotam often appears as a relay-enabling movement pattern rather than a standalone exploit.

From an investigation standpoint, tie the initial coercion to the outbound destination and then ask whether the destination was acting as a relay endpoint, sinkhole, or attacker-controlled service. The downstream question is whether the coerced authentication was accepted, forwarded, or converted into access somewhere else. That is why host telemetry alone is usually insufficient.

Responder workflows also benefit from identity-aware correlation. If the coerced authentication led to a certificate enrollment, account misuse, or session creation, the incident has moved beyond simple probing. For that reason, Identity Threat Detection and Response (ITDR) Guide helps frame the post-coercion checks: what identities were touched, what access was issued, and what persistence or abuse followed.

How to Reduce Exposure and Prove the Attack Path

PetitPotam detection becomes much easier when the exposed paths are reduced in advance. Restrict the unnecessary exposure of the vulnerable interfaces, limit NTLM where the environment can tolerate it, and segment systems so that a coerced authentication cannot simply reach a useful relay target. The value is not only prevention, it is also noise reduction, because the smaller the allowed trust surface, the easier anomalous outbound authentication becomes to spot.

When an alert fires, verify whether the path was actually usable for relay. That means checking the destination listener, whether the coercion was successful, and whether any secondary abuse occurred after authentication was captured or relayed. If you are trying to validate whether the activity fits a known attacker pattern, the broader evidence set in The State of NHI & AI Agent Breach Report 2026 is useful mainly as a navigation point for how credential and access abuse tends to chain after initial compromise.

Practitioners should also preserve the exact timing between the coercion trigger and the outbound authentication attempt. In many environments, that interval is the cleanest way to distinguish a real attack path from unrelated printer, discovery, or name-resolution noise. If the sequence is repeatable, it is usually actionable.

Risk and Threat Considerations

Pretending PetitPotam is “just an authentication event” is the common failure. The real risk is that coerced authentication can be converted into relayable trust, which then becomes a path to certificate abuse, account abuse, or broader lateral movement. The attacker does not need the initial host to be compromised in the traditional sense if the host can be tricked into authenticating on demand.

Failure mechanism: The adversary induces a Windows system to authenticate to an attacker-controlled listener, then reuses or relays that authentication before defenders recognise the sequence as hostile.

Impact: Teams may miss the true point of compromise, misclassify the event as a benign connectivity issue, and allow follow-on abuse of certificates, accounts, or adjacent services.

Practitioner Guidance

What to verify: Confirm the coercion source, the destination listener, and the immediate follow-on authentication flow before closing the alert. If those three elements line up, treat it as a relay-preparation event even if the business impact is not yet visible.

What to prioritise: Focus first on systems that can coerce outbound authentication at scale or sit on trust boundaries, because those are the best leverage points for both detection and containment. A small number of exposed paths often explains a large share of meaningful exposure.

Practitioner takeaway: The key judgement is to investigate PetitPotam as a chained abuse path, not as a single exploit, because the detection value lies in connecting coercion, outbound authentication, and any later certificate or account misuse.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?