Silver Ticket

Un Silver Ticket es un TGS forjado para un servicio concreto. En Kerberos, el DC entrega al cliente un ticket de servicio (TGS) cifrado con el hash de la cuenta que ejecuta ese servicio; el servicio lo descifra con su propia clave y confía en lo que contiene (incluido el PAC con los grupos del usuario). Si conocemos el hash de la cuenta de servicio, podemos construir nosotros mismos un TGS válido, sin pasar por el DC, presentándonos como cualquier usuario (típicamente Administrator).

A diferencia del Golden Ticket (que falsifica TGT con el hash de krbtgt y vale para todo el dominio), el Silver Ticket solo sirve para ese servicio en ese host, pero es más sigiloso: no hay tráfico con el KDC.

Hacen falta tres datos: el hash NT de la cuenta de servicio (de un Kerberoasting o un volcado), el SID del dominio y el SPN objetivo (CIFS, HOST, MSSQL, HTTP...):

ticketer.py -nthash <hash_NT> \
  -domain-sid <domain-SID> \
  -domain <domain> \
  -spn MSSQL/host.dominio Administrator
export KRB5CCNAME=Administrator.ccache
impacket-mssqlclient -k host.dominio
# con clave AES (mas sigiloso) y otros SPN de servicio
ticketer.py -aesKey <aes-key> -domain-sid <domain-SID> -domain <domain> -spn cifs/host.dominio Administrator
# en Windows con mimikatz
kerberos::golden /user:Administrator /domain:<domain> /sid:<domain-SID> /target:host.dominio /service:cifs /rc4:<hash_NT> /ptt

El ticket se guarda en un .ccache; al exportarlo en KRB5CCNAME, las herramientas de impacket lo usan para autenticarse por Kerberos contra el servicio. Si el SPN es de MSSQL, abre la puerta a xp_cmdshell; si es CIFS, a leer recursos compartidos, etc.

Matiz. El PAC del ticket forjado no está firmado por el KDC; con la validación de PAC (PAC validation) activa en el servicio, un Silver Ticket puede ser rechazado. En muchos entornos no se aplica, de ahí que la técnica siga funcionando. El reloj debe estar sincronizado y el SPN debe coincidir exactamente con el registrado.

Cómo detectarlo. Es sigiloso precisamente porque no hay tráfico con el KDC: no verás el 4768/4769 que acompaña a un login Kerberos normal. La detección se hace del lado del servicio, no del DC. La señal clásica es un Event ID 4624 (inicio de sesión) en el host destino sin el 4769 correspondiente en el DC en esa ventana: acceso Kerberos que nadie pidió al KDC. Ayuda también un desajuste en el PAC (nombre o RID que no cuadra con la cuenta real) si se recogen los logs de validación, y valores de ticket anómalos (lifetime por defecto de 10 años que ponen algunas herramientas). Correlacionar logons de servicio con las peticiones TGS del DC es lo que delata el ticket forjado.

Defensa. Rotar periódicamente las contraseñas de las cuentas de servicio (invalida los tickets forjados), preferir gMSA, y habilitar la validación de PAC. Relacionado con la Pass-the-Hash y el Kerberoasting.