How do defenders detect AS-REP Roasting attempts in authentication logs?

Why This Matters for Security Teams

AS-REP roasting is not just a password problem. It is a visibility problem that shows up in Kerberos authentication telemetry when an account can be queried without pre-authentication, producing responses that attackers can take offline and crack later. Teams that only look for failed logons miss the earlier signal: a valid request that should not exist in the first place.

This matters because identity risk often concentrates in accounts that are old, over-permissioned, or poorly governed. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which broadens the blast radius once an attacker turns a crackable response into access. That is why defenders need to correlate authentication events with identity lifecycle and privilege context, not just count login failures. The broader governance lesson aligns with the Ultimate Guide to NHIs and the visibility gaps described in the Top 10 NHI Issues.

Authentication log review should therefore treat unusual Kerberos request patterns as early warning, then test whether the affected account should have pre-auth disabled at all. In practice, many security teams encounter AS-REP roasting only after a password hash has already been extracted, rather than through intentional control testing.

How It Works in Practice

Detection starts with Kerberos event ID 4768 and an analyst’s ability to distinguish normal ticket requests from suspicious ones. A Pre-Authentication Type of 0 is the most important indicator because it means the KDC issued a ticket-granting response without pre-authentication. That is expected only for specific accounts, and even then it should be rare, documented, and justified. Pair that with ticket encryption type review: RC4 use can indicate weaker protection and is often worth escalating when it appears alongside unusual account behavior.

A practical workflow is to baseline which service accounts, legacy apps, or exception accounts legitimately generate these events, then alert on deviation. The request’s Service Name, source host, frequency, and timing matter. A single 4768 with Pre-Authentication Type 0 may be benign. Multiple requests across many accounts, especially from a workstation that does not normally touch those principals, is a stronger indicator of enumeration or collection activity. This is where the broader NHI lifecycle lens from NHI Lifecycle Management Guide becomes useful: if the account was never reviewed, the exception may already be a liability.

• Alert on 4768 events where Pre-Authentication Type equals 0.
• Flag RC4 or other weak encryption when it appears with unusual request volume.
• Correlate the source host, Service Name, and account age or tier.
• Separate expected legacy exceptions from newly exposed accounts.

For control mapping, this log review aligns with NIST Cybersecurity Framework 2.0 detection and monitoring expectations, and with event-centric telemetry guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls. These controls tend to break down in heavily delegated Windows environments where legacy applications require pre-auth exceptions and logging is incomplete across domain controllers.

Common Variations and Edge Cases

Tighter Kerberos monitoring often increases alert volume, requiring organisations to balance detective value against the operational cost of tuning legacy exceptions. The biggest edge case is a legitimate account that intentionally has pre-auth disabled, which is sometimes necessary for compatibility but should be tightly scoped and reviewed. There is no universal standard for this yet, but current guidance suggests treating every exception as temporary unless a business owner can defend it.

Another common pitfall is assuming all AS-REP roasting activity will look identical. Attackers may spread requests across time, use different source systems, or query low-value accounts first to avoid detection. In environments with weak identity hygiene, the problem compounds because exposed accounts are often difficult to inventory, and the organisation may not know which principals should never be exempted. NHI Mgmt Group’s reporting that only 5.7% of organisations have full visibility into service accounts underscores why baseline quality matters as much as alert logic.

Defenders should also avoid overfocusing on RC4 alone. Weak encryption strengthens the case for investigation, but the core signal is still the disabled pre-authentication state combined with abnormal request context. Mature detection programs enrich 4768 events with identity ownership, device posture, and exception records so analysts can separate routine administration from attacker enumeration. For broader threat context, CISA cyber threat advisories can help validate whether the observed pattern matches current adversary tradecraft. In practice, this guidance breaks down when domain controller logs are incomplete or when exception handling is unmanaged across multiple forests.

Related resources from NHI Mgmt Group

• How should security teams defend against AS-REP Roasting in Active Directory environments?
• What breaks when identity tools rely only on authentication logs to detect compromise?
• How should security teams detect malicious code commits when a legitimate contributor account has been compromised?
• What breaks when onboarding and account recovery still rely on manual authentication setup?