Kerberoasting Attack in Cyber Security & How it Works?

Hacking a password is not a difficult task for hackers these days. That’s why Kerberos, a computer network authentication protocol was introduced in the 1980s to prevent passwords from being sent over the internet & ultimately protect systems and users. But, the sophisticated hackers found loopholes in this protocol as well & started exploiting it. This type of assault in cyber security language is referred to as the Kerberoasting attack. 

So, let’s understand this attack in detail, how it works, and the best practices you can follow to prevent such an attack.

What is Kerberoasting Attack? – The Definition

Attacks on the Kerberos authentication protocol are known as “Kerberoasting.” A Kerberoasting attack involves the extraction of encrypted Kerberos tickets from a network by an attacker using specialized tools, followed by an attempt to decipher the encryption. Depending on the attack’s success rate, the attacker may be able to access private data or network resources. 

In this attack, an attacker can try to target as many service accounts as they can, or they might carry out internal reconnaissance to locate particular service accounts with the credentials they want.

What is the Purpose of Kerberoasting Attack?

Before learning more about the attack, let’s have a look at the architecture of service accounts to understand why hackers are targeting the same.

• Passwords for service accounts have the same length and never expire.
• The majority of service accounts have elevated permissions and frequently belong to extremely privileged groups like Domain Admins, giving AD complete admin rights.
• By breaking the credentials for the service accounts, attackers can take advantage of the Kerberos system and take over the entire AD domain.

Now, let’s dig deeper into knowing this attack.

How Kerberoasting Work?

Similar to the majority of attacks on Active Directory, Kerberoasting allows for lateral movement on networks and privilege escalation. Once attackers are established inside an enterprise network, they start researching more and move laterally. This way, it enables the attackers to request any Kerberos service ticket as legitimate domain users, grab the TGS ticket from memory, and then attempt to offline decrypt the service credential hash using any number of password-cracking tools.

Attacks such as “Kerberoasting” are conceivable because of weaknesses in the Kerberos design and another trustworthy component, unreliable user behavior.

The TGT (Ticket Granting Ticket) is the user’s authorization to request ticket-granting service (TGS) tickets for various domain resources in Kerberos-based systems like Active Directory. TGS tickets are by design encrypted with the NTLM hash of the service account. Service accounts that are used to encrypt TGS tickets are identified by service principal names (SPNs) in Microsoft Windows. They can be connected to domain or host user accounts.

Also, attacks on Kerberoasting only succeed against SPNs (Service Principal Names) of domain users. Because host-based SPNs are protected by randomly generated 128-character passwords that are updated every 30 days, this is true. Even with the most up-to-date technology and software for password cracking, these lengthy, random, and transient passwords are essentially impossible to guess.

Then again, SPN passwords for user accounts are a different matter. These are chosen by people, they never expire, and they are hardly ever updated. Given human proclivities, these passwords are frequently cliched, inadequate, and easily decipherable. They are frequently also quite old, making them simple prey for offline cracking.

This is when the restriction imposed by architectural design comes into the picture. The Kerberos authentication architecture enables authenticated domain users to make a TGS ticket request for any network service. The domain controller from which the user is requesting the ticket, however, does not check to see if the user is authorized to use the in-question service. Since the service handles the enforcement, an offline attack is possible.

How Kerberoasting Attacks Actually Operate? Learn the Step by Step Operative Procedure

There are some elements of such an attack that exist. Let’s see what are they & how attackers use them to carry out the attack.

1. An attacker first gains access to a domain user’s account. It is not necessary for the user to have elevated or “administrator” rights. The hacker logs on to the domain.
2. The Kerberos key distribution center (KDC), which is signed by its KRBTGT service account in Active Directory, issues a ticket-granting ticket (TGT) to the malicious user after they have successfully authenticated.
3. The malicious actor then submits a service ticket request for the compromised service. The domain controller will construct a TGS ticket, encrypt it using the service password, and obtain the rights from the Active Directory database. Because only the service and the domain controller have access to the secret, they are the only ones who can decrypt the ticket.
4. The service ticket is given to the user by the domain controller, which presents it to the service, which decrypts it and determines whether to grant the user access to the service. An attacker may now remove the ticket from system memory and crack it manually.
5. The process of requesting service tickets and returning crackable ticket hashes in formats suitable for submission to password-cracking tools, which will extract plaintext credentials from vulnerable hashes, is automated by features.

Kerberoasting Attack Examples – Realtime Instances

There are many examples where Kerberoasting attacks are performed in different ways.

For instance, threat actors utilized PowerSploit’s Invoke-Kerberoast module during Operation Wocao to get encrypted service tickets and offline brute force Windows Service Account passwords. The connected service accounts can then be authenticated using these service tickets on other networked systems. The passwords for these service accounts, which are frequently weak or shared among several accounts, were then subjected to a brute force attack by threat actors. Hackers could access delicate network systems and data by guessing the password for a service account.

Secondly, the FIN7 attack group executed lateral network movement using Kerberoasting for credential access.

In addition, APT29 adversaries gained Ticket Granting Service (TGS) tickets for Active Directory SPNs. They used the same to crack offline in the Solorigate backdoor issue. The Solorigate backdoor event was a cyber attack on a number of targets, including governmental organizations and tech firms. A sophisticated backdoor termed “Solorigate” was employed by the attackers, who were thought to be members of the APT29 gang, to gain access to the victims’ networks. Kerberoasting was one of the attack’s strategies. Attackers can access sensitive network data and systems by guessing the password for a service account.

Plus, in order to steal AES hashes, Wizard Spider, a Russia-based financially motivated threat group, employed Rubeus, the MimiKatz Kerberos module, and the Invoke-Kerberoast cmdlet.

How to Detect Kerberoasting Attack?

The first question must have come across your mind after reading about this attack i.e. can you detect it?

Well, yes. It’s possible to detect several aspects of Kerberoasting by monitoring. Keep an eye out for unusual Kerberos activity, such as when Audit Kerberos Service Ticket Operations is made available to record Kerberos TGS service ticket requests. Look into unusual patterns of activity in particular. For example: accounts sending Event ID 4769 multiple times in a short period of time, especially if they additionally request RC4 encryption [Type 0x17] (Reference from MITRE ATT&CK)

Also, monitor for odd behavior, such as when Audit Kerberos Service Ticket Operations is made available to record Kerberos TGS service ticket requests. Look into unusual activity patterns in particular.

How to Respond to Kerberoasting?

Once you detect the Kerberoasting attack, the next step is to respond. Here are the actions you can follow.

• Set the incident response system into motion and notify the incident response team.
• Any affected machines (such as the host that sought service tickets) should be quarantined for forensic analysis, eradication, and recovery operations.
• Change the user account password for the Kerberoasting process.
• Any service accounts for whom TGS tickets were requested should have their passwords reset. Privileged accounts need to come first.

Now, comes the question of how can you prevent or mitigate the Kerberoasting attack. 

Kerberoasting Prevention Techniques

Well, first you need to secure service account passwords. For that, you can: 

• Reject Kerberos Flexible Authentication Secure Tunnelling (FAST)-based authentication requests — This pre-authentication extension, also known as Kerberos Armoring, creates a pre-authentication secure channel between the client and domain controller with the aim of better shielding Kerberos tickets against offline password cracking efforts. While FAST can completely eliminate the danger associated with Kerberoasting, organizations may find it difficult to quickly deploy and enforce it.
• Eliminate the usage of insecure protocols in Kerberos – Although completely turning off RC4 requires further work, it is possible to set up specific service accounts so that they do not support the protocol. Only AES128 and AES256 will be supported if the parameter msDS-SupportedEncryptionTypes is set to 0x18 (decimal 24). Additionally, this improves the sensitivity of the detection: A stronger indicator of malicious activity is the use of RC4 in a TGS request.
• For service accounts, adopt strong password hygiene procedures — Passwords for service accounts must be generated at random, contain at least 30 characters, and be changed frequently.
• When possible, use group-managed service accounts (gMSAs). Active Directory automatically generates and periodically modifies the 256-bit passwords for gMSAs. Administrators are relieved of this responsibility, which promotes accuracy and efficiency.
• Ensure that SPNs are not being allocated to powerful user accounts that are not intended for usage as service accounts, such as members of the Domain Admins group.

Key Takeaways

1. Kereberoasting is an attack method that adversaries use to crack the hash password in Active Directory.
2. To avoid detection or account lockouts, hackers use an offline password-cracking approach.
3. After cracking the password and logging in, they behave as authenticated users and proceed with their attack strategies.
4. It’s challenging to cut off the Kerberoasting attack since it is hard to spot.
5. Multi Factor Authentication (MFA) and centrally managed password systems can help prevent this attack.

FAQs

Q- What is the difference between traditional password cracking and Kerberoasting?

The most basic difference is that traditional password cracking focuses on extracting user account passwords whereas Kerberoasting focuses on extracting service account passwords. 

Q- How common is a Kerberoasting attack in the real world?

These attacks are becoming common and have been documented in various cyberattacks. Though this attack method is used by hackers, security professionals such as red team members and penetration testers use this approach to test the security environment.

Note: This attack may become a matter of concern for organizations having poorly or improperly managed service accounts. 

Q- What should you do when suspect Kerberoasting attack?

Once you suspect this attack, immediate action. Such as isolating the compromised account, changing passwords, conducting a deep investigation of the incident, etc.

Q- What could be the negative impact of a successful Kerberoasting attempt?

A successful attempt at this attack may lead to critical service account compromise. Further, the attackers may gain unauthorized access to network resources, move laterally within the environment, etc.