The PetitPotam attack forces Windows domain controllers to authenticate against attacker-controlled systems through MS-EFSRPC protocol abuse. Attackers relay these coerced credentials to Active Directory Certificate Services, obtain valid certificates, and gain domain admin access. The attack succeeds because many organizations still use NTLM authentication with poorly configured certificate services, even after Microsoft released patches.
Detection remains the biggest challenge. Standard security tools miss the authentication and certificate enrollment patterns that indicate an active PetitPotam identity attack. This guide explains the technical mechanics, why conventional monitoring fails, and which continuous monitoring strategies actually catch these threats across your Microsoft infrastructure before attackers escalate privileges.
What Is PetitPotam and Why Is It Important?
PetitPotam represents a class of attack that exploits fundamental weaknesses in how Windows systems handle authentication. Unlike malware that requires installation or phishing schemes that rely on user error, PetitPotam weaponizes legitimate Microsoft protocols to force authentication events that administrators never intended. This technique bypasses traditional security controls because it operates within the bounds of “normal” system behavior, making it exceptionally difficult to detect and prevent.
The Discovery and Initial Impact
Security researcher Lionel Gilles (known as Topotam) publicly released PetitPotam in July 2021, demonstrating how the Microsoft Encrypting File System Remote Protocol (MS-EFSRPC) could be abused to coerce Windows machines into authenticating against attacker-controlled systems. The technique works by sending specially crafted requests through the LSARPC named pipe on TCP port 445, a port that’s typically open for file sharing and domain operations.
What made this discovery particularly alarming is that the attack required no credentials. An attacker on the same network could trigger authentication requests from domain controllers without first compromising any accounts. Within days of the proof-of-concept release, security teams worldwide realized they had a serious problem: Most enterprise environments had the necessary components in place for successful exploitation.
How PetitPotam Exploits NTLM Authentication
The attack centers on NT LAN Manager (NTLM), an authentication protocol that Windows systems still support despite its known vulnerabilities. When PetitPotam triggers an authentication request, the target server responds with NTLM credentials through a challenge-response mechanism. The attacker intercepts these credentials and relays them to another service that accepts NTLM authentication.
PetitPotam Attack Visualization
The authentication coercion happens without any warning to administrators: no failed login attempts, no suspicious access logs, just normal-looking network traffic that masks the beginning of a domain compromise.
This relay technique functions as a man-in-the-middle attack, where the attacker sits between two legitimate systems and forwards authentication traffic while capturing the credentials in transit. NTLM lacks mutual authentication, unlike Kerberos, so the protocol cannot verify that both parties in the exchange are legitimate.
The Role of Active Directory Certificate Services
PetitPotam becomes a critical threat when combined with Active Directory Certificate Services (AD CS). AD CS implementations frequently run web enrollment interfaces that accept NTLM authentication over HTTP. When an attacker relays coerced credentials to these AD CS endpoints, they can request and obtain valid certificates for the compromised account, including domain controller machine accounts.
These certificates then serve as persistent authentication credentials that work even if administrators reset passwords or apply other remediation measures. Certificate-based authentication is trusted implicitly within Windows environments, creating a scenario where attackers maintain access through what appears to be legitimate, certificate-authenticated sessions.
How PetitPotam Identity Attacks Work
The technical sequence of a PetitPotam identity attack shows exactly why it’s so effective against organizations running standard Active Directory configurations. This attack follows a precise five-step process that transforms routine network activity into complete domain compromise. Each phase builds on the previous one, creating a chain reaction that security teams typically don’t detect until after damage has occurred.
Step 1: Triggering the Authentication Request
The attack starts when an adversary sends a specially crafted request through the Microsoft Encrypting File System Remote Protocol (MS-EFSRPC) interface. This request targets the EfsRpcOpenFileRaw function, which was originally designed to enable remote access to encrypted files. The attacker connects to the target system’s LSARPC named pipe over TCP port 445, a port that stays open on domain controllers and member servers for legitimate file sharing and domain operations.
What makes this initial step particularly dangerous is that it requires zero authentication. An attacker with basic network access can force a domain controller to initiate an authentication attempt without first compromising any accounts or credentials. The target system interprets the MS-EFSRPC request as legitimate and responds by attempting to authenticate to the attacker-specified server.
Step 2: Intercepting NTLM Credentials
Once the authentication request is triggered, the target server sends its credentials using the NTLM protocol. The attacker positions themselves to capture this authentication attempt in real time. Unlike Kerberos, which implements mutual authentication to verify both parties in an exchange, NTLM operates through a challenge-response mechanism that can be intercepted and forwarded without detection.
The authentication data includes the target system’s machine account credentials, typically a domain controller account when this attack is executed correctly. These credentials pass through the network in a format that allows an attacker to relay them to another service, even though the attacker cannot directly decrypt or crack them within a practical timeframe.
Step 3: Relaying to Certificate Services
With captured NTLM credentials in hand, the attacker relays them to an Active Directory Certificate Services web enrollment endpoint. According to practical attack guides, this relay typically targets the /certsrv/certfnsh.asp endpoint running on IIS servers that host AD CS functionality. The attacker uses tools that automate this relay process, forwarding the authentication data while the target system believes it’s communicating with a legitimate service.
The relay happens through HTTP rather than HTTPS in many default configurations, making the attack easier to execute. The attacker sends a POST request containing an automatically generated Certificate Signing Request (CSR) along with the relayed NTLM credentials. The AD CS server, seeing what it believes are legitimate credentials from a domain controller or authorized system, processes the certificate request.
The certificate authority has no way to distinguish between legitimate authentication and relayed credentials. They appear identical from the server’s perspective, making this attack extremely difficult to prevent through AD CS configuration alone.
Step 4: Obtaining Domain Controller Certificates
When the certificate request succeeds, the AD CS server signs the certificate and makes it available for retrieval. The attacker fetches this newly minted certificate by sending a GET request to /certsrv/certnew.cer with the request ID provided in the POST response. This certificate carries the full authentication weight of the compromised machine account (in most scenarios, a domain controller).
Unlike passwords or NTLM hashes that can be changed or reset, certificates remain valid for their entire lifecycle, typically ranging from months to years, depending on template configuration. This persistence means the attacker maintains access even if administrators reset passwords, disable accounts, or implement other standard incident response procedures.
Step 5: Achieving Domain Compromise
The final step involves using the obtained certificate to request Kerberos Ticket Granting Tickets (TGTs). Tools like Rubeus can convert the certificate into active Kerberos authentication tickets that grant the attacker the full privileges of the compromised machine account. When that account belongs to a domain controller, the attacker essentially becomes the domain controller from an authentication perspective.
From this position, attackers can perform DCSync operations to extract password hashes for every account in the domain, including domain administrators and the krbtgt account. They can create new accounts, modify group memberships, change security policies, or deploy malware across the entire domain, all using what appear to be legitimate, certificate-authenticated sessions that most security tools will not flag as suspicious.
Why Traditional Detection Methods Fall Short
Most security teams use tools built for yesterday’s threats, scanning for known malware signatures, analyzing periodic log dumps, or generating snapshot reports of system configurations. When it comes to PetitPotam identity attacks, this approach creates dangerous blind spots that attackers are happy to exploit.
The Limitations of Point-in-Time Scanning
Some tools identify Active Directory misconfigurations during scheduled assessments. These utilities examine group policies, trust relationships, password policies, and other security settings to produce detailed reports highlighting potential weaknesses.
The fundamental problem is timing: These scanners operate on demand, capturing only what exists at the moment of execution. If an administrator runs Purple Knight on Monday morning and an attacker launches a PetitPotam attack Tuesday afternoon, the security team remains blind until the next scheduled scan, which might be days, weeks, or even months away.
During this gap, attackers can complete the entire attack chain, from initial MS-EFSRPC abuse through certificate enrollment to domain controller compromise. Static reports don’t track the sequence of authentication events, certificate requests, or permission changes that signal an active PetitPotam identity attack. They show you vulnerabilities that exist, not attacks that are happening.
NTLM's Persistent Vulnerability
Organizations face a difficult reality: NTLM authentication remains deeply embedded in enterprise environments despite Microsoft’s long-standing recommendation to migrate to Kerberos. According to SANS Internet Storm Center analysis, the core issue is that NTLM uses challenge-response mechanisms without mutual authentication, making credential relay attacks feasible.
Here’s what makes NTLM particularly problematic for detection:
- Legacy application dependencies: Line-of-business applications built years ago often require NTLM, and replacing or updating these systems demands significant budget and testing resources that many IT departments lack.
- Protocol downgrade attacks: Even when Kerberos is available, attackers can force systems to fall back to NTLM through various techniques, and most monitoring solutions don’t alert on these downgrades because they happen frequently during normal operations.
- Authentication traffic volume: NTLM generates enormous amounts of network traffic in typical enterprise environments, making it extremely difficult to distinguish malicious relay attempts from legitimate authentication requests without continuous, context-aware monitoring.
Disabling NTLM enterprise-wide would break too many critical systems, so organizations accept the risk, often without understanding the full implications for PetitPotam-style attacks.
The Certificate Services Blind Spot
Active Directory Certificate Services often operates as security’s forgotten component. Administrators focus on domain controllers, group policies, and user accounts while certificate authorities run with default configurations that haven’t been reviewed since initial deployment. IIS logs from AD CS servers rarely feed into security information and event management (SIEM) systems, and when they do, security teams lack the baseline understanding needed to identify suspicious certificate enrollment patterns.
The web enrollment interface presents the perfect target because it accepts NTLM authentication over HTTP in many default configurations. This combination allows attackers to relay credentials and request certificates without ever needing to crack passwords or bypass multi-factor authentication. Most security tools don’t correlate coerced authentication attempts with subsequent certificate requests, so the attack appears as a number of separate, benign events rather than the coordinated assault it actually represents.
Protecting Your Hybrid Identity Environment from PetitPotam
Defending against PetitPotam identity attacks means moving away from periodic security checks toward continuous observation. You need to see authentication patterns, certificate enrollment activity, and permission changes as they happen, not hours or days later when attackers have already done damage. This section walks through the specific monitoring capabilities and detection strategies that fill the gaps traditional security tools miss.
Implementing Real-Time Change Monitoring
Real-time change monitoring captures every modification across your Microsoft identity infrastructure the moment it happens. This approach tracks both object-level changes (like user account creation or group modifications) and attribute-level changes (such as permission escalations or policy adjustments) across Active Directory, Microsoft Entra ID, and connected services.
For PetitPotam detection specifically, your real-time monitoring should capture these three critical areas:
- Certificate enrollment patterns: Unusual certificate requests from machine accounts, especially domain controllers, need immediate investigation. Track who requested the certificate, which template was used, and whether the request came from an expected source.
- Authentication anomalies: Watch for authentication attempts that follow suspicious patterns, such as machine accounts authenticating to unexpected endpoints or NTLM authentication occurring when Kerberos should be the default protocol.
- AD CS configuration changes: Any modifications to certificate templates, enrollment permissions, or web enrollment settings should trigger alerts, since attackers sometimes alter these configurations to enable credential relay attacks.
Continuous Threat Detection for Identity Infrastructure
Beyond change tracking, effective PetitPotam defense requires threat detection logic that understands attack patterns specific to identity infrastructure. This means correlating events that look harmless in isolation but signal compromise when viewed together.
The attack chain creates specific behavioral indicators that continuous monitoring systems can identify. These include the sequence of MS-EFSRPC calls followed by NTLM authentication attempts, relay activity targeting AD CS endpoints, and certificate requests that don’t match normal enrollment patterns for the requesting account.
How Cayosoft Guardian Protector Addresses PetitPotam Risks
Cayosoft Guardian Protector delivers continuous visibility across the entire attack surface that PetitPotam exploits. The platform monitors Active Directory, Microsoft Entra ID, Exchange Online, and Microsoft 365 in real time without requiring agents or creating performance overhead.
Guardian Protector detects the specific changes and patterns that indicate PetitPotam identity attacks in progress. When certificate enrollment occurs from unexpected sources, NTLM authentication patterns deviate from baseline behavior, or AD CS permissions change unexpectedly, the system generates immediate alerts with full context about what changed, who made the change, and where it originated.
The platform captures both indicators of exposure (IOEs) and indicators of compromise (IOCs) related to PetitPotam. This includes monitoring for the certificate template misconfigurations that make the attack possible, tracking authentication relay attempts, and identifying privilege escalations that follow successful certificate-based compromises.
What separates Guardian Protector from point-in-time scanning tools is its continuous operation and unlimited object coverage. You can monitor every user, group, policy, and certificate across your hybrid environment without hitting licensing caps or feature restrictions. When suspicious activity occurs, such as a domain controller machine account requesting a certificate through web enrollment, your security team receives actionable alerts that include the full change history and context needed for fast investigation.
The solution also provides one-click remediation capabilities, allowing administrators to reverse unauthorized changes immediately without relying on backup restores or manual configuration edits. This rollback functionality is critical when responding to PetitPotam attacks, as it enables teams to remove maliciously obtained certificates and restore proper configurations before attackers can use their access.
Download Guardian Protector for free and experience real-time visibility across your hybrid Microsoft identity infrastructure.
Moving Beyond Reactive Security
PetitPotam identity attacks succeed because they exploit the time gap between when threats emerge and when security teams detect them. Static scanning tools cannot protect against attacks that unfold in minutes, and manual log review cannot scale to match the speed of credential relay techniques.
Organizations that continue relying on periodic assessments and point-in-time snapshots will remain vulnerable to authentication coercion and certificate-based compromises that bypass traditional defenses. The solution requires shifting from scheduled security checks to continuous observation across your entire hybrid Microsoft infrastructure, tracking every authentication event, certificate request, and permission change as they occur. Real-time threat detection identifies suspicious patterns before attackers escalate privileges, while immediate alerting gives your team the visibility needed to respond during the attack window rather than discovering compromise weeks later during the next scheduled scan.
FAQs
Traditional antivirus solutions cannot effectively detect PetitPotam because the attack uses legitimate Windows protocols and doesn’t involve malware installation. Specialized identity threat detection systems that monitor authentication patterns and certificate enrollment activity in real time are required to identify these attacks.
While Microsoft has released patches addressing specific MS-EFSRPC functions, the underlying NTLM relay technique and AD CS misconfigurations remain exploitable through alternative methods. Complete protection requires disabling NTLM where possible, hardening certificate services configurations, and implementing continuous monitoring of authentication activity.
PetitPotam forces authentication through MS-EFSRPC protocol abuse to steal credentials via relay attacks, while PrintNightmare exploits Windows Print Spooler service vulnerabilities to execute arbitrary code. Both target domain controllers but use fundamentally different exploitation techniques and require distinct mitigation strategies.
Once an attacker successfully relays credentials and obtains a valid certificate from AD CS, domain compromise can occur within minutes. The entire attack chain, from initial authentication coercion to obtaining domain admin privileges, typically completes in under an hour if certificate services are misconfigured.
Certificate templates that allow Subject Alternative Name (SAN) specification, permit NTLM authentication for enrollment, and don’t require manager approval create the highest risk. Default templates like “Domain Controller” and “Web Server” are frequently targeted when web enrollment accepts NTLM over HTTP.
Want to See Cayosoft in Action?
Cayosoft is recognized by Gartner as an ITDR solution provider and provides solutions that make identities more resilient to attacks and guarantee a fast forest recovery, if needed. Learn how Cayosoft Guardian facilitates granular change tracking, post-breach analysis, and long-term AD security improvements. Schedule a demo to see the capabilities in depth.