Authentication Coercion Defence: Harden, detect and contain PetitPotam style forced authentication

Authentication coercion turns a normal Windows server, often a domain controller, into an unwilling participant that authenticates with its own computer account to a machine the attacker chooses. On its own that is a leak of a credential exchange; chained with NTLM relay to Active Directory Certificate Services or LDAP, publicly reported techniques such as PetitPotam and PrinterBug have turned it into a short path to domain compromise. This guide covers the coercion side at concept level: which remote procedure call (RPC) interfaces are abused, how to harden the Print Spooler, the Encrypting File System Remote Protocol (EFSRPC) and Distributed File System namespace management, how RPC filters and outbound controls limit what is left, and how to detect attempts. It is written for Active Directory, Windows server and detection engineers. The relay side (SMB signing, LDAP signing and channel binding, Extended Protection for Authentication) is covered in the NTLM Relay Guide. This page contains no attack tooling or procedures.

Key takeaways

• Coercion is a primitive, not a single bug. Several RPC interfaces can be asked to "connect back" to a supplied path. Patching one named technique leaves the others, so defend the pattern.
• Domain controllers and Tier 0 servers matter most. Their computer accounts carry the most authority, so coercion of a DC is the scenario every control should be tested against.
• Turn off what is not needed. Microsoft recommends disabling the Print Spooler on domain controllers and Active Directory admin systems; the same reasoning applies to other services that expose coercible interfaces.
• Break the chain at the destination too. Restricting outbound NTLM from Tier 0, blocking outbound SMB and WebDAV, and enforcing relay protections on AD CS and LDAP make any remaining coercion far less useful.
• Detection is realistic. Coercion produces RPC calls to unusual interfaces and outbound authentication from servers that should never initiate it; both can be alerted on.

How coercion works, at concept level

MITRE ATT&CK catalogues this as T1187 Forced Authentication: getting a system to send authentication material automatically to an adversary-controlled server over SMB or WebDAV. ATT&CK notes abuse of the EfsRpcOpenFileRaw function in MS-EFSRPC as a way to force a remote machine to authenticate and enable NTLM relay, and lists PetitPotam among its examples.

The pattern has three parts, and each is a place to defend:

1. An exposed RPC interface on the target that accepts a request containing a network path, reachable by any authenticated (or, before patches, unauthenticated) caller.
2. The target authenticates outbound with its computer account, by SMB or by HTTP through the WebDAV client, to the supplied path.
3. The authentication is relayed or captured: typically relayed to AD CS web enrolment to obtain a certificate for the computer account, or to LDAP to change directory objects.

Microsoft describes PetitPotam in KB5005413 as a classic NTLM relay attack that can be used against domain controllers or other Windows servers where NTLM relay protections are not yet configured on AD CS. Its Defender for Identity guidance on the Print Spooler explains the PrinterBug case: any authenticated user can connect to a domain controller's spooler and ask it to send change notifications to another system, which exposes the domain controller computer account credential because the spooler runs as SYSTEM.

Coercion primitives and their primary defences

Microsoft's monthly security updates restrict the anonymous and unauthenticated EFSRPC paths; they do not remove the general ability of authenticated callers to reach every coercible interface, which is why the remaining sections matter. Apply updates promptly and follow the Microsoft Security Update Guide.

Hardening the Print Spooler

Microsoft's Defender for Identity security assessment recommends that domain controllers and Active Directory admin systems have the Print Spooler service disabled, preferably through Group Policy, and that the service be disabled on all servers that do not need it.

• Domain controllers: disable the service with a GPO linked to the Domain Controllers OU. Microsoft notes a trade-off: the DC role adds a print pruning thread to the spooler that removes stale print queue objects from AD, so prune stale queues periodically by another means.
• Tier 0 and admin servers: AD CS, synchronisation, federation, PAM and jump servers rarely print. Disable the spooler there too.
• Servers that print: where a print server must run the spooler, keep it in a non Tier 0 tier, and on clients that only print locally use the policy Allow Print Spooler to accept client connections (Administrative Templates, Printers) set to Disabled to stop remote connections.
• Driver installation: keep RestrictDriverInstallationToAdministrators at 1 (the default since the 10 August 2021 updates) and configure Point and Print Restrictions to show warning and elevation prompts, as described in KB5005010. This is spooler hygiene rather than coercion defence, but it is usually handled by the same change.

Defender for Identity surfaces DCs running the spooler as a Secure Score action, which gives you an inventory before the change. See the Printer and Print Spooler Security Guide.

Hardening EFSRPC, DFS and other RPC interfaces

Security updates first

Install Windows security updates on all domain controllers and servers promptly; the EFSRPC fixes ship in the monthly cumulative updates. Track update compliance for Tier 0 separately, because a single unpatched DC keeps the old path open.

RPC filters

Windows supports RPC filters, configured from the netsh rpc filter context. A rule can match on the interface identifier (if_uuid) and on the authentication level (auth_level), with a block or permit action, and filters are persistent by default. Defenders use them to block remote access to EFSRPC and DFS namespace management on domain controllers where those functions are not used remotely. Treat RPC filters as a change to a critical system:

• Confirm dependency first: establish whether anything legitimately uses the interface remotely (for example remote EFS operations on file servers, or DFS namespace administration tools pointed at a DC). Block only where the answer is no.
• Pilot on one DC: apply to a single DC, watch for failures in dependent services for a defined period, then extend to the rest.
• Manage as code: deploy filters through your configuration management, record each filter's interface and purpose, and keep a tested removal script for rollback.
• Prefer permit with authentication conditions over block where an interface is needed by a small set of administrators.

Reduce the surface

• Remove unneeded roles: do not host DFS namespaces, file shares or print queues on DCs unless required. Each role adds coercible interfaces.
• Disable the WebDAV client on servers: the WebClient service lets coerced authentication travel over HTTP, which is relayable to LDAP even where SMB signing is enforced. Servers rarely need it.
• Restrict RPC reachability: host firewall rules on Tier 0 servers should allow RPC endpoint mapper and dynamic RPC only from management and replication sources that need them.

See the AD Domain Controller Hardening Guide for the wider DC baseline.

Breaking the chain: outbound and relay controls

Assume a new coercion path will be found. The controls below limit what any coercion achieves.

Microsoft advises not moving straight to Deny all for outbound NTLM: set Audit all, review the events in Applications and Services Logs, Microsoft, Windows, NTLM, add legitimate servers to Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication, then deny. The setting takes effect without a restart. See the NTLM Relay Guide, the SMB Signing Guide and the AD CS Security Guide.

Choosing controls for your estate

• Small estate, few DCs, no AD CS web enrolment: disable the spooler on DCs, keep updates current, block outbound SMB at the edge and restrict outbound NTLM from DCs. That removes most of the risk with little effort.
• Estate with AD CS web enrolment: treat KB5005413 mitigations as mandatory before anything else, because certificate theft for a DC computer account is the highest impact outcome.
• Large or legacy estate that cannot deny NTLM: rely more heavily on RPC filters, host egress rules on Tier 0 and detection, and run NTLM auditing to shrink exceptions over time.

Where identity fits

The credential at stake is a non-human one: the computer account of a domain controller or server. A certificate issued to that account can be used to request Kerberos tickets as the machine, and a DC computer account can replicate directory secrets (ATT&CK T1003.006 DCSync). Treat Tier 0 computer accounts as privileged identities: monitor certificates issued to them, alert on authentication by them from unexpected hosts, and include them in incident response scope. See the Kerberos PKINIT and Certificate Mapping Guide and the Tiered Administration and Enterprise Access Model Guide.

Detecting coercion attempts

• Identity threat detection alerts: Microsoft Defender for Identity documents alerts including Suspected DFSCoerce attack using Distributed File System Protocol (external ID 2426, mapped to T1187), Suspected exploitation attempt on Windows Print Spooler service (2415) and Suspected NTLM relay attack (Exchange account) (2037). Equivalent products alert on the same RPC patterns.
• Outbound authentication from servers: a DC authenticating by NTLM to a workstation or an unknown host is abnormal. The NTLM operational log (after enabling auditing) and network flow data on TCP 445 and WebDAV from DCs show this.
• Computer account logons from unexpected sources: a DC computer account authenticating to AD CS or LDAP from an IP that is not a DC indicates relay.
• Certificates for computer accounts: review AD CS issuance for certificates requested for DC or Tier 0 computer accounts outside normal auto-enrolment.
• RPC filter audit: Microsoft documents auditing only for filters with the permit action, so use audited permit rules (for example, permit only at a strong authentication level) to see who is still calling the interfaces.

See the Active Directory Security Monitoring and Event IDs Guide for event collection.

Metrics that show the programme is working:

1. Domain controllers and Tier 0 servers with the Print Spooler running (target zero).
2. Tier 0 servers on the current cumulative update.
3. Percentage of DCs with RPC filters or documented exceptions for EFSRPC and DFS namespace management.
4. Number of outbound NTLM exceptions for Tier 0, trending down.
5. AD CS web enrolment endpoints with EPA Required and NTLM disabled (target 100%).
6. Coercion alerts triaged within the agreed response time.

Rolling out the controls

1. Inventory: list DCs, AD CS servers and other Tier 0 hosts, their running services (spooler, WebClient, DFS) and AD CS web endpoints.
2. Quick wins: disable the spooler on DCs and Tier 0 servers, apply KB5005413 mitigations to AD CS web enrolment, confirm current updates.
3. Audit NTLM: enable outbound NTLM auditing on DCs and incoming auditing on AD CS servers; collect for several weeks.
4. Pilot RPC filters: on one DC, then the rest, with a tested rollback.
5. Enforce: move outbound NTLM from Tier 0 to Deny all with exceptions, add host egress rules, disable WebClient on servers.
6. Validate: run an authorised test, by your red team or an assessor, to confirm that coercion of a DC no longer yields a usable relay, and repeat after major changes.

Framework mapping

Common failure patterns

• Treating PetitPotam as patched and closed: the updates closed specific paths; authenticated coercion through other interfaces remains, so the relay destinations must still be protected.
• Disabling the spooler on DCs but not on AD CS or sync servers: any Tier 0 computer account is worth coercing.
• Relying on SMB signing alone: coerced authentication over WebDAV arrives as HTTP and can be relayed to LDAP or AD CS unless those are protected too.
• Deploying RPC filters without a dependency check: a blocked interface used by a management tool causes an outage and the filters get removed for good.
• Exceptions that never shrink: outbound NTLM exception lists created during audit become permanent allow lists.
• No owner for AD CS web enrolment: endpoints installed years ago without EPA remain the relay target. See the AD CS Security Guide.

Practitioner checklist

• Disable the Print Spooler on every domain controller and Tier 0 server through Group Policy.
• Keep DCs and Tier 0 servers on current cumulative updates and report compliance separately.
• Apply KB5005413 mitigations: EPA Required, Require SSL and NTLM disabled on AD CS web enrolment.
• Audit, then deny, outbound NTLM from DCs with a minimal exception list.
• Block outbound SMB (TCP 139 and 445, UDP 137) and WebDAV at the edge and from DCs to non-DC hosts.
• Pilot and deploy RPC filters for EFSRPC and DFS namespace management where they are not used remotely.
• Disable the WebDAV client and unneeded roles on servers.
• Alert on coercion patterns, outbound authentication from DCs and unexpected certificates for computer accounts.
• Validate with an authorised test after changes.

Standards and references

• MITRE ATT&CK: Forced Authentication (T1187)
• Microsoft Learn: netsh rpc
• Microsoft Support: KB5005413 Mitigating NTLM relay attacks on Active Directory Certificate Services
• Microsoft Learn: Security assessment, domain controllers with Print Spooler service available
• Microsoft Learn: Network security, Restrict NTLM, outgoing NTLM traffic to remote servers
• Microsoft Learn: Defender for Identity security alerts
• Microsoft Support: KB5005010 Restricting installation of new printer drivers
• Microsoft Open Specifications: MS-EFSR Encrypting File System Remote Protocol

Related NHI Mgmt Group resources: NTLM Relay Guide · AD CS Security Guide · AD Domain Controller Hardening Guide · Printer and Print Spooler Security Guide · Active Directory Security Checklist