Diamond and Sapphire Tickets

Also calleddiamond ticket, sapphire ticket, krbtgt

Alters a real TGT with the krbtgt key, so a genuine sign-in sits behind the forgery.

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 KeyandDomain Account
Gives: TGTandDomain Admin

How the Attack Works

A diamond ticket starts from a genuine TGT that a DC issued after an ordinary sign-in. The krbtgt key opens it, its PAC is changed, and it is sealed and signed again. A sapphire ticket puts a privileged user's real PAC in its place, fetched from the DC with S4U2self and user-to-user, so the groups it claims match the directory. Either way a DC logged a real AS exchange, though for the account that signed in, which need not be the name the finished ticket carries.

Read first AS Reply: The TGT, The PAC and Its Signatures, Kerberos Delegation

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, a foothold on ws-017, dana's workstation, turns its own genuine TGT into one that claims Domain Admins (a diamond ticket).Step through it

ws-017 Foothold

krbtgt key

dc-01 Domain controller

krbtgt key
srv-fin-01 key

Step 1 of 5, AS Request, ws-017 to dc-01
Step 2 of 5, Genuine TGT, dc-01 to ws-017
Step 3 of 5, PAC Changed, on ws-017
Step 4 of 5, TGS Request, ws-017 to dc-01
Step 5 of 5, Service Ticket, dc-01 to ws-017

Step 1 of 5: AS Request
ws-017 Foothold to dc-01 Domain controller
Ordinary request for a TGT KRB_AS_REQ Kerberos, port 88
WS-017$ asks dc-01 for a TGT as usual, proving itself with its own computer account key.
What Defenders See
Nothing unusual shows, as dc-01 writes event 4768 to its Security log when it answers.
Step 2 of 5: Genuine TGT
dc-01 Domain controller to ws-017 Foothold
Reply with a real TGT KRB_AS_REP Kerberos, port 88
dc-01 returns a real TGT for WS-017$, its PAC holding the account's real groups.
What Travels in This Step
- The TGT ticket
  WS-017$'s name and real groups in a PAC signed with the krbtgt key
  Encrypted with the krbtgt key Only ws-017 and dc-01 can open it.
Keys and Tickets
- ws-017 now holds TGT (new at this step) TGT session key (new at this step)
Logged
- 4768 A Kerberos authentication ticket (TGT) was requested
  On dc-01, in the Security log
  A normal TGT issue for WS-017$ to 192.0.2.17.
  AS Reply: The TGT explains how to read it.
What Defenders See
The Security log on dc-01 shows an ordinary event 4768 for WS-017$, the record a golden ticket lacks.
Step 3 of 5: PAC Changed
On ws-017 Foothold
The TGT is opened with the krbtgt key, Domain Admins added to its PAC, then sealed and signed again with the same key.
What Defenders See
Nothing shows in any log, as this step happens on ws-017, away from every DC.
Hooks into Kerberos AS Reply
Step 4 of 5: TGS Request
ws-017 Foothold to dc-01 Domain controller
Request made with the altered TGT KRB_TGS_REQ Kerberos, port 88
The altered TGT goes to dc-01 with a request for a ticket to cifs/srv-fin-01.corp.example.
What Travels in This Step
- The altered TGT ticket
  WS-017$'s name with Domain Admins added to its PAC
  Encrypted with the krbtgt key Only ws-017 and dc-01 can open it.
- An authenticator authenticator
  The name and the time
  Encrypted with the TGT session key Only ws-017 and dc-01 can open it.
Logged
- 4769 A Kerberos service ticket was requested
  On dc-01, in the Security log
  A ticket request for WS-017$ with no groups to read. On updated DCs, its Request ticket hash matches no 4768.
  TGS Reply: The Service Ticket explains how to read it.
What Defenders See
The Security log on dc-01 shows event 4769 for WS-017$ with no groups. On updated DCs, the event also has a Request ticket hash that no event 4768 returned. Defender for Identity raises its diamond ticket alert too.
Hooks into Kerberos TGS Request
Step 5 of 5: Service Ticket
dc-01 Domain controller to ws-017 Foothold
Reply with a service ticket KRB_TGS_REP Kerberos, port 88
dc-01 issues a genuine service ticket, copying the altered PAC into it.
What Travels in This Step
- The service ticket ticket
  A copy of the altered PAC, signed again by dc-01
  Encrypted with srv-fin-01's key Only 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 shows on dc-01 at this step. When the ticket is used, srv-fin-01 writes event 4627 with Domain Admins to its Security log.

Needs First

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

The krbtgt KeyThe krbtgt key, to open the genuine TGT and seal it again.
A Domain AccountAny domain account, a computer account included, whose sign-in gets the genuine TGT.

Comes From

krbtgt Key: NTDS.dit Theft, DCSync
Domain Account: Password Spraying

Gives the Attacker

What running it hands the attacker to use next.

A TGTA TGT a DC really issued, now carrying the groups the holder chose.
Domain Admin RightsDomain Admin rights, from groups added to the PAC or a real admin's PAC put in its place.

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
4768 `A Kerberos authentication ticket (TGT) was requested` (opens in a new tab) Security log	Domain controllers	The genuine TGT issue behind the ticket, which matches the 4769 by account and address where the name is kept, but on updated DCs not by ticket hash.AS Reply: The TGT explains how to read it.	Audit Kerberos Authentication Service
4769 `A Kerberos service ticket was requested` (opens in a new tab) Security log	Domain controllers	No groups to read. On updated DCs, a Request ticket hash no 4768 returned. For a sapphire, an S4U2self request with user-to-user.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 at logon the account does not hold in the directory. A diamond adds them, while a sapphire copies a real admin's.	Audit Group Membership, with Audit Logon success on as well

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.

4627 Group membership information

In the Security log on srv-fin-01, 24 Oct 2026, 01:52:30 UTC

Group membership on srv-fin-01 for a computer account that claims Domain Admins.

A workstation's computer account logging on to the file server. That alone can be normal, but its groups are not.
As Windows writes it: Account Name WS-017$
A network logon with a service ticket from dc-01. Its 4624 holds the Logon GUID that leads back to that DC's 4769.
As Windows writes it: Logon Type 3
Domain Admins in a computer account's groups, which the directory does not give it. The PAC was changed, so treat the krbtgt key as stolen.
As Windows writes it: Group Membership CORP\Domain Computers, CORP\Domain Admins

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.

Kerberos privilege escalation using a diamond ticket (opens in a new tab)Flags a service ticket obtained with a TGT that looks modified, which 4769 alone cannot show.
Suspicious Kerberos ticket authorization data (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.

Where the ticket keeps the name that signed in, its real 4768 passes the account and address match that finds golden tickets, and 4769 records no groups to compare.
A sapphire ticket carries a real admin's PAC under that admin's name, so 4627 shows groups the directory agrees with. Look for its S4U2self request in 4769 instead.

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, which inspect the TGT each TGS request presents. An alert is a lead to confirm against the account's real groups, not proof the krbtgt key was stolen.

KQLDefender XDR, Advanced hunting

// Defender for Identity alerts for altered TGTs and their PACsAlertEvidence| where Timestamp > ago(30d)| where Title == "Kerberos privilege escalation using a diamond ticket" or Title == "Suspicious Kerberos ticket authorization data"| 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, so altered TGTs stop working.
Hardened domain controllers (opens in a new tab)
Guard DCs, their backups and virtual disks, since the attack starts from the krbtgt key they hold.
Replication rights reviewed (opens in a new tab)
Remove replication rights from accounts that are not DCs, bar what Entra Connect needs, closing the DCSync route to the key.

How the Attack Works

How It Plays Out

Step 1 of 5: AS Request

Step 2 of 5: Genuine TGT

Step 3 of 5: PAC Changed

Step 4 of 5: TGS Request

Step 5 of 5: Service Ticket