Skip to content
Hermes Codex

Identity Security: Active Directory Certificate Services (AD CS)

1. The Mechanics of AD CS and PKINIT

Section titled “1. The Mechanics of AD CS and PKINIT”

To understand AD CS attacks, one must understand how certificates translate into Domain access.

AD CS relies on Certificate Templates—blueprints defining what a certificate can be used for (Extended Key Usage, or EKU), who can request it, and how long it remains valid. When an endpoint requests a certificate, it undergoes the Enrollment process interacting with the Certificate Authority (CA).

The bridge between PKI and Active Directory authentication is PKINIT (Public Key Cryptography for Initial Authentication in Kerberos). Instead of sending a timestamp encrypted with a password hash during the initial Kerberos AS-REQ, a user can present a valid certificate (e.g., a Smart Card). The Domain Controller verifies the certificate’s signature against the trusted CA. If valid, the DC issues a Ticket Granting Ticket (TGT).

The Attacker’s Goal: Trick the CA into issuing a valid certificate for a highly privileged account. The attacker then uses PKINIT via tools like Rubeus to convert that certificate into a Domain Admin TGT.

2. Primary Attack Vectors (The ESC Taxonomy)

Section titled “2. Primary Attack Vectors (The ESC Taxonomy)”

Security researchers categorize AD CS vulnerabilities into specific escalation paths (ESC1 through ESC14+). DFIR analysts must prioritize the two most devastating and common vectors: ESC1 and ESC8.

A. ESC1: Privilege Escalation via Template Misconfiguration

Section titled “A. ESC1: Privilege Escalation via Template Misconfiguration”

This vector requires no exploits, only an abuse of a poorly configured template.

  • The Flaw: A certificate template is vulnerable to ESC1 if it meets three conditions simultaneously:
    1. It grants enrollment rights to low-privileged users (e.g., Domain Users or Authenticated Users).
    2. It contains an EKU enabling authentication (e.g., Client Authentication or Smart Card Logon).
    3. The CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is enabled. This fatal flaw allows the requester to manually specify the Subject Alternative Name (SAN) within the certificate.
  • The Attack: A standard user requests a certificate using this template. In the request, they inject the User Principal Name (UPN) of a Domain Admin into the SAN field. The CA blindly issues the certificate. The attacker now possesses a cryptographic passport that effectively says: “I am the Domain Admin.”

B. ESC8: NTLM Relay to AD CS Web Enrollment

Section titled “B. ESC8: NTLM Relay to AD CS Web Enrollment”
  • The Flaw: Many AD CS deployments feature a Web Enrollment interface (/certsrv) operating over HTTP, which inherently lacks protection against NTLM Relaying.
  • The Attack: An attacker utilizes a coercion technique (e.g., PetitPotam) to force a critical machine (like a Domain Controller) to authenticate to the attacker’s machine. The attacker relays this NTLM authentication to the AD CS Web Enrollment HTTP endpoint.
  • The Result: The CA issues a certificate for the Domain Controller’s machine account. The attacker uses this certificate to authenticate as the DC and executes a DCSync attack, dumping all password hashes from the domain.

3. Forensic Investigation (CSIRT)

Section titled “3. Forensic Investigation (CSIRT)”

Hunting for AD CS abuse requires shifting focus from standard authentication logs to the specific audit logs generated by the Certificate Authority.

  1. Enable CA Auditing: By default, CA auditing is disabled. Administrators must configure the CA properties to audit “Issue and manage certificate requests” and ensure the matching GPO is enabled (Audit Certification Services).
  2. Analyze Event ID 4886 & 4887: These events reside in the Security log of the CA server.
    • 4886: Certificate Services received a certificate request.
    • 4887: Certificate Services approved a certificate request and issued a certificate.
  3. Hunt for Anomalous SANs: Within Event 4887, analyze the Subject Alternative Name field. If the Requester is a standard user account but the SAN contains the identity of a privileged account (e.g., Administrator), an ESC1 attack has occurred.

4. Detection & Threat Hunting

Section titled “4. Detection & Threat Hunting”
hunt_adcs_esc1_abuse.kql
// Detects potential ESC1 exploitation by hunting for Event 4887 where a certificate
// was issued containing a Subject Alternative Name (SAN).
SecurityEvent
| where EventID == 4887
// Filter for events containing SANs
| where EventData has "Subject Alternative Name:"
| parse EventData with * "Requester: " RequesterAccount "\n" *
| parse EventData with * "Subject Alternative Name: " SAN "\n" *
| project TimeGenerated, Computer, RequesterAccount, SAN, EventData
// Exclude legitimate computer account auto-enrollments (which often use SANs)
| where RequesterAccount !endswith "$"
| sort by TimeGenerated desc

5. Mitigation and Hardening

Section titled “5. Mitigation and Hardening”
  1. ESC1 Mitigation: Audit all certificate templates using tools like Certify or PingCastle. Disable the ENROLLEE_SUPPLIES_SUBJECT flag on any template utilized for authentication. If a template absolutely requires this flag, explicitly deny Domain Users from enrolling, restricting access to designated administrators.
  2. ESC8 Mitigation: Disable the AD CS Web Enrollment feature if it is not strictly necessary. If it is required, enforce HTTPS and configure Extended Protection for Authentication (EPA) in IIS to mitigate NTLM relaying attacks entirely.

Sources & References

Section titled “Sources & References”