Problema

En entornos con Active Directory Certificate Services (AD CS) habilitado, los controladores de dominio pueden actuar como Certificate Authorities (CA) para emitir certificados de autenticación Kerberos (PKINIT). Cuando la configuración permite que los clientes busquen automáticamente un DC para validar la cadena de confianza, un atacante con una cuenta de dominio de bajo privilegio puede explotar esa lógica de “chase” y solicitar un certificado que se firme como si fuera emitido por el propio DC. Con ese certificado, el atacante inicia una sesión PKINIT contra el controlador, ejecuta DCSync y extrae el hash del krbtgt, lo que abre la puerta a un compromiso total del bosque.

El patrón es recurrente: una política de emisión demasiado permisiva combinada con un comportamiento de descubrimiento automático (EDITF_ENABLECHASECLIENTDC) crea una vía de escalada que no depende de vulnerabilidades de software específicas, sino de la confianza implícita entre los componentes de AD.

Causa

  1. Política de emisión abierta – Cuando la plantilla de certificado permite que cualquier usuario autenticado solicite un certificado con la finalidad “Domain Controller Authentication”, el CA no distingue entre un DC legítimo y un cliente cualquiera.

  2. Chase behavior habilitado – El flag EDITF_ENABLECHASECLIENTDC indica al servicio de certificación que, al no encontrar una CA local adecuada, persiga (chase) a un DC para completar la solicitud. Esta característica está pensada para entornos con múltiples CA, pero en la práctica permite que un atacante redirija la solicitud a sí mismo.

  3. Falta de restricciones de autorización – La ausencia de listas de control de acceso (ACL) en la plantilla o en el objeto de la CA permite que cuentas de bajo nivel soliciten certificados con atributos críticos (Key Usage, EKU) sin revisión.

  4. Ausencia de monitoreo de emisión – Sin alertas que detecten solicitudes de certificados con EKU de “Domain Controller Authentication” provenientes de cuentas que no son DC, la actividad pasa desapercibida.

Solución

La mitigación se basa en tres pilares: restringir la emisión, desactivar el chase behavior y monitorizar la actividad de la CA.

1. Restringir plantillas de certificado

  • Revise todas las plantillas que incluyen Domain Controller Authentication en EKU.
  • Asigne la plantilla solo a grupos que contengan los propios controladores de dominio (por ejemplo, Domain Controllers).
  • Añada una ACL de Deny para cualquier otro grupo o usuario.

2. Desactivar el chase behavior (EDITF_ENABLECHASECLIENTDC)

El flag se puede limpiar mediante certutil. Esta acción impide que la CA persiga a un DC cuando no encuentra una autoridad local adecuada, eliminando la vía de escalada usada por el exploit.

certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force

Nota: El comando anterior solo limpia el flag; si la CA necesita el chase por motivos de arquitectura multi‑site, evalúe la repercusión antes de aplicar.

3. Aplicar parches de seguridad

Microsoft lanzó correcciones en la actualización de julio 2026. Asegúrese de que los controladores y los servidores de certificación estén al día. En entornos donde el parche no puede aplicarse inmediatamente, la desactivación del chase behavior es la medida de contención más rápida.

4. Implementar auditoría de emisión

  • Habilite el registro de eventos 4886 (solicitud de certificado) y 4887 (emisión) en el servidor de certificación.
  • Cree una regla de detección en SIEM que alerte cuando una cuenta que no pertenece a Domain Controllers solicite un certificado con EKU 1.3.6.1.5.5.7.3.2 (Domain Controller Authentication).
  • Revise periódicamente los logs de certutil -view -restrict "RequestID>0" para identificar patrones sospechosos.

Cuándo aplicar esta solución

  • Síntomas: usuarios de bajo privilegio pueden iniciar sesiones PKINIT contra DC; detección de DCSync desde cuentas no privilegiadas; logs de emisión de certificados con EKU de DC provenientes de usuarios normales.
  • Entornos: cualquier dominio que tenga AD CS habilitado y que use plantillas de certificado para autenticación Kerberos.
  • Excepciones: si la arquitectura de la CA depende estrictamente del chase behavior para la disponibilidad de certificados en sitios remotos, evalúe alternativas como replicar una CA local antes de desactivar el flag.

Código

# Limpiar el flag que permite chase hacia DC
certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC

# Reiniciar el servicio de certificación para que el cambio tenga efecto
Restart-Service CertSvc -Force

Verificación

  1. Comprobar el flag

    certutil -getreg policy\EditFlags

    El valor devuelto no debe contener el bit 0x00000001 (EDITF_ENABLECHASECLIENTDC).

  2. Validar que la CA sigue operativa

    • Solicite un certificado legítimo desde un controlador de dominio y verifique que la emisión se completa sin errores.
    • Intente la misma solicitud desde una cuenta de usuario estándar; la operación debe fallar con “Access denied”.

  3. Revisar eventos de auditoría

    • En el visor de eventos, filtre por ID 4886/4887 y confirme que no aparecen solicitudes de usuarios no autorizados con EKU de DC.

Notas adicionales

  • La desactivación del chase behavior puede afectar a entornos con CA distribuidas. En esos casos, la solución recomendada es desplegar una CA local en cada sitio antes de limpiar el flag.
  • Mantenga una copia de seguridad de la configuración del CA (certutil -backupdb) antes de modificar los flags; revertir es tan sencillo como restaurar la copia.
  • Si necesita seguir emitiendo certificados para DC en un entorno multi‑site, considere crear una plantilla exclusiva para DC y asignarla únicamente a los grupos de controladores, evitando el uso de plantillas genéricas.
  • La combinación de restricciones de ACL y auditoría suele ser suficiente para detectar intentos de abuso antes de que se materialicen en un compromiso total. No confíe solo en el parche; la defensa en profundidad sigue siendo la mejor práctica.