Kerberos is one of the foundations of authentication in Active Directory.
It allows users and services to authenticate securely without sending passwords across the network. It is reliable, scalable, and deeply integrated into Windows domains.
But Kerberos also depends heavily on how service accounts are configured.
And that is where Kerberoasting becomes dangerous.
Kerberoasting is a post-exploitation technique used to target service accounts in Active Directory environments. It abuses legitimate Kerberos behavior to request service tickets that can later be cracked offline.
No malware is required on the domain controller.
No vulnerability needs to be exploited.
No password needs to be transmitted over the network.
The attacker only needs a valid domain account and access to a service ticket encrypted with material derived from the target service account password.
That is why Kerberoasting remains one of the most effective attacks against poorly managed Active Directory environments.

What Is Kerberoasting?

Kerberoasting targets domain accounts that have a Service Principal Name (SPN) configured.
SPNs are used by Kerberos to associate a service with an account in Active Directory. For example, an SQL Server instance, a web application, or an internal enterprise service may run under a dedicated domain account with one or more SPNs assigned.
Any authenticated domain user can request a Kerberos service ticket for an SPN.
That behavior is normal.
The problem is that part of the service ticket is encrypted using a key derived from the service account password.
If an attacker requests that ticket and extracts it, they can attempt to crack it offline.
The domain controller is no longer involved.
There are no repeated authentication attempts against Active Directory.
There is no account lockout.
Only one valid ticket request may be enough.
If the service account uses a weak, predictable, reused, or human-created password, the attacker may eventually recover it.
Once that happens, the attacker owns the service account.
The real impact depends on what that account can access.

A Bit of Kerberos Theory

To understand Kerberoasting, it is useful to understand how Kerberos authentication works at a high level.
Kerberos is the default authentication protocol in Windows domains. It allows secure authentication between users and services through a trusted authority called the Key Distribution Center (KDC), which runs on domain controllers.
The process involves three main phases.
First, the client authenticates to the KDC and receives a Ticket Granting Ticket (TGT).
This happens during the AS-REQ / AS-REP exchange.
Second, when the client needs to access a specific service, it uses the TGT to request a Service Ticket (TGS) for that service.
This happens during the TGS-REQ / TGS-REP exchange.
Third, the client presents the service ticket to the target service and gains access if authorization checks succeed.
This is normal Kerberos behavior.
Kerberoasting abuses the second phase.
The attacker requests service tickets for SPN-enabled accounts and then attempts to crack the encrypted ticket material offline.

Service Principal Names

A Service Principal Name is a unique identifier for a service instance in Active Directory.
It tells Kerberos which account is responsible for running a specific service.
Examples include:

MSSQLSvc/dbserver01.contoso.com:1433
HTTP/webserver.contoso.com

When an SPN is registered on a domain account, that account becomes eligible to receive Kerberos service tickets.
This is necessary for many applications to work correctly.
But it also creates an attack surface.
If the account behind the SPN has a weak password, Kerberoasting can turn that configuration into a credential compromise.

Group Managed Service Accounts

Group Managed Service Accounts (gMSAs) are one of the best defenses against Kerberoasting.
Unlike traditional service accounts, gMSAs are managed by Active Directory.
Their passwords are:

• Automatically generated.
• Long and complex.
• Rotated automatically.
• Not manually known by administrators.
• Not intended for interactive logon.

This significantly reduces the risk of weak, reused, or manually stored passwords.
Where supported, gMSAs should be preferred over traditional domain service accounts.
They do not eliminate every identity risk, but they dramatically reduce the effectiveness of Kerberoasting against service accounts.

How the Attack Works

A Kerberoasting attack usually follows a predictable pattern.
First, the attacker obtains access to any valid domain account.
This does not need to be an administrator.
A standard user account is usually enough.
Next, the attacker enumerates accounts with registered SPNs. These accounts represent services that can receive Kerberos service tickets.
Then the attacker requests one or more service tickets for those SPNs.
The tickets are extracted and moved offline.
At that point, the attacker attempts to crack the encrypted ticket material using password-cracking tools.
If the password is recovered, the attacker can authenticate as the service account.
This is what makes Kerberoasting so effective.
The cracking happens offline.
The attacker does not need to continuously interact with the domain controller.
Most real-time network defenses will not see the cracking activity because it does not happen inside Active Directory.
From the domain controller’s perspective, the original ticket request may look like normal Kerberos activity.

Why Kerberoasting Is Dangerous

Kerberoasting is dangerous because service accounts are often poorly managed.
They are created for applications, scripts, databases, integrations, or legacy systems. Then they are left untouched for years because nobody wants to risk breaking production.
Common issues include:

• Passwords that never expire.
• Weak or predictable passwords.
• Passwords based on company names, seasons, years, or application names.
• Service accounts with excessive privileges.
• SPNs assigned to normal user accounts.
• Lack of account ownership.
• No regular access review.
• No monitoring of Kerberos activity.

This creates the ideal target.
A normal user account may have limited access.
A service account may have access to databases, file shares, application servers, backup systems, or administrative functions.
In some environments, service accounts are even members of privileged groups.
When that happens, Kerberoasting can become a direct path to privilege escalation.

Impact in Production Environments

The impact of Kerberoasting depends on the privileges assigned to the compromised service account.
If the account has limited permissions, the attacker may gain access only to a specific application or system.
If the account is overprivileged, the consequences can be severe.
A successful Kerberoasting attack may lead to:

• Access to sensitive applications.
• Access to databases or file shares.
• Lateral movement across servers.
• Compromise of application infrastructure.
• Privilege escalation.
• Persistence through service account credentials.
• Domain compromise in poorly segmented environments.

The worst-case scenario is not the theft of the service account password itself.
The worst-case scenario is what that account can do.
Kerberoasting turns poor service account hygiene into an identity attack path.

Detection and Monitoring

Kerberoasting is difficult to detect because it uses legitimate Kerberos functionality.
A user requesting a service ticket is not suspicious by itself.
That happens constantly in Active Directory environments.
The goal is to detect unusual patterns.
Useful indicators include:

• A user requesting service tickets for many different SPNs in a short period.
• Service ticket requests for systems the user does not normally access.
• Requests targeting privileged or sensitive service accounts.
• Kerberos activity from unusual workstations.
• Spikes in Windows Security Event ID 4769.
• Use of weaker encryption types, especially RC4.
• TGS requests followed by no normal application access.

Detection should not rely on a single event.
It should combine Kerberos logs, identity context, asset ownership, endpoint telemetry, and historical user behavior.
Security tools such as SIEM platforms and Microsoft Defender for Identity can help detect known Kerberoasting patterns, but they are most effective when service accounts are properly classified and monitored.

How to Defend Against Kerberoasting

Mitigating Kerberoasting requires both prevention and detection.
The goal is simple: reduce the number of roastable accounts, reduce the value of any ticket that can be requested, and detect abnormal Kerberos behavior early.

Use Long and Random Passwords

Traditional service accounts must use long, random, and unique passwords.
Human-generated passwords are not enough.
Avoid passwords based on:

• Company names.
• Application names.
• Seasons.
• Years.
• Keyboard patterns.
• Reused administrative passwords.

Kerberoasting is an offline attack.
That means the attacker can attempt password cracking without continuously touching Active Directory.
The stronger and longer the service account password is, the less useful the ticket becomes.

Prefer Group Managed Service Accounts

Where possible, replace traditional service accounts with gMSAs.
gMSAs automatically manage password complexity and rotation, reducing the risk of weak or reused credentials.
They also remove the need for administrators to know, store, or manually rotate service account passwords.
This is one of the most effective ways to reduce Kerberoasting exposure.

Apply Least Privilege

Service accounts should have only the permissions required for their specific function.
Avoid placing service accounts in privileged groups such as:

• Domain Admins.
• Enterprise Admins.
• Account Operators.
• Server Operators.
• Backup Operators.
• Broad local administrator groups.
• Custom groups with excessive rights.

A service account used by an application should not have administrative control over unrelated systems.
Least privilege limits the damage if the account is compromised.

Review and Clean Up SPNs

Every SPN should have a clear purpose.
Regularly review SPNs and remove those that are no longer required.
Pay attention to:

• SPNs assigned to normal user accounts.
• Duplicate SPNs.
• SPNs linked to decommissioned applications.
• SPNs associated with accounts that have no owner.
• SPNs tied to privileged accounts.

SPN hygiene is identity hygiene.
If an SPN is no longer needed, remove it.

Disable Weak Encryption Where Possible

Older Kerberos encryption types, especially RC4, make Kerberoasting easier.
Where possible, enforce modern encryption such as AES.
Before disabling legacy encryption globally, test carefully. Some older applications may still depend on weaker encryption types.
The objective is not to break production.
The objective is to remove unnecessary weak cryptography from the environment.

Rotate Service Account Passwords

Service account passwords should not remain unchanged for years.
For traditional service accounts, implement a controlled rotation process.
For modern environments, prefer gMSAs where supported.
Password rotation reduces the usefulness of credentials that may have already been exposed, cracked, or stored in unsafe locations.

Build a Service Account Inventory

You cannot protect what you cannot identify.
Every service account should have documented ownership and purpose.
At a minimum, track:

• Account name.
• Owner.
• Business purpose.
• Associated SPNs.
• Systems where it is used.
• Privileges assigned.
• Password rotation process.
• Last logon activity.
• Risk level.

This inventory is essential for both prevention and incident response.

Minimize the Damage

Kerberoasting cannot always be eliminated completely, especially in large legacy environments.
But the damage can be minimized.
Start by separating privilege tiers.
Service accounts used for standard applications should not have administrative rights over domain controllers, identity systems, backup infrastructure, or security platforms.
Next, monitor privileged service accounts closely.
Create alerts for:

• Interactive logons.
• Remote desktop activity.
• Group membership changes.
• Password changes.
• SPN modifications.
• Delegation changes.
• Authentication from unusual hosts.
• Use outside expected business patterns.

A service account should behave like a service account.
When it starts behaving like a user, investigate.

Final Thoughts

Kerberoasting is effective because it does not break Kerberos.
It uses Kerberos exactly as designed.
The real weakness is usually not the protocol.
It is weak passwords.
It is excessive privilege.
It is poor SPN hygiene.
It is old service accounts nobody wants to touch because they might break something important.
Defending against Kerberoasting means treating service accounts as critical identities.
Inventory them.
Harden them.
Monitor them.
Rotate them.
Remove what is no longer needed.
Because in Active Directory, forgotten service accounts often become the quietest path to privilege escalation.