How to Detect Kerberoasting: Signals, Logs, and Hidden Blind Spots
Kerberoasting leaves distinct traces in authentication logs that appear as normal service requests, allowing attackers to extract keys without triggering standard intrusion alerts.
Monitor for high-frequency TGS-REQ events targeting accounts with SPNs, especially those with weak password hashes. Look for requests originating from unexpected workstations and analyze the size of the returned ticket encryption data to identify extraction attempts.
Identifying the Initial Service Request
Kerberoasting begins when an attacker requests a ticket-granting service (TGS) ticket for a service account. This process is part of the standard Kerberos protocol, which handles authentication in Windows environments. The attacker does not need special privileges to request these tickets. Any authenticated user can ask the domain controller for a ticket to access a service.
The domain controller responds by encrypting the ticket with the service account's password hash. The attacker receives this encrypted ticket. They cannot decrypt it on the server, but they can take it offline. This is why the initial request looks like normal activity. It is a legitimate function of the identity management system.
You must look at the volume of requests. A single request is likely legitimate. A burst of requests for multiple service accounts in a short time suggests enumeration. The attacker is scanning for accounts that have Service Principal Names (SPNs) assigned. These SPNs allow the account to be accessed by network services.
Analyzing Ticket Encryption Types
The encryption type used for the ticket provides a strong signal of malicious intent. Modern systems default to strong encryption algorithms like AES. Older systems or misconfigured accounts may still use RC4-HMAC. This older encryption is significantly weaker and faster to crack.
Attackers prioritize RC4-HMAC tickets because they require less computational power to break. If you see a request for an RC4 ticket, investigate immediately. The request itself is legal, but the choice of encryption reveals a target of opportunity. Check the properties of the service account. If it allows RC4, the account is vulnerable to this specific attack vector.
Disabling RC4 support for service accounts removes this low-hanging fruit. However, it does not stop the attack entirely. Attackers will still target AES-encrypted tickets if they have sufficient resources. The signal shifts from "weak encryption used" to "high-volume requests for strong encryption."
| Signal | Where to look | What it may mean |
|---|---|---|
| TGS-REQ Event ID 4769 | Domain Controller Security Logs | A user is requesting a service ticket. |
| RC4-HMAC Encryption | Ticket Properties in Logs | The target account uses weak encryption, easy to crack. |
| High Request Volume | SIEM Aggregation | An attacker is enumerating SPNs across the domain. |
| Unusual Source IP | Workstation Logs | The request came from a non-server or unexpected machine. |
Correlating Source and Destination
The origin of the request matters as much as the request itself. Service tickets are typically requested by servers or applications that need to access a resource. These requests come from known, static IP addresses. When a request comes from a general-purpose workstation, it is suspicious.
Imagine a scenario where a developer's laptop requests tickets for five different database services in one minute. This behavior does not match typical user patterns. Users request tickets for file shares or email. They do not request tickets for backend services they cannot directly access.
Map the source IP to a user account. Check if that user has a reason to access those services. If the user is a helpdesk technician, they should not be requesting tickets for the payroll database. This mismatch indicates the attacker is using compromised credentials to harvest keys. The goal is to collect as many tickets as possible before moving to the next phase.
Detecting Offline Cracking Behavior
Once the attacker has the tickets, they leave the network. The cracking process happens offline, often on the attacker's own hardware. This means you will not see network traffic during the cracking phase. The silence can be misleading. It suggests the attack has stopped, but it has only moved to a different stage.
You cannot detect the cracking itself on your network. You must infer it from the previous steps. If you detect the harvesting phase, assume the tickets are being cracked. The time between harvesting and account compromise varies. It depends on the password strength and the attacker's resources.
Monitor for successful logins using the harvested accounts. If a service account logs in from an unusual location or at an unusual time, it may indicate the attacker has cracked the key. They are now using the stolen credentials to access the target service directly. This is the final step in the chain.
Common Blind Spots in Detection
Many security teams miss Kerberoasting because they focus on server logs only. They ignore the workstation logs where the requests originate. The domain controller logs the request, but the workstation logs the user's action. Without correlating both, you lack context. You see a ticket request but do not know who initiated it or why.
Another blind spot is the assumption that all service accounts are monitored. Service accounts often have different alerting rules than human user accounts. They may have broader permissions and less scrutiny. An attacker knows this. They target these accounts because they are less likely to trigger user behavior analytics alerts.
See also: Detect Employee Data Breaches: Log Signals and Blind Spots · Detecting SIM Swap Attacks Through Log Analysis and Signal Correlation
Integrating with Threat Intelligence
To improve detection, integrate findings with broader threat intelligence platforms. These tools can provide context on known attack patterns and techniques. They help you understand if the behavior you see is part of a larger campaign.
You can also use attack path analysis to visualize how an attacker moves from a low-privilege account to a service account. This helps you prioritize which accounts to secure first. By understanding the likely path, you can place sensors at critical junctions.
For deeper visibility, consider using user and entity behavior analytics. These systems learn normal behavior for each account and flag deviations. They can detect the subtle shift from normal service usage to aggressive enumeration. This reduces false positives and highlights true threats.
Hardening Against Extraction
Prevention is easier than detection. Enforce strong password policies for all service accounts. Use long, random passwords that are resistant to offline cracking. Disable RC4 encryption support where possible. This forces attackers to use stronger encryption, which takes longer to crack.
Regularly audit SPNs. Remove SPNs from accounts that do not need them. If an account does not host a service, it should not have an SPN. This reduces the attack surface. It also makes it easier to spot anomalies because the list of valid targets is smaller.
Key takeaways
- Standard authentication logs record service ticket requests that resemble Kerberoasting attempts.
- Accounts with weak password hashes or default service principals are primary targets for offline cracking.
- Detection requires correlating request frequency, source IP, and encryption type rather than relying on single-event alerts.
Kerberoasting exploits standard Kerberos functions to harvest service account keys for offline cracking. Monitor for high-frequency TGS requests with weak encryption from unexpected sources to catch this activity early.
Frequently asked questions
How do I distinguish Kerberoasting from legitimate service access?
Look for high volumes of requests from a single source or requests from workstations instead of servers. Legitimate access is usually sporadic and from known service endpoints.
Can I stop Kerberoasting by blocking port 88?
No, port 88 is used for all Kerberos traffic. Blocking it will break authentication for your entire domain. You must use detection and hardening instead.
What is the best way to secure service accounts against this attack?
Use long, complex passwords and enforce AES encryption. Regularly rotate credentials and remove unnecessary SPNs to reduce the attack surface.
Do cloud environments suffer from Kerberoasting?
No, Kerberoasting is specific to on-premises Active Directory. Cloud identities use different protocols and are not vulnerable to this specific technique.
How this guide was produced: written by the Firewall Scoop 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.
