How do attackers use AS-REQ roasting?

How AS-REQ roasting works in practice

AS-REQ roasting is a Kerberos abuse path, not a live password-spray attack. The attacker sends authentication requests and looks for accounts that return material suitable for offline cracking, which shifts the work away from the domain controller and onto the attacker’s own hardware. That is why weak passwords and exposed service accounts are the usual prize.

The technique depends on pre-authentication behavior. When an account can be probed in a way that yields crackable material, the attacker can collect responses at scale and test guesses offline without triggering the same interactive lockout pressure that online authentication would create. Kerberos Security Guide is the clearest internal reference for the surrounding Kerberos failure modes, including AS-REP roasting, ticket abuse, and detection considerations.

Because the attack is opportunistic, the main target is not “Kerberos itself” but the accounts most likely to resist poor handling, such as service principals, legacy user accounts, and anything with a weak secret or a permissive pre-authentication posture. In other words, the attacker is probing for the easiest offline crack, not for a specific application exploit.

Why attackers prefer offline cracking over interactive guessing

The practical advantage is speed and stealth. Once the attacker has collected crackable material, they can move the expensive part of the attack away from the identity provider and into offline tooling, where rate limits, lockouts, and normal user-facing alarms are less useful. That makes the technique attractive for quiet reconnaissance, especially in environments where monitoring focuses on failed logons but not on unusual Kerberos request patterns.

This also changes the defender’s job. The meaningful question is not only whether a request succeeded, but whether the request volume, request distribution, and target accounts look normal for your environment. If the attacker can harvest material from many accounts before any password is recovered, the exposure is already present even if no account has yet been compromised.

AS-REQ roasting becomes materially more effective when strong secrets are absent, pre-authentication is weakly controlled, or service accounts are allowed to remain long-lived and poorly reviewed. Those are the conditions that convert a routine Kerberos exchange into a high-value offline recovery opportunity.

What defenders need to change to shrink the attack surface

The first control is to reduce crackability, which means strong passwords or equivalent secret hygiene for the accounts most likely to be probed. The second is to reduce the number of accounts that can be harvested at all, by tightening account settings and reviewing where pre-authentication-related exposure exists. The third is to make the collection phase visible through alerting on unusual Kerberos request volume and target diversity.

That is why Kerberos hygiene is not just an authentication concern, but also an account governance concern. The same operational discipline that limits stale service accounts, weak secrets, and unnecessary exceptions also reduces the usefulness of AS-REQ roasting as a reconnaissance step. CISA cyber threat advisories are worth tracking for broader credential-abuse patterns and response cues, even when the technique itself is not the headline item.

Risk and Threat Considerations

AS-REQ roasting is dangerous because it turns a single exposed account into a quiet offline-cracking opportunity, and because weak service or user secrets often exist in clusters. If one account is crackable, the attacker may use the recovered secret to probe for lateral movement, privilege escalation, or additional Kerberos abuse paths.

Failure mechanism: The defender allows accounts to remain probeable and weakly secreted, then misses the collection phase because the activity resembles ordinary Kerberos traffic until the offline crack succeeds.

Impact: A successful crack can expose reusable credentials, enable impersonation, and create a stepping stone toward broader domain access, especially where the account has service-level reach or legacy privileges.

Practitioner Guidance

What to verify: Confirm which accounts can still return crackable pre-authentication material, and treat service accounts as a priority review set rather than a background inventory task. If you cannot quickly identify the weak or legacy accounts, assume your exposure is broader than your current monitoring suggests.

What good looks like: The environment has few or no crackable targets, service accounts are tightly governed, and request-volume anomalies are investigated as a credential-harvesting signal rather than dismissed as routine Kerberos noise.

Practitioner takeaway: AS-REQ roasting is less about a clever exploit than about finding weak accounts that were never brought under disciplined secret and request governance, so the best defense is to remove the harvestable target first and watch the collection pattern second.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?