Certighost y el riesgo de una PKI descuidada en tu Active Directory

Una vulnerabilidad que apunta más alto de lo habitualDurante años, los servicios de certificados de Active Directory (AD CS) fueron ese componente que...

Una vulnerabilidad que apunta más alto de lo habitual

Durante años, los servicios de certificados de Active Directory (AD CS) fueron ese componente que se instaló una vez, funcionó sin quejas y nadie volvió a mirar. Esa comodidad tiene un precio: cuando la infraestructura de clave pública (PKI) interna queda abandonada, se convierte en una de las superficies de ataque más rentables del bosque. La reciente publicación de Certighost (CVE-2026-54121) es un recordatorio incómodo de ello.

Según Microsoft, el fallo es una elevación de privilegios por un problema de autorización que permite a un usuario autenticado escalar a través de la red. La puntuación CVSS ronda el 8,8 y ya circula una prueba de concepto pública. Pero lo verdaderamente relevante no es la mecánica del exploit, sino hasta dónde llega: en lugar de perseguir un certificado de un usuario privilegiado, el ataque busca obtener uno que represente al propio Domain Controller.

Por qué una identidad de máquina del DC lo cambia todo

Quien haya trabajado con autenticación basada en certificados entiende la gravedad. No hablamos solo de llegar a Domain Admin: hablamos de disponer de una identidad de máquina que participa en numerosos mecanismos de autenticación del directorio. Eso abre la puerta a movimientos laterales silenciosos y a una persistencia difícil de detectar con las herramientas habituales.

La prueba de concepto publicada ilustra el flujo con una lógica inquietantemente sencilla:

Se crea una cuenta de equipo nueva (o se reutiliza una existente) para solicitar el certificado.
Se levantan listeners falsos que simulan servicios de autenticación y de directorio en puertos controlados por el atacante.
La solicitud de certificado incluye atributos personalizados que apuntan a esos listeners y al nombre del controlador de dominio objetivo.
La entidad de certificación se conecta a los listeners no autorizados, se autentica con la cuenta creada y recibe como respuesta la identidad del DC real.
La CA emite un certificado válido que pertenece al controlador de dominio, y con él se puede completar la autenticación Kerberos y obtener material sensible de la cuenta de máquina.

El resultado es un certificado y una caché de Kerberos en manos del atacante. No hace falta ser un equipo de red team experimentado para reproducirlo.

Parchear no es suficiente: revisa tu PKI de arriba abajo

Microsoft ya ha publicado actualizaciones para los sistemas afectados y aplicarlas es obligatorio. Pero si tu única medida es el parche, estás dejando intactas las condiciones que hacen posible este tipo de abuso. Una revisión seria debería incluir, como mínimo:

Inventario completo de todas las entidades de certificación empresariales, incluidas las que se desplegaron en filiales o durante migraciones antiguas.
Auditoría de plantillas de certificados, prestando atención a las que permiten suplantación o a las que admiten atributos controlados por el solicitante.
Revisión de permisos de inscripción (Enroll y AutoEnroll): quién puede solicitar qué y con qué condiciones.
Mapeo de la autenticación por certificado en todo el bosque, para saber qué identidades pueden autenticarse por esta vía.
Auditoría de eventos de solicitudes y emisiones de certificados, con alertas ante patrones anómalos.
Limpieza de configuraciones heredadas que nadie ha revisado desde la instalación inicial.

En muchas organizaciones de Barcelona, Lleida, Tarragona o Girona descubriréis que la PKI lleva años funcionando en piloto automático. Ese es, precisamente, el caldo de cultivo de Certighost.

La lección que va más allá del certificado

Certighost confirma una tendencia que venimos observando: los atacantes ya no buscan solo la contraseña del administrador, sino cualquier identidad de confianza que el sistema acepte sin preguntar. Un certificado mal emitido, una cuenta de equipo huérfana o un servicio expuesto con reglas laxas son moneda de cambio para un intruso.

Por eso conviene ampliar la mirada más allá de AD CS. Los servidores que sostienen tu infraestructura también necesitan una capa de control propia: servicios expuestos a internet que reciben intentos de autenticación constantes, IPs que escanean puertos y prueban credenciales, bots que buscan cualquier rendija. Ahí es donde herramientas como Abuse Shield encajan de forma natural: centraliza la protección de tus servidores con bloqueo automático de IPs maliciosas, gestiona fail2ban en múltiples máquinas desde un único punto y comparte un feed de reputación de IP entre todos tus servidores. Si una IP ataca uno de tus equipos, el resto la conoce y la bloquea antes de que lo intente.

Qué hacer esta misma semana

El orden de prioridades es claro. Primero, aplica las actualizaciones de Microsoft y verifica que todos los controladores de dominio y servidores de CA las tienen. Después, revisa las plantillas y los permisos de inscripción, y elimina cualquier configuración que ya no tenga un dueño identificable. Por último, refuerza la vigilancia perimetral de tus servidores con bloqueo automatizado y reputación compartida, de modo que la siguiente vulnerabilidad de este tipo te pille con la puerta cerrada y no solo con el parche puesto.

Relacionado

¿Tus servidores bajo ataque constante?

Centraliza fail2ban y la reputación de IPs en todos tus servidores. Descubre Abuse Shield de ALMC. Contáctanos para una demo personalizada.

Resultados sin salir de la página.