ADCS ESC9, ESC10, ESC11: escalada de certificados más allá de ESC1-ESC8

Qué es la escalada de certificados ADCS ESC9, ESC10, ESC11

La escalada de certificados ADCS ESC9, ESC10, ESC11 es el conjunto de técnicas de escalada de privilegios de Active Directory Certificate Services (AD CS) publicadas después de la investigación original "Certified Pre-Owned", que introdujo ESC1 a ESC8. Mientras que las primeras ocho rutas se centran en configuraciones erróneas de plantillas, ajustes peligrosos de la CA y la inscripción web HTTP, ESC9, ESC10 y ESC11 apuntan a la capa que decide si un certificado realmente se mapea a la cuenta correcta: la extensión de seguridad incrustada en el certificado, la configuración de mapeo de certificados del controlador de dominio, y la aplicación de cifrado en la interfaz RPC de inscripción de la CA.

Las tres técnicas existen debido al mismo cambio subyacente: la actualización de Microsoft de mayo de 2022 (KB5014754) introdujo la extensión de seguridad szOID_NTDS_CA_SECURITY_EXT, que incrusta el SID del principal solicitante en el certificado emitido para que el KDC pueda vincular fuertemente ese certificado a una sola cuenta. ESC9, ESC10 y ESC11 son tres formas distintas en que ese vínculo puede fallar en proteger un entorno: una a nivel de plantilla, otra a nivel de controlador de dominio/Schannel, y otra a nivel de transporte RPC.

Cómo funciona

ESC9 — Sin extensión de seguridad

ESC9 existe cuando el msPKI-Enrollment-Flag de una plantilla de certificado incluye el bit CT_FLAG_NO_SECURITY_EXTENSION (0x80000). La documentación de Certify de SpecterOps describe que esto suprime la extensión szOID_NTDS_CA_SECURITY_EXT en cualquier certificado emitido desde esa plantilla. El efecto es que el proceso de mapeo de certificados se comporta como si StrongCertificateBindingEnforcement estuviera establecido en 0, independientemente de su valor real en el registro del controlador de dominio, porque no hay SID en el certificado con el que comparar.

Por sí solo, ese indicador no es explotable. Se convierte en ESC9 cuando se combina con una segunda condición que los atacantes ya buscan en plantillas adyacentes a ESC1-ESC8: un principal con pocos privilegios que posee GenericWrite (o equivalente) sobre otra cuenta. Un atacante con GenericWrite sobre una cuenta víctima puede cambiar el userPrincipalName de esa cuenta para que coincida con un objetivo privilegiado (por ejemplo, el sAMAccountName de un administrador), inscribir un certificado desde la plantilla marcada como ESC9 en calidad de cuenta víctima, y autenticarse como el objetivo suplantado — porque el certificado resultante no lleva extensión SID que contradiga el UPN falsificado.

ESC10 — Mapeo de certificado débil (a nivel de dominio)

ESC10 produce el mismo resultado práctico que ESC9 — una autenticación que se resuelve hacia la cuenta equivocada — pero la configuración errónea reside en el controlador de dominio o en Schannel, no en una sola plantilla de certificado. SpecterOps y la investigación de la comunidad (incluyendo el wiki de Certify y análisis independientes de ADCS) describen dos variantes:

• Caso A — El valor de registro CertificateMappingMethods de Schannel en el controlador de dominio incluye el mapeo UPN. Un atacante que puede escribir en el userPrincipalName de una cuenta víctima (de nuevo mediante GenericWrite o similar) lo establece para que coincida con un principal objetivo, y luego se autentica vía Schannel (autenticación TLS de cliente) con cualquier certificado cuyo sujeto o SAN refleje el UPN falsificado.
• Caso B — StrongCertificateBindingEnforcement en el controlador de dominio está explícitamente establecido en 0 (modo Compatibilidad) en lugar del valor forzado por defecto, de modo que una extensión SID ausente o no coincidente se acepta en lugar de rechazarse, para cada plantilla y cada principal — no solo una plantilla marcada como en ESC9.

La diferencia operativa clave respecto a ESC9: ESC10 no está limitado a una sola plantilla de certificado, por lo que normalmente amplía el conjunto de cuentas explotables a todo el dominio.

ESC11 — Retransmisión de NTLM a la interfaz RPC de la CA

ESC11 es el equivalente a nivel de transporte RPC de ESC8 (retransmisión NTLM a la inscripción web HTTP). Las autoridades certificadoras exponen la interfaz RPC ICertPassage (MS-ICPR) para las solicitudes de certificados. Según la documentación de Certify de SpecterOps y la investigación independiente de Compass Security, si esa interfaz aplica cifrado a nivel de paquete lo controla el indicador de interfaz IF_ENFORCEENCRYPTICERTREQUEST en la CA. Ese indicador está habilitado por defecto, pero se deshabilita con frecuencia por compatibilidad con clientes antiguos que no pueden negociar RPC_C_AUTHN_LEVEL_PKT_PRIVACY.

Cuando el indicador está desactivado, un atacante que coacciona a una víctima (por ejemplo, la cuenta de equipo de un controlador de dominio) para que se autentique vía NTLM puede retransmitir esa autenticación a la interfaz RPC de la CA — eludiendo las mismas protecciones de inscripción web que cubre ESC8, pero por RPC en lugar de HTTP, e independientemente de si la inscripción web siquiera está instalada.

La cadena de ataque

🚨 Peligro: las tres técnicas pueden terminar en el mismo resultado que ESC1-ESC8 — un certificado utilizable para autenticación Kerberos PKINIT como administrador de dominio o controlador de dominio. La escalada vía GenericWrite se encadena directamente con Abuso de ACL y DCSync: las rutas silenciosas hacia Domain Admin. El paso de retransmisión de ESC11 usa las mismas primitivas de coacción/retransmisión cubiertas en Ataques de retransmisión NTLM: secuestro de la autenticación en AD.

Detección

Remediación

1. Eliminar CT_FLAG_NO_SECURITY_EXTENSION de las plantillas (ESC9). Audita el msPKI-Enrollment-Flag de cada plantilla de certificado. Cualquier plantilla capaz de autenticación con este indicador debería tenerlo despejado, salvo una razón documentada y revisada — y esa razón no debería incluir derechos de inscripción no privilegiados.
2. Llevar los controladores de dominio a Full Enforcement (ESC10, Caso B). Confirma que StrongCertificateBindingEnforcement no esté fijado en 0. Según la cronología del KB5014754 de Microsoft, los controladores de dominio sin un valor de registro explícito pasaron a modo Full Enforcement con la actualización de febrero de 2025, y la propia clave de registro dejó de tenerse en cuenta tras la actualización de septiembre de 2025 — un 0 explícito dejado en su lugar es por tanto una degradación deliberada que debe encontrarse y justificarse.
3. Deshabilitar métodos de mapeo Schannel débiles (ESC10, Caso A). Revisa CertificateMappingMethods en cada controlador de dominio y cualquier servidor que termine autenticación TLS de certificado de cliente. Los métodos débiles (Sujeto/Emisor, Solo emisor, UPN) deberían permanecer deshabilitados; solo deberían permitirse los métodos fuertes (S4U2Self, S4U2Self explícito) salvo que una aplicación heredada específica y documentada lo requiera.
4. Forzar el cifrado RPC en cada CA (ESC11). Ejecuta certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST en cada CA, y luego reinicia el servicio de Servicios de certificados (net stop certsvc && net start certsvc). Valida después con certutil -config "<CA>" -getreg CA\InterfaceFlags y confirma que 0x200 esté presente.
5. Cerrar la exposición subyacente de GenericWrite. Tanto ESC9 como ESC10 Caso A requieren que un atacante ya posea acceso de escritura sobre el userPrincipalName de una cuenta víctima. Revisa las ACL en busca de concesiones demasiado amplias de GenericWrite, GenericAll, WriteProperty, o equivalentes a Validated-SPN sobre objetos de usuario, especialmente desde grupos de helpdesk o aprovisionamiento, como parte de la misma pasada de remediación.
6. Volver a probar después de cada cambio. Los cambios de mapeo de certificados y de cifrado RPC pueden romper clientes heredados (versiones antiguas de Windows, clientes RPC que no son Windows, middleware antiguo de tarjeta inteligente). Despliega los cambios mediante un grupo piloto representativo antes de aplicarlos a todo el dominio, y mantén la revisión de eventos KDC/Schannel de la sección de detección activa durante el despliegue para confirmar que ninguna autenticación legítima empieza a fallar.

✅ Acción rápida: si solo hay tiempo para una acción hoy, ejecuta la comprobación certutil -config "<CA>" -getreg CA\InterfaceFlags en cada CA. ESC11 no requiere privilegios de directorio para explotarse — solo acceso de red y una primitiva de coacción — lo que la convierte en la ruta con la barrera de entrada más baja de las tres.

Cómo lo detecta EtcSec

Las verificaciones de auditoría de AD de EtcSec se corresponden directamente con cada técnica: ESC9_NO_SECURITY_EXTENSION señala plantillas de certificado con CT_FLAG_NO_SECURITY_EXTENSION en una plantilla capaz de autenticación, ESC10_WEAK_CERTIFICATE_MAPPING revisa la configuración de mapeo de certificados del controlador de dominio y de Schannel en busca de ajustes en modo compatibilidad, y ESC11_ICERT_REQUEST_ENFORCEMENT verifica la aplicación de cifrado RPC en cada CA descubierta. Dado que ESC9 y ESC10 Caso A dependen ambos de un prerrequisito de tipo GenericWrite, EtcSec también correlaciona estos hallazgos con la superficie de exposición ACL más amplia, de modo que un indicador de plantilla o un ajuste de registro se prioriza según si un atacante realmente tiene una ruta para abusarlo — no se señala de forma aislada.

Si estás construyendo una revisión completa de AD CS en lugar de verificar una técnica a la vez, combina este artículo con Auditar la seguridad de Active Directory: qué revisar primero y cómo demostrar la remediación para la checklist Tier 0 completa en la que encajan estas rutas.

Referencias principales

• SpecterOps / Certify — ESC9: No Security Extension
• SpecterOps / Certify — ESC10: Weak Certificate Mapping
• SpecterOps / Certify — ESC11: NTLM Relay to AD CS RPC Interfaces
• Microsoft Support: KB5014754 — Certificate-based authentication changes on Windows domain controllers
• Microsoft Defender for Identity: Enforce encryption for RPC certificate enrollment interface (ESC11)
• Compass Security: Relaying to AD Certificate Services over RPC