AS-REP Roasting — Kerberos Pre-Authentication Disabled Account Attack

MITRE ATT&CK

Security Relevance

AS-REP Roasting is particularly dangerous because it requires zero credentials — an unauthenticated attacker on the network can request crackable hashes for any vulnerable account. This distinguishes it from Kerberoasting, which requires a valid domain account to start. Accounts with pre-authentication disabled were often configured for legacy compatibility and are frequently overlooked in hardening reviews. If an administrative or service account is vulnerable, an attacker can crack its password offline and authenticate with full privileges — without triggering any failed logon events during the attack.

Indicators of Malicious Use

• ⚑Event 4768 with Pre-Authentication Type field value 0 — the KDC issued a TGT without requiring a pre-authentication timestamp, exposing the AS-REP for offline cracking
• ⚑Rapid burst of 4768 requests from a single source IP across multiple account names — characteristic of AS-REP Roasting tool enumeration
• ⚑Event 4688: Rubeus.exe with 'asreproast' argument, or python.exe running GetNPUsers.py from a non-developer host
• ⚑Event 4104 (PowerShell script block): Invoke-ASREPRoast, Get-ASREPHash, or Get-DomainUser -PreauthNotRequired
• ⚑LDAP query for userAccountControl attribute with value 4194304 (DONT_REQ_PREAUTH flag) originating from a workstation rather than a domain controller

Example Log Entry

Event ID: 4768 — A Kerberos authentication ticket (TGT) was requested

Account Information:
  Account Name:        svc_legacy@CORP.LOCAL
  Supplied Realm Name: CORP.LOCAL
  User ID:             CORP\svc_legacy

Service Information:
  Service Name:        krbtgt
  Service ID:          CORP\krbtgt

Network Information:
  Client Address:      ::ffff:10.10.2.88
  Client Port:         54321

Additional Information:
  Ticket Options:      0x40800010
  Result Code:         0x0 (success)
  Ticket Encryption Type: 0x17 (RC4-HMAC)
  Pre-Authentication Type: 0     ← no pre-auth required; AS-REP hash returned for offline cracking

Note: The encrypted portion of this AS-REP can be extracted as a $krb5asrep$
hash and submitted to hashcat (-m 18200) or John the Ripper for offline
password cracking — no domain credentials were used to obtain it.

Investigation Steps

1. 1.Audit for vulnerable accounts immediately: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth,Enabled | Select Name,SamAccountName,Enabled. Any enabled account with DoesNotRequirePreAuth = True is exploitable right now.
2. 2.Review Event 4768 logs on domain controllers — filter for Pre-Authentication Type = 0. Any 4768 with this value means the KDC issued a crackable AS-REP. Note the Client Address and Account Name.
3. 3.Identify the requesting source: pivot to the host at Client Address and check Event 4688 (process creation) and 4104 (PowerShell script block) for Rubeus, GetNPUsers, Invoke-ASREPRoast, or BloodHound activity.
4. 4.Assess account privilege: query group memberships for each vulnerable account (Get-ADUser -Identity svc_legacy -Properties MemberOf) and check for administrative rights, SPNs, or access to high-value systems. Prioritize by blast radius.
5. 5.Check for follow-on authentication: search Event 4624 for successful logons from the vulnerable account after the 4768 event. Successful logon from a new source IP shortly after suggests the password was cracked quickly.
6. 6.If compromise is suspected: reset the account password immediately with a strong random value (25+ characters), then disable DoesNotRequirePreAuth. For service accounts, coordinate with application owners before resetting.

Common False Positives

• ◎Legacy applications with genuine Kerberos pre-authentication compatibility requirements — some older systems cannot negotiate pre-authentication and require the setting to be disabled. Document these accounts as named exceptions and monitor them for anomalous logon patterns.
• ◎Authorized security assessments: red team exercises and AD security audits (BloodHound, PingCastle) intentionally enumerate accounts with this flag. Create detection exceptions during known engagement windows.
• ◎A single 4768 with PreAuthType 0 for a known legacy account is expected behavior — the signal becomes high-confidence when multiple accounts are targeted in quick succession from the same source IP.

Remediation

• ✓Disable DoesNotRequirePreAuth on all accounts that have it set — this is the definitive fix. Run Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} | Set-ADUser -DoesNotRequirePreAuth $false after testing for application impact.
• ✓For accounts where pre-authentication cannot be re-enabled, set a strong random password (25+ characters) to make offline cracking computationally infeasible — this is a fallback control, not a substitute for fixing the setting.
• ✓Enforce AES encryption for the vulnerable accounts: set msDS-SupportedEncryptionTypes = 24 (AES128+AES256). This makes the AS-REP hash significantly harder to crack even if it's obtained — RC4-HMAC ($krb5asrep$) cracks much faster.
• ✓Enable Event 4768 auditing on all domain controllers (Account Logon → Kerberos Authentication Service). Without this, AS-REP Roasting is undetectable at the event log level.
• ✓Add vulnerable accounts to a monitoring watchlist — alert on 4624 logons from these accounts to unexpected source IPs or outside business hours.
• ✓Use Group Managed Service Accounts (gMSA) for service accounts — gMSAs cannot have DoesNotRequirePreAuth set and Windows auto-rotates their 120-character passwords every 30 days, eliminating both Kerberoasting and AS-REP Roasting risk.

Related Event IDs

Related Detection Guides

Frequently Asked Questions

What makes AS-REP Roasting different from Kerberoasting?

Kerberoasting requires a valid domain account to request service tickets — the attacker must already be authenticated. AS-REP Roasting requires no credentials at all: if an account has pre-authentication disabled, anyone on the network can request its AS-REP hash. AS-REP Roasting also targets a smaller set of accounts, generates fewer events, and the vulnerable accounts are frequently overlooked in hardening reviews — making it a quieter attack path.

How do I find accounts vulnerable to AS-REP Roasting?

Run: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth | Select Name,SamAccountName. Any enabled account in this list is exploitable without credentials. You can also query for the DONT_REQ_PREAUTH flag (userAccountControl bit 4194304) via LDAP. BloodHound marks these accounts as 'AS-REP Roastable' nodes in its attack path analysis.

Can AS-REP Roasting be detected without a SIEM?

Yes — check your domain controller's Security event log for Event ID 4768 with Pre-Authentication Type = 0. This value means the KDC issued a TGT without requiring a pre-authentication timestamp, returning a hash that can be cracked offline. EventPeeker's Kerberos attack detection covers this pattern. A single occurrence for a known legacy account may be expected; multiple accounts targeted from one source IP in rapid succession is a high-confidence indicator.

Is a long password enough to protect against AS-REP Roasting?

A strong random password (25+ characters) makes offline cracking computationally infeasible with current hardware, significantly mitigating the risk. However, the correct fix is to re-enable Kerberos pre-authentication by unchecking 'Do not require Kerberos preauthentication' in ADUC or setting DoesNotRequirePreAuth = $false via PowerShell. A long password is a fallback control for accounts where the setting cannot be changed due to legacy application requirements.