Active Directory AS-REP Roasting Privileged Service Accounts: The Accounts Pre-Auth Was Supposed to Protect

Active directory AS-REP roasting privileged service accounts is the higher-stakes case this piece covers: Kerberos accounts with pre-authentication disabled that also happen to sit in a privileged group or run as a service account, not a random standard user.

Active Directory AS-REP Roasting Privileged Service Accounts

The EtcSec catalogue tracks the privileged-account case separately as ADMIN_ASREP_ROASTABLE (Critical), because an account already sitting in Domain Admins, Enterprise Admins, or another Tier 0 group with this flag set turns AS-REP roasting into a direct-to-DA offline cracking race, not a multi-step lateral-movement chain. For the general any-account version of this attack, see AS-REP Roasting: Harvesting Hashes Without Credentials — this piece is scoped narrower, to the privileged and service-account cluster that piece doesn't tag.

The underlying flag is DONT_REQ_PREAUTH (0x400000 / decimal 4194304) in the userAccountControl attribute (Microsoft Learn: UserAccountControl property flags). When it's set, any client can request a Kerberos Authentication Server Reply (AS-REP) for that account, and the reply comes back with a portion encrypted using a key derived from the account's password — without the client ever proving it knows that password. MITRE ATT&CK T1558.004 tracks this as "Steal or Forge Kerberos Tickets: AS-REP Roasting."

Most generic write-ups treat this as a one-size-fits-all user-account hygiene item. That framing misses why two specific clusters matter more:

• Privileged accounts without pre-auth (ADMIN_ASREP_ROASTABLE, Critical) — Tier 0 group membership plus a roastable hash.
• Service accounts with the adjacent misconfiguration cluster — no pre-auth (SERVICE_ACCOUNT_NO_PREAUTH), allowed to log on interactively (SERVICE_ACCOUNT_INTERACTIVE), and running on a password that hasn't rotated in over a year (SERVICE_ACCOUNT_OLD_PASSWORD). Each is High severity alone; together they mean the hash is easy to obtain and, once cracked, stays valid for a long time on an account that can also be abused for interactive access.

Why the Flag Ends Up Set on Real Accounts

DONT_REQ_PREAUTH is rarely set out of malice — it's usually a leftover from a specific compatibility need that was never cleaned up. Documented causes include cross-domain SIDHistory migrations, where some third-party VPN or federation solutions fail to complete Kerberos pre-authentication for migrated identities unless the flag is temporarily disabled during cutover (Quest support KB 4313059), and legacy application or appliance compatibility, where an older Kerberos client library can't handle pre-authentication at all (Tenable: How to Stop the Kerberos Pre-Authentication Attack; JumpCloud: What Is Kerberos Pre-Authentication?). The migration or the legacy appliance gets decommissioned; the flag stays flipped on the account indefinitely because nothing ever re-checks it.

How It Works

Kerberos pre-authentication exists specifically to stop this class of attack: the client has to encrypt a timestamp with a key derived from its password and send it in the AS-REQ before the KDC issues anything. Skip that requirement, and the sequence collapses to four steps: the attacker sends an AS-REQ for the target username with no password and no prior domain authentication required, as long as the account is enumerable (LDAP, RPC, or a leaked username list); the KDC replies immediately with an AS-REP because pre-authentication isn't required; part of that AS-REP is encrypted with a key derived from the account's password; and the attacker cracks that portion offline, with no domain-side logging of failed password guesses, since every guess happens on the attacker's hardware, not against the DC.

Cracking speed depends on the negotiated Kerberos encryption type. If the account still allows RC4 (etype 23), the attacker requests RC4, and hashcat mode 18200 ($krb5asrep$23$...) cracks it orders of magnitude faster than an AES-256 (etype 18) response would. RC4 fallback is worth closing at the same time — see Kerberos RC4 Fallback in Active Directory for that detection and removal path.

The Attack Chain

AS-REP roasting rarely stands alone in a real compromise. A published walkthrough of the ShadowGate lab from Hack Smarter Labs — "ShadowGate Active Directory Lab Walkthrough" by incoggeek — lays out a chain that starts with anonymous SMB enumeration, moves into AS-REP roasting as the first credentialed step, then pivots into BloodHound-mapped ACL abuse (a GenericWrite grant abused via Shadow Credentials) and AD CS enrollment attacks (ESC8, via PetitPotam-coerced authentication to the CA's web enrollment endpoint) on the way to a Domain Controller certificate. AS-REP roasting is what turns a fully unauthenticated foothold into the first crackable secret in that chain — the same reason Active Directory Attack Paths to Domain Admin treats an early Kerberos-roasting step as a pivotal edge, and exactly why an ADMIN_ASREP_ROASTABLE finding on a Tier 0 account is scored Critical rather than treated as routine hygiene.

Step 1 — Enumerate and request

# Impacket -- enumerate every account in usersfile.txt that has pre-auth disabled
# and dump crackable AS-REP hashes without any valid domain credentials
impacket-GetNPUsers CORP.LOCAL/ -no-pass -usersfile usersfile.txt -format hashcat -outputfile asrep_hashes.txt

Step 2 — Crack offline

# Crack the resulting $krb5asrep$23$... hashes offline (mode 18200 = Kerberos 5, AS-REP, etype 23)
hashcat -m 18200 asrep_hashes.txt rockyou.txt

Detection

The single highest-confidence signal is Windows Security Event ID 4768 (Kerberos Authentication Ticket request) with Pre-Authentication Type 0, which only occurs legitimately when the target account has pre-auth disabled (MITRE ATT&CK Detection Strategy DET0113; HackTheBox: AS-REP roasting detection). Pair it with the negotiated encryption type: 0x17 (RC4) alongside Pre-Auth Type 0 is the strongest combined indicator, since an attacker deliberately downgrades to RC4 to speed up offline cracking. For the broader audit-policy and event-ID baseline this detection sits on top of, see Active Directory Monitoring: Security Event IDs That Matter.

Two PowerShell queries cover the catalogue-gap detectors directly:

# Privileged accounts with pre-auth disabled (ADMIN_ASREP_ROASTABLE candidates)
Get-ADUser -Filter {(userAccountControl -band 4194304) -and (adminCount -eq 1)} `
    -Properties userAccountControl, adminCount, ServicePrincipalName, MemberOf |
    Select-Object Name, DistinguishedName, ServicePrincipalName

# Service accounts (SPN-bearing) with pre-auth disabled, plus password age
Get-ADUser -Filter {(userAccountControl -band 4194304) -and (ServicePrincipalName -like '*')} `
    -Properties ServicePrincipalName, PasswordLastSet, LastLogonDate |
    Select-Object Name, ServicePrincipalName, PasswordLastSet,
        @{N='PasswordAgeDays';E={(New-TimeSpan -Start $_.PasswordLastSet -End (Get-Date)).Days}}

SERVICE_ACCOUNT_INTERACTIVE isn't a userAccountControl flag — it's a behavioral finding. Confirm it by correlating the service account's sAMAccountName against 4624 events with Logon Type 2 (Interactive) or 10 (RemoteInteractive/RDP). A genuine service account should only ever show Logon Type 3 (Network) or 5 (Service).

Remediation

For privileged accounts

Unset the flag: uncheck "Do not require Kerberos preauthentication" on the account's Account tab, or run Set-ADAccountControl -Identity <account> -DoesNotRequirePreAuth $false. Re-run the detection query above and confirm it returns zero rows. If the account was flagged because of a past SIDHistory migration or federation cutover, confirm that migration is fully complete — including SIDHistory cleanup — before flipping the flag back, so pre-auth doesn't break a still-active dependency.

For service accounts

1. Migrate roastable service accounts to gMSA. Group Managed Service Accounts rotate a 120-character password automatically and cannot be used for interactive logon by design, closing SERVICE_ACCOUNT_OLD_PASSWORD and SERVICE_ACCOUNT_INTERACTIVE in the same move. See gMSA Password Exposure in Active Directory for the caveats on who can still read a gMSA's password once it's deployed.
2. Restrict interactive logon explicitly. Where an account can't move to gMSA yet, apply "Deny log on locally" and "Deny log on through Remote Desktop Services" via GPO scoped to the service-account OU, and restrict "Log on as a service" to the specific hosts that actually need it.
3. Rotate the password and enforce Kerberos AES. Set a strong, unique password now, and put the account under a password policy or Fine-Grained Password Policy that actually enforces rotation instead of leaving it static for a year or more. Separately, enforce AES over RC4 via "Network security: Configure encryption types allowed for Kerberos" — this doesn't fix a missing pre-auth requirement, but it raises the cracking cost of every ticket the account negotiates legitimately.
4. Don't reach for Protected Users as the fix. The Protected Users security group is the right control for human privileged accounts, but Microsoft explicitly advises against adding service or computer accounts to it: membership blocks credential caching, so a service account that can't reach a DC even briefly will fail outright. Membership also does not clear the DONT_REQ_PREAUTH flag — a service account left in the group with that flag still set is exactly as roastable as before. See Active Directory Privileged Accounts: Protected Users, Delegation, and Service Account Gaps for where this group does and doesn't apply.

How EtcSec Detects This

EtcSec's Active Directory audit checks for this cluster directly: ADMIN_ASREP_ROASTABLE flags privileged-group members with Kerberos pre-authentication disabled, SERVICE_ACCOUNT_NO_PREAUTH covers the same flag on any SPN-bearing service account, SERVICE_ACCOUNT_INTERACTIVE flags service accounts observed or configured for interactive logon, and SERVICE_ACCOUNT_OLD_PASSWORD flags service accounts whose password hasn't rotated within policy. None of these require a live attack simulation — they're LDAP-attribute and logon-behavior checks that run in every audit pass.