This manifold implementation or process of brute forcing credential hashes within the Windows Active Directory ecosystem would soon become the de facto attack vector against the Kerberos protocol, leveraging certain exploitable authentication and encryption mechanisms of the popular MIT-born technology while embroiling the Redmond giant in a cascade of existential threats for years to come. Owing to this, it would take the effort of the entire cybersecurity community to later arrive at a suitable arrangement of detection and mitigation opportunities.

As pervasive as it was, Kerberoast actually embodied only a handful of operating principles which allowed non-privileged domain users to get their hands on so-called service accounts—an alluring proposition that was usually met with a favorable outcome in the case of service accounts having weak passwords. Needless to say, the formalism known as Kerberoasting, as early adopters coined the new technique, was quickly charged with being an accessory to a growing number of post-exploitation scenarios that plagued modern enterprises from all across the globe.

In this blog post, we will explore the Kerberoasting affair in light of its salient features; taking a quick dive into some of its more creative touches and periodizing important ideas as they pertain to the privilege escalation and lateral movement aspects of the cyber kill chain, as well as to its contribution to the ever-growing list of network threats.

We’ll begin our journey by revisiting Kerberos, examining its pitfalls and going into some detail as to why the former crypto apparatus exposed critical vulnerabilities that led to the extraction of such sensitive data with such little relative effort.

Let’s begin.

Kerberos revisited

Distributed computing systems in the late 80s presented unique challenges against the authentication backdrop in which one endpoint entity was required to prove its trustworthiness to another, preferably in a single sign-on fashion that could take advantage of a centralized management infrastructure according to the technology of the day. In this context, Kerberos quickly emerged as an arbitrator protocol between client and server that leveraged cryptographic tickets as the accepted authentication exchange mechanism between trusted hosts to achieve controlled access to services and applications.

Over the years, Kerberos spanned five different models or versions that encompassed several subprotocols rolled into three different components: a trusted third party, also called a key distribution center or KDC, with a database of principals (user and service accounts) and their corresponding shared secrets to perform authentication with; a client, or privileged user, who negotiates authentication within a specific realm by issuing a request to the ticket-granting service (TGS) for a special ticket (TGT or ticket granting ticket) that is used to derive the necessary credentials to gain access to a specific resource; and a service, or application server, hosting data or the resource in question that is being requested by the client.

Kerberos excelled in cross-realm scenarios where organizational boundaries required authentication across different network segments. Organized in a hierarchical manner, these inter-realm capabilities are the main driving force behind Microsoft’s Active Directory and the way in which this proprietary implementation of Kerberos version 5 establishes user control and authentication. This represented a vast improvement over previous NTLM-based approaches, including the adoption of symmetric cryptographic primitives and “salting” in lieu of password hashing, or the aforementioned mutual authentication and delegation feature options required by multi-tier applications. Kerberos is also classified as an open standard, which technically translates to the MIT-born technology being shipped as part of all major computer operating systems under open source licensing terms, and vendors’ ability to extend the protocol as they see fit.

Before we move on, let’s summarize all pertinent acronyms and similar terminology introduced thus far, with a handful of additional ones to be discussed later on:

Despite its robust features, Kerberos has some important weaknesses—two, to be precise: one that allows user impersonation via unsecure session key storage, but more importantly, a second one that allows attackers to obtain and bruteforce (the “roast” in Kerberoast) Kerberos tickets associated with weak encryption linked to poor password hygiene. Other minor flaws include questions that revolve around key caching (and an overarching storage problem) as well as certain time-bound operations prone to failure due to time offsets between clients and servers.

What are Kerberoasting attacks?

But, what exactly are Kerberoasting attacks? Kerberoasting belongs to the post-exploitation, or post-compromise, phase of an attack which focuses on gaining further access to additional targets using privilege escalation and similar lateral movement techniques. At a high level, Kerberoasting allows attackers, impersonating non-privileged domain users with preset SPN attributes, to request service-related TGS tickets from memory in an attempt to crack the associated NTLM hashes of the plaintext passwords linked to that particular service account.

There are a few key points to highlight regarding the above definition:

• As explained, the attack does not require special privileges or administrative rights to the domain—any domain-joined machine will do so for the purpose of extracting the service account credential dumps, without any interaction with domain controllers or directory services for that matter.

• The impersonating aspect comes from an unconstrained delegation ability on the part of certain computer accounts to leverage other accounts to access resources on behalf of those users. This defeats the purpose of trust boundaries by allowing out-of-scope services to reach across domains. Microsoft has ever since implemented additional protections, but older deployments may still be at risk.

• The offline password-cracking nature of the attack is a luring proposition, especially when the extent of any active defenses involved is yet to be determined or when stealth is required and covert actions are a must.

Kerberoasting greatly simplifies the frequent heavy lifting that takes place after a foothold has been achieved. This boils down to miscreants being able to pull a noteworthy feat of hacking ingenuity with relative ease. Thus, it is a common misconception to disregard dated attack vectors, such as Kerberoasting, with the mindset that deficiencies in protocol design and implementation can be overcome through adequate detections. To the contrary, Kerberoasting remains as relevant as it was when it first appeared; in fact, it is far from detached from its glory days—a testimony to its subtle sophistication and validity.

How Kerberoasting attacks work

At the heart of Kerberoasting is Microsoft’s legacy support for a form of Kerberos encryption that supports RC4—a steadily-weakening stream cipher highly sensitive to statistical biases that significantly reduces the strength of the password hashing algorithm used to secure principals in the Active Directory ecosystem. Cryptographic best practices that suggest the use of a “salt” as an additional input to the hashing function are also absent from certain RC4 encryption functions. This allows attackers to construct smaller rainbow tables that diminish the computational efforts required to crack RC4 open.

How is this all applicable to Kerberoasting? Well, as far as the intent goes, compromising the Active Directory domain begins by you (or the attacker) scanning the environment looking for domain accounts whose SPN values indicate any service-related associations. With this information in hand, the next step is to request TGS service tickets for any high-privileged SPNs using your proof-of-identity TGT (received at login time) while focusing on SPNs specifically linked to domain user accounts and not host-based ones, also known as machine accounts, since the latter would entail the need to brute force randomized 128-character long passwords—good luck.

In a nutshell, Kerberos allows any authenticated domain user to request valid TGS tickets of service accounts by specifying their SPN values, returning a service ticket partially encrypted with the NTLM plaintext password hash of the account whose SPN value was specified. Additionally, if a certain SPN is registered for a particular domain user account, the account will be secured using the NTLM hash of that user’s password instead; for instance, some SQL instances are known to run under a certain domain user—if this user account happens to have a weak password, it is an absolute candidate for Kerberoasting.

Once enumeration is complete and TGS tickets have been obtained, attackers can now proceed to grab all these TGS tickets from memory (using hacking tools like Mimikatz), save them to a desired location, and obtain the password hashes linked to those service accounts for further cracking using any number of mechanisms (e.g., Hashcat) available online for this purpose, with little risk of detection or the possibility of locking any of the targeted accounts.

Finally, being in possession of the plaintext passwords means these credentials can now be used to compromise additional systems and resources the exposed service accounts may have access to—this is akin to an attack vector known as horizontal privilege escalation whereby the attacker is able to access protected systems using high privileges obtained from vulnerable applications or even front-end services.

Detecting and mitigating Kerberoasting

For a number of reasons, including the lack of proper password hygiene and similar unkempt domain conditions, Kerberoasting remains incredibly feasible across the enterprise world, which can leave many system owners and security practitioners gawking as to why the attack even happened in the first place.

In everyone’s defense, however, the attack remains as challenging to detect and mitigate against as ever; after all, Kerberoasting, as an overarching technique, was deeply ingrained in the fabric of Kerberos prior to any attempts by Microsoft to come to terms with any of its pre-existing cryptographic flaws. But, in the meantime, we can certainly focus our efforts on some, if not all, of the below recommendations:

• The brute-forcing, or password-cracking, stage of the attack can be severely dampened by enforcing robust password complexity requirements on service accounts across the domain. This includes using the recommended password length proposed by MITRE of 25 characters or more, or the use of Managed Service Accounts introduced by Microsoft back in 2012 in an effort to assist with automatic password management and rotation.

• Attackers are very often surgical about which systems they choose to target; be mindful of your service accounts’ group memberships and frequently audit SPN assignments linked to high-privileged user accounts; for instance, no member account of groups such as Domain Administrators should ever have SPNs assigned (be used as service accounts). This will limit the scope of what systems can be further compromised in case an attacker gets a hold of less-privileged accounts.

• Use Kerberos FAST (Flexible Authentication Secure Tunneling), if possible, to armor pre-authenticated data by protecting authentication service (AS) exchanges with the KDC via secure tunneling. In case FAST becomes challenging to implement, resource-based constrained delegation can be used as a safer form of delegation to restrict the services to which a given server can act on the behalf of a user.

• Take advantage of group policies to eliminate the use of insecure protocols like RC4: the litmus test by which Kerberoasting becomes a decisive attack vector. Using stronger symmetric key encryption suites like AES-256 to secure TGTs will go a long way in protecting your environment, but don’t disable RC4 across the board until you understand every possible repercussion (you have been warned).

• Finally, do retire legacy systems (Windows Server 2003 and older) using older forms of Kerberos encryption as soon as you can; this is obviously easier said than done, but its operating principle cannot be overly stressed.

When it comes to detection opportunities, be wary of high volumes of TGS ticket requests being generated within a short amount of time; although very frequent TGS transactions aren’t rare, Kerberoasting tends to cast a wide net that is not so easily concealed. Baselining TGS activity can also help with the detection efforts. To this effect, do carefully examine Windows logs especially if Kerberos Service Ticket Operations auditing is enabled, which can lead to detections around the use of RC4 in environments where only AES is allowed.

As always, the detection literature abounds with supplementary materials; be proactive in your approach to securing your Kerberos environment and make sure to rely on the cyber community if you require additional understanding and support.

Final words

The narrative around Kerberoasting is a rather simple one: a hacking technique that has stood the test of time for its ability to go almost undetected, leveraging a distorted approach at mechanisms meant to protect the very data that Kerberoasting seeks to covertly procure. Deconstructing this narrative also took us on a brief tour of service principals claiming authenticity, and the role they play in allowing the proper functioning of trusted third-party access control models as conceived by Kerberos; the next level of detail regarding the evolution of the protocol could launch us into architectural and authorization challenges beyond the scope of this article.

Kerberoasting can be carried through any number of tools and native OS applications as commonplace as PowerShell, so logging and monitoring the use of these resources is a must for any cyber defense undertaking to begin to stand a chance against it. Overall, if there’s one thing that Kerberoasting teaches us, it’s that achieving adequate security is anything but trivial, as effective authentication in today’s modern directory services entails supporting a shared population of disparate, and often highly complex, mix of users and services across multiple boundaries.

Finally, take a closer look at your baseline data and fine-tune your prevention arsenal following any of the above recommendations; know what to look for in the tools and train your first responders to do so as well through the use of red team exercises aimed at strengthening your security posture. It will be time and effort well spent and the rewards ample.