Kerberos Pre-Authentication: Prevent AS-REP Roasting
Kerberos Pre-Authentication: Prevent AS-REP Roasting
Kerberos pre-authentication helps prevent attackers from requesting crackable authentication data for Active Directory users without first proving knowledge of their password. When pre-authentication is disabled on an account, that user can become vulnerable to AS-REP roasting, allowing an attacker to obtain encrypted material and attempt to crack the account password offline.
Quick Summary
When Kerberos Pre-Authentication is disabled on an Active Directory account, attackers can request an encrypted ticket without knowing the password. That ticket can then be taken offline and cracked at will. This technique, known as AS-REP Roasting, is one of the most common first steps used by ransomware groups and opportunistic attackers once they have a foothold on the internal network.
| Priority | Critical |
| Risk | Accounts with this setting allow attackers to request encrypted ticket data and crack passwords offline. |
| Impact | Credential compromise, unauthorized access, privilege escalation, lateral movement, domain persistence |
| Exploitation | Attackers send an unauthenticated AS-REQ to a vulnerable account and receive an AS-REP encrypted with its password-derived key. |
| Fix | Re-enable Kerberos Pre-Authentication on affected accounts and implement continuous monitoring or provisioning controls to prevent unauthorized exceptions. |
What Is Kerberos Pre-Authentication?
Kerberos Pre-Authentication is a security layer built into the Kerberos authentication protocol. When it is enabled (the default), the client must demonstrate possession of the account’s Kerberos key before the KDC returns a successful AS-REP containing a Ticket-Granting Ticket (TGT). In the traditional password-based flow, this is commonly accomplished by encrypting a timestamp using a key derived from the user’s password.
When Pre-Authentication is disabled on an account, the domain controller skips this verification step entirely. It responds to any unauthenticated AS-REQ with an AS-REP message that contains a portion of data encrypted with the account’s password-derived key. An attacker who collects this AS-REP can take it offline and attempt to crack the hash without any further interaction with the domain.
This setting is controlled in Active Directory by the DONT_REQ_PREAUTH flag within the UserAccountControl attribute. It is occasionally enabled by administrators to support legacy applications or to work around Kerberos compatibility issues, but it should be treated as a security exception requiring explicit justification and regular review.
How AS-REP Roasting Can Pose a Risk
Disabling Pre-Authentication removes the primary barrier that prevents unauthenticated users from obtaining crackable credential material. The risk is compounded by the fact that the attack requires no special access and leaves minimal traces.
Common risks include:
- Offline password cracking with no authentication required
Any attacker on the network can request an AS-REP for a vulnerable account. No credentials, no elevated access, and no interaction with the target account are needed. - Rapid cracking using commodity hardware
AS-REP hashes commonly use RC4-HMAC encryption, which is significantly faster to crack than modern alternatives. Consumer GPU hardware can attempt billions of password combinations per second. - High-value account exposure
The accounts most commonly found vulnerable are service accounts and legacy application accounts, many of which carry elevated privileges and have rarely changed passwords. - No account lockout risk
Because cracking happens entirely offline against the captured hash, there are no failed authentication attempts against Active Directory. - Ransomware and APT entry point
AS-REP roasting can be used as an early-stage credential-access technique by ransomware operators and other threat actors. A successful crack often leads directly to a privileged foothold from which broader attacks are launched.
Real-World Context
AS-REP Roasting is one of the few Active Directory attacks that works before an attacker has any credentials at all. From the moment a threat actor reaches the internal network, every account with Pre-Authentication disabled is a free password attempt waiting to be collected. This is often one of the first actual attacks that threat actors perform.
How Attackers Take Advantage of AS-REP Roasting
The attack is well-documented, widely automated, and executable in seconds. Tooling is freely available and does not require advanced technical knowledge to operate.
Typical abuse scenarios include:
- AS-REP hash collection: Using tools such as Rubeus, Impacket’s GetNPUsers.py, or PowerView, attackers query Active Directory for accounts with the DONT_REQ_PREAUTH flag and request AS-REP tickets for each one in a single operation.
- Offline cracking with Hashcat or John the Ripper: The collected hashes are fed directly into cracking tools. RC4-HMAC hashes are particularly fast to crack. A weak or commonly used password can fall within seconds.
- Credential reuse across systems: Once a password is recovered, the attacker authenticates as that account and begins enumerating what it has access to, including file shares, remote management interfaces, databases, and additional Active Directory objects.
- Pivoting to higher privileges: Service accounts with cracked passwords are frequently members of privileged groups or have access to systems that enable further escalation, such as backup servers, deployment infrastructure, or domain controllers.
- Establishing persistence before detection: With a valid set of credentials, the attacker can create backdoor accounts, configure delegation, or deploy tooling that survives remediation efforts if the initial access is discovered and cut off.
How to Detect Accounts with Pre-Authentication Disabled
Detection is straightforward and should be part of standard Active Directory hygiene reviews.
PowerShell Method
Run the following command from an elevated PowerShell prompt:
# List all Active Directory user accounts that have Kerberos pre-authentication disabled
Get-ADUser -Filter * -Properties DoesNotRequirePreAuth | Where-Object { $_.DoesNotRequirePreAuth } | Select-Object Name, SamAccountName
What it does: This queries Active Directory for all user accounts where the DONT_REQ_PREAUTH flag is set.
How to interpret results: Any accounts returned have Kerberos pre-authentication disabled and are potentially vulnerable to AS-REP roasting. Compare the results against your documented exceptions and confirm whether the setting is genuinely required. Any unexpected account, especially one with privileged access, broad group membership, or a weak/unchanged password, should be treated as a priority finding and remediated by re-enabling Kerberos pre-authentication.
Active Directory Users and Computers (ADUC)
For manual verification of individual accounts:
- Open Active Directory Users and Computers
- Locate the target user or service account
- Open Properties and navigate to the Account tab
- Look for the checkbox labeled “Do not require Kerberos preauthentication”
If checked, the account is vulnerable
How Insight Recon Identifies This Risk
Insight Recon’s Active Directory security assessment surfaces all accounts configured with Kerberos Pre-Authentication disabled. It provides context on potential impact by analyzing object relationships, privilege levels, and account permissions.
It also provides:
- Full visibility into every account with the DONT_REQ_PREAUTH flag set across the entire domain
- Context on account privilege, group membership, and password age to assess exploitation likelihood
- Risk-based prioritization so that high impact misconfigurations are remediated first
- Clear, actionable remediation guidance with the exact steps and commands needed to resolve the exposure
This allows teams to quickly understand not just if they are at risk, but how much it matters in their environment.
Remediating AS-REP Roasting
Prerequisites
Before making changes, verify the following to avoid disrupting services:
- Verify that no applications or scripts are configured to rely on Pre-Authentication being disabled.
- Confirm that Domain Administrator or equivalent privileges are available to make the change.
- If a service account is affected, notify the application owner before making changes and schedule a maintenance window for the change.
PowerShell Method
From an elevated PowerShell prompt, run the following command. “Replace ‘username’ with the target account name.
# Re-enable Pre-Authentication for a specific account
$user = Get-ADUser "username" -Properties userAccountControl
$newUAC = $user.userAccountControl -band (-bnot 0x400000)
Set-ADUser -Identity $user -Replace @{userAccountControl = $newUAC}
# Confirm the change was successful for a specific account
Get-ADUser "username" -Properties DoesNotRequirePreAuth | Select-Object Name, DoesNotRequirePreAuth
# Re-enable Pre-Authentication for all affected accounts at once
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
ForEach-Object {
Set-ADAccountControl -Identity $_.SamAccountName -DoesNotRequirePreAuth $false
}
Active Directory Users and Computers (ADUC)
- Open Active Directory Users and Computers
- Navigate to the affected account and open Properties
- Go to the Account tab
- Within the Account Options section, uncheck “Do not require Kerberos preauthentication”
- Apply changes and re-run the detection query to confirm the account no longer appears in results
Preventing Kerberos Pre-authentication Drift Going Forward
Fixing existing exposure is the first step. Preventing the misconfiguration from reappearing requires policy controls and ongoing visibility.
- Ongoing Monitoring
Schedule regular PowerShell audits or use a security monitoring tool to detect accounts where Pre-Authentication becomes disabled. - Administrator Training
Ensure that administrators who provision accounts understand that the DONT_REQ_PREAUTH flag should never be enabled without a documented justification and a defined expiry for the exception. - Policy Enforcement
Treat DONT_REQ_PREAUTH as a controlled Active Directory configuration exception. Restrict who can modify affected account attributes, incorporate checks into account provisioning workflows, and continuously monitor for unauthorized changes. - Event Logging and Alerting
Monitor Kerberos Event ID 4768 for requests where Pre-Authentication Type is 0, indicating that Kerberos pre-authentication was not used. Prioritize events involving accounts that are not approved exceptions, and treat RC4-HMAC ticket encryption (0x17) as an additional risk signal. Repeated requests across multiple pre-authentication-disabled accounts from a single source may indicate AS-REP roasting activity. - Password Hygiene for At-Risk Accounts
For any account that must temporarily retain this setting, enforce a strong, unique, randomly generated password of at least 25 characters. This does not eliminate the risk but increases the time and cost of a successful offline crack.
Quick Validation Checklist
Can you confidently answer “yes” to all of these?
✓ Do all accounts, especially service accounts, require Pre-Authentication?
✓ Do you know which accounts have Kerberos Pre-Authentication disabled in your domain?
✓ Are you alerting on Event ID 4768 requests with RC4-HMAC encryption and a pre-authentication type of 0?
If any of these are unclear, your environment may be exposed to AS-REP Roasting.
Risk & Compliance Mapping
Business Impact: Increased risk of credential compromise, unauthorized access, lateral movement, ransomware deployment, and potential regulatory exposure.
| Framework | Reference |
|---|---|
| NIST CSF 2.0 | PR.AC-1 (Identity Management and Authentication), PR.AC-7 (User Authentication) |
| CIS Controls | Control 5 (Account Management), Control 6 (Access Control Management) |
| MITRE ATT&CK | T1558.004 (Steal or Forge Kerberos Tickets: AS-REP Roasting) |
| DISA STIG | V-254478 (Windows Server must enforce Kerberos Pre-Authentication), V-36432 |
| ANSSI | User accounts with Kerberos Pre-Authentication disabled [vuln_kerberos_properties_nopreauth] |
| Microsoft Security Baselines | Microsoft recommends that Kerberos Pre-Authentication remain enabled for user accounts. The ‘Do not require Kerberos preauthentication’ setting should only be used for documented legacy exceptions with compensating controls. |
Frequently Asked Questions
In rare cases, legacy applications may require it. However, this should be treated as a documented exception with a defined remediation timeline, not a permanent configuration. No current Microsoft product or modern application requires Pre-Authentication to be disabled, and the setting should be reviewed and removed as soon as the legacy dependency is retired.
The most common cause is an administrator disabling it during a troubleshooting session to rule out Kerberos compatibility issues, then never re-enabling it. It also appears on accounts migrated from older environments where it was the default, and occasionally on service accounts set up by application vendors who included it in their deployment instructions without explaining the security implications.
Possibly for legacy applications, though it is unlikely. In most environments, re-enabling the setting on stale or general user accounts carries little service disruption risk. However, service accounts should be tested during a maintenance window when possible.
Both attacks involve cracking Kerberos ticket material offline, but they target different stages of the authentication flow. Kerberoasting requires the attacker to already have valid domain credentials, as it targets service tickets (TGS-REP) for accounts with Service Principal Names. AS-REP Roasting requires no credentials at all, making it a lower-barrier attack that can be executed earlier in the kill chain.
Stop AS-REP Roasting at the Source
AS-REP Roasting is not a sophisticated attack. It requires no credentials, leaves minimal logs, and can yield cracked passwords in seconds. Insight Recon helps you identify every account with Pre-Authentication disabled, prioritize the highest-risk exposures, and take action with confidence before an attacker gets there first.
See exactly where your Active Directory is exposed and what to fix first.