AS-REP roasting: hunting down accounts without Kerberos preauthentication
AS-REP roasting is a cousin of Kerberoasting, less common but even easier to exploit. It targets accounts where Kerberos preauthentication has been disabled, often for a reason long forgotten. Finding them takes only seconds.
What preauthentication does
When requesting an initial ticket (TGT), the client normally proves it knows the password by encrypting a timestamp with its key. That is preauthentication. When it is disabled, the domain controller returns an AS-REP response, part of which is encrypted with the user's key, to anyone who asks. An attacker can then try to crack that password offline, and does not even need a domain account if they know the target user names.
Why the option exists
"Do not require Kerberos preauthentication" was designed for older Kerberos implementations, such as some Unix clients or legacy applications that did not support preauthentication. Today that need is exceptional. The flag usually turns up after hasty troubleshooting, a migration or a badly configured provisioning script.
Finding affected accounts
The option maps to the DONT_REQ_PREAUTH flag (value 4194304) of the userAccountControl attribute. Two queries are enough:
Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth, PasswordLastSet, Enabled, adminCount |
Select-Object SamAccountName, Enabled, PasswordLastSet, adminCount
Get-ADObject -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=4194304)"
The second one, a raw LDAP filter, is handy in tools that do not use the ActiveDirectory module.
Fixing it
- For each account, identify the owner and the actual use.
- Re-enable preauthentication:
Set-ADAccountControl -Identity account -DoesNotRequirePreAuth $false. - Reset the password if the account was exposed for a long time, using a long random value.
- If an application genuinely needs the option, isolate the account, strip all privileges and give it a very long password.
Targeted variant. An attacker with write access to an account can disable preauthentication themselves, grab the AS-REP and then restore the setting. Monitoring write delegations on sensitive accounts matters as much as checking for the flag.
Detecting it
Event 4768 (TGT request) on domain controllers records the preauthentication type used. A value of 0 indicates a request without preauthentication. In a clean domain these events should be very rare, which makes for a simple alert. Changes to userAccountControl can also be tracked through account change events.
In short
- Kerberos preauthentication should be enabled on every account, barring a documented exception;
- a single PowerShell query finds the exceptions;
- write permissions on accounts must be controlled to prevent the targeted variant.