Certighost: cuando un usuario de dominio puede acabar obteniendo un certificado de un Domain Controller (CVE-2026-54121)

Si durante los últimos años ha habido una tecnología de Active Directory que ha pasado de ser la gran olvidada a convertirse en uno de los objetivos favoritos de Red Teams y atacantes reales, esa es Active Directory Certificate Services (AD CS). Desde la publicación de Certified Pre-Owned, la comunidad descubrió que una PKI mal configurada podía ser incluso más peligrosa que un Kerberoasting o un abuso de delegaciones.

Ahora llega una nueva vulnerabilidad bautizada como Certighost (CVE-2026-54121), una elevación de privilegios que afecta a Microsoft Active Directory Certificate Services y que, según Microsoft, permite que un usuario autenticado eleve privilegios a través de la red debido a un problema de autorización. La vulnerabilidad ha recibido una puntuación CVSS 8.8 y ya dispone de un Proof of Concept público.

Lo interesante de Certighost no es únicamente la vulnerabilidad, sino el objetivo final. Mientras muchos ataques contra AD CS buscan obtener un certificado válido para un usuario privilegiado, este fallo permite llegar mucho más lejos: conseguir un certificado que representa al propio Domain Controller.

Y cualquiera que haya trabajado con autenticación basada en certificados sabe lo que significa disponer de una identidad de máquina de un DC dentro del bosque.

No estamos hablando simplemente de escalar privilegios a Domain Admin, sino de obtener una identidad que participa directamente en numerosos mecanismos de autenticación de Active Directory.

La PoC

Apenas unas horas después de hacerse pública la vulnerabilidad apareció el repositorio de aniqfakhrul, que implementa un script en python para una prueba de concepto:

Crea una nueva cuenta de equipo (p. ej., GHOSTABCDEFGH$) o reutiliza una existente proporcionada mediante --computer-name.
Inicia dos listeners falsos: un servidor SMB/LSA en el puerto 445 y un servidor LDAP en el puerto 389.
Envía una solicitud de certificado como esa cuenta de equipo, incluyendo un atributo cdc personalizado que apunte a una IP controlada (mediante --listener; opcional, se detecta automáticamente si se omite) y un atributo rmd con el nombre DNS del controlador de dominio (DC) de destino.
La CA se conecta a los listeners LSA/LDAP no autorizados. Estos se autentican como la cuenta creada (validada a través del DC real mediante Netlogon) y responden a las consultas de la CA con la identidad del DC de destino (sAMAccountName, SID, dNSHostName).
La CA emite un certificado válido perteneciente al DC.
El script también ejecuta PKINIT con el archivo pfx del DC para solicitar .ccache y el hash NT.ç

sudo python3 certighost.py -d playground.local -u lowpriv -p 'Password1234' --dc-ip 192.168.1.10

La ejecución correcta escribe el certificado de destino (.pfx) y la caché de Kerberos (.ccache) en el directorio actual.

¿Qué debemos revisar?

Aunque Microsoft ya ha publicado actualizaciones para los sistemas afectados, parchear únicamente no debería ser la única medida.

Una revisión seria debería incluir, como mínimo:

Inventario completo de todas las Enterprise CA.
Revisión de plantillas de certificados.
Permisos de inscripción (Enroll y AutoEnroll).
Mapeo de autenticación mediante certificados.
Auditoría de eventos relacionados con solicitudes de certificados.
Revisión de configuraciones heredadas que permanezcan desde migraciones antiguas.

En muchas organizaciones descubriréis que la PKI lleva años funcionando sin que nadie haya vuelto a revisarla desde su instalación inicial.