Evidence of Targeted Kerberoasting is usually found in directory and authentication logs that show repeated service ticket requests for specific accounts, especially when the pattern is narrow and suspicious. Look for unusual Kerberos activity from a single source, requests against high-value service accounts, and accompanying reconnaissance. Correlate with account attributes and endpoint activity to separate abuse from legitimate service behaviour.
What logs best reveal targeted Kerberoasting?
Directory and Kerberos authentication logs are the primary sources, because targeted kerberoasting shows up as repeated service ticket requests aimed at a narrow set of accounts. The strongest signal is not volume alone, but repetition against specific high-value service principals from one source, especially when the activity does not fit the usual service pattern.
Kerberos logs are useful because they preserve the request path, ticket-granting behavior, and account context needed to distinguish normal service use from focused enumeration. Directory logs add the surrounding identity detail, such as service account attributes, naming patterns, group membership, delegation settings, and whether the account is the sort of target an attacker would deliberately pursue.
To make those logs actionable, Kerberos Security Guide is the best starting point when you need to interpret ticket-request patterns, and the Service Account Security Guide helps you decide which accounts are unusually exposed or overvalued by attackers.
What patterns in the logs separate abuse from normal service behavior?
Targeted Kerberoasting usually looks narrower than broad password spraying or noisy enumeration. Watch for repeated ticket requests for the same service account, requests clustered around a small set of privileged or legacy accounts, and activity that comes from a workstation or host that would not normally initiate those requests. The pattern often appears after reconnaissance, not in isolation.
Another useful distinction is whether the source has a legitimate business reason to contact the service. A well-behaved application host usually shows stable, repeatable Kerberos behavior. A targeted attack is more likely to show bursts, odd timing, unusual source diversity, or requests that are inconsistent with the endpoint’s role. Correlating directory events with endpoint telemetry makes the difference between a service retry loop and a credential collection attempt.
For a practitioner view of how identity attacks fit together, the Identity Threat Detection and Response Guide is useful because it ties Kerberos abuse to the broader detection problem, not just the single log event.
External references that support this interpretation include the NIST SP 800-53 Rev 5 Security and Privacy Controls for audit and authentication logging, and the MITRE ATT&CK Enterprise Matrix for mapping Kerberoasting-style activity to credential access behavior.
How should you investigate and confirm the finding?
Start by correlating the authentication trail with the account inventory. Confirm whether the targeted accounts are service principals, whether they are high-value, whether they have long-lived passwords or weak legacy settings, and whether the requesting host has an expected relationship to those services. Then check adjacent logs for reconnaissance, failed access attempts, or endpoint behavior that suggests the source was testing or collecting rather than operating normally.
If the pattern is suspicious, preserve the relevant logs before changing anything, because later remediation can erase the sequence you need for attribution and scope. The investigation should answer three questions: which accounts were targeted, which source initiated the requests, and whether any other compromise indicators appeared before or after the Kerberos activity. If you can answer those, you can judge whether the event is curiosity, misconfiguration, or active abuse.
Risk and Threat Considerations
Targeted Kerberoasting is dangerous because the attacker is not hunting broadly, but selecting accounts that are more likely to yield usable material. That makes the signal subtle and the damage asymmetric: a small amount of authenticated activity can expose accounts that support many downstream systems.
Failure mechanism: An attacker requests service tickets for specific accounts, then uses the resulting material offline or in follow-on access attempts. If the environment lacks alerting on repeated narrow requests or does not correlate Kerberos events with source-host context, the behavior can blend into ordinary service traffic.
Impact: A successful compromise of one service account can expand access, enable lateral movement, and create persistence that is hard to spot because the activity may still look like valid Kerberos use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Kerberos abuse is confirmed through authentication and directory audit logs. |
| AU-6 — Audit Record Review, Analysis, and Reporting | The question hinges on correlating suspicious ticket patterns across logs. | |
| IA-2 — Identification and Authentication (Organizational Users) | Targeted Kerberoasting abuses authenticated service access paths. | |
| Recommendation — Log Kerberos requests and identity events needed to detect repeated ticket abuse. Review authentication and directory logs for repeated, narrow service-ticket requests. Validate and monitor account authentication paths that support service-ticket issuance. | ||
| MITRE ATT&CK | T1558.003 — Kerberoasting | The subject is evidence of Kerberoasting activity in logs. |
| Recommendation — Map ticket-request patterns to Kerberoasting and hunt for associated reconnaissance. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection depends on collecting and reviewing directory and Kerberos logs. |
| Recommendation — Centralize and review Kerberos and directory logs for suspicious ticket activity. | ||
Practitioner Guidance
What to prioritize: Triage the highest-value service accounts first, especially those with broad privileges, legacy settings, or long password lifetimes. Those accounts are the ones most worth protecting and the ones most likely to be targeted in a narrow attack.
What to verify: Confirm that the source host, user, and timing are consistent with the service’s normal operating pattern. If the source is not a known application server or the request cadence is unusual, treat the event as suspicious until proven otherwise.
What good looks like: You can explain why each repeated ticket request occurred, tie it to a legitimate workload when appropriate, and show that the account is monitored for abuse as well as for availability.
Practitioner takeaway: The key judgment is not whether Kerberos traffic exists, but whether the request pattern is narrow enough, unusual enough, and contextually inconsistent enough to justify treating it as targeted collection activity.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org