A Diamond Ticket attack is a parasitic cryptographic forgery. It hijacks a legitimate Windows authentication flow. This grants an attacker stealthy, long-term access to your network. Unlike Golden Tickets, which are built from scratch and easily flagged by missing request logs, or Silver Tickets, which are limited to specific services, a Diamond Ticket modifies a real, freshly issued ticket.
The Diamond Ticket: Mastering Stealth Persistence in 2026
For years, Golden and Silver Tickets were the ultimate prize for hackers looking to maintain access after a breach. But as Identity Threat Detection and Response (ITDR) tools evolved, those fake tickets became easy to spot.
Today, specialised threat actors have moved on to something far more dangerous: the Diamond Ticket.
A Diamond Ticket isn’t a tool to break into your domain. Instead, it’s a tool used after an attacker has gained access. By changing a legitimate, normal login sequence, an attacker creates a credential that’s structurally and mathematically perfect.
Because the resulting ticket originates from a genuine request on the Domain Controller, it easily blends in with normal network traffic. This effectively hides it from traditional detection mechanisms.
What We'll Cover
- The fundamental difference between Diamond and Golden tickets.
- How the recutting process works within modern offensive tools.
- The evolution of the threat: Introducing the Sapphire Ticket via S4U2self.
- Why EDR struggles with this attack and how Network telemetry catches it.
- How we identify the pathways attackers use to steal the KRBTGT key.
The Evolution of Forgery
To understand why a Diamond Ticket is so effective, you have to look at what came before it.
Golden Tickets (The Artificial Forgery)
A Golden Ticket is built from thin air. An attacker steals the master domain key (the KRBTGT hash). They then use it to manufacture a fake Ticket Granting Ticket (TGT).
- The Flaw. No competent attacker uses an impossible 10-year lifespan. Instead, they match your domain policy. However, the ticket still lacks a corresponding request history (Event ID 4768) in the Domain Controller logs.
- The Detection. Modern SOCs flag these because the user presents a TGT to the network without the Domain Controller having ever recorded a request for it.
Silver Tickets (The Service-Level Forgery)
A Silver Ticket is a more surgical form of forgery. Instead of stealing the master KRBTGT key, the attacker steals the password hash of a specific service account (like a SQL server or a File Server). They then use that hash to forge a Ticket Granting Service (TGS) ticket.
- The Scope. A Silver Ticket only gives the attacker access to the specific service managed by that account.
- The Detection. Because Silver Tickets are forged offline and presented directly to the target server, the Domain Controller (KDC) is never involved. This makes them difficult to find unless you’re monitoring the logs of every individual server on your network.
Diamond Tickets (The Parasitic Forgery)
A Diamond Ticket works like a parasite. Instead of making a fake ticket, the attacker asks the domain for a real one using valid, low-level credentials.
- The attacker uses a tool like Rubeus to make a legitimate request (AS-REQ).
- The Domain Controller issues a real, signed ticket (TGT) via an AS-REP.
- The attacker's tool intercepts this response. This prevents the OS from processing the ticket normally.
- Because the attacker already holds the stolen master domain key (KRBTGT), they decrypt the ticket locally. Then, they inject Domain Admin rights into the Privilege Attribute Certificate (PAC) and resign it.
The resulting ticket is perfect. It has a real request history and correct timestamps. It also matches the network’s normal traffic patterns perfectly.
The Sapphire Ticket (The Apex Predator)
If you want to understand the true bleeding edge of identity research in 2026, look at the Sapphire Ticket.
While a Diamond Ticket requires the attacker to manually calculate and inject PAC information, a Sapphire Ticket is even more advanced.
Using the S4U2self Kerberos extension, the attacker forces the Domain Controller to generate a legitimate, high-privileged PAC for a real administrator. They then steal this PAC and inject it into their own low-level TGT.
A Sapphire Ticket is the absolute peak of Kerberos forgery. This is because the PAC is structurally correct and a precise, stolen replica of a real administrator's identity.
The 2026 Cryptographic Reality
According to the most recent Microsoft Security Baselines, AES-only environments will no longer be enforced in Active Directories. There’s a dangerous myth that AES-256 stops ticket forgery because the keys are harder to steal. This is false.
Both AES-256 keys and legacy hashes are stored in the same place: the NTDS.dit database and LSASS memory. When an attacker executes a DCSync attack, they extract the AES keys just as effortlessly as the legacy hashes.
What AES-256 changes is the baseline. A Diamond Ticket forged with an AES key is incredibly difficult to detect. This is because it matches your highest security standards. It blends seamlessly with modern, fully patched network traffic.
Advanced Diamond Ticket Detection: Spotting the Forgery
Since a Diamond Ticket is mathematically perfect, you can't find it by looking for bad math. You must look for unusual behaviours and structural changes.
EDR Blindness vs. Endpoint Monitoring
Modern Endpoint Detection and Response (EDR) and antivirus platforms can’t cryptographically tell that a ticket is forged while it’s in transit.
However, they can monitor the local endpoint for the Pass-the-Ticket (PtT) event (e.g., API calls to LsaCallAuthenticationPackage). It’s required to load the forged ticket into memory.
Advanced attackers must use kernel-level EDR bypasses (like BYOVD) to safely inject the forged ticket without triggering an alert.
Ticket Size Anomalies
Your Network Detection and Response (NDR) or SIEM is a critical defence. The attacker decrypts the TGT, adds new administrative groups to the PAC, and re-encrypts it. Because of this, the ticket becomes bloated.
Crucially, this size anomaly is visible during the TGS-REQ, when the attacker presents the forged TGT back to the DC. It’s not noticeable during the initial AS-REP.
Advanced SOC teams detect Diamond Tickets by correlating abnormal TGS-REQ payload sizes with unusual endpoint behaviour. An example is the sudden use of administrative named pipes.
Finding the Root Cause: How We Hunt for the Master Key
A Diamond Ticket is a post-compromise weapon. So, the most important question for any defender is: How did the hacker steal the KRBTGT master key in the first place?
When our cybersecurity experts conduct an internal penetration test, we manually trace the same paths an attacker would take. We don't just scan for obvious gaps. Instead, we demonstrate how different systems can be chained together to reach your most sensitive data.
For example, in a threat hunt we look for things like:
- Unsecured Backup Servers. We check if an attacker could find old, forgotten copies of your Active Directory database (NTDS.dit) on a backup drive.
- Certificate Flaws. We analyse your Active Directory Certificate Services (ADCS) to see if a flawed template lets a standard user request an admin-level certificate.
- Hypervisor Weaknesses. We test your virtual environment to see if an attacker could silently copy the virtual hard drive of a Domain Controller while it’s still running.
By simulating these complex, multi-stage attacks, we provide precise reports. These reports show you the exact technical steps a cybercriminal would take to break your network. This helps your internal teams fix the root cause. It secures the master keys and makes a Diamond Ticket attack impossible.
Close Your Identity Gaps for Good
Automated tools won't find the complex, hidden escalation paths in your directory. You need a manual, expert-led audit to secure your network's master keys today.
Secure Your Identity Perimeter Today
Frequently Asked Questions About Diamond Tickets
Is a Diamond Ticket used to break into a network?
No. It is a persistence mechanism. To forge the ticket, the attacker must already have the KRBTGT master key. This means they’ve already achieved Domain Admin rights. They use the ticket to stay hidden while they move around.
Does resetting the KRBTGT account password stop Diamond Tickets?
Yes, but you must do it twice. The Domain Controller remembers the previous password. This prevents login failures while the change is happening.
If you only reset it once, an attacker's forged ticket using the old master key might still work. Resetting it twice completely locks out the old keys. You just need to leave enough time between resets for your system to sync.
Will moving to the cloud stop Diamond Ticket attacks?
Diamond Tickets are an on-premises Active Directory attack. If you move completely to cloud-only identities (like Microsoft Entra ID), this specific attack is no longer possible.
However, if your cloud still syncs with your local network, a forged ticket on-premises can still compromise your synced cloud data.
How long can a hacker stay hidden with a Diamond Ticket?
Because the hacker holds the master key, they can keep creating new Diamond Tickets whenever they want. Even if you force all users to log out and change their passwords, the attacker can just forge a new ticket to get right back in.
The only way to remove them is to find and secure the stolen KRBTGT key.
Can my antivirus block the tools used to make these tickets?
Standard antivirus can block common hacking tools if they’re saved to the hard drive. However, advanced hackers run these tools in the computer's temporary memory (RAM).
This is why looking for unusual network behaviour, like sudden changes in ticket sizes, is much more reliable than just scanning for bad files.
Will requiring Smart Cards or MFA stop this attack?
No. When an attacker forges a Diamond Ticket offline using the master key, they control every piece of data inside that ticket. They can simply edit the ticket to claim that Multi-Factor Authentication was successfully used.
Then, when the Domain Controller reads the ticket, it trusts the signature. It believes the attacker passed the MFA challenge.
