Estimados amigos de Inseguros !!!
Hay ataques que se solucionan cambiando una contraseña, cerrando una sesión o deshabilitando una cuenta.
Y luego está Golden Ticket.
Golden Ticket es uno de esos conceptos que muchas veces se explican como si fueran magia negra, pero en realidad nos está diciendo algo muy sencillo: si el atacante consigue el secreto con el que el dominio firma los tickets Kerberos, deja de necesitar tus usuarios.
Puede fabricar autenticaciones aparentemente válidas y moverse como si fuera quien dice ser.
Aquí aparece una cuenta que muchos administradores han visto mil veces y a la que no siempre se le presta suficiente atención: KRBTGT.
Esa cuenta no es una cuenta de usuario normal. Es una pieza clave del funcionamiento de Kerberos en Active Directory. Y cuando su hash queda comprometido, el problema no es solo que alguien se haya llevado una contraseña.
El problema es que puede fabricar tickets.
Cuando hablamos de Golden Ticket Active Directory, hablamos de uno de los escenarios más críticos de compromiso en entornos Microsoft.
Qué es un Golden Ticket
Un Golden Ticket es un ticket Kerberos falsificado que el entorno puede aceptar como válido porque está firmado con el secreto asociado a KRBTGT.
Dicho de forma sencilla: el atacante no necesita pedir permiso al dominio de forma normal. Si tiene el material adecuado, puede generar un Ticket Granting Ticket y usarlo para solicitar acceso a servicios dentro del dominio.
Eso permite suplantar identidades, mantener persistencia y operar con una apariencia de legitimidad difícil de detectar.
Por eso Golden Ticket no es solo una técnica ofensiva.
Es una prueba de hasta qué punto Active Directory depende de la confianza en Kerberos y en la cuenta KRBTGT.
Por qué KRBTGT es tan importante
KRBTGT es una cuenta especial de Active Directory utilizada por el KDC en el proceso de autenticación Kerberos.
No es una cuenta para iniciar sesión como un usuario normal. No se administra como una cuenta cualquiera. No debería tratarse como un objeto olvidado en la carpeta Users.
Su importancia viene de que el secreto de KRBTGT se usa para proteger los Ticket Granting Tickets del dominio.
Si ese secreto queda comprometido, el atacante puede construir tickets que el dominio acepte.
Y ahí está el problema: cambiar la contraseña de un usuario no invalida automáticamente un Golden Ticket si el atacante sigue teniendo capacidad para generar tickets válidos con el secreto robado.
Por qué Golden Ticket es tan peligroso
Lo peligroso de Golden Ticket no es únicamente el privilegio.
Es la persistencia.
En un incidente, una empresa puede hacer muchas cosas bien:
Cambiar contraseñas de usuarios.
Borrar cuentas sospechosas.
Deshabilitar accesos.
Reinstalar servidores.
Desplegar EDR.
Revisar endpoints.
Cerrar sesiones.
Bloquear cuentas comprometidas.
Pero si nadie rota correctamente KRBTGT, el atacante puede conservar una forma de volver.
Ese es el punto incómodo.
Golden Ticket afecta a la raíz de confianza del dominio. No hablamos de una aplicación aislada, ni de un servidor concreto. Hablamos del sistema que decide quién eres, qué puedes hacer y a qué puedes acceder.
Si el atacante controla esa capa, todo lo demás queda condicionado.
Cómo deberíamos mirarlo en una empresa
En una auditoría seria de Active Directory, Golden Ticket no se mira como una curiosidad de laboratorio.
Se mira dentro de una cadena completa.
La pregunta no es solo:
“¿Podrían hacernos un Golden Ticket?”
La pregunta correcta es:
“Si alguien lo hubiera hecho hace tres meses, ¿lo sabríamos?”
Para responder a eso hay que revisar muchas piezas:
Cómo podría obtenerse el hash de KRBTGT.
Qué cuentas tienen permisos de replicación.
Si existen señales de DCSync.
Si hay riesgo de extracción de NTDS.dit.
Si los backups de controladores de dominio están bien protegidos.
Si existen copias antiguas con secretos críticos.
Si hay cuentas privilegiadas usadas desde estaciones normales.
Si existe un procedimiento real de rotación de KRBTGT.
Si se monitoriza Kerberos con criterio.
Si los administradores trabajan bajo modelo Tier.
Golden Ticket rara vez aparece aislado.
Suele ser la consecuencia de haber perdido antes otras capas de defensa.
Señales de detección
Detectar Golden Ticket puede ser complicado porque el ticket puede parecer legítimo desde el punto de vista del servicio que lo recibe.
Aun así, hay señales que deberían investigarse:
Autenticaciones de cuentas inexistentes.
Tickets con vida útil anormal.
Uso de cifrados antiguos o débiles.
Actividad privilegiada fuera de patrón.
Accesos administrativos desde equipos que no deberían tocar Tier 0.
Sesiones que no encajan con la secuencia normal de autenticación Kerberos.
Cambios raros en grupos privilegiados después de autenticaciones sospechosas.
Acceso a servicios críticos desde orígenes no habituales.
Uso de cuentas privilegiadas en horarios o ubicaciones extrañas.
No basta con guardar logs.
Hay que correlacionar.
Hay que entender Kerberos.
Y hay que tener una línea base de comportamiento normal de los administradores.
Si nunca has definido qué es normal en tu entorno, detectar lo anormal será mucho más difícil.
Mitigación práctica
La medida clásica cuando KRBTGT puede estar comprometido es rotar su contraseña dos veces, dejando tiempo suficiente entre ambas rotaciones para que el cambio replique correctamente y los tickets antiguos expiren.
Pero esto no debería descubrirse por primera vez en mitad de un ransomware.
La empresa debería tener el procedimiento documentado, probado en un entorno controlado y asumido dentro del plan de respuesta a incidentes.
Además, hay que proteger la fuente del problema.
Limitar permisos de replicación.
Reducir Domain Admins.
Proteger backups de controladores de dominio.
Usar estaciones PAW para administración.
Aplicar modelo Tier.
Revisar rutas de ataque.
Monitorizar actividad contra controladores de dominio.
Controlar DCSync.
Proteger NTDS.dit.
Separar cuentas administrativas y cuentas de uso diario.
Golden Ticket se mitiga evitando que el atacante llegue al secreto de KRBTGT y teniendo capacidad real de respuesta si eso ocurre.
El problema de recuperar tarde
Una empresa que descubre tarde un Golden Ticket tiene un problema muy serio.
Porque no sabe cuánto tiempo lleva el atacante usando esa capacidad. No sabe qué accesos ha realizado. No sabe qué sistemas tocó. No sabe si creó nuevas persistencias. No sabe si extrajo más secretos.
Por eso la respuesta no puede limitarse a una acción rápida y aislada.
Hay que investigar alcance, timeline, cuentas implicadas, accesos a controladores de dominio, posibles DCSync, extracción de NTDS.dit, cambios en grupos críticos, actividad administrativa y persistencias adicionales.
Cuando se compromete Kerberos, hay que pensar en dominio completo.
Golden Ticket y hardening de Active Directory
Golden Ticket es una razón más para tomarse en serio el hardening de Active Directory.
Y hardening no significa solo poner una política de contraseña más larga.
Significa ordenar privilegios, reducir exposición, separar administración, controlar rutas de acceso, monitorizar eventos críticos y formar al equipo que opera el entorno.
Algunas medidas importantes:
Modelo Tier 0, Tier 1 y Tier 2.
PAW para administración privilegiada.
Revisión periódica de cuentas privilegiadas.
Rotación controlada de KRBTGT.
Protección de backups.
Monitorización Kerberos.
Reducción de permisos de replicación.
Control de cuentas de servicio.
Eliminación de delegaciones peligrosas.
Revisión de sesiones administrativas.
Procedimientos de respuesta documentados.
Active Directory no se defiende solo con una herramienta.
Se defiende con arquitectura, operación y criterio.
Por qué esto importa a empresas
Para una empresa, Golden Ticket puede sonar a técnica avanzada.
Y lo es.
Pero el mensaje práctico es muy claro:
Si alguien compromete la raíz de confianza Kerberos, cambiar contraseñas puede no ser suficiente.
Y eso afecta a toda la organización.
Usuarios.
Servidores.
Aplicaciones.
Recursos compartidos.
Sistemas críticos.
Administradores.
Cloud híbrido.
Backups.
Herramientas de gestión.
Active Directory sigue siendo una pieza central en muchas empresas. Y cuando la identidad cae, todo lo demás se tambalea.
Por eso este tema debe formar parte de cualquier estrategia seria de seguridad avanzada en Active Directory.
Formación Microsoft, Active Directory y FUNDAE
Si quieres aprender esto con más profundidad, con enfoque de empresa y no como una lista de comandos sueltos, en el curso de ciberseguridad Microsoft trabajamos Active Directory desde ataque, defensa, hardening, detección y reducción de riesgo.
Es formación avanzada para perfiles IT y ciberseguridad que necesitan entender cómo se comprometen los entornos Microsoft y cómo se defienden de verdad.
También encaja muy bien para empresas que quieren formar a su equipo técnico mediante cursos de ciberseguridad para empresas.
Además, este enfoque está alineado con guías defensivas como la guía Five Eyes sobre ataques y mitigación en Active Directory, donde se trata Golden Ticket como un abuso crítico relacionado con KRBTGT, replicación, NTDS.dit y recuperación del dominio. Fuente técnica: Five Eyes Active Directory Attacks Guide.
Conclusión
Golden Ticket deja una lección muy clara.
No todo se arregla cambiando contraseñas.
Si el atacante consigue el secreto de KRBTGT, puede fabricar confianza dentro del dominio. Y cuando el atacante puede fabricar confianza, la recuperación exige mucho más que limpiar una máquina o bloquear una cuenta.
Hay que entender Kerberos.
Hay que proteger Tier 0.
Hay que vigilar DCSync.
Hay que proteger NTDS.dit.
Hay que saber rotar KRBTGT.
Hay que formar al equipo.
Porque en Active Directory, a veces el problema no es que alguien tenga una llave.
El problema es que puede fabricar todas las llaves que quiera.
Gracias por leerme !!!
Preguntas frecuentes sobre Golden Ticket Active Directory
¿Qué es un Golden Ticket en Active Directory?
Un Golden Ticket es un ticket Kerberos falsificado que puede permitir a un atacante suplantar identidades dentro del dominio si ha conseguido el secreto asociado a la cuenta KRBTGT.
¿Por qué KRBTGT es tan importante?
KRBTGT es una cuenta clave para Kerberos en Active Directory. Su secreto se usa para proteger los Ticket Granting Tickets del dominio, por lo que su compromiso afecta a la raíz de confianza de la autenticación.
¿Cambiar contraseñas elimina un Golden Ticket?
No necesariamente. Si KRBTGT sigue comprometido, cambiar contraseñas de usuarios puede no ser suficiente. En incidentes graves puede ser necesario rotar KRBTGT correctamente.
¿Cómo se mitiga Golden Ticket?
La mitigación pasa por proteger KRBTGT, limitar permisos de replicación, prevenir DCSync, proteger NTDS.dit, aplicar modelo Tier, usar PAW, monitorizar Kerberos y tener un procedimiento probado de rotación de KRBTGT.
¿Qué relación tiene Golden Ticket con DCSync?
DCSync puede usarse para obtener hashes del dominio, incluyendo KRBTGT. Si un atacante consigue ese hash, puede generar Golden Tickets y mantener persistencia avanzada en Active Directory.
