Golden, Silver and Diamond Tickets in Kerberos

Kerberos trusts tickets because somebody holding the correct key was able to produce them.

When that key is compromised, the trust mechanism still works. It simply starts working for the attacker.

Golden Tickets, Silver Tickets, and Diamond Tickets abuse this trust at different levels. The main differences are which key is compromised, which ticket is created or modified, and who participates in validation.

The examples below assume a lab or an authorized penetration test.

Start with the two keys that matter

A TGT is issued by the KDC and protected with key material tied to the krbtgt account.

A service ticket is protected with the key of the account representing that service.

If cifs/FILE01.lab.local belongs to FILE01$, the service uses material from that account when validating the ticket.

That creates two levels of trust.

Compromising krbtgt affects the whole domain.

Compromising a service account key affects the services represented by that account.

Golden Tickets operate at the TGT layer

A Golden Ticket is a forged TGT created with the krbtgt key.

The attacker needs cryptographic material from krbtgt plus domain information required to construct the ticket.

After creating the TGT, the attacker can request service tickets from the KDC as the identity described inside that forged TGT.

The flow looks like this:

compromised krbtgt key
          |
          v
       forged TGT
          |
          | TGS-REQ
          v
         KDC
          |
          v
    service tickets

The technique is powerful because of where trust was compromised.

krbtgt sits at the center of TGT trust for the domain.

Silver Tickets operate at the service layer

A Silver Ticket uses the key of a service account to forge a service ticket directly.

The attacker does not need to create a TGT first.

The attack may also avoid contacting the KDC during ticket creation and initial use, depending on the service and its validation behavior.

Conceptually:

hash or AES key of FILE01$
        |
        v
ticket for cifs/FILE01
        |
        v
FILE01 validates with its own key

The scope is narrower.

Owning the key for FILE01$ does not automatically produce valid tickets for SQL01$.

The SPN and its backing account still define the boundary.

Diamond Tickets start from a real TGT

A Diamond Ticket begins with a legitimate TGT obtained from the KDC.

An attacker who already possesses the krbtgt key then modifies relevant ticket content and recalculates the required cryptographic protections.

The goal is to preserve characteristics of a KDC-issued ticket while changing identity or authorization data.

That matters for detection.

A Golden Ticket can be created fully offline.

A Diamond Ticket includes a legitimate AS-REQ and AS-REP before modification.

That does not make a Diamond Ticket invisible.

It changes the artifacts and the observed path.

The PAC matters

In Windows, the Privilege Attribute Certificate carries information used for authorization.

Groups.

SIDs.

Logon-related data.

When ticket forgery modifies that material, the attacker usually wants a service to see privileges that the represented identity would not normally have.

A forged ticket therefore involves more than changing username=Administrator.

The resulting structure still needs to be accepted by Kerberos and by the service receiving it.

RC4 and AES change the required material

Older tooling talks heavily about NT hashes.

That comes from RC4-HMAC usage.

Modern environments may use AES128 or AES256.

The required key material changes accordingly.

The core idea stays the same.

The attacker needs a key compatible with the encryption type protecting the ticket.

A good pentest does not assume RC4 just because an old Mimikatz example uses /rc4.

Identify the encryption types the environment actually accepts.

A Golden Ticket does not depend on the represented user’s password

The KDC trusts the TGT because it is protected by the krbtgt key.

The password of the user represented by the ticket may be completely unknown.

It may even have been changed afterward.

As long as the key supporting TGT trust remains valid, the attacker retains the ability to forge acceptable material.

That is why krbtgt compromise requires a different response from resetting one administrator password.

Silver Ticket response is more localized

If the compromised key belongs to a service account, containment centers on that identity.

Rotating the account password or key invalidates forged material based on the old key once the change is effective and the application supports the rotation.

The investigation still needs to find how the key leaked.

LSASS dump?

Deployment secrets?

Weak password on an SPN account?

Compromised machine account?

Rotation closes the old ticket path. The source needs fixing too.

Golden Ticket response requires careful krbtgt rotation

Microsoft instructs organizations performing forest recovery to reset the krbtgt password twice.

The official process requires at least a 10-hour gap between resets when maximum ticket lifetimes are at their default values.

If the configured lifetime is higher, the waiting period needs to exceed that configured value.

The reason is key history.

One rotation still leaves previous key material available for compatibility.

Two resets clear the older keys from the relevant history.

This should be performed with healthy replication and as part of a proper incident response process.

It is not an operation to trigger casually during a penetration test.

How I separate the three during analysis

First I ask which key the attacker needs.

If it is krbtgt, Golden or Diamond is in scope.

If it is a specific service account key, Silver becomes relevant.

Then I ask whether the base ticket came from the KDC.

Golden can be created offline.

Diamond starts with a real TGT and modifies it.

Finally, I ask which ticket the service receives.

Those three questions remove most naming confusion.

Detection should not depend on one IOC

Ticket forgery artifacts change with encryption type, tooling, Windows version, and PAC construction.

Indicators tied to old tool versions may disappear in newer implementations.

Mature detection combines behavior.

Service ticket requests inconsistent with account history.

Unusual SIDs or groups.

Unexpected TGT properties.

Use of disabled accounts.

Privileged access from unusual hosts.

High-privilege activity without the expected logon sequence.

For Silver Tickets, a missing matching TGS request may be useful in some scenarios because the ticket can be built offline.

None of those signals should be treated as proof by itself.

Protection starts before ticket creation

Treat krbtgt as a critical domain secret.

Isolate Domain Controllers.

Keep privileged credentials away from unnecessarily exposed hosts.

Give service accounts strong managed passwords.

Prefer AES where compatibility allows.

Reduce legacy RC4 deliberately.

Include service accounts and machine accounts in credential hygiene.

The distinction worth remembering

Golden compromises trust in domain TGTs.

Silver compromises trust at a specific service.

Diamond uses the same critical krbtgt key but starts with a legitimately issued TGT before changing its contents.

The technique name is useful.

The compromised key explains the impact.

References

Microsoft Learn, Active Directory Forest Recovery: Reset the krbtgt password.

Microsoft Learn, Kerberos authentication overview.

SpecterOps, Rubeus.