Golden Ticket Attack vs Silver Ticket: What Each Proves and How to Detect It

A golden ticket attack is the forgery of a Kerberos ticket-granting ticket (TGT) with the key of the domain’s krbtgt account, which lets an attacker pose as any user, with any group memberships, to any service in the domain for as long as that key stays valid. A silver ticket is the narrower version: a forged service ticket built with one service or computer account’s key, good only for that account’s services, and never shown to a domain controller. Neither is a way in: both need a key the attacker should never hold, either the krbtgt key (which takes control of the domain’s most privileged systems) or a service account’s key (often a cracked weak password). Finding one changes the question from “which setting is wrong?” to “how did they get the key, and do they still have it?”

Whether one ordinary account could reach those keys in your domain is what our Active Directory security assessment answers, from $6,000 for one domain, with multiple domains or forests quoted from your scope; the internal network penetration testing cost page shows how price scales with domains and hosts.

Golden ticket vs silver ticket at a glance

	Golden ticket	Silver ticket
MITRE ATT&CK	T1558.001	T1558.002
What is forged	A TGT	A service ticket (file share, SQL Server, web app, remote management)
Key required	krbtgt, which domain controllers use to encrypt and sign TGTs	The account that runs the target service
Reach	Every service in the domain, as anyone; from a child domain, the rest of the forest through SID history	That account’s services, as anyone
Contacts a domain controller	Yes, whenever it is exchanged for a service ticket	No
Where it shows up	Domain controller Kerberos events, identity sensors	Only on the target server
What invalidates it	Resetting krbtgt twice	Changing that account’s password (twice for a computer account, which keeps its previous one)
What its use proves	Tier 0 was already compromised	That one key was exposed

How Kerberos makes forgery possible

A user proves knowledge of their password to a domain controller and receives a TGT, encrypted with the krbtgt key. The client presents the TGT to request a service ticket, which the domain controller encrypts with the key of the account running the service. Inside both sits the Privilege Attribute Certificate (PAC): the user’s identity and group memberships, which the receiving system turns into an access token.

The design trusts possession of a key. A domain controller accepts a TGT it can decrypt and verify with the krbtgt key, and a service accepts a ticket it can decrypt with its own. The PAC carries a server signature made with the service’s key and KDC signatures made with the krbtgt key, and only a domain controller can check the KDC ones. Microsoft’s explanation of Kerberos PAC validation states that services running as part of Windows, the SMB file service among them, skip that check and verify only the signature made with their own key. Whoever holds the right key writes the PAC, and the PAC is where the groups live.

The golden ticket attack

A Kerberos golden ticket is a TGT the attacker wrote rather than one a domain controller issued. With the krbtgt key, the forger picks the user name, the groups (Domain Admins, Enterprise Admins) and the lifetime, and every domain controller treats the result as genuine.

The krbtgt key lives only on domain controllers, so taking it requires Tier 0 access (domain controllers and the accounts, backups and systems that control them): pulling password data through directory replication rights (DCSync, ATT&CK T1003.006), copying the directory database (NTDS.dit) from a domain controller, a backup or a virtual machine snapshot, or running code on a domain controller. Coerced authentication is one documented route to that access; our explainer covers NTLM relay against a domain controller and how to close it.

The danger is persistence. Resetting administrator passwords, disabling the accounts the attacker used or rebuilding the laptop they came in on does not touch a forged TGT. Only changing the krbtgt key does. Each domain has its own krbtgt account, and each read-only domain controller has a separate one named krbtgt_ plus a number.

What the 2021 to 2023 hardening changed

The November 2021 updates for CVE-2021-42287 (KB5008380), enforced from October 11, 2022, record the requesting account inside every TGT, so on patched domain controllers a forged TGT must name a real account with its real SID and tickets for made-up user names fail. The KB5020805 updates for CVE-2022-37967 added PAC signatures, and since October 10, 2023, service tickets lacking them are denied. These closed bugs that let an ordinary account obtain a ticket meant for another account or alter PAC signatures without the krbtgt key. Neither stops a golden ticket, because the krbtgt key produces every signature a real domain controller does.

The silver ticket attack

A silver ticket skips the domain controller entirely. The attacker builds the service ticket with the target account’s key and hands it straight to the server, which decrypts it and logs the user on.

The key usually comes from a service account password cracked offline after Kerberoasting, from the machine account secret of a server where the attacker already has local administrator rights, or from credentials in that server’s memory. With it, the attacker reaches the share, database or management endpoint as any user they name, including a domain administrator who has never logged on there.

A silver ticket lives as long as its key. Domain members change their machine account password every 30 days by default, unless someone disabled it. A service account whose password never changes gives a silver ticket no expiry date.

Diamond and sapphire tickets

Better golden ticket detection pushed attackers to two variants, both still needing the krbtgt key. A diamond ticket is a real TGT a domain controller issued, with its PAC decrypted, altered and re-encrypted. A sapphire ticket swaps in the genuine PAC of a privileged user, obtained through a delegation request (S4U2self combined with user-to-user). Unit 42 documented both in December 2022: a domain controller really did issue the TGT, so the classic missing-request rule finds nothing. Detection moves to the theft of the key, to sessions whose groups do not match the directory (diamond), and to unusual S4U2self plus user-to-user requests (sapphire).

Mimikatz, Rubeus and Impacket are the tool names usually seen beside these findings, with NetExec earlier in the credential extraction that leads to the key, but the key matters more than the tool.

Golden ticket vs pass-the-ticket

Pass-the-ticket (ATT&CK T1550.003) is a different technique that often gets filed under the same name. It reuses a genuine ticket stolen from a logged-on session, so it needs no key, forges nothing, and stops working when that ticket expires. A golden or silver ticket is written by the attacker and lasts as long as the key does. The response differs to match: a passed ticket points to one compromised host and session, while a forged one points to a stolen key.

What a forged ticket in your environment means

• A golden or diamond ticket: someone held the krbtgt key. Treat the whole forest as compromised (a child domain’s krbtgt key can forge Enterprise Admins membership in the forest root), and find the route the key left by: replication rights on accounts that are not domain controllers, administrators logging on to ordinary servers, readable domain controller backups.
• A silver ticket: one service key was exposed through a crackable service-account password, RC4 still accepted, or local administrator rights spread too widely.

In a penetration test report, either one is the end of a chain, and the fixes belong on the steps that reached the key, which are usually privilege escalation steps from an ordinary account. Recovering from a real golden ticket is incident response work, which Invadel does not provide; bring in an incident response firm.

Golden ticket detection: log sources and event IDs

Enable “Audit Kerberos Authentication Service” and “Audit Kerberos Service Ticket Operations” on every domain controller and forward the logs. Event 4768 records each TGT a domain controller issues and event 4769 each service ticket request; both are written only on domain controllers. Most golden ticket detection compares the two.

Signal	Log source and event	What it means	Catches
Service ticket with no TGT behind it	DC Security log: 4769 with no 4768 or 4770 (renewal) for that account within the maximum renewal window	The TGT was never issued by a domain controller	Golden
Ticket hash with no issuer	4769 “Request ticket hash” vs 4768 “Response ticket hash” (Server 2016+ DCs, January 14, 2025 update or later)	Microsoft’s sample events show the same hash in both; a 4769 request hash that matches no 4768 response hash, outside TGT renewals (4770), is a strong lead	Golden
Ticket used beyond policy	Identity sensor alert “Suspected Golden Ticket usage (time anomaly)”	The forger set the lifetime; the domain default is 10 hours	Golden
RC4 TGT where the domain uses AES	Identity sensor alert “Suspected Golden Ticket usage (encryption downgrade)”, which inspects the TGT itself; 4769 logs only the issued ticket’s encryption, where 0x17 more often means Kerberoasting or a legacy RC4 account	Forged with the RC4 form of the krbtgt key	Golden (RC4 key only)
Logon with no ticket issued	Member server Security log: 4624 logon type 3 over Kerberos with no matching 4769 on any DC	The ticket never came from a domain controller	Silver
Groups the directory does not show	4627 group membership, logged with 4624 (needs Audit Group Membership)	The PAC claims memberships the account lacks	Golden, silver, diamond
PAC check failures	DC System log, KDC events 37, 38 (KB5008380), 43, 44 (KB5020805)	Missing or inconsistent requestor data or signatures	Crude forgeries (also fires on tickets from DCs missing the 2021 and 2022 updates)
Replication from a non-DC	DC Security log 4662 naming replication rights; “Suspected DCSync attack”	The step that steals the krbtgt key	Precursor

The Microsoft Defender for Identity classic alert list has golden ticket alerts for time anomaly (ID 2022), encryption downgrade (2009), nonexistent account (2027), ticket anomaly (2032 and 2040) and forged authorization data (2013), plus DCSync (2006). Three practical notes:

• Correlation needs every domain controller. A TGT issued by one DC is often used at another, and renewals log 4770, not 4768, so the rule needs centralized logs from all DCs, must treat a 4770 as a valid origin, and needs a lookback as long as the maximum lifetime for user ticket renewal (7 days by default), not the 10-hour ticket lifetime. Match on account first; client address is secondary.
• Tripwires are not coverage. A forger using the AES key and a realistic lifetime defeats the RC4 and time rules. Keep them, but do not count them as golden ticket detection.
• Silver tickets live on the servers. Forward Security logs from file, database, backup and management servers. Microsoft documents the 4769 Logon GUID for correlating with 4624 on the target computer, which turns “logon with no ticket” into a join.

Sample detection query: service tickets with no TGT

The first row of the table, written as logic you can port to your SIEM’s query language. Field names are the ones in Microsoft’s event documentation linked above.

// Input: Security logs from every domain controller
tgt_seen = events where EventID in (4768, 4770)
           over the last 7 days
           -> account = lowercase(TargetUserName, text before "@")

alert    = events where EventID == 4769 and Status == "0x0"
           over the last 1 hour
           -> account = lowercase(TargetUserName, text before "@")
           -> keep rows whose account is not in tgt_seen
           -> group by account, IpAddress, ServiceName

Two details decide whether it works. Event 4769 records the account as user@REALM while 4768 records the bare user name, so normalize both before the join. And an account from a trusted domain gets its TGT from that domain’s controllers, so either collect from every domain or filter on TargetDomainName, or cross-domain logons will raise false alerts.

How to prevent golden and silver tickets

Neither can be patched away, because both use Kerberos as designed. Prevention means keeping keys out of reach and shortening how long a stolen key works.

Control	Stops or limits	How to verify
Domain Admins log on only to DCs and Tier 0 systems	Golden: the easy route to replication rights	Tier 0 logons on lower-tier hosts
Replication rights held only by domain controllers	Golden: DCSync	Rights on the domain object
DC backups, snapshots and hypervisors treated as Tier 0	Golden: offline theft of NTDS.dit	Who can read backups and virtualization consoles
krbtgt reset twice, 10+ hours apart, on a schedule and after any exposure	Golden: every existing forged TGT	krbtgt password-last-set date
Service accounts on gMSA, or 25+ character random passwords with AES only	Silver: nothing crackable to roast	SPN accounts, password age, encryption types
Machine account password changes left on	Silver: life of a machine-key forgery	“Disable machine account password changes” not enabled
Unique local admin passwords, narrow server admin rights	Silver: who can pull a server’s key	Local Administrators on high-value servers

Microsoft’s krbtgt procedure is to reset twice and wait at least the maximum ticket lifetime (10 hours by default) between resets, because the account keeps its two most recent passwords. MITRE suggests rotating it about every 180 days. Our Active Directory hardening checklist covers replication rights, AES for service accounts and the krbtgt schedule as checks 9, 12 and 14.

How Invadel tests for it, and what it costs

Testing for forged tickets is mostly about proving whether the keys are reachable. Our Active Directory security assessment starts from one standard domain user and maps every path toward the krbtgt key and high-value service keys: Kerberoastable accounts, delegation, dangerous ACLs, certificate services (the AD CS attack paths), privileged sessions and replication rights. Paths are mapped with tools like BloodHound and proven by hand, and the report shows each step, its fix and which step to cut first.

Written rules of engagement apply: no changes to domain controllers, and forged tickets only if you put them in scope, in which case your team sees whether the detections above fire.

Engagement	Published starting price	Best for
Active Directory security assessment	$6,000 for one domain; multiple domains or forests quoted	Paths to krbtgt and service keys, in depth
Internal network penetration test	$6,000 Small, $9,200 Medium, $14,500+ Large	The domain plus hosts, services and segmentation
Red team	$12,500	Whether your team detects and stops the whole chain
Purple team	Quoted	Tuning forged-ticket detections with your defenders

Every penetration test includes a free retest of remediated findings, executive and technical reports and an attestation letter, at a price fixed in writing from your scope details with no sales call. See a sample penetration testing report or the full pricing page.

Frequently asked questions

What is a golden ticket attack? It is the forgery of a Kerberos ticket-granting ticket with the domain’s krbtgt key, letting an attacker impersonate any user with any group memberships across the domain until krbtgt is reset twice.

What is the difference between a golden ticket and a silver ticket? A golden ticket is a forged TGT that works against every service in the domain. A silver ticket is a forged service ticket that works only for one account’s services and never touches a domain controller.

Does resetting the krbtgt password stop a golden ticket? Yes, if you reset it twice with at least the maximum ticket lifetime (10 hours by default) between resets. Remove the attacker’s access first, or they can take the new key the same way.

Should the krbtgt account be disabled? Yes. It is disabled by default and should stay that way, but being disabled does not stop domain controllers using its key to sign every TGT, so the fix is resetting its password.

Can a silver ticket be detected on a domain controller? Not directly, because it is never presented to one. Look on the target server for Kerberos network logons (4624) with no matching service ticket request (4769) on any domain controller.

Does Microsoft Defender for Identity detect golden tickets? Its classic alert list includes several golden ticket detections, covering time anomalies, encryption downgrades, nonexistent accounts and ticket anomalies. Silver tickets bypass domain controllers, so plan to catch them in server logs.

How long does a golden ticket last? As long as the krbtgt key it was made with. The forger writes the lifetime into the ticket, so the domain’s 10-hour default does not limit it; resetting krbtgt twice is what ends it.

Is a golden ticket the same as pass-the-ticket? No. Pass-the-ticket reuses a real ticket stolen from a session and expires with it. A golden ticket is forged with the krbtgt key and needs no stolen ticket at all.

The short version

A golden ticket is a forged TGT made with the krbtgt key and means Tier 0 was already lost; a silver ticket is a forged service ticket made with one account’s key and means that key was exposed. Detect them by matching 4769 against 4768 and 4770 on every domain controller and server 4624 logons against 4769; prevent them by guarding Tier 0, rotating krbtgt twice and moving service accounts to managed passwords. To learn whether one ordinary account could reach those keys, see our Active Directory security assessment, the internal network testing prices, or scope your test.