Table of Contents
Charlie Clark

[Editor’s note: This blog was co-authored by Andrew Schwartz at TrustedSec.] One day, while browsing YouTube, we came across a Black Hat 2015 presentation by Tal Be’ery and Michael Cherny. In their talk and subsequent brief, Watching the Watchdog: Protecting Kerberos Authentication with Network Monitoring, Be’ery and Cherny outlined something we had never heard of … the Diamond Privilege Attribute Certificate (PAC) attack. We’ve both been interested in forging tickets over the past year, so this technique immediately grabbed our attention and started us on a journey of examination and PoC weaponization. The result? The Diamond Ticket.

Related Reading

Golden Ticket vs Diamond Ticket

Both Golden  attacks and Diamond Ticket attacks require access to the KRBTGT key. However, Diamond Ticket attacks almost certainly also require access to the AES256 key. Whereas Golden Ticket attacks take advantage of the ability to forge a ticket granting ticket (TGT) from scratch, Diamond Ticket attacks take advantage of the ability to decrypt and re-encrypt genuine TGTs requested from a domain controller (DC).

Diamond PAC vs Diamond Ticket

The original Diamond PAC attack:

  1. Requests a TGT without a PAC
  2. Ensures that the service account for the service to be accessed did not have the NA bit set in its UserAccountControl (UAC) attribute
  3. Forges a PAC and signed it with the KRBTGT key
  4. Injects the PAC into the resulting service ticket by including the PAC in the enc_authorization_data section of the TGS-REQ

The NA bit in the UAC attribute has the value 33554432 (see Figure 1).

Figure 1 – UAC NA BIT

After setting the NA bit in a service account’s UAC attribute, service ticket requests to that service account have no PAC (see Figure 2).

Figure 2 – Requesting a Service Ticket Without a PAC

Whenever authorization data is included within the enc_authorization_data section of a TGS-REQ (see Figure 3), it is copied into the authorization_data section of the encrypted part of the resulting service ticket.

Figure 3 – Wireshark Output of enc_authorization_data in a TGS-REQ

Diamond PAC took advantage of this behavior to inject a PAC into the resulting service ticket when the target service account did not have the NA bit set (see Figure 4).

Figure 4 – Injecting PAC in Service Ticket

Note the size difference of the ticket output between Figure 2 and Figure 4.

As Figure 5 shows, the ticket belongs to Loki but the PAC has different user information (i.e., Thor).

Figure 5 – Dump of Service Ticket with Injected PAC

Thanks to the November 2021 Kerberos/AD patches, using a TGT without a PAC is no longer possible on fully up-to-date DCs. So, we knew immediately that this version of the attack would no longer work. But, after reading about it, we wondered why the attack needed to be so complex. In the process of simplifying the attack, we removed most of its requirements—making it possible on fully up-to-date DCs.

The KRBTGT key was one requirement, and the attack made use of any other valid account to request a TGT. Why not just decrypt that TGT, modify it however we wanted, recalculate the PAC signatures, and re-encrypt it? We dubbed this approach a Diamond Ticket attack.

Weaponizing Rubeus

We implemented our Diamond Ticket into Rubeus with a new command— diamond

—within this PR. In the following demonstration, we use this new command to create and use a Diamond Ticket.

We begin the attack by attempting to access the C$ file share (CIFS) on a DC, using our low-privileged user (Loki). As Figure 6 shows, we get an Access is denied response.

Figure 6 – Low-Privileged User Denied on the DC for CIFS Access

Assuming we have previously compromised the KRBTGT key, we can use the new command diamond

in Rubeus to create a Diamond Ticket. This command first requests a normal TGT for the low-privileged user Loki (see Figure 7). The command then decrypts the TGT, modifies the relevant parts, recalculates the signatures, and re-encrypts the TGT (see Figure 8).

Figure 7 – Rubeus Constructing a Diamond Ticket (1)
Figure 8 – Rubeus Constructing a Diamond Ticket (2)

The resulting ticket can then be used like any other TGT, but now with modifications. As Figure 9 shows, we then requested a service ticket to the CIFS service on our target DC (Earth-DC).

Figure 9 – ASKTGS for CIFS Service Ticket

Lastly, in the same terminal, we can now access the C$ share on the DC, authenticating as a different user than the account that requested the TGT (see Figure 10).

Figure 10 – Successful Access of C$ on Domain Controller

OPSEC advantages

There are many potential ways to detect Golden Ticket use or the actions required to gain access to the KRBTGT key (like DCSync). One technique: Monitor for service ticket requests (TGS-REQs) that have no corresponding TGT request (AS-REQ). However, be aware that the Diamond Ticket technique is more likely to bypass this type of detection by requesting a valid TGT before using the resulting ticket. In addition, because the ticket is first created by a DC, some values (for example, ticket times) are more likely to be correct by default, rather than requiring the calculation of proper times for OPSEC Golden Ticket creation.

Detection guidance

The original Diamond PAC research listed the following as network-based detection guidance:

  • An AS-REQ with a PA-PAC-REQUEST set to false
  • The addition of authorization data in a subsequent TGS message
  • The target service NA bit set to false, requiring PAC for authorization

Given our improved technique, this guidance does not apply. The Diamond Ticket attack does not require requesting a TGT without a PAC, sending a forged PAC within an enc_authorization_data section of a TGS-REQ, or setting the NA bit on any service accounts.

However, some detection logic for Golden Tickets attack (for example, the actions required to gain access to the KRBTGT key) might also apply to detecting a Diamond Ticket attack. Many other techniques that can be used to detect any type of forged ticket (Golden, Silver, or Diamond) largely depend on the level of care taken during the creation of the ticket—for example, setting ticket times that are different from what they should be.

None of these methods are guaranteed silver bullets for detecting this attack, just as there are no silver bullets for detecting Golden Tickets.

A new take on tickets

This post has sought to demonstrate a minimal PoC weaponization of Diamond Tickets, albeit a Mimikatz-style implementation. This research can be easily extended to provide full control and manipulation of any tickets, given the right keys.

Upon concluding our research and creating a PoC weaponization, Elad Shamir sent us Tim Medin’s DerbyCon 2014 talk, Attacking Microsoft Kerberos Kicking the Guard Dog of Hades. In this talk, Tim discusses the same technique in the context of service tickets.

Although our technique is a slightly different take on Golden and Silver Tickets, it might provide a useful and preferred alternative in certain environments.