ASREPRoasting Prevention: How to Find and Fix Accounts with Kerberos Pre-Authentication Disabled
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
ASREPRoasting is one of the few Active Directory attacks that requires zero valid credentials -- an attacker with only network access to a domain controller can request AS-REP responses for any account with pre-authentication disabled and walk away with crackable hashes. Finding and fixing these accounts requires a single PowerShell query, but organizations often have legacy application accounts or improperly configured accounts with the flag set and forgotten. This guide covers enumeration, prioritization by password strength risk, remediation, and monitoring.
Find All ASREPRoastable Accounts
PowerShell query: Get-ADUser -Filter { DoesNotRequirePreAuth -eq $true } -Properties DoesNotRequirePreAuth, PasswordLastSet, Enabled, MemberOf | Select-Object SamAccountName, Enabled, PasswordLastSet, @{Name='Groups';Expression={($_.MemberOf | Get-ADGroup | Select-Object -ExpandProperty Name) -join ', '}} | Sort-Object Enabled, PasswordLastSet. This returns every account with DONT_REQ_PREAUTH set. The output includes whether the account is enabled, when the password was last set (critical for assessing crack risk), and what groups the account belongs to (critical for assessing impact if cracked). Also check disabled accounts -- disabled accounts can still be ASREPRoasted if the flag is set. An attacker cannot authenticate with a cracked disabled account password directly, but the cracked password may reveal a password pattern used across other enabled accounts (password reuse, seasonal patterns). Enumerate and document all findings before beginning remediation.
Why Pre-Authentication Gets Disabled
The most common reason an account has pre-authentication disabled: an application or legacy script required it because it could not handle standard Kerberos authentication. Specific scenarios: older SAP, Oracle, and custom Java applications that used Kerberos libraries not supporting pre-authentication (a compatibility issue common before 2010). Some Unix and Linux Kerberos clients (MIT Kerberos and Heimdal pre-2.0) had optional pre-authentication support and were sometimes configured to skip it. IT staff following outdated guides or troubleshooting Kerberos errors by disabling pre-auth as a workaround (this appears as a fix in many legacy forum posts). Service account configuration errors where a technician checked the wrong box in ADUC. In the vast majority of cases, pre-authentication can be re-enabled without breaking the application -- modern versions of all major application platforms support Kerberos pre-authentication.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Remediation: Re-Enable Pre-Authentication
For each account identified: re-enable pre-authentication and test. PowerShell to re-enable: Set-ADUser -Identity username -DoesNotRequirePreAuth $false. Via ADUC: open account Properties > Account tab > Account options, uncheck 'Do not require Kerberos preauthentication'. After re-enabling, test the application that prompted the original disable. In most cases, the application will work without changes. If the application breaks: identify the specific Kerberos error (Event ID 4768 on the DC with a failure code -- 0x18 is bad password, 0x25 is clock skew, 0x6 is account not found). The most common issue after re-enabling is clock skew: Kerberos requires clocks within 5 minutes of the KDC. If clocks are synchronized (which they should be for any domain-joined system), this is not an issue. For the small number of accounts where re-enabling pre-authentication genuinely breaks an application: rotate the password to a 64-character random string immediately (minimizing crack risk), document the business justification, and plan migration of the application to a version that supports standard Kerberos.
Prioritize Remediation by Password Age and Account Privilege
Not all ASREPRoastable accounts are equal risk. Highest priority: any enabled account whose password was set more than 90 days ago and that is a member of privileged groups (Domain Admins, Server Operators, Account Operators). These are likely to have guessable or crackable passwords and the impact of compromise is severe. Fix immediately. High priority: any enabled account with a password older than 1 year, regardless of group membership. These passwords may appear in breach databases. Fix within 1 week. Medium priority: enabled accounts with recent passwords (under 90 days) that are not in privileged groups. Lower crack risk but still a vulnerability. Fix within 30 days. Lower priority: disabled accounts. No immediate authentication risk, but re-enable pre-auth and rotate password as part of standard cleanup. Before beginning the remediation queue, reset passwords for the highest-priority accounts to a long random string even before re-enabling pre-authentication -- this eliminates the crack risk while you work through compatibility testing.
Prevent Recurrence and Monitor
Prevent new accounts from being created with pre-authentication disabled: there is no built-in GPO setting to block this flag, but you can monitor for it. Enable auditing: Event ID 4738 (A user account was changed) logs changes to userAccountControl, including setting DONT_REQ_PREAUTH. Alert in your SIEM when Event ID 4738 appears with a userAccountControl change that includes the 0x400000 bit (DONT_REQ_PREAUTH). KQL in Sentinel: SecurityEvent | where EventID == 4738 and UserAccountControl contains '%%2089'. Create a scheduled PowerShell script that runs weekly and alerts if Get-ADUser -Filter { DoesNotRequirePreAuth -eq $true } returns any enabled accounts. After completing the initial remediation, this list should be empty. Any new entries require investigation within 24 hours.
The bottom line
ASREPRoasting is one of the easiest Active Directory credential attacks to fix because the remediation is a single attribute change per account. Run the PowerShell query, sort by password age and privilege, start rotating passwords for the highest-risk accounts today, and re-enable pre-authentication for every account. The entire remediation process for a typical organization is a day's work. Post-remediation, monitor Event ID 4738 so any future occurrence is caught within hours.
Frequently asked questions
What is the difference between ASREPRoasting and Kerberoasting?
ASREPRoasting targets accounts with Kerberos pre-authentication disabled and requires no valid credentials -- the attacker asks the KDC for an AS-REP and cracks the resulting encrypted session key offline. Kerberoasting targets accounts with Service Principal Names (SPNs) and requires a valid authenticated domain user -- the attacker requests a service ticket (TGS) for the SPN and cracks the service account's password offline. ASREPRoasting is a zero-credential attack; Kerberoasting requires at least one valid domain credential. Both produce offline-crackable material and both are addressed primarily by using strong long random passwords.
Can an attacker perform ASREPRoasting from outside the network?
ASREPRoasting requires network access to the domain controller's Kerberos port (88/TCP and 88/UDP). If the DC is directly internet-accessible (uncommon but not unheard of in poorly configured environments) or if the attacker is on the internal network (via VPN access, a compromised endpoint, or a rogue device), ASREPRoasting is possible. The main external-access scenario is a red team with VPN credentials. Ensure port 88 is not exposed externally on any DC.
Should I add ASREPRoastable accounts to Protected Users?
Adding an account to Protected Users prevents NTLM authentication and restricts Kerberos ticket lifetimes but does NOT prevent ASREPRoasting if pre-authentication is still disabled -- Protected Users membership does not enable pre-authentication. The fix is specifically to re-enable the DoesNotRequirePreAuth=False flag. Protected Users membership is valuable for privileged accounts but is a separate control from the ASREPRoasting remediation.
How do I check if my environment was already ASREPRoasted?
Event ID 4768 on domain controllers logs AS-REP requests. Filter for 4768 events with Pre-Authentication Type set to 0 (no pre-auth). These events show which accounts were requested and from which source IP. A high volume of 4768 with Pre-Authentication Type 0 from a non-DC IP is evidence of ASREPRoasting activity. Check historical logs if available -- the queries are fast and the accounts with the flag set are a small subset of all domain accounts.
What password cracking tools and techniques do attackers use against AS-REP hashes?
AS-REP hashes are cracked using Hashcat (mode 18200, AS-REP etype 23) or John the Ripper. The hash format is the RC4-HMAC encrypted portion of the AS-REP message, specifically the session key encrypted with the account's password-derived key. Attackers use wordlist attacks with common password lists (rockyou.txt, leaked corporate password lists), rules-based mutations (adding numbers, capitalizing first letters), and hybrid attacks combining wordlists with masks. Passwords under 20 characters that follow predictable patterns (word + year + symbol) are cracked in minutes to hours on GPU hardware. The practical defense is a password length requirement of 20 characters minimum for accounts without pre-auth; better yet, enable pre-auth and the hash cannot be extracted at all.
How do I find all accounts with Kerberos pre-authentication disabled in Active Directory?
Query using PowerShell: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth. This returns all user accounts with the 'Do not require Kerberos preauthentication' flag set (UserAccountControl flag 0x400000). For each account returned: determine whether the flag is intentional (some legacy authentication scenarios required this for compatibility) or inadvertent (set by an admin who did not understand the security implication). For any account with the flag that is a service account with high privilege, treat this as a critical finding requiring immediate remediation. Enable pre-auth on all accounts where possible: Set-ADUser -Identity username -Replace @{DoesNotRequirePreAuth=$false}. Schedule this as a recurring quarterly check since applications or scripts can re-set the flag when resetting account properties.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.