September 20, 2022

I Wanna Go Fast, Really Fast, like (Kerberos) FAST

Written by Andrew Schwartz

Active Directory Security Review Penetration Testing Purple Team Adversarial Detection & Countermeasures Red Team Adversarial Attack Simulation Research Security Testing & Analysis

1 Introduction

At TrustedSec, we weigh an information security program's ability to defend against a single specified attack by measuring detection, deflection, and deterrence. Now while a majority of my blog posts have been concentrated around detection this post is more 'deterrence' focused. I first heard about Kerberos FAST from Steve Syfuhs (@SteveSyfuhs) of Microsoft in a series of tweets that he has since turned into his own post. Of course, whenever I have any Kerberos questions, without hesitation or delay, my next turn is to connect with my close friend Charlie Clark (@exploitph).

2 Lab Setup

Being eager to test FAST out, I used Marvel-Lab by Jonathan Johnson (@jsecurity101) and Ben Shell (@UsernameIsBen) to help me create an Active Directory environment. I first turned to the official Microsoft documentation What’s New in Kerberos Authentication, which Steve Syfuhs also mentions and links in his post. After dozens of attempts and even 'bricking' my own domain the process, I settled on the following Group Policy Object (GPO) polices:

Figure 1 - Domain Controller FAST KDC GPO Setting

Figure 2 - Domain Controller FAST Kerberos GPO Setting

The biggest thing for me was to fully enable the GPO to Fail unarmored authentication requests on the Domain Controller (DC).

Figure 3 - Workstation Kerberos FAST GPO Setting

3 The FAST Difference

There have been probably several hundred, if not thousand, 'infosec' blogs on Kerberos and attacking Kerberos. As such, we have all come to be familiar with the 'standard' Kerberos protocol-authentication flow.

Figure 4 - Kerberos Authentication Diagram by Sean Metcalf from adsecurity.org

The absolute high-level summary and main difference between 'normal' Kerberos and FAST is that parts of the authentication flow are now encrypted with a separate key causing parts of the request and response to be 'armored.' The armor key is derived from the armored TGT session key and the subkey within the authenticator. The TGT session key is generated by the DC, and the authenticator subkey is generated by the client.

According to the Microsoft article What’s New in Kerberos Authentication, the main control FAST serves is: “Protection against offline dictionary attacks. Kerberos armoring protects the user’s pre-authentication data, which is vulnerable to offline dictionary attacks when it is generated from a password.” In other words, this protects the AS-REQ. Once FAST is enabled, this will be noticeably obvious over the 'wire'. This led me to create the following diagrams, based on my understanding of a WireShark packet capture in my lab:

Figure 7 - Kerberos FAST TGS-REQ Diagram

Figure 8 - Kerberos FAST TGS-REP Diagram

When we obtain Kerberos tickets and run the klist command on a host, we will see that our tickets contain a new indication that FAST is being utilized in the Cache Flags field:

Figure 9 - klist Output Showing FAST is Being Utilized

4 OST Testing

For a while now, there has been much debate within the infosec community, primarily on Twitter, about the release of tools by security researchers to the general public, which have become unofficially dubbed as Offensive Security Tools (OSTs). The debate centers around the issue of a tool being released in the open that will do more harm than good, as it will ultimately be used by adversaries/threat actors in attacks. I will say that without OSTs such as Rubeus and Impacket, I would not have been able to test the implementation of this control effectively and reliably.

One reason I wanted to look at FAST was my interest from Steve’s post. In his post, he notes the following:

Figure 10 - Kerberoasting Note from Kerberos FAST 'Armoring' by Steve Syfuhs

This made me want to investigate what was actually possible with FAST enforced.

4.1 Rubeus Testing

With the above said, we can now first use Rubeus to test this deterrence control. I began by executing common attack scenario commands. I based the testing cases on the Rubeus commands that do and do not utilize LSASS:

Figure 11 – Rubeus Tool **LSASS** v. Non-**LSASS** Usage

Rubeus commands that do not leverage LSASS were found to not work, as noted by the rerun of KDC_ERR_POLICY, as of writing this post, with FAST enforced. This is most likely due to the way the tickets are being crafted as non-LSASS commands take a more manual request/approach.

4.1.1 Rubeus LSASS Utilization Results

Figure 12 - Successful Rubeus Kerberoast

4.1.2 Rubeus Non-LSASS Utilization Results

Figure 14 - Failed Rubeus Kerberoast With Supplied Ticket

Figure 17 - Failed Rubeus ASREPRoasting With FAST Fail Authentication in Place

Figure 18 - Failed Rubeus Kerberoast With RC4OPSEC

4.2 Impacket Testing

We can also confirm FAST's impact on the current Impacket tool suite:

Figure 19 - Testing FAST With Impacket's GetUserSPNs.py

Figure 20 - Testing FAST With Impacket's GetNPUsers.py

Figure 21 - Testing FAST With Impacket's getTGT.py

As evident in the above screenshot, an error of KDC_ERR_POLICY is returned. At this point, I further suspected and hypothesized that Impacket's ability to use Kerberos would be effectively broken as LSASS is not being utilized.

5 Conclusion

I had significant difficulty getting FAST implemented in my domain. I 'bricked' my domain on multiple occasions based on the GPOs and how they were configured, and whether or not I first needed to reboot my client prior to my DC to obtain an armored ticket from my DC. I also encountered other strange cases where I could not use NTLM, RDP, or runas /netonly, but I was able to use PSSession. I countlessly read the Microsoft documentation and Steve’s post, and every time I walked away with more questions each time, and still wasn't sure I configured FAST in accordance with and adherence to Microsoft's intended implementation and best practice.

Now, let me definitively state the goal of this post on Kerberos FAST is not intended to disparage Microsoft or FAST itself. The implementation of FAST, which I have yet to observe in a client environment, was not easy or straightforward for me. Notwithstanding, it is also not fair on my part to call out the ineffectiveness of a single or independent control. The larger picture should be examined through defense-in-depth. Defense-in-depth should exist both horizontally and vertically among detection, deflection, and deterrence. I hope, if anything, this post pushes Microsoft to continue to implement controls like FAST and further strengthen them.

Lastly, this blog would not have been possible without help from the following people:

Alberto Solino (@agsolino)

Ben Shell (@UsernameIsBen)

Benjamin Delpy (@gentilkiwi)

Carlos Perez (carlos_perez)

Charlie Clark (@exploitph)

Dirk-jan Mollema (@_dirkjan)

Elad Shamir (@elad_shamir)

Jonathan Johnson (@jsecurity101)

Julie Daymut

Justin Elze (@HackingLZ)

Nathan Noll