Silver Ticket

A Silver Ticket is a forged TGS for a specific service. In Kerberos, the DC hands the client a service ticket (TGS) encrypted with the hash of the account running that service; the service decrypts it with its own key and trusts what it contains (including the PAC with the user's groups). If we know the service account's hash, we can build a valid TGS ourselves, without going through the DC, presenting as any user (typically Administrator).

Unlike the Golden Ticket (which forges a TGT with krbtgt's hash and works domain-wide), a Silver Ticket only works for that service on that host, but it's stealthier: there's no traffic with the KDC.

Three things are needed: the service account's NT hash (from Kerberoasting or a dump), the domain SID and the target SPN (CIFS, HOST, MSSQL, HTTP...):

ticketer.py -nthash <NT_hash> \
  -domain-sid <domain-SID> \
  -domain <domain> \
  -spn MSSQL/host.domain Administrator
export KRB5CCNAME=Administrator.ccache
impacket-mssqlclient -k host.domain
# with an AES key (stealthier) and other service SPNs
ticketer.py -aesKey <aes-key> -domain-sid <domain-SID> -domain <domain> -spn cifs/host.domain Administrator
# on Windows with mimikatz
kerberos::golden /user:Administrator /domain:<domain> /sid:<domain-SID> /target:host.domain /service:cifs /rc4:<NT_hash> /ptt

The ticket is saved to a .ccache; exporting it in KRB5CCNAME lets impacket tools authenticate over Kerberos against the service. If the SPN is MSSQL, it opens the door to xp_cmdshell; if it's CIFS, to reading shares, and so on.

Nuance. The forged ticket's PAC isn't signed by the KDC; with PAC validation enabled on the service, a Silver Ticket can be rejected. Many environments don't enforce it, which is why the technique still works. The clock must be in sync and the SPN must exactly match the registered one.

How to detect it. It is stealthy precisely because there is no traffic with the KDC: you won't see the 4768/4769 that accompanies a normal Kerberos login. Detection happens on the service side, not the DC. The classic signal is an Event ID 4624 (logon) on the target host without a matching 4769 on the DC in that window: Kerberos access that nobody requested from the KDC. A PAC mismatch also helps (a name or RID that doesn't match the real account) if validation logs are collected, along with anomalous ticket values (the default 10-year lifetime some tools set). Correlating service logons with the DC's TGS requests is what betrays the forged ticket.

Defence. Rotate service account passwords regularly (invalidates forged tickets), prefer gMSA, and enable PAC validation. Related to Pass-the-Hash and Kerberoasting.