PetitPotam Attack

Most Active Directory attacks require credentials, which means the attacker has to steal something first, and that theft is the hard part that gets them caught. PetitPotam belongs to a different category entirely, because it requires no credentials at all, and it works by making a Windows machine authenticate on the attacker's behalf, which means the victim's own server hands over the authentication the attacker needed.

That single idea, which is called authentication coercion, is not new, and what made PetitPotam notable was how reliably it worked against domain controllers and how little it required, which is why it became one of the most discussed techniques in Windows environments when it appeared.

So here is how it actually works, why the relay is where the real damage happens, the actual tools involved, and the telemetry that catches it.

Important Disclaimer

This article is intended for educational and defensive purposes only, and it describes published attack techniques and the corresponding defensive telemetry so that defenders can build detections and harden their environments. It is not a penetration testing guide and it should not be used against systems you do not own or have explicit written authorisation to test, because unauthorised access is a criminal offence in most jurisdictions. 

The commands described are for detection and validation in your own lab. The author assumes no liability for missed detections, business outcomes, or damages resulting from the use or misuse of this information.

The Core Idea: Make the Victim Do the Talking

Authentication protocols exist so that a client can prove its identity to a server, and PetitPotam inverts that relationship, because it makes the victim server act as the client and authenticate to a destination the attacker controls.

The mechanism is a Windows API that accepts a file path as a parameter, which means an attacker can pass a UNC path pointing at their own machine, and Windows will dutifully attempt to open that path, which requires authentication, which means the victim connects out and proves its identity to the attacker.

The critical detail is what identity it proves, because a machine authenticating to a remote resource uses its computer account, which in Active Directory is a real principal with a password and group memberships, and a domain controller's computer account is a very powerful thing to hold.

The Protocol Behind It: EFSRPC

The specific interface abused is the Encrypting File System Remote Protocol, which exposes remote procedure calls for managing encrypted files, and it exists because EFS needs to support remote operations in enterprise environments.

The call that matters is EfsRpcOpenFileRaw, which takes a filename and attempts to open it, and because the filename can be a UNC path, the function will trigger an SMB connection to whatever host the attacker specifies. Other calls in the same interface have been used for the same purpose, which is why patching one function rarely ends the technique.

The reason this is so useful to an attacker is that the interface is reachable over a named pipe, and access to that pipe has historically not required authentication in the configurations that made the attack work, which is exactly the property that makes coercion unauthenticated.

Where the Real Damage Happens: The Relay

Coercion on its own gets an attacker a machine authentication, and a machine authentication is only useful if it can be used for something, and that something is NTLM relay.

The relay works because NTLM authentication is a challenge-response protocol where the attacker sits in the middle, and instead of answering the challenge themselves, they forward it to a different server and let that server validate the victim's response. If the victim's authentication succeeds against the target, the attacker now has an authenticated session to that target without ever knowing a password.

PetitPotam provides the authentication, and the relay provides the access, and the combination is what turns a single outbound SMB connection into a serious incident.

The AD CS Path: Why This Became Domain Takeover

Relaying to a file server gets an attacker file access, which is useful but bounded, and relaying to Active Directory Certificate Services gets something far more valuable, because certificate services issue credentials rather than grant access.

The specific weakness is ESC8, which is the condition where an AD CS server exposes the HTTP enrollment endpoint and accepts NTLM authentication on it, and when both are true, a relayed machine authentication can be used to request a certificate.

A domain controller's computer account is authorized to request a certificate that permits client authentication, and once the attacker holds that certificate, they can use it to request a Kerberos ticket-granting ticket for the domain controller, which is the whole game, because a domain controller's TGT permits replication, and replication permits extraction of every password hash in the domain including krbtgt.

That's the full chain in one sentence, which is coerce the DC, relay to the certificate authority, get a certificate, get a ticket, replicate the domain.

The Actual Tools

The tooling is well documented because the technique was published openly, and knowing what it looks like on the wire matters more than knowing how to run it.

PetitPotam itself is a small executable that calls the EFSRPC interface against a target and points it at a listener address, and its output is short, which means the detection value is in the network and authentication logs rather than in the binary.

ntlmrelayx.py from Impacket is the relay, and it listens for incoming authentication and forwards it to a target, and its common invocation for this attack accepts a target of the certificate authority's enrollment endpoint and a template to request.

Certipy is the post-relay tool, and it takes the certificate and requests a TGT, and then uses that ticket for replication, which is why the detection opportunity extends beyond the coercion itself.

What the Logs Actually Show

The good news is that this chain is unusually visible if the right logging is enabled, because each stage leaves a distinct artefact.

The coercion shows up as an outbound connection and a named pipe access. On the coerced machine, Event ID 5145 records detailed file share access and will show the efsrpc pipe being accessed, and the source address in that event is the attacker's machine rather than a legitimate peer.

# On the coerced server, look for EFSRPC pipe access
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5145} |
  Where-Object { $_.Message -match 'efsrpc' } |
  Select-Object TimeCreated, @{n='Subject';e={$_.Properties[1].Value}},
                @{n='Source';e={$_.Properties[8].Value}},
                @{n='Share';e={$_.Properties[9].Value}}

The relay shows up as an anonymous or machine logon. On the certificate authority, Event ID 4624 with Logon Type 3 and the NTLM authentication package, where the account is the domain controller's machine account, is the signature of a relayed authentication, because a domain controller does not normally log on to a certificate authority that way.

# On the CA, look for machine-account NTLM network logons
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
  Where-Object {
    $_.Properties[8].Value -eq 3 -and
    $_.Properties[10].Value -match 'NTLM' -and
    $_.Properties[5].Value -match '\$$'
  } |
  Select-Object TimeCreated, @{n='Account';e={$_.Properties[5].Value}},
                @{n='Source';e={$_.Properties[18].Value}}

The certificate request shows up in AD CS logging. If certificate services auditing is enabled, Event ID 4886 records a certificate request received and Event ID 4887 records a certificate issued, and a request from a domain controller's machine account against a client-authentication template is exactly what the ESC8 path produces.

The ticket request shows up in Kerberos logs. Event ID 4768 records a TGT request, and a TGT request using a certificate for a machine account that does not normally authenticate that way is a strong signal, especially if the source address is not the machine itself.

And the replication shows up in directory service logs. If the attacker proceeds to DCSync, Event ID 4662 on the domain controller records directory service access with the replication GUIDs, which is the last chance to catch the chain before the domain is fully compromised.

What Actually Fixes It

Patching closes specific functions and does not close the class, so the durable fixes address the conditions that make the chain work.

• Disable NTLM where you can, and enforce Extended Protection where you cannot. EPA with channel binding on the certificate authority's endpoints means a relayed authentication cannot be reused, because the binding ties the authentication to the original TLS channel, and that single control breaks the middle of the chain.
• Require HTTPS on certificate enrollment and disable the HTTP endpoint. If the endpoint isn't reachable over plain HTTP, the relay target disappears, which removes the most valuable destination for coerced authentication.
• Enable SMB signing and LDAP signing with channel binding. These prevent relay to file shares and directory services, which closes the less dramatic but still useful relay paths.
• Reduce coercion surface where practical, and monitor the rest. Blocking outbound SMB from servers that have no business making SMB connections removes many coercion opportunities, and for the machines that must keep it, detect the pattern instead.
• Audit your AD CS templates. Any template that permits client authentication and is enrollable by machine accounts is a potential ESC8 target, and the fix is to restrict enrollment to the accounts that genuinely need it rather than to everyone.

Real Two Scenarios

Scenario 1: The Coercion That Found an Open Endpoint

The Setup

A company has an internal certificate authority with the HTTP enrollment endpoint enabled, because it was set up that way years ago and nobody questioned it, and NTLM is accepted on that endpoint because disabling it would break a legacy application.

What Happened

An attacker with a foothold on a single workstation runs PetitPotam against a domain controller, pointing the coercion at their own machine, and relays the incoming machine authentication to the certificate authority's HTTP endpoint, which issues a certificate for the domain controller's computer account.

The Result

The attacker uses the certificate to request a TGT for the domain controller, performs a DCSync, and extracts every hash in the domain, and the investigation finds the entire chain in the logs, including the 5145 pipe access, the 4624 machine logon on the CA, and the 4887 issuance.

The Lesson

The coercion was possible because the protocol allows it, and the takeover was possible because the CA accepted relayed NTLM on an HTTP endpoint, which means the fix was in the CA configuration rather than in the coercion technique itself.

Scenario 2: The Chain That Broke at the Middle

The Setup

Another company reads the same research and takes two actions, which are enabling Extended Protection for Authentication with channel binding on the certificate authority and disabling the HTTP enrollment endpoint in favour of HTTPS only.

What Happened

The same attacker runs the same coercion, and the domain controller does authenticate to the attacker's machine, so the first stage succeeds, and the relay to the CA fails because the authentication cannot be bound to a new TLS channel.

The Result

The attacker gets one machine authentication that is unusable against the valuable target, the 4624 and 5145 events are logged, and the SOC detects and investigates an anomaly that never became an incident.

The Lesson

The coercion could not be prevented without breaking legitimate functionality, and the relay could be prevented easily, which is why the defensive priority is breaking the chain rather than eliminating every possible trigger.

How to Spot PetitPotam Activity

• A server making outbound SMB connections it has never made before. Coercion requires the victim to reach out, so a new outbound connection from a domain controller is a strong signal.
• EFSRPC pipe access in Event ID 5145. The efsrpc named pipe being accessed from an unexpected source is the clearest single artefact of coercion.
• Machine-account NTLM logons on a certificate authority. A domain controller logging on to the CA over NTLM with Logon Type 3 is not normal behaviour.
• Certificate issuance for a machine account against a client-authentication template. Event ID 4887 from an unexpected account is the moment the chain succeeds.
• TGT requests using certificate-based authentication for machine accounts. Event ID 4768 with certificate pre-authentication for a computer account deserves investigation.
• Directory replication from a non-DC source. Event ID 4662 with replication GUIDs from an unusual account means DCSync is in progress.
• Anonymous logon attempts against EFSRPC. A spike in anonymous NTLM attempts against the pipe on multiple servers suggests scanning or attempted coercion.

Quick Reference: The Chain and the Countermeasure

The Bottom Line

PetitPotam is not a bug in the traditional sense, it's an abuse of a protocol feature that makes a server authenticate on request, and the reason it matters is that authentication is the one thing an attacker normally has to steal, which means coercion removes the hardest step in the intrusion.

The damage, however, happens at the relay, and the relay succeeds because certificate authorities accept NTLM on HTTP endpoints and because NTLM has no channel binding by default, which means the durable fix is not to patch a function but to break the middle of the chain with Extended Protection, HTTPS-only enrollment, and signing on the services that can be relayed to.

So check your certificate authority this week, specifically whether the HTTP endpoint is enabled and whether EPA is enforced, because that single configuration decision is the difference between a coerced authentication being a logged anomaly and being a domain takeover.

FAQ

What is the PetitPotam attack in simple terms?

It is a technique that makes a Windows machine, including a domain controller, authenticate to a server the attacker controls, which gives the attacker that machine's authentication without needing to steal any credentials.

Does PetitPotam require credentials?

No, the coercion itself is unauthenticate, which is what made it notable, because the attacker only needs network reachability to the target's EFSRPC interface and a listener to receive the authentication.

Why is relaying necessary for the attack to work?

Because coercion only produces an authentication, and an authentication has to be used against something, so the attacker forwards it to a target that will accept it, which is how a machine authentication becomes access to a certificate authority or a file server.

What is ESC8 and why does it matter here?

ESC8 is the condition where a certificate authority exposes an HTTP enrollment endpoint that accepts NTLM, and it matters because it is the relay target that turns a coerced machine authentication into a certificate, and a certificate into domain replication.

What logs show PetitPotam activity?

Event ID 5145 shows EFSRPC pipe access on the coerced machine, 4624 Type 3 with NTLM on the relay target, 4886 and 4887 on the certificate authority, 4768 for the TGT request, and 4662 with replication GUIDs if DCSync proceeds.

Does patching fix PetitPotam?

Patching closes specific functions and does not close the class, because other calls in the same interface and other coercion techniques exist, which is why the durable fix is breaking the relay with Extended Protection and HTTPS-only enrollment.

What is the single most effective mitigation?

Enforcing Extended Protection for Authentication with channel binding on your certificate authority endpoints, because it makes a relayed authentication unusable even when the coercion succeeds.

Can I disable NTLM entirely?

In many environments yes, and it is the cleanest fix, but where legacy applications depend on it, the practical approach is to disable it on the high-value targets first, which means domain controllers and certificate authorities, and enforce EPA everywhere else.