Block Outbound NTLM: Tier 0 Domain Controller Coercion-Relay Attacks, Stopped at the GPO Layer

What "Outbound NTLM" Means for a Domain Controller

This guide explains how to block outbound NTLM: Tier 0 domain controller coercion relay chains such as PetitPotam and the techniques that followed it depend entirely on that outbound authentication existing in the first place — deny it, and they have nothing left to relay. Domain controllers authenticate almost everything they do to each other and to other Active Directory-integrated services with Kerberos, but NTLM still exists underneath as a fallback, and by default every Windows system will happily authenticate outbound over NTLM to whatever server asks for it.

ANSSI, the French national cybersecurity agency, documents this pattern directly in its Active Directory administration guide. NTLMv2 authentication is a network logon — distinct from the interactive logons that leave reusable hashes sitting in memory — and its challenge response can be intercepted mid-flight and relayed to a second target without the attacker ever learning the underlying secret, borrowing the victim's access rights instead of stealing its password (ANSSI-PA-099, §4.15.2). When the coerced system is a domain controller, the access rights being relayed are Tier 0.

How Coercion-and-Relay Attacks Abuse Outbound NTLM

The best-documented member of this class is PetitPotam. CERT/CC's advisory on the technique explains that it abuses the Encrypting File System Remote Protocol: a call to EfsRpcOpenFileRaw makes the target system "use NTLM to authenticate with the host that is specified within the path," and an attacker can point that path at infrastructure they control — triggering an NTLM authentication attempt from the domain controller's own machine account, with no credentials needed to start the chain (CERT/CC VU#405600).

That captured NTLM authentication is only dangerous because somewhere else accepts it. CERT/CC lays out the full chain against Active Directory Certificate Services in three steps:

Step 1 — Coerce

The attacker calls EfsRpcOpenFileRaw (or an equivalent RPC method with the same authentication-triggering behavior) against the domain controller, pointing it at attacker-controlled infrastructure. The DC's machine account opens an outbound NTLM authentication — this is a network logon, ANSSI's guide notes, not the interactive kind that leaves reusable hashes in memory.

Step 2 — Relay

The attacker captures the NTLMv2 challenge response — the "Net-NTLMv2" hash — and immediately relays it, unmodified, to the AD CS Web Enrollment HTTP endpoint before it expires.

Step 3 — Convert

AD CS issues a certificate for the domain controller's machine account. CERT/CC notes that certificate "can be used to obtain a Ticket Granting Ticket," which is enough to compromise the entire domain — no password or hash ever had to be cracked.

Every step in that chain depends on step 1 succeeding: the domain controller has to be willing to send NTLM authentication outbound in the first place. Remove that, and steps 2 and 3 have nothing to work with.

Microsoft's fix, tracked as CVE-2021-36942 ("Windows LSA Spoofing Vulnerability"), closed only the unauthenticated version of the EfsRpcOpenFileRaw call. It did not close the underlying pattern — a Tier 0 system can still be pushed into an outbound NTLM authentication through other RPC interfaces that behave the same way, which is why Microsoft's own remediation guidance for this attack family goes further than one patch. KB5005413 recommends enabling Extended Protection for Authentication on AD CS endpoints, and — as a stronger, protocol-level option — to "disable NTLM Authentication on your Windows domain controller" outright (Microsoft KB5005413). That second option is precisely what ANSSI's R73 recommendation operationalizes as a single Group Policy setting.

Block Outbound NTLM on Tier 0 Domain Controllers Against Coercion-Relay Attacks (ANSSI R73)

ANSSI's R73 recommendation is direct: "outbound NTLM authentications from all Tier 0 systems must be blocked," applied through a single Group Policy setting. The GPO path, taken from the guide, is:

Computer Configuration\Windows Settings\Security Settings\Local Policies\
Security Options\Network Security: Restrict NTLM: Outgoing NTLM traffic
to remote servers → Deny all

Microsoft's own reference for this setting confirms the same three states — Allow all (no restriction), Audit all (logs every outbound NTLM attempt without blocking it), and Deny all (the device "can't authenticate any identities to a remote server by using NTLM authentication") — and notes the setting is Not Configured by default on every domain controller and member server (Microsoft Learn — Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers). Left unconfigured, the coercion-and-relay class has exactly the outbound path it needs.

ANSSI is explicit that Audit all is not sufficient for R73 — the recommendation prescribes Deny, not logging. Audit mode is the pre-deployment step: run it long enough to confirm no legitimate outbound NTLM traffic exists from Tier 0 (it normally shouldn't, since DC-to-DC and DC-to-AD-service traffic natively supports Kerberos), then switch to Deny all. The guide adds one operational caveat worth taking seriously: blocking outbound NTLM assumes Tier 0 systems reach other AD services by FQDN rather than by raw IP address, since Kerberos depends on name resolution to select the right service ticket — a misconfiguration the audit phase will surface before it becomes an outage.

The Companion Control: Restricting What Tier 0 Sends Downward (ANSSI R82/R83)

Blocking outbound NTLM closes the network-authentication side of Tier 0 exposure. ANSSI's baseline position is that Tier 0 administration workstations should have no downward connectivity to begin with — physically dedicated, with outbound traffic allowed only to Tier 0 resources (R80). R82 and R83 apply specifically when an organization instead adopts ANSSI's second alternative architecture: pooling Tier 0 remote access to lower-trust environments as a transitional fallback to full segregation. Within that model, R82 restricts which remote-connection methods are allowed out of Tier 0 toward less-trusted zones — RPC/MMC, PowerShell WinRM with its default Kerberos-or-NTLM network authentication, or native RDP either with RestrictedAdmin mode or using an account scoped to the destination tier. R83 goes further: the account used for an interactive session on that lower-trust destination must belong to that destination's own trust zone, never a Tier 0 or Tier 1 credential, so a compromised lower-tier system never ends up holding reusable Tier 0 secrets. For the full walkthrough of tier-scoped logon restrictions, see Active Directory authentication policies and silos for Tier 0.

Detecting Outbound NTLM Before and After the Block

Both event IDs are confirmed directly in ANSSI-PA-099 §4.15.2.1, and Microsoft's own reference for the policy setting points to the same operational log path. Two things worth monitoring once the block is live:

• Any burst of Event ID 4001 after rollout deserves investigation — either a legitimate dependency was missed during the audit phase, or something is actively trying to coerce an outbound authentication and being stopped.
• Event ID 8001 during the audit phase is your dependency map. Every source/destination pair it lists is something to resolve — fix it, exempt it, or migrate it to Kerberos — before flipping to Deny all.

Related detection coverage — LDAP and SMB relay defenses that matter regardless of whether outbound NTLM is blocked — is covered in LDAP channel binding on domain controllers and SMB signing and NTLM relay.

Remediation

1. Confirm Tier 0 scope first. R73 only works if your Tier 0 OU actually contains every domain controller and Tier 0-sensitive server — cross-check against your tiered admin model before linking any GPO.
2. Roll out Audit all on a GPO linked to the Tier 0 OU. Let it run long enough to span your patch cycle, backup jobs, and any monthly/quarterly admin tasks — short audit windows miss recurring dependencies.
3. Review Event ID 8001 entries and resolve every legitimate one: point the source at Kerberos (usually a DNS/SPN fix), add it to the NTLM server exception list if it truly cannot move off NTLM, or retire the dependency.
4. Flip the same GPO to Deny all. Watch for Event ID 4001 in the days after — anything unexpected is either a missed dependency or an active coercion attempt.
5. Extend to R74+ once Tier 0 is clean: link an equivalent GPO at the domain root for the rest of the environment, with WMI-filtered exceptions where NTLM genuinely cannot be removed yet.
6. Layer R82/R83 for Tier 0 admins who must connect downward — restrict the remote-connection method and require a destination-tier account, per the previous section, so this control and the network-layer block cover both directions of the risk.
7. Combine with relay-side hardening. Outbound NTLM blocking removes the source of relayed authentications from Tier 0, but any system anywhere in the SI that still accepts unsigned/unprotected NTLM relay targets (LDAP without channel binding, SMB without signing, AD CS Web Enrollment without Extended Protection) remains exploitable against non-Tier-0 victims. Treat this GPO as one layer, not the whole defense.

How EtcSec Detects This

EtcSec's Active Directory audit checks for exactly this configuration gap. ANSSI_R73_NTLM_OUTBOUND_TIER0 flags the absence of any GPO setting RestrictSendingNTLMTraffic to Deny all across Tier 0 systems — Audit-only mode is correctly treated as not meeting the control. ANSSI_R74_NTLM_OUTBOUND_DOMAIN separately tracks whether that same deny policy has been extended to a GPO linked at the domain root. ANSSI_R82_R83_ADMIN_ARCHITECTURE flags Tier 0 systems that lack the admin-architecture safeguards R82 and R83 call for, and NTLM_RELAY_OPPORTUNITY flags the broader relay exposure across the environment whenever NTLM remains reachable without the compensating protections described above.