In the Active Directory (AD) attack landscape, the Diamond Ticket attack emerges as a stealthy, advanced method of escalating privileges and bypassing standard security controls. Based on traditional Kerberos abuse techniques, this attack takes advantage of a fundamental weakness in the way services trust the contents of Kerberos tickets, in particular the privilege attribute certificate (PAC).
What is a Diamond Ticket?
At its core, a Diamond Ticket is a forged Kerberos Ticket Granting Ticket (TGT) where the PAC is modified to include elevated privileges, such as membership in the "Domain Admins" group. Unlike Golden or Silver Ticket attacks, which focus on creating entire fake tickets or service tickets respectively, the Diamond Ticket attack modifies an existing valid TGT—injecting privilege escalation without raising red flags.
How the Attack Works
Here’s how an attacker pulls off a Diamond Ticket attack step-by-step:
1. Compromise the KRBTGT Account
The attacker must first gain access to the domain’s KRBTGT account hash (often via DCSync attacks using tools like Mimikatz or Impacket). This account is responsible for signing all Kerberos tickets in the domain.
2. Decrypt a Valid TGT
With the KRBTGT hash, the attacker decrypts a legitimate TGT to access its contents, including the embedded PAC.
3. Modify the PAC
The attacker alters the PAC data to falsely claim higher privileges—like adding themselves to Domain Admins or other sensitive groups.
4. Re-encrypt the TGT
The modified TGT is re-encrypted using the KRBTGT hash, making it appear completely valid to domain services.
5. Use the Forged Ticket
The attacker now presents this TGT to the domain to request service tickets, which are issued based on the fake elevated privileges in the tampered PAC.
Why It Works: The Flaw in PAC Validation
Most domain services trust the PAC blindly and skip validation with the Domain Controller (DC). This design choice speeds up performance but opens a critical gap: services often do not verify the PAC's digital signature, allowing tampered tickets to pass unchecked.
Real-World Example: Linux & Windows Scenarios
The attack works from both Linux and Windows environments using tools like:
-
Impacket (Linux): Used to extract hashes, create forged tickets (
ticketer.py), and execute commands (psexec.py) with the fake identity. -
Rubeus (Windows): Powerful forker of Kerberos tickets, supporting Diamond Ticket creation and injection directly into sessions (
/ptt).
Detection: Know the Signs
Monitoring the following Windows Event IDs can help detect Diamond Ticket activity:
-
4769: Service ticket request—watch for unusual privileges or rare encryption types.
-
4624: Successful logon—track logon type 3 (network logon) from unexpected sources.
-
4678: Privileges assigned—flag non-admins receiving special rights.
-
4713: Kerberos policy changes—look for unusual ticket lifetime updates.
-
4625: Failed logons from suspicious accounts/IPs.
SIEM tools can also be tuned to detect patterns like multiple high-privilege service requests or tickets reused across multiple IPs.
Mitigation: Shutting the Door
Preventing Diamond Ticket attacks involves a combination of good practices and proactive defenses:
Reset KRBTGT Passwords Regularly
Reset the password twice to invalidate all existing Kerberos tickets.
Disable RC4, Enforce AES
Modern encryption like AES256 makes ticket forging harder.
Least Privilege Model
Limit who can request sensitive ticket types and access privileged tools.
PAC Validation
Where possible, configure services to validate PACs with the domain controller.