What signs indicate Kerberoasting activity in Active Directory?

How Kerberoasting Shows Up in Active Directory Traffic

Kerberoasting is often visible first as a pattern of service ticket requests rather than a single obvious event. The key clue is concentration: one account begins asking for many service tickets in a short window, often across multiple targets that do not match that user’s normal work. That makes the activity look “directory-like” while still standing out in volume and target selection.

Another useful signal is mismatch. A workstation user who suddenly requests tickets for privileged or rarely used services, especially outside normal business hours or from an unusual host, deserves scrutiny. The same is true when you see requests moving across many service principal names instead of a narrow set tied to the user’s job role. For broader context on AD hardening and privileged paths, see the Active Directory and Entra ID Hardening Guide.

Weak-encryption indicators are especially important because they tell you the attacker may be collecting tickets for offline cracking. That means the observable abuse can happen before any password is guessed. In practice, weak encryption plus high request volume is more concerning than either signal alone, because it suggests deliberate ticket harvesting rather than a noisy but benign application issue.

Which AD Behaviours Are Most Suspicious for Kerberoasting?

The strongest behavioural sign is an account repeatedly requesting service tickets for many principals in a compressed timeframe. In a healthy environment, ticket requests usually follow stable user or application patterns. Kerberoasting breaks that rhythm by driving enumeration of services that are interesting to an attacker, not necessarily to the user making the requests.

Requests aimed at unusual targets are the next clue. That includes service accounts that are not normally contacted by the user, admin-oriented services, or accounts that stand out because they are old, overprivileged, or poorly governed. A honeytoken service account is even stronger evidence, because it is intentionally created to make this pattern visible when touched.

Traffic context matters too. A single source host, one login session, or repeated requests from the same account can be benign in some application flows, but when those requests expand across many services, the pattern becomes much harder to explain operationally. If you need a deeper identity-security lens on why service accounts and inventory discipline matter, the Service Account Security Guide is the most direct companion resource.

What Detection Logic Helps Separate Kerberoasting from Normal Kerberos Use?

Detection works best when it combines volume, target rarity, and cryptographic clues. Counting ticket requests alone is not enough, because some enterprise applications legitimately generate large numbers of Kerberos requests. The more reliable approach is to baseline normal service relationships and then flag spikes, unusual SPN fan-out, and tickets that show weak-encryption characteristics.

High-confidence detection also benefits from identity context. Ask whether the requesting account normally accesses those services, whether the destination account is privileged, and whether the request source is consistent with prior behaviour. Kerberoasting becomes easier to spot when you compare the request pattern against the account’s historical profile instead of treating every ticket request as equivalent. For incident-response-oriented detection patterns, the Identity Threat Detection and Response (ITDR) Guide is a useful reference.

Weak-encryption tickets deserve special attention because they shift the risk from live exploitation to offline password cracking. That means the defender may not see a loud authentication failure sequence. Instead, the tell is often the collection of tickets themselves, followed by suspicious reuse of cracked credentials later in the environment. Microsoft’s NIST SP 800-53 Rev 5 Security and Privacy Controls provides the underlying control language for logging, access control, and auditability that supports this kind of detection.

Risk and Threat Considerations

Kerberoasting is risky because it can look like ordinary directory activity until the request pattern becomes extreme or the target choice becomes implausible. Once an attacker has harvested enough tickets, the compromise path shifts offline, which means the visible abuse may end before the real breach becomes obvious.

Failure mechanism: The attacker requests service tickets for interesting accounts, extracts material that can be cracked offline, and then uses recovered credentials to move toward higher privilege or lateral access.

Impact: A single weak service account can become an entry point to broader domain compromise, especially where privileged or long-lived accounts reuse weak passwords or have excessive access.

Practitioner Guidance

What to verify: Confirm whether the request burst is tied to a known application, scheduled job, or patching workflow before treating it as malicious. The key question is whether the requesting identity normally needs that breadth of service access.

Common mistake: Teams often look only for failed logons or password spraying and miss Kerberoasting because the attack is front-loaded as ticket collection, not immediate authentication failure.

What good looks like: You should be able to explain why each service account exists, who owns it, what it can access, and whether its encryption and password posture would still resist offline cracking if its ticket were captured.

Practitioner takeaway: The best Kerberoasting detections combine behavioural anomaly, target rarity, and ticket-strength signals, but the real control is reducing the value of any single service account through governance, least privilege, and rapid rotation.

Related resources from NHI Mgmt Group

• What are the signs that Active Directory compromise may be hiding behind normal service account activity?
• What are the signs that Active Directory attack activity is moving from initial access to wider compromise?
• How should security teams reduce Kerberoasting risk in Active Directory?
• Why does Kerberoasting remain effective in mature Active Directory environments?