Esta página está traducida automáticamente y pendiente de revisión humana. Una guía de remediación de seguridad que no puedes verificar es una afirmación, así que el original en inglés está a un clic. English.

ADCS-008: ESC5 - ACL vulnerables en objetos de PKI

Plataforma
Active Directory
Categoría
AD Certificate Services
Severidad
High
Pilar de Zero Trust
Identity (peso 2)
Fixtures de referencia
3
Cobertura de ramas
Observada: los fixtures prueban los veredictos que ejercitan
Procedencia
baseline

Qué comprueba

ESC5 abarca los permisos de escritura sobre otros objetos de AD relacionados con la PKI más allá de las plantillas de certificado, incluidos el objeto de AD del servidor de CA, el objeto NTAuthCertificates, el contenedor de servicios de inscripción y el contenedor de plantillas de certificado. El acceso de escritura a estos objetos puede permitir a un atacante añadir CA fraudulentas, modificar la configuración de inscripción o publicar plantillas maliciosas

Por qué importa

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.

Ruta de ataque

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.

Cómo lo evalúa Guerrilla

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.

Valor recomendado

Ningún permiso de escritura sobre los objetos contenedores de PKI para principales no administrativos; acceso de escritura limitado a Enterprise Admins

Remediación

Audite las ACL de todos los objetos bajo CN=Public Key Services,CN=Services,CN=Configuration, incluidos el contenedor de servicios de inscripción, el contenedor AIA, el objeto NTAuthCertificates y el contenedor de plantillas de certificado. Elimine los permisos de escritura de los principales no administrativos. Asegúrese de que el objeto de equipo de la CA en AD no tenga permisos de escritura para grupos amplios. Supervise estos objetos en busca de cambios no autorizados.

Veredictos probados con fixtures

Cada veredicto de esta tabla está probado por un fixture de referencia en la suite de pruebas que valida el módulo. La tabla se deriva de la última ejecución en verde; no puede editarse a mano.

Escenarios de veredicto de ADCS-008
EscenarioVeredicto esperado
cleanPASS
known-badFAIL
throttledNot Assessed

Mapeos a marcos de referencia

NIST SP 800-53
AC-6, AC-3, IA-5(2)
ANSSI
vuln_adcs_esc5
MITRE ATT&CK
T1649, T1222.001