Estimados amigos de Inseguros !!!
Si AD CS mal configurado ya es peligroso, Golden Certificate es subir un nivel más.
Aquí ya no hablamos solo de una plantilla vulnerable, de un permiso demasiado amplio o de una opción mal marcada en una plantilla de certificados.
Hablamos de comprometer la confianza raíz de la autoridad de certificación, especialmente su clave privada, para emitir certificados fraudulentos que el dominio puede aceptar como válidos.
Y esto es muy incómodo de asumir.
Porque si un atacante puede fabricar certificados en los que tu entorno confía, deja de necesitar muchas de las cosas que normalmente intentamos proteger: contraseñas, sesiones, tokens o incluso algunas respuestas clásicas ante incidente.
Por eso, cuando hablamos de Golden Certificate Active Directory, no hablamos de un truco aislado. Hablamos de identidad, persistencia y confianza completa en entornos Microsoft.
Qué es un Golden Certificate
Un Golden Certificate es un certificado fraudulento emitido o construido a partir del compromiso de la autoridad de certificación.
La idea recuerda al concepto de Golden Ticket en Kerberos, pero aplicada al mundo de certificados.
Si el atacante consigue controlar la CA o acceder a su clave privada, puede generar certificados que parecen legítimos para el entorno. Y si esos certificados se aceptan para autenticación, el atacante puede usarlos para suplantar identidades o mantener acceso persistente.
La diferencia importante es esta:
Una contraseña se puede cambiar.
Una sesión se puede cerrar.
Una cuenta se puede bloquear.
Un ticket puede caducar.
Pero un certificado emitido con una CA confiable puede seguir funcionando hasta que expire o hasta que se revoque correctamente.
Y muchas empresas nunca han probado de verdad cómo responderían ante un abuso de su PKI interna.
Por qué es tan peligroso
El peligro principal es que el atacante no depende ya de la contraseña de la víctima.
Imagina este escenario.
Una empresa detecta un compromiso de una cuenta privilegiada.
El equipo cambia la contraseña.
Revoca sesiones.
Bloquea accesos sospechosos.
Limpia endpoints.
Revisa grupos.
Activa controles adicionales.
Todo eso está bien.
Pero si el atacante tiene capacidad de emitir certificados válidos o ya ha emitido uno para una identidad privilegiada, puede conservar una vía de autenticación que no se arregla solo cambiando contraseñas.
Ese es el problema.
Golden Certificate cambia la conversación defensiva. Ya no basta con preguntar “¿qué cuenta se ha visto comprometida?”. Hay que preguntar también:
¿Se ha tocado la CA?
¿Se ha accedido a claves privadas?
¿Se han emitido certificados anómalos?
¿Hay certificados válidos para identidades sensibles?
¿Funciona la revocación?
¿Sabemos qué sistemas confían en esa CA?
¿Tenemos inventario real de plantillas y certificados?
Cuando la confianza está comprometida, el incidente es más profundo.
La CA debe tratarse como Tier 0
Este es el punto más importante del artículo.
La autoridad de certificación no es “un servidor más”.
No es “la máquina de certificados”.
No es un recurso secundario que se instaló hace años y que solo se mira cuando caduca algo.
La CA forma parte de la raíz de confianza del dominio. Si puede emitir certificados aceptados para autenticación, forma parte del corazón de la identidad.
Por tanto, debe tratarse como Tier 0.
Eso implica administración restringida, accesos mínimos, cuentas separadas, estaciones de administración privilegiada, monitorización específica, backups protegidos, procedimientos de recuperación y revisiones periódicas.
Si proteges tus controladores de dominio pero dejas la CA abandonada, estás dejando otra puerta hacia el mismo problema: controlar la identidad.
Preguntas defensivas que deberías hacerte
La pregunta no es solo:
“¿Está la CA parcheada?”
Eso importa, claro. Pero no es suficiente.
Hay preguntas mucho más importantes:
¿Quién puede administrar la CA?
¿Quién puede modificar plantillas?
¿Quién puede emitir certificados sensibles?
¿Quién puede aprobar solicitudes?
¿Quién puede exportar claves privadas?
¿Dónde están los backups de la CA?
¿Están cifrados y protegidos?
¿Quién puede restaurarlos?
¿Se ha probado el proceso de revocación?
¿Se monitoriza la emisión de certificados?
¿Se revisan solicitudes anómalas?
¿Hay certificados emitidos para cuentas privilegiadas?
¿Sabemos qué plantillas permiten autenticación?
¿Tenemos baseline de comportamiento normal?
Si no puedes responder a esto, probablemente tu AD CS necesita una revisión seria.
Golden Certificate y respuesta a incidentes
Golden Certificate obliga a pensar la respuesta a incidentes de otra manera.
En muchos incidentes Microsoft, la respuesta típica se centra en cuentas, contraseñas, endpoints, sesiones, grupos privilegiados y movimiento lateral.
Pero cuando entra en juego AD CS, hay que ampliar el alcance.
Hay que revisar la CA.
Hay que revisar plantillas.
Hay que revisar certificados emitidos.
Hay que revisar revocación.
Hay que revisar accesos administrativos a la CA.
Hay que revisar backups.
Hay que revisar logs de emisión.
Hay que revisar autenticación basada en certificados.
Porque puede que el atacante no esté volviendo con una contraseña.
Puede que esté volviendo con confianza.
Y eso es bastante más serio.
Señales que deberías monitorizar
La detección de abusos relacionados con Golden Certificate requiere madurez.
No basta con tener un SIEM lleno de eventos si nadie mira AD CS.
Algunas señales que conviene vigilar:
Cambios en la configuración de la CA.
Accesos administrativos a la CA fuera de patrón.
Intentos de exportación o acceso a claves privadas.
Cambios en plantillas de certificados.
Nuevas plantillas con permisos peligrosos.
Emisión de certificados para identidades privilegiadas.
Certificados donde solicitante y sujeto no cuadran.
Uso anómalo de autenticación basada en certificados.
Eventos de revocación inesperados.
Certificados con atributos sospechosos.
Actividad administrativa desde equipos no autorizados.
Pero hay un problema: la detección llega tarde si nunca has hecho inventario ni baseline.
Si no sabes cómo se comporta tu CA normalmente, te costará mucho distinguir lo normal de lo raro.
La PKI interna también es identidad
Golden Certificate muestra una idea que muchas empresas todavía no tienen interiorizada: la identidad en Microsoft no son solo usuarios y grupos.
También son certificados.
También es Kerberos.
También es NTLM.
También es LDAP.
También son delegaciones.
También son plantillas.
También es Entra Connect.
También son relaciones de confianza.
También son cuentas de servicio.
También son estaciones desde las que administras.
Una organización puede tener buena política de contraseñas, MFA y EDR, pero si su PKI interna está abandonada, el atacante puede buscar otro camino.
Y muchas veces lo buscará.
Porque la seguridad real no consiste en tener una medida fuerte en una zona y zonas ciegas en otra. Consiste en entender cómo se conectan todas las piezas.
Qué revisar para reducir el riesgo
Para reducir el riesgo de Golden Certificate y abusos avanzados de AD CS, conviene trabajar en varias líneas.
Primero, proteger la CA como activo crítico.
Nada de administración desde equipos de usuario. Nada de cuentas compartidas. Nada de accesos permanentes innecesarios.
Segundo, revisar plantillas y permisos.
Hay que saber qué plantillas existen, quién puede usarlas, qué EKU tienen, si permiten autenticación, si permiten SAN y si requieren aprobación.
Tercero, proteger claves y backups.
La clave privada de la CA y sus backups deben tratarse con el mismo cuidado que tratarías otros secretos Tier 0.
Cuarto, probar revocación y recuperación.
No vale tener documentación que nadie ha probado. En un incidente real, descubrir que la revocación no funciona como esperabas es una muy mala noticia.
Quinto, monitorizar.
La CA debe generar eventos útiles y esos eventos deben llegar a donde alguien pueda analizarlos.
Sexto, formar al equipo.
AD CS no se defiende por intuición. Hay que entender cómo funciona, cómo se abusa y cómo se opera de forma segura.
Por qué esto importa a empresas
Para una empresa, Golden Certificate puede parecer un tema muy avanzado.
Y lo es.
Pero el mensaje de fondo es muy práctico:
Si no proteges tu autoridad de certificación como proteges tus controladores de dominio, quizá estás dejando abierta otra forma de controlar la identidad de toda la empresa.
Eso afecta a sistemas, usuarios, administradores, VPN, WiFi, aplicaciones, servidores y autenticación.
No es un problema “de certificados”.
Es un problema de confianza.
Por eso una formación práctica en seguridad Active Directorydebe incluir AD CS, certificados, Kerberos, modelo de privilegios, auditoría y respuesta a incidentes.
Formación Microsoft, Active Directory y FUNDAE
Este tipo de temas son los que diferencian una formación de ciberseguridad real de una colección de trucos.
Un curso de ciberseguridad Microsoft para empresas debe explicar cómo funcionan las relaciones de confianza, qué impacto tiene comprometerlas y cómo construir defensas operativas.
En SeguridadSi trabajamos esa visión práctica de Active Directory, Windows Server y defensa empresarial, conectando ataque, hardening, detección y respuesta.
Y si buscas cursos de ciberseguridad para empresas con FUNDAE, esta formación ayuda a que el equipo entienda riesgos que muchas veces no se ven hasta que ya es demasiado tarde.
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
Golden Certificate nos deja una conclusión dura.
Si no proteges tu autoridad de certificación como proteges tus controladores de dominio, quizá estás dejando abierta otra forma de controlar la identidad de toda la empresa.
Una contraseña se cambia.
Una sesión se revoca.
Una cuenta se bloquea.
Pero si la confianza de la CA está comprometida, el problema es mucho más profundo.
AD CS debe tratarse como parte crítica de la seguridad Microsoft, no como una pieza olvidada de infraestructura.
Porque cuando el atacante puede emitir confianza, ya no necesita pedir permiso.
Gracias por leerme !!!
Preguntas frecuentes sobre Golden Certificate Active Directory
¿Qué es un Golden Certificate en Active Directory?
Un Golden Certificate es un certificado fraudulento generado a partir del compromiso de una autoridad de certificación o de su clave privada, permitiendo al atacante autenticarse como identidades confiadas por el dominio.
¿Por qué Golden Certificate es tan peligroso?
Es peligroso porque puede permitir persistencia incluso después de cambiar contraseñas o revocar sesiones. Si el certificado sigue siendo válido y confiado, el atacante puede conservar acceso.
¿Qué relación tiene Golden Certificate con AD CS?
Golden Certificate está relacionado con Active Directory Certificate Services porque AD CS gestiona la emisión de certificados dentro del entorno Microsoft. Si la CA se compromete, la confianza completa puede verse afectada.
¿Cómo se reduce el riesgo de Golden Certificate?
Protegiendo la CA como Tier 0, restringiendo administradores, revisando plantillas, protegiendo claves privadas y backups, monitorizando emisión de certificados y probando revocación y recuperación.
¿Qué formación ayuda a defenderse frente a este riesgo?
Una formación práctica en seguridad Microsoft, Active Directory, AD CS, Kerberos, modelo de privilegios, auditoría y respuesta a incidentes ayuda a entender cómo se abusa la confianza y cómo protegerla.
