Kerberoasting: The Silent Identity Thief

In the intricate dance of authentication within a Windows Active Directory (AD) environment, few attacks are as notoriously simple yet devastatingly effective as Kerberoasting. For years, this technique has allowed attackers to abuse legitimate features of the Kerberos protocol to harvest credentials without ever sending a packet to the victim system. It requires no elevated privileges to perform, making it a favorite for attackers who have just gained a foothold in a network.

This article explores the mechanics of Kerberoasting in excruciating detail, why it remains a top-tier threat in 2026, and how defenders can detect and mitigate it effectively.

The Genesis of the Attack

To understand Kerberoasting, we must first revisit how Kerberos handles service authentication. The protocol was designed in the 80s at MIT to solve a specific problem: "How do I prove who I am to a service without sending my password over the network?"

The answer lies in Tickets.

When a user wants to access a service (like a SQL Server, a web application, or a file share), they don't authenticate directly to that service. Instead, they authenticate to a trusted third party: the Key Distribution Center (KDC), which resides on every Domain Controller (DC).

The Kerberos Ticket Flow (Simplified)

  1. AS-REQ: The user asks the KDC for a Ticket Granting Ticket (TGT). This proves "I am User A".
  2. AS-REP: The KDC validates the user's password hash and issues a TGT. The user now has a "passport" valid for 10 hours.
  3. TGS-REQ: The user wants to access a specific service (e.g., MSSQLSvc/db.corp.local). They present their TGT to the KDC and ask for a Service Ticket (ST) for that service.
  4. TGS-REP: The KDC issues the Service Ticket.

Here is the critical part: The KDC needs to encrypt this Service Ticket so that only the target service can decrypt it. If the KDC encrypted it with the KDC's own key, the service wouldn't be able to open it. So, the KDC encrypts the Service Ticket using the password hash of the account running the service.

The Service Principal Name (SPN)

How does the KDC know which account runs the service? This is where the Service Principal Name (SPN) comes in. An SPN is a unique identifier associated with an AD account (either a computer account or a user account) that tells the KDC: "Hey, if you want to talk to the SQL service on Server01, use the password of the 'sql_svc' user account to encrypt the ticket."

The Fatal Flaw

The fatal flaw exploited by Kerberoasting is that any authenticated user can request a Service Ticket for any service account with an SPN. The KDC does not check if the user should access that service; it simply issues the ticket. And because part of that ticket is encrypted with the service account's password hash, the attacker receives a blob of data that is effectively a "password oracle". If they can guess the password offline, the blob will decrypt successfully.

Why User Accounts Are the Target

Technically, you can Kerberoast any account with an SPN. However, in practice, attackers target User Accounts, not Computer Accounts.

  • Computer Accounts (Machine Accounts): When a computer joins a domain, it gets an account (e.g., SERVER01$). It has SPNs for default services like CIFS and HOST. However, the password for a computer account is a random, 120-character string that rotates automatically every 30 days. Cracking a 120-character random password is mathematically impossible with current technology.
  • User Accounts (Service Accounts): These are accounts created by admins to run specific applications (e.g., svc_sql, iis_admin, backup_svc). Because humans create them and often need to type the password into configuration files, these passwords are frequently weak (e.g., Summer2025!, Password123, Service1).

Kerberoasting is the art of requesting tickets for these weak user accounts and cracking them offline.

The Anatomy of a Kerberoasting Attack

Let's walk through the full attack lifecycle, from reconnaissance to domain dominance.

Phase 1: Reconnaissance and Target Selection

The attacker, having compromised a standard user's workstation or credentials, first needs to find targets. They are looking for user accounts that have the servicePrincipalName attribute set. This can be done using standard LDAP queries, meaning it requires no special privileges and generates very little noise.

Using PowerShell (ActiveDirectory Module)

If the RSAT tools are installed (or imported via a DLL), finding targets is trivial:

Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName

Using PowerView (Dev Branch)

PowerView is a staple for AD reconnaissance. It's often run in memory to avoid antivirus detection.

Get-DomainUser -SPN

Using Native Windows Tools (Listing SPNs)

If no PowerShell is allowed, the built-in setspn binary can list SPNs, though it's "noisy" if you query the whole domain.

setspn -Q */*

Phase 2: Requesting the Ticket (The "Roast")

Once targets are identified, the attacker requests the Service Tickets. This is a standard TGS-REQ.

The Weapon of Choice: Rubeus

Rubeus (C#) is the modern standard for Kerberos interaction. It can request tickets, extract the hash, and format it for cracking tools automatically.

# "Roast" all vulnerable accounts and output to a file
.\Rubeus.exe kerberoast /stats /nowrap /outfile:hashes.txt
  • /stats: Shows how many accounts were found.
  • /nowrap: Ensures the long hash isn't broken by newlines.
  • /outfile: Saves the hashes to a file.

Legacy: Invoke-Kerberoast

The classic PowerShell script still works but is heavily flagged by EDRs (Endpoint Detection and Response systems).

Invoke-Kerberoast -OutputFormat Hashcat | Select-Object -ExpandProperty Hash

From Linux: Impacket

If the attacker is pivoting through a Linux box or using a SOCKS proxy:

GetUserSPNs.py domain.local/user:password -request -outputfile hashes.kerberoast

Phase 3: The Extraction

The output of these tools is a hash that looks like this:

$krb5tgs$23$*svc_sql$DOMAIN.LOCAL$MSSQLSvc/sql01.domain.local*$6A8B...[snip]...

Let's break this down:

  • $krb5tgs$: Indicates it's a Kerberos 5 TGS-REP etype 23 hash.
  • 23: Specifies the encryption type (RC4-HMAC). This is the most common and easiest to crack.
  • svc_sql: The target username.
  • DOMAIN.LOCAL: The domain.
  • MSSQLSvc/sql01...: The SPN requested.
  • $6A8B...: The encrypted part of the ticket.

Phase 4: Offline Cracking

This is where the magic happens. The attacker takes hashes.txt to their own powerful rig (often a GPU cluster) and uses tools like Hashcat or John the Ripper.

Since this happens offline, there is no risk of locking out the account. An attacker can try billions of passwords per second without the domain controller ever knowing.

Hashcat Command

Mode 13100 corresponds to Kerberos 5 TGS-REP etype 23.

hashcat -m 13100 -a 0 hashes.txt /usr/share/wordlists/rockyou.txt

If the password is in the rockyou.txt wordlist (which contains 14 million common passwords), it will be cracked in seconds. If it's a bit more complex (e.g., "Winter2025!"), a brute-force mask attack might take hours or days, but is still very feasible.

Phase 5: Escalation

Success! The attacker now has the plaintext password for svc_sql. What can they do?

  1. DCSync: If svc_sql happens to be a Domain Admin (a common misconfiguration), the attacker can execute a DCSync attack and dump the entire domain database. Game over.
  2. Silver Tickets: Even if they can't log in, they can forge a Silver Ticket. Since they have the service account's password hash, they can create a fake TGS for that specific service. This allows them to log in to the SQL database as sa (System Administrator), even if the svc_sql account itself doesn't have those rights within the app!
  3. Lateral Movement: They can simply log in via RDP or WinRM to any server where svc_sql has access.

OpSec Considerations for Attackers

While Kerberoasting is "quiet" in terms of network packets (it looks like normal traffic), it generates logs.

  • Encryption Downgrade: If an attacker forces RC4 (type 23) encryption when the environment supports AES (type 18 or 28), it's a huge red flag. Smart attackers will try to roast using AES keys if possible, though cracking AES is slower.
  • Honeytokens: Defenders may place "honey" user accounts with SPNs in the domain. These accounts are never used for real services. Any TGS-REQ for them is an immediate alert. Attackers must be careful to validate targets before roasting everything.

Detection and Mitigation Strategies

Defending against Kerberoasting is difficult because you cannot simply "turn it off". Service Tickets are essential for Active Directory to function. However, you can make the attack ineffective.

1. The Silver Bullet: Group Managed Service Accounts (gMSA)

This is the most effective mitigation. A gMSA is a special type of AD account where Windows manages the password.

  • The password is a 240-byte complex random string.
  • It rotates automatically every 30 days.
  • Administrators never see or know the password.

If you migrate your services (SQL, IIS, Scheduled Tasks) to run as gMSAs, Kerberoasting becomes impossible against those accounts because the passwords are mathematically uncrackable.

2. Strong Password Hygiene

For accounts that cannot be gMSAs (e.g., accounts used by 3rd party apps on Linux that don't support AD integration fully):

  • Length is King: A 15-character complex password can be cracked. A 30-character passphrase (e.g., Correct-Horse-Battery-Staple-2025) is virtually secure against current GPU capabilities.
  • Regular Rotation: Change these passwords at least annually.

3. Enforce AES Encryption

RC4 (Type 23) is much faster to crack than AES. By default, AD might still allow RC4 for backward compatibility.

  • Check the box "This account supports Kerberos AES 128 bit encryption" and "This account supports Kerberos AES 256 bit encryption" on the user object in AD.
  • Ideally, disable RC4 globally via Group Policy, though this requires thorough testing to ensure legacy apps don't break.

4. Detection via Event Logs

You should be ingesting Domain Controller logs into a SIEM (Splunk, Sentinel, ELK). Look for Event ID 4769 ("A Kerberos service ticket was requested").

Suspicious Indicators:

  • High Volume: A single user requesting 20+ service tickets in one minute.
  • Encryption Type: Requests using 0x17 (RC4) when the rest of your network uses 0x12 (AES).
  • Honeytoken Access: Any request for your honeytoken SPN.

Events to filter:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=4769)]] 
      and 
      *[EventData[Data[@Name='TicketOptions']='0x40810000']] 
      and 
      *[EventData[Data[@Name='TicketEncryptionType']='0x17']]
    </Select>
  </Query>
</QueryList>

Advanced Concepts: AS-REP Roasting

A close cousin to Kerberoasting is AS-REP Roasting. This attack targets users who have the attribute "Do not require Kerberos preauthentication" enabled. For these users, an attacker can send an AS-REQ (request for TGT) and the DC will immediately reply with an AS-REP, which contains a chunk encrypting with the user's password hash.

  • Difference: Kerberoasting targets Service Accounts (via TGS-REQ). AS-REP Roasting targets User Accounts with pre-auth disabled (via AS-REQ).
  • Tool: Rubeus asreproast or Impacket GetNPUsers.py.
  • Fix: Never enable "Do not require Kerberos preauthentication" unless absolutely necessary for legacy OTP hardware.

Conclusion

Kerberoasting is a vulnerability born from design, not error. It relies on the fundamental way Kerberos provides single sign-on convenience. In 2026, it remains a primary method for lateral movement and privilege escalation because organizations continue to create service accounts with weak, non-rotating passwords.

For the security professional, the message is simple: Identify your service accounts. Audit them. Convert them to gMSAs. If you can't, give them 30-character passwords. If you don't, an attacker eventually will, and your domain will be theirs.

Love it? Share this article:

Related Cybersecurity Guides and Tutorials: