Kerberoasting: The hunt for weak password

Written by Jean-Camille LOISEAU & Anup Tripathi | Published 20 August 2021

Computers and servers are protected by a username & password in order to control and restrict their access. This has been for decades now the go-to default security mechanism for all systems from the desktop PC to the mighty Domain Controller.

This lock mechanism is a prime target for attack as controlling is controlling the kingdom.

Since Windows 2000, Microsoft Active Directory (AD) is based on the LDAPv3 protocol and Microsoft’s proprietary implementation of Kerberos is the default authentication method in AD environment and domain.

At Derbycon 2014, Tim Medin presented a new method Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades. Kerberoasting (MITRE: T1558.003)is a pervasive attack that takes advantage of weaknesses within the Kerberos authentication protocol to extract service account credential hashes for the purpose of decrypting them offline before reusing them to take over new accounts.

Kerberoasting, as many other dangerous techniques, abuse valid functionalities of a ubiquitous protocol that cannot be "patched" and are therefore very dangerous as they can enable the attacker to achieve Persistence, Privilege Escalation, and Lateral Movement via access to Valid Accounts.

Some context on Kerberos and Active Directory first.

Kerberos is a great security feature for systems and user authentication within the context of computers and domain. One of the big risk solved by Kerberos is that of password being exchanged and traversing the network.

With Kerberos, passwords no longer need to transit between systems. Instead the authentication relies on "tickets" or session keys that are issued to the user or requesting system by the Kerberos Key Distribution Center (KDC) that is part of the domain controller (DC).

The KDC, being integrated within the DC, has obviously all access to know the passwords of all security account database and can operate what's called Delegated authentication.

Instead of connecting directly to an application server and entering a local password,

the user first authenticates themselves with the domain controller.
When the DC has validated that username and password checks out, the KDC issues the user a Ticket-Granting Ticket (TGT).
The authenticated user then revert back to the DC with the TGT attached to prove they are authenticated and request access to a service or an account or resource
The DC checks & validate the TGT, creates a new Ticket Granting Service (TGS) contains the hashed credentials of the service requested, or the service account, as part of the ticket and sends that to the requesting user.
The user can then go back to the application or service or account with this TGS that once validated will grants them access to that specific resource.

Pay close attention to step 3 & 4 as they are key parts of how Kerberoasting works.

Below is a great detailed diagram of Kerberos delegated authentication steps from adsecurity.org:

1a. Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an authenticator in the authentication ticket (TGT) request (AS-REQ). 1b. The Domain Controller (KDC) checks user information (logon restrictions, group membership, etc) & creates Ticket-Granting Ticket (TGT).

2. The TGT is encrypted, signed, & delivered to the user (AS-REP). Only the Kerberos service (KRBTGT) in the domain can open and read TGT data.

3. The User presents the TGT to the DC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ). The DC opens the TGT & validates PAC checksum – If the DC can open the ticket & the checksum check out, TGT = valid. The data in the TGT is effectively copied to create the TGS ticket.

4. The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP).

5.The user connects to the server hosting the service on the appropriate port & presents the TGS (AP-REQ). The service opens the TGS ticket using its NTLM password hash.

What is Kerberoasting?

It's important to repeat that for the Kerberoasting attack to occur, the attacker already entered your network, and obtained the credentials to a valid account that they can use to launch their attack from.

Kerberoasting is a popular pervasive attack technique where the attacker abuses the valid Kerberos ticket granting ticket (TGT) obtained from the KDC upon authentication with an account they previously compromised and took control of, to make initiate requests for a Ticket Granting Service *TGS) for any service account Service Principal Names (SPNs) they target.

Once the TGS is received, they extract it from their system's memory and can begin offline brute force methods to crack the SPN's credential hash of the targeted account embedded within the TGS using any number of password-cracking tools.

Kerberoasting attacks are possible for several reasons:

1- The attacker never actually attempts logon on the target, nor does he sends a single packet to the service itself. There are no failed logon attempts registered anywhere.

2- Kerberos and the DC that the attacker is requesting the TGS from do not control if the requesting account of the attacker is authorized or privileged to access the target service (this is left to the end service to enforce).

3- Kerberos architecture does not limit the amount of TGS tickets an account can request over any period of time as it assumes that all requests for TGS are valid attempts at logon from an authenticated valid account.

In short as long as the attacker controls ANY valid SPN's account, they can, without requiring special or escalated privileges, request TGS (that contain target account password hash) from any number of account they want to then crack offline.

It's important to note here that Kerberoasting attack will only be effective against SPN's from accounts that have a user set password. host-based accounts are typically secured with random 128-character passwords that are changed every 30 days.

On the other hand, service accounts where the passwords was set by a human are at higher risk. These password may be common, weak and, guessable or they may already be part of password "dictionary" leverage from previously compromised passwords in other hacking breaches.

In addition, they may be set without expiry date, or may be changed only rarely and in case of legacy technologies may not even comply with latest password policy requirements set forth by the organization.

Why should I care about Kerberoasting attack?

Kerberoasting is a dangerous attack because it does not require any specific privileges or accesses. all it requires is 1 compromised account and time. Because it relies on misusing ubiquitous and indispensable protocols, the attack surface is large and it is not easy to prevent occurrence of such an attack from a malicious actor with a foothold on the network.

Once an attacker successfully completed a Kerberoasting attack, there may be little to now signs of the attack ever occurring and the attacker may have gained access to different more discreet account or accounts with higher level of privileges that may enable them to carry out other attack. For example, if they compromise a domain admin account, they may be able to launch Shadow DC or DCSync attacks.

Kerberoasting has a low barrier to entry and high potential for automation. Since 2020, there has been demonstration of the technique being used to assist in spreading ransomware throughout business networks.

How does a Zerologon attack unfold?

Once the attacker gained a foothold and compromised an account within the organization, they will begin by using LDAP functions to perform SPN scanning. The attacker will either leverage PowerShell such as Invoke-Kerberoast, python scripts such as GetUserSPN.py, or simply the Windows built-in SetSPN.exe function.

Using crafted queries, the attacker will look for lists of service accounts, their role, their privilege. For example they may want to prioritize admin accounts identified by account attritbute AdminCount=1, or an accounts with MSSQL, IIS web services enabled, etc.

This preliminary phase does not raise any alarm and enables the attacker to establish a list of service accounts they want to attack in priority and avoid host based SPNs which would likely be immune to the attack method.

In a second step, the attacker requests a service ticket for the service accounts SPNs they want to target from the DC and as they are an authenticated user, their request comes enclosed with a validated TGT.

The DC takes the request, retrieves the target account password's and permission and generates a TGS shared as a hash encrypted by the SPC's password.

At this point, instead of presenting the TGS to the service to be decrypted and granted access based on adequate permissions, the attacker intercept and copies the TGS from system memory and can begin attacking the hash of the TGS offline using a variety of password cracking tools.

The attacker then uses these tools to brute force different hashes on the ticket and when the ticket is successfully opened and decrypted that means they discovered, the correct service account password.

They can then use the service account name and newly discovered password to log on using these newly compromised credentials to another system thus enabling the previously mentioned Persistence, Privilege Escalation, and Lateral Movement.

How do I prevent a Kerberoasting attack?

Kerberoasting is challenging to prevent as it t is based on the abuse of important system features.

What you can do to specifically prevent this type of attack is to maintain discipline and proper control of your accounts and their password:

Inventory all service account and ensure all of them follow robust password policies:
1. long (25+ characters), complex passwords,
2. ideally randomly generated
3. rotating on a regular basis: no less than yearly, ideally monthly or more
Follow least privilege access model and ensure privileges and permissions are limited to the strict indispensable minimum on service accounts.
Use Privilege Account Solution (PAM) to track and monitor the use of any privileged account and monitor for any usage of these account bypassing your PAM solution.

How do I detect a Kerberoasting attack?

Pre-Requisite: It’s recommended to enable logging of Event Id 4769 “A Kerberos service ticket was requested” on your organizations DCs and sent to SIEM solution

Kerberoasting detection is a lot tougher since requesting service tickets (Kerberos TGS tickets) happens all the time when users need to access resources, therefore 4769 event is very noisy as there are a lot of such events from every legitimate users attempting to authenticate to resources.

There are multiple ways to detect Kerberoasting. However, it is useful to perform statistical analysis as a Kerberoast attempt would likely generate multiple 4769 attempts for multiple different SPNs in a short burst of time from a single source.

It is important to monitor for TGS-REQ packets with RC4 encryption as it is probably the best method, though, again, many false positives are likely.

Let us see a few effective ways to detect Kerberoasting:

Method 1: Using SIEM/SOAR and creating use case/alert with below conditions:

"event_id":"4769"

AND

“TicketEncryptionType":"0x17"

NOT

“ServiceName”:“krbtgt”

NOT

“ServiceName”:“*$” ## Service Name does not end with ‘$’##

NOT

“TargetUserName”: “*$@*” ## Account Name does not match '<MachineName>$@<Domain>’##

This would detect & trigger an alert if a single IP address requests at least 10 TGS (adjust as needed) on at least 10 different service names in last 1 hour (or less). AD Forest requests are to be excluded.

Method 2: Detecting slow Kerberoasting attack based on historical activity baseline:

This approach can be used to detect an attacker who performs slow Kerberoasting attack by requesting very few TGS from vulnerable services over a longer period of time.

You may create an algorithm that can add below 2 type of entries in a database:

Whitelisted services: list of services that are commonly used (more than 10 different user in a pre-defined period of time). TGS requests from any user on these services are not to be monitored.
For the rest of services: the algorithm can be used to add known username along with service name and last activity timestamp in the database.

The ideal way is to run this algorithm for at least 2 months of past windows logs to populate the database with whitelisted service and known user service requests to have enough learning/baseline based on historical activity that can enable effective alerting of any unusual Kerberoasting activity.

If a user makes more than two (or any other defined threshold) TGS requests that satisfy both of the following conditions, then alert should triggered:

The requested service is not whitelisted,
The combination of username & service name is not found in the database

Finally, based on the analysis if it's a false positive alert, the combination of username & service name can be stored in the database as part of the learning algorithm.

Method 3: Detecting slow Kerberoasting attack using a Honeypot Kerberoast Service Account (Honey SPN)

You can create an account and it's SPN (using setpspn) that isn’t actually used in your organization. This service should never be requested for a ticket by any legitimate client. This honeypot account should look a lot like a good SPN account in your organization.

You want this account's group membership look intriguing to an attacker. It can be done in below 2 ways:

Add this account to a privileged group (make sure the password is very strong, at least 30 chars long)
Create a deceptive group just for this account (The group needs to look interesting)

This account needs to look real, regardless of the method you use, You may even want to ensure that the account’s LastLogonTimeStamp is not old.

If TGS requests are observed for this Honeypot Service Account (which is not expected), it would highlight the suspicious Kerberoasting activity.

How do I respond to a Kerberoasting attack alert?

In case a Kerberoasting attack is detected, below response actions should be taken:

Activate your Security Team and follow the defined incident response process.
Immediately quarantine any implicated computers (such as the host that requested service tickets) for in-depth forensic investigation, also initiate the mitigation and recovery process.
Reset the password of all service accounts for which TGS tickets were requested by the attacker. Privileged service accounts to be prioritized.
Perform password reset for the user account used for Kerberoasting.

Related content:

Kerberoasting: The hunt for weak password

Recent Posts

Kommentare