Vulnerabilidades de Microsoft Active Directory Certificate Services (ADCS): análisis de seguridad

Introducción

Active Directory Certificate Services (ADCS) es una función de Windows Server que permite crear y administrar una infraestructura de clave pública (PKI) para emitir y gestionar certificados digitales utilizados en comunicaciones seguras y protocolos de autenticación. Aunque ADCS proporciona servicios criptográficos esenciales para entornos empresariales, también puede ser una superficie de ataque importante cuando está mal configurado.

Según el artículo original, a agosto de 2025 los investigadores de seguridad habían identificado 16 técnicas distintas de escalada de privilegios (ESC1–ESC16) relacionadas con errores de configuración de ADCS. La cifra y el estado reflejan la fecha de publicación del artículo. Estos caminos de ataque se han utilizado para pasar de una cuenta de dominio estándar a privilegios elevados, incluida la suplantación de cuentas de alto valor.

Este artículo examina los riesgos de ADCS, presta especial atención a Web Enrollment y Network Device Enrollment Service (NDES), y presenta recomendaciones para reducir la exposición y gestionar PKI de forma segura.

Superficie de ataque de ADCS: comprender el riesgo

Las vulnerabilidades de ADCS suelen deberse a errores de configuración, no a defectos inherentes del software. Las plantillas de certificado, los permisos de inscripción y la configuración de servicios pueden abrir rutas de ataque. Herramientas disponibles públicamente, como Certipy, pueden ayudar a identificar y explotar ciertas configuraciones.

La superficie de ataque incluye:

• Plantillas de certificado: ADCS incluye 32 plantillas predeterminadas; algunas pueden tener permisos demasiado amplios. Las plantillas que permiten al solicitante especificar el nombre del sujeto pueden crear las condiciones de ESC1.
• Servicios de inscripción: los endpoints de inscripción HTTP pueden exponer a la organización a ataques de retransmisión NTLM.
• Permisos de objetos PKI: los controles de acceso demasiado permisivos en objetos de dominio relacionados con PKI pueden poner en riesgo la infraestructura PKI.

Las consecuencias pueden incluir escalada de privilegios desde una cuenta estándar y persistencia mediante técnicas como “Golden Certificate”. En entornos híbridos, una configuración local incorrecta también puede afectar a la infraestructura cloud.

Web Enrollment: un riesgo crítico que conviene evitar

¿Qué es Web Enrollment?

Web Enrollment es un servicio ADCS opcional que ofrece una interfaz web (normalmente en `/certsrv`) para que usuarios y equipos soliciten certificados mediante HTTP. Aunque se diseñó para facilitar las solicitudes a usuarios de bosques separados o sin acceso directo al dominio, puede introducir vulnerabilidades importantes.

La vulnerabilidad ESC8

El riesgo principal de Web Enrollment es ESC8, un ataque de retransmisión NTLM contra endpoints HTTP de ADCS. Con configuraciones predeterminadas, pueden darse dos condiciones críticas:

• HTTP admite autenticación NTLM, pero no protege frente a ataques de retransmisión mediante firma de autenticación.
• Las plantillas predeterminadas Machine y DomainController pueden permitir que un atacante que fuerce la autenticación de un equipo solicite un certificado que represente a ese equipo.

Ejemplo de cadena de explotación

1. Forzar autenticación: con herramientas como Coercer o PetitPotam, un atacante induce a un controlador de dominio a autenticarse mediante NTLM.
2. Retransmitir: la solicitud de autenticación se retransmite al servicio Web Enrollment de ADCS mediante herramientas como ntlmrelayx.
3. Solicitar un certificado: se solicita un certificado utilizando la plantilla Domain Controller.
4. Comprometer el dominio: el certificado resultante puede utilizarse en un ataque de replicación (dcsync) y facilitar la toma de control del dominio.

El artículo señala que esta cadena no requiere malware ni un exploit de día cero y que puede iniciarse desde una cuenta de dominio estándar. PetitPotam puede permitir que un usuario del dominio fuerce la autenticación de equipos activos, incluidos controladores de dominio.

Por qué deshabilitar NTLM no es suficiente

Deshabilitar NTLM específicamente para el sitio Web Enrollment puede abordar un aspecto del problema, pero el servicio sigue siendo una superficie de ataque innecesaria si sus funciones pueden cubrirse con alternativas más seguras. La recomendación del artículo es no desplegar Web Enrollment salvo que exista una necesidad empresarial imprescindible que no pueda resolverse de otro modo.

Network Device Enrollment Service (NDES): un componente de alto riesgo

Descripción de NDES

NDES es la implementación de Microsoft del Simple Certificate Enrollment Protocol (SCEP), diseñada para emitir certificados a dispositivos de red, como routers, firewalls y teléfonos, que no pueden autenticarse mediante Active Directory. NDES actúa como puente entre dispositivos que no están unidos al dominio y Microsoft Certificate Authority.

Riesgos de seguridad de NDES

1. Abuso de Subject Alternative Name (SAN)

Las plantillas de certificado NDES suelen permitir que el cliente proporcione un Subject Alternative Name (SAN) y normalmente incluyen el Extended Key Usage (EKU) de autenticación de cliente. Esta combinación puede permitir que una persona con acceso a una contraseña NDES solicite un certificado que represente a otro usuario y se autentique en su nombre mediante PKINIT o SChannel.

2. Vías de escalada de privilegios

De forma predeterminada, NDES genera contraseñas de un solo uso (OTP) de duración limitada, válidas durante 60 minutos, y permite hasta cinco contraseñas sin usar por hora. Sin embargo, los administradores pueden cambiar esta configuración en el registro para:

• Aumentar el tamaño de la caché de contraseñas.
• Usar contraseñas estáticas en lugar de OTP aleatorias.
• Deshabilitar completamente la contraseña NDES.

Deshabilitar las contraseñas NDES puede crear una ruta de ataque desde ningún acceso hasta el compromiso del bosque.

3. Vulnerabilidad de retransmisión NTLM

Los servidores NDES publicados mediante HTTPS sin Channel Binding también pueden ser vulnerables a ataques de retransmisión NTLM similares a ESC8.

4. Desafío de autenticación de dispositivos

NDES emite certificados a dispositivos sin cuentas de red. Esto genera un equilibrio complejo entre facilidad de uso y seguridad, y dificulta garantizar que los certificados no se emitan a actores maliciosos.

Reconocimiento del riesgo por parte de Microsoft

Microsoft reconoce estos riesgos y recomienda usar un módulo de directivas con NDES para añadir autenticación. Aun así, NDES sigue siendo un servicio complejo de proteger. El artículo cita a Microsoft: “el punto crucial para operar NDES de forma segura es que, como ocurre con la mayoría de las soluciones de seguridad, no se ha terminado cuando la inscripción de certificados funciona como se espera”. Se recomienda evitar NDES salvo que sea imprescindible y, si se despliega, aplicar controles exhaustivos.

Causa raíz: complejidad de configuración de ADCS

Los riesgos descritos reflejan una realidad más amplia: ADCS puede ser difícil de configurar de forma segura. La cantidad de opciones, plantillas e interdependencias crea oportunidades de error. Entre los riesgos de configuración se incluyen:

• Permisos de inscripción demasiado amplios en plantillas de certificado.
• Plantillas que permiten al solicitante especificar el nombre del sujeto (ESC1).
• Endpoints de inscripción HTTP sin protección adecuada (ESC8).
• Configuración criptográfica débil en certificados y CA.
• Controles de acceso insuficientes en objetos de dominio relacionados con PKI (ESC5).
• Plantillas de esquema versión 1 que permiten al solicitante especificar políticas de aplicación (CVE-2024-49019).

El artículo indica que estos problemas aparecen habitualmente en pruebas de penetración y evaluaciones de seguridad.

Alternativas modernas: proteger la PKI con soluciones Securetron

PKI Trust Cloud (SaaS)

PKI Trust Cloud es una solución SaaS de gestión PKI que puede reducir la necesidad de mantener infraestructura ADCS local. Entre sus capacidades descritas se incluyen:

• Agilidad criptográfica y preparación para criptografía poscuántica.
• MFA resistente al phishing.
• Automatización de ciclo de vida de certificados TLS de 47 días.
• Descubrimiento avanzado de certificados.
• Servicio inteligente de notificaciones de expiración.

PKI Trust Manager (local)

Para organizaciones que requieren gestión PKI local, PKI Trust Manager ofrece funciones para complementar y mejorar despliegues ADCS:

• Gestión inteligente del ciclo de vida de certificados.
• Creación y renovación automatizadas de certificados.
• Integración multiplataforma, incluida la conexión de PKI local con Azure Key Vault.
• Aplicación de políticas empresariales en entornos híbridos.
• Automatización mediante SCEP, EST, ACME y API RESTful.

PKI Trust Auditor: evaluación continua de seguridad

PKI Trust Auditor permite auditar infraestructuras ADCS e incluye:

• Descubrimiento automático de autoridades de certificación en Active Directory.
• Auditorías de conectividad, configuración, criptografía, plantillas y operaciones.
• Más de 28 controles para entornos PKI multinivel.
• Informes JSON, CSV, web y de consola.
• Informes ejecutivos con hallazgos, evidencias y recomendaciones de corrección.
• Integración con SIEM mediante resultados JSON o CSV para supervisión y alertas.

PKI Trust Auditor está disponible como herramienta comunitaria gratuita. El artículo la presenta como opción para realizar evaluaciones puntuales y supervisar tendencias de seguridad PKI a lo largo del tiempo.

Acciones recomendadas

1. Auditar inmediatamente el entorno PKI

Utilice PKI Trust Auditor para evaluar la infraestructura ADCS e identificar:

• Plantillas de certificado mal configuradas.
• Servicios de inscripción vulnerables.
• Debilidades criptográficas.
• Riesgos operativos.
• Brechas de cumplimiento.

2. Eliminar Web Enrollment

Si Web Enrollment está desplegado, desactívelo salvo que exista una necesidad empresarial imprescindible. El artículo identifica ESC8 como un riesgo crítico asociado al servicio.

3. Evaluar y retirar NDES

Determine si NDES es realmente necesario. Si lo es, aplique controles sólidos, entre ellos:

• Módulo de directivas obligatorio con autenticación adicional.
• Aplicación de Channel Binding sobre HTTPS.
• Políticas estrictas para OTP.
• Revisiones de seguridad periódicas.

La recomendación preferida del artículo es evitar el despliegue de NDES cuando sea posible.

4. Implementar gestión PKI moderna

• Organizaciones centradas en cloud: evalúe PKI Trust Cloud (SaaS) para gestionar PKI sin infraestructura local.
• Entornos híbridos o requisitos locales: evalúe PKI Trust Manager para automatizar y proteger el ciclo de vida de certificados.

5. Establecer supervisión continua

Use PKI Trust Auditor para evaluaciones periódicas. Envíe los datos JSON o CSV a su SIEM para generar alertas y analizar tendencias.

Próximos pasos

La seguridad de Active Directory Certificate Services es demasiado importante para dejarla al azar. Las configuraciones incorrectas de ADCS pueden crear superficies de ataque críticas y explotadas. Evalúe el entorno, identifique y corrija Web Enrollment, NDES y otras configuraciones de alto riesgo, considere PKI Trust Cloud o PKI Trust Manager según sus necesidades y establezca supervisión continua.

No espere a una prueba de penetración o a una brecha real para descubrir vulnerabilidades PKI. La evaluación y corrección proactivas ayudan a adelantarse a los atacantes que buscan errores de configuración de ADCS.

Contacte con nosotros para obtener información sobre PKI Trust Cloud, PKI Trust Manager y PKI Trust Auditor, la herramienta comunitaria gratuita.

Conclusión

Microsoft ADCS proporciona capacidades PKI esenciales, pero las configuraciones incorrectas pueden crear riesgos graves. Web Enrollment y NDES requieren especial atención y deben evitarse salvo necesidad; si se despliegan, necesitan controles exhaustivos. Soluciones como PKI Trust Cloud y PKI Trust Manager ofrecen capacidades modernas de gestión de certificados, y PKI Trust Auditor ayuda a evaluar continuamente la seguridad. Una gestión proactiva puede reforzar la postura PKI y reducir el riesgo operativo.