Unauthorized access to credentials is a part of virtually any successful cyberattack. Attackers are particularly interested in techniques that provide access credentials that allow far-reaching authorizations without immediately setting off the alarm bells on monitoring systems. Sometimes these techniques result from the functionality of Windows and Active Directory (AD).

Stolen and Broken

Kerberoasting [1] is an attack technique that relies on the ability of every user or computer to request, in Kerberos, a service ticket from the domain controller (DC) for every service. A check as to whether the requesting account has the right to do this only occurs when the service is accessed with this ticket. Therefore, if a security principal in the AD has a service principal name (SPN), any user – including a standard user or a workstation hijacked by an attacker – can grab a service ticket for this security principal from a DC.

The service ticket issued by the DC contains a part that is exclusively intended for the requested service principal and is also intended to ensure that the ticket was generated by the DC of the specified domain. For this purpose, the ticket is encrypted with the Kerberos hash of the service account, which is ideally only known to the DC and the account itself. However, the ticket contains plain text information that is known from the outset, such as the name of the requesting user, which allows the success of a decryption attempt to be verified quickly and reliably. The information attackers are looking for is not included in the payload, but used as an encryption key.

Kerberoasting therefore boils down to brute force. As a rule, the attackers first extract the complete service ticket from the compromised environment and use tools such as Hashcat or John the Ripper in their own environment to reconstruct the plaintext password (offline cracking). Because the leading ransomware gangs already tapped into the as-a-service business model some time ago, the GPU power required for cracking hashes and tickets can be rented by the hour in hyperscaler clouds such as Azure or AWS and naturally lends itself to hacking from a commercial perspective. At the same time, it is impossible to determine the location of the "crack stations" on the basis of typical power consumption patterns.

The two phases of Kerberoasting therefore involve diametrically opposed levels of effort. As easy as creating and extracting a service ticket may be in the vast majority of AD environments, cracking the password can be time-consuming if the password is long and complex. The choice of hash algorithm also makes a big difference to the computing power required for cracking: The conventional RC4, which is identical to the NT hash, is increasingly being replaced by AES. Windows versions from Server 2019 onward will only request and issue tickets encrypted with the AES hash. However, if RC4 is generally possible in the AD environment, the attacker can force the domain controller to downgrade the protocol and explicitly request a ticket in which the service part is encrypted with the RC4 hash.

As always, when it comes to guessing passwords, the number of characters and complexity play a very important role. If you limit yourself to the character set that can be entered directly on a computer keyboard when generating passwords, you can have more different passwords, up to a length of 19 characters, than different RC4 hashes in total. Therefore, computer accounts and group Managed Service Accounts (gMSAs) are generally not suitable as Kerberoasting targets, because their passwords are purely random strings that change regularly and are controlled by group policy for computers and defined when the account is created for gMSAs. The default value in both cases is 30 days, which makes cracking uneconomical.

A rumor has circulated among many administrators that domain members lose their trust in AD if they are unable to connect to a domain controller for too long. Although this was sometimes the case with the old Windows NT domain model and with Windows 2000, modern Windows versions can handle this problem. Nevertheless, during the pandemic, some organizations used group policy to disable machine password changes for home office laptops, and in some cases, this policy was linked incorrectly so that it also affected servers, including some with elevated privileges. If an attacker detects this kind of a misconfiguration and has access to inexpensive GPU resources, even cracking a 128-character password can prove economical if the reward is big enough.

The ideal target for Kerberoasting is therefore a legacy service account – that is, a user account that has:

• a non-expiring password, preferably assigned manually and encrypted with RC4;
• an explicit SPN; and
• extensive authorizations either in AD itself or on other systems.

A somewhat rarer variation of Kerberoasting only provides the hash of the plaintext password, which can then be used for pass-the-hash (NTLM), overpass-the-hash (Kerberos ticket with RC4 encryption), or pass-the-key (Kerberos ticket with AES encryption) attacks. However, the computational effort required is identical because the hashes are not tried out directly, but formed from plain text in both cases.

Tracking Down Kerberoasting Targets

Finding worthwhile Kerberoasting targets is easy. Attackers use tools such as Python scripts (one popular example being GetUserSPN.py from the Impacket project [2], which runs on a Linux machine) to reduce the chances of detection when using PowerShell or other standard tools. On the defense side, you don't have to worry about being exposed during reconnaissance and can simply use the on-board AD module for PowerShell. You are looking for accounts that:

• are not deactivated,
• are normal users,
• have a non-expiring password, and
• at have least one explicitly defined SPN.

To accomplish these objectives, you can use the LDAP filter:

(&(!(userAccountControl:
   1.2.840.113556.1.4.803:=2))
  (userAccountControl:
   1.2.840.113556.1.4.803:=66048)
  (servicePrincipalName=*))

The userAccountControl value of 2 means the account is deactivated, and the value 66048 is the sum of 65536 (password does not expire) and 512 (normal user account). If you want to find particularly worthwhile targets that are also members of one of the privileged groups, add (adminCount=1) to the filter after (servicePrincipalName=*). The resulting LDAP filter can be enabled with either of the following commands:

Get-ADUser -LDAPFilter <Filter>
Get-ADObject -LDAPFilter <Filter>

You can also use it with the LDAP browser of your choice or with command-line search tools such as adfind [3] or dsquery [4].

Mitigating Attacks

The Kerberoasting vector is attributable to Kerberos functionality; you will not be able to harden your Active Directory with configuration settings that make Kerberoasting impossible. However, you are not powerless. You will want your defense not to focus exclusively on making the attacks more difficult, but also to limit any consequential damage, making the Kerberoasting technique expensive for the attacker to carry out as well as unattractive in terms of the results.

If an attacker manages to obtain a ticket-granting service (TGS) for a service account from the domain controller, you can reduce the attractiveness of this yield in three ways:

1. Use the longest possible passwords for service accounts to make cracking the hash as difficult as possible. Because the password for service accounts does not usually have to be typed in, character by character, but rather transferred with copy and paste, it can be long and complex.

2. Change the passwords of the service accounts regularly to shorten the time span in which the captured hash material can be used. If the lifetime of passwords is shorter than the estimated time required to crack the hashes, the plaintext password is theoretically secure. For services that do not need to be available 100 percent of the time and can tolerate an occasional restart, you can reset the password quite frequently in a script. If supported by the respective application, gMSA [5], which changes your password automatically, is the best bet. By default, this happens every 30 days, but you can set the permanence of the password to a different value when creating a gMSA – and only at this time.

3. Rigorously restrict the login options and authorizations of the SPN-protected service accounts (Figure 1). Although not necessary to operate SQL servers, SQL server service accounts are often provided with administrative authorizations on the machines in question. Very often, service accounts are even members of highly privileged groups such as domain admins. Adhere to the least privilege principle when assigning rights.

Figure 1: Use authentication policies to prevent issuing a TGS.

If you use systems at the perimeter of your network that recognize and prevent data extraction, you will want to check whether you can enable rules there that respond to service tickets as payload. However, this option should only be viewed as an additional safety measure. You can assume that extraction will probably succeed, because the tickets are relatively small; they can be integrated into most exfiltration methods – for example, DNS and Online Certificate Status Protocol (OCSP), but also HTTP, FTP, or email.

You have several options for restricting the login capability of a service account, such as the old-fashioned Login to… button in AD user management, which is equivalent to the logonWorkstation attribute. However, you can also use group policies to deny service account logins. Multifactor authentication, which is so effective for regular user accounts, cannot be used for service accounts for obvious reasons. The login restrictions also help prevent overpass-the-hash and pass-the-key attacks, but provide no protection against classic pass-the-hash attacks if the compromised service account has authorizations for resources that still accept NT LAN Manager (NTLM).

In many application scenarios you have a very effective way of severely restricting Kerberoasting right at the source, although you will very rarely see it used in production environments. With the authentication policies introduced in Windows Server 2012 R2, you can specify which accounts are generally allowed to request a service ticket for a specific service principal and define the computers on which this is permitted. For example, if the database uses the SVCSQL account and the application layer uses the SVCAPP account in a three-tier application, your maximum protection against Kerberoasting might be:

• SVCSQL created as a gMSA, with the restriction that only the actual SQL servers are allowed to read the password.
• An SVCSQL account assigned an authentication policy that only allows a group named SQL Access to request service tickets; the group includes the regular service account SVCAPP and the database administrators. Service tickets can only be issued for requests that come either from the application servers or from the admin workstations.
• SVCAPP subject to login restrictions so that only the application servers can use this account to log in.
• The two service accounts with only the authorizations they absolutely need to run SQL or the application layer.
• An SVCAPP account with a matching authentication policy if the front end of the application that does not need to be available to everyone in the organization, but only to very specific users and clients.

These strategies massively limit the opportunities for obtaining a service ticket for Kerberoasting and the usefulness of that ticket from an attacker's point of view. Additionally, always make sure only those users and groups in your environment who actually need it (i.e., only the Tier 0 administrators, if in doubt) have the right to describe the servicePrincipalName attribute; otherwise, an attacker could make a privileged account they are targeting vulnerable to Kerberoasting by assigning it an SPN.