Analyzing and Executing ADCS Attack Paths with BloodHound

### Overview In this presentation, Andy Robbins (co-creator of BloodHound and Principal Product Architect at SpecterOps) and Jonas (Product Architect at SpecterOps) explore the identification, analysis, and execution of Active Directory Certificate Services (ADCS) attack paths using BloodHound. Following the foundational research in the "Certified Pre-Owned" white paper by Will Schroeder and Lee Christensen, the speakers explain how ADCS abuse primitives can allow unauthorized domain or enterprise privilege escalation, how these paths emerge through combinations of configurations and privileges, how BloodHound visualizes and models them, and practical strategies for auditing and remediation.

### Key Topics - **ESC1 Abuse and Modeling**: ESC1 occurs when a certificate template permits a subject alternative name (SAN) supplied by an enrollee (allowing impersonation of high-privilege accounts like domain admins) and has an Extended Key Usage (EKU) valid for authentication (such as Client Authentication). In BloodHound, this is represented by an attack path directing to the domain head, which can be unfurled via the "composition" view to examine the required templates, Enterprise CAs, root trust, and enrollment access rights. - **ESC3 (Enrollment Agent Abuse)**: ESC3 involves requesting a certificate from a template containing the Certificate Request Agent EKU, which allows the holder to act as an enrollment agent and enroll on behalf of other users (such as target domain admins) in another template. BloodHound models this with an `enroll on behalf of` relationship between templates. - **ESC5 (ADCS LDAP Object Manipulation)**: ESC5 encompasses misconfigurations and write privileges over securable Active Directory LDAP objects tied to ADCS (e.g., within the Public Key Services container in the configuration naming context, such as Certification Authorities and the `NTAuthCertificates` store). Missing prerequisites can be substituted with existing access permissions. The speakers detail how generic write/create privileges over these containers permit an attacker to fully bootstrap a rogue CA into Active Directory, even in environments where ADCS was never installed, enabling escalation from domain admin to Enterprise Admin across forest boundaries. - **ESC13 (Issuance Policies & OID Group Links)**: Abuse of certificate templates specifying issuance policies linked via OIDs to universal groups (such as Enterprise Admins or Enterprise Key Admins), granting Kerberos ticket group membership upon authentication without explicit static group membership. - **Visualizing and Auditing PKI Hierarchies**: Using BloodHound's graph visualization and API (supported in both BloodHound Community Edition and Enterprise) to map PKI trust, identify non-tier-0 accounts with control over ADCS objects, and discover insecure template configurations.

### Technical Details - **ESC1 and ESC3 Tooling**: Demos utilized `Certify` to request certificates with specified SANs or enrollment agent permissions, Windows `certutil` for formatting PFX files, and `Rubeus` to request Kerberos TGTs into memory, as well as extracting NTLM hashes. - **Bootstrapping Rogue CAs (ESC5)**: Exploiting `GenericAll` on the `Certification Authorities` container and `NTAuthCertificates` object. A self-signed CA CRT and CRL are published using `certutil -dspublish`. A lightweight HTTP server serves the CRL so domain controllers can complete validation when the DC processes the newly trusted root via Group Policy (which refreshes every 5 minutes by default). - **Forest Boundary Crossings**: Because the configuration naming context replica is writable on domain controllers when running as `SYSTEM` (which possesses an ACE on the container), child domain admins can modify forest-wide configuration objects, bypassing standard trust separation.

### Takeaways - **Audit ADCS Object Control**: Rights like `GenericAll`, `WriteDacl`, or `WriteOwner` on public key services containers should strictly belong to Tier-0 principals. - **Remediating ESC1**: Restrict enrollment permissions on templates with `ENROLLEE_SUPPLIES_SUBJECT` exclusively to Tier-0 identities, or remove authentication EKUs. - **Securing Enrollment Agents**: When smart card enrollment or help desk delegation is required, implement explicit enrollment agent restrictions on the Enterprise CA to strictly define or deny which templates and principals can be targeted.