ADCS-008: ESC5 - Vulnerable PKI Object ACLs
- Platform
- Active Directory
- Category
- AD Certificate Services
- Severity
- High
- Zero Trust pillar
- Identity (weight 2)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
ADCS-008 reads the nTSecurityDescriptor attribute on every object under CN=Public Key Services,CN=Services,CN=Configuration,DC=forest-root and on every Enterprise CA computer account in AD. It parses the DACL on each of the following and reports ACEs that grant write-class rights (GenericAll, GenericWrite, WriteDacl, WriteOwner, WriteProperty, AllExtendedRights) to any principal outside the default trusted set (Enterprise Admins, Domain Admins of the forest root, SYSTEM, BUILTIN\Administrators, Cert Publishers where applicable): - CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration (and every pKIEnrollmentService child object, one per Enterprise CA) - CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration - CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration (and child certificationAuthority objects) - CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration (and child cRLDistributionPoint objects) - CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration (the container ACL, distinct from individual template ACLs which are ESC4 / ADCS-007) - CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration (the Root CA trust store object) - CN=OID,CN=Public Key Services,CN=Services,CN=Configuration - The CA computer object in AD (Enterprise CAs have an HKLM-equivalent computer account whose AD ACL governs who can edit its servicePrincipalName, msDS-AllowedToActOnBehalfOfOtherIdentity, and userCertificate attributes) The trustee set, ActiveDirectoryRights, AccessControlType, ObjectType GUID, and IsInherited flag are emitted for every flagged ACE.
Why it matters
NTAuthCertificates is the authoritative list of CAs that domain controllers will accept for Kerberos PKINIT and Schannel client authentication. Write access to it lets an attacker publish their own self-signed CA certificate as forest-trusted, then issue smartcard-logon certificates for any user, including Domain Admins and the forest-root Administrator. This is a documented forest compromise primitive and is the canonical ESC5 case. Write access to the Enrollment Services container or to an individual pKIEnrollmentService object lets the attacker either remove a CA from the forest or add a rogue CA with templates of their choosing (effectively a stealthier variant of ESC11). Write access to the Certificate Templates container lets the attacker publish new templates without going through the CA, allowing them to backdoor enrollment policy. Write access on the CA computer account itself permits resource-based constrained delegation onto the CA host, which yields code execution as SYSTEM on the CA and therefore the CA private key. Every one of these objects lives in the Configuration NC and replicates to every DC in the forest, so a single rogue ACE in a child domain trivially escalates to forest root.
Attack path
1. Enumeration: the attacker runs certipy find -u user@corp -p pw -dc-ip 10.0.0.10 -vulnerable -enabled, or Certify.exe find /vulnerable, which walks the PKI Services container and reports objects with non-default DACLs. BloodHound (CollectionMethod ACL with the ADCS edge set) renders the same data as ADCSESC5 / AddSelf / WriteDacl edges. 2. Target selection: NTAuthCertificates is the highest-value target. The pKIEnrollmentService object for an Enterprise CA is the second-highest because publishing a rogue CA is straightforward once write access exists. 3. Exploitation, NTAuthCertificates branch: with WriteProperty on the cACertificate attribute of CN=NTAuthCertificates, the attacker uses certutil -dspublish -f rogueCA.cer NTAuthCA or certipy ca -ca rogue -add-cert ... to inject their own CA certificate. The attacker then issues a smartcard-logon EKU certificate for any UPN (for example administrator@corp.local) and authenticates with PKINIT using Rubeus asktgt /certificate:... /user:administrator or certipy auth -pfx admin.pfx, receiving a TGT and the NTLM hash of the target. 4. Exploitation, pKIEnrollmentService branch: with WriteProperty on certificateTemplates of an enabled CA, the attacker adds a template they control (or that has a known ESC1 misconfiguration) to the CAs published list. They then enroll against the rogue template and forge an authentication certificate. 5. Exploitation, CA computer account branch: with WriteProperty on msDS-AllowedToActOnBehalfOfOtherIdentity of the CA computer object, the attacker stages an RBCD attack (Rubeus s4u /user:rogueComputer$ /msdsspn:HOST/ca01 /impersonateuser:administrator), gets a service ticket as SYSTEM on the CA host, extracts the CA private key (certutil -store My, mimikatz crypto::capi / crypto::certificates /export, or Certify.exe extract), and forges certificates offline. 6. Persistence: rogue NTAuth entries survive password resets, krbtgt rotations, and even Tier-0 account decommissioning. The only remediation is detection plus manual removal from the NTAuth store, which most defenders never check.
How Guerrilla assesses it
Guerrilla resolves the Configuration NC distinguishedName via RootDSE configurationNamingContext, enumerates every child object of CN=Public Key Services,CN=Services,<configNC>, and reads nTSecurityDescriptor with Get-ADObject -Properties nTSecurityDescriptor -Server <forest-root-DC>. The DACL is parsed via System.DirectoryServices.ActiveDirectorySecurity and every ACE is evaluated against an allowlist of expected trustees and rights. Inherited ACEs are checked against the parent owner and reported when they introduce a non-default principal. The check also enumerates pKIEnrollmentService objects to collect every Enterprise CA name, then resolves each CA hostname to its AD computer object and reads its nTSecurityDescriptor. For NTAuthCertificates, the cACertificate attribute is enumerated alongside the DACL so the current trusted-CA list is captured for delta analysis. All findings include DN, trustee (resolved to NTAccount where possible, SID string otherwise), ActiveDirectoryRights, ObjectType GUID, AccessControlType, and IsInherited.
Recommended value
No write permissions on PKI container objects for non-administrative principals; write access limited to Enterprise Admins
Remediation
Audit ACLs on all objects under CN=Public Key Services,CN=Services,CN=Configuration including the Enrollment Services container, AIA container, NTAuthCertificates object, and Certificate Templates container. Remove write permissions for non-administrative principals. Ensure the CA computer object in AD does not have write permissions for broad groups. Monitor these objects for unauthorized changes.
Fixture-proven verdicts
Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.
| Scenario | Expected verdict |
|---|---|
| clean | PASS |
| known-bad | FAIL |
| throttled | Not Assessed |
Framework mappings
- NIST SP 800-53
- AC-6, AC-3, IA-5(2)
- ANSSI
- vuln_adcs_esc5
- MITRE ATT&CK
- T1649, T1222.001