Blocking authentication coercion on domain controllers

Authentication coercion is the step that turns a low-privileged domain account into a domain compromise without a single password. The attacker calls an RPC method on a domain controller that makes the DC's machine account authenticate to a host the attacker chooses. That authentication is then relayed with NTLM to AD CS web enrollment (ESC8) or LDAP, or captured as a Kerberos TGT on a host with unconstrained delegation. A DC machine account can DCSync, so the chain ends with every hash in the domain.

The best-known triggers are PrinterBug (MS-RPRN), PetitPotam (MS-EFSR), DFSCoerce (MS-DFSNM) and ShadowCoerce (MS-FSRVP). New variants appear regularly, and Microsoft generally does not treat authenticated coercion as a vulnerability. This guide goes deeper than the coercion notes in the DC baseline. It covers measuring exposure, cutting the triggers with services and RPC filters, making coerced authentication useless, and verifying the result.

Why coercion is a two-sided problem

Every coercion chain has a trigger (an RPC interface on the DC that accepts a UNC path from the caller) and a destination (a relay target or delegation host that accepts the DC's credentials). Fix only one side and you are betting that no one finds the next trigger or the next destination. Hardening both is what makes the attack class boring:

The destination side belongs to other guides: LDAP signing and channel binding, SMB signing, EPA on AD CS web enrollment and removing unconstrained delegation. The rest of this guide covers the trigger side and the DC-specific controls that connect the two.

Measure: what is exposed today

Start by confirming which trigger services actually run on each DC. The Spooler should already be disabled if you applied the baseline, but check anyway. The File Server VSS Agent Service is only present when the FS-VSS-Agent role service is installed.

$dcs = (Get-ADDomainController -Filter *).HostName
Invoke-Command -ComputerName $dcs -ScriptBlock {
    [PSCustomObject]@{
        DC            = $env:COMPUTERNAME
        Spooler       = (Get-Service Spooler -ErrorAction SilentlyContinue).Status
        FssAgent      = (Get-Service -DisplayName 'File Server VSS Agent Service' -ErrorAction SilentlyContinue).Status
        DfsNamespace  = (Get-Service Dfs -ErrorAction SilentlyContinue).Status
        EfsService    = (Get-Service EFS -ErrorAction SilentlyContinue).Status
        VssAgentRole  = (Get-WindowsFeature FS-VSS-Agent).InstallState
        RpcFilters    = (netsh rpc filter show filter | Select-String 'filterKey').Count
    }
} | Format-Table -AutoSize

Note that stopping the EFS service is not a PetitPotam fix. The MS-EFSR interface is also reachable through \pipe\lsarpc, which LSASS serves whether or not the EFS service runs. That is why RPC filtering is the recommended control for EFSRPC.

Then check the destinations. Coercion targets the DC, but the relay lands somewhere else. List the hosts that would turn a coerced DC authentication into a win:

# Computers (other than DCs) trusted for unconstrained delegation
Get-ADComputer -Filter { TrustedForDelegation -eq $true -and PrimaryGroupID -ne 516 } |
    Select-Object Name, DNSHostName

# Enterprise CA hosts: check each (and any CES/Web Enrollment servers) for HTTP relay targets
Get-ADObject -SearchBase ("CN=Enrollment Services,CN=Public Key Services,CN=Services," +
    (Get-ADRootDSE).configurationNamingContext) -Filter * -Properties dNSHostName |
    Select-Object Name, dNSHostName

Audit: see coercion attempts before you block

Before you add blocking filters, run the same filters in audit mode for a week. The Windows RPC filter engine writes Security event 5712 ("A Remote Procedure Call (RPC) was attempted") for filters with auditing enabled, provided the RPC Events audit subcategory is on:

auditpol /set /subcategory:"RPC Events" /success:enable /failure:enable

You can also see named-pipe access on the DC with Detailed File Share auditing (event 5145) and a filter on the relative target names efsrpc, lsarpc, spoolss, netdfs and FssagentRpc. Be careful: lsarpc is used by every domain member all day. Use it for correlation, not alerting.

Look for the obvious things first. Any EFSRPC call to a DC from a workstation is suspicious because no legitimate client encrypts files on a DC. Any MS-DFSNM call from a host that is not a Tier 0 PAW deserves an owner.

Enforce: remove or filter each trigger

Print Spooler

Keep it disabled with Computer Configuration > Policies > Windows Settings > Security Settings > System Services > Print Spooler = Disabled in a GPO linked to the Domain Controllers OU. This is the only complete fix for PrinterBug. RPC filtering MS-RPRN is a fallback for member servers that must keep the Spooler.

File Server VSS Agent (ShadowCoerce)

A DC should not host this role. Remove it:

Uninstall-WindowsFeature -Name FS-VSS-Agent -ComputerName DC01

RPC filters for EFSRPC and DFSNM

RPC filters are Windows Filtering Platform rules at the RPC layer, keyed on interface UUID. Blocking by UUID stops the call no matter which named pipe or TCP endpoint it arrives on. The MS-EFSR interface is exposed under two UUIDs, c681d488-d850-11d0-8c52-00c04fd90f7e (via lsarpc) and df1941c5-fe89-4e79-bf10-463657acf44d (via efsrpc), so block both. MS-DFSNM uses 4fc742e0-4a10-11cf-8273-00aa004ae673. For DFSNM, a permit rule scoped to your Tier 0 group is safer than a blanket block, because administrators still manage domain-based namespaces through it.

Save the filter definition as a versioned file, for example dc-rpc-filters.txt:

rpc
filter
add rule layer=um actiontype=block audit=enable
add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add filter
add rule layer=um actiontype=block audit=enable
add condition field=if_uuid matchtype=equal data=df1941c5-fe89-4e79-bf10-463657acf44d
add filter
add rule layer=um actiontype=permit audit=enable
add condition field=if_uuid matchtype=equal data=4fc742e0-4a10-11cf-8273-00aa004ae673
add condition field=remote_user_token matchtype=equal data=D:(A;;CC;;;DA)
add filter
add rule layer=um actiontype=block audit=enable
add condition field=if_uuid matchtype=equal data=4fc742e0-4a10-11cf-8273-00aa004ae673
add filter
quit

Apply it and confirm:

netsh -f C:\Tier0\dc-rpc-filters.txt
netsh rpc filter show filter

Replace DA in the SDDL with the SID of your dedicated Tier 0 admin group when you have one. There is no Group Policy node for RPC filters, so distribute the file through your Tier 0 configuration management or a DC startup script. Make the script idempotent: run netsh rpc filter delete filter filterkey=all first only if you own every filter on the box.

Take away the network path

Coercion needs the DC to reach the attacker's listener over SMB (445) or HTTP (80, or any port through the WebClient service). A DC rarely has a legitimate reason to start SMB or HTTP sessions toward workstations or user server subnets. Blocking that egress is covered in firewalling domain controllers and is one of the most effective anti-coercion controls, because it also covers triggers nobody has published yet.

Harden the destinations

Treat these as mandatory companions, not optional extras:

• LDAP: require signing and channel binding on every DC.
• SMB: require signing on servers and clients. This is the default on recent Windows 11 and Windows Server 2025 builds, but verify it rather than assume it.
• AD CS: remove Web Enrollment if unused. Otherwise enforce HTTPS with Extended Protection for Authentication and disable NTLM on those IIS sites.
• Delegation: no non-DC computer should keep unconstrained delegation. Add Tier 0 accounts to Protected Users and mark them sensitive so their TGTs cannot be forwarded.

Verify

Check the configuration from a PAW:

Invoke-Command -ComputerName $dcs -ScriptBlock {
    $f = netsh rpc filter show filter | Out-String
    [PSCustomObject]@{
        DC          = $env:COMPUTERNAME
        Spooler     = (Get-Service Spooler).StartType
        EfsLsarpc   = $f -match 'c681d488-d850-11d0-8c52-00c04fd90f7e'
        EfsEfsrpc   = $f -match 'df1941c5-fe89-4e79-bf10-463657acf44d'
        DfsNm       = $f -match '4fc742e0-4a10-11cf-8273-00aa004ae673'
        VssAgent    = (Get-WindowsFeature FS-VSS-Agent).InstallState
    }
}

Then test the behaviour. In a lab or approved window, have your red team or a purple-team exercise run the common coercion tools (for example, Coercer or the individual proof-of-concepts) against one DC with a standard user account. Confirm three things: no authentication reaches the listener, event 5712 fires for the blocked interface, and your SIEM raises an alert. Test the DFSNM permit rule as well. Open the DFS Management console from a PAW as a Tier 0 admin and confirm namespace administration still works.

Re-run the check after each cumulative update and after any DC rebuild. A freshly promoted DC without the filter file is the most common gap.

What it breaks

• Remote EFS operations on DCs. Nothing legitimate should encrypt files on a DC over the network. Backup or file-management tools that call EFSRPC against shares hosted on DCs will fail. Move those shares off the DC.
• DFS namespace administration from non-admin hosts. With the DFSNM filter, only the SID in the permit rule can manage namespaces remotely. Delegated namespace admins who work from ordinary workstations lose access until they move to a PAW or into the permitted group. SYSVOL and NETLOGON referrals are not affected because clients do not use the management interface.
• Printing through a DC. Any queue still published from a DC disappears once the Spooler is disabled.
• Monitoring or backup agents that pull from DCs over SMB/HTTP in the reverse direction. Egress filtering can catch agents that expect the DC to connect out to them. Map these during the audit week.
• Future RPC changes. Filters keyed on UUID are precise. If Microsoft ever moves functionality to a new interface, filters will not cover it, so keep the audit events flowing.

Related reading: the DC baseline for the rest of the domain controller configuration, Stop NTLM relay: LDAP, SMB signing and LLMNR for the relay-target side, and the NTLM relay glossary entry for background on why a coerced authentication is so valuable.