Kerberoasting is a well-known Active Directory credential access attack that abuses the way Kerberos handles authentication for services. Instead of directly attacking a user’s password, an attacker with valid domain access can request Kerberos service tickets for accounts associated with Service Principal Names (SPNs) and attempt to crack those tickets offline.
The technique is especially important because the initial request can look like legitimate Kerberos activity. A normal domain user may be allowed to request a service ticket, so simply requesting a ticket does not automatically indicate compromise. The security problem becomes much more serious when service accounts use weak, old, reused, or poorly managed passwords.
MITRE ATT&CK currently tracks Kerberoasting as T1558.003, under the “Steal or Forge Kerberos Tickets” technique. The technique belongs to the Credential Access tactic and specifically targets Windows environments.
For security teams, understanding Kerberoasting is important because compromised service-account credentials can sometimes provide access far beyond the original account’s intended purpose.
What Is Kerberoasting?
Kerberoasting is an attack technique in which an authenticated domain user requests Kerberos Ticket Granting Service (TGS) tickets for services associated with SPNs.
The attacker then obtains the service-ticket material and attempts to recover the service account’s password through offline password cracking.
The important point is that the attacker does not need to continuously communicate with the Domain Controller while testing password guesses. Once the relevant ticket material has been obtained, password guessing can be performed offline.
MITRE describes Kerberoasting as abuse of a valid Kerberos Ticket Granting Ticket (TGT), or potentially captured Kerberos traffic, to obtain TGS tickets that may be vulnerable to offline brute-force attacks.
This makes Kerberoasting different from traditional online password guessing.
An online password attack repeatedly sends authentication attempts to a service. Kerberoasting can shift much of the password-cracking activity away from the target environment.
Understanding Kerberos and SPNs
Before understanding the attack, it helps to understand two important Active Directory concepts: Kerberos and Service Principal Names.
Kerberos is the primary authentication protocol used in modern Windows domain environments. It uses tickets instead of repeatedly sending a user’s password to every service.
At a high level, Kerberos involves:
- The client
- The Key Distribution Center (KDC)
- The requested service
- A Ticket Granting Ticket (TGT)
- A Ticket Granting Service ticket (TGS)
The KDC operates through the Active Directory domain controller and helps issue tickets that allow authenticated users to access network services.
What Is an SPN?
A Service Principal Name (SPN) is a unique identifier for a service instance.
Microsoft explains that Kerberos uses SPNs to associate a service instance with the account used to sign in to that service.
An SPN can represent services such as:
- SQL Server
- Web applications
- File services
- Custom enterprise applications
- Database services
- Other Kerberos-enabled services
For example, an organization might have a service account running a database service. That account could have an SPN registered in Active Directory.
The SPN effectively tells Kerberos which account is responsible for a particular service.
Microsoft documents SPNs as part of the Active Directory service-account authentication process and provides the setspn utility for viewing and managing them.
Why Are Service Accounts Targeted?
Service accounts are attractive targets because they often have characteristics that make them more valuable than ordinary user accounts.
A service account may:
- Run continuously
- Have access to important servers
- Have permissions to databases
- Run enterprise applications
- Have access to network resources
- Be configured with an SPN
- Remain active for long periods
- Have historically been configured with long-lived passwords
The biggest security problem is not the existence of service accounts. Properly designed service accounts are an important part of enterprise infrastructure.
The problem occurs when a service account has excessive privileges combined with a weak or poorly managed password.
For example, imagine a company has an account called svc-database that runs a business-critical SQL service. If the account has a weak password and excessive permissions, successfully recovering that password could give an attacker a path into sensitive systems.
MITRE recommends minimizing service-account privileges and specifically warns against placing service accounts in highly privileged groups such as Domain Administrators unless absolutely necessary.
How Does a Kerberoasting Attack Work?
A simplified Kerberoasting attack can be understood in several stages.
1. The Attacker Gains Domain Access
The attacker first needs some level of valid access to the Active Directory environment.
This could happen after:
- Phishing
- Malware infection
- Credential theft
- Password reuse
- Compromise of a workstation
- Another initial-access technique
Kerberoasting is therefore often not the first step of an intrusion.
It can become a follow-on technique after an attacker has obtained a normal domain account.
2. The Attacker Identifies SPNs
The attacker looks for accounts that have registered SPNs.
These accounts are interesting because Kerberos service tickets can be requested for their associated services.
From a defensive perspective, this makes SPN inventory an important part of Active Directory security.
Security administrators should know:
- Which accounts have SPNs
- Which services they operate
- Who owns those accounts
- What permissions they have
- How their passwords are managed
- Whether the accounts are still required
3. A TGS Request Is Made
The attacker requests a service ticket for a selected SPN.
Under normal circumstances, this is legitimate Kerberos functionality.
A user requesting access to a service needs a service ticket, so a TGS request by itself is not proof of malicious activity.
The difference is usually found in behavior and context.
For example, an account suddenly requesting tickets for many unrelated services may deserve investigation.
4. The Ticket Is Obtained
The resulting service ticket contains encrypted material associated with the service account.
Historically, tickets using RC4-HMAC encryption have been particularly relevant to Kerberoasting because the service account’s password-derived key can be attacked offline.
MITRE specifically identifies Kerberos 5 TGS-REP encryption type 23, associated with RC4, as a potential source of crackable material.
Modern environments should therefore reduce unnecessary use of legacy encryption.
5. Offline Password Cracking
The attacker can attempt password recovery against the obtained ticket material without repeatedly authenticating against the domain.
This is one of the reasons Kerberoasting can be dangerous.
If the service account password is:
- Short
- Predictable
- Based on a company name
- Based on a service name
- Reused
- Very old
- Present in password dictionaries
the chances of successful recovery increase.
A strong, randomly generated password can make offline cracking substantially more difficult.
6. The Recovered Credential May Be Abused
If the password is successfully recovered, the attacker now has credentials for the service account.
The impact depends entirely on the account’s permissions.
A low-privilege service account might provide limited access.
A highly privileged service account could provide a much more serious path toward:
- Lateral movement
- Privilege escalation
- Access to sensitive applications
- Persistence
- Additional credential theft
MITRE notes that cracked service-account credentials can enable Valid Accounts and potentially support persistence, privilege escalation, and lateral movement.
A Simple Kerberoasting Example
Consider a fictional company called ExampleCorp.
The organization has:
- An Active Directory domain
- Several Windows servers
- A SQL Server environment
- A service account called
svc-sql - An SPN associated with that service account
An attacker compromises an ordinary employee workstation and obtains a legitimate domain account.
The attacker then performs Active Directory reconnaissance and discovers the SQL service account.
The attacker requests a Kerberos service ticket associated with the SPN.
The request itself may appear legitimate because domain users are normally allowed to request service tickets.
The attacker extracts the relevant ticket material and performs password cracking offline.
Suppose the service account uses a predictable password based on the company’s name and the current year.
The password is recovered.
The attacker can now authenticate as the service account and investigate what resources that account can access.
If svc-sql has unnecessary administrative privileges, the initial Kerberoasting event can become the starting point for a much larger compromise.
This example demonstrates an important security principle:
The danger of Kerberoasting depends heavily on service-account password strength and privilege.
Kerberoasting vs. AS-REP Roasting
Kerberoasting and AS-REP Roasting are often confused because both involve Kerberos and offline password attacks.
They are not the same technique.
| Feature | Kerberoasting | AS-REP Roasting |
|---|---|---|
| MITRE ATT&CK | T1558.003 | T1558.004 |
| Primary target | Service accounts with SPNs | Accounts without Kerberos preauthentication |
| Main ticket | TGS | AS-REP |
| Requires SPN | Generally yes | No |
| Main weakness | Weak service-account password | Disabled Kerberos preauthentication |
| Attack stage | Service-ticket request | Authentication request |
MITRE classifies AS-REP Roasting separately as T1558.004. The technique abuses accounts configured without Kerberos preauthentication, allowing authentication responses to be obtained for offline password cracking.
Understanding the difference helps security teams avoid treating every Kerberos password-cracking technique as the same problem.
Why Kerberoasting Is Dangerous
Kerberoasting is dangerous because it combines legitimate authentication functionality with weak identity-management practices.
It Can Start With a Low-Privilege Account
An attacker does not necessarily need Domain Administrator access to begin looking for service accounts.
A compromised ordinary domain account may provide enough access to request service tickets.
Cracking Can Happen Offline
Offline password attacks remove much of the protection provided by online authentication controls.
For example, account lockout policies primarily protect against repeated online authentication failures. They do not automatically prevent an attacker from testing password candidates against previously obtained ticket material.
Service Accounts Can Be Highly Privileged
Some legacy environments assign broad permissions to service accounts because administrators want applications to “just work.”
That approach creates unnecessary risk.
If the account is compromised, those permissions become available to the attacker.
Old Accounts Can Remain Forgotten
Organizations frequently change applications without immediately removing every associated service account.
An account created years ago may still have:
- An SPN
- A valid password
- Excessive permissions
- Access to sensitive systems
Regular account reviews help identify this type of exposure.
Detecting Kerberoasting Attacks
Detection should focus on unusual Kerberos behavior rather than treating every TGS request as malicious.
One of the most useful Windows events is Event ID 4769, which records Kerberos service-ticket requests.
MITRE’s current Kerberoasting detection strategy recommends looking for anomalous TGS requests, including unusual numbers of requests in a short period, suspicious targeting of service accounts, and RC4 encryption usage where stronger encryption would normally be expected.
Indicators Security Teams Should Monitor
Useful detection signals include:
- A user requesting an unusual number of TGS tickets
- Requests for services the account does not normally access
- Multiple service accounts targeted within a short time
- RC4-based Kerberos requests in environments where AES is expected
- Unusual service-ticket activity from workstations
- Suspicious PowerShell or security-tool activity near Kerberos events
- Abnormal authentication followed by lateral movement
Context matters.
A backup server or monitoring system may legitimately request many service tickets.
A normal employee workstation suddenly requesting tickets for dozens of unrelated services is more suspicious.
Event ID 4769
Event 4769 is particularly useful for hunting Kerberoasting activity.
Security teams can establish baselines for:
- Requesting account
- Target service
- Encryption type
- Request frequency
- Source workstation
- Time of day
MITRE recommends correlating Event ID 4769 with other Windows security telemetry, including process and logon events, to improve detection quality.
How to Prevent Kerberoasting
There is no single setting that eliminates Kerberoasting risk.
The strongest defense combines identity management, password security, encryption, least privilege, monitoring, and regular Active Directory hygiene.
Use Strong Service Account Passwords
Service-account passwords should be long, random, unique, and managed securely.
Avoid passwords based on:
- Company names
- Application names
- Server names
- Seasons
- Years
- Common words
- Repeated patterns
MITRE recommends strong service-account password policies and notes that long passwords can significantly improve resistance to cracking.
Prefer Group Managed Service Accounts
Where supported, consider Group Managed Service Accounts (gMSAs).
gMSAs allow Windows to manage complex passwords automatically instead of requiring administrators to manually maintain static service-account passwords.
This can reduce the risk created by predictable or forgotten credentials.
The goal is to remove unnecessary human involvement from service-account password management wherever practical.
Reduce Service Account Privileges
A service account should have only the permissions required for its job.
For example, a database service account that needs access to a specific database should not automatically become a local administrator across dozens of servers.
Least privilege limits the impact of credential compromise.
MITRE specifically recommends limiting service-account permissions and avoiding unnecessary membership in privileged groups.
Prefer Strong Kerberos Encryption
Organizations should reduce reliance on legacy Kerberos encryption where possible.
MITRE recommends enabling AES or another stronger encryption algorithm instead of RC4 where practical.
However, encryption changes should be planned carefully.
Legacy applications may depend on older configurations, so security teams should inventory applications and test compatibility before making domain-wide changes.
Audit SPNs Regularly
SPNs should be reviewed as part of normal Active Directory security maintenance.
Microsoft’s setspn tooling can be used by administrators to inspect and manage SPNs.
Organizations should identify:
- Accounts with SPNs
- Unused service accounts
- Duplicate or outdated SPNs
- Service accounts with excessive permissions
- Accounts using legacy authentication settings
Removing unnecessary SPNs and accounts reduces the attack surface.
Rotate Service Account Credentials
Service-account passwords should not remain unchanged indefinitely.
Where automated password management is unavailable, organizations should establish a controlled rotation process.
Password rotation becomes particularly important after:
- Employee or administrator changes
- Application migrations
- Security incidents
- Credential exposure
- Service ownership changes
Monitor Active Directory Continuously
Security monitoring should identify unusual authentication patterns rather than relying only on static indicators.
A SIEM can correlate:
- Event 4769
- Event 4624
- Event 4648
- Event 4672
- Process telemetry
- PowerShell activity
- Endpoint alerts
- Authentication anomalies
MITRE’s detection guidance specifically recommends correlating Kerberos ticket activity with other security events to identify suspicious behavior.
Conduct Regular Active Directory Security Assessments
A security assessment can identify service accounts that internal administrators may have overlooked.
During an authorized assessment, testers can review:
- SPNs
- Service accounts
- Account privileges
- Kerberos configuration
- Encryption types
- Password-management practices
- Authentication logs
- Lateral movement opportunities
Organizations that need professional security assessments can also consider VAPT services as part of a broader security-testing program.
Tools Commonly Associated With Kerberoasting
Security professionals may encounter several tools when studying or investigating Kerberoasting.
Rubeus
Rubeus is a Windows-based tool focused on Kerberos interaction and is frequently discussed in Active Directory security research.
MITRE lists Rubeus as a tool associated with Kerberoasting activity.
Impacket
Impacket contains modules that interact with Windows networking and Active Directory protocols.
MITRE specifically identifies GetUserSPNs as an Impacket capability associated with obtaining SPNs and producing ticket material suitable for password-cracking workflows.
PowerShell-Based Tools
Security researchers and penetration testers have historically used PowerShell tooling to demonstrate Kerberoasting.
MITRE documents PowerSploit’s Invoke-Kerberoast as an example of tooling used for this technique.
These tools have legitimate uses in authorized penetration testing, security research, and defensive validation. They should only be used against systems for which the tester has explicit authorization.
For people building practical Active Directory skills, hands-on labs can provide a safer environment for learning security concepts.
Kerberoasting in Penetration Testing
Kerberoasting is an important technique for penetration testers because it demonstrates how a seemingly ordinary domain account can become useful for credential discovery.
A professional assessment should not stop at proving that a ticket can be requested.
The tester should determine:
- Which service accounts are exposed.
- Whether weak credential practices exist.
- Whether the accounts have excessive privileges.
- Whether legacy encryption is being used.
- Whether defensive monitoring detects suspicious activity.
- What business impact could result from compromise.
The final report should focus on risk and remediation rather than simply listing tools or commands.
For example, finding a service account with an SPN is not automatically a critical vulnerability.
Finding an SPN-linked service account with a weak password and Domain Administrator privileges is a very different situation.
Common Mistakes That Increase Kerberoasting Risk
Giving Service Accounts Domain Administrator Rights
This is one of the most serious configuration mistakes.
A service normally does not need the same privileges as a domain administrator.
Using Human-Created Passwords
Passwords such as Company@123, SQLServer2026!, or application-name variations are poor choices for long-lived service accounts.
Never Rotating Credentials
A service account created years ago should not automatically retain the same password forever.
Ignoring Legacy Encryption
RC4 usage should be investigated in environments where AES is expected.
Failing to Monitor TGS Requests
If security teams do not collect and analyze relevant domain-controller logs, suspicious Kerberos activity can be difficult to identify.
Keeping Unused Accounts
Unused service accounts increase the number of potential attack paths without providing business value.
Kerberoasting and the Modern Active Directory Threat Landscape
Active Directory remains a major target because it often sits at the center of enterprise identity and access management.
Modern intrusions frequently involve multiple stages rather than a single vulnerability.
An attacker may initially compromise a workstation, obtain domain credentials, perform reconnaissance, target service accounts, move laterally, and eventually seek privileged access.
Kerberoasting can fit into this broader attack chain as a credential-access technique.
CISA has previously documented Kerberoasting among techniques used by Russian state-sponsored actors and recommended strong service-account passwords, least privilege, and monitoring of successful Kerberos TGS requests.
That makes Kerberoasting relevant not only to penetration testers but also to SOC analysts, identity administrators, threat hunters, and incident responders.
Kerberoasting Security Checklist
Organizations can use the following checklist to reduce exposure:
- Inventory all accounts with SPNs.
- Remove unused service accounts.
- Remove unnecessary SPNs.
- Use long, random service-account passwords.
- Prefer gMSAs where appropriate.
- Rotate legacy service-account credentials.
- Apply least privilege.
- Remove unnecessary Domain Admin membership.
- Prefer AES over legacy RC4 where compatible.
- Monitor Event ID 4769.
- Baseline normal TGS-request behavior.
- Investigate unusual bursts of service-ticket requests.
- Correlate Kerberos events with endpoint telemetry.
- Review service-account permissions regularly.
- Test detection through authorized security assessments.
Frequently Asked Questions
What is a Kerberoasting attack?
A Kerberoasting attack abuses Kerberos service-ticket functionality to obtain TGS ticket material associated with SPN-enabled service accounts. An attacker can then attempt to crack the material offline to recover the service-account password.
Does Kerberoasting require Domain Administrator privileges?
No. An attacker with valid domain credentials may be able to request Kerberos service tickets for SPNs. The eventual impact depends on whether the targeted service-account credentials can be recovered and what permissions that account has.
What is an SPN in Active Directory?
A Service Principal Name is a unique identifier for a service instance. Kerberos uses SPNs to associate a service with the account under which that service operates.
Is Kerberoasting the same as AS-REP Roasting?
No. Kerberoasting targets service tickets associated with SPNs, while AS-REP Roasting targets accounts configured without Kerberos preauthentication. MITRE tracks them separately as T1558.003 and T1558.004.
How can organizations prevent Kerberoasting?
The most effective measures include strong and unique service-account passwords, gMSAs where appropriate, least privilege, reduced use of legacy encryption, regular SPN reviews, credential rotation, and monitoring for unusual TGS requests.
Can Microsoft Defender detect Kerberoasting?
Microsoft security products can contribute to detecting suspicious identity and Kerberos activity. More broadly, security teams should monitor Domain Controller events and correlate TGS requests with endpoint and authentication telemetry. MITRE’s current detection guidance highlights Event ID 4769 and related activity as useful signals.
Why are service accounts important in Kerberoasting?
Service accounts frequently run important enterprise services and may have SPNs. If their passwords are weak and their permissions are excessive, compromising one can provide an attacker with access to valuable systems.
Is Kerberoasting still relevant today?
Yes. Kerberoasting remains a documented Active Directory credential-access technique in the MITRE ATT&CK framework. Modern defenses can reduce the risk through stronger password management, AES encryption, least privilege, service-account modernization, and behavioral monitoring.
Conclusion
Kerberoasting demonstrates an important lesson in Active Directory security: legitimate authentication functionality can become dangerous when identity management is weak.
The attack does not depend on breaking Kerberos itself. Instead, attackers abuse normal service-ticket functionality to obtain material that may be attacked offline.
The biggest risks usually come from the surrounding configuration: weak service-account passwords, excessive privileges, outdated accounts, unnecessary SPNs, and legacy encryption.
Security teams should therefore treat service-account management as an important part of Active Directory defense.
Start by identifying every SPN-linked account, reviewing its privileges, strengthening or automating its password management, removing unnecessary accounts, and monitoring Kerberos activity.
For security professionals looking to strengthen their practical skills, cyber security training and cyber security labs can complement hands-on Active Directory and penetration-testing practice.
For organizations, PentestHint can be used as a resource for security testing and VAPT-related services.
