¿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 por qué los Silver Ticket siguen siendo valiosos. 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 entornos Kerberos de Windows Active Directory. El foco son la cadena real de prerrequisitos, el comportamiento de protocolo que distingue el ataque de Golden Ticket, y el hardening de cuentas de servicio que realmente elimina la oportunidad.
Cómo funciona el ataque Silver Ticket
Kerberos depende normalmente de que el Key Distribution Center emita tickets de servicio después de que un cliente presenta un TGT válido. Silver Ticket rompe ese flujo esperado forjando directamente el ticket de servicio.
La página de MITRE sobre la técnica Silver Ticket 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 concreto y al sistema que lo aloja. Pero a diferencia de un Golden Ticket, el atacante puede crear el ticket sin interactuar con el KDC.
Esa diferencia de diseño tiene dos consecuencias directas:
- el ticket forjado queda limitado a un service principal concreto en lugar de a todo el dominio
- la detección suele ser más difícil porque falta el camino normal de emisión del controlador de dominio
Por qué importa el secreto de la cuenta de servicio
Silver Ticket funciona porque el atacante conoce la clave que usa la cuenta de servicio objetivo. Ese secreto puede provenir de:
- credential dumping directo tras comprometer un sistema
- la extracción del hash de contraseña de una cuenta de servicio en un servidor donde corre el servicio
- Kerberoasting: Riesgo en Cuentas de Servicio, que MITRE nombra explícitamente como una vía para obtener el hash objetivo
Si el atacante no logra obtener el secreto del servicio objetivo, no puede forjar un Silver Ticket utilizable para ese servicio.
Por qué algunos tickets forjados igualmente llegan al servicio
La documentación de Microsoft sobre Kerberos muestra que el manejo de la PAC depende del modelo de aplicación y de las suposiciones de confianza. En particular, Microsoft señala que la validación de la PAC puede ser opcional para una aplicación autocontenida.
Esa matización importa, pero no debe sobrevalorarse. El prerrequisito central de Silver Ticket sigue siendo la posesión del secreto de la cuenta de servicio objetivo y un camino de servicio objetivo dispuesto a aceptar el ticket forjado. El comportamiento de la PAC es una parte del modelo de procesamiento del lado del servicio, no una explicación completa de cada caso exitoso de ticket forjado.
Silver Ticket vs. Golden Ticket, Kerberoasting y Pass-the-Ticket
Estos términos se mezclan a menudo. No deberían.
- Silver Ticket: ticket de servicio forjado para un servicio específico tras obtener el secreto de la cuenta de servicio
- Golden Ticket: TGT forjado a partir del secreto
krbtgt, con un impacto mucho más amplio a nivel de 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. Ver Kerberoasting: Riesgo en Cuentas de Servicio
- Pass-the-Ticket: reproducir o reutilizar un ticket Kerberos real que fue robado en lugar de forjado
Silver Ticket suele aparecer después de otro ataque prerrequisito. Kerberoasting o el credential dumping obtiene el secreto de la cuenta de servicio. Silver Ticket convierte ese secreto en acceso no autorizado al servicio.
Por qué los Silver Ticket siguen importando
Los Silver Ticket son menos famosos que los Golden Ticket, pero siguen siendo importantes porque atacan una debilidad empresarial común: secretos de cuentas de servicio mal gestionados.
Las cuentas de servicio suelen ser más amplias y antiguas de lo que los equipos creen
Las cuentas de servicio tienden a sobrevivir durante años, dar soporte a múltiples aplicaciones y acumular SPN, derechos locales y excepciones operativas. Eso crea exactamente el tipo de secreto de larga vida que un atacante busca.
El ataque es más silencioso que un flujo de servicio normal emitido por el KDC
MITRE destaca directamente el problema de detección más importante: los Silver Ticket forjados pueden crearse sin interactuar con el KDC. Eso significa que, desde el momento en que se forja el ticket, falta parte de la visibilidad habitual del controlador de dominio en la que confían los defensores.
La higiene débil de cuentas de servicio sigue existiendo
La guía de Microsoft sobre cuentas de servicio administradas existe porque la gestión manual de contraseñas de servicio es propensa a errores. Una cuenta de usuario normal que ejecuta un servicio sigue siendo uno de los lugares más fáciles para acumular claves antiguas, rotación débil y configuraciones de cifrado inconsistentes.
El cifrado Kerberos legacy sigue aumentando el riesgo
Microsoft ha ido ahora más allá de simplemente eliminar RC4 de forma progresiva. Bajo el despliegue de CVE-2026-20833, las actualizaciones desde el 13 de enero de 2026 añadieron eventos de auditoría, las actualizaciones desde el 14 de abril de 2026 cambiaron el valor predeterminado del KDC para DefaultDomainSupportedEncTypes a solo AES-SHA1 (0x18), y las actualizaciones publicadas a partir de julio de 2026 eliminaron la subclave de registro RC4DefaultDisablementPhase que permitía revertir el cambio. Un controlador de dominio sin configuración explícita ahora asume solo AES. Eso es relevante porque las cuentas de servicio con una postura de cifrado antigua suelen ser las mismas cuentas que permanecen mal gestionadas operativamente, y son las que fallan o mantienen silenciosamente una clave RC4 en cuanto cambia el valor predeterminado.
Prerrequisitos de un ataque Silver Ticket exitoso
Silver Ticket no es un truco Kerberos de un solo clic. Varias condiciones tienen que alinearse.
1. El atacante debe obtener el secreto de la cuenta de servicio objetivo
Este es el prerrequisito no negociable. MITRE dice explícitamente que el atacante necesita el hash de contraseña de la cuenta de servicio objetivo. Las vías de adquisición comunes son el credential dumping y Kerberoasting.
2. El servicio objetivo debe depender de ese service principal
El ticket forjado tiene que coincidir con una identidad de servicio real que el host acepte. El alcance es, por tanto, más estrecho que el de un Golden Ticket.
3. El ticket forjado tiene que ser aceptado por el camino de servicio objetivo
La documentación de Microsoft sobre la PAC muestra por qué el procesamiento del lado del servicio puede variar según el diseño de la aplicación. Esa matización es útil para entender el protocolo, pero no elimina la necesidad de que el atacante apunte al service principal correcto con el secreto correcto.
4. La cuenta de servicio debe ser lo bastante valiosa para importar
Un ticket forjado para un servicio de bajo valor sigue siendo un problema, pero la preocupación real es una cuenta de servicio vinculada a una aplicación sensible, un flujo de trabajo administrativo o un host privilegiado.
5. El entorno todavía tiene una higiene débil de cuentas de servicio
Cuentas de servicio basadas en usuario de larga vida, falta de adopción de gMSA, rotación débil, cuentas de servicio con privilegios excesivos o claves antiguas dependientes solo de RC4 hacen que los prerrequisitos de Silver Ticket sean más realistas de lo que deberían.
La cadena de ataque
Una intrusión práctica de Silver Ticket suele verse así.
Paso 1 - Identificar una cuenta de servicio que valga la pena atacar
El atacante mapea SPN, servicios y sistemas para encontrar un service principal que daría un acceso útil si se compromete.
Paso 2 - Obtener el hash o la clave de la cuenta de servicio
El atacante obtiene el secreto mediante dumping, cracking offline tras Kerberoasting u otro camino de acceso a credenciales.
Paso 3 - Forjar el ticket de servicio offline
Usando el secreto del servicio, el atacante crea un ticket de servicio Kerberos para el service principal elegido.
Paso 4 - Presentar el ticket forjado directamente al servicio
Aquí es donde Silver Ticket diverge del camino Kerberos normal. MITRE señala que el ticket forjado puede usarse sin interactuar con el KDC.
Paso 5 - Usar el acceso resultante dentro del alcance del servicio
El acceso es más estrecho que el de un Golden Ticket, pero puede seguir siendo grave operativamente si el servicio corre en un host sensible, expone funciones administrativas o habilita movimiento lateral.
Por eso Silver Ticket pertenece a la misma revisión que Rutas de ataque AD: como se encadenan hasta Domain Admin. Incluso un ticket de servicio limitado puede convertirse en parte de una cadena mucho más grande.
Detección
Detectar Silver Ticket es difícil por una razón simple: el atacante puede no pedir nunca al KDC el ticket de servicio que usa.
El modelo correcto es, por tanto, detección de anomalías más detección de prerrequisitos, no un único Event ID que demuestre el caso de forma mágica.
Buscar uso de tickets de servicio que no encaja con la actividad esperada del KDC
La estrategia de detección de MITRE para Silver Ticket (DET0241) describe uno de los mejores enfoques de alto nivel: buscar actividad anómala de tickets de servicio Kerberos, incluidos campos malformados en eventos de inicio de sesión y solicitudes TGS sin interacción con el KDC.
En términos operativos, eso significa investigar casos en los que:
- una cuenta de servicio se usa en un host o recurso fuera de su alcance normal
- el servicio objetivo ve actividad autenticada con Kerberos que no encaja limpiamente con los patrones esperados de emisión de tickets de servicio por parte del KDC
- aparecen campos malformados o inusuales en datos de logon o de procesamiento de tickets
Esta no es una regla trivial de implementar. Depende de tener una baseline de qué hosts y recursos debería tocar realmente cada cuenta de servicio.
Vigilar los ataques prerrequisito, no solo el ticket forjado en sí
La estrategia de detección de MITRE también señala directamente el acceso sospechoso a LSASS y el credential dumping como fuentes de datos útiles. Eso importa porque el secreto de la cuenta de servicio normalmente tiene que ser robado antes de que exista el Silver Ticket.
Si ya monitorizas:
- acceso sospechoso a LSASS
- comportamiento de credential dumping
- Kerberoasting: Riesgo en Cuentas de Servicio
- patrones de autenticación inusuales de cuentas de servicio
entonces estás mucho más cerca de detectar la cadena de ataque real que si solo buscas un único indicador final de ticket forjado.
Usar el contexto de eventos Kerberos con cuidado
La guía de Microsoft sobre Kerberos y el evento 4769 sigue siendo útil porque documenta que una solicitud normal de ticket de servicio es visible en el KDC como un evento de ticket de servicio. Eso hace que 4769 sea un contexto valioso para la actividad Kerberos normal.
Para investigaciones de Silver Ticket, el punto no es "alertar cuando falta 4769" en abstracto. El punto es entender que un ticket de servicio forjado puede no seguir el mismo camino de emisión del KDC que un ticket de servicio legítimo. Cualquier detección basada en esta idea necesita contexto de baseline, no una regla simplista de un solo evento.
Vigilar cuentas de servicio fuera de su radio de acción esperado
La estrategia de detección de MITRE para Silver Ticket señala específicamente los intentos de acceso usando cuentas de servicio fuera de los hosts o recursos esperados. Esta es una de las detecciones más útiles operativamente porque es comprensible para los defensores y está ligada al alcance real de la cuenta de servicio.
Correlacionar con actividad privilegiada posterior
Si el ticket forjado llega a un servicio con impacto administrativo, las siguientes señales pueden aparecer como:
- acceso inusual a funciones administrativas en la aplicación objetivo
- logons al host del servicio desde identidades que no deberían estar presentes ahí
- acciones privilegiadas posteriores tras aceptar el ticket
- anomalías circundantes ya cubiertas en Supervision Seguridad AD: Event IDs y SIEM
Remediación
La mitigación de Silver Ticket es principalmente hardening de cuentas de servicio. Si el atacante no puede obtener un secreto de cuenta de servicio reutilizable, no puede forjar el ticket.
1. Migrar los servicios elegibles a gMSA
La guía de Microsoft sobre group Managed Service Accounts es la mitigación de fuente primaria más clara aquí.
Microsoft documenta que los gMSA:
- permiten que Windows gestione la administración de contraseñas de las cuentas de servicio
- cambian periódicamente las claves usadas por la cuenta
- permiten que los hosts miembros obtengan los valores de contraseña actual y anterior desde el controlador de dominio
- reducen la necesidad de que los administradores gestionen la sincronización de contraseñas manualmente
Eso aborda directamente uno de los mayores prerrequisitos de Silver Ticket: secretos de cuentas de servicio estáticos o mal gestionados.
2. Configurar soporte AES para cuentas de servicio administradas
La documentación de Microsoft sobre gMSA es explícita: las cuentas de servicio administradas dependen de los tipos de cifrado Kerberos soportados, y siempre se debe configurar AES para las MSA. El controlador de dominio lee el atributo msDS-SupportedEncryptionTypes de la cuenta para decidir qué soporta el servidor, y cuando ese atributo no está definido, trata la cuenta como si no soportara los tipos más fuertes. Así que, si has endurecido el host para rechazar RC4 mientras el atributo sigue sin definirse, la autenticación siempre falla. Por eso la postura de cifrado tiene que ser explícita en lugar de asumida.
3. Restablecer contraseñas antiguas de cuentas de servicio para generar claves AES
La guía de Microsoft sobre remediación de RC4 en Kerberos explica que las cuentas creadas antes del soporte de AES pueden carecer de claves AES si sus contraseñas nunca se restablecieron después de añadirse el soporte de AES. Microsoft es explícito en que cambiar la contraseña de la cuenta genera esas claves.
Esto importa porque muchas cuentas de servicio legacy son lo bastante antiguas como para arrastrar exactamente ese problema.
4. Eliminar la dependencia restante de RC4
Esto ya no es opcional por parte de Microsoft: desde las actualizaciones de julio de 2026, el KDC asume solo AES-SHA1 cuando no hay configurado ningún tipo de cifrado explícito, y la subclave de registro para la reversión temporal ha desaparecido. La guía de RC4 de Microsoft ofrece los pasos de auditoría y remediación para encontrar cuentas que aún lo usan, incluidos los scripts List-AccountKeys.ps1 y Get-KerbEncryptionUsage.ps1 y los eventos 4768 y 4769. Eso no hace imposible Silver Ticket por sí solo, pero elimina una debilidad legacy más del manejo Kerberos de las cuentas de servicio y mejora la baseline Kerberos general. También se combina directamente con AS-REP Roasting: Recopilando Hashes Sin Credenciales y otro trabajo de hardening Kerberos.
5. Minimizar el privilegio y el alcance de las cuentas de servicio
Un ticket forjado es solo tan útil como la cuenta de servicio que hay detrás. Incluso si la cuenta de servicio tiene que existir, no debería llevar además derechos de administrador local innecesarios, pertenencia a grupos privilegiados o acceso amplio a sistemas no relacionados.
6. Inventariar SPN y la propiedad de las cuentas de servicio
No puedes defender secretos de cuentas de servicio que no entiendes. Un programa de hardening real debería saber:
- qué SPN se corresponden con qué cuentas
- qué hosts se espera que usen esas cuentas
- quién es el responsable operativo de cada cuenta de servicio
- si la cuenta puede migrarse a gMSA
- si la cuenta todavía depende de RC4 o de configuraciones legacy
Por eso Auditar la seguridad de Active Directory: checklist práctica pertenece junto a este tema. Si estás escalando esa revisión por todo el estado, Comparativa de herramientas de auditoría AD también es relevante.
7. Tratar el credential dumping y Kerberoasting como precursores directos de Silver Ticket
Si un atacante puede dumpear un secreto de cuenta de servicio o crackearlo offline, el camino de Silver Ticket queda abierto. Por eso este artículo debería leerse junto con 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 de Silver Ticket porque hayas cambiado una contraseña una vez. Valida el modelo de cuentas de servicio directamente.
- confirmar qué service principals todavía usan cuentas de usuario tradicionales en lugar de gMSA
- confirmar si cada cuenta de servicio tiene claves AES y si RC4 sigue en uso
- verificar
msDS-SupportedEncryptionTypesdonde sea relevante y compararlo con el uso Kerberos real observado en los controladores de dominio - revisar los datos del evento
4769en los KDC para entender qué cuentas de servicio siguen solicitando tickets de servicio y qué tipos de cifrado usan - verificar que los servicios sensibles no dependan de identidades de servicio obsoletas, compartidas o no documentadas
- confirmar que las cuentas de servicio no tienen privilegios más amplios de los que el servicio realmente necesita
El verdadero criterio de éxito no es solo una mejor política Kerberos. Es que comprometer una cuenta de servicio ya no entregue un secreto estable y reutilizable con un valor operativo amplio.
Cómo EtcSec detecta la exposición relacionada
No existe un tipo de vulnerabilidad exacto para Silver Ticket en el catálogo actual, así que los hallazgos más útiles son los prerrequisitos y las debilidades Kerberos circundantes que hacen práctica la técnica.
Los hallazgos más relevantes son:
KERBEROASTING_RISK, porque la recuperación offline de un secreto de cuenta de servicio es uno de los precursores más claros de Silver TicketKERBEROS_RC4_FALLBACK, porque la postura de cifrado Kerberos legacy suele solaparse con la misma población de cuentas de servicio mal gestionadas- cuentas de servicio privilegiadas o con alcance excesivo que hacen mucho más dañino un ticket de servicio forjado
- condiciones de attack path circundantes ya capturadas en Rutas de ataque AD: como se encadenan hasta Domain Admin
Ese es el modelo mental correcto: Silver Ticket es una técnica de ticket forjado, pero su superficie real de corrección es la higiene de cuentas de servicio.
Controles relacionados
Si estás revisando el riesgo de 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.
Referencias principales
- MITRE ATT&CK: Silver Ticket (T1558.002)
- MITRE ATT&CK: Detect Forged Kerberos Silver Tickets (DET0241)
- Microsoft Learn: Kerberos PAC Validation
- Microsoft Learn: Group Managed Service Accounts overview
- Microsoft Learn: Detect and remediate RC4 usage in Kerberos
- Microsoft Support KB5073381: Kerberos KDC usage of RC4 for service account ticket issuance (CVE-2026-20833)
Explore las páginas de identidad que apoyan este tema