El 24 de julio de 2026 se publicó el análisis técnico completo de Certighost, junto con una prueba de concepto funcional. Se trata de una vulnerabilidad en Active Directory Certificate Services (AD CS) —la infraestructura de llave pública que Microsoft incluye con Windows Server— que permitía a un usuario de dominio sin privilegios obtener un certificado que lo identificaba como un Domain Controller. Con ese certificado, el atacante podía autenticarse como el DC y, desde ahí, ejecutar DCSync para extraer el secreto de la cuenta krbtgt.

Microsoft corrigió el problema el 14 de julio de 2026 como CVE-2026-54121, con puntaje CVSS 8.8. Al momento de la divulgación pública no se había reportado explotación activa en el mundo real. Eso no es motivo para relajarse: ahora existe una herramienta pública que automatiza la cadena completa en un solo comando, y el tiempo entre «PoC publicada» y «usada en un incidente» hoy se mide en días.

Queremos explicar qué ocurrió, por qué nos parece relevante para las empresas de Panamá y la región, y qué debería hacer un equipo de TI esta semana.

Lo que dice el aviso de Microsoft

Vale la pena partir de la fuente oficial antes que de los titulares. Así clasifica Microsoft esta vulnerabilidad en el Security Update Guide:

• Componente afectado: el rol de Active Directory Certificate Services en Windows Server.
• Severidad: Crítica. Tipo: elevación de privilegios.
• CVSS: 8.8, con impacto alto en confidencialidad, integridad y disponibilidad.
• Debilidad subyacente: CWE-285, autorización incorrecta.
• Vector: red, baja complejidad de ataque, privilegios bajos requeridos y sin interacción del usuario.
• Fecha de corrección: 14 de julio de 2026.

Ese conjunto —red, baja complejidad, sin interacción del usuario— es lo que convierte a esta vulnerabilidad en un candidato natural para operaciones de ransomware, que normalmente ya cuentan con una cuenta de dominio obtenida por phishing o robo de credenciales. La lista exacta de productos y builds afectados está en el aviso oficial; conviene contrastarla con su inventario antes de planificar el despliegue:

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-54121

Qué es AD CS y por qué está en su red aunque nadie lo pidió

AD CS es la implementación de PKI de Microsoft, integrada a Active Directory. Emite certificados X.509 para cifrado, firma, comunicaciones seguras y autenticación. En la práctica, un certificado funciona como una prueba de identidad firmada: igual que un ticket de Kerberos, se presenta durante la autenticación para demostrar quién es un usuario o un equipo.

Las plantillas de certificado controlan el proceso de inscripción: quién puede solicitar, para qué sirve el certificado, qué información de identidad debe contener y si la CA puede aceptar datos suministrados dentro de la solicitud.

Aquí está el punto que vemos repetirse en nuestras evaluaciones. AD CS se instala con frecuencia «porque hacía falta para el Wi-Fi corporativo» o «para el VPN», y después nadie lo vuelve a mirar. Termina tratado como un servidor más del inventario cuando en realidad es infraestructura de identidad, tan crítica como un Domain Controller.

Cómo funcionaba el ataque

El «chase»: una consulta de respaldo poco conocida

En ciertos escenarios de inscripción entre controladores de dominio, la CA puede realizar una segunda consulta al directorio. Los investigadores llaman a ese comportamiento chase. Dos atributos de la solicitud influyen en esa consulta:

• cdc (Client DC): identifica el host que la CA debe contactar.
• rmd (Remote Domain): identifica el principal que la CA debe buscar.

Cuando ambos atributos están presentes, la CA se conecta por SMB y LDAP al host indicado en cdc y busca allí el principal indicado en rmd.

El error: confiar en la dirección que entrega el solicitante

La CA aceptaba el destino del chase suministrado por el solicitante sin comprobar antes que ese host fuera realmente el Domain Controller que decía ser. Eso hacía posible la siguiente secuencia:

1. El atacante, con una cuenta de dominio común, crea una cuenta de máquina aprovechando ms-DS-MachineAccountQuota (valor por defecto: 10).
2. Levanta servicios falsos de LDAP y LSA en un host bajo su control.
3. Envía una solicitud de certificado a nombre de esa cuenta de máquina, con el atributo cdc apuntando a su propio host y rmd nombrando al Domain Controller objetivo.
4. La CA se conecta de vuelta a los servicios falsos. Estos se autentican como la cuenta de máquina recién creada —validándose contra el DC real a través de Netlogon— y responden las consultas de la CA con la identidad del DC objetivo: sAMAccountName, SID y dNSHostName.
5. La CA emite un certificado válido que pertenece al Domain Controller.
6. Con ese certificado, el atacante ejecuta PKINIT para obtener credenciales Kerberos y el hash NT de la cuenta del DC.
7. Como las cuentas de DC tienen derechos de replicación de directorio, ejecuta DCSync y extrae el secreto de krbtgt.

Un detalle relevante: la cuenta de máquina creada por el atacante es un principal de dominio válido, y eso bastaba para que el endpoint controlado por él superara las verificaciones de autenticación que la CA esperaba, aunque no fuera el Domain Controller suplantado.

La cadena tenía requisitos. Necesitaba una CA Enterprise que siguiera la ruta vulnerable, inscripción a través de la plantilla Machine por defecto, y conectividad de red desde la CA hacia los listeners SMB y LDAP del atacante. No es una vulnerabilidad remota sin autenticación. Pero esos requisitos se cumplen en una cantidad incómoda de dominios corporativos con configuración estándar.

Qué cambió con la actualización de julio

La actualización del 14 de julio modifica la ruta de procesamiento de solicitudes en el módulo de política de la CA. Antes de continuar un chase, la CA ahora valida el destino contra Active Directory:

• Rechaza valores vacíos, nombres excesivamente largos y direcciones IP literales, tanto IPv4 como IPv6.
• Rechaza caracteres que podrían usarse para manipular el filtro LDAP.
• Consulta el directorio para confirmar que el destino corresponde a un objeto de equipo real cuyo userAccountControl incluye el bit SERVER_TRUST_ACCOUNT (8192), es decir, un Domain Controller legítimo.
• Después de resolver el objeto, compara el SID para impedir la sustitución de objetos.

Solo si todas esas verificaciones pasan, la CA continúa con el chase y emite el certificado.

Un matiz técnico que conviene conocer: la nueva validación está detrás de una compuerta de servicio (servicing feature gate) en el binario de julio. La protección aplica cuando esa compuerta y su ruta de validación están activas.

Por qué esto importa si su empresa «ya está en la nube»

Es una conversación que tenemos casi todas las semanas. Una empresa migró correo y archivos a Microsoft 365, invirtió en MFA y políticas de acceso condicional, y asume que el Active Directory local pasó a ser un tema secundario.

En un entorno de identidad híbrida no lo es. Si un atacante obtiene el secreto de krbtgt, controla la autenticación Kerberos de todo el dominio local. Desde ahí puede moverse hacia las cuentas privilegiadas que se sincronizan con Entra ID, hacia los servidores que alojan los conectores de sincronización y hacia cualquier servicio que confíe en esas identidades. La nube hereda la confianza que usted deposita en su directorio local.

Por eso insistimos en el mismo principio con nuestros clientes: la seguridad de su tenant de Microsoft 365 tiene como piso la seguridad de su Active Directory. Ninguna política de acceso condicional compensa un dominio comprometido en la raíz.

Plan de acción

Esta semana

1. Inventaríe sus CA. Muchas organizaciones no saben con certeza cuántas autoridades certificadoras Enterprise tienen activas ni quién las administra. Ese es el primer entregable.
2. Aplique las actualizaciones de seguridad de julio de 2026 a todos los hosts de AD CS. Es la remediación recomendada.
3. Valide el resultado en un ambiente de staging que refleje su producción, incluyendo los flujos de inscripción legítimos que hoy dependan de la CA.

Si no puede parchar de inmediato

Los investigadores describen una mitigación temporal: deshabilitar el comportamiento de chase limpiando el flag correspondiente en la CA y reiniciando el servicio de Certificate Services.

certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC

Restart-Service CertSvc -Force

Con las advertencias que los propios investigadores señalan:

• Es una mitigación, no un parche. Si el flag se vuelve a habilitar en una CA sin actualizar —por un administrador, una imagen de sistema o una política de grupo— la vulnerabilidad vuelve a ser explotable.
• Fue validada solo en un laboratorio controlado, no sobre una CA de producción. Debe probarse primero en staging.
• Cualquier flujo de inscripción legítimo que dependa del fallback de chase dejará de funcionar una vez limpiado el flag.
• La actualización de julio sigue siendo la remediación recomendada.

Reducir la superficie, más allá de este CVE

• Revise ms-DS-MachineAccountQuota. El valor por defecto de 10 permite que cualquier usuario del dominio cree cuentas de máquina, y esa capacidad aparece como paso inicial en múltiples cadenas de ataque contra Active Directory, no solo en esta. En la mayoría de las organizaciones la creación de cuentas de equipo debería estar delegada a un grupo específico y este valor en cero. Sea claro sobre el alcance de esta medida: la prueba de concepto permite reutilizar una cuenta de máquina existente en lugar de crear una nueva, así que bajar la cuota sube el costo del ataque pero no cierra la ruta por sí sola.
• Segmente sus CA. Una autoridad certificadora no debería tener conectividad de red arbitraria hacia estaciones de trabajo. En esta cadena, la CA necesitaba alcanzar los puertos SMB (445) y LDAP (389) del host del atacante.
• Retire AD CS si no lo usa. Es la mitigación más efectiva y la que menos se aplica.
• Trate sus CA como Tier 0. Las mismas políticas de administración, el mismo aislamiento y los mismos controles de acceso privilegiado que aplica a sus Domain Controllers.

Qué monitorear

• Creación inusual de cuentas de equipo (evento 4741), especialmente desde cuentas de usuario estándar.
• Solicitudes y emisiones de certificados en la CA (eventos 4886 y 4887), buscando plantillas y solicitantes que se salgan del patrón habitual.
• Conexiones salientes desde la CA por SMB o LDAP hacia hosts que no son Domain Controllers.
• Actividad de replicación de directorio originada en cuentas o equipos que no son Domain Controllers.

La lección de fondo

Certighost no es un caso aislado. Es el capítulo más reciente de una serie que arrancó públicamente con Certifried en 2022, y el patrón se repite: la CA acepta información suministrada por el solicitante y la usa para tomar decisiones de identidad.

Para un equipo de TI regional, la conclusión práctica no es memorizar cada técnica de abuso de AD CS. Es reconocer que la PKI interna forma parte del perímetro de identidad y merece el mismo rigor operativo que el resto: inventario, parcheo con un SLA definido, monitoreo y revisión periódica de configuración.

Cómo acompañamos este trabajo en GFS InfoSec

En GFS InfoSec trabajamos con empresas de Panamá y la región justo en ese punto de unión entre el directorio local y Microsoft 365. Nuestro servicio de Administración Segura de Microsoft 365 parte de un principio simple: no se puede asegurar el tenant sin entender y controlar la identidad que lo alimenta. Nuestras evaluaciones de seguridad y ejercicios de pentesting incluyen la revisión de configuración de AD CS y la validación de rutas de escalamiento de privilegios como la que describe este CVE.

Si hoy no tiene certeza de cuántas autoridades certificadoras hay en su red, o de si están actualizadas, esa es la conversación por donde empezar. Escríbanos y la tenemos.

Fuentes

Aviso oficial de Microsoft (Security Update Guide), CVE-2026-54121:

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-54121

Análisis técnico de Certighost, por H0j3n y Aniq Fakhrul (24 de julio de 2026):

https://gist.github.com/H0j3n/a5ef2609b5f2944ac2390a191a534c26

Prueba de concepto publicada por los investigadores:

https://github.com/aniqfakhrul/CVE-2026-54121