AD CS mal configurado:

cuando la PKI interna es la puerta de atrás (ESC1-ESC8)

Serie Red Team / Active Directory  |  unfantasmaenelsistema.com

Esta serie sobre Active Directory ha ido dibujando un mapa: el modelo de seguridad del directorio, cómo BloodHound revela las rutas de escalada y por qué una cuenta de servicio débil se convierte en Kerberoasting. Falta la pieza que hoy más se explota en auditorías reales y en incidentes: los servicios de certificados de Active Directory, AD CS. Casi todas las organizaciones que despliegan una entidad certificadora interna lo hacen una vez, con las plantillas por defecto, y no vuelven a mirarla en años. Ese olvido es exactamente lo que un atacante busca.

El artículo explica a alto nivel qué es AD CS, por qué un certificado puede valer como identidad en Kerberos, y cuáles son las familias de mala configuración que la comunidad bautizó como ESC1 a ESC8. No es una guía de abuso: no hay peticiones de certificado maliciosas, ni herramientas ofensivas en modo ataque, ni pasos reproducibles de escalada. El foco está en detectar esas configuraciones en tu propia PKI y en remediarlas. Para entender por qué un certificado equivale a confianza conviene tener fresco el artículo de TLS y PKI de esta misma web.

1. Qué es AD CS y por qué importa

AD CS (Active Directory Certificate Services) es el rol de Windows Server que convierte un dominio en su propia autoridad de certificación. Con él, la organización emite certificados internos para cifrar tráfico, firmar código, autenticar equipos con 802.1X, habilitar el inicio de sesión con tarjeta inteligente o dar identidad a servidores web internos sin pagar a una CA pública.

• La CA raíz empresarial se integra en Active Directory: su certificado se publica automáticamente en el contenedor de configuración del bosque y todos los equipos del dominio la consideran de confianza.
• Los certificados se emiten a partir de plantillas (certificate templates): objetos de AD que definen quién puede solicitar el certificado, qué datos lleva, para qué sirve (los EKU) y si hace falta aprobación manual.
• La inscripción (enrollment) puede ser por LDAP/RPC contra la CA o por el endpoint web (Certificate Enrollment Web Service y la Web Enrollment clásica, `certsrv`).
• Un certificado emitido es válido hasta que caduca o se revoca. La revocación en la práctica es lenta y a menudo no se comprueba, así que un certificado indebido es una credencial de larga duración.

El problema de seguridad no está en el software de AD CS, sino en la combinación de dos cosas: plantillas que conceden más de lo que deberían y el hecho de que, en un dominio moderno, un certificado puede usarse para autenticarse como el usuario que figura en él.

2. PKINIT: por qué un certificado vale como identidad

Kerberos admite una extensión llamada PKINIT que permite pedir el primer ticket (el TGT) presentando un certificado en lugar de una clave derivada de la contraseña. La idea legítima es el inicio de sesión con tarjeta inteligente: insertas la tarjeta, el certificado que contiene demuestra quién eres y el KDC te entrega el TGT.

El KDC decide a quién pertenece ese certificado mirando su identidad. Históricamente lo hacía por el campo SAN (Subject Alternative Name): si el certificado dice `userPrincipalName = admin@dominio`, el KDC emite un TGT para esa cuenta. Aquí está el nudo: si una plantilla permite que quien solicita el certificado elija libremente ese SAN, y además el certificado sirve para autenticación de cliente, cualquiera que pueda inscribirse puede pedir un certificado «a nombre de» una cuenta privilegiada.

Un certificado así no caduca cuando la víctima cambia la contraseña. Por eso el abuso de AD CS se considera también una técnica de persistencia: un certificado de administrador emitido hoy puede seguir siendo válido dentro de un año.

3. ESC1-ESC8: el mapa de las malas configuraciones

En 2021 el informe «Certified Pre-Owned» de SpecterOps catalogó las vías de abuso de AD CS y las numeró ESC1 a ESC8 (ESC = Escalation). Desde entonces la lista ha crecido (ESC9, ESC10, ESC11, ESC13, ESC15…), pero las ocho originales cubren la mayoría de lo que se encuentra en una auditoría. Lo que sigue es una descripción de qué condición hace vulnerable cada caso, para que puedas buscarla en tu PKI. No es una receta de explotación.

Hay un patrón común: casi todas terminan igual, en un certificado válido para autenticación a nombre de una cuenta con más privilegios que la del atacante. Cambian la puerta de entrada (una plantilla, un flag de la CA, un permiso mal puesto, el endpoint web), no el resultado. Por eso la defensa se organiza por superficie: plantillas, permisos, configuración de la CA y endpoints.

4. Detección: qué se ve en los logs y en el directorio

AD CS registra la actividad de la CA en el log Application del servidor que aloja el rol, siempre que esté activada la auditoría del rol (`certutil -setreg CA\AuditFilter 127` y la subcategoría de auditoría «Servicios de certificación» en la directiva). Los eventos clave:

Los indicios más útiles no son un evento aislado sino incoherencias:

• Certificado cuyo SAN no coincide con el solicitante. Si la cuenta `becario01` solicita un certificado cuyo `userPrincipalName` es `svc_backup` o `Administrador`, eso no es actividad normal.
• Inscripción en una plantilla de autenticación por parte de cuentas que nunca la usan. Una línea base de «qué cuentas se inscriben en qué plantillas» convierte lo anómalo en evidente.
• Solicitudes al endpoint web (`certsrv`, CES) desde equipos o cuentas inesperadas, sobre todo si la autenticación llega por NTLM y el origen es una cuenta de máquina (indicio de ESC8).
• Uso de PKINIT poco después de emitir un certificado nuevo: un TGT obtenido por certificado minutos después de que ese certificado se emitiera a una cuenta sensible merece una mirada.
• Cambios en objetos de plantilla en AD (atributo `whenChanged` de objetos bajo `CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration`): una plantilla que se modifica fuera de una ventana de cambio planificada es una alerta (ESC4).

# Inventario de SOLO LECTURA de plantillas publicadas y sus banderas (defensivo)
# Requiere el modulo PSPKI (https://github.com/PKISolutions/PSPKI)
Import-Module PSPKI
 
Get-CertificationAuthority | Get-CertificateTemplate |
  Select-Object Name,
    @{n='ClientAuth'; e={ $_.EKU -match 'Client Authentication|Smart Card Logon|Any Purpose' -or -not $_.EKU }},
    @{n='EnrolleeSuppliesSubject'; e={ [bool]($_.EnrollmentFlags -band 0) -or
        ($_.CertificateNameFlag -match 'SubjectAltRequireUpn|EnrolleeSuppliesSubject') }},
    @{n='RequiresManagerApproval'; e={ $_.EnrollmentFlags -match 'PendAllRequests' }},
    RASignatureCount |
  Sort-Object Name | Format-Table -AutoSize
 
# Flag peligroso a nivel de CA (ESC6): debe devolver una linea SIN 'EDITF_ATTRIBUTESUBJECTALTNAME2'
certutil -getreg policy\EditFlags

5. Remediación: cómo se cierra cada superficie

5.1 Plantillas de certificado

• Quita `EnrolleeSuppliesSubject` de toda plantilla de autenticación. El sujeto y el SAN deben construirse a partir de los datos de Active Directory, no de lo que envíe el solicitante. Esto corta ESC1 de raíz.
• Revisa los EKU. Una plantilla de autenticación de cliente no necesita «Any Purpose» ni la ausencia de EKU. Retira «Client Authentication», «Smart Card Logon» y «PKINIT Client Authentication» de las plantillas que no requieran login por certificado (ESC2).
• Exige aprobación del gestor (`CT_FLAG_PEND_ALL_REQUESTS`) en las plantillas sensibles: convierte una emisión automática en una solicitud que alguien tiene que aprobar a mano.
• Requiere firmas de autorización (RA signatures) donde tenga sentido, de modo que la solicitud deba ir firmada por un enrollment agent autorizado (controla ESC3).
• Reduce los permisos de inscripción. «Domain Users» o «Authenticated Users» con permiso de Enroll sobre una plantilla de autenticación es casi siempre un error: limítalo a un grupo concreto.
• Despublica las plantillas que no se usan. Una plantilla que no está publicada en ninguna CA no se puede solicitar. El inventario suele revelar plantillas heredadas que nadie recuerda.

5.2 Configuración de la CA

• Desactiva `EDITF_ATTRIBUTESUBJECTALTNAME2` si está presente (ESC6). Con ese flag, ninguna restricción de plantilla sirve: el solicitante puede inyectar el SAN que quiera.
• Revisa quién tiene `ManageCA` y `ManageCertificates` sobre la CA (ESC7). Deben ser un puñado de administradores de PKI de Tier 0, nadie más.
• Audita los permisos de los objetos de PKI en AD (ESC5): el objeto de la CA, `NTAuthCertificates`, el contenedor `Certificate Templates`, el objeto de configuración de inscripción. Solo Tier 0 debe poder escribir en ellos.
• Trata el servidor de la CA como un sistema de Tier 0, al mismo nivel que un controlador de dominio: sin navegación, sin software de más, administración solo desde estaciones seguras.

5.3 Endpoints de inscripción (ESC8)

• Deshabilita la inscripción web si no se usa. La Web Enrollment clásica (`certsrv`) y el Certificate Enrollment Web Service se instalan a menudo «por si acaso» y casi nunca son necesarios.
• Si el endpoint web es imprescindible, exige HTTPS y activa Extended Protection for Authentication (EPA) en IIS, y deshabilita NTLM en ese endpoint (solo Kerberos). Sin NTLM no hay relay.
• Aplica las mitigaciones generales de NTLM relay: firma de SMB y LDAP, retirada progresiva de NTLM en el dominio, cuentas privilegiadas en «Protected Users». Se detallan en el artículo de NTLM relay.

5.4 Mapeo fuerte de certificados

Lleva el dominio a la fase obligatoria (Enforcement) del endurecimiento de KB5014754, de modo que el KDC exija el identificador fuerte (SID) en el certificado y deje de fiarse del SAN. Antes de activarlo, usa el modo de auditoría para localizar los certificados con mapeo débil que habría que reemitir, y planifica su renovación. Este paso neutraliza el efecto de ESC1, ESC2, ESC3 y ESC6 aunque quede alguna plantilla mal configurada.

6. Practicarlo en el laboratorio

Para ver cómo se audita una PKI hace falta un dominio de Active Directory de pruebas, aislado y sin salida a producción, en un rango 192.168.56.x: un controlador de dominio, un servidor con el rol de CA empresarial y un cliente Windows. Se crean a propósito una plantilla mal configurada (autenticación de cliente con `EnrolleeSuppliesSubject` e inscripción abierta) y otra correcta, para comparar.

• Activa la auditoría de la CA y comprueba que aparecen los Event ID 4886 y 4887 al solicitar y emitir un certificado con una cuenta normal del laboratorio.
• Pasa PSPKIAudit y Locksmith y verifica que ambos marcan la plantilla insegura y no la correcta.
• Corrige la plantilla (quita `EnrolleeSuppliesSubject`, ajusta EKU y permisos) y vuelve a pasar las herramientas: el hallazgo debe desaparecer.
• Revisa en qué fase de KB5014754 está tu DC de laboratorio y prueba a moverlo a auditoría para ver los eventos de mapeo débil.
• Si el endpoint web está instalado, comprueba con una captura en Wireshark si acepta NTLM, y luego aplica EPA y Kerberos-only y confirma el cambio.

Conclusión

AD CS no es peligroso por lo que hace, sino por lo poco que se revisa. Una entidad certificadora interna se despliega una vez, con las plantillas que trae de fábrica y los permisos amplios que facilitan la puesta en marcha, y a partir de ahí se convierte en infraestructura invisible. ESC1 a ESC8 no son ocho exploits distintos: son ocho formas de llegar al mismo sitio, un certificado de autenticación a nombre de una cuenta que no te corresponde, que además sobrevive al cambio de contraseña de la víctima.

La buena noticia es que la remediación es finita y no se compra: inventariar las plantillas, quitar `EnrolleeSuppliesSubject`, recortar EKU y permisos de inscripción, revisar los flags y los roles de la CA, cerrar o endurecer el endpoint web y llevar el dominio a la fase obligatoria del mapeo fuerte de certificados. Con la auditoría de la CA activada y una línea base de quién se inscribe en qué, lo anómalo salta a la vista. Trata tu PKI como lo que es: un sistema de Tier 0, al nivel de un controlador de dominio.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)