Un usuario de dominio normal —de esos que solo pueden imprimir y abrir el correo— podía, con una cuenta cualquiera y sin permisos de administrador, hacerse pasar por un Domain Controller y salir de ahí con las llaves de todo el dominio. Se llama Certighost, es la CVE-2026-54121, y no fue un fallo del kernel ni un 0-day exótico: fue la parte de Windows que emite confianza —los certificados— fiándose de quien no debía.
Microsoft lo corrigió en el Patch Tuesday del 14 de julio de 2026. Los investigadores que lo encontraron —H0j3n y Aniq Fakhrul— publicaron el 24 de julio un PoC completamente funcional. Es decir: llevas diez días con el parche disponible y ahora hay código público que lo explota. Si tu directorio activo tiene una CA integrada (y muchos la tienen sin saberlo), este post es tu plan del día.
Certighost en una frase (y por qué duele tanto)
Active Directory Certificate Services (AD CS) es la autoridad de certificación que muchas empresas montan dentro de su dominio Windows. Al emitir un certificado, si la CA no consigue toda la información de la entidad final, el protocolo de inscripción permite un mecanismo de reserva llamado chase: el solicitante puede aportar unos atributos —cdc (qué servidor de directorio consultar) y rmd (qué objeto de máquina resolver)— para que la CA vaya a buscar los datos que le faltan.
El fallo: la CA seguía al host que le pasaba el solicitante sin comprobar antes que fuera un Domain Controller de verdad. El atacante levantaba servicios LDAP y SMB falsos, respondía con la identidad de un DC real (su SID y su nombre), y la CA firmaba esa identidad en el certificado. Con un certificado que dice "soy un Domain Controller", el resto es de manual: una credencial Kerberos con derechos de replicación, un DCSync para sacar el hash de la cuenta krbtgt y, con eso, control total del dominio. Microsoft lo clasificó como autorización indebida con un CVSS de 8,8.
El detalle que lo hace tan accesible: el atacante necesitaba una cuenta de máquina para dar identidad válida, y ahí entra otra pieza. Por defecto, cualquier usuario del dominio puede crear hasta 10 cuentas de máquina (el atributo ms-DS-MachineAccountQuota vale 10). No hace falta ser administrador de nada. Solo tener un usuario y estar en la red.
Esto no es un bug suelto: AD CS lleva años siendo el atajo favorito
Si Certighost te suena a algo, es porque no es el primero. Desde que en 2021 SpecterOps publicó la primera familia de técnicas de escalada de AD CS —hoy ampliada hasta las ESC1–ESC16—, la autoridad de certificación se ha convertido en uno de los caminos más limpios de "usuario normal" a "administrador del dominio". La razón es de fondo: la CA es la máquina que fabrica identidad. Quien consigue que emita un certificado a su nombre —o al de un DC— no necesita robar una contraseña: se la firma la propia infraestructura de confianza.
Y aquí está la parte incómoda: AD CS suele montarse una vez, "para que el WiFi con certificado y el VPN funcionen", y luego nadie vuelve a mirarlo. No sale en el inventario de aplicaciones, no tiene un dueño claro, y sus plantillas de certificado —donde vive la mayor parte de las malas configuraciones— las tocó alguien hace tres años. El parche de Certighost tapa este agujero; no te dice si la plantilla que permite que un usuario ponga su propio nombre de sujeto (el clásico ESC1) sigue ahí abierta desde 2019.
El plan del día: qué hacer, en este orden
No es una lista de 20 puntos. Son cinco decisiones, ordenadas por lo que de verdad reduce el riesgo:
- 1Parchea. La actualización de julio de 2026 es la solución definitiva: añade una validación (
_ValidateChaseTargetIsDC) que comprueba que el objetivo es un DC real —rechaza IPs literales, nombres con caracteres de inyección LDAP y exige que la cuenta tenga el flagSERVER_TRUST_ACCOUNT—. Hay una mitigación temporal para quien no pueda parchear ya (deshabilitar el chase concertutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDCy reiniciarCertSvc), pero los propios investigadores solo la probaron en laboratorio: es un torniquete, no la cura. - 2Averigua si tienes AD CS —y cuántas CAs—. Suena absurdo, pero es el paso que más gente se salta. Muchos dominios heredan una CA que montó un consultor hace años para un proyecto puntual y que sigue viva, emitiendo, sin dueño. Si no está en tu inventario, no lo estás parcheando ni vigilando.
- 3Baja
ms-DS-MachineAccountQuotaa 0. Que un usuario normal no pueda crear cuentas de máquina corta la primitiva que necesitan Certighost y media docena de ataques más (relay NTLM, RBCD…). Solo los administradores o cuentas delegadas deberían unir equipos al dominio. Es un cambio de un valor, gratis, y quita una palanca a un montón de técnicas a la vez. - 4Audita las plantillas y los permisos de la CA. Aquí es donde vive el riesgo crónico. Herramientas como
Certipy(en modo find),LocksmithoPSPKIAuditte revisan la familia ESC1–ESC16 y te dicen qué plantilla deja pedir un certificado con nombre de sujeto arbitrario, quién puede inscribirse y dónde falta la aprobación del gestor. Lo que un atacante usa para encontrar el agujero, tú lo usas para taparlo antes. - 5Reduce la exposición y mira los logs correctos. El servidor de la CA y su inscripción web no tienen por qué ser alcanzables desde toda la red plana; segméntalos. Y ten vigilada la emisión de certificados y los eventos de replicación de directorio (DCSync): una petición de certificado rara o un DCSync desde algo que no es un DC es exactamente la señal que quieres ver a tiempo.
Lo que NO haríamos
- ✗Desmantelar AD CS en caliente por pánico. Media red depende de esos certificados (WiFi, VPN, autenticación de máquinas). Arrancarlo de golpe rompe más de lo que arregla. Se parchea, se audita y se ordena; no se amputa a ciegas.
- ✗Dar por cerrado el tema con el parche. El parche mata Certighost, no las plantillas mal configuradas que llevan años ahí. Aplicar la actualización y no auditar la CA es cambiar la cerradura de la puerta principal dejando la ventana abierta.
- ✗Asumir que "es de Microsoft, ya estará bien". AD CS es un componente que instalas y configuras tú; su seguridad depende de cómo dejaste las plantillas y los permisos, no de una casilla del fabricante. La responsabilidad de la configuración es de casa.
El fondo del asunto: el plano que emite confianza vale más que cualquier servidor
Certighost es un caso más de un patrón que vemos una y otra vez: lo que de verdad hay que proteger no es "un servidor", sino el sistema que fabrica identidad y confianza —la CA, el controlador de dominio, el proveedor de identidad—. Un atacante que dobla ese plano no necesita robarte nada: se emite a sí mismo el permiso. Por eso el privilegio mínimo (que un usuario cualquiera no pueda crear cuentas de máquina), la premisa de asumir la brecha (vigilar como si ya estuvieran dentro) y auditar la configuración en vez de confiar en el estado por defecto no son eslóganes de Zero Trust: son el trabajo.
No todos nuestros clientes corren AD CS, pero los que tienen un directorio activo con una CA integrada casi nunca la han mirado desde que se montó. Y ese "casi nunca" es justo el hueco por el que se cuelan estas cosas.
Fuentes (verificadas): mecanismo, atributos cdc/rmd, parche _ValidateChaseTargetIsDC, mitigación y cronología (reportado 14-may, parche 14-jul, PoC 24-jul-2026) — cybersecuritynews.com y The Hacker News; PoC original de H0j3n y Aniq Fakhrul — gist de H0j3n; familia ESC1–ESC16 y auditoría con Certipy/Locksmith/PSPKIAudit — investigación pública de AD CS. CVSS 8,8 y ausencia de explotación confirmada en CISA KEV a 24-jul-2026.
¿Sabes qué hay dentro de tu directorio activo —y quién puede fabricar identidad en él?
En everyWAN auditamos configuraciones de identidad y seguridad sin vender licencias de nadie: te decimos qué está mal puesto y qué mueve la aguja. Revisamos tu postura de ciberseguridad y te acompañamos en la consultoría para dejarla ordenada, antes de que sea un incidente.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN