How to detect AD Certificate Services (ADCS) abuse

Threat snapshot

Active Directory Certificate Services is arguably the most overlooked attack surface in enterprise environments. Organizations spend years hardening Kerberos, monitoring LDAP queries, and alerting on failed logons, but leave their PKI infrastructure completely unmonitored. The result: an attacker with a low-privileged domain account can silently request a certificate that grants them persistent, MFA-bypassing domain administrator access.

That certificate survives password resets. It remains valid even after the compromised user account is disabled. It can be used to authenticate via PKINIT and request Kerberos tickets for any user in the domain, including Domain Admins, without ever touching LSASS or triggering the credential-dumping alerts your SOC watches for.

This is why ADCS abuse has become the preferred persistence mechanism for APT groups operating in enterprise Active Directory environments. The research by Will Schroeder and Lee Christensen (ESC1 to ESC8) published in 2021 mapped eight distinct attack paths against misconfigured AD CS environments. Since then, tooling like Certify and Certipy has made these attacks trivially automatable by any attacker with basic domain knowledge.

This page maps each attack path to Log360 detection rules, shows the log signals that distinguish malicious certificate activity from legitimate PKI operations, and provides the investigation workflow your SOC needs when these rules fire.

ADCS abuse, at a glance

How ADCS attacks work

Understanding why ADCS is dangerous requires understanding what a certificate actually does in Active Directory authentication. When a domain-joined system authenticates using PKINIT (the Kerberos extension that supports certificate-based authentication), the KDC accepts the certificate as proof of identity, not the user's password. A certificate that allows authentication as a Domain Admin is, functionally, a durable credential that cannot be invalidated by a password change alone.

The ESC attack paths exploit different weaknesses in how certificate templates are configured and how the CA handles enrollment requests. The three most operationally significant paths are shown below.

ESC1: Misconfigured certificate templates

ESC1 is the most common ADCS attack path. The vulnerability requires three conditions in a single certificate template: the template allows the requester to supply a Subject Alternative Name (the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is set), the template includes an EKU that permits client authentication, and the template is enrollable by a low-privilege group such as Domain Users. When all three are met, any domain user can request a certificate claiming any identity in the domain, including Domain Administrators. The CA signs it because it trusts the requester to supply the correct SAN. The attacker then presents this certificate via PKINIT to obtain a TGT for the Domain Admin account. The entire operation takes under 60 seconds with Certify or Certipy and leaves almost no trace unless certificate auditing is explicitly enabled on the CA.

ESC6: The EDITF_ATTRIBUTESUBJECTALTNAME2 flag

ESC6 differs from ESC1 in that the vulnerability lives in the Certificate Authority itself rather than a specific template. When a CA is configured with the EDITF_ATTRIBUTESUBJECTALTNAME2 flag, every certificate template on that CA allows SAN specification by the requester, regardless of whether the template itself permits it. Even templates that appear safe from an ESC1 review become exploitable. This flag is sometimes set accidentally by administrators following outdated documentation. Once set, it is not visible in standard CA GUI tooling and persists until explicitly removed.

ESC8: NTLM relay to the CA HTTP enrollment endpoint

ESC8 does not require a misconfigured template. The attacker coerces NTLM authentication from a privileged machine account (typically a Domain Controller) using techniques like PetitPotam or PrinterBug, then relays that authentication to the CA's HTTP-based enrollment interface (usually http://CA/certsrv). The CA issues a certificate in the name of the relayed machine account. For a DC, this certificate can then be used for a DCSync-equivalent operation through Shadow Credentials or PKINIT. ESC8 works even when the CA is fully patched and templates are properly configured, because the vulnerability is the absence of Extended Protection for Authentication (EPA) on the HTTP enrollment endpoint.

Real-world campaigns and CVEs

ADCS abuse has transitioned from a research novelty to a documented staple of APT and ransomware operator toolkits. The following campaigns show how these attack paths are used in practice.

APT29 (Cozy Bear): ADCS persistence in government networks

APT29, the Russian SVR-affiliated threat group, has been documented using ADCS-based persistence in targeted intrusions against government and critical infrastructure organizations. After initial access via spearphishing or supply chain compromise, the group specifically seeks out CA servers to issue themselves persistent authentication certificates. Unlike Golden Ticket attacks, these certificates remain valid even after krbtgt password resets, giving the group a re-entry mechanism that survives most standard incident response actions.

Technique used: ESC1 against user-enrollable templates with Client Authentication EKU, combined with post-exploitation export of the issued certificate using certutil or PowerShell for offline storage.

Black Basta and Scattered Spider: ESC8 via PetitPotam

Black Basta affiliates have incorporated ESC8 attacks via PetitPotam into their credential escalation chain during ransomware pre-positioning operations. In environments where ESC1-style template abuse is not viable due to more mature PKI configurations, the relay approach provides an alternative path to domain compromise without requiring a misconfigured template. The technique is used to obtain a certificate for the domain controller machine account, which then enables a DCSync-equivalent data dump via Shadow Credentials or PKINIT-authenticated LDAP.

CVE reference table

Business impact

• Persistence that survives incident response: A certificate-based backdoor survives password resets, account disables, and even krbtgt resets. Only explicit certificate revocation (CRL update) and template hardening remove the attacker's access. Organizations that remediate a domain compromise without checking for unauthorized certificate issuance often find the attacker returns within days.
• MFA bypass at the domain level: Certificates issued via ADCS abuse authenticate through PKINIT, a Kerberos extension that bypasses password-based MFA entirely. This is why ADCS attacks are favored by APT groups in environments with strong MFA deployments: the certificate-based authentication path never invokes MFA controls.
• Breadth of exposure: The 2021 SpecterOps research estimated that the majority of Active Directory environments with ADCS deployed have at least one ESC-vulnerable configuration. Because PKI infrastructure is rarely reviewed as part of routine security hardening, misconfigurations introduced during initial deployment frequently persist for years undetected.
• Regulatory implications: Certificate-based domain compromise enables access to all domain-joined systems. In regulated environments this means patient records, payment card data, and controlled information. Unauthorized access via forged certificates triggers breach notification obligations under HIPAA, GDPR, and SEC cyber disclosure rules regardless of whether data exfiltration is confirmed.

Detecting ADCS abuse with Log360

Log360 ships with two detection rules that specifically target ADCS template misconfigurations. These rules require Active Directory audit logs to be forwarded to Log360 and AD CS audit settings to be enabled on the CA server (certutil -setreg CA\AuditFilter 127). The rules are proactive: they surface a vulnerable template configuration before exploitation occurs, giving security teams a remediation window rather than waiting for a certificate request to be made.

Attack chain visibility

The two ADCS-specific rules cover the misconfiguration layer. A complete picture of an ADCS attack requires an analyst to manually connect alerts fired across multiple log sources in Log360's incident workbench. The sequences below show what that chain looks like for the two most common attack paths.

Sequence A: ESC1 exploitation (template abuse to Domain Admin)

Sequence B: ESC8 via PetitPotam (relay chain to DC certificate issuance)

Investigation playbook

When an ADCS detection rule fires in Log360, use the following steps to scope the incident, determine whether exploitation has already occurred, and collect the evidence needed for remediation.

Step 1: Triage - determine what fired and why

Step 2: Scope - check whether exploitation has already occurred

• Pull CA audit logs (Event ID 4887) for the 30 days preceding the alert. Look for certificate requests where the SAN in the issued certificate does not match the requesting account's UPN. This mismatch is the primary forensic indicator of ESC1 exploitation.
• For every suspicious issuance, record the Certificate Serial Number, Template Name, Requesting Account, and Source Machine. These are your revocation targets.
• Check Kerberos authentication logs (Event ID 4768 with certificate-based pre-authentication) for PKINIT TGT requests using suspect certificates. This confirms whether the certificate has already been used for authentication and from which machine.
• Review UEBA anomaly scores for the requesting account in Log360. A standard domain user account suddenly requesting certificates for domain administrators is a high-anomaly behavioral signal.

Step 3: Investigate using the Incident Workbench

• From the fired alert, click on the username or source IP to invoke the Incident Workbench. It can be opened directly from the alerts view, log search results, reports, or the incidents list by clicking on any supported entity field such as username, source IP, process name, or domain.
• In the Incident Workbench, use the User analytics tab to pull the requesting account's full activity overview and risk profile. This shows the account's recent logon history, accessed resources, and any UEBA-flagged anomalies, giving context on whether this is a known admin or a standard user behaving unusually.
• Use the Process analytics tab to inspect the process tree on the source host. This shows parent-child process relationships and an event timeline for that machine, allowing you to see whether Certify or Certipy was executed, what spawned it, and whether a PowerShell certificate export followed. This is the primary way to confirm enumeration and exploitation steps within the Incident Workbench.
• If external IPs are involved (for example in ESC8 relay scenarios), use the Advanced Threat Analytics tab on those IPs to pull risk scores from integrated threat feeds and confirm whether the IP is associated with known threat infrastructure.
• Once investigation is complete, save the Incident Workbench session to an existing incident or create a new one directly from the workbench. This preserves the full investigation context, including entity timelines and process trees, as the evidence record for the incident.
• For broader log-level pivoting (searching raw CA audit events, querying Kerberos Event 4768, correlating across log sources by time window), use Log360's log search rather than the Incident Workbench. The Incident Workbench is for entity-focused investigation; log search is for raw event queries.

Step 4: Determine impact

• Was the issued certificate used for authentication? Check Kerberos Event 4768 for PKINIT pre-authentication. If used, all actions taken under the impersonated identity must be reviewed and treated as attacker-controlled.
• Was the DPAPI backup key accessed? If detection rules covering DPAPI backup key export fired alongside the ADCS alert, treat the entire PKI as compromised. The attacker can forge certificates for any domain identity offline without any further CA interaction. This scenario requires full PKI rebuild.
• How many templates are misconfigured? Each misconfigured template is an independent attack vector. The ADCS rules may fire multiple times across different templates.
• Was a root certificate installed? Look for root certificate installation detection rule alerts on domain-joined endpoints in the same time window. Attacker-installed root certificates enable MITM against TLS-protected internal applications.

Step 5: Collect evidence and build the timeline

• Export the CA audit log for the investigation period. This is your primary forensic artifact: it records every certificate request, approval, and denial with timestamp, requesting identity, template name, and certificate details.
• Collect Sysmon process creation logs from the source machine. The process timeline should show the enumeration, request, and export sequence if exploitation occurred.
• Record all issued certificate Serial Numbers before beginning remediation. Revocation requires the serial number from the CA database; if CA state is modified before revocation is complete, recovery becomes significantly harder.
• Export the correlated event timeline from Log360 as your compliance artifact for NIST CSF DE.AE-5 (incident analysis) and HIPAA Section 164.308(a)(6) (security incident procedures documentation).

Response and remediation

Immediate containment

• Revoke unauthorized certificates immediately: Use certutil -revoke <SerialNumber> on the CA, then publish an updated CRL with certutil -dspublish. Without certificate revocation, password resets and account disables are insufficient. The certificate remains valid until its expiry date regardless of account state.
• Restrict or disable the misconfigured template: In the CA management console, either remove the ENROLLEE_SUPPLIES_SUBJECT flag, add Manager Approval as a requirement, or disable the template entirely until the configuration is corrected.
• Block HTTP access to the CA enrollment endpoint: For ESC8 scenarios, blocking access to /certsrv from non-CA-management IPs prevents the relay from completing while longer-term EPA configuration is applied.
• Disable the requesting account pending investigation if unauthorized certificate requests are confirmed from that account.

Response actions by trigger

PKI hardening

• Remove the ENROLLEE_SUPPLIES_SUBJECT flag from all templates where it is not explicitly required for a documented business process. For templates where it is genuinely needed (specific Smart Card enrollment scenarios), require Manager Approval for certificate issuance and restrict the enrollment group to the minimum necessary.
• Enable Extended Protection for Authentication (EPA) on the IIS-hosted enrollment endpoints (certsrv, CES, CEP). EPA binds NTLM authentication to the TLS channel, preventing NTLM relay to these endpoints and closing ESC8.
• Remove the EDITF_ATTRIBUTESUBJECTALTNAME2 flag from all CAs where it is set but not required. Run certutil -getreg policy\EditFlags on each CA to check. This flag should not exist in any environment unless a specific Smart Card UPN SAN scenario explicitly requires it.
• Enable full CA audit logging with certutil -setreg CA\AuditFilter 127 on all CAs if not already in place. Without this setting the CA does not log certificate issuance events and Log360's ADCS detection rules cannot fire.

False positive tuning