¿Qué es un ataque Silver Ticket?
Un ataque Silver Ticket consiste en forjar un ticket de servicio Kerberos (TGS) usando el secreto de la cuenta de servicio objetivo. MITRE clasifica la técnica como T1558.002, Silver Ticket.
El alcance es más estrecho que el de un Golden Ticket, pero el mecanismo es importante. Un atacante que conoce el hash de contraseña o la clave Kerberos de una cuenta de servicio puede forjar un ticket para ese servicio y presentarlo directamente al host que lo ejecuta. MITRE deja claros tres puntos:
- el atacante necesita el hash de contraseña de la cuenta de servicio objetivo
- el ticket forjado es un ticket de servicio, no un TGT
- el ticket puede crearse sin interactuar con el KDC
Ese último punto explica su valor. El atacante no pide al controlador de dominio que emita el ticket de servicio en tiempo real. Lo forja offline y luego lo presenta al servicio objetivo.
El alcance de este artículo es Kerberos en Windows Active Directory. El foco son los prerrequisitos reales, la diferencia con Golden Ticket y el hardening de cuentas de servicio que elimina oportunidades prácticas.
Cómo funciona el ataque Silver Ticket
En un flujo Kerberos normal, el Key Distribution Center emite un ticket de servicio después de que el cliente presenta un TGT válido. Silver Ticket rompe ese flujo esperado forjando directamente el ticket de servicio.
MITRE indica que adversarios con el hash de contraseña de una cuenta de servicio objetivo pueden forjar Kerberos ticket granting service tickets, es decir, tickets de servicio. A diferencia de Golden Ticket, estos tickets quedan limitados a un recurso y al sistema que lo aloja. Pero pueden generarse sin interacción con el KDC.
Esto tiene dos consecuencias:
- el ticket está limitado a un service principal específico
- la detección es más difícil porque falta el camino normal de emisión en el controlador de dominio
Por qué importa el secreto de la cuenta de servicio
Silver Ticket funciona porque el atacante conoce la clave de la cuenta de servicio objetivo. Ese secreto puede venir de:
- credential dumping tras comprometer un servidor
- extracción del hash de la cuenta de servicio en un host donde corre el servicio
- Kerberoasting: Riesgo en Cuentas de Servicio, que MITRE cita como una vía para obtener el hash objetivo
Si el atacante no obtiene el secreto de la cuenta de servicio, no puede forjar un Silver Ticket utilizable para ese servicio.
La PAC debe explicarse con cuidado
La documentación Microsoft sobre PAC muestra que el procesamiento puede depender del modelo de aplicación y de supuestos de confianza. Microsoft menciona que la validación PAC puede ser opcional para una aplicación autocontenida.
Esa nuance importa, pero no debe exagerarse. El prerrequisito central sigue siendo poseer el secreto de la cuenta de servicio y apuntar a un servicio que acepte el ticket presentado. La PAC es parte del procesamiento del servicio, no una explicación universal para todos los casos de éxito.
Silver Ticket vs Golden Ticket, Kerberoasting y Pass-the-Ticket
Estos términos se mezclan con frecuencia, pero no son equivalentes.
- Silver Ticket: ticket de servicio forjado para un servicio concreto tras obtener el secreto de la cuenta de servicio
- Golden Ticket: TGT forjado a partir del secreto
krbtgt, con impacto mucho más amplio en el dominio. Ver Ataque Golden Ticket — Deteccion & Remediacion - Kerberoasting: solicitar tickets de servicio legítimos al KDC y crackearlos offline para recuperar secretos de cuentas de servicio
- Pass-the-Ticket: reutilizar un ticket Kerberos real robado, no forjado
Silver Ticket suele aparecer después de otra técnica. Kerberoasting o credential dumping obtiene el secreto; Silver Ticket convierte ese secreto en acceso no autorizado al servicio.
Por qué Silver Ticket sigue importando
Silver Ticket es menos famoso que Golden Ticket, pero ataca una debilidad común: secretos de cuentas de servicio mal gestionados.
Las cuentas de servicio suelen vivir demasiado
Las cuentas de servicio sobreviven durante años, respaldan varias aplicaciones y acumulan SPN, permisos locales y excepciones operativas. Es exactamente el tipo de secreto estable que busca un atacante.
El ataque es más silencioso que un flujo KDC normal
MITRE destaca el problema de detección: el ticket puede crearse sin interacción con el KDC. Parte de la visibilidad normal del controlador de dominio falta desde el momento de la forja.
La higiene de cuentas de servicio sigue siendo débil
Microsoft documenta cuentas de servicio administradas porque la gestión manual de contraseñas de servicio es propensa a errores. Una cuenta de usuario normal usada como servicio sigue siendo un lugar común para secretos antiguos, rotación débil y cifrado inconsistente.
El cifrado Kerberos legacy aumenta la exposición
La guía Microsoft actual sigue empujando auditoría y reducción de RC4 en Kerberos. Esto importa porque las cuentas antiguas con postura de cifrado legacy suelen pertenecer a la misma población de cuentas de servicio mal gestionadas.
Prerrequisitos de un ataque Silver Ticket exitoso
Silver Ticket no es un truco Kerberos sin condiciones.
1. El atacante debe obtener el secreto de la cuenta de servicio
Es el prerrequisito central. MITRE afirma que se necesita el hash de la cuenta de servicio objetivo. Las rutas comunes son credential dumping y Kerberoasting.
2. El servicio objetivo debe depender de ese service principal
El ticket forjado debe coincidir con una identidad de servicio real aceptada por el host. Por eso el alcance es menor que Golden Ticket.
3. El ticket debe ser aceptado por el camino de servicio
La documentación Microsoft sobre PAC explica por qué el procesamiento puede variar por aplicación. Pero eso no elimina la necesidad de apuntar al service principal correcto con el secreto correcto.
4. La cuenta de servicio debe tener valor
Un ticket para un servicio de bajo valor sigue siendo problema, pero el riesgo real aparece cuando la cuenta está ligada a una aplicación sensible, workflow administrativo o host privilegiado.
5. La higiene de cuentas de servicio es débil
Cuentas de usuario usadas como servicios, ausencia de gMSA, contraseñas antiguas, privilegios excesivos o dependencia de RC4 hacen más realistas los prerrequisitos.
Cadena de ataque
Una cadena Silver Ticket práctica suele verse así.
Paso 1 - Identificar una cuenta de servicio útil
El atacante mapea SPN, servicios y sistemas para encontrar un service principal con valor.
Paso 2 - Obtener el hash o clave de la cuenta
El secreto se obtiene por dumping, cracking offline tras Kerberoasting u otro camino de acceso a credenciales.
Paso 3 - Forjar el ticket de servicio offline
Con el secreto, el atacante crea un ticket de servicio Kerberos para el service principal elegido.
Paso 4 - Presentar el ticket directamente al servicio
Aquí Silver Ticket se separa del flujo Kerberos normal. MITRE indica que el ticket forjado puede usarse sin interacción con el KDC.
Paso 5 - Usar el acceso dentro del alcance del servicio
El acceso es más estrecho que Golden Ticket, pero puede ser serio si el servicio corre en un host sensible, expone funciones administrativas o habilita movimiento lateral.
Por eso Silver Ticket pertenece a la revisión de Rutas de ataque AD: como se encadenan hasta Domain Admin.
Detección
Detectar Silver Ticket es difícil porque el atacante puede no pedir nunca al KDC el ticket que usa.
El modelo correcto es detección de anomalías más detección de prerrequisitos, no un único Event ID milagroso.
Buscar uso de tickets que no encaja con el KDC
La estrategia MITRE DET0241 recomienda buscar actividad anómala de tickets de servicio, incluida actividad sin los patrones esperados de validación o emisión del KDC.
Investiga casos donde:
- una cuenta de servicio aparece en hosts o recursos fuera de su alcance esperado
- el servicio ve actividad Kerberos que no encaja con patrones normales de emisión TGS en el KDC
- aparecen campos raros o malformados en datos de logon o ticket
No es una regla trivial. Necesitas una baseline de qué hosts y recursos debe tocar cada cuenta de servicio.
Vigilar los ataques prerrequisito
MITRE también menciona acceso sospechoso a LSASS y credential dumping como fuentes útiles. El secreto de la cuenta de servicio suele robarse antes de que exista el Silver Ticket.
Vigila:
- acceso sospechoso a LSASS
- comportamiento de credential dumping
- Kerberoasting: Riesgo en Cuentas de Servicio
- autenticaciones de cuentas de servicio fuera de alcance
Detectar la cadena previa suele ser más fiable que buscar solo el ticket final.
Usar contexto Kerberos con prudencia
El evento 4769 es útil porque representa una solicitud normal de ticket de servicio al KDC. Para Silver Ticket, el punto no es alertar simplemente cuando falta 4769. El punto es que un ticket forjado puede no seguir el camino normal de emisión. Esa lógica necesita baseline y contexto.
Vigilar cuentas de servicio fuera de su radio esperado
MITRE llama explícitamente a detectar intentos de acceso con cuentas de servicio fuera de hosts o recursos esperados. Esto suele ser más accionable que señales puramente protocolares.
Correlacionar actividad privilegiada posterior
Si el ticket llega a un servicio con impacto administrativo, pueden aparecer:
- accesos inusuales a funciones administrativas de la aplicación
- logons o accesos al host del servicio desde identidades inesperadas
- acciones privilegiadas posteriores
- anomalías cubiertas en Supervision Seguridad AD: Event IDs y SIEM
Remediación
La mitigación de Silver Ticket es principalmente higiene de cuentas de servicio. Si el atacante no puede obtener un secreto reutilizable, no puede forjar el ticket.
1. Migrar servicios elegibles a gMSA
La documentación Microsoft sobre group Managed Service Accounts es la mitigación primaria más clara. Los gMSA permiten a Windows gestionar contraseñas de cuentas de servicio, rotar claves y reducir sincronización manual. Eso aborda directamente secretos estáticos o mal gestionados.
2. Configurar AES para cuentas de servicio administradas
Microsoft indica que las Managed Service Accounts dependen de los tipos de cifrado Kerberos soportados y recomienda configurar siempre AES para MSA. Si el host no soporta RC4, la autenticación falla cuando la cuenta no tiene postura AES correcta.
3. Restablecer contraseñas antiguas de cuentas de servicio
La guía Microsoft sobre RC4 explica que cuentas antiguas pueden no tener claves AES si su contraseña no se cambió tras añadirse soporte AES. Cambiar la contraseña genera esas claves.
4. Reducir dependencia de RC4
Microsoft ofrece pasos actuales para auditar y remediar RC4 en Kerberos. No hace imposible Silver Ticket por sí solo, pero elimina una debilidad legacy de la misma población de cuentas de servicio. También complementa AS-REP Roasting: Recopilando Hashes Sin Credenciales.
5. Minimizar privilegios y alcance
Un ticket forjado solo es tan útil como la cuenta detrás. Las cuentas de servicio no deberían tener derechos locales admin, grupos privilegiados o acceso amplio si el servicio no lo necesita.
6. Inventariar SPN y ownership
Un programa serio debe saber:
- qué SPN corresponden a qué cuentas
- qué hosts deben usar esas cuentas
- quién es responsable de cada cuenta
- si puede migrar a gMSA
- si sigue dependiendo de RC4 o legacy
Esto encaja con Auditar la seguridad de Active Directory: checklist práctica.
7. Tratar Kerberoasting y dumping como precursores directos
Si un atacante puede dumpear o crackear el secreto de una cuenta de servicio, el camino Silver Ticket queda abierto. Revisa Kerberoasting: Riesgo en Cuentas de Servicio, Delegacion Kerberos: no restringida, restringida y RBCD y Ataque Golden Ticket — Deteccion & Remediacion.
Validación tras el hardening
No cierres el riesgo Silver Ticket por un solo cambio de contraseña.
- confirmar qué servicios siguen usando cuentas de usuario normales en vez de gMSA
- comprobar que las cuentas tienen claves AES y si RC4 sigue en uso
- revisar
msDS-SupportedEncryptionTypescuando aplique - comparar configuración con uso Kerberos real en controladores de dominio
- analizar eventos
4769para entender qué cuentas solicitan tickets y con qué cifrado - confirmar que servicios sensibles no dependen de identidades compartidas, antiguas o sin documentar
- eliminar privilegios superiores a los necesarios
El éxito real no es solo mejor política Kerberos. Es que comprometer una cuenta de servicio ya no entregue un secreto estable y reutilizable de alto valor.
Cómo EtcSec detecta exposición relacionada
No existe un tipo exacto Silver Ticket en el catálogo actual. Los hallazgos más útiles son los prerrequisitos y debilidades Kerberos que hacen práctica la técnica.
Los más relevantes son:
KERBEROASTING_RISK, porque recuperar offline un secreto de cuenta de servicio es precursor directoKERBEROS_RC4_FALLBACK, porque la postura Kerberos legacy suele solaparse con cuentas de servicio mal gestionadas- cuentas de servicio sobreprivilegiadas o demasiado amplias
- condiciones de attack path de Rutas de ataque AD: como se encadenan hasta Domain Admin
El modelo correcto: Silver Ticket es una técnica de ticket forjado, pero la superficie real de corrección es higiene de cuentas de servicio.
Controles relacionados
Si revisas riesgo Silver Ticket, revisa también Ataque Golden Ticket — Deteccion & Remediacion, Kerberoasting: Riesgo en Cuentas de Servicio, AS-REP Roasting: Recopilando Hashes Sin Credenciales, Delegacion Kerberos: no restringida, restringida y RBCD, Supervision Seguridad AD: Event IDs y SIEM, Rutas de ataque AD: como se encadenan hasta Domain Admin, Auditar la seguridad de Active Directory: checklist práctica y Comparativa de herramientas de auditoría AD.
