Estimated reading time: 3 minutes
AS-REP Roasting is a post-exploitation attack technique that targets user accounts in Active Directory (AD) that have the “Do not require Kerberos preauthentication” setting enabled. This allows an attacker to request and retrieve AS-REP (Authentication Server Response) messages, which contain an encrypted NTLM hash of the user’s password, and crack them offline.
1. The Kerberos Authentication Process
In a standard Kerberos authentication flow, the client requests a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC). This process involves:
- The client sends an Authentication Service Request (AS-REQ).
- The KDC responds with an Authentication Server Response (AS-REP), containing an encrypted TGT.
- The encryption key for the AS-REP is derived from the user’s NTLM hash.
Normally, Kerberos preauthentication is required, meaning the AS-REQ must be encrypted using the user’s password-derived key to prove their identity before getting an AS-REP.
However, when the “Do not require Kerberos preauthentication” setting is enabled on an account, anyone can request an AS-REP without needing prior knowledge of the user’s password.
2. Attack Execution: AS-REP Roasting
To perform AS-REP roasting, an attacker follows these steps:
Step 1: Enumerate User Accounts Without Preauthentication
The attacker first identifies accounts that have preauthentication disabled. This can be done using PowerShell:
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth
PowerView:
Get-DomainUser -PreauthNotRequired
Step 2: Request an AS-REP Ticket for a Target User
The attacker requests an AS-REP for a vulnerable user using Impacket’s GetNPUsers.py:
python3 GetNPUsers.py domain.local/ -usersfile users.txt -format hashcat -output hashes.txt
Since preauthentication is disabled, the KDC directly responds with an AS-REP message containing an encrypted NTLM hash of the user’s password.
Step 3: Extract and Save the AS-REP Hash
The AS-REP response contains an encrypted NTLM hash, which follows the Kerberos 5 AS-REP etype 23 format. The extracted hash looks like this:
$krb5asrep$23$user@DOMAIN:HASH
This is then saved to a file (e.g., hashes.txt) for offline cracking.
Step 4: Crack the Hash Offline
The attacker attempts to recover the user’s password by brute-forcing the AS-REP hash using Hashcat:
hashcat -m 18200 hashes.txt /path/to/wordlist.txt --force
If the user’s password is weak, Hashcat will recover it.
3. Impact of AS-REP Roasting
- If a privileged account (e.g., Service Account, Domain Admin) is targeted, an attacker could escalate privileges.
- Enables lateral movement across the domain.
- Can be performed by any domain user, requiring no special privileges.
- AS-REP hashes are crackable offline, so detection is difficult.
4. Mitigation Strategies
To prevent AS-REP roasting, organizations should:
- Enforce Kerberos Preauthentication on all accounts.
- Ensure that the “Do not require Kerberos preauthentication” option is unchecked for all user accounts.
- Run this PowerShell command to disable the setting:
Set-ADUser -Identity <User> -DoesNotRequirePreAuth $false
- Use Strong Passwords
- Enforce long, complex passwords to make brute-force cracking infeasible.
- Implement password policies using tools like LAPS or gMSAs.
- Monitor for Unusual AS-REP Requests
- Look for Event ID 4768 in domain controller logs, which tracks AS-REP requests.
- Use SIEM solutions (Splunk, ELK, Microsoft Sentinel) to detect multiple AS-REP requests from a single source.
- Disable Unused Accounts
- Remove or disable stale accounts that may have preauthentication disabled.
Conclusion
AS-REP Roasting is an effective attack that allows attackers to obtain encrypted NTLM hashes without triggering authentication failures. Since the attack is offline, it is difficult to detect in real time. Organizations should enforce Kerberos preauthentication, strong password policies, and continuous monitoring to mitigate this risk.