Microsoft RAMP se detiene en el límite de su autoridad certificadora

Microsoft parcheó CVE-2026-54121 el 14 de julio. Los investigadores H0j3n y Aniq Fakhrul publicaron un proof of concept funcional 10 días después y lo llamaron Certighost. Si tus servidores AD CS aplicaron la actualización acumulativa de julio, estás protegido. Si aún usan las versiones de junio, estás expuesto a código de exploit público.

El ataque en sí es breve. Un usuario estándar del dominio sin derechos de administrador manipula atributos en una cuenta de máquina que controla, activa una lógica de reserva defectuosa dentro de la autoridad certificadora y recibe un certificado firmado que autentica como controlador de dominio mediante PKINIT. A partir de ahí, DCSync obtiene el hash krbtgt y la capacidad de falsificar Golden Tickets en todo el bosque. Requiere una Enterprise CA integrada con Active Directory y la capacidad de crear o controlar una cuenta de computadora, que la cuota predeterminada de 10 cuentas de máquina otorga a cada usuario del dominio.

La cuenta que inició la cadena nunca tuvo privilegios elevados en ningún momento. Ese es el detalle importante aquí, porque la hoja de ruta de Microsoft para privileged access se basa en un modelo de amenaza que este ataque evita.

Los tres grupos de iniciativa de RAMP

El Plan de Modernización Rápida indica separar y gestionar las cuentas privilegiadas, mejorar la experiencia de credenciales para quienes las poseen y desplegar estaciones de trabajo administrativas. Debajo de esto están los detalles que la mayoría de los equipos de seguridad están abordando ahora: Privileged Identity Management (PIM), cuentas de acceso de emergencia, categorización de roles Microsoft Entra según impacto, MFA y acceso sin contraseña para administradores, bloqueo de autenticación heredada y Privileged Access Workstations.

La mayor parte de eso es trabajo de Microsoft Entra ID. Lo que RAMP solicita en las instalaciones se reduce a cuentas de administrador separadas, estaciones de trabajo dedicadas para las personas que las usan y contraseñas únicas de administrador local. Certighost es un defecto en AD CS. Ninguno de esos tres lo afecta.

RAMP no incluye ninguna iniciativa de autoridad certificadora. Microsoft lo definió así deliberadamente, y la guía lo indica, basándose en un documento separado de implementación de Privileged Access Management. RAMP responde quién tiene acceso elevado en su entorno. Cómo su CA decide qué identidad vincular a un certificado es otra cuestión.

Certighost no será el último

La integridad en la emisión de certificados es una categoría que sigue generando casos. La mayoría de los métodos conocidos son las técnicas de ataque ESC documentadas desde "Certified Pre-Owned", donde una plantilla o una bandera de CA permite a un usuario sin privilegios solicitar un certificado para una identidad que no posee. Certighost es diferente. La configuración de la plantilla no importa. El defecto está en la lógica de manejo de solicitudes de la autoridad certificadora, en cómo resolvió qué objeto del directorio estaba realmente solicitando la petición.

Esa distinción es importante para lo que hagas al respecto. Una auditoría de plantilla de certificado, que es el consejo estándar, no habría detectado este caso.

Lo que los clientes entienden mal sobre esto

La mayoría de los clientes consideran que AD CS está cubierto porque alguien se encarga de ello. La autoridad certificadora está con un equipo de PKI o infraestructura, el equipo de identidad asume que eso significa que está gestionado, y una línea de reporte diferente se interpreta como un control. Cuando pregunto si han auditado sus configuraciones según alguna de las rutas ESC, la respuesta suele ser que no las conocían.

Los equipos que lo poseen se miden por su disponibilidad. La emisión tiene éxito, las renovaciones no caducan, la autenticación no falla, la CA está sana según todas las métricas de las que son responsables. Permanece sana en todas ellas cuando un usuario estándar inscribe un certificado para una cuenta que no le pertenece, y es precisamente por eso que nadie lo detecta.

La gobernanza no tiene nada a qué sujetarse

Los controles de RAMP se activan alrededor de una cuenta privilegiada. Certighost nunca toca una hasta que la CA emite el certificado que la crea.

No hay una cuenta intermedia para que PIM controle ni autenticación de administrador para que MFA desafíe. La escalada y el pago ocurren en una sola transacción dentro del procesamiento de la solicitud de la autoridad certificadora, y la cuenta inicial del adversario permanece exactamente donde empezó, al mismo nivel que cualquier otro usuario estándar del dominio. La cuota de cuentas de máquina que hace posible el paso de preparación tampoco es una iniciativa RAMP.

RAMP apunta a Microsoft Defender for Identity (MDI), y MDI ofrece cobertura real de certificados. Las evaluaciones de postura analizan plantillas y configuraciones de CA para las rutas conocidas de escalada, y las verificaciones que examinan la CA requieren un sensor MDI en el servidor AD CS. También hay una detección nombrada para esta técnica que se activa según el patrón de solicitud.

Ambos son valiosos. Ninguno rechaza la solicitud de inscripción. Una evaluación de postura es un informe de configuración que se lee periódicamente, y una detección es una alerta que llega mientras se completa la transacción.

Así, un equipo de seguridad puede completar RAMP de principio a fin, hacerlo bien, ejecutar MDI junto a él y aun así no tener ningún control que evalúe y rechace una solicitud de certificado. La gobernanza de Privileged Access Management y la integridad de la autoridad certificadora son problemas separados. RAMP resuelve uno de ellos, y diría que considerar una implementación completa como cobertura para ambos es la interpretación errónea más común de para qué sirve esa hoja de ruta.

Si alguien me dice que ha terminado su trabajo con RAMP, mi primera pregunta es quién posee la autoridad certificadora. Si tienen que averiguarlo, esa es la respuesta. RAMP es la hoja de ruta correcta y completarla significa que sus cuentas privilegiadas están gobernadas, lo que es un progreso real y no nada. Solo no dice nada sobre el sistema que puede emitir una de esas cuentas a partir de la solicitud de certificado de un usuario estándar. Monitorear ese sistema es el mínimo. Lo que querría a continuación es algo que pueda rechazar la solicitud.

Bloqueando la solicitud de inscripción

Netwrix Threat Prevention (NTP) y Netwrix Threat Manager (NTM) actúan en ambos lados. En el monitoreo, NTM cubre el mismo terreno que RAMP señala a través de Defender for Identity, detectando el mal uso de AD CS y patrones de abuso de certificados en tiempo real.

El aspecto de prevención es lo que los diferencia. NTP evalúa las solicitudes de inscripción contra patrones conocidos de abuso de AD CS, incluidas las técnicas ESC1 a ESC7, y las bloquea antes de que exista un certificado en lugar de generar un registro de que se emitió uno. Una evaluación de postura indica que una plantilla está mal y una detección indica que una solicitud parecía incorrecta, pero la aplicación es la única de las tres que termina la transacción.

Haz RAMP, luego revisa tu autoridad certificadora

Sigue RAMP. El trabajo que pide es un trabajo que vale la pena hacer. Actualiza tus servidores AD CS y establece la cuota de cuentas de máquina a cero mientras estás allí.

Luego revisa tu autoridad certificadora, porque RAMP no te dirigirá allí. Audita las plantillas, y luego haz la pregunta más difícil debajo de ellas: cuando una cuenta estándar envía una solicitud de inscripción afirmando una identidad que no le corresponde, ¿qué en tu entorno evalúa esa solicitud, y algo la detiene o solo la registra?