Kerberoasting

ActiveDirectoryCredentialAccessintermediateT1558.00314 min

Kerberoasting exploits a design property of Kerberos to extract service account credential material for offline cracking. This lesson explains why the attack works, what makes it possible, what the attacker gains, and how to communicate the risk clearly in interviews, reports, and stakeholder conversations.

This lesson builds on

Kerberos Authentication

Theory

Why It Matters

Kerberoasting is one of the most commonly encountered AD attack techniques because it requires nothing more than a standard domain user account and produces results that can be cracked entirely offline with no further interaction with the target environment.

It is also one of the most frequently asked interview questions in AD security. Understanding it well, including the preconditions, the mechanism, and the implications, separates candidates who memorized a tool command from those who can explain what is actually happening and why it matters.

Preconditions

Kerberoasting requires a valid domain user account (any privilege level) and at least one user-based service account with a Service Principal Name (SPN) registered in Active Directory. Computer accounts also have SPNs, but their passwords are long, random, and machine-generated, making them effectively uncrackable.

The attack targets user-based service accounts because organizations often set these passwords manually, and manual passwords are frequently weak, reused, or unchanged for years. The attacker does not need elevated privileges, does not need access to the target service, and does not need to interact with the service at all. They only need the ability to request a Kerberos service ticket from the KDC, which any authenticated domain user can do by design.

Key Concepts

Service Principal Names (SPNs) — identify which accounts run services in AD; user accounts with SPNs are the targets; computer accounts with SPNs are not viable targets because their passwords are long and random
TGS ticket request — any authenticated domain user can request a TGS ticket for any SPN; the KDC does not check whether the user is authorized to use the service before issuing the ticket
Encrypted ticket material — the TGS ticket's encrypted portion uses the service account's password hash as the key; if the password is weak, the ticket can be cracked offline
Offline cracking — generates no authentication events in the domain; the attack is difficult to detect through traditional login monitoring
Weak service account passwords — service account passwords are often weak because they are set manually, rarely rotated, and sometimes shared across environments; this is what makes the attack practical, not a flaw in Kerberos itself
Targeted Kerberoasting — a variant where an attacker with write access to an account (e.g., GenericAll or GenericWrite) sets an SPN on a target user, requests a ticket, cracks it, and then removes the SPN

Why It Works

When a domain user requests access to a service, the KDC issues a Ticket Granting Service (TGS) ticket encrypted with the target service account's secret key, which is derived from the account's password hash. This is by design: the ticket must be encrypted with the service's key so only that service can decrypt it. But Kerberos does not verify that the requesting user actually intends to use the service.

Any domain user can request a TGS ticket for any SPN in the directory. The KDC issues the ticket without checking whether the user has authorization to use the service. The authorization check happens later, at the service itself.

This means an attacker can request a ticket, receive the encrypted material, and never present it to the service. Instead, they take the encrypted ticket offline and attempt to recover the service account's password through brute-force or dictionary attacks against the encrypted portion. If the service account has a weak or guessable password, the attacker recovers it. The entire cracking process happens offline, generating no additional authentication events in the domain.

What the Attacker Gains

A successful Kerberoast yields the plaintext password of one or more service accounts. The impact depends entirely on what those service accounts can access. In many environments, service accounts are members of privileged groups (Domain Admins, Server Operators, SQL Admins) or have elevated permissions on critical systems.

A Kerberoasted service account with Domain Admin membership means the attacker has gone from a standard user to full domain compromise through a single offline cracking operation. Even when the service account is not directly privileged, its password often provides access to application servers, databases, or file shares that contain sensitive data or enable further lateral movement.

Where It Fits in the Attack Chain

Kerberoasting typically occurs after the attacker has obtained an initial foothold and at least one set of domain user credentials. It sits at the intersection of discovery and credential access: the attacker enumerates service accounts with SPNs during their AD reconnaissance and then targets those accounts for ticket extraction.

In a realistic attack chain, Kerberoasting often follows initial enumeration and precedes lateral movement or privilege escalation. It is especially common in the early-to-mid stages of an engagement because it is low-risk (no failed login attempts, no service interaction) and high-reward (direct credential recovery). It can also be used later in an engagement to expand access from one compromised area to another by targeting service accounts that bridge different parts of the environment.

Tools & Examples

Rubeus kerberoast — Windows tool that enumerates Kerberoastable accounts and requests TGS tickets in crackable format
Impacket GetUserSPNs.py — Linux tool for remote Kerberoasting using domain credentials
PowerView Get-DomainUser -SPN — PowerShell-based enumeration of accounts with registered SPNs
hashcat -m 13100 — cracks Kerberos 5 TGS-REP hashes (etype 23) using dictionary or brute-force attacks

Defender's Perspective

Use Group Managed Service Accounts (gMSAs) where possible. gMSA passwords are 120 characters, randomly generated, and automatically rotated, making Kerberoasting infeasible against them.
Enforce strong, long passwords (25+ characters) on all service accounts that cannot be converted to gMSAs.
Audit service accounts with SPNs regularly. Remove SPNs from accounts that no longer need them.
Monitor for anomalous TGS ticket requests, particularly requests for RC4-encrypted tickets (encryption type 0x17) or large volumes of TGS requests from a single user in a short period.
Reduce the privileges of service accounts. A Kerberoasted account that is not a member of privileged groups limits the blast radius.

Communication

How to Explain It in an Interview

Kerberoasting takes advantage of how Kerberos issues service tickets. Any domain user can request a TGS ticket for any SPN, and that ticket is encrypted with the service account's password hash. The KDC does not check whether the user is authorized to use the service before issuing the ticket. So an attacker with any domain account can request tickets for every service account with an SPN, take those tickets offline, and attempt to crack the password. The cracking happens entirely offline, so there are no failed login attempts to trigger alerts.

The real risk depends on what those service accounts can access. In a lot of environments, service accounts end up in privileged groups or have broad access because they were set up years ago and never reviewed. If one of those accounts has a weak password, the attacker goes from standard user to full domain compromise through a single offline cracking operation.

How to Explain It to a Stakeholder

Kerberoasting is a technique where an attacker with any employee-level domain account can extract encrypted password material for service accounts and attempt to crack those passwords offline, with no interaction with the systems those accounts protect.

The risk is that service accounts often have far more access than any individual employee, and their passwords are rarely changed. If an attacker recovers one of these passwords, they gain access to whatever that service account controls, which in many organizations includes database servers, application infrastructure, or administrative access across the domain. The attack is difficult to detect because the cracking happens on the attacker's own system, not on yours.

How It Might Appear in a Report

Finding: Kerberoastable Service Accounts with Weak Passwords. During the assessment, the operator identified multiple user-based service accounts with registered Service Principal Names (SPNs). TGS tickets were requested for these accounts using standard domain user credentials. Offline password cracking recovered the plaintext password for the svc_sqlprod account, which is a member of the Server Administrators group with local administrator access to three production database servers. The password had not been changed in over two years.

Severity: High.

Recommendation: Convert service accounts to Group Managed Service Accounts (gMSAs) where possible. For remaining accounts, enforce passwords of at least 25 characters and implement regular rotation. Audit privileged group memberships for all service accounts and remove unnecessary access.

Common Weak Answers

Describing Kerberoasting as 'cracking Kerberos' without explaining what is actually being cracked. The protocol itself is not broken. The vulnerability is that service tickets are encrypted with account passwords, and weak passwords can be recovered.
Saying 'you run Rubeus and get hashes' without explaining why the KDC issues the ticket, what the encrypted material represents, or why any domain user can request it.
Claiming Kerberoasting always leads to Domain Admin. The actual impact depends entirely on the privileges of the cracked service account. Some service accounts have no meaningful access at all.
Ignoring preconditions. Stating the attack works 'if you have access' without specifying that you need an authenticated domain user account and that the target must be a user-based service account with a registered SPN.
Not mentioning that the cracking is offline. This is the core reason the attack is stealthy and difficult to detect through traditional means.

Likely Follow-Up Questions

Why are computer account SPNs not viable Kerberoasting targets?
What makes Kerberoasting difficult to detect, and what monitoring would you recommend?
How would you explain the difference in risk between a Kerberoasted service account that is a Domain Admin versus one that only has access to a single application server?
What is targeted Kerberoasting, and what additional access does it require?
If you found Kerberoastable accounts during an assessment but could not crack any of the passwords, would you still report it? Why or why not?

Study Kit