Rutas de ataque ADCS explicadas

Rutas de ataque ADCS: qué cuenta como una ruta real

Si busca una explicación práctica de rutas de ataque ADCS, hay que empezar por la cadena y no por la etiqueta. Una ruta de ataque AD CS no es solo una plantilla débil. Es la combinación de reglas de emisión, derechos de enrollment, control sobre la configuración de la template o de la CA, endpoints de enrollment accesibles y comportamiento de autenticación basada en certificados que permite a una identidad de bajo privilegio convertirse en una identidad más privilegiada o reabrir esa ruta después.

Por eso una revisión de AD CS no puede quedarse en una sola captura de Certificate Templates. Hay que responder cinco preguntas a la vez:

¿Qué Enterprise CAs existen en el bosque?
¿Qué templates están publicadas y son utilizables para autenticación?
¿Quién puede enroll, auto-enroll o modificar esas templates?
¿Qué configuraciones globales de la CA amplían el abuso de subject o SAN?
¿Qué endpoints de enrollment y qué rutas de autenticación hacen que esos certificados sean utilizables en producción?

En la investigación Certified Pre-Owned de SpecterOps, las etiquetas ESC nombran patrones de abuso recurrentes. En una revisión real son rutas de ataque porque conectan la configuración PKI con la escalada de identidad.

Por qué las rutas de ataque ADCS siguen importando en Active Directory

Microsoft documenta AD CS como el rol de Windows Server que emite y administra certificados PKI para autenticación, cifrado, smart card sign-in, TLS, VPN y otros flujos de seguridad. Ese mismo rol se convierte en una superficie de identidad de alto impacto cuando las reglas de emisión de certificados y de autenticación basada en certificados se separan del mínimo privilegio.

Las rutas AD CS importan porque no todas se parecen a un abuso clásico de admin. Algunas rutas permiten a un atacante solicitar un certificado que autentica como otra identidad. Otras le permiten cambiar primero el plano de control y crear después las condiciones peligrosas en la template. Otras dependen de relaying de autenticación hacia endpoints de enrollment en lugar de modificar directamente la configuración de la template. Y otras forman parte de cadenas de escalada más amplias con rutas de ataque AD o abuso ACL y DCSync, en vez de actuar por sí solas.

La segunda razón es el punto ciego operativo. Los equipos de seguridad suelen vigilar mejor los resets de contraseña, los errores críticos de contraseñas AD o la delegación Kerberos que la emisión de certificados. Si la auditoría de la CA, la visibilidad sobre cambios de templates o las baselines de autenticación con certificados son débiles, una ruta PKI vulnerable puede seguir viva mucho después de que se hayan revisado otras rutas de escalada.

Paquete mínimo de evidencias

Evidencia	Por qué importa
Inventario de Enterprise CAs	Confirma qué CAs y qué servicios de rol existen realmente en el bosque
Templates publicadas	Una template no publicada no puede solicitarse desde esa CA
Derechos de enrollment y auto-enrollment	Muestran si identidades de bajo privilegio pueden obtener certificados
ACL de las templates	Determinan quién puede manipular la template
Controles de subject y SAN	Identifican si los solicitantes pueden aportar valores de identidad peligrosos
Edit flags de la CA	Revelan configuraciones globales como `EDITF_ATTRIBUTESUBJECTALTNAME2`
Estado de web enrollment, HTTPS y EPA	Determina si siguen expuestos endpoints relayables
Telemetría de emisión y autenticación con certificados	Prueba si la monitorización realmente ve solicitudes, emisión y autenticación con certificados

Rutas de abuso de templates: ESC1 y las templates de autenticación publicadas

ESC1 es el ejemplo más claro de una ruta de abuso de template. Microsoft Defender for Identity describe la condición peligrosa así: si una certificate template tiene activado Supply in the request y el certificado también es válido para autenticación, los atacantes podrían enroll un certificado válido para usuarios arbitrarios.

En términos prácticos, una ruta ESC1 suele construirse con estas condiciones:

la template está publicada en una CA
identidades de bajo privilegio pueden enroll en ella
la template permite valores de subject o SAN aportados por el solicitante
el certificado puede usarse para autenticación, por ejemplo con un EKU apto para client authentication
no existe un control más fuerte, como manager approval o authorized signatures requeridas, que detenga la emisión

Lo importante no es solo el flag. Una template puede tener un comportamiento de naming arriesgado y aun así no ser una ruta activa si no está publicada o si está restringida a una población de enrollment estrechamente gobernada. En cambio, una template de autenticación publicada, con scope débil y controles de emisión débiles, ya es una ruta de identidad y no solo un problema de higiene de templates.

Por eso la revisión debe hablar de templates de autenticación publicadas y no solo de “templates vulnerables” en abstracto. La publicación determina la explotabilidad.

Rutas de plano de control: ESC4 y ESC6

ESC4 y ESC6 son rutas de plano de control. Son peligrosas porque permiten a un atacante crear o ampliar un comportamiento de emisión explotable aunque la template no empezara en un estado obviamente inseguro.

Con ESC4, el problema está en la ACL del objeto template. Las certificate templates son objetos de Active Directory y sus ACL controlan no solo el enrollment sino también quién puede editar el objeto. Microsoft Defender for Identity destaca explícitamente el riesgo cuando grupos no privilegiados reciben permisos que permiten cambiar configuraciones de la template, como Full Control o WriteDACL. Dicho de otra forma, el atacante no necesita que la template empiece siendo ESC1: puede modificarla hasta convertirla en una.

Con ESC6, el problema pasa de la template a la CA. Si la CA tiene activado el flag EDITF_ATTRIBUTESUBJECTALTNAME2, Microsoft Defender for Identity indica que los usuarios pueden especificar configuraciones SAN en solicitudes de certificados y que eso afecta a las templates, tanto si habilitan individualmente Supply in the request como si no. Eso no significa que cada template se convierta en un botón directo de Domain Admin. Significa que la CA ha ampliado la superficie de control del subject, de modo que cualquier template de autenticación publicada en un scope inadecuado se vuelve mucho más peligrosa.

Estas dos rutas deben revisarse junto con el abuso de permisos y derechos de replicación, porque en el fondo son problemas de gobernanza sobre el plano de control PKI.

Rutas de relay: ESC8 y endpoints de enrollment

ESC8 es diferente del abuso de templates. La ruta depende de endpoints de enrollment relayables y no solo de flags de templates.

Microsoft documenta AD CS web enrollment y certificate enrollment web services como superficies de enrollment HTTP. Microsoft Support KB5005413 explica por qué importa: si los atacantes pueden relayar autenticación NTLM hacia endpoints AD CS vulnerables, pueden obtener certificados que después se usan para ampliar la intrusión. La evaluación ESC8 de Microsoft Defender for Identity precisa aún más la condición al señalar endpoints IIS que aceptan autenticación NTLM sin HTTPS forzado o sin Extended Protection for Authentication (EPA).

Eso hace que ESC8 sea tanto un problema de endpoint y protocolo como un problema PKI. La revisión debe incluir por tanto:

si están instalados CA Web Enrollment o servicios web de enrollment asociados
si siguen accesibles por HTTP
si EPA está realmente forzado
si NTLM sigue aceptándose allí donde Microsoft recomienda deshabilitarlo o restringirlo

Esta ruta también debe leerse junto al endurecimiento general contra relay, como ataques NTLM relay y firma SMB deshabilitada, porque el endpoint de certificados suele ser solo un paso de la cadena.

Dónde encaja weak certificate mapping

Weak certificate mapping importa, pero no es el mismo problema que ESC1, ESC4, ESC6 o ESC8.

El núcleo de las rutas AD CS anteriores trata de cómo se emite un certificado o de cómo puede reabrirse la ruta de emisión. KB5014754 aborda otra capa: cómo los domain controllers evalúan los mappings de autenticación basada en certificados y avanzan hacia un binding más fuerte. Por eso weak mapping debe tratarse como un control adyacente y enlazarse al post dedicado Weak Certificate Mapping in AD CS: Why Strong Binding Matters, no fusionarse aquí como si ya estuviera representado por los cuatro vuln tags ADCS del artículo.

En la práctica, una revisión sólida de AD CS tiene que distinguir dos preguntas:

¿puede un atacante obtener un certificado peligroso?
si existe un certificado peligroso, ¿cómo lo va a vincular el domain controller a una cuenta?

Están relacionados, pero no son la misma ruta de ataque.

Detección

La detección debe correlacionar emisión, cambios del plano de control y telemetría de autenticación. Ningún evento por sí solo demuestra abuso de AD CS.

Telemetría de emisión y configuración de la CA

La guidance de Microsoft sobre advanced audit policy y monitorización PKI sitúa la auditoría de la CA en el centro. Como mínimo, el equipo de seguridad debe saber si la CA produce telemetría de solicitudes y emisión como:

4886 para solicitudes de certificados
4887 para emisión de certificados
4882 para cambios de permisos de seguridad en Certificate Services
4890, 4891 o 4892 para cambios de gestión y configuración en Certificate Services

Estos eventos son útiles porque muestran que hubo una solicitud, una emisión o un cambio de configuración. No demuestran por sí solos que la solicitud fuera maliciosa. Aún hace falta correlacionar el solicitante, la template, el subject previsto y el flujo de negocio esperado.

Telemetría de cambios de objetos Active Directory

Las templates son objetos AD, así que 5136 importa cuando la auditoría está configurada y existen las SACL relevantes. Microsoft documenta 5136 como el evento generado cuando se modifica un objeto de Active Directory. En una revisión AD CS, eso importa para cambios en ACL de templates, cambios en el estado de publicación y otras modificaciones de objeto que convierten una template normal en una ruta de ataque.

Telemetría de autenticación

En el domain controller, 4768 registra solicitudes de TGT. Eso lo hace útil para correlacionar emisión de certificados con patrones posteriores de autenticación, especialmente en cuentas o máquinas que no suelen usar autenticación basada en certificados. Pero 4768 no es un detector AD CS. Es una fuente de correlación entre varias, y gana valor cuando se combina con eventos de emisión de la CA y con una baseline del comportamiento normal de autenticación con certificados.

Evidencia de configuración y exposición

No toda la detección útil está basada en eventos. Algunos de los hallazgos AD CS más importantes son hallazgos de estado:

una template de autenticación publicada sigue siendo enrollable por usuarios de bajo privilegio
una ACL de template sigue concediendo permisos de escritura peligrosos
EDITF_ATTRIBUTESUBJECTALTNAME2 sigue activado
un endpoint de enrollment sigue aceptando condiciones relayables NTLM por HTTP o sin EPA

Esa es una de las razones por las que la supervisión de seguridad AD y los Event IDs que importan debe combinarse con una revisión de configuración repetible y no tratarse como toda la respuesta.

Remediation: prioridades de corrección

El orden correcto es romper primero las rutas activas de emisión, luego endurecer el plano de control, después cerrar las brechas de endpoints y, por último, validar aparte la postura de mapping.

1. Romper las rutas activas de emisión

Empiece por despublicar o restringir las templates que hoy crean la ruta. Microsoft Defender for Identity recomienda explícitamente retirar de publicación una template peligrosa cuando no debería poder solicitarse. Si una template debe seguir disponible, reduzca primero el scope de enrollment antes de hacer limpieza cosmética.

Después retire o limite los comportamientos de subject y SAN aportados por el solicitante cuando no sean estrictamente necesarios. Para las templates que sí deban seguir soportando flujos especiales, aplique controles de emisión más fuertes, como approval o authorized signatures, en lugar de dejar un enrollment amplio a identidades de bajo privilegio.

2. Eliminar las condiciones de abuso del plano de control

Para ESC4, endurezca las ACL de las templates para que grupos no privilegiados no puedan modificar permisos ni configuraciones. Para ESC6, elimine EDITF_ATTRIBUTESUBJECTALTNAME2 salvo que exista una dependencia operativa justificada y revisada.

Revise también quién puede gestionar configuraciones de la CA, publicar templates o delegar la administración PKI. Una corrección sobre la template no es duradera si otro operador o grupo delegado puede restaurar silenciosamente el estado peligroso más tarde.

3. Cerrar superficies de enrollment relayables

Para ESC8, aplique las mitigaciones Microsoft de KB5005413:

deshabilitar roles web de enrollment no utilizados cuando sea posible
exigir HTTPS
habilitar EPA
reducir o deshabilitar la exposición NTLM en endpoints IIS de enrollment donde Microsoft lo recomienda

Si web enrollment no es necesario en producción, eliminarlo suele ser una mejor reducción de riesgo que intentar conservarlo con controles parciales.

4. Tratar weak certificate mapping como endurecimiento adyacente

No confunda el endurecimiento de templates con el endurecimiento del mapping. Si el entorno sigue dependiendo de mappings débiles, trate KB5014754 como una línea de remediación separada y valide explícitamente esos cambios en los domain controllers.

Validación tras la remediación

No dé por cerrada una remediación AD CS hasta poder demostrar que la ruta de ataque está realmente rota desde la misma perspectiva usada en la revisión de seguridad.

La validación debe incluir:

prueba de que las templates vulnerables ya no están publicadas o ya no son enrollables por identidades de bajo privilegio
prueba de que las entradas ACL peligrosas han desaparecido
prueba de que la CA ya no expone EDITF_ATTRIBUTESUBJECTALTNAME2
prueba de que los endpoints de enrollment ya no siguen expuestos por HTTP o sin EPA cuando la ruta dependía de esas condiciones
prueba de que la auditoría de la CA ahora captura solicitudes y emisión de certificados
prueba de que la monitorización AD puede ver cambios de objetos template donde eso importa
prueba de que los certificados arriesgados ya emitidos se revisaron y revocaron cuando correspondía

Aquí es donde un flujo más amplio como auditar la seguridad de Active Directory resulta útil. La validación AD CS no trata de un solo flag: debe demostrar que la ruta de emisión, el plano de control y la ruta de monitorización han cambiado en producción.

Cómo EtcSec mapea las rutas de ataque ADCS

EtcSec debe mantenerse estrecho aquí: mide las condiciones que crean la ruta.

Para las rutas centrales, eso significa mapear findings como:

ESC1_VULNERABLE_TEMPLATE
ESC4_VULNERABLE_TEMPLATE_ACL
ESC6_EDITF_FLAG
ESC8_HTTP_ENROLLMENT

La misma revisión también puede sacar a la luz findings adyacentes que explican por qué la ruta existe o cómo se encadena más allá:

ADCS_WEAK_PERMISSIONS
PATH_CERTIFICATE_ESC

Lo importante no es prometer una detección mágica. El valor está en medir repetidamente el scope de las templates, sus ACL, los flags de la CA y la exposición de los endpoints de enrollment para que la deriva PKI sea visible antes de volver a convertirse en una cadena de escalada.

Rutas de ataque ADCS: cómo errores de certificados se convierten en rutas de escalada en Active Directory