What Is PetitPotam?
PetitPotam is a publicly discussed security research tool associated with a Windows authentication behaviour known as authentication coercion. In defensive terms, it is best understood as a reference point for a particular risk in Active Directory environments: under certain conditions, a Windows system can be made to initiate NTLM authentication toward another host, and if that authentication reaches a service without adequate relay protection, it can be abused. Security teams study this behaviour to understand, detect, and close that risk.
The name is most often mentioned alongside CVE-2021-36942, a Windows issue connected to an unauthenticated path in the Encrypting File System Remote Protocol, or EFSRPC. That vulnerability identifier gives defenders a concrete patching reference, but the broader lesson goes beyond one fix: authentication relay risk depends on the whole chain of services, settings, and network paths in an environment, not on a single flaw.
Understanding the Risk Chain
The risk is easiest to grasp as a chain of stages. First, a Windows service receives an EFSRPC-related request. Next, the system may initiate NTLM authentication toward another host as part of how that service behaves. The risk then depends on the destination: if a reachable service accepts NTLM without effective relay protection, the authentication can potentially be relayed and misused. Each stage is a place where defensive controls can break the chain.
Two parts of this chain deserve emphasis. Coercion and relay are not the same thing: coercion describes making a system initiate authentication, while relay describes what happens if another service mishandles that authentication. Defenders therefore need to harden both ends, not just one. Domain controllers also matter more than ordinary workstations here, because they hold highly trusted machine identities, so unexpected outbound authentication involving a domain controller carries greater weight.
Why Active Directory Certificate Services Matter
Active Directory Certificate Services, often shortened to AD CS, appears frequently in PetitPotam discussions because certificate enrollment services can be a high-impact relay target. When enrollment endpoints accept NTLM without protections such as Extended Protection for Authentication, they become a place where relayed authentication could have serious consequences, including certificate issuance.
This is why hardening guidance for AD CS focuses on several layers at once: enabling Extended Protection for Authentication, requiring HTTPS, reviewing permissions and certificate templates, and enabling signing protections where supported. No single setting covers every case, and changes should be tested against representative enrollment flows so legitimate clients keep working.
Defensive Controls That Reduce the Risk
Patching is the first layer. Keeping domain controllers and identity servers current closes the known unauthenticated path, but patching alone does not cover every relay condition. Broader NTLM hardening matters just as much: auditing where NTLM is still used, identifying legacy dependencies, protecting services that must accept NTLM, and planning a staged reduction of NTLM use where feasible.
Network segmentation is another powerful control. Removing unnecessary reachability between ordinary systems and sensitive identity services shrinks the set of paths an attacker could use. Signing requirements on compatible services add a further barrier, since relayed authentication that cannot satisfy integrity requirements is rejected. Together with Extended Protection for Authentication, these controls make relay attacks substantially harder even when coercion remains theoretically possible.
Detection: What Defenders Can Monitor
Detection starts with knowing what normal looks like. Useful signals include domain controller authentication logs, endpoint telemetry, network connection data, and AD CS enrollment or issuance logs. The most valuable alerts correlate unusual machine authentication with high-value destinations: for example, a domain controller initiating authentication toward a system it would not normally contact, followed by certificate activity.
Good detection also needs context. Alerts improve dramatically when they include the asset’s role, the identity type involved, the expected management source, the destination service, and any certificate context. Without that context, authentication alerts tend to be noisy and easy to ignore, which defeats their purpose.
Safe Handling and Lab Practice
Any hands-on review of this topic belongs in an authorised, isolated environment, never on production systems. That means written authorisation for the systems in scope, isolated virtual machines or disposable lab systems, snapshots and a rollback plan, and logging enabled before any validation begins. Production credentials, routes, and sensitive data should be kept out of the lab entirely.
The objective of lab work should be defensive measurement: do the updates, relay protections, segmentation rules, and detections behave as designed? Uncontrolled testing against live infrastructure risks disrupting services, triggering incident response, and creating legal and operational problems. When in doubt, prefer vendor guidance and administrative configuration checks over running proof-of-concept code.
Who Is It For?
The material is most useful to Windows administrators, Active Directory engineers, vulnerability managers, detection engineers, and security architects. Vulnerability teams use it to connect patch status with identity-service hardening and track exceptions to closure. Detection engineers use it to build better correlation rules. Architects use it to review NTLM dependencies, certificate enrollment design, segmentation, and trust boundaries. In every case, the value lies in risk reduction, not in the tool itself.
Frequently Asked Questions
Is PetitPotam the same as an NTLM relay tool?
No. It is associated with triggering authentication behaviour, while relay is a separate stage that depends on another service accepting and mishandling NTLM authentication.
Does patching alone remove the risk?
No. Patching is essential, but defenders should also review NTLM usage, service protections, AD CS configuration, signing, segmentation, and monitoring.
Can a single failed test prove an environment is safe?
No. One failed attempt does not prove comprehensive protection, and configuration and control validation should be performed through approved administrative checks.
Conclusion
PetitPotam is best treated as a teaching reference for defenders: a concrete example of how authentication coercion and NTLM relay risk connect in Windows domains, and why defence must span patching, service hardening, segmentation, and detection. Teams that understand the full chain can prioritise the controls that matter most for their environment. For further defensive background, the reference site at petitpotam.com collects the vulnerability context, hardening guidance, and detection planning in one place.
