What is AS-REP Roasting?

Definition

AS-REP Roasting is an Active Directory attack against accounts that have Kerberos pre-authentication disabled. Attackers can request an AS-REP message for these accounts and crack the encrypted timestamp offline to recover the user's password.

It is MITRE ATT&CK T1558.004.

In simple terms:

If pre-authentication is off, the KDC will hand attackers an offline-crackable password hash for the asking.

---

Why It Matters

• Requires no authenticated session — the attacker only needs network access to the DC and the account name.
• Often affects legacy accounts retained for backward-compatible apps.
• Cracking is offline — fast and silent.
• Recovered passwords directly enable interactive logon, lateral movement, and escalation.

---

How Pre-Authentication Works

In normal Kerberos:

1. Client sends AS-REQ with encrypted timestamp using a key derived from the user's password.
2. KDC verifies the timestamp before responding — proving the client knows the password.
3. KDC returns the TGT.

If pre-authentication is disabled (UF_DONT_REQUIRE_PREAUTH in userAccountControl), the KDC sends the TGT response without verifying the timestamp — and the AS-REP includes data encrypted with the user's key. Anyone can request it and crack offline.

---

How AS-REP Roasting Works

1. Discover Accounts Without PreAuth

LDAP query (works for unauthenticated or low-privilege users in some configs):

(&(objectCategory=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))

Tools: Rubeus, Impacket's GetNPUsers.py.

2. Request AS-REP

GetNPUsers.py corp.local/ -no-pass -usersfile users.txt

For each non-preauth account, the KDC returns a hash like:

[email protected]:...

3. Crack Offline

Hashcat mode 18200. Weak passwords crack in minutes.

4. Use Recovered Credentials

Authenticate as the user, leveraging whatever access they have.

---

Why Accounts Have PreAuth Disabled

• Legacy applications that didn't support Kerberos pre-auth.
• Migration artifacts (often disabled "temporarily" decades ago).
• Misconfiguration during account creation.
• Sometimes intentionally for compatibility — usually no longer required.

---

Real-World Examples

1. Service Account With Disabled PreAuth

A 2008-era integration account had pre-auth disabled. Password was 8 characters and never rotated. Cracked in minutes; account had access to the file server hosting customer data.

2. Penetration Test Discovery

Pen testers routinely find one or two AS-REP roastable accounts in any Active Directory environment, often leading to lateral movement.

3. Combined With Kerberoasting

Attacker uses AS-REP Roasting to recover one password, authenticates, then performs Kerberoasting against SPN-enabled accounts to reach Domain Admin.

---

Defense Against AS-REP Roasting

Enable Pre-Authentication Everywhere

1. Inventory all accounts with UF_DONT_REQUIRE_PREAUTH set:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}

2. Test the legacy dependency — almost always pre-auth can be safely re-enabled.
3. Re-enable pre-authentication on every such account.

Strengthen Passwords

4. Long, random passwords (25+ chars) on any account that retains disabled pre-auth.
5. Use gMSA for service accounts where possible.

Detection

6. Monitor AS-REQ events without PA-DATA.
7. Honeypot account with pre-auth disabled and a long random password — any AS-REP request is a high-fidelity alert.
8. Alert on userAccountControl changes that disable pre-auth.

Hygiene

9. Decommission unused legacy accounts.
10. Document any account that must keep pre-auth disabled with owner and review date.

---

AS-REP Roasting Defense Checklist

• All accounts inventoried for DoesNotRequirePreAuth?
• Pre-authentication re-enabled wherever feasible?
• Honeypot AS-REP roastable account in place?
• Detections for AS-REP requests without PA-DATA?
• Alerts on userAccountControl changes that disable pre-auth?
• gMSA used for service accounts?
• Legacy dependencies justified, documented, and reviewed?

---

How Forestall Helps

Forestall continuously inventories AS-REP roastable accounts and ranks them by:

• Privilege of the account (admin, service, standard).
• Age and complexity of the password.
• Group memberships and reachable systems.
• Attack paths from this account to Tier 0.

It also tracks remediation progress and flags any new account created with pre-auth disabled.

---

Frequently Asked Questions

How is AS-REP Roasting different from Kerberoasting?

• AS-REP Roasting — targets accounts without pre-auth; needs only the username; affects any user with the flag set.
• Kerberoasting — requires authenticated user; targets SPN-enabled service accounts.

Both crack hashes offline.

Why would pre-auth ever be disabled?

Mostly historical reasons. Modern applications support pre-auth.

Will re-enabling pre-auth break anything?

Rarely. Test in a non-prod tenant first, then re-enable. Monitor logon failures briefly after.

Can attackers do this without any access?

In some configurations, yes — only the username and network reachability to a DC are required.

Is the Protected Users group helpful?

Yes — Protected Users have stronger Kerberos protections, but the primary defense is enabling pre-auth.

---

Conclusion

AS-REP Roasting is a "free" attack: no authenticated session needed, no native alerts, and very fast offline cracking. The good news is that the fix is equally simple — re-enable pre-authentication on every account that doesn't actually require it disabled (which is almost all of them). Combined with strong password policy, gMSA migration, and a honeypot detection, AS-REP Roasting becomes a non-issue and one of the easiest wins in any AD hardening project.