Active Directory Part 3: Kerberoasting Attack – What is it?

Active Directory (AD) is central to modern enterprise networks, handling authentication, access control, and user management. But its complexity also makes it a prime target for attackers. One such attack is Kerberoasting, and understanding it is essential for defending your AD environment. In this third blog post, I will touch upon what Kerberos is, how it might be exploited and the importance of proper password policies, encryption algorithms and what one should consider when using Kerberos in Active Directory. 

What is Kerberos? 

AD uses Kerberos as its primary authentication protocol. Kerberos It issues tickets to verify identities and authorize access to resources. These tickets include: 

• Ticket-Granting Ticket (TGT): Proves a user’s identity to request other tickets. 

• Service Ticket (ST): Grants access to a specific service. 

Service accounts,  which are often privileged and used by applications,  authenticate via Service Principal Names (SPNs), making them potential targets. 

Kerberos Mutual Authentication Process 

1. Client authenticates against the authentication server, and issues Ticket Granting Ticket (TGT).

2. TGS verified TGT and issues Service Ticket (ST) to Client.

3. Client sends ST to Service. Service verified ST and grants/decline access. 

What is Kerberoasting?

Kerberoasting takes advantage of how Kerberos handles service ticket requests. An attacker with domain access can request a service ticket for a targeted service account. Because these tickets are encrypted with the service account’s password hash, the attacker can extract them and attempt to crack the password offline.

Service accounts in Active Directory provide authentication and authorization for services and applications, allowing them to run with the necessary permissions without user credentials. They’re often used for automated tasks like backups or updates and typically hold elevated privileges, making them attractive targets.

Each service account can be associated with a Service Principal Name (SPN) — a unique identifier that allows Kerberos to authenticate services on the network. When a service account requests a Kerberos ticket, it includes its SPN to verify its identity to other services. While SPNs enable secure service authentication, misconfigured or poorly managed SPNs can become a vulnerability, exposing accounts to attacks like Kerberoasting.

Once a service account password is recovered, it often grants elevated access within the network, potentially enabling lateral movement, privilege escalation, or further attacks.

Common tools used in this attack include Mimikatz, Rubeus, and Impacket for ticket extraction, and Hashcat to perform offline password cracking.

Why is Kerberoasting effective?

This attack works because of several common weaknesses in AD environments:

• Weak service account passwords: Many service accounts use simple, outdated, or guessable passwords, sometimes left unchanged for years.
  
  
• Outdated encryption algorithms: By default, Kerberos might use older algorithms like RC4_HMAC_MD5, which are vulnerable to modern cracking techniques. If encryption isn’t upgraded to AES256, passwords are easier to crack.

• Weak password policies: Inadequate complexity requirements or no enforced minimum lengths leave accounts exposed to brute-force attacks.

• Lack of password rotation: Service account passwords often remain static, increasing the window of opportunity for an attacker to successfully crack a ticket.

• Overprivileged service accounts: Accounts with excessive permissions increase the damage an attacker can do once credentials are obtained.

• Misconfigured delegation settings: Delegation allows a service to act on behalf of a user. If poorly configured, it enables attackers to impersonate users and request tickets to other services.

• Insufficient monitoring: Without alerting systems in place to flag unusual ticket requests or other anomalies, Kerberoasting attacks can go undetected.

Example of Kerberoasting

Using the PowerView module, after identifying a potential victim, the ticket can be extracted into a format that can then be used in Hashcat to be cracked:

> Get-DomainUser -SPN | Get-DomainSPNTicket -Format Hashcat 

Rubeus is also another tool that can automate this exploit. It is also possible to retrieve the ticket from memory using Mimikatz. Another way to identify possible vulnerable entities in the system is to use Bloodhound. This tool visually maps out relations, permissions, and connections. In this case, the kerberoastable account SQLSERVICE has Admin permissions to LABDC.

The next step after extracting the service account hash would be to try to crack it. In the following picture, the hash has been passed to Hashcat, which is a password cracking tool. Hashcat works by taking a hashed password and attempting to reverse it by comparing it against a large list of possible passwords (wordlist) or by using brute-force techniques. It repeatedly hashes each candidate password using the same algorithm and checks if the result matches the target hash, if it does, the original password is revealed.  Using the Hashcat command, the cleartext password can be retrieved.

If the password is crackable, then the cleartext password can be used for authentication. In this case it could be used to access LABDC.

How to Defend Against Kerberoasting

Protecting your AD environment requires a combination of preventative measures and proactive monitoring:

• Enforce strong, complex passwords for all accounts, especially service accounts. Combine this with mandatory regular password changes.

• Upgrade to AES256 encryption for Kerberos authentication where possible, eliminating weak algorithms from your environment.

• Review and restrict delegation settings to the minimum necessary. Avoid unconstrained delegation wherever possible, as it broadens the attack surface.

• Apply the principle of least privilege, ensuring service accounts have only the permissions required for their function.

• Implement continuous monitoring for abnormal Kerberos ticket activity, such as a high number of service ticket requests or unusual account behavior.

Security assessments and audits play a key role here too. Tools like BloodHound can map attack paths and privilege relationships, while Microsoft Baseline Security Analyze (MBSA) can identify configuration flaws.  Though built for offense, Kerberoast (the PowerShell tool) can be used defensively to find vulnerable accounts and Mimikatz remains valuable for testing ticket extraction protections.

Final thought: If you’ve lost track of your service accounts or aren’t monitoring their behavior, attackers might already be ahead. Time to audit, clean up, and lock them down.

Next up in this series: Delegation settings, and why you should be wary of anything “unconstrained.”