ADCS-011: ESC8 - Retransmisión NTLM a extremos HTTP de AD CS
- Plataforma
- Active Directory
- Categoría
- AD Certificate Services
- Severidad
- Critical
- Pilar de Zero Trust
- Identity (peso 3)
- Fixtures de referencia
- 2
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
ESC8 explota los extremos HTTP de inscripción web de AD CS (certsrv) y del servicio de inscripción de certificados (CES) que aceptan autenticación NTLM. Un atacante puede coaccionar la autenticación de un controlador de dominio o una cuenta privilegiada y retransmitir la autenticación NTLM al extremo HTTP de la CA para solicitar un certificado con la identidad retransmitida, lo que conduce al compromiso del dominio
Por qué importa
ESC8 is the most reliable, lowest-skill path to forest compromise in modern AD environments. The chain is short: a single coerced DC authentication is relayed to /certsrv, the relay submits a CSR against the default User or DomainController template (which permits client authentication), and the CA issues a certificate bound to the DCs computer identity. That certificate is then used to authenticate to LDAP via Schannel and pull every secret in the directory via DRSUAPI replication. There is no patch that fully closes the primitive: the underlying NTLM relay surface, the AD CS web roles, and the coercion RPC interfaces all ship enabled by default. The Microsoft fix (KB5005413, May 2022 patch wave, and the eventual ExtendedProtection enforcement) only blocks the relay when EPA is configured on every CA web endpoint, when SMB signing is required on all DCs, and when the IIS bindings drop HTTP entirely. In real engagements, ESC8 is exploited within minutes of initial network access by ransomware affiliates (LockBit, BlackCat, Akira) and by every red team that pulls down Certipy.
Ruta de ataque
1. Reconnaissance: from any unauthenticated foothold on the corporate network, the attacker enumerates CA hosts with Certipy (certipy find -vulnerable -u user@corp -p pass) or with PowerView (Get-CertificateEnrollmentService). The output lists every CA with Web Enrollment, CES, or NDES enabled. 2. Relay setup: the attacker starts ntlmrelayx (impacket-ntlmrelayx -t http://ca01.corp/certsrv/certfnsh.asp -smb2support --adcs --template DomainController) on a host that can reach both the target CA and the DC. ntlmrelayx will accept inbound SMB or HTTP and relay the captured NTLM authentication to the CA HTTP endpoint. 3. Coercion: the attacker triggers a privileged authentication from the DC to the relay listener. Common primitives: - PetitPotam (CVE-2021-36942) via the EFS RPC interface (efsrpc EfsRpcOpenFileRaw). - PrinterBug via MS-RPRN RpcRemoteFindFirstPrinterChangeNotificationEx. - DFSCoerce via MS-DFSNM NetrDfsAddStdRoot. - ShadowCoerce via MS-FSRVP IsPathSupported. 4. Relay and issuance: ntlmrelayx forwards the DC machine account NTLM to /certsrv, submits a CSR for the DomainController or User template, and receives a PFX bound to DC01$. 5. Authentication and DCSync: the attacker authenticates with the certificate via PKINIT to obtain a TGT for DC01$ (certipy auth -pfx dc01.pfx), or uses the certificate directly against LDAP/S to perform DRSUAPI replication (certipy dcsync). The krbtgt hash is dumped, Golden Tickets are forged, and the forest is owned. 6. Persistence: with krbtgt and an enterprise CA NTAuth certificate, the attacker can forge authentication for any principal indefinitely, surviving password rotations and DC rebuilds.
Cómo lo evalúa Guerrilla
Guerrilla queries CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=<forest> to enumerate every pKIEnrollmentService object, extracts the dNSHostName attribute for each CA, and probes the host. Where WinRM is available, it reads the IIS applicationHost.config under system.webServer/security/authentication and checks the windowsAuthentication enabled and extendedProtection tokenChecking values on each AD CS application (/certsrv, /ADPolicyProvider_CEP_*, /<CAName>_CES_*, /certsrv/mscep). It also checks the site bindings to confirm whether port 80 is bound and whether the HTTPS binding has a Server Authentication EKU certificate. Where WinRM is denied, the check falls back to an HTTP HEAD against each well-known path and parses the WWW-Authenticate header: a response containing Negotiate or NTLM over an http:// scheme, or over https:// without an EPA challenge, is classified as ESC8. The check also reads the EnforceEncryptionForRequests, InterfaceFlags, and EditFlags registry values on HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName> on the CA itself, and the IF_ENFORCEENCRYPTICERTREQUEST flag on the CA interface, to confirm that RPC enrollment is also locked down. Finally it correlates with ADCS-001 (Web Enrollment enabled) and ADCS-002 (CES enabled) to give a single ESC8 disposition per CA.
Valor recomendado
Ningún extremo de inscripción basado en HTTP; si es necesario, imponga HTTPS con Extended Protection for Authentication (EPA) habilitado
Remediación
Identifique todos los extremos de inscripción web de la CA con Get-CertificateEnrollmentService y comprobando los enlaces de IIS. Deshabilite los extremos de inscripción basados en HTTP y exija HTTPS. Habilite Extended Protection for Authentication en IIS para evitar la retransmisión NTLM. De forma alternativa, deshabilite por completo el rol de inscripción web y utilice únicamente la interfaz de inscripción basada en DCOM. Deshabilite la autenticación NTLM en los servidores de CA cuando sea posible.
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.
| Escenario | Veredicto esperado |
|---|---|
| limitation | WARN |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- SC-8, SC-23, IA-5(2)
- ANSSI
- vuln_adcs_esc8
- MITRE ATT&CK
- T1649, T1557, T1187