Diamond Ticket

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Diamond Ticket

Like a golden ticket, a diamond ticket is a TGT which can be used to access any service as any user. A golden ticket is forged completely offline, encrypted with the krbtgt hash of that domain, and then passed into a logon session for use. Because domain controllers don’t track TGTs it (or they) have legitimately issued, they will happily accept TGTs that are encrypted with its own krbtgt hash.

There are two common techniques to detect the use of golden tickets:

  • Look for TGS-REQs that have no corresponding AS-REQ.
  • Look for TGTs that have silly values, such as Mimikatz’s default 10-year lifetime.

A diamond ticket is made by modifying the fields of a legitimate TGT that was issued by a DC. This is achieved by requesting a TGT, decrypting it with the domain’s krbtgt hash, modifying the desired fields of the ticket, then re-encrypting it. This overcomes the two aforementioned shortcomings of a golden ticket because:

  • TGS-REQs will have a preceding AS-REQ.
  • The TGT was issued by a DC which means it will have all the correct details from the domain’s Kerberos policy. Even though these can be accurately forged in a golden ticket, it’s more complex and open to mistakes.

Requirements & workflow

  • Cryptographic material: the krbtgt AES256 key (preferred) or NTLM hash in order to decrypt and re-sign the TGT.
  • Legitimate TGT blob: obtained with /tgtdeleg, asktgt, s4u, or by exporting tickets from memory.
  • Context data: the target user RID, group RIDs/SIDs, and (optionally) LDAP-derived PAC attributes.
  • Service keys (only if you plan to re-cut service tickets): AES key of the service SPN to be impersonated.
  1. Obtain a TGT for any controlled user via AS-REQ (Rubeus /tgtdeleg is convenient because it coerces the client to perform the Kerberos GSS-API dance without credentials).
  2. Decrypt the returned TGT with the krbtgt key, patch PAC attributes (user, groups, logon info, SIDs, device claims, etc.).
  3. Re-encrypt/sign the ticket with the same krbtgt key and inject it into the current logon session (kerberos::ptt, Rubeus.exe ptt…).
  4. Optionally, repeat the process over a service ticket by supplying a valid TGT blob plus the target service key to stay stealthy on the wire.

Updated Rubeus tradecraft (2024+)

Recent work by Huntress modernized the diamond action inside Rubeus by porting the /ldap and /opsec improvements that previously only existed for golden/silver tickets. /ldap now auto-populates accurate PAC attributes straight from AD (user profile, logon hours, sidHistory, domain policies), while /opsec makes the AS-REQ/AS-REP flow indistinguishable from a Windows client by performing the two-step pre-auth sequence and enforcing AES-only crypto. This dramatically reduces obvious indicators such as blank device IDs or unrealistic validity windows.

# Query RID/context data (PowerView/SharpView/AD modules all work)
Get-DomainUser -Identity <username> -Properties objectsid | Select-Object samaccountname,objectsid

# Craft a high-fidelity diamond TGT and inject it
.\Rubeus.exe diamond /tgtdeleg \
  /ticketuser:svc_sql /ticketuserid:1109 \
  /groups:512,519 \
  /krbkey:<KRBTGT_AES256_KEY> \
  /ldap /ldapuser:MARVEL\loki /ldappassword:Mischief$ \
  /opsec /nowrap
  • /ldap (with optional /ldapuser & /ldappassword) queries AD and SYSVOL to mirror the target user’s PAC policy data.
  • /opsec forces a Windows-like AS-REQ retry, zeroing noisy flags and sticking to AES256.
  • /tgtdeleg keeps your hands off the cleartext password or NTLM/AES key of the victim while still returning a decryptable TGT.

Service-ticket recutting

The same Rubeus refresh added the ability to apply the diamond technique to TGS blobs. By feeding diamond a base64-encoded TGT (from asktgt, /tgtdeleg, or a previously forged TGT), the service SPN, and the service AES key, you can mint realistic service tickets without touching the KDC—effectively a stealthier silver ticket.

.\Rubeus.exe diamond \
  /ticket:<BASE64_TGT_OR_KRB-CRED> \
  /service:cifs/dc01.lab.local \
  /servicekey:<AES256_SERVICE_KEY> \
  /ticketuser:svc_sql /ticketuserid:1109 \
  /ldap /opsec /nowrap

This workflow is ideal when you already control a service account key (e.g., dumped with lsadump::lsa /inject or secretsdump.py) and want to cut a one-off TGS that perfectly matches AD policy, timelines, and PAC data without issuing any new AS/TGS traffic.

OPSEC & detection notes

  • The traditional hunter heuristics (TGS without AS, decade-long lifetimes) still apply to golden tickets, but diamond tickets mainly surface when the PAC content or group mapping looks impossible. Populate every PAC field (logon hours, user profile paths, device IDs) so automated comparisons do not immediately flag the forgery.
  • Do not oversubscribe groups/RIDs. If you only need 512 (Domain Admins) and 519 (Enterprise Admins), stop there and make sure the target account plausibly belongs to those groups elsewhere in AD. Excessive ExtraSids is a giveaway.
  • Splunk’s Security Content project distributes attack-range telemetry for diamond tickets plus detections such as Windows Domain Admin Impersonation Indicator, which correlates unusual Event ID 4768/4769/4624 sequences and PAC group changes. Replaying that dataset (or generating your own with the commands above) helps validate SOC coverage for T1558.001 while giving you concrete alert logic to evade.

References

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks