PetitPotam (CVE-2021-36942) forces a Windows server, usually a domain controller, to authenticate over EFSRPC to an attacker’s machine, which then relays that NTLM authentication to AD CS web enrollment. PetitPotam mitigation: install updates from August 2021 or later, enable EPA and Require SSL on AD CS web endpoints, block EFSRPC with RPC filters and restrict NTLM on domain controllers.
What the scanner is actually detecting
In Nessus the finding is Microsoft Windows EFSRPC NTLM Reflection Elevation of Privilege (PetitPotam) (Remote), plugin ID 152102, in the Windows family. It is a remote check, so it runs without credentials: Nessus sends a crafted EFSRPC request to the host and Tenable marks the plugin as “Exploited by Nessus”. A hit means the host still accepts the unauthenticated call that makes it connect out to another server. Tenable’s solution text is to apply the vendor updates, optionally follow KB5005413, and optionally use RPC filters to block the EFSRPC interface UUIDs.
PingCastle reports a related but broader issue on domain controllers as rule A-DC-Coerce, titled “RPC interfaces potentially vulnerable to Coerce attacks”. It is not limited to EFSRPC. According to the rule definition, PingCastle considers a DC protected when the GPO “Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers” is applied to it, or when the coercible RPC interfaces are not reachable.
Real-world risk
The attack is a chain. First, an attacker on the network coerces a domain controller into authenticating to a host they control. Second, they relay that NTLM authentication to an AD CS HTTP endpoint (Certificate Authority Web Enrollment or the Certificate Enrollment Web Service) that has no relay protection, and receive a certificate for the DC’s computer account. CERT/CC describes the result as a path to Active Directory compromise, and Microsoft’s CVE FAQ says the combined CVSS score is 9.8 when this vulnerability is chained with the AD CS relay.
CVE-2021-36942 on its own is rated 7.5 by Microsoft and is listed in the CISA Known Exploited Vulnerabilities catalog, with known ransomware campaign use (our CISA KEV catalog explainer covers what that listing means for patch deadlines). Stated honestly: the full domain takeover needs a reachable AD CS web endpoint without EPA. If you have no Web Enrollment or CES, the classic chain does not work, but the coercion primitive still feeds other NTLM relay targets, so it is not a finding to ignore on domain controllers.
How to confirm it on the host
Check that the host has a cumulative update from August 10, 2021 or later and has been rebooted since:
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, InstalledOnFind your AD CS web endpoints. On each CA or enrollment server:
Get-WindowsFeature ADCS-Web-Enrollment, ADCS-Enroll-Web-Svc | Select-Object Name, InstallStateTest Web Enrollment from any client. A 401 response offering NTLM or Negotiate over plain HTTP means the endpoint still accepts HTTP authentication; with Require SSL set you should get a 403 instead:
curl.exe -I http://ca01.contoso.com/certsrv/Read the effective IIS settings on the server (WebAdministration module):
Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location 'Default Web Site/CertSrv' `
-Filter 'system.webServer/security/authentication/windowsAuthentication/extendedProtection' -Name tokenChecking
Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location 'Default Web Site/CertSrv' `
-Filter 'system.webServer/security/access' -Name sslFlagsNone for tokenChecking means EPA is off. On domain controllers, list any existing RPC filters with netsh rpc filter show filter.
How to fix it
Step 1: patch, domain controllers first
Install the August 2021 security update or any later cumulative update. Microsoft states the update blocks the OpenEncryptedFileRawA/W calls through the LSARPC interface, that all servers are affected, and that domain controllers should be prioritized. This is what closes Nessus 152102. Microsoft also states that further action is needed after the update, which is KB5005413.
Step 2: harden AD CS Web Enrollment (KB5005413)
In IIS Manager, select Default Web Site > CertSrv > Authentication > Windows Authentication > Advanced Settings and set Extended Protection to Required. Then open SSL Settings for CertSrv and tick Require SSL. The site needs a working HTTPS binding first. The equivalent AppCmd commands are:
%windir%system32inetsrvappcmd.exe set config "Default Web Site/CertSrv" -section:system.webServer/security/authentication/windowsAuthentication /extendedProtection.tokenChecking:"Require" /extendedProtection.flags:"None" /commit:apphost
%windir%system32inetsrvappcmd.exe set config "Default Web Site/CertSrv" -section:system.webServer/security/access /sslFlags:"Ssl" /commit:apphost
iisreset /restartIf the current sslFlags value already includes client certificate flags, keep them in the new value rather than overwriting them with Ssl alone.
Step 3: harden the Certificate Enrollment Web Service
Set Extended Protection to Required on the CES application in IIS Manager and confirm Require SSL. Then edit the CES web.config at %windir%systemdataCES<CA Name>_CES_Kerberosweb.config and add the policy inside the Windows transport element. KB5005413 says to use Always when the UI is set to Required:
<transport clientCredentialType="Windows">
<extendedProtectionPolicy policyEnforcement="Always" />
</transport>Run iisreset /restart afterwards. Note that it restarts every IIS site on the server.
Step 4: remove the roles if nobody uses them
Many environments installed Web Enrollment years ago and never used it. Removing it is cleaner than hardening it:
Uninstall-AdcsWebEnrollment -Force
Uninstall-AdcsEnrollmentWebService -AllEnrollmentServices -Force
Uninstall-WindowsFeature ADCS-Web-Enrollment, ADCS-Enroll-Web-SvcStep 5: block EFSRPC with netsh RPC filters
On domain controllers and other servers where nobody manages EFS-encrypted files remotely, block both EFSRPC interfaces. Save this as block_efsr.txt (the content published by CERT/CC):
rpc
filter
add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add filter
add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=df1941c5-fe89-4e79-bf10-463657acf44d
add filter
quitImport it from an elevated prompt with netsh -f block_efsr.txt. Per the MS-EFSR specification, the first UUID is EFSRPC reached through pipelsarpc and the second is EFSRPC through pipeefsrpc. The rest of LSARPC is not blocked.
Step 6: audit, then restrict NTLM on domain controllers
Link a GPO to the Domain Controllers OU and go to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. Set Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers to Audit all, review the NTLM operational log for a full business cycle, add legitimate targets to Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication, then move to Deny all. No restart is required. On AD CS servers, KB5005413 additionally suggests Network security: Restrict NTLM: Incoming NTLM traffic set to Deny All Accounts or Deny all domain accounts, and setting IIS Windows authentication providers to Negotiate:Kerberos. Our guide on how to disable NTLM safely walks through the audit phase in detail.
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -MaxEvents 50 | Format-List TimeCreated, Id, MessageHow to verify the fix and rescan
- Rerun curl.exe -I http://ca01.contoso.com/certsrv/ and confirm HTTP is refused, then request a test certificate over HTTPS from a domain-joined client to prove enrollment still works.
- Rerun the two Get-WebConfigurationProperty commands and confirm Require and Ssl.
- Run netsh rpc filter show filter and confirm both UUIDs are listed, including after the next reboot.
- Rescan the domain controllers and servers with Nessus. Plugin 152102 is a remote check, so a normal network scan is enough to confirm it has closed.
- Rerun the PingCastle healthcheck and check whether A-DC-Coerce is gone.
What can break and how to roll back
- EPA Required: clients that do not send channel binding tokens fail to authenticate. Microsoft’s IIS documentation notes that SSL offloading at a proxy or load balancer changes how extended protection works, so test published enrollment URLs. Roll back by setting tokenChecking to Allow (the “Accept” option) or None and running iisreset.
- Require SSL: old http:// bookmarks and scripts pointing at /certsrv stop working. Roll back by restoring the previous sslFlags value.
- Negotiate:Kerberos: clients that cannot get a Kerberos ticket for the server name, for example when browsing by IP address, can no longer authenticate.
- RPC filters: remote management of EFS-encrypted files on that server stops. Find the filterKey with netsh rpc filter show filter and remove it with netsh rpc filter delete filter filterkey=<key>.
- Outgoing NTLM deny on DCs: PingCastle warns that NTLM-dependent services such as file copy backups may fail. Revert the GPO to Audit all or Allow all; the change takes effect without a restart.
- The update itself: Microsoft notes that OpenEncryptedFileRaw, used by some backup software, no longer works on Windows Server 2008 SP2.
Common false positive reasons
- Update installed, reboot pending. The patched code is not active until the restart, so Nessus 152102 still fires. Reboot and rescan.
- Stale results. The host was patched after the scan that raised the finding.
- PingCastle cannot fully test coercion. Its own documentation says it sends a malformed RPC packet and treats an RPC_X_BAD_STUB_DATA error as “interface available”, so a flagged interface may not be exploitable. Use the Detail rows to see which interfaces were hit.
- NTLM restricted outside Group Policy. PingCastle looks for the outgoing NTLM setting applied through a GPO to domain controllers. A value set by another tool may leave the rule flagged even though the DC is protected.
FAQ
Does the August 2021 update fully fix PetitPotam?
It closes the unauthenticated LSARPC path that Nessus 152102 tests. Microsoft still says further steps are needed and points to KB5005413, because NTLM relay to AD CS remains possible without EPA.
We do not run Web Enrollment or CES. Do we still need to act?
Patch anyway, since the plugin will keep firing on unpatched hosts. The AD CS web chain does not apply to you, but restricting NTLM on DCs still limits relay to other services.
Is the netsh RPC filter a replacement for patching?
No. Tenable lists RPC filters as an additional mitigation next to the vendor updates. Treat them as defense in depth on DCs, where remote EFS is rarely needed.
Does fixing this need a domain controller reboot?
The cumulative update does. The NTLM restriction policy takes effect without a restart, and the IIS changes on AD CS servers only need iisreset.
Tracking this finding across many hosts
PetitPotam touches every DC, every CA server and the GPOs between them, so proving closure host by host is the slow part. If you use SITEY, you can upload the .nessus export to track plugin 152102 per host, have AI draft host-specific remediation scripts that run only after human approval through SITEY agents on Windows endpoints, and use per-finding Nessus retest to confirm each host is closed.