TTechniqueActiveDirectory
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.
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.
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.
MITRE · Official MITRE ATT&CK reference for the Kerberoasting sub-technique, including detection and mitigation guidance
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.
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.
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.
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.
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.
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.