Authentication coercion and NTLM relay: understanding PetitPotam and its relatives to defend against them
Some attacks do not exploit a single flaw but a chain of legitimate behaviours. Authentication coercion is the textbook case: a server is pushed into authenticating to a machine controlled by the attacker, who relays that authentication to another service. When the victim is a domain controller, the whole forest is at stake.
How coercion works
Many Windows RPC protocols include functions that ask the server to access a network path supplied by the caller. If that path points to a machine controlled by the attacker, the server connects to it and authenticates with its computer account. Several public techniques abuse this behaviour:
| Technique | Protocol used |
|---|---|
| Printer bug | MS-RPRN, Print Spooler service |
| PetitPotam | MS-EFSR, Encrypting File System |
| DFSCoerce | MS-DFSNM, DFS Namespace management |
| Other variants | various RPC interfaces, including file server shadow copies |
Some of these techniques required a domain account, others could work unauthenticated before patches. Microsoft has fixed several variants, but the family remains open: new interfaces are identified regularly. The lasting defence is therefore not to plug each function, but to make the captured authentication useless.
Relay: where the attack really happens
An NTLM authentication obtained through coercion is only valuable if the attacker can relay it to a service that accepts it without checking it was meant for that service. Typical targets are:
- AD CS web enrollment: by relaying a domain controller's authentication to the certification authority's HTTP enrollment pages, the attacker can obtain a certificate in the DC's name, and from there replication rights on the directory;
- LDAP on domain controllers: a relay can allow changes to computer object attributes, for example to configure delegation;
- SMB on servers where signing is not required.
Kerberos relay also exists under narrower conditions; signing and channel binding measures limit it as well.
Breaking the chain on AD CS
This is the priority if you run a certification authority with web enrollment roles. Microsoft has published specific guidance:
- remove the "Certification Authority Web Enrollment" and "Certificate Enrollment Web Service" roles if they are not used;
- otherwise, require HTTPS and enable Extended Protection for Authentication (EPA) in IIS for these applications;
- disable NTLM on those IIS sites, keeping only Kerberos through Negotiate where possible.
Signing, channel binding and filtering
- Required SMB signing on domain controllers (the default) and ideally on every server and workstation. Recent Windows versions tighten these defaults; check which ones apply to your estate.
- Required LDAP signing and LDAP channel binding on domain controllers, after an audit phase to spot non-compliant clients.
- Print Spooler disabled on domain controllers and Tier 0 servers that do not print.
- RPC filters: Windows RPC filtering lets you block or restrict access to abused interfaces, such as MS-EFSR, on servers that do not need them. Test carefully, because a blocked interface may be used by a legitimate feature.
- Outbound filtering on domain controllers: a DC that cannot open SMB or HTTP connections to arbitrary machines cannot be forced to authenticate to them.
Reduce NTLM over time. Each of these measures closes one relay target. Gradually reducing NTLM, starting with auditing its use on domain controllers, removes the common cause. It is a project of several months, but it is the one that makes the whole family of attacks ineffective.
What an audit checks
- whether AD CS web enrollment roles are present, and their use of HTTPS, EPA and NTLM;
- required SMB signing and LDAP signing, and LDAP channel binding;
- the state of the Print Spooler service on domain controllers;
- outbound flows allowed from domain controllers;
- whether an inventory of NTLM usage and a reduction plan exist.