← All posts

PetitPotam and NTLM Coercion: Stopping the RPC Attacks That Force Authentication

How PetitPotam, PrinterBug, and other NTLM coercion attacks force Windows machines to authenticate to an attacker, and how to detect and shut them down.

Most credential-relay defenses assume the attacker has to wait for a victim to authenticate. Coercion attacks throw that assumption out. Instead of phishing a user or poisoning name resolution, the attacker reaches into a Windows machine over RPC and orders it to authenticate — to any host the attacker chooses. The victim is not a person; it's the machine account of a domain controller, file server, or workstation, and machine accounts are often exactly the identities that unlock Active Directory.

How coercion works

Windows exposes several RPC interfaces whose legitimate purpose involves reaching out to a remote path. An attacker with even an unprivileged domain foothold — or in some cases none at all — can invoke a method and supply a UNC path pointing at their own machine. Windows dutifully connects and authenticates with the calling computer's account. The best-known examples:

Why it's dangerous: coercion + relay

Coercion by itself just produces an authentication attempt. It becomes catastrophic when chained to an NTLM relay. The attacker coerces a domain controller into authenticating, then relays that NTLM authentication to a service that does not enforce signing — classically AD CS web enrollment (HTTP). The result is a certificate issued for the domain controller's identity, which the attacker uses to request a Kerberos TGT and impersonate the DC. That is a direct path to domain compromise, and it needs no cracked password.

The attack primitive is "force a privileged machine to talk to me." The impact primitive is "relay that conversation to something that trusts it." Break either link and the chain fails.

Detecting coercion attempts

Coercion is noisy if you know where to look. On the coerced host, an inbound RPC call over the named pipes \pipe\efsrpc, \pipe\lsarpc, \pipe\spoolss, or \pipe\netdfs immediately followed by an outbound SMB authentication to an unexpected host is the tell. Useful signals:

Shutting it down

There is no single patch that kills all coercion, so defense is layered:

  1. Disable the Print Spooler everywhere it isn't needed — mandatory on domain controllers. This closes PrinterBug.
  2. Enforce SMB signing on all hosts and LDAP signing + channel binding on DCs. Signing breaks the relay leg even if coercion succeeds.
  3. Harden AD CS: require HTTPS with Extended Protection for Authentication (EPA) on enrollment web services, or disable web enrollment entirely. This removes the most valuable relay target.
  4. Filter RPC: use RestrictRemoteClients / the RPC Filter feature to block anonymous EFSRPC, and restrict inbound SMB (445) between endpoints with host firewall rules.
  5. Reduce NTLM: every NTLM authentication you eliminate is one fewer thing to relay. See our companion post on retiring NTLM.

Where WinSentinel fits

Coercion resistance is really a bundle of configuration facts spread across services, protocols, and CA settings — exactly the kind of thing that quietly drifts. WinSentinel audits the ingredients directly on each machine: whether the Print Spooler is running where it shouldn't be, whether SMB signing is required, the state of NTLM restrictions, and firewall exposure of SMB/RPC. All 33 modules run in full on a single machine for free, with no limits — so any admin can validate a lone server without a license.

For organizations running fleets, WinSentinel Pro adds central orchestration: the node manages agents across every endpoint, rolls the coercion-relevant findings up into a single posture view, and raises drift alerts when a DC's spooler is re-enabled or a file server's signing requirement is weakened months after you hardened it. That closes the gap between "we fixed it once" and "it stays fixed across a hundred machines."

Coercion attacks are a reminder that authentication you didn't initiate is still authentication an attacker can weaponize. You cannot stop a machine from being asked to authenticate — but you can make sure the answer is worthless to whoever's listening.