AS-REP Roasting: Finding and Fixing Vulnerable Accounts with PowerShell
- Chris Keim
- 12 hours ago
- 10 min read
In This Article:
What is AS-REP Roasting
AS-REP Roasting is a credential attack against Active Directory that targets accounts with Kerberos pre-authentication disabled. It's quieter than Kerberoasting, requires no valid domain credentials to execute, and still shows up in environments that have never been audited for it.
In a standard Kerberos authentication flow, a client must prove its identity before the Domain Controller will issue a ticket. That proof comes in the form of a timestamp encrypted with the user's password hash, this is Kerberos pre-authentication. When pre-authentication is disabled on an account, that requirement disappears. Anyone can send an unauthenticated AS-REQ for that account and the Domain Controller will respond with an AS-REP containing data encrypted with the account's password hash. That encrypted blob can be taken offline and cracked without any further interaction with your environment.
The setting that creates this exposure is called DONT_REQ_PREAUTH. In most environments, it gets enabled for a specific reason, an application or legacy system that doesn't support modern Kerberos pre-authentication. It gets set, the app works, and nobody ever revisits it. In the environments I've reviewed, these accounts are found, often with passwords that haven't changed since the setting was enabled.
This article follows the same approach as my Kerberoasting post: find the accounts, understand the risk, fix the highest priority items first, and put detection in place while you work through remediation. You don't need a pen testing background or special tools. PowerShell and read access to Active Directory is all it takes.
How AS-REP Roasting Works
To understand the attack, you need to understand the piece of Kerberos it abuses.
Normal Kerberos authentication starts with an AS-REQ (Authentication Service Request) from the client to the Domain Controller. Before the DC will respond with a ticket, the client must include a pre-authentication timestamp encrypted with the user's password hash. This step proves the client knows the password without sending it in plaintext. The DC validates the timestamp, and if it checks out, issues an AS-REP (Authentication Service Reply) containing a Ticket Granting Ticket (TGT) and session key, both encrypted with the user's credentials.
Pre-authentication is what keeps unauthenticated attackers from requesting ticket material for arbitrary accounts. When it's disabled on an account, that protection is gone.
With DONT_REQ_PREAUTH set, an attacker can send an AS-REQ for that account without supplying proof of password knowledge or valid pre-authentication data. The Domain Controller skips the pre-authentication check and replies with an AS-REP. That reply contains a portion encrypted with the account's password hash, specifically the enc-part of the AS-REP, which is the krb5asrep hash type. The attacker captures this response and walks away with something they can crack offline using Hashcat or John the Ripper.
The attack doesn't require an existing domain account. It can be executed with no foothold in your environment, just network access to a Domain Controller on port 88. That's what separates it from Kerberoasting, which requires at least a valid domain user to request service tickets. AS-REP Roasting can be the first step in a compromise, not just a post-exploitation technique.
Whether it succeeds comes down entirely to password strength. A short, human-set password is cracked in minutes. A long, randomly generated password may never fall. Service accounts and legacy application accounts tend to have the worst hygiene, and they're the most common accounts with this setting enabled.
What Makes an Account Vulnerable
AS-REP Roasting has a single core requirement, but the risk level varies significantly depending on what else is true about the account. Here's what to look for.
DONT_REQ_PREAUTH is enabled. This is the only technical requirement. It's a flag on the UserAccountControl attribute. Any account with this bit set can be targeted without credentials. In Active Directory Users and Computers, it shows up as 'Do not require Kerberos preauthentication' under Account Options. It's easy to miss because it sits quietly in the account properties with no expiration, no rotation, and no built-in alerting.
The password is weak or old. An account with DONT_REQ_PREAUTH and a strong, long, recently rotated password is a low practical risk. An account with the same flag and a password set in 2019 that has never expired is a different story. Service accounts are the usual offenders, created for an application, set with a password that met the policy minimum at the time, and excluded from password expiration so the app doesn't break.
The account carries elevated privilege. A vulnerable account with no meaningful access is a cleanup item. A vulnerable account in Domain Admins or with broad delegation rights is a critical finding. Privilege level is the primary triage factor. If a cracked account can do damage, it needs to be addressed immediately.
The account has broad access to sensitive systems. Even without formal group membership, some accounts carry significant access through direct ACL assignments, membership in application-specific groups, or delegation rights. Always check what an account can actually reach, not just which built-in groups it belongs to.
In practice, the accounts that show up most often are legacy application service accounts, accounts for products that predate modern Kerberos support, and accounts created by vendors during initial deployment and never revisited. These are the ones to focus on first.
Finding Vulnerable Accounts with PowerShell
The goal here is to find every account with DONT_REQ_PREAUTH enabled, evaluate their password hygiene, and identify which ones carry elevated privilege. All of this is read-only, nothing is changed.
Basic Enumeration
Start with the simplest query. This finds every enabled user account with the DONT_REQ_PREAUTH flag set:
This gives you the full list. In a small environment you might get two or three accounts. In a larger one you may find a dozen. Either way, this is your starting point.
Adding Password Age
Password age is one of the most important signals. Add a calculated column:
Checking Group Membership for Privilege
Knowing an account has DONT_REQ_PREAUTH is one thing. Knowing it's in Domain Admins is another. Add a group membership check to separate low risk findings from high-risk ones:
Putting It Together, Export to CSV
Once you have the full picture, export it for review and documentation:
Run this on any domain-joined machine with the Active Directory module loaded. No elevated privileges are required to query this data, which is exactly what makes this attack viable for any attacker who gets a foothold in your environment.
Interpreting What You Find
Running the script is the easy part. What you do with the results is where most reviews stall. Here's how to triage what you're looking at.
Start with privilege. Any account with DONT_REQ_PREAUTH that is a member of Domain Admins, Enterprise Admins, Schema Admins, or another tier-zero group is an immediate priority. These need to be addressed before everything else. In most environments I've reviewed, finding a privileged account with this setting is rare but not impossible, and when it's there, it's a critical finding.
Check the password age. The PasswordAgeDays column tells the story. A service account with DONT_REQ_PREAUTH and a password set four years ago is a high priority regardless of its group membership. Combined with PasswordNeverExpires = True, you have an account that has been sitting with the same crackable hash for years with no rotation ever planned.
Look at the account's purpose. Some accounts with this flag have a legitimate technical reason for it, legacy applications, certain backup agents, some VoIP systems. Others were set up by vendors during deployment and forgotten. For anything you can't immediately identify, track down the application owner before making changes. Disabling the account or re-enabling pre-authentication may break authentication for a running service.
Stale accounts are easy wins. Any account you identify as belonging to a decommissioned service or application is a zero-effort remediation. Disable the account and confirm nothing breaks. The risk is immediately eliminated.
A simple way to prioritize your findings:
Priority | Criteria |
|---|---|
Critical | Account with DONT_REQ_PREAUTH + member of privileged group (Domain Admins, etc.) |
High | DONT_REQ_PREAUTH + password never expires + password age over 1 year |
High | DONT_REQ_PREAUTH + password age over 1 year |
Medium | DONT_REQ_PREAUTH + password age under 1 year + not privileged |
Low | Work through them in that order. The goal isn't to fix everything at once — it's to make sure the highest risk accounts get addressed first. |
Work through them in that order. The goal isn't to fix everything at once, it's to make sure the highest risk accounts get addressed first.
Remediation
Finding vulnerable accounts is only half the job. Here's how to actually reduce the risk, starting with the highest impact changes.
Re-Enable Kerberos Pre-Authentication
The most direct fix is also the most effective. If there's no current technical requirement for the setting, re-enable pre-authentication. This immediately removes the account as an AS-REP Roasting target. The account is no longer attackable from outside the domain without credentials.
Before making this change, confirm the application or service that required the setting is still active and whether it still needs it. Older versions of some products required pre-auth to be disabled, but most modern versions support it. Test the change in a non-production environment first if the account is associated with a running service.
Reset Passwords to a Strong Length
For any account where DONT_REQ_PREAUTH must remain enabled, password length is the primary control. A 25+ character randomly generated password makes offline cracking computationally impractical even with modern hardware. Use a password manager or PAM solution to generate and store these.
After changing a service account password, make sure the associated service, scheduled task, or application pool is updated immediately. A password change without updating the service will cause authentication failures.
Disable or Remove Stale Accounts
For any account associated with a decommissioned application or service, disable it first and wait to confirm nothing breaks before deleting it. A disabled account with DONT_REQ_PREAUTH is still technically queryable but cannot be used for lateral movement. Full deletion removes the risk entirely.
Remediation Priority
Work through your findings in this order:
Re-enable pre-authentication on any account where it's no longer technically required.
Disable or remove accounts associated with decommissioned services.
Reset passwords to 25+ characters on any remaining accounts where the setting must stay enabled.
Document every account where DONT_REQ_PREAUTH must remain, who owns it, and why.
Schedule a quarterly review to catch new accounts before they become a long-standing exposure.
Don't try to fix everything at once. In a production environment, service account changes carry real risk of outage if they're not coordinated with application owners. Work the critical and high findings first, document the rest, and build a remediation plan with realistic timelines.
Detection: Is It Happening Right Now?
Remediation takes time. While you're working through your findings, it's worth knowing whether someone is already taking advantage of what you have. AS-REP Roasting does leave traces in your event logs, and unlike Kerberoasting, there's a particularly clean detection signal.
Event ID 4768, Kerberos Authentication Service Request
Every AS-REQ generates a 4768 event on your Domain Controllers. This event logs the account name, client address, and ticket encryption type. For AS-REP Roasting, the key indicator is an AS-REQ with no pre-authentication data, specifically, Failure Code 0x0 combined with an unauthenticated request pattern, or more directly, successful AS-REP responses issued to accounts with DONT_REQ_PREAUTH where the source is unexpected.
The most reliable detection approach is correlation: watch for 4768 events targeting your DONT_REQ_PREAUTH accounts from sources that don't match normal usage patterns. A workstation or IP that has never previously accessed a given service account and suddenly requests an AS-REP is worth investigating.
Make sure Advanced Audit Policy is configured to log Kerberos Authentication Service events on your Domain Controllers. Once enabled, you can query for AS-REP events targeting your vulnerable accounts from PowerShell (requires elevated rights on the DC or remote event log access):
Deploy a Honeypot Account
One of the most effective detection techniques requires almost no maintenance. Create a dedicated user account with DONT_REQ_PREAUTH enabled that has no legitimate purpose. Nothing in your environment should ever request an AS-REP for it. Any 4768 event targeting that account is an immediate indicator of enumeration activity.
A single hit on this account is enough to start an investigation. Feed these events into a SIEM or build a scheduled task that alerts on any 4768 targeting your honeypot account name.
What to Do When You See It
If you identify active AS-REP Roasting activity in your environment, the immediate priorities are:
Identify the source IP and workstation from the IpAddress field in the 4768 events.
Disable the source account and isolate the workstation pending investigation.
Reset passwords immediately on all accounts with DONT_REQ_PREAUTH enabled, regardless of whether they were directly targeted.
Review what the targeted accounts have access to and determine whether any credentials may have already been compromised and used.
Detection without response is just watching. If you have the logging in place, make sure someone is actually reviewing it, or feed these events into a SIEM with an alert on 4768 events targeting your known DONT_REQ_PREAUTH accounts or honeypot.
Full Audit Script
This section pulls everything together into a complete PowerShell audit script you can run on a schedule. The script finds all accounts with DONT_REQ_PREAUTH enabled, assigns a risk tier based on privilege and password hygiene, and exports a dated CSV to C:\Reports.
What the Script Does
Enumerates every enabled user account with DONT_REQ_PREAUTH set using a direct LDAP filter.
Calculates password age in days from PasswordLastSet.
Checks group membership against a configurable list of privileged groups.
Assigns a risk tier of Critical, High, Medium, or Low based on privilege + password age + password expiration.
Exports a dated CSV to C:\Reports for review, documentation, and tracking over time.
Suggested Cadence
Run this every 6 months as part of a regular AD security review. Accounts get created, pre-authentication gets disabled for new applications, and password hygiene drifts. A monthly check keeps you ahead of it. If your environment has a change management process, also run it after any major application deployment or AD infrastructure change.
Conclusion
AS-REP Roasting isn't talked about as often as Kerberoasting, but it's arguably more dangerous. It requires no domain credentials. Any attacker with network access to port 88 on a Domain Controller can run it. And in most environments, the accounts vulnerable to it were configured years ago and haven't been reviewed since.
The good news is that it's one of the more straightforward risks to address. A single LDAP filter finds every vulnerable account in your environment in seconds. The remediation path is clear: re-enable pre-authentication where you can, reset passwords to a length that makes offline cracking impractical where you can't, and eliminate stale accounts that have no business still existing. None of that requires expensive tooling or a security team.
The environments that get hurt are the ones where nobody looked. Run the audit script, work through the findings by risk tier, put the detection logging in place, and deploy a honeypot account so you'll know immediately if someone starts enumerating your environment. That combination, find it, fix it, detect it, is what actually improves your security posture.
If you found this useful, check out my related post on Kerberoasting for the SPN-side of the credential attack picture, and the Active Directory Trust Security article for a deeper look at how trust configurations can expand your attack surface beyond a single domain.
Comments