What are the signs that Kerberos is being abused for offline password cracking?

Common warning signs include unusual service ticket requests for many SPNs, especially high-value services like SQL, followed by patterns consistent with ticket export and offline cracking. Security teams should also watch for unexpected use of legacy encryption types, repeated TGS requests from ordinary user accounts, and activity that suggests someone is enumerating service principals rather than using them normally.

How to recognise Kerberos abuse before the cracking starts

The first clue is usually volume and shape, not a single ticket. Attackers probing for Kerberoast opportunities tend to ask for many service tickets in a short period, often across a broad set of SPNs rather than only the services they would normally access. That stands out when the requester is an ordinary user account or when the request pattern does not match the user’s role or recent activity.

Legacy encryption is another strong signal. If a domain still allows weaker ticket encryption, repeated TGS activity using RC4 or other older types can indicate a deliberate attempt to obtain crackable material. In practice, this is most suspicious when the same account is generating many service ticket requests without corresponding application use.

Normal users usually consume services, they do not enumerate them. When you see requests that look like discovery, especially across high-value services such as SQL, file, or admin-oriented SPNs, treat that as a sign the activity is being collected for later offline analysis rather than for immediate access.

What makes the pattern different from ordinary Kerberos traffic

Legitimate Kerberos traffic tends to be repetitive and narrow. A user signs in, gets tickets for the services they actually need, and then reuses them in the course of normal work. Abuse looks different because the attacker is optimising for ticket harvest: many requests, many principals, little evidence of corresponding business use, and sometimes requests made from systems or sessions that do not normally host that user.

Another practical discriminator is timing. A burst of service ticket requests shortly after initial foothold, or outside the user’s usual access window, is more suggestive of collection activity. The pattern can also show up as a mismatch between the requesting account and the target service set, for example a low-privilege workstation user suddenly requesting tickets for multiple backend services.

If you are hunting at the protocol level, focus on the relationship between requester, target SPN, encryption type, and follow-on behaviour. A single request is rarely enough to prove abuse, but a cluster of requests that looks like broad sampling of service principals is far more important than one isolated ticket.

What defenders should validate in the response

Once the pattern is suspected, confirm whether the requesting account should ever talk to those services, then check whether the ticket requests line up with an expected application workflow. If they do not, the safest assumption is that the tickets were gathered for offline cracking and potential privilege escalation after password recovery.

It is also worth validating whether the account has been used to request tickets for services with weaker password hygiene or excessive privilege. Those services are often the ones that turn a cracking attempt into a domain-impacting compromise. A good response separates noisy but benign service discovery from the more serious case where the collection pattern targets privileged or high-value SPNs.

Detection improves when ticket activity is tied back to host, user, and service context rather than only event counts. That makes it easier to see whether the ticket requests came from a standard business process or from a one-off collection run meant to feed an offline attack.

Risk and Threat Considerations

Kerberos ticket harvesting matters because the attacker is not trying to break Kerberos directly, they are trying to turn a service ticket into an offline password-cracking opportunity. The real risk is that a single exposed service account can become an entry point to broader privilege abuse if the underlying password is weak or reused.

Failure mechanism: The environment permits broad service ticket requests, weak encryption, or poor visibility into SPN access patterns, so an attacker can collect crackable material without immediately tripping interactive authentication controls.

Impact: Successful cracking can expose service-account credentials, enable lateral movement, and turn a limited foothold into access to backend systems or higher-value administrative functions.

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 CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1558.003 — Kerberoasting	Directly covers Kerberos service-ticket abuse for offline cracking.
Recommendation — Hunt for unusual TGS fan-out and service-account exposure consistent with Kerberoasting.
NIST CSF 2.0	DE.CM-01 — Networks and network services are monitored to find anomalous behavior	Kerberos abuse is detected through anomalous ticket-request patterns and service access.
Recommendation — Monitor Kerberos service-ticket patterns for requester, SPN, and encryption anomalies.
NIST SP 800-53 Rev 5	AU-12 — Audit Record Generation	Kerberos abuse detection depends on generating logs for ticket requests and related events.
	IA-5 — Authenticator Management	Weak or legacy credentials increase the payoff of offline cracking after ticket capture.
	AC-6 — Least Privilege	Excessive service access broadens the impact if cracked credentials are recovered.
Recommendation — Ensure ticket-request and authentication events are logged for investigation. Rotate and strengthen service credentials to reduce offline cracking value. Limit service-account privileges to reduce blast radius after credential compromise.
CIS Controls v8	CIS-6 — Access Control Management	Service-ticket abuse becomes more dangerous when access is broad and poorly governed.
	CIS-8 — Audit Log Management	Ticket fan-out and encryption anomalies are only visible when authentication logs are retained and reviewed.
Recommendation — Restrict and review service account access paths and SPN use. Centralize and review authentication logs for anomalous Kerberos activity.

Practitioner Guidance

What to verify: Check whether the requesting principal has a legitimate business reason to request the observed SPNs, and confirm whether the requests align with the account’s normal service footprint. If the answer is no, treat the activity as suspicious even before cracking evidence appears.

Common mistake: Teams often look for a failed logon trail and miss the real tell, which is successful ticket acquisition followed by quiet offline abuse. The absence of authentication failures does not make the activity benign.

What good looks like: You should be able to distinguish normal application ticketing from collection-style bursts by account, host, service, and encryption type. Where possible, alert on unusual SPN fan-out, especially from accounts that do not normally enumerate services.

Practitioner takeaway: The best detection rule is not “many tickets,” it is “many tickets from a principal that should not be behaving like a service mapper.”