Certighost la vulnerabilidad de AD CS que podría convertir a un usuario de dominio en el Controlador de Dominio

El 24 de julio se hizo pública una prueba de concepto que explota una vulnerabilidad en Active Directory Certificate Services (AD CS) —bautizada por sus descubridores como Certighost— y que permite a un usuario de dominio con pocos privilegios conseguir un certificado que identifique a un Controlador de Dominio (Domain Controller) y autenticarse como esa máquina. La gravedad no es simbólica: al autenticar como un DC se abren las puertas para solicitar secretos de cuentas mediante DCSync, incluido el krbtgt, lo que puede desembocar en una compromisión total del dominio mediante tickets forjados y persistencia a largo plazo.

Microsoft calificó el problema como un fallo de autorización y lo asignó como CVE-2026-54121 con una puntuación CVSS de 8.8; el parche para AD CS se publicó el 14 de julio. A diferencia de muchas vulnerabilidades que requieren privilegios elevados o interacción del usuario, este vector exige únicamente acceso de red y una cuenta de dominio estándar. En las pruebas públicas los investigadores usaron una cuenta del grupo Domain Users y se apoyaron en comportamientos por defecto como la cuota ms-DS-MachineAccountQuota (10) para crear o reutilizar cuentas de equipo.

El núcleo técnico reside en la lógica de “chase” del enrolamiento de AD CS: cuando una CA no puede resolver la información del sujeto, el protocolo permite que la petición indique un cdc (el servidor de Active Directory a contactar) y rmd (el objeto de máquina a resolver). Los atacantes pueden engañar a la CA para que se comunique con servicios SMB/LDAP falsos, relé la autenticación al DC real vía Netlogon y devuelva atributos como objectSid y dNSHostName del objetivo, validando así identidad y provocando que la CA firme un certificado con identidad de DC. La prueba de concepto automatiza este encadenamiento, levanta escuchas en puertos 445/389 y produce un PFX y un cache de credenciales Kerberos PKINIT capaces de autenticarse como el Controlador de Dominio.

Que exista una PoC pública hace que el riesgo sea inminente: aunque hasta la fecha no se hayan verificado explotaciones en la naturaleza según reportes primarios, la disponibilidad del exploit significa que equipos de respuesta podrán ver ataques activos rápidamente. Además, el vector explota configuraciones muy comunes: CA de empresa (Enterprise CA), plantilla Machine por defecto y accesibilidad de la CA a servicios SMB/LDAP del atacante.

Microsoft corrigió la falla añadiendo validaciones antes de seguir una chase; la actualización introduce comprobaciones que rechazan literales IP, nombres demasiado largos y metacaracteres LDAP, exige exactamente un objeto de equipo cuyo nombre DNS coincida y que tenga el flag SERVER_TRUST_ACCOUNT, y realiza comparaciones de SID para evitar sustituciones de objetos. Esta verificación está incluida en el binario de la CA y es la mitigación correcta y definitiva, por lo que las organizaciones con Enterprise CA deben instalar los parches de Microsoft en los hosts de AD CS inmediatamente. Para referencia general sobre AD CS y su arquitectura consulte la documentación oficial de Microsoft en https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/ad-cs-overview.

Cuando aplicar parches no sea posible de forma inmediata, los autores documentaron una mitigación temporal que deshabilita la flag de chase en la política de la CA: ejecutar certutil para modificar EditFlags y reiniciar el servicio CertSvc. Ese cambio puede interrumpir flujos legítimos de enrolamiento, por lo que los investigadores y Microsoft recomiendan probarlo en un entorno controlado antes de desplegarlo en producción. La utilidad certutil y sus parámetros están documentados por Microsoft en https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil.

En términos de detección y respuesta, hay acciones concretas que deben priorizarse: auditar la creación reciente de cuentas de equipo y cambios en la ms-DS-MachineAccountQuota, revisar los registros de la CA por solicitudes de enrolamiento que usen atributos cdc/rmd, monitorizar actividad PKINIT inusual y operaciones DCSync o peticiones LDAP anómalas. Si hay indicios de compromiso, la respuesta debe incluir la rotación del krbtgt (idealmente dos veces por seguridad) y la investigación forense de accesos a la CA y a los DC afectados.

Además de parchear y monitorizar, conviene tomar medidas de hardening: restringir qué hosts pueden comunicarse con la CA en puertos SMB/LDAP, limitar derechos de inscripción en plantillas de certificado, revisar delegaciones que permitan crear cuentas de equipo y segmentar las CA para que no estén directamente accesibles desde estaciones de trabajo de bajo privilegio. La defensa en profundidad reduce la probabilidad de que un usuario con permisos mínimos pueda alcanzar la cadena completa de explotación.

La comunidad debería seguir la evolución del caso en fuentes de referencia técnica; el registro oficial de la vulnerabilidad en la base de datos nacional de vulnerabilidades puede consultarse en https://nvd.nist.gov/vuln/detail/CVE-2026-54121. También es importante mantenerse alerta frente a actualizaciones y guías adicionales de Microsoft o de CERT nacionales que proporcionen indicadores de compromiso y procedimientos de remediación específicos.

Para equipos de TI y seguridad la recomendación es clara: priorizar la instalación del parche en todos los servidores AD CS, probar cuidadosamente cualquier mitigación temporal como la desactivación de chase, y ejecutar una caza de anomalías centrada en certificados de máquina no habituales, creación de cuentas de equipo y señales de uso de DCSync. La combinación de parche, monitorización y endurecimiento de la CA reduce significativamente el riesgo de que una vulnerabilidad como Certighost derive en un compromiso de dominio completo.