How can security teams detect AS-REQ roasting?

What AS-REQ roasting tells you about Kerberos exposure

AS-REQ roasting is not a single exploit signature so much as a pattern of authentication probing. The attacker is trying many user principals, usually hoping to trigger a Kerberos response that can be analysed offline. Detection works best when teams treat this as a reconnaissance and credential-attack pattern, not just isolated log noise.

The useful question is whether the source behaviour fits normal user or service activity. Bursts of pre-authentication failures, many account names from one host, and repeated attempts against accounts that should not all be in active use are the core signals. That is why Kerberos telemetry, source correlation, and failure timing matter more than any one event ID on its own.

For deeper Kerberos context, the Kerberos Security Guide is the most direct reference for understanding how AS-REQ roasting sits alongside Kerberoasting, AS-REP roasting, and other ticket-oriented abuse patterns.

What to look for in logs and detections

Focus on concentrated request patterns rather than only on failed logons. A single source that cycles through many accounts, especially with similar request timing, is more suspicious than a few random Kerberos failures distributed across the estate. The same applies when the volume is high but the identities targeted are broad and unrelated.

Correlate the authentication failures with host context, identity context, and time windows. If one workstation, jump host, or application tier suddenly becomes the origin for repeated Kerberos pre-authentication attempts, that is a stronger indicator than looking at the events in isolation. Rate-based alerts are useful here because they surface volume shifts that human review often misses.

Successful detection also depends on separating normal service churn from abuse. Some environments legitimately generate large authentication volumes, so teams should baseline by source, account class, and time of day. The point is not to alert on every failure, but to catch abnormal concentration, especially when attempts fail quickly across many accounts.

If you want a broader map of the adversary tradecraft behind these patterns, MITRE ATT&CK Enterprise Matrix helps connect Kerberos probing to credential access and lateral movement techniques.

How to reduce noise and validate suspected roasting activity

Detection improves when Kerberos failures are paired with environment controls. Rate limiting, lockout policy tuning, and alerting on suspicious pre-authentication spikes reduce the chance that a spray or roasting attempt stays quiet long enough to be useful to an attacker. Good detection logic should also suppress obvious service behaviour that is already known and trusted.

When a pattern looks suspicious, validate whether the source has any legitimate reason to query that many user principals. Check whether the host is new, unmanaged, or recently compromised, and whether the target accounts include privileged users, stale users, or accounts that should not be broadly enumerated. That validation step is important because roasting activity often blends into ordinary authentication traffic until the breadth of account targeting becomes clear.

Current guidance suggests using a layered view of authentication telemetry, not a single alert. A practical detection stack combines source correlation, failure frequency, unusual account fan-out, and follow-up review of whether the same host is involved in other suspicious authentication behaviour.

Practitioner Guidance

What to prioritise: Start with sources that generate repeated Kerberos pre-authentication failures across many accounts, then separate legitimate service churn from suspicious fan-out. That order matters because the attacker value is in breadth, speed, and repeatability, not in any one failed request.

What to verify: Confirm whether the source host, user, or service identity is expected to authenticate against that account set at all. If the pattern is novel, treat it as a potential precursor to offline password-cracking activity and inspect adjacent telemetry for broader compromise indicators.

What good looks like: Your detection should flag unusual concentration early enough that responders can contain the source, preserve evidence, and review the targeted accounts before the activity turns into follow-on access attempts.

Practitioner takeaway: AS-REQ roasting detection is strongest when teams measure fan-out and failure rate together, because the abuse pattern is about systematic account probing, not just repeated authentication errors.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?