How do you detect Kerberoasting through RC4 ticket requests?

Detect it by identifying repeated service ticket requests for many accounts where RC4 is negotiated or requested unexpectedly. A burst of Kerberos TGS requests from one account or host, especially for service principals that should use stronger encryption, is a strong signal. Prioritise accounts with SPNs, and review whether legacy RC4 support is still needed.

What RC4 ticket request patterns are the signal?

kerberoasting detection starts with the pattern, not a single event. Look for repeated Kerberos service ticket requests tied to many service principals, especially when the ticket encryption type is RC4 and that choice is unexpected for the environment. A single request is weak evidence; a concentrated burst from one source is more meaningful.

The strongest signal is a request stream that looks exploratory or systematic, such as one account or host requesting tickets for multiple SPNs in a short window. That pattern is most concerning when the targeted services should normally negotiate stronger encryption and the RC4 fallback appears only because older settings are still tolerated.

Repeated RC4 negotiation matters because it can indicate an attacker is collecting material for offline password cracking. If the service principal names are widely distributed across systems, the behaviour may also indicate an attempt to enumerate reachable services before choosing the most promising target.

How do you separate noisy RC4 use from suspicious Kerberoasting?

Not every RC4 ticket is malicious. Legacy systems, older service configurations, and interoperability exceptions can still produce RC4 on legitimate traffic, so the detection question is whether the requests are normal for that account, host, and service set. Baseline the usual encryption types, source hosts, and service principals before you alert.

Review whether the requesting principal normally touches those services, whether the volume is unusual for that workload, and whether the activity clusters around accounts with SPNs. A benign service account usually requests a narrow set of tickets in a repeatable pattern, while Kerberoasting tends to show broader service coverage than that account would ordinarily need.

If your telemetry includes Kerberos fields, use it to distinguish established application behaviour from an event sequence that is broader than the workload’s role. A workload that suddenly requests tickets for unrelated services, or one that generates an unusual number of TGS requests without a corresponding business change, deserves closer review.

What should you validate once RC4 ticketing looks suspicious?

Confirm whether the account has an SPN, whether the service really requires RC4, and whether stronger encryption is available but not being enforced. That validation matters because the best detection outcome is not only alerting, but identifying where the environment still allows weak ticket material that can be abused.

Check for signs that the account or host was already under investigation for credential exposure, password spraying, or service-account misuse. A Kerberoasting pattern is more actionable when it aligns with other identity abuse signals rather than standing alone as an isolated protocol anomaly.

When the same account repeatedly requests tickets for several services, the priority is to determine whether the account should be allowed to reach that breadth at all. If the pattern does not fit the workload, treat it as an access review and potential compromise lead, not just a logging event.

Risk and Threat Considerations

RC4 ticket requests are risky because they can expose weak service principals to offline password cracking, especially when the service account password is long-lived or poorly managed. The threat is not the ticket itself, but the fact that repeated requests can create a reusable capture set for an attacker.

Failure mechanism: An attacker requests Kerberos service tickets for SPN-bearing accounts, captures the encrypted material, and then attempts offline cracking against passwords that are still accepted by RC4-compatible services.

Impact: A successful crack can expose service account credentials, expand access to additional services, and create a path to lateral movement or privilege abuse if the account is overpermitted.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1558.003 — Kerberoasting	Covers the exact adversary technique behind RC4 service ticket abuse.
Recommendation — Map repeated RC4 TGS requests to T1558.003 and hunt for service-account targeting.
NIST SP 800-53 Rev 5	AU-6 — Audit Record Review, Analysis, and Reporting	Detection depends on reviewing Kerberos logs and unusual ticket-request patterns.
	IA-5 — Authenticator Management	Weak or long-lived service credentials make RC4 ticket abuse materially worse.
Recommendation — Correlate Kerberos audit events and alert on abnormal TGS request bursts. Rotate and govern service account authenticators when RC4 exposure is found.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Service accounts with excess access increase the impact of Kerberoasting.
	NHI-07 — Long-Lived Secrets	Kerberoasting becomes more dangerous when service credentials remain valid for long periods.
Recommendation — Reduce service-account privilege so a cracked ticket yields less reach. Shorten service credential lifetimes to limit offline-cracking exposure.

Practitioner Guidance

What to verify: Validate that the alert is tied to a real service account pattern, not a scheduled application job or a known legacy dependency. If RC4 is still present for business reasons, document the exception and the compensating control that explains why it is tolerated.

Decision rule: If the source account is requesting tickets for more SPNs than its role should require, treat the event as suspicious even before you confirm compromise. If the service can move off RC4, prioritise that change because weak ticket encryption reduces the value of any later detection.

Practitioner takeaway: Kerberoasting detection is strongest when you combine ticket volume, source concentration, and encryption type, then ask whether the service account should have been able to generate that pattern in the first place.