Silver Ticket

Also calledforged service ticket

Forges a service ticket with the service's own key, so no DC ever issues it.

Technique: MITRE ATT&CK T1558.002: Steal or Forge Kerberos Tickets: Silver Ticket (opens in a new tab)
Hooks Into: Kerberos TGS Reply Kerberos AP Request
Needs: Service Key
Gives: Account AccessandLocal Admin

How the Attack Works

A service ticket is sealed with the key of the account that runs the service, and the service checks that it opens with that key and that the PAC's server signature, made with the same key, is right. Whoever holds the key can therefore make a ticket naming any user with any groups, and no DC takes part. The PAC's other signatures need the krbtgt key, which the forger lacks, but only a DC can check them. Services running as SYSTEM, the file server among them, do not ask one to (PAC validation).

Read first Password Hashes and Kerberos Keys, TGS Reply: The Service Ticket, AP Exchange: Using the Ticket, The PAC and Its Signatures, Where Sign-In Evidence Lands

How It Plays Out

The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.

With srv-fin-01's key, taken earlier, a foothold on ws-017, dana's workstation, makes its own ticket to the file server and never asks a DC.Step through it

ws-017 Foothold

srv-fin-01 key

srv-fin-01 File server

srv-fin-01 key

Step 1 of 3, Ticket Forged, on ws-017
Step 2 of 3, Forged AP Request, ws-017 to srv-fin-01
Step 3 of 3, Share Opened, srv-fin-01 to ws-017

Step 1 of 3: Ticket Forged
On ws-017 Foothold
A service ticket to srv-fin-01 is made with its key. It names adm-alice with any groups, and its server signature checks out.
Keys and Tickets
- ws-017 now holds service ticket (new at this step) service session key (new at this step)
What Defenders See
Nothing shows anywhere. No message leaves ws-017, so no DC writes an event 4769 to its Security log.
Hooks into Kerberos TGS Reply
Step 2 of 3: Forged AP Request
ws-017 Foothold to srv-fin-01 File server
Forged ticket shown to the server KRB_AP_REQ SMB, port 445
The forged ticket goes straight to srv-fin-01 inside the SMB session setup, with a fresh authenticator.
What Travels in This Step
- The forged service ticket ticket
  adm-alice's name and the chosen groups in a PAC, with a server signature made with srv-fin-01's key
  Encrypted with srv-fin-01's key Only ws-017 and srv-fin-01 can open it.
- An authenticator authenticator
  The name and the time
  Encrypted with the service session key Only ws-017 and srv-fin-01 can open it.
Keys
- srv-fin-01 now holds service session key (new at this step)
Logged
- 4624 An account was successfully logged on
  On srv-fin-01, in the Security log
  A Kerberos network logon for adm-alice from 192.0.2.17, with no 4769 behind its Logon GUID.
  Reading Logon Events explains how to read it.
- 4672 Special privileges assigned to new logon
  On srv-fin-01, in the Security log
  Admin privileges in the new logon, from groups the forged PAC claims.
  Reading Logon Events explains how to read it.
- 4627 Group membership information
  On srv-fin-01, in the Security log When enabled
  The groups from the forged PAC, whatever the directory says.
What Defenders See
The Security log on srv-fin-01 shows event 4624 whose Logon GUID matches no event 4769 on any DC. It also shows event 4672 if the PAC claims admin groups, and event 4627 listing groups she does not hold.
Hooks into Kerberos AP Request
Step 3 of 3: Share Opened
srv-fin-01 File server to ws-017 Foothold
The server's proof of identity KRB_AP_REP SMB, port 445
srv-fin-01 answers as the real server, and the share opens on a token built from the forged PAC with no DC asked to check it.
Logged
- 5140 A network share object was accessed
  On srv-fin-01, in the Security log When enabled
  The share opened as adm-alice from 192.0.2.17.
What Defenders See
Where file share auditing is on, the Security log on srv-fin-01 shows event 5140 for the share. No DC logs anything.

Needs First

What the attacker must already hold for this attack to be possible.

A Service's KeyThe key of the account that runs the service (its NT hash or AES key), or its password.

Comes From

Service Key: Kerberoasting, SAM, LSA Secrets and Cached Logons, NTDS.dit Theft, DCSync every attack that gives it: A Service's Key

Gives the Attacker

What running it hands the attacker to use next.

Access as Another AccountThat one service, reached as any user with any groups.
Local Admin RightsAdmin rights on that server, where the ticket names an admin or claims admin groups.

Leads To

Local Admin: LSASS Memory Theft, SAM, LSA Secrets and Cached Logons, Clearing and Silencing Logs

What Defenders See

What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.

Event and Log	Written On	Look For	Switch It On
4624 `An account was successfully logged on` (opens in a new tab) Security log	The computer that was logged on to	A Kerberos network logon whose Logon GUID matches no 4769 on any DC, so no DC issued its ticket.Reading Logon Events explains how to read it.	Audit Logon
4769 `A Kerberos service ticket was requested` (opens in a new tab) Security log	Domain controllers	The request that should sit behind each Kerberos logon within the ticket lifetime. Collect it from every DC.TGS Reply: The Service Ticket explains how to read it.	Audit Kerberos Service Ticket Operations
4627 `Group membership information` (opens in a new tab) Security log	The computer that was logged on to, beside its 4624	Groups in the logon that the account does not hold in the directory, written into a forged PAC.	Audit Group Membership, with Audit Logon success on as well
4672 `Special privileges assigned to new logon` (opens in a new tab) Security log	The computer that was logged on to	Admin privileges in a logon whose ticket no DC issued.Reading Logon Events explains how to read it.	Audit Special Logon

What It Looks Like

One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.

4624 An account was successfully logged on

In the Security log on srv-fin-01, 22 Oct 2026, 03:41:07 UTC

A Kerberos logon on srv-fin-01 that no DC ever issued a ticket for.

A network logon, here to a share on srv-fin-01. One of your DCs should hold the 4769 for its ticket.
As Windows writes it: Logon Type 3
The name the ticket claims. A forged ticket can name anyone, so the name alone proves nothing.
As Windows writes it: Account Name adm-alice
Kerberos, so a DC should have issued the ticket. Find that request by its Logon GUID.
As Windows writes it: Authentication Package Kerberos
The join key to the DC side. No 4769 on any DC carries it, so no DC issued this ticket.
As Windows writes it: Logon GUID {6f1c2a9e-3b7d-4e05-9a41-2c8d7b5e0f13}
ws-017, where the ticket was presented from. Collect it, then trace how srv-fin-01's key was taken.
As Windows writes it: Source Network Address 192.0.2.17

Defender for Identity Alerts

Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.

Suspicious Kerberos authentication (AP-REQ) (opens in a new tab)Only where the forged ticket goes to a server with a Defender for Identity sensor, a DC above all, since the sensors read no other AP requests.

Blind Spots

Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.

A file server's logon events hold no ticket encryption type, it asks no DC to check the PAC, and no DC ever sees the ticket.
The Logon GUID join needs every DC's 4769s for the whole ticket lifetime. One DC missing from collection makes its genuine tickets look forged.

Hunt It

The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.

Sees It DirectlyAlertEvidence (Defender for Identity alerts)

Needs a Defender for Identity sensor on the server the forged ticket goes to, which means DCs and a few other server roles, not a member server such as srv-fin-01. An alert marks a suspect AP request. It does not show how the service's key was taken.

KQLDefender XDR, Advanced hunting

// Defender for Identity alerts for forged service tickets to servers its sensors watchAlertEvidence| where Timestamp > ago(30d)| where Title == "Suspicious Kerberos authentication (AP-REQ)"| summarize FirstSeen = min(Timestamp), Accounts = make_set_if(AccountName, isnotempty(AccountName)), Devices = make_set_if(DeviceName, isnotempty(DeviceName)), Addresses = make_set_if(RemoteIP, isnotempty(RemoteIP)) by AlertId, Title| order by FirstSeen desc

How to Prevent It

The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.

Group managed service accounts (opens in a new tab)
Run services as group managed service accounts, so their keys are long, random and changed by Windows.
Least-privilege administration (opens in a new tab)
Keep local admin rights on servers few, since a local admin can read the server's own computer account key.
Windows LAPS (opens in a new tab)
Give each machine's local administrator its own password, so one stolen hash does not open every server.

How the Attack Works

How It Plays Out

Step 1 of 3: Ticket Forged

Step 2 of 3: Forged AP Request

Step 3 of 3: Share Opened