Stealing Active Directory credentials by abusing Kerberos pre-authentication
Introduction
AS-REP Roasting is an attack technique used against Microsoft Active Directory environments that allows an attacker to obtain encrypted Kerberos authentication data for accounts that have Kerberos pre-authentication disabled.
If successful, the attacker can then attempt to crack the encrypted response offline to recover the user’s password.
Like Kerberoasting, AS-REP Roasting does not necessarily exploit a software vulnerability. Instead, it abuses a legitimate Kerberos feature combined with an insecure account configuration.
The key difference is that Kerberoasting targets service accounts with SPNs, while AS-REP Roasting targets accounts that do not require Kerberos pre-authentication.
What is Kerberos Pre-Authentication?
Kerberos normally uses a mechanism called pre-authentication to prove that a user knows their password before the domain controller issues an authentication response.
A simplified process of Pre-Authentication looks like this:
User → Authentication Request → Domain Controller → Pre-Authentication → AS-REP
The pre-authentication stage provides an important security control – Without it, an attacker may be able to request authentication data for an account without first proving knowledge of that account’s password.
What is an AS-REP?
AS-REP stands for Authentication Service Response – It is the response generated by the Kerberos Authentication Service after an authentication request.
The response contains information encrypted using a key derived from the user’s password. Normally, the user can decrypt this information because they know their own password.
For an attacker, however, this creates an opportunity – If pre-authentication is disabled, the attacker may be able to obtain the encrypted response and take it away for offline password cracking.
How AS-REP Roasting works
The attack can be broken into several stages.
1. Identify vulnerable accounts
The attacker first looks for Active Directory accounts where Kerberos pre-authentication is not required. These accounts have the DONT_REQ_PREAUTH configuration flag enabled.
This is the critical condition that makes an account susceptible to AS-REP Roasting.
2. Request authentication data
The attacker sends a Kerberos authentication request for the vulnerable account. Because pre-authentication is disabled, the domain controller can return an AS-REP response without first requiring the normal pre-authentication exchange.
This is important because the attacker does not need to know the account’s password to obtain the encrypted response.
3. Obtain the encrypted response
The AS-REP contains encrypted authentication material – The encryption is based on a key derived from the target account’s password.
The attacker can then perform the password-cracking process offline.
4. Crack the password offline
The attacker attempts different password candidates against the captured encrypted data.
As with offline password cracking Kerberos data – because the cracking occurs offline, the attacker can potentially perform a large number of guesses without repeatedly authenticating against the domain.
This makes account lockout controls less effective against the cracking phase of the attack.
Why is AS-REP Roasting dangerous?
The recovered password belongs to a legitimate Active Directory account – The consequences therefore depend on the privileges assigned to that account.
A compromised account may provide access to:
- File shares
- Internal applications
- Workstations
- Servers
- Databases
- Sensitive information
- Additional credentials
- Privileged systems
If the compromised account has significant privileges, AS-REP Roasting can become an important step in a larger compromise.
AS-REP Roasting vs Kerberoasting
The two attacks are closely related but target different weaknesses.
| AS-REP Roasting | Kerberoasting | |
|---|---|---|
| Primary target | Accounts without Kerberos pre-authentication | Accounts associated with SPNs |
| Requires SPN? | No | Yes |
| Key weakness | Pre-authentication disabled | Weak service-account password |
| Authentication data | AS-REP | TGS service ticket |
| Offline cracking | Yes | Yes |
| Typical target | User/service accounts | Service accounts |
| Key Windows event | 4768 | 4769 |
The distinction is important:
AS-REP Roasting → disabled Kerberos pre-authentication
Kerberoasting → service accounts/SPNs
What makes an account vulnerable?
The most important configuration is “Do not require Kerberos preauthentication”
In Active Directory, this corresponds to the DONT_REQ_PREAUTH user-account control setting.
Accounts may have this setting for historical, compatibility or application-specific reasons, but unfortunately, leaving it enabled unnecessarily creates an opportunity for attackers.
Detecting AS-REP Roasting
Detection should focus on unusual Kerberos authentication activity.
One particularly useful Windows Security event is Event ID 4768 – A Kerberos authentication ticket was requested
Security teams can examine these events for unusual authentication requests involving accounts configured without pre-authentication.
Potential indicators include:
- Unusual AS-REQ activity
- Authentication requests for rarely used accounts
- Requests originating from unexpected workstations
- Multiple requests for accounts with pre-authentication disabled
- Authentication activity outside normal working patterns
- Requests involving dormant or service accounts
- Unexpected encryption types
- Sudden authentication activity involving privileged accounts
As always, a single event does not necessarily indicate malicious activity – Context and behavioural patterns are more valuable than isolated events.
Preventing AS-REP Roasting
- Enable Kerberos pre-authentication – This is the most direct defence. Accounts should normally require Kerberos pre-authentication. The “Do not require Kerberos preauthentication” setting should only be enabled when there is a legitimate requirement.
- Use strong passwords – Accounts that are exposed to offline cracking attempts should have goods password policies applied to them. Strong passwords make offline cracking considerably more difficult.
- Review Active Directory accounts – Organisations should regularly identify accounts where Kerberos pre-authentication has been disabled.
- Apply least privilege – A service or user account should only have the permissions necessary for its role. Avoid giving vulnerable or legacy accounts unnecessary administrative privileges.
- Remove obsolete accounts – Dormant accounts are particularly dangerous. An account that is no longer required but remains active can become an attractive target. Regular Active Directory account reviews can identify and remove these accounts.
Conclusion
AS-REP Roasting demonstrates how a relatively small Active Directory configuration weakness can provide attackers with a powerful credential-access opportunity.
The attacker does not need to directly brute-force the target account. Instead, they exploit the absence of Kerberos pre-authentication to obtain an encrypted AS-REP, which can then be subjected to offline password cracking.
The fundamental defensive lesson is straightforward – Do not disable Kerberos pre-authentication unless there is a genuine requirement to do so.
Combined with strong passwords, least privilege, regular Active Directory auditing and effective Kerberos monitoring, this significantly reduces the opportunity for AS-REP Roasting.