Estimados amigos de Inseguros !!!
Active Directory Certificate Services suele ser el gran olvidado de muchos entornos Microsoft.
Todo el mundo mira usuarios, grupos, GPOs, controladores de dominio, EDR, antivirus, firewall y políticas de contraseñas. Pero la CA interna queda ahí, funcionando, emitiendo certificados, usando plantillas heredadas y con permisos que rara vez se revisan.
Y ese es el problema.
AD CS no es un elemento menor. Es una pieza muy sensible dentro de la identidad corporativa. Si está mal configurado, puede abrir caminos de escalada, suplantación y persistencia bastante serios.
En otras palabras: una autoridad de certificación mal revisada puede terminar convirtiéndose en una autoridad de ataque.
Por eso, cuando hablamos de AD CS Active Directory seguridad, no hablamos solo de certificados. Hablamos de identidad, privilegios y confianza.
Por qué AD CS importa tanto en Active Directory
AD CS permite emitir certificados para usuarios, equipos, servicios, autenticación, VPN, WiFi corporativa, smart cards, servidores, aplicaciones internas y otros escenarios de infraestructura.
Sobre el papel, todo esto tiene sentido.
Una PKI interna ayuda a ordenar la confianza dentro de la empresa. Permite autenticar, cifrar, firmar y automatizar procesos que de otra forma serían más difíciles de gestionar.
El problema aparece cuando esa confianza se reparte sin control.
Si una plantilla permite pedir certificados con identidades que no corresponden, si permite especificar Subject Alternative Name de forma peligrosa, si tiene EKU demasiado amplios o si usuarios de bajo privilegio pueden inscribirse donde no deben, el impacto puede ser muy serio.
No estamos hablando de una alerta menor.
Estamos hablando de la posibilidad de autenticarse como otro usuario, escalar privilegios o mantener persistencia durante mucho tiempo mediante certificados válidos.
El certificado puede sobrevivir a la contraseña
Una idea importante: una contraseña se puede cambiar.
Un certificado emitido puede seguir siendo útil hasta que expire o hasta que se revoque correctamente.
Y aquí viene la parte incómoda: muchas empresas no han probado nunca su proceso de revocación.
Tienen CRL.
Tienen CDP.
Tienen plantillas.
Tienen políticas.
Tienen una CA que lleva años funcionando.
Pero nadie sabe realmente si todo eso respondería bien ante un abuso real.
Si un atacante consigue un certificado válido para autenticarse como una identidad privilegiada, cambiar la contraseña puede no ser suficiente. Hay que entender qué certificado se emitió, para quién, con qué plantilla, durante cuánto tiempo, si se puede revocar y qué sistemas aceptan esa autenticación.
Ahí es donde AD CS deja de parecer un tema de infraestructura y empieza a parecer lo que es: un componente crítico de seguridad.
El riesgo de las plantillas mal configuradas
En auditorías reales, muchas veces el problema no está en la CA “en general”, sino en una plantilla concreta.
Una plantilla que se copió de otra antigua.
Una plantilla que se modificó para que una aplicación funcionara.
Una plantilla que dejó permisos demasiado abiertos.
Una plantilla donde Authenticated Users puede inscribirse.
Una plantilla que permite definir SAN.
Una plantilla con EKU peligrosos.
Una plantilla que no exige aprobación.
Una plantilla que nadie ha revisado desde hace años.
No hace falta que todo AD CS esté mal.
Basta una plantilla vulnerable en el sitio correcto.
Ese es el tipo de configuración que un atacante busca con mucho cariño: algo aparentemente administrativo, poco visible y con impacto directo sobre identidad.
Qué deberías revisar en AD CS
Una revisión seria de AD CS debería mirar bastantes cosas.
No es una lista pequeña, porque AD CS tampoco es pequeño en impacto.
Como mínimo, conviene revisar:
Plantillas de certificados.
Permisos de enrolamiento.
Permisos de autoenrolamiento.
EKU configurados.
Plantillas que permiten autenticación de cliente.
Posibilidad de especificar Subject Alternative Name.
Aprobación de manager.
Permisos sobre la CA.
Administradores de certificados.
Endpoints web de enrolamiento.
Uso de HTTP donde no toca.
EPA en servicios web de certificados.
Configuración de revocación.
CRL y CDP.
Eventos de emisión.
Cambios en plantillas.
Certificados emitidos para identidades sensibles.
Esto no se revisa mirando una pantalla deprisa.
Hay que entender qué función cumple cada plantilla, quién puede solicitar certificados, para qué sirven esos certificados y qué impacto tendría un abuso.
Certificados e identidad: el error de tratarlos como infraestructura
El gran error es pensar que los certificados son “tema de infraestructura” y no de seguridad.
En entornos Microsoft modernos, los certificados forman parte de la identidad.
Se usan en autenticación, acceso remoto, WiFi, VPN, servidores, aplicaciones, dispositivos, servicios internos y escenarios híbridos.
Y si la identidad cae, cae todo.
Por eso AD CS debe entrar en cualquier revisión seria de Active Directory. No basta con mirar contraseñas, grupos privilegiados y GPOs. También hay que mirar las relaciones de confianza que permiten autenticarse sin usar una contraseña tradicional.
Porque muchas veces el camino de ataque no pasa por robar la contraseña de un administrador.
Pasa por conseguir un certificado que permita actuar como él.
Detección: si tu SIEM no mira AD CS, tienes una zona ciega
AD CS también debe monitorizarse.
No basta con revisarlo una vez y olvidarse.
Hay que recoger eventos de la CA, correlacionar solicitudes con identidades y vigilar comportamientos raros.
Algunas señales interesantes:
Emisión de certificados para cuentas sensibles.
Solicitudes donde el solicitante y el sujeto no cuadran.
Uso anómalo de plantillas delicadas.
Cambios en plantillas de certificados.
Cambios en permisos de enrolamiento.
Activación de opciones peligrosas.
Autenticaciones con certificado fuera de patrón.
Solicitudes desde equipos o usuarios inusuales.
Cambios en configuración de la CA.
Eventos relacionados con revocación.
Si tu SIEM no mira AD CS, tienes una zona ciega importante.
Y lo peor de una zona ciega no es que no veas nada. Es que crees que estás viendo suficiente.
AD CS en entornos híbridos
En muchas empresas, Active Directory ya no vive solo.
Está conectado con Microsoft 365, Entra ID, Entra Connect, ADFS, aplicaciones SaaS, VPNs, herramientas de seguridad, servicios cloud y dispositivos gestionados.
Eso hace que cualquier problema de identidad on-prem pueda tener impacto más allá del dominio clásico.
AD CS puede parecer una pieza antigua, pero sigue siendo relevante en entornos híbridos. De hecho, muchas empresas arrastran PKI interna desde hace años y la conectan con servicios modernos sin revisar bien el modelo de riesgo.
Por eso la seguridad Microsoft no puede quedarse en “tengo el dominio parcheado”.
Hay que mirar el conjunto.
Kerberos.
NTLM.
LDAP.
GPOs.
Delegaciones.
Certificados.
Entra Connect.
ADFS.
Relaciones de confianza.
Cuentas privilegiadas.
Estaciones de administración.
Monitorización.
Todo está conectado.
Qué puede pasar si AD CS se abusa
Cuando AD CS se abusa, muchas veces la pregunta no es “cómo entraron”.
La pregunta es otra:
“¿Cómo pudieron autenticarse como quien quisieron durante tanto tiempo?”
Ese es el peligro.
Un certificado mal emitido puede permitir autenticación persistente. Puede sobrevivir a cambios de contraseña. Puede pasar desapercibido si no se monitoriza. Y puede dar al atacante una vía silenciosa para volver.
En un incidente real, esto complica mucho la respuesta.
No solo tienes que contener la cuenta.
No solo tienes que cambiar contraseñas.
No solo tienes que revisar grupos.
También tienes que entender certificados emitidos, plantillas usadas, revocación, logs de la CA y autenticaciones con certificado.
Si nunca has revisado AD CS antes del incidente, hacerlo durante el incendio no es el mejor momento.
Por qué esto importa a empresas
Para una empresa, AD CS puede parecer un tema muy técnico.
Pero la pregunta de fondo es sencilla:
¿Nuestra autoridad de certificación puede emitir confianza de forma peligrosa?
Si la respuesta es sí, el impacto puede ser alto.
Porque estamos hablando de autenticación, privilegios y persistencia. No de una configuración estética.
Por eso una formación práctica en seguridad Active Directory debe incluir certificados, plantillas, Kerberos, modelo de privilegios y monitorización.
No se puede defender bien Microsoft mirando solo usuarios y contraseñas.
Formación Microsoft, Active Directory y FUNDAE
En SeguridadSi, el curso de ciberseguridad Microsoft para empresas está pensado para profesionales que ya conocen entornos Microsoft y quieren entenderlos desde ataque y defensa.
Trabajamos Active Directory, Windows Server, Kerberos, delegación, certificados, cuentas privilegiadas, rutas de abuso, hardening y monitorización desde una perspectiva práctica.
Además, para empresas españolas, esta formación puede encajar dentro de cursos de ciberseguridad para empresas con FUNDAE, especialmente si el objetivo es formar a equipos de sistemas, cloud, seguridad o responsables técnicos.
Puedes ampliar esta línea con el Curso de Ciberseguridad Microsoft para Empresas, centrado en hacking y defensa avanzada de Active Directory y Windows Server.
Conclusión
AD CS no suele hacer ruido hasta que alguien lo abusa.
Y cuando eso ocurre, muchas veces el problema no está en una vulnerabilidad nueva, sino en una confianza antigua, una plantilla mal configurada o un permiso que nadie revisó.
Active Directory Certificate Services puede ser una pieza muy útil de infraestructura. Pero también puede convertirse en un camino serio de ataque si no se gobierna bien.
Revisar AD CS es revisar identidad.
Y revisar identidad, en una empresa Microsoft, es revisar el corazón de la seguridad.
Gracias por leerme !!!
Preguntas frecuentes sobre AD CS Active Directory seguridad
¿Qué es AD CS en Active Directory?
AD CS, o Active Directory Certificate Services, es el servicio de Microsoft que permite crear una autoridad de certificación interna para emitir certificados usados en autenticación, cifrado, firma y otros escenarios corporativos.
¿Por qué AD CS puede ser peligroso?
AD CS puede ser peligroso si las plantillas de certificados, permisos de enrolamiento o configuraciones de autenticación están mal definidas. Un atacante podría abusar de certificados para autenticarse como otros usuarios o mantener persistencia.
¿Qué hay que revisar en AD CS?
Conviene revisar plantillas, permisos de enrolamiento, EKU, posibilidad de especificar SAN, aprobación de manager, permisos sobre la CA, endpoints web, revocación y eventos de emisión de certificados.
¿AD CS forma parte de una auditoría de Active Directory?
Sí. Una auditoría seria de Active Directory debería incluir AD CS, porque los certificados forman parte del modelo de identidad y pueden afectar a privilegios, autenticación y persistencia.
¿Qué formación ayuda a proteger AD CS?
Una formación práctica en seguridad Microsoft, Active Directory, Kerberos, certificados, modelo de privilegios y monitorización ayuda a entender cómo se abusa AD CS y cómo reducir el riesgo en empresas.
