This blog post was co-authored with Charlie Clark at Semperis

1.1   Background of the ‘Diamond’ Attack

One day, while browsing YouTube, we came across an older presentation from Blackhat 2015 by Tal Be’ery and Michael Cherny. In their talk, and subsequent brief, WATCHING THE WATCHDOG: PROTECTING KERBEROS AUTHENTICATION WITH NETWORK MONITORING, they outlined something we had never heard of before…the ‘Diamond PAC Attack.’ Since we both have been interested in forging tickets over the past year, this technique immediately grabbed our attention and started us on a journey of examination and POC weaponization.

1.2   Difference Between Golden and Diamond Tickets

Both Golden and Diamond Tickets require access to the KRBTGT key. However, unlike Golden, Diamond would almost certainly require access to the AES256 key. The reason for this is, while Golden takes advantage of being able to forge a ticket granting ticket (TGT) from scratch, Diamond takes advantage of being able to decrypt and re-encrypt genuine TGTs requested from a domain controller (DC).

1.3   Original Diamond PAC vs. Diamond Ticket

The original attack, termed the ‘Diamond PAC Attack,’ consisted of:

1. Requesting a TGT without a Privilege Attribute Certificate (PAC)

2. Ensuring the service account for the service that was to be accessed does not have the ‘NA’ bit set in its UserAccountControl (UAC) attribute

The NA bit in the UAC attribute has the value 33554432:

After setting the NA bit in a service account’s UAC attribute, STs requested to that service account have no PAC:

3. Forging a PAC and signing it with the KRBTGT key

4. Injecting it into the resulting Service Ticket (ST) by including it in the enc_authorization_data section of the TGS-REQ

Whenever authorization data is included within the enc_authorization_data section of a TGS-REQ (like in the screenshot below), it is copied into the authorization_data section of the encrypted part of the resulting ST:

Diamond PAC took advantage of this behavior to inject a PAC into the resulting ST when the target service account did not have the NA bit set:

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

As shown below, while the ticket belongs to Loki, the PAC has a different user’s information (i.e., Thor):

Due to the November 2021 Kerberos/AD patches, it is no longer possible to use a TGT without a PAC on fully up-to-date Domain Controllers (DCs). So, we knew immediately that this version of the attack would no longer work. But, after reading it, we were not certain why the attack needed to be so complex. In the process of simplifying the attack, we removed most of the requirements while at the same time making it possible on fully up-to-date DC's. We knew a requirement needed to be having the KRBTGT key, and the attack made use of any other valid account to request a TGT. So we thought why not just decrypt that TGT, modify it however we wanted, recalculate the PAC signatures, and re-encrypt it. This is what we’ve termed the ‘Diamond Ticket’.

1.4   Weaponizing Rubeus

We have implemented ‘Diamond Ticket’ into Rubeus with a new command (diamond) within this PR . In the following demonstration, we use this new command to create a Diamond Ticket and then use it.

We begin the attack by attempting to access the C$ File Share (CIFS) on a DC using our low-privileged user (Loki).  As shown below, we get an Access is denied response:

Assuming we have previously compromised the KRBTGT key, we can use the new diamond command in Rubeus to create a Diamond Ticket. This command first requests a normal TGT for the low-privileged user Loki; it then decrypts it, modifies the relevant parts, recalculates the signatures, and re-encrypts it:

The resulting ticket can then be used like any other TGT, but now with the modifications. We then request an ST to the CIFS service on our target DC (Earth-DC).

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:

1.5      OPSEC Advantages

There are many potential ways to detect Golden Ticket usage or actions required to gain access to the KRBTGT key (like DCSync). One technique is to monitor for ST requests (TGS-REQs) that have no corresponding TGT request (AS-REQ). The ‘Diamond Ticket’ technique makes it ‘more likely’ to bypass this type of detection by requesting a valid TGT before using the resulting ticket. Additionally, as the ticket is first created by a DC, some values (for example, the ticket times) are more likely to be correct by default, rather than the requirement of calculating the proper times for OPSEC Golden Ticket creation.

1.6      Detection Guidance

In the original research, the following was listed as ‘network-based’ detection guidance:

1. An AS-REQ with a PA-PAC-REQUEST set to false
2. Adding authorization data in a subsequent TGS message
3. The target service has its NA bit set to false, which means it requires PAC for authorization

However, given our improved technique, the above 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 similar detection logic that is used for Golden Tickets may also be applied in detecting a “Diamond Ticket” Attack (for example, the actions required to gain access to the KRBTGT key). Many other techniques that may 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 the ticket times that are different from what they should be.

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

1.7      Conclusion

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.

While this technique is a slightly different take on Golden/Silver Tickets, it may provide a useful and preferred alternative in certain environments.

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 his talk, Tim discusses the same technique but in the context of STs.