Golden Ticket

Also calledforged TGT, krbtgt

Forges a TGT with the krbtgt key, for any account and groups, that every DC accepts.

Technique: MITRE ATT&CK T1558.001: Steal or Forge Kerberos Tickets: Golden Ticket (opens in a new tab)
Hooks Into: Kerberos AS Reply Kerberos TGS Request
Needs: krbtgt Key
Gives: TGTandDomain Admin

How the Attack Works

Every TGT is sealed, and its PAC signed, with the krbtgt key, and a DC checks no list of the TGTs it has issued. Any TGT that opens with the key and whose signatures check out is believed. Whoever holds the key can therefore make a TGT for any account, with any groups and any lifetime, with no AS exchange at all. A DC then issues genuine service tickets from it, copying the forged PAC into each.

Read first Authentication and Authorisation, Password Hashes and Kerberos Keys, AS Reply: The TGT, TGS Request, 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 the krbtgt key, taken earlier, a foothold on ws-017, dana's workstation, makes a TGT for adm-alice that claims Domain Admins, then uses it.Step through it

ws-017 Foothold

krbtgt key

dc-01 Domain controller

krbtgt key
srv-fin-01 key

srv-fin-01 File server

srv-fin-01 key

Step 1 of 4, TGT Forged, on ws-017
Step 2 of 4, TGS Request, ws-017 to dc-01
Step 3 of 4, Service Ticket, dc-01 to ws-017
Step 4 of 4, AP Request, ws-017 to srv-fin-01

Step 1 of 4: TGT Forged
On ws-017 Foothold
A TGT for adm-alice is made with the krbtgt key, its PAC claiming Domain Admins and its lifetime whatever its maker chose.
Keys and Tickets
- ws-017 now holds TGT (new at this step) TGT session key (new at this step)
What Defenders See
Nothing shows anywhere. No AS exchange takes place, so no DC writes an event 4768 to its Security log.
Hooks into Kerberos AS Reply
Step 2 of 4: TGS Request
ws-017 Foothold to dc-01 Domain controller
Request made with the forged TGT KRB_TGS_REQ Kerberos, port 88
The forged TGT goes to dc-01 with an authenticator and a request for a ticket to cifs/srv-fin-01.corp.example.
What Travels in This Step
- The forged TGT ticket
  adm-alice's name, a PAC claiming Domain Admins, its session key and its times
  Encrypted with the krbtgt key Only ws-017 and dc-01 can open it.
- An authenticator authenticator
  Her name and the time
  Encrypted with the TGT session key Only ws-017 and dc-01 can open it.
- The service wanted sname
  cifs/srv-fin-01.corp.example
  In the clear Anyone who sees the traffic can read it.
Logged
- 4769 A Kerberos service ticket was requested
  On dc-01, in the Security log
  A ticket request for adm-alice from 192.0.2.17, with no TGT issue behind it on any DC.
  TGS Reply: The Service Ticket explains how to read it.
What Defenders See
The Security log on dc-01 shows event 4769 for adm-alice, and no DC logged an event 4768 for her within the ticket lifetime. Defender for Identity also raises its golden ticket alerts.
Hooks into Kerberos TGS Request
Step 3 of 4: Service Ticket
dc-01 Domain controller to ws-017 Foothold
Reply with a real service ticket KRB_TGS_REP Kerberos, port 88
dc-01 opens the TGT with the krbtgt key, trusts its PAC and returns a genuine service ticket carrying the same claims.
What Travels in This Step
- The service ticket ticket
  adm-alice's name and a copy of the forged PAC, signed again by dc-01
  Encrypted with srv-fin-01's key Only dc-01 and srv-fin-01 can open it.
- The service session key
  For talking to srv-fin-01
  Encrypted with the TGT session key Only ws-017 and dc-01 can open it.
Keys and Tickets
- ws-017 now holds service ticket (new at this step) service session key (new at this step)
What Defenders See
Nothing new shows, as the event 4769 above in the Security log on dc-01 is the only record of this exchange.
Step 4 of 4: AP Request
ws-017 Foothold to srv-fin-01 File server
Service ticket shown to the server KRB_AP_REQ SMB, port 445
srv-fin-01 accepts the ticket as adm-alice with Domain Admins, exactly as it would a real one.
What Travels in This Step
- The service ticket ticket
  adm-alice's name and the forged groups
  Encrypted with srv-fin-01's key Only dc-01 and srv-fin-01 can open it.
- An authenticator authenticator
  Her 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.
  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 the forged Domain Admins claim.
  Reading Logon Events explains how to read it.
- 4627 Group membership information
  On srv-fin-01, in the Security log When enabled
  Domain Admins among her groups, which the directory does not give her.
What Defenders See
The Security log on srv-fin-01 shows events 4624 and 4672 for adm-alice, and event 4627 listing Domain Admins, which she does not hold.

Needs First

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

The krbtgt KeyThe krbtgt key, taken by DCSync, from a copy of NTDS.dit or with code on a DC.

Comes From

krbtgt Key: NTDS.dit Theft, DCSync

Gives the Attacker

What running it hands the attacker to use next.

A TGTA TGT for any account, with any groups and lifetime, accepted until krbtgt is reset twice.
Domain Admin RightsDomain Admin rights, where the TGT names an admin or claims the admin groups.

Leads To

TGT: Pass-the-Ticket
Domain Admin: LSASS Memory Theft, SAM, LSA Secrets and Cached Logons, NTDS.dit Theft, DCSync every attack that uses it: Domain Admin Rights

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
4769 `A Kerberos service ticket was requested` (opens in a new tab) Security log	Domain controllers	A request whose account has no 4768 on any DC within the ticket lifetime. On updated DCs, a Request ticket hash no 4768 returned.TGS Reply: The Service Ticket explains how to read it.	Audit Kerberos Service Ticket Operations
4768 `A Kerberos authentication ticket (TGT) was requested` (opens in a new tab) Security log	Domain controllers	The TGT issue that should come before each 4769 for the same account, on one DC or another. A forged TGT has none.AS Reply: The TGT explains how to read it.	Audit Kerberos Authentication Service
35 to 38 `PAC without attributes, Ticket without a PAC, Ticket without Requestor, Requestor Mismatch` (opens in a new tab) System log	Domain controllers	A TGT with no PAC requestor, or one whose requestor does not match the directory, refused by a DC since the 2022 enforcement.	Domain controllers with the November 2021 or later updates (KB5008380)
4627 `Group membership information` (opens in a new tab) Security log	The computer that was logged on to, beside its 4624	Groups at logon, such as Domain Admins, that the account does not hold in the directory.	Audit Group Membership, with Audit Logon success on as well
4624 `An account was successfully logged on` (opens in a new tab) Security log	The computer that was logged on to	Privileged logons on servers that follow a 4769 with no TGT issue behind it.Reading Logon Events explains how to read it.	Audit 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.

4769 A Kerberos service ticket was requested

In the Security log on dc-01, 23 Oct 2026, 02:14:09 UTC

A service ticket request on dc-01 with no TGT issue behind it on any DC.

The account the TGT names. No DC logged a 4768 for her in the ten hours before, from this address or any other.
As Windows writes it: Account Name adm-alice@CORP.EXAMPLE
The file server's computer account, whose key seals the ticket the DC now issues. Check the server for her logon next.
As Windows writes it: Service Name srv-fin-01$
ws-017, where the TGT was presented. Check every DC's 4768s before calling it forged, because one missing DC log looks the same.
As Windows writes it: Client Address ::ffff:192.0.2.17
AES for the service ticket, which the DC chose. It says nothing about how the TGT behind it was sealed.
As Windows writes it: Ticket Encryption Type 0x12
Issued, because the TGT opened with the krbtgt key, which is all the DC trusts. If no DC issued it, treat the key as stolen.
As Windows writes it: Failure Code 0x0

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.

Suspected Golden Ticket usage (time anomaly) (opens in a new tab)A TGT used beyond the domain's maximum lifetime for user tickets, which no Windows event records.
Suspected Golden Ticket usage (nonexistent account) (opens in a new tab)A TGT naming an account that does not exist. DCs with the 2022 enforcement refuse these as well.
Suspected Golden Ticket usage (ticket anomaly) (opens in a new tab)
Suspected Golden Ticket usage (encryption downgrade) (opens in a new tab)A TGT sealed with a weaker cipher than its source normally uses, with no AS exchange seen before it.
Possible golden ticket attack (opens in a new tab)
Possible golden ticket attack (suspicious ticket) (opens in a new tab)

Blind Spots

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

4769 records neither the TGT's lifetime nor its groups, so its own fields cannot tell a forged TGT from a real one. Join it to 4768, and read the groups in 4627.
The no-4768 check needs every DC's events for the whole ticket lifetime, and a TGT renewed for up to seven days has no fresh 4768 behind it either.

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 Defender for Identity sensors on every DC. The time anomaly alert sees a TGT used beyond the maximum lifetime for user tickets, which 4769 does not record. An alert is a lead to confirm in the 4768 and 4769 trail, not proof the krbtgt key was stolen.

KQLDefender XDR, Advanced hunting

// Defender for Identity golden ticket alerts, with the accounts, machines and addresses they nameAlertEvidence| where Timestamp > ago(30d)| where Title contains "golden ticket"| 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.

krbtgt password reset (opens in a new tab)
Reset the krbtgt password twice, waiting at least the maximum ticket lifetime between, after any DC compromise.
Hardened domain controllers (opens in a new tab)
Protect DCs, their backups and their virtual disks like the domain itself, because each holds the krbtgt key.
Replication rights reviewed (opens in a new tab)
Let only DCs replicate secrets, and the Entra Connect account only as far as it needs, so DCSync cannot hand out the key.
Least-privilege administration (opens in a new tab)
Keep Domain Admins nearly empty, so few accounts can reach the key at all.

How the Attack Works

How It Plays Out

Step 1 of 4: TGT Forged

Step 2 of 4: TGS Request

Step 3 of 4: Service Ticket

Step 4 of 4: AP Request