Kerberoasting is an attack where adversaries request service account tickets from a domain controller. Because these tickets are encrypted with the service account’s password hash, attackers can crack them offline. The risk lies in weak passwords, not in the protocol itself.
The Library Key Analogy
Imagine a large library where you need a key card to enter the reference section. You do not carry the master key. Instead, you ask the librarian for a temporary pass. The librarian checks your ID, confirms you are allowed in, and hands you a sealed envelope. This envelope contains the access rights for that specific section.
In this scenario, the envelope is the ticket. The seal is the encryption. You cannot open it yourself. The reference desk staff can, because they hold the master key for that section. If someone steals the envelope, they cannot open it without the master key. However, if the master key is a simple word like "Open," they can try every word in the dictionary until the seal breaks.
How the Protocol Works
In a Windows domain environment, this library is your network. The librarian is the Key Distribution Center, a service on the domain controller that issues tickets. When a computer or user needs to access a service, such as a database or a file server, it requests a ticket.
This ticket is called a Kerberos ticket. It is encrypted using a secret key derived from the service account’s password. The service account is the identity of the application, not a human user. The domain controller sends the encrypted ticket back to the requester. The requester cannot read the contents. They can only present it to the service. The service decrypts it to verify the identity.
The Offline Attack Vector
The vulnerability exists in the encryption method for service tickets. The ticket is encrypted with the service account’s password hash. This allows the service to decrypt the ticket without contacting the domain controller. An attacker who intercepts this ticket can take it offline.
They do not need to interact with the network again. They can run a program that tries millions of passwords per second. This is called offline cracking. Because the attacker controls the speed and volume of guesses, they can try complex passwords rapidly. If the service account password is weak, the attacker recovers the plaintext password. They now have full access to that service.
Why Detection Is Difficult
This attack is insidious because it uses legitimate protocols. The request for a ticket looks identical to a normal user accessing a service. There is no malware signature. There is no unusual network port. The traffic appears benign.
This is why security telemetry must be tuned carefully. Standard logs show a successful ticket request. They do not show the intent. Attackers often request tickets for many service accounts at once. This pattern is unusual. Sigma rules can help identify this behavior by looking for a high volume of ticket requests from a single user or computer in a short time.
The Human Factor and Service Accounts
Service accounts are often created by administrators who prioritize convenience over security. They may set a simple password to make it easier to remember or to script automation. They may never change that password. This creates a low-hanging fruit for attackers.
Once an attacker has a foothold in the network, they look for these accounts. They do not need to steal a user’s password. They just need to request the ticket. This lowers the barrier to entry. It allows attackers with limited access to escalate their privileges. This increases attacker dwell time because they can move laterally without being detected.
See also: Process Injection Mechanics: Step-by-Step Execution Flow · Operational Threat Intelligence for Small Business Security
Simple Safety Habits
You cannot change the Kerberos protocol. You can, however, change the strength of the keys. The most effective defense is to use strong, complex passwords for service accounts. These should be long, random, and unique. They should not be based on dictionary words or common patterns.
Regularly rotate these passwords. Monitor for unusual ticket requests. Use threat hunting to look for patterns that deviate from the norm. If a user account requests a ticket for a service it never uses, that is a red flag. Investigate immediately. Do not ignore anomalies.
Mini Glossary
| Term | Plain meaning |
|---|---|
| Kerberos | An authentication protocol that uses tickets to verify identities. |
| Ticket | A cryptographically sealed message granting access to a specific service. |
| Service Account | A non-human identity used by software to interact with the network. |
| Offline Cracking | Trying passwords against a captured ticket without network interaction. |
| Key Distribution Center | The server component that issues and manages Kerberos tickets. |
| Domain Controller | The server that manages user accounts and authentication in a network. |
Try This Now
- Audit service account passwords. Identify all service accounts in your environment. Check their password complexity and age. Replace any weak passwords with long, random strings.
- Monitor ticket request volume. Configure your logging to track the number of ticket requests per user. Set alerts for sudden spikes in requests, which may indicate enumeration.
- Review access rights. Ensure service accounts have only the permissions they need. Limit the number of services that can be accessed by each account to reduce the attack surface.
Key takeaways
- Service accounts with weak passwords are vulnerable to offline password cracking.
- The attack uses legitimate authentication requests, making it hard to distinguish from normal traffic.
- Monitoring for ticket requests to service accounts helps detect this specific threat early.
Kerberoasting exploits weak service account passwords through legitimate ticket requests. Strengthen passwords and monitor for unusual ticket activity to mitigate this risk.
Frequently asked questions
Does Kerberoasting work on non-Windows systems?
Kerberos is used in many environments, but Kerberoasting specifically refers to the Windows implementation. Other systems may have similar vulnerabilities in their ticket encryption.
Can I prevent Kerberoasting with a firewall?
No, the traffic is internal and legitimate. Firewalls do not inspect the content of the tickets. Detection requires internal monitoring and log analysis.
Is using AES encryption enough?
AES is stronger than older encryption methods, but it is not immune to cracking if the password is weak. Strong passwords remain the primary defense.
How do I know if I have been targeted?
Look for patterns in your logs. Unusual volumes of ticket requests or requests for services that do not exist are strong indicators of reconnaissance.
How this guide was produced: written by the Malware Chronicle editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
