Si todavía no leíste la primera publicación de esta serie, te recomendamos comenzar por ahí. En esa entrada revisamos qué es AD CS, cómo funciona dentro de Active Directory y por qué terminó convirtiéndose en una superficie de ataque crítica en muchos entornos corporativos.
En esta segunda parte dejamos la teoría y pasamos a la explotación. Vamos a analizar ESC1: una de las configuraciones inseguras más conocidas en AD CS, donde una plantilla de certificados mal configurada permite solicitar certificados para identidades arbitrarias dentro del dominio.
¿Qué es ESC1?
ESC1 es una mala configuración en las plantillas de certificados, y es una de las más comunes y peligrosas que existen.
El problema está en la opción "Supply in the request" dentro de la configuración de la plantilla. Cuando esta opción está habilitada en una plantilla que permite Client Authentication, el usuario que solicita el certificado puede indicar libremente quién quiere ser, usando el campo Subject Alternative Name (SAN).
Para explicarlo un poco mejor: un usuario normal del dominio puede pedirle a la CA un certificado que diga que es el Administrador del dominio. Y si además no hay Manager Approval requerido y los permisos de enrollment son amplios, la CA lo emite sin preguntar nada.
Para que ESC1 sea explotable, se tienen que cumplir estas condiciones al mismo tiempo:
Si falta alguna de esas condiciones, el ataque no funciona o se complica significativamente.
Explotación de ESC1
Entorno del laboratorio
| Componente | Detalle |
|---|---|
| Domain Controller | DC1-COFIACORE (Windows Server 2019) |
| CA | cofiacore-DC1-COFIACORE-CA |
| Atacante | Kali Linux + Certipy v5.0.2 |
| Usuario utilizado | wladimir.hernandez (usuario del dominio sin privilegios) |
| Objetivo | Obtener acceso como Administrador del dominio |
| Herramientas | Certipy v5.0.2, NetExec (nxc) |
El laboratorio cuenta con tres usuarios de dominio estándar sin privilegios: wladimir.hernandez, david.soto y hugo.sandoval. Ninguno tiene permisos administrativos. La demostración será desde wladimir.hernandez para mostrar que cualquier cuenta de dominio es suficiente para ejecutar el ataque.
Para esta demostración usaremos Certipy desde Kali Linux. Existen otras herramientas que pueden lograr el mismo resultado dependiendo del entorno, como Certify en Windows o ForgeCert, pero para este laboratorio trabajaremos con Certipy.
Paso 1: Enumerar plantillas vulnerables
Lo primero es identificar qué plantillas tienen la configuración vulnerable. Certipy consulta LDAP y evalúa los atributos de cada plantilla automáticamente.
bashcertipy-ad find \ -u wladimir.hernandez@cofiacore.local \ -p 'P@ssw0rd123!' \ -dc-ip 192.168.229.10 \ -stdout
En la salida, Certipy devuelve el detalle de cada plantilla. Los campos que confirman que ESC1 es explotable en este entorno serían:
Certipy confirma las cuatro condiciones de explotabilidad en la plantilla ESC1-Vulnerable
Esas cuatro condiciones juntas son lo que hace explotable esta plantilla. Si cualquiera de ellas cambia, el ataque se complica o no funciona.
Paso 2: Solicitar un certificado como Administrador
Con la plantilla identificada, solicitamos un certificado especificando el UPN del Administrador en el campo SAN. Acá es donde ocurre el abuso real: le estamos diciendo a la CA que emita un certificado a nombre de Administrador, usando las credenciales de wladimir.hernandez.
bashcertipy-ad req \ -u wladimir.hernandez@cofiacore.local \ -p 'P@ssw0rd123!' \ -ca 'cofiacore-DC1-COFIACORE-CA' \ -template 'ESC1-Vulnerable' \ -upn 'administrador@cofiacore.local'
Certipy solicita un certificado para administrador@cofiacore.local usando credenciales de wladimir.hernandez
La CA acaba de firmar un certificado que identifica a wladimir.hernandez como el Administrador del dominio.
Paso 3: Autenticarse con el certificado
Con el archivo PFX obtenido, nos autenticamos vía PKINIT. Kerberos recibe el certificado, lo valida contra la CA que lo firmó, y entrega un TGT para Administrador.
bashcertipy-ad auth \ -pfx administrador.pfx \ -dc-ip 192.168.229.10
Certipy auth obtiene el TGT y el hash NTLM del Administrador vía PKINIT
El resultado es el hash NTLM del Administrador. Desde aquí hay varias rutas posibles, la más directa es el volcado de credenciales del dominio.
Paso 4: Volcado de credenciales del dominio
Con el hash NTLM del Administrador usamos NetExec para volcar el NTDS, que contiene los hashes de todas las cuentas del dominio.
bashnxc smb 192.168.229.10 \ -u administrador \ -H 6a86228f2c48d4c0e225b97877e69a6d \ --ntds
NetExec volcando el NTDS completo del Domain Controller con el hash del Administrador
Un detalle importante: en Windows Server 2019, NetExec advierte que el volcado del NTDS puede crashear el DC. En un entorno de producción real hay que evaluar ese riesgo antes de ejecutarlo.
El resultado muestra los hashes de todas las cuentas del dominio: Administrador, krbtgt, usuarios del dominio y cuentas de equipos. Con el hash de krbtgt un atacante puede crear Golden Tickets y mantener acceso indefinido aunque se cambien todas las contraseñas.
Detección de ESC1
Un aspecto que no suele mencionarse en otros análisis sobre la detección de ESC1 es que la auditoría de AD CS no viene habilitada por defecto, al menos en Windows Server 2019. Durante nuestras pruebas ejecutamos el ataque completo y observamos que el Security Log no registraba ningún evento relacionado.
Sin habilitar previamente esta auditoría, los eventos asociados a la solicitud y emisión de certificados por parte de la CA simplemente no se generan, lo que provoca que el ataque pueda pasar completamente desapercibido. Por ello, antes de definir reglas de detección o indicadores de compromiso, es fundamental verificar que el registro de eventos correspondiente se encuentre correctamente habilitado.
Habilitar auditoría de certificados
Paso 1 — Habilitar auditoría en la CA
En el servidor que actúa como Autoridad de Certificación (CA), abrir la consola de administración de AD CS:
certsrv.msc → Propiedades de la CA → pestaña Auditoría
Habilitar las siguientes opciones:
Finalmente, aplicar y guardar los cambios.
Pestaña Auditoría de la CA en certsrv.msc con opciones de registro habilitadas
Paso 2 — Habilitar auditoría de seguridad mediante GPO
En el servidor donde se encuentra instalado AD CS, habilitar la auditoría avanzada siguiendo la siguiente ruta:
Configurar la política para registrar:
GPO de auditoría avanzada configurada para registrar eventos de servicios de certificación
Paso 3 — Aplicar las políticas configuradas
Una vez habilitada la auditoría, aplicar las políticas y reiniciar el servicio de certificados:
powershellgpupdate /force net stop certsvc net start certsvc
Paso 4 — Verificación
Para comprobar que la auditoría quedó correctamente habilitada, revisar el siguiente registro en el Event Viewer:
Event Viewer → Registros de Windows → Seguridad
Los eventos más relevantes para la detección de actividad asociada a certificados son:
Event Viewer mostrando eventos 4886 y 4887 tras habilitar la auditoría en la CA
Implementación en Wazuh
En nuestro laboratorio implementamos esta lógica de detección en Wazuh como un ejemplo práctico de monitoreo de abuso de certificados. La regla distingue dos escenarios principales:
Reglas de detección implementadas en Wazuh para alertas CRITICAL y MEDIUM-HIGH de abuso de AD CS
Hoy en día es muy fácil encontrar reglas para este tipo de detección en distintos SIEM usando su propio lenguaje: Splunk con SPL, Microsoft Sentinel con KQL, o adaptando reglas Sigma públicas. Incluso algunos simuladores de adversario ya incluyen casos de uso para este tipo de ataque.
Sin embargo, lo realmente importante no es la herramienta utilizada, sino comprender la lógica detrás de la detección. La efectividad de cualquier regla dependerá del contexto específico de cada organización: cómo se identifican las cuentas privilegiadas, qué plantillas de certificados están en uso y cuál es el comportamiento considerado legítimo dentro del entorno.
Sin ese conocimiento contextual, una regla genérica copiada de otra implementación probablemente terminará generando falsos positivos o, en el peor de los casos, permitirá que una actividad maliciosa pase inadvertida.
Una condición previa que no hay que olvidar: si tu SIEM no está recolectando los eventos del servidor CA, cualquier regla que configures no va a detectar nada. El primer paso siempre es verificar que los eventos se estén generando y llegando al SIEM.
Lo que dispara la alerta es siempre la misma lógica: la discrepancia entre quien solicitó el certificado y el UPN del certificado emitido.
Mitigación e impacto operacional
Todas las medidas descritas en esta sección se aplican directamente sobre Active Directory y la Autoridad de Certificación (CA), sin necesidad de herramientas de terceros. Las mitigaciones se presentan ordenadas de menor a mayor impacto operacional.
Mitigación 1 — Deshabilitar "Supply in the request"
Esta es la mitigación principal y la de menor impacto operacional.
La vulnerabilidad se encuentra en la pestaña Subject Name de la plantilla de certificado. Mientras la opción esté configurada como "Supply in the request", cualquier usuario puede definir libremente el Subject Alternative Name (SAN).
En certsrv.msc → Plantillas de certificado → clic derecho sobre la plantilla → Propiedades → pestaña Nombre del sujeto
Modificar la configuración de "Proporcionado por el solicitante" a "Construido a partir de esta información de Active Directory".
Plantilla con Subject Name cambiado de Supply in the request a Construido a partir de esta información de Active Directory
Después de aplicar el cambio, al ejecutar nuevamente el escaneo la plantilla ya no debe aparecer como vulnerable:
bashcertipy-ad find \ -u wladimir.hernandez@cofiacore.local \ -p 'P@ssw0rd123!' \ -dc-ip 192.168.229.10 \ -stdout
Certipy rescan confirma que la plantilla ya no aparece como vulnerable tras la mitigación
La plantilla deja de aparecer en la sección de vulnerabilidades del escaneo, por lo que ESC1 se considera mitigado.
Impacto operacional: Muy bajo. El único impacto potencial se da en aquellos casos donde algún proceso legítimo dependía de la especificación manual de SANs. Antes de aplicar el cambio, es recomendable revisar los eventos 4887 de los últimos 90 días.
Mitigación 2 — Deshabilitar plantillas no utilizadas
Si una plantilla no presenta uso real en el entorno, la medida más sencilla es retirarla de la publicación en la CA.
En certsrv.msc → Plantillas de certificado → clic derecho sobre la plantilla → Eliminar
Esto no elimina la plantilla del Active Directory, únicamente la despublica de la CA. Antes de aplicar este cambio, verificar la actividad de los últimos 90 días:
powershellGet-WinEvent -ComputerName DC1-COFIACORE ` -FilterHashtable @{ LogName = 'Security' Id = 4887 StartTime = (Get-Date).AddDays(-90) } | Select-Object -ExpandProperty Message | Select-String 'CertificateTemplate'
PowerShell verificando la actividad de la plantilla en los últimos 90 días con Get-WinEvent
Impacto operacional: Nulo, siempre que la plantilla no presente actividad en el entorno.
Mitigación 3 — Restringir permisos de Enrollment
Otra medida clave consiste en limitar el permiso de Enroll a los usuarios o grupos estrictamente necesarios. Es importante evitar asignaciones amplias, como Domain Users o Authenticated Users, y restringir el uso de la plantilla únicamente a los grupos que realmente lo requieren.
En certsrv.msc → Plantillas de certificado → clic derecho → Propiedades → pestaña Seguridad
Remover el permiso Inscribir (Enroll) para grupos amplios como Usuarios del dominio.
Pestaña Seguridad de la plantilla: removiendo el permiso Enroll de Domain Users
Impacto operacional: Bajo a medio. Es necesario identificar previamente qué usuarios o servicios dependen de la plantilla antes de aplicar la restricción.
Mitigación 4 — Habilitar Manager Approval
Esta medida introduce un control adicional en el flujo de emisión de certificados, de modo que toda solicitud queda en estado pendiente hasta que un administrador de la CA la apruebe manualmente. Esto impide que un atacante pueda completar el proceso de forma totalmente automatizada.
En certsrv.msc → Plantillas de certificado → clic derecho → Propiedades → pestaña Requisitos de emisión
Habilitar la opción "Aprobación del administrador de certificados de CA".
Manager Approval habilitado en la pestaña Requisitos de emisión de la plantilla
Impacto operacional: Medio. Elimina la inmediatez en la obtención de certificados. Cualquier flujo de auto-inscripción o despliegue automatizado de servicios requerirá intervención humana.
Resumen de mitigaciones
| Mitigación | Impacto operacional | Prioridad |
|---|---|---|
| Deshabilitar plantillas no usadas | Ninguno | Inmediata |
| Deshabilitar Supply in the request | Muy bajo | Inmediata |
| Restringir permisos de Enrollment | Bajo a medio | Planificada |
| Habilitar Manager Approval | Medio | Selectiva |
Nota: Deshabilitar "Supply in the request" mitiga específicamente ESC1. Sin embargo, para una postura de seguridad más completa, se recomienda complementar esta medida con la restricción de permisos de enrollment y la revisión del resto de plantillas mediante herramientas como Certipy.
Las vulnerabilidades en AD CS rara vez se presentan de forma aislada, por lo que es habitual que existan múltiples configuraciones débiles encadenables dentro del entorno.
Conclusión
ESC1 evidencia un punto crítico: no es necesario explotar una vulnerabilidad de software para comprometer un dominio completo. Una única configuración incorrecta en una plantilla de certificados puede ser suficiente para habilitar un escenario de escalamiento de privilegios.
Lo descrito en este artículo representa solo el punto de partida. En la siguiente publicación abordaremos ESC2, donde el problema ya no se centra en el SAN, sino en los EKUs (Extended Key Usage). El impacto es equivalente, aunque el vector de abuso es distinto.
Wladimir Hernandez
CEO
CEO de Cofiacore con más de 10 años de experiencia en ciberseguridad ofensiva y defensiva. Especialista en pruebas de penetración web, análisis de vulnerabilidades y operaciones de Red Team.
