Attack Vectors Against Active Directory Certificate Services (AD CS) in Enterprise Environments

Active Directory Certificate Services (AD CS) is Microsoft’s on-premises Public Key Infrastructure (PKI) solution, deeply integrated with Active Directory. It enables organizations to issue and manage digital certificates for encryption, code signing, and authentication of users and machines. While AD CS enhances security when properly configured, it has flown under the radar of many security audits (posts.specterops.io). Unfortunately, misconfigurations in AD CS can provide attackers with “privilege escalation as a service” (abrictosecurity.com). In recent years, security researchers (notably SpecterOps in their Certified Pre-Owned research) have identified a series of AD CS misconfiguration-based escalation techniques, labeled ESC1 through ESC8 (labs.lares.com). These allow a low-privileged adversary to escalate privileges to Domain Admin, often with shocking ease, or to establish stealthy persistence by abusing certificates.

This article provides a comprehensive deep dive into how AD CS can be abused by attackers, covering each major escalation vector (ESC1–ESC8) and real-world attack chains. We will explore how red team tools like Certify, Certipy, ForgeCert, and PowerShell-based techniques are used to exploit AD CS, with step-by-step examples (e.g., abusing vulnerable certificate templates, NTLM relay attacks to AD CS, and forging “golden certificates”). Finally, we present defense strategies for blue teamers and CISOs – including hardening guidance, logging/monitoring of certificate services, and mitigations to detect or prevent these attacks.

AD CS Overview and Authentication Role

Active Directory Certificate Services is an optional AD role that acts as a Certificate Authority (CA) for the domain. It issues X.509 certificates to users and computers, binding their identity to a public key. These certificates can then be used for authentication (e.g., smart card logons, mutual TLS, or Kerberos PKINIT), meaning a certificate can let a user access resources in Active Directory as that user (trustfoundry.net). In an AD CS deployment, administrators define certificate templates – rules that specify who can enroll for a certificate and what that certificate can do (validity period, allowed usages, subject name format, etc.) (beyondtrust.com). Domain integration means that if a CA’s certificate is trusted in AD (specifically, present in the NTAuthCertificates store), any certificate it issues with an appropriate Extended Key Usage (EKU) can be used to log into the domain as the identity on the certificate (medium.com, beyondtrust.com). This is powerful: if an attacker can obtain a valid certificate for a high-privilege account, they can authenticate as that account without knowing its password or touching its Kerberos keys.

Before diving into specific attacks, it’s important to note how AD CS authentication works. When a user or machine presents a certificate to Active Directory (for example, during a smart-card logon or Kerberos PKINIT), the domain controller verifies that: (a) the certificate was issued by a CA trusted for authentication (NTAuth), (b) the certificate is valid (not expired or revoked), and (c) the certificate’s subject corresponds to the account trying to log in (via mappings). AD CS allows two mapping methods: explicit mapping (linking a cert to an account via the account’s altSecurityIdentities attribute) or implicit/UPN mapping (where the certificate’s Subject Alternative Name contains the user’s UPN or other identifier) (nccgroup.com). Many AD CS attacks involve tricking the CA into issuing a certificate that claims to belong to a privileged account (e.g., Administrator) while being requested by an attacker. If successful, the attacker gets an authentication-capable cert for that account and can use it to impersonate them.

In short, an AD CS compromise can let an attacker bypass typical authentication controls. They no longer need passwords or hashes; a certificate is enough to assume another’s identity. As we’ll see, misconfigurations in templates or CA settings can make such abuse trivial. Even a fresh Domain Admin password or enabled LAPS can’t stop an attacker wielding a valid cert, and certificates can remain valid for years. This makes AD CS a juicy target for both escalation and persistence.

Misconfigurations and Attack Vectors (ESC1 – ESC8)

AD CS itself is not “vulnerable” by default, but it’s surprisingly easy for admins to misconfigure. In the SpecterOps study, eight common misconfiguration scenarios (ESC1–ESC8) were identified that allow domain escalation (posts.specterops.io). We will explain each of these escalation vectors, along with how an attacker exploits them and example commands using real tools. These are not the only AD CS abuses, but they represent the most prevalent and dangerous.

ESC1: Misconfigured Certificate Template (Supply SAN)

ESC1 (Enterprise Security Certificate 1) refers to a certificate template misconfiguration that lets a low-privileged user obtain a cert for a different, highly privileged account (abrictosecurity.com). In essence, the template permits the requester to specify the certificate’s subject alternate name (SAN), allowing impersonation, and the cert has appropriate EKUs to be used for logon. Several conditions typically align for ESC1 (posts.specterops.io):

• “Enrollee supplies subject” is enabled on the template, meaning the requester can supply a Subject Alternative Name (e.g., UPN) when requesting a cert
• The template has an authentication EKU such as Client Authentication (OID 1.3.6.1.5.5.7.3.2) or Smartcard Logon (OID 1.3.6.1.4.1.311.20.2.2)
• Low-privileged users have Enroll permissions on the template
• No additional issuance requirements like manager approval or authorized signatures are in place (or they can be bypassed)

If all the above are true, an attacker with any valid domain user account can abuse ESC1 to impersonate another user (e.g. a Domain Admin). The attacker requests a certificate from the CA using the vulnerable template, but in the request they specify the SAN (UPN) of a target account (say Administrator@domain.local). The CA, seeing that the template allows it and the requester is authorized to enroll, will issue a certificate for Administrator and hand it to the low-priv user (posts.specterops.io, abrictosecurity.com). Now, the attacker holds a valid Administrator certificate, which can be used to authenticate as that admin user (abrictosecurity.com). The real Administrator isn’t notified, and even if the admin’s password is changed, the certificate remains valid until it expires (often years) (abrictosecurity.com).

Exploitation – ESC1: To find such vulnerable templates, attackers use tools to enumerate AD CS. For example, the Certify tool can query AD for certificate templates and identify those that have the dangerous settings. Running Certify.exe find /vulnerable will list templates that appear misconfigured (supply-in-request flag set, client auth EKU, etc.) (ired.team). The output might show something like: Template=UserTemplate, EKU=Client Authentication, Enrollable by Domain Users, CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT = True, indicating an ESC1 candidate. Another tool, Certipy, can do similarly: for instance, certipy find -vulnerable -u 'user@domain' -p 'Password' -dc-ip <DC-IP> will list vulnerable templates and CAs (medium.com).

Once a vulnerable template is found, the attacker requests a cert for a target account. Using Certify as an example:

# Using Certify to request a certificate as Administrator via vulnerable template

Certify.exe request /ca:<CA_SERVER>\<CA_NAME> /template:<VulnTemplateName> /altname:Administrator        

This command contacts the CA and requests a cert based on <VulnTemplateName>, but tells the CA “I am requesting on behalf of Administrator” (the /altname param) (ired.team). If the template doesn’t require additional approval, the CA promptly issues the certificate. Certify will output the certificate in PEM format (containing the new cert and private key) (ired.team). At this point, the attacker has essentially “minted” Domain Admin credentials out of thin air.

Using the stolen certificate: The issued cert can be converted to a PFX and then used to authenticate. For instance, the attacker can convert PEM to PFX with OpenSSL:

openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out admin_cert.pfx -passout pass:changeit        

Now, the attacker can use a tool like Rubeus to perform a Kerberos PKINIT with this certificate and obtain a TGT for the Administrator account:

# Using Rubeus to get a Kerberos TGT using the forged certificate 

Rubeus.exe asktgt /user:Administrator /certificate:admin_cert.pfx /password:changeit /ptt        

The /ptt will inject the obtained ticket into the current session (ired.team), so the attacker now is the Administrator on the network. From here, they could, for example, access the Domain Controller’s C$ share or run DCSync – confirming full Domain Admin compromise (ired.team).

Real-World Example: In one real engagement, a pentester compromised a service account that was a regular domain user. A quick Certify scan showed a template named “DesktopLogin” was vulnerable to ESC1. Any domain user could enroll, it had Client Authentication EKU, and “Supply in Request” was enabled. The pentester issued a cert for the Domain Admin account. Within seconds, they leveraged that cert to obtain a Kerberos ticket and list the Domain Admin’s group memberships and files on the DC – a clean privilege escalation with no exploitation of traditional vulnerabilities. The misconfigured template had been created years ago for a pilot project and forgotten, illustrating how one misconfigured certificate template can undermine an entire domain.

ESC2: Weak Template EKUs (Any Purpose / No EKU)

ESC2 is closely related to ESC1 – it also involves misconfigured templates – but specifically templates that have overly permissive or absent EKUs. In ESC2, a low-privileged user can enroll in a template that grants a certificate with “Any Purpose” EKU or no EKU at all (which essentially means it can be a subordinate CA cert) (posts.specterops.io). The conditions are similar to ESC1 (unprivileged enrollment, no special issuance requirements) (posts.specterops.io) except, the template might not allow custom SAN. So, the attacker cannot specify someone else’s identity here. However, certificates issued from an ESC2 template can still be dangerous:

• An Any Purpose EKU (OID 2.5.29.37.0) means the cert can be used for any usage, including client auth

In practice, ESC2 templates alone (without supply-in-request) don’t let you impersonate a different user immediately. But they do yield a cert that authenticates the user who requested it, which could still be useful to an attacker (e.g., if that user account has some privileges in another context, or to bypass MFA for their own account). Also, an Any Purpose cert can potentially be combined with other issues or used to sign code or emails maliciously. The key takeaway: administrators sometimes configure templates with very broad EKUs (or as subordinate CAs) for flexibility, not realizing any domain user might be able to enroll and get a highly privileged certificate type (posts.specterops.io).

For an attacker, ESC2 is enumerated similarly (Certify will flag “Any Purpose” templates as potentially risky (posts.specterops.io). The exploitation (enrollment) is straightforward, but since it doesn’t allow direct impersonation, we won’t dwell on a step-by-step. Instead, an attacker might use an Any Purpose cert they obtained in creative ways, or simply note that the environment is one step away from ESC1 (just missing the supply-in-request flag). Often, ESC2 is a policy violation waiting to become an actual vulnerability – many organizations have templates that technically allow dangerous certs to be issued, but require an extra misconfig to fully abuse. Best practice is to avoid Any Purpose templates or at least restrict who can enroll in them (posts.specterops.io).

ESC3: Enrollment Agent (Certificate Request Agent Misuse)

ESC3 involves abusing Enrollment Agent certificate templates. An Enrollment Agent (EA) is a special certificate type that grants the bearer the ability to request certificates on behalf of other users (acting as a proxy requester). It’s an intended feature for scenarios like a helpdesk officer enrolling smartcard certs for users. However, if an Enrollment Agent template is misconfigured to be enrollable by regular users, an attacker can obtain an EA cert and then sign certificate requests for any user, effectively impersonating them (posts.specterops.io).

The conditions for ESC3 are similar to ESC1 (unprivileged enrollment, no manager approval, etc) (posts.specterops.io) plus:

• The template’s EKU includes Certificate Request Agent (OID 1.3.6.1.4.1.311.20.2.1)
• The CA does not have Enrollment Agent Restrictions configured to limit what an EA can do

If a low-priv user can get an Enrollment Agent certificate (via a misconfigured template), they can then craft a request for, say, a Domain Admin using any template that doesn’t outright forbid it. Notably, any “Version 1” template (default built-in templates in Windows 2000 era) can be requested by an EA without extra requirements (posts.specterops.io). Many domains still have Version 1 templates like the default “User” and “Computer” published. These usually allow client authentication and are vulnerable targets for an EA abuse (posts.specterops.io). So an attacker with an EA cert can co-sign a request for a “User” certificate for the Administrator account, and the CA will issue it (because the EA’s signature satisfies the need for an authorized request) (posts.specterops.io). This is another path to the same outcome – a cert for a privileged account.

Exploitation – ESC3: The attacker’s first step is to get the Enrollment Agent certificate. Tools like Certipy or Certify will identify templates with the Certificate Request Agent EKU. For example, Certipy might list a template “EnrollmentAgent” as vulnerable. The attacker enrolls for that template (similar to ESC1 steps, but no alt name needed – they’re getting a cert for themselves as an agent). Once they have their Enrollment Agent cert, they can use certutil or Certipy to perform agent signing. Certipy has an authorize or request feature where you can supply an /on-behalf-of parameter with the target user. Another approach is using the built-in certreq tool: create a CSR for the target user and sign it with the Enrollment Agent cert.

To illustrate conceptually: after obtaining EA cert, an attacker could do:

# Using certreq with an Enrollment Agent cert to request a cert for Administrator

certreq -submit -config "<CA_SERVER>\<CA_NAME>" -attrib "CertificateTemplate:User" -signedby EA_cert.pfx Administrator.csr        

(This is pseudo-syntax; actual usage of certreq for EA involves more steps.) The result is the CA issues a User certificate for Administrator, because it was requested by a valid Enrollment Agent. From there, the attacker uses the issued cert as in ESC1.

In summary, ESC3 is a two-step compromise: get an enrollment agent cert, then use it to get any other cert. It’s a bit less direct than ESC1, but if admins have carelessly allowed users to enroll in an EA template, it’s game over. In real environments, this might happen if someone duplicated the default Enrollment Agent template and forgot to restrict Enroll permissions to a small group. The SpecterOps team noted EA abuse is complex due to various issuance rules, but extremely powerful (posts.specterops.io). They’ve seen cases where EA templates were published and unwittingly exploitable.

ESC4: Vulnerable Certificate Template Access Control

Where ESC1-3 assumed the template settings themselves were insecure, ESC4 is about the template’s Access Control. Certificate templates are AD objects, and like any object they have an ACL controlling who can read or modify them. ESC4 is when an unprivileged user has been granted (or can gain) permission to edit a certificate template’s settings (posts.specterops.io). This is often a result of overly broad delegation – e.g., all Authenticated Users given modify rights on a template or a helpdesk group given rights, but that group was compromised. If an attacker can modify a template that was not otherwise vulnerable, they can make it vulnerable.

For instance, suppose there’s a template that only Domain Admins can enroll in or that doesn’t allow supply-in-request. If an attacker can edit that template, they could change its ACL to allow enrollment by Domain Users, and enable the “supply in request” flag (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) on it (posts.specterops.io). In effect, the attacker turns it into an ESC1 template (medium.com). They could also add an EKU like Client Authentication if it wasn’t present. After making these changes, the attacker can enroll for a cert on that template as described before, impersonating a privileged account (medium.com, medium.com). This is a two-step attack: first get control of the template, then request cert.

Another ESC4 scenario is if multiple templates exist and one template’s permissions allow a low-priv user to write another template’s properties (this would be a weird ACL inheritance case, but AD is full of odd ACL inheritance). More straightforward is the attacker having write access on one specific template.

Exploitation – ESC4: The attacker first identifies templates where they have edit rights. Tools like BloodHound (with the PKI 2.2 update) can highlight ADCS object ACLs, including a path like User -> WriteProperty -> Template (BloodHound has “ADCSESC4” indicators for principals that can modify templates) (medium.com). Alternatively, Certify’s/template command or Certipy’stemplate module can be used to manually edit template settings. In fact, Certipy has an automated exploit: certipy template with -save-old will backup a template’s current config and then flip the settings needed to make it an ESC1 scenario (medium.com). For example:

# Using Certipy to convert a safe template into a vulnerable one (ESC4 exploit) 

certipy template -u user@domain -p Password123 -ca CA_NAME -template "SecureUser" -enable-enrollee-supplies-subject -add-eku 1.3.6.1.5.5.7.3.2 -save-old        

(The above command is illustrative – Certipy’s actual flags allow enabling the SAN flag and adding EKUs as needed.) The key is that the attacker, having rights, enables Supply in Request and an auth EKU on “SecureUser” template, which previously might have been locked down. Certipy then allows them to request a cert via the now-vulnerable template in one go (medium.com).

This attack chain was seen in a “shadow admin” scenario: a user account had been delegated permissions to edit certain certificate templates (perhaps a PKI admin left the company and their account got compromised). The attacker modified a template that only allowed Domain Admin enrollment, opening it to everyone. They then enrolled a cert for a Domain Admin via that template and regained full privileges. The defenders were confused because the template itself looked normal at first (it was intended for Domain Admins), but logs showed it was briefly edited to weaken it – that was the attacker’s doing.

Mitigation for ESC4 is straightforward: ensure certificate template ACLs are strict. Only designated PKI admins should have rights like Write or Full Control on template objects (posts.specterops.io, posts.specterops.io). Regular users should never be able to modify template settings. We’ll discuss detection (monitoring for template changes) in the defense section.

ESC5: Misconfigured PKI Object Access (Other PKI Infrastructure Abuse)

ESC5 is a broad category covering other AD objects in the PKI infrastructure that, if poorly secured, can lead to compromise. AD CS’s integration with AD means there are multiple objects in the Configuration partition under CN=Public Key Services, CN=Services, CN=Configuration, DC=<domain> that control how PKI operates. Examples include: the Certificate Templates container itself, the Certification Authorities container (holding CA objects), the Enrollment Services container (also CA info), and the NTAuthCertificates object (which stores which CAs are trusted for authentication). Even the CA server’s computer object in AD can matter.

If an attacker can modify any of these critical objects, they may subvert AD CS security. For instance:

• Trusting a rogue CA (NTAuthCertificates): An attacker with rights to modify the NTAuthCertificates object could add their own malicious root CA certificate to it. This would tell the domain to trust that CA for logons. The attacker could then issue themselves a cert for Administrator from their rogue CA and log in as Administrator – effectively a backdoor trust. (This is not trivial, as it requires writing a multi-valued attribute, but it’s a known risk
• Adding a new CA: If an attacker can create a new object under the Certification Authorities container, they might convince AD that a new Enterprise CA exists (though the actual issuance would require more steps).
• Modifying CA security: The Enrollment Services container holds entries for each CA. If the attacker can alter those (or the templates container ACL globally), they might elevate privileges.
• CA Machine account abuse: If the CA runs on a domain member server (often it does), the CA’s computer account might have privileges on the certificates it issues. An attacker with control of the CA’s computer account (say through resource-based constrained delegation or SPN configuration, as hinted by S4U2Proxy/S4U2Self mention

In short, ESC5 is about any other ACL that grants control over PKI-related objects. It’s a bit of a catch-all: “If a low-privileged attacker can gain control over any of these [PKI objects], the attack can likely compromise the PKI system.” We won’t go into exhaustive detail, as this gets into AD internals. However, one example is a known privilege: the user “Certificate Publishers” group can write userCertificate attribute on user objects. If misused, one could add a certificate to a privileged user’s account and use it if strong mapping isn’t enforced (this edges into ESC9/ESC11 territory, beyond our current scope).

Administrators should treat the entire Public Key Services container as sensitive and ensure only PKI admins can modify it. Tools like ADSI Edit or scripts can be used to audit the ACLs on these objects. An attacker typically will look for any mispermission via LDAP queries or BloodHound’s built-in PKI ACL knowledge.

ESC6: CA Flag EDITF_ATTRIBUTESUBJECTALTNAME2 (Another way to supply SAN)

ESC6 is a sneaky configuration issue on the CA server itself. It exploits a flag called EDITF_ATTRIBUTESUBJECTALTNAME2 which, if enabled on the CA, allows requesters to supply a Subject Alternative Name via request attributes, even if the template doesn’t normally allow it (posts.specterops.io). In other words, ESC6 is like a backdoor way to do what ESC1 does, but by abusing the CA’s setting rather than the template’s.

Microsoft’s documentation states: “If this flag is set on the CA, any request (including when the subject is built from Active Directory) can have user-defined values in the subject alternative name.” (posts.specterops.io). Many admins flip this flag on because “it just makes it work” for certain certificate requests (posts.specterops.io) – for example, they had trouble getting a SAN in a cert, and found enabling this registry flag on the CA solves it, not realizing the security impact. With EDITF_ATTRIBUTESUBJECTALTNAME2 enabled, any template that a low-priv user can enroll in becomes potentially exploitable to impersonate others (posts.specterops.io, posts.specterops.io). For example, the default User template (which many CAs have and which Domain Users can enroll for by default) normally doesn’t allow specifying SAN. But if the CA has ESC6 flag enabled, an attacker can submit a crafted request to the User template with a SAN attribute for a domain admin UPN – and the CA will honor it, issuing an “User” certificate for that admin (posts.specterops.io). Essentially, ESC6 lets you do ESC1 against a non-ESC1 template.

Exploitation – ESC6: Unlike previous attacks which abuse LDAP/AD settings, this is purely a CA-side registry setting. Attackers first need to detect if the flag is on. This can be done remotely: certutil -config "<CA_HOST>\<CA_NAME>" -getreg policy\EditFlags returns the CA’s edit flags (if remote registry is allowed). Tools like Certify also attempt to check this for each CA during enumeration. If found enabled, the attacker proceeds to request a cert via any enrollable template that has an authentication EKU. The trick is to include the SAN: attribute in the request. This can be done using certreq with an INF file or using OpenSSL to create a CSR with a custom extension. For example, using certreq one might prepare an INF like:

[NewRequest] Subject="CN=Attacker" Attributes="SAN:upn=Administrator@DOMAIN.LOCAL" CertificateTemplate=User        

Then run certreq -new request.inf request.req and certreq -submit -config "<CA>" request.req. The CA will issue a cert for “Administrator@DOMAIN.LOCAL” under the User template. Certipy might also automate this (e.g. certipy req -template User -upn administrator@domain.local ... will likely work if ESC6 is in effect, even if the template isn’t marked supply-in-request).

From there, the attack is identical to ESC1: the attacker obtains an admin cert and uses it to authenticate. The only difference is that the poor admin who configured the CA this way might be scratching their head because they never enabled “supply in request” on any template – the CA itself overrode the restriction.

Mitigation: The obvious fix is don’t enable this flag unless absolutely needed. If it must be on, treat all templates that allow user enrollment as if they were ESC1-vulnerable, because they are. Microsoft’s guidance is to leave EDITF_ATTRIBUTESUBJECTALTNAME2 off; use template settings for SAN control instead. We’ll also note in ESC7 how an attacker with certain CA permissions could enable this flag themselves – another reason to secure access to the CA.

ESC7: Vulnerable CA Permissions (ManageCA / ManageCertificates)

Active Directory CAs have their own access control (separate from template ACLs). In the Certification Authority management console, there are roles like CA Administrator and Certificate Manager, which correspond to permissions such as ManageCA and ManageCertificates on the CA object (posts.specterops.io, nccgroup.com). ESC7 is when an attacker obtains one of these high-impact CA permissions without being a full administrator. If, for example, a Domain User was delegated as a “CA Manager” for some reason, an attacker compromising that account can effectively reconfigure the CA.

• ManageCA permission (CA Admin) lets you perform most CA configurations, including setting registry flags like EDITF_ATTRIBUTESUBJECTALTNAME2
• ManageCertificates permission (Certificate Manager) allows approving or denying pending cert requests

To exploit ESC7, the attacker first has to have those permissions. This could happen if the CA’s ACL was misconfigured, or if the attacker compromised a user/group that was given those rights (sometimes orgs delegate certificate manager roles to certain teams). If a low-priv user finds themselves with ManageCA on a CA, it’s basically done – they can directly issue a cert for any user by temporarily enabling the SAN flag or altering template ACL via the CA’s authority. One could argue that having ManageCA itself is already a privileged position, but many wouldn’t realize it equates to domain escalation.

Exploitation – ESC7: Using built-in tools, a user with ManageCA could run PowerShell with the PSPKI module (a PowerShell PKI toolkit) to set flags. For example: Enable-PolicyModuleFlag -Name "EDITF_ATTRIBUTESUBJECTALTNAME2" using the PSPKI module (this is how one would programmatically set that flag) (posts.specterops.io). Or they could use the certsrv.msc GUI to change settings. Certify might allow abuse of this via an offensive command, but typically at that point the user has so much control that simpler methods suffice. Once the flag is enabled, it’s essentially ESC6. If they didn’t want to do that, as ManageCA they could also directly issue a certificate via the CA’s interface impersonating someone (though issuing a cert still goes through the templates).

For ManageCertificates, an attacker could submit a cert request that gets held for approval (if the template had “manager approval required”). Then, using certsrv.msc or certutil, approve their own request. This scenario is less common because few templates use that setting, and if attacker can enroll anyway it might not be needed. But it’s a method to bypass one layer of defense.

Bottom line: If an attacker gets any administrative permission on the CA, they can likely escalate to domain admin. This is why the CA should be treated as a Tier 0 asset – compromising it means compromising the domain. Even Microsoft acknowledged in their AD CS hardening that these settings are critical to secure (nccgroup.com, nccgroup.com).

ESC8: NTLM Relay to AD CS HTTP Endpoints

ESC8 is a very different beast: it’s about network-level attacks rather than AD object misconfigs. Many AD CS deployments have optional web services enabled, like the Certificate Authority Web Enrollment pages (e.g. http://<CA_Server>/certsrv/...) or the Certificate Enrollment Web Service (CES) / Network Device Enrollment Service (NDES). These services often accept Windows authentication (NTLM) and, crucially, are not always configured to require channel binding or signing. This makes them vulnerable to NTLM relay attacks (posts.specterops.io, nccgroup.com). In 2021, a technique dubbed “PetitPotam” was published that showed how to force a Windows host (like a Domain Controller) to authenticate via NTLM to another machine, which could then relay that to a target service – in that case, the target was an AD CS HTTP endpoint to obtain a certificate.

In plain terms, ESC8 allows an attacker with no credentials (or just network access) to trick a high-privilege machine into giving them a certificate. The attack chain is typically:

1. Coerce a high-value machine to authenticate to you: Using a method like PetitPotam (which exploits the MS-EFSRPC interface), the attacker causes, say, the Domain Controller or another server to initiate an NTLM authentication to the attacker’s rogue server
2. Relay that NTLM auth to the AD CS web endpoint: The attacker’s tool captures the NTLM handshake and forwards it to the CA’s HTTP interface. Since the CA web enrollment might accept NTLM, it believes the DC (or whatever machine/user) is authenticating to it
3. Request a certificate for the relayed identity: The attacker, now authenticated to the CA as the DC’s machine account (or whichever account was coerced), submits a certificate request. If the web endpoint is the simple web enrollment (certsrv), the attacker can automate a request for a certificate based on a template like Machine or DomainController. By default, the built-in Machine certificate template is often enabled for enrollment by Authenticated Users (or at least by the machine itself), and it has Client Authentication EKU
4. Use the issued certificate to escalate privileges: With a Domain Controller’s certificate in hand, the attacker can now authenticate as that DC. One terrifying outcome is the attacker uses the DC’s cert to perform a DCSync (using something like Mimikatz or certipy’s auth module to do an LDAP bind as DC). This yields the krbtgt hash or other credentials – effectively Domain Admin or Domain compromise right there.

All of the above can happen very fast and without any user credentials on the attacker’s side, which is why PetitPotam+ADCS was a big deal. Microsoft released advisories (KB5005413) on mitigating this (primarily by requiring Extended Protection for Authentication and disabling NTLM on the enrollment services) (kb.cert.org, success.trendmicro.com).

Exploitation – ESC8: Let’s illustrate the steps with actual tools:

• The attacker runs Responder or PetitPotam to generate an NTLM authentication from the target. PetitPotam, for example, can be directed at the Domain Controller’s LSARPC service to make it connect to an arbitrary host.
• The attacker sets up Impacket’s ntlmrelayx to listen for an incoming SMB/HTTP connection and relay it to the CA. A typical command might be:
• The attacker triggers PetitPotam against the DC. The DC attempts to authenticate to the attacker, and ntlmrelayx intercepts this and relays to the CA site. The CA thinks the DC is requesting a certificate. The request is made for the Machine template (or DomainController template – that’s another option if the DC’s machine account is allowed that template)
• Ntlmrelayx saves the certificate (and key) to disk (in newer versions, it outputs something like a DC.pfx). The attacker now loads this certificate. Using Certipy’s auth module or even a tool like CrackMapExec, the attacker can test access. For example, Certipy has:

certipy auth -pfx DC.pfx -dc-ip <DC-IP>        

This would authenticate as the DC computer account. With that context, the attacker can perform an LDAP query to replicate user credentials (DCSync) or open an SMB session to the DC’s IPC$ with administrative rights (since DC’s machine account is essentially a domain admin equivalent).

In one demonstration, this exact attack chain was used to go from no access to Domain Admin in minutes. The combination of a default-enabled web service (which often doesn’t force HTTPS or require any special auth) and an NTLM coercion vulnerability made AD CS a lightning rod for attackers (nccgroup.com, nccgroup.com).

Conditions for ESC8 are: the CA has Web Enrollment or similar HTTP service enabled and it does not require SSL or EPA (Extended Protection) (nccgroup.com). By default, the web enrollment does allow HTTP and NTLM, so many installs were at risk prior to PetitPotam’s publicity.

Domain Persistence with Golden Certificates (Beyond ESC8)

In addition to the ESC1–ESC8 escalation vectors, attackers can leverage AD CS for persistence in a way analogous to Kerberos Golden Tickets. If an attacker fully compromises a CA (or is able to steal the CA’s private key), they can forge certificates at will for any user – we can call this a “Golden Certificate” scenario (thehacker.recipes). The term “Golden Certificate” is used because, like a Golden Ticket (forged Kerberos TGT), a forged CA-signed certificate can grant the attacker long-term access as any identity.

Golden Certificate via CA compromise: Once an attacker is Domain Admin, they often target the CA server to cement their control. The CA’s private key is typically stored on the server (encrypted by DPAPI if not using an HSM). Tools like Mimikatz or dedicated scripts can extract this “stolen CA cert + key” (github.com). SpecterOps released ForgeCert for this purpose: given the CA’s cert and key (in PFX format), ForgeCert can create arbitrary certs for any user github.com. This is labeled DPERSIST1 (Domain Persistence 1) in their paper (github.com).

Using ForgeCert is straightforward. Suppose the attacker has ca.pfx (the CA cert and key) and its password. They decide to forge a cert for a new user “mallory” with Domain Admin rights. They can create a cert with a SAN of an existing DA or even create a fake user that doesn’t exist in AD (if they later map it). Usually it’s easier to forge for an existing account or one they control. Example command:

ForgeCert.exe --CaCertPath ca.pfx --CaCertPassword "CApass123" \ --Subject "CN=Mallory" --SubjectAltName "Mallory@domain.local" \ --NewCertPath mallory.pfx --NewCertPassword "Certpass123"        

This will output mallory.pfx, a certificate signed by the trusted CA for user Mallory’s identity (github.com). If Mallory is an AD account, that cert can authenticate as Mallory. If Mallory wasn’t an AD user, no direct effect unless mapping is done – so typically the attacker would forge for a real account or one they create.

The potency here is that the attacker can now maintain access indefinitely. Even if incident response changes all passwords, if they don’t remove or invalidate the CA, the attacker can simply mint a new certificate for a domain admin again. It’s like having the master key to the kingdom. Detecting a forged cert used is very difficult if the CA is legitimately trusted.

Another persistent method is to abuse long-lived certificates that were issued during exploitation. For example, a cert obtained via ESC1 or ESC8 might be valid for years. Attackers can safely stash those and return later. Blue teams must remember to revoke any compromised certs and perhaps shorten their validity or require re-enrollment to limit this risk.

Red Team Tools and Techniques for AD CS Attacks

Attackers (and penetration testers) have developed several tools to automate AD CS abuse. We’ve mentioned a few already. Here we summarize the prominent ones and how they are used:

• Certify (GhostPack) – A C# tool released by SpecterOps as part of their research
• Certipy (by Oliver Lyak, Python) – A Python port of Certify’s functionality, plus additional features
• ForgeCert (GhostPack) – Mentioned above, ForgeCert is an offensive tool for post-compromise. It assumes you have already stolen a CA’s private key (which likely requires Domain Admin or local admin on the CA server). ForgeCert uses the BouncyCastle library to create new certificates signed by that CA
• PSPKIAudit & PowerShell – The SpecterOps research also produced PSPKIAudit
• Impacket’s tools (ntlmrelayx) – For the NTLM relay scenario, Impacket’s ntlmrelayx.py with the --adcs flag was a game-changer because it automated requesting a certificate upon a successful relay

In summary, the tooling around AD CS attacks has matured: what used to be a complex, niche attack is now accessible via user-friendly commands. Red teamers should familiarize themselves with these tools as they open up new lateral movement and priv-esc paths that bypass traditional defenses (no need for Mimikatz to grab creds if you can mint creds!). Blue teamers likewise should use some of these in audit mode (e.g., run Certipy find -vulnerable in your domain regularly) to catch misconfigs before attackers do (reddit.com).

Defense Strategies and Mitigations

AD CS may be an esoteric component, but defending against these attacks is crucial. A compromise via AD CS is often high impact and stealthy, so prevention and detection must be addressed. We break defense into configuration hardening, credential/use management, and monitoring/detection.

1. Secure Configuration of AD CS

Harden Certificate Templates: Review all certificate templates in the environment:

• Eliminate vulnerable settings: Disable “Supply in Request” for subject names on templates that don’t absolutely require it
• Restrict enrollment permissions: Only specific groups or users that need a given certificate should have Enroll (and/or AutoEnroll) permissions. Never give Domain Users or Authenticated Users enroll on a template that has any powerful EKU. Use dedicated groups for enrollment. For example, if developers need code signing certs, create a group for them and only give that group enroll on the CodeSigning template.
• Limit EKUs: Do not use “Any Purpose” EKU on templates if it’s not necessary. Be explicit with EKUs. If a template is for email encryption, don’t include Client Authentication EKU by default. Avoid templates that issue subordinate CA certs unless absolutely required (and again, restrict who can request those).
• Use manager approval or authorization where appropriate: For extremely sensitive templates, enabling “Manager approval” can add a roadblock (though as noted, an attacker with ManageCert can bypass, but that’s a higher bar). Also consider authorized signature requirements – e.g., require that any enrollment in a high-priv template be co-signed by an Enrollment Agent held by a PKI admin. This is not widely used but is a potential mitigation for misuse.

Harden CA Server and Roles:

• Lock down CA permissions (ESC7): Ensure that only designated PKI admin accounts have the ManageCA/ManageCertificates permissions on the CA
• Disable or secure HTTP endpoints (ESC8): If you do not need the web enrollment or NDES services, do not install them. Many enterprises function fine with just the RPC-based enrollment. Every additional service is extra attack surface. If you do need them (for network devices or user web enrollment), require HTTPS and Extended Protection for Authentication (EPA)
• SAN flag (ESC6): Ensure EDITF_ATTRIBUTESUBJECTALTNAME2 is not enabled on CAs unless absolutely needed. Most organizations should turn this off. If some application needed it, consider the security implications carefully and find alternatives. If it must be on, audit all templates that allow enrollment to low-priv users because they are effectively ESC1 now.
• Enrollment Agent restrictions (ESC3): If you use Enrollment Agents in your org (smartcard provisioning, etc.), configure Enrollment Agent Restrictions on the CA. This allows you to specify which accounts an EA can enroll for, and on which templates
• CA in Offline Root / Tiered model: Follow best practices of a two-tier PKI: an offline root CA (highly secured, not domain joined) and an online subordinate issuing CA. The root CA’s key is kept offline so it can’t be stolen from the network. The issuing CA (which is domain joined) should be treated as critical; if compromised, you at least can revoke its cert via the root and not trust it anymore. Having a root CA that is separate can limit the blast radius if the issuing CA is owned – you’d still likely need to rebuild PKI, but an attacker can’t directly forge a new chain without also compromising the offline root.

Clean up & tighten AD CS objects (ESC5):

• Audit the ACLs on CN=Public Key Services and its children. Remove any unnecessary permissions. Only Enterprise Admins (and maybe PKI admins) should have full control there.
• Check the NTAuthCertificates object – it should only contain legitimate CA certs. If you find unknown certificates in there, investigate and remove them if malicious. Consider enabling Strong Certificate Mapping (set StrongCertificateBindingEnforcement registry on DCs to 2 for strict mapping) so that even if an attacker adds a rogue CA, they would need the proper certificate mappings to use it
• Remove or archive old/unneeded certificate templates. Sometimes domains have templates from old projects that no one uses but have dangerous rights. If it’s not needed, delete or disable it (templates can be marked as not available for issuance). This reduces the attack surface.

2. Monitoring and Detection

Even with good configuration, assume determined attackers might find a gap. Thus, monitoring AD CS activity is vital. There are several key areas to enable logging:

Enable CA Auditing Logs: On the CA server, enable the Certification Services logs (if not on by default). The CA generates Windows Event Log entries for certificate requests and issuance. Particularly:

• Event ID 4886 – Certificate request submitted (pending)
• Event ID 4887 – Certificate issued (and to which template)
• Event ID 4890 – Certificate request denied.
• Event ID 4888 – Changes to CA configuration or security (when a CA setting or ACL is modified).
• Event ID 4897/4898 – Changes to certificate templates (if done via the CA interface).

By aggregating these events to a SIEM, you can look for suspicious patterns. For example, as BeyondTrust suggests, an alert when the requester and the subject name don’t match in an issuance event (beyondtrust.com) is a strong indicator of ESC1 abuse. If you see Event 4887, where RequesterName is LOWPRIVUSER and Subject or SAN contains ADMINISTRATOR, that’s a red flag (beyondtrust.com).

. Normally, those should match (the person getting a cert is themselves). This detection helped some organizations catch attacks in action.

Also, monitor 4888 events – if someone enabled the EditFlags SAN flag or changed template settings, you’d likely see something. Combine with Sysmon or Security logs on the CA server for process execution (if an attacker ran certutil or Certify on the CA server, that could show up).

Domain Controller Logs for Certificate Logon: When a certificate is used to authenticate to AD (Kerberos PKINIT or Schannel), it can produce logs:

• Kerberos TGT request Event ID 4768 on the DC will show if Certificate was used for pre-auth instead of a password. There’s a field that might say “Certificate Information” when a cert was used. If an account that doesn’t normally use smartcard suddenly does, investigate.
• Event ID 4771 (Kerberos pre-auth failed) might show certificate failures if an attacker tried a wrong cert.
• If smartcard logon is used (which is one way these certs might be used), you could see interactive logon events (4624) with Logon Type = 2 and “Authentication Package: Kerberos” but the Key Distribution Center events are more direct.

Also, the CA will sometimes publish issued certs to AD user objects (in the userCertificate attribute) if configured. If you have tooling to track changes in AD, see if a highly privileged account’s userCertificate attribute was modified unexpectedly (that could indicate a cert was issued to it). Not all deployments auto-publish user certificates to AD, though.

Network Monitoring for NTLM relay attempts: PetitPotam and related attacks might generate specific patterns. For example, if you see SMB connections from a DC to an unexpected host on LSARPC (endpoint mapper calls) followed by that host connecting to your CA web server, that’s suspicious. IDS rules exist for PetitPotam behavior. Also monitor your CA’s HTTP logs – any anonymous or NTLM requests to certsrv/certfnsh.asp from internal hosts that aren’t user-driven could indicate a relay (especially if the User-Agent is unusual or it occurs at odd times). Microsoft’s mitigations essentially suggest to “monitor for NTLM usage to the CA” and treat any such usage as potentially malicious (rapid7.com).

Auditing AD Object Changes: Enable the “Directory Service Changes” auditing category on your domain. This will log events (like 5136) when certain objects are modified. Specifically, watch for modifications to:

• Certificate Templates (class pKICertificateTemplate) – changes to attributes like flags or security descriptor.

• PKI containers – e.g., if someone adds a value to NTAuthCertificates or creates a new object under Enrollment Services.
• altSecurityIdentities on user accounts (if attackers try mapping a cert to an admin account explicitly, which is another possible attack not detailed here).

By monitoring these, you catch an attacker trying to set up persistence or stage an attack (like ESC4 changes a template’s flag – that’s an AD change event).

User Behavior and Anomaly Detection: Since certificate-based attacks might not trigger typical credential abuse alerts, incorporate them into your threat hunting:

• Look for accounts obtaining Ticket-Granting Tickets in abnormal ways. If you have advanced Kerberos logging or a SIEM, see if an account’s TGT was acquired via PKINIT (there might be an event or the absence of a preceding 4768 with normal pre-auth).
• Look for multiple certificate enrollments in a short period. E.g., a single user account requesting many certs or requesting a cert from an uncommon template could be a machine doing automated malicious enrollment.
• If possible, restrict and monitor membership of local groups like Cert Publishers and Account Operators – while not directly AD CS, those can indirectly be used to push certificates or move laterally.

3. Incident Response and Recovery Planning

Because AD CS attacks often yield persistence, organizations should have a plan specifically for certificate-based compromise. Traditional password resets are not enough if an attacker has a certificate for a user or the CA’s key:

• Certificate Revocation: Be ready to revoke any certificates that are known or suspected to be stolen/malicious. In an incident, identify all certs issued to the compromised accounts (the CA database or logs can help). Publish CRLs. Keep in mind, Windows might not check CRL for smartcard logon by default unless configured – so you may also have to remove compromised certs from the accounts (e.g., remove them from userCertificate attribute if present, or disable the account). Revoking the cert at CA is necessary but not always sufficient for immediate mitigation.
• CA compromise (Golden Certificate scenario): This is worst-case. If you believe the CA itself is compromised (e.g., private key stolen), you must assume the attacker can forge certs at will. The safest mitigation is to remove that CA from NTAuth trust and retire it. That might mean standing up a new CA (which is not trivial in a live environment). In some cases, changing the CA’s CA cert (renewing with new key) could invalidate the stolen key’s usefulness (because any cert they forge with the old key would chain to a now-untrusted root). However, if the root is same and only subCA was renewed, not foolproof. Microsoft’s guidance in such cases leans toward a full incident response process treating it similar to a domain compromise
• Triage: If an alert triggers (say you caught an Event 4887 mismatch or a weird DC activity), respond as if credentials were compromised. That might involve disabling the affected accounts, forcing re-enrollment of certs, etc. One tough part: if an attacker has a cert for Administrator, changing Administrator’s password won’t help – you’d need to revoke that cert or remove the CA trust. One extreme response is to temporarily disable AD CS (stop the CA service) – but that could disrupt legitimate services. Still, in an active attack, cutting off further certificate issuance might prevent the attacker from minting new certs while you clean up.

Defense-in-Depth: Finally, integrate AD CS into your broader security program:

• Ensure Tier separation: Regular users or even helpdesk personnel should not have direct access to manage the CA or templates at will. Use admin tier model.
• Apply the principle of least privilege to PKI admins. Maybe your PKI admin accounts should not be general Domain Admins (they just manage AD CS). Conversely, Domain Admins shouldn’t casually manage PKI unless needed – minimize chances their account could be abused for PKI changes.
• Regularly audit AD CS: Use tools like PSPKIAudit or even run Certify/Certipy in audit mode and fix any issues reported. Consider an annual or semi-annual PKI review as part of security assessments
• Keep software updated: Some AD CS related attacks and bugs get patched (for example, after PetitPotam, Microsoft provided options to harden). Stay aware of patches for AD CS and apply them.

By implementing these defensive measures, organizations can significantly reduce the risk of AD CS being the hidden crack in the armor. AD CS attacks often seem magical to those unfamiliar – “How did the attacker become Domain Admin without any password?” – but with the knowledge of these vectors (ESC1–ESC8) and proper vigilance, both red and blue teams can demystify and address this threat. Active Directory Certificate Services need no longer be the “silent killer” in AD security; it can be an asset rather than a liability when managed correctly.

TL;DR

AD CS is a powerful component of Active Directory that, if misconfigured, can become an attackers’ golden ticket to the kingdom. We explored how subtle oversights – like a wrong flag on a template or a web service left unconstrained – can lead to domain escalation via certificates. From impersonating admins with ESC1 to relaying NTLM for instant domain takeover in ESC8, the techniques are numerous and varied. Attack tools like Certify, Certipy, and ForgeCert have lowered the barrier for exploiting these weaknesses, turning AD CS attacks from theoretical to repeatable. Real-world breach scenarios show that attackers are actively looking for and exploiting these openings to elevate privileges or persist in networks (abrictosecurity.com, labs.lares.com).

On the defensive side, we stressed that prevention is key: secure your templates, restrict enrollment, harden or disable the CA web endpoints, and guard your CA like the critical infrastructure it is. At the same time, implement robust detection – the technology exists to catch unusual certificate issuance or usage if logs are collected and analyzed (e.g., a low-priv user requesting a cert for a Domain Admin will generate telltale events (beyondtrust.com). Blue teams should treat a suspicious certificate event with the same severity as an anomalous domain admin login or a Golden Ticket detection.

For CISOs and administrators, the takeaway is awareness: Include AD CS in your security assessments. Many organizations have mature processes for AD user account security, but PKI often falls into a blind spot. As we’ve shown, that blind spot can be fatal. Ensure policies are in place for PKI admin roles, certificate template management, and incident response involving certificates. Regularly review and test AD CS just as you would test AD Group Policy or privileged account controls.

Active Directory security is not just about passwords and Kerberos anymore – certificates are equally important credentials (beyondtrust.com). By understanding the attack vectors and applying the recommended defenses, enterprises can enjoy the benefits of AD CS’s PKI features without offering attackers an easy path to domain dominance. In the ongoing cat-and-mouse game between attackers (red teams) and defenders (blue teams), AD CS misconfigurations are a newer playing field – but one where informed defenders can now hold their ground. Stay vigilant, patch the holes, and monitor those certs – don’t let your domain become “Certified Pre-Owned” by an adversary!

Sources:

• Will Schroeder & Lee Christensen, Certified Pre-Owned: Abusing Active Directory Certificate Services (posts.specterops.io, posts.specterops.io) – SpecterOps research unveiling ESC1–ESC8 and tools (Certify, ForgeCert).
• Abricto Security, Domain Admin Utilizing ADCS (ESC1 & ESC8) (abrictosecurity.com, abrictosecurity.com) – Practical blog with ESC1 and ESC8 attack demos (using Certipy, PetitPotam).
• Red Team Notes (ired.team), From Misconfigured Certificate Template to Domain Admin (ired.team, ired.team) – Step-by-step ESC1 exploitation with Certify and usage of Rubeus for Kerberos.
• TrustFoundry, Understanding AD CS: ESC1 and ESC8 (trustfoundry.net, trustfoundry.net) – Explanation of how AD CS can allow arbitrary certificate requests to impersonate users.
• NCC Group, Defending Your Directory: AD CS (nccgroup.com, nccgroup.com) – Defensive focus on mitigating NTLM relay (ESC8) and certificate abuse, with mapping of ESC9, ESC10 beyond the original 8.
• BeyondTrust, AD CS 101: ESC1 Detection/Mitigation (beyondtrust.com) – Guidance on logging (Event IDs 4886, 4887) and detecting SAN impersonation in cert issuance.
• Microsoft KB5005413 & related articles (kb.cert.org, success.trendmicro.com) – Official mitigations for PetitPotam (require EPA, disable HTTP).
• The Hacker Recipes, Golden Certificate (thehacker.recipes) – Concept of forging certs with stolen CA key (Golden Certificate similar to Golden Ticket).
• Various community blogs and tools documentation (Certipy GitHub, Impacket, etc.) for command usage and attack examples (abrictosecurity.com, github.com).