AS-REP roasting: the checkbox that hands out hashes

Start with the exact answer. This is the query to keep, run weekly, and diff:

$out = 'C:\temp\preauth-inventory.csv'
Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth,
    PasswordLastSet, PasswordNeverExpires, ServicePrincipalName, LastLogonDate, Enabled |
  Select-Object SamAccountName, Enabled, PasswordLastSet, PasswordNeverExpires,
    ServicePrincipalName, LastLogonDate, DistinguishedName |
  Sort-Object SamAccountName |
  Export-Csv $out -NoTypeInformation

Where PowerShell isn't available (a Linux jump box, an appliance, a script that must not need RSAT), the LDAP filter does the same job:

ldapsearch -x -H ldaps://dc01.example.local -D '[email protected]' -W \
  -b 'DC=example,DC=local' \
  '(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))' \
  sAMAccountName userAccountControl pwdLastSet

If you already run BloodHound, these accounts are in its data with the paths attached, so the same question is one query away.

The DC-side signal is event 4768, "A Kerberos authentication ticket (TGT) was requested". Four fields do the work:

• PreAuthType: 0 means logon without pre-authentication; 2 is the normal encrypted timestamp.
• Status: 0x0, because a roast succeeds.
• ServiceName: krbtgt.
• TicketEncryptionType: 0x17 RC4, 0x11 AES128, 0x12 AES256.

The Sigma rule that does the rounds keys on all four, and it's worth reading before you trust it:

# excerpt: the metadata block is trimmed, the detection is verbatim
title: Potential AS-REP Roasting via Kerberos TGT Requests
id: 3e2f1b2c-4d5e-11ee-be56-0242ac120002
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4768
        TicketEncryptionType: '0x17'
        ServiceName: 'krbtgt'
        PreAuthType: 0
    condition: selection
level: medium

Two things make that second rule survivable. First, 4771 will not help you here: it is the pre-authentication failure event, and Microsoft's 4768 documentation says it is generated instead of 4768 when pre-authentication fails. A roast never fails pre-authentication, so nothing fires. Second, the account's legitimate logons look identical in PreAuthType, because that's the whole point of the flag. The signal isn't the field, it's the deviation: a name that never normally authenticates, appearing from a source address that has never asked for a TGT for it, often in a burst across several accounts.

One more shape worth hunting, and I'll flag it as my reading of the protocol rather than something Microsoft documents: the TGT a roast produces is never used. The session key lives inside the enc-part, which is encrypted with the account's password, so the attacker cannot turn the TGT into service tickets. In the logs that looks like a 4768 followed by nothing: no 4769 for that principal from that address. A real logon gets a TGT and then immediately goes shopping. A roast gets one and walks away.

For the attribute being flipped, two events and one prerequisite:

auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4738,4742,5136} -MaxEvents 200 |
  Where-Object Message -match 'userAccountControl'

And the check that tells you whether any of this has data behind it at all:

auditpol /get /subcategory:"Kerberos Authentication Service"

If you run Defender for Identity, the detection is built in: external ID 2412, triggered "when an attacker targets accounts with disabled Kerberos preauthentication" to obtain TGT data. Microsoft also ships the find-it-before-they-do half as a posture assessment row, "Remove Don't require Kerberos preauthentication", which is the same query you just ran, with a remediation column.

Run the inventory above and send each line to whoever owns the application. The question is not "can we clear this?", it's "what client software and version stops working if we do?". In most estates the answer is a shrug, because the flag was ticked during a troubleshooting session nobody remembers, for an application nobody can name. Some accounts will have a real answer, and those are the interesting ones.

This is the step that gets skipped, and it's the one that decides whether the change means anything.

• Clearing the flag does not invalidate a hash already captured. The AS-REP you (or an attacker) collected last month is encrypted with the key from the password in force at the time. It stays crackable offline until that password changes.
• Resetting the password does not clear the flag. Roast the account one second after your reset and you get a fresh blob against the new password.

So do both, in one change: clear the flag, reset the password, then verify both. If the account is a service with a fixed password, the rotation is the point at which you move it to 30-plus random characters, which is the next section.

In order of preference. Most of the legacy offenders can't take option one, which is why they are legacy.

Replace the account with a gMSA. Passwords for gMSAs are 120 characters, complex, randomly generated and rotated automatically, so even if somebody ticked the box on it, the hash is not crackable and the material goes stale. New-ADServiceAccount -Name gmsa-sql01 -DNSHostName gmsa-sql01.corp.example.com -PrincipalsAllowedToRetrieveManagedPassword 'SQL01$', then Install-ADServiceAccount on the host. Windows Server 2025 adds dMSA, which can supersede an existing service account instead of requiring a new one, so this is getting easier for the services that can't be rebuilt.

Keytab, AES only. Re-run ktpass with -crypto AES256-SHA1 rather than -crypto all, set msDS-SupportedEncryptionTypes to 24 (AES128 plus AES256, no RC4), then reset the password, because the AES keys are derived at password change. The application loads the keytab, not a password. This is the fix for the Alfresco pattern above, and for the SAML and Java SSO setups that inherit it.

Long random password plus containment. If it must keep both the flag and a password: 30-plus characters, generated, in the secret store, rotated on a schedule with a name against it. Then take away everything the account doesn't need. Not in Domain Admins, Enterprise Admins, Server Operators, Backup Operators or Account Operators. Logon restricted to the hosts that run the service, with deny logon locally and deny logon through Remote Desktop where the service allows it. The joint guide's line is the one to take to a change board: accounts that must bypass pre-authentication should get the minimum privileges they need and stay out of highly privileged groups like Domain Admins.

Two numbers worth having straight before you brief this, because the internet is sloppy about them. Microsoft's service account guidance says a 14-character minimum and recommends longer; the gMSA figure is 120. The CISA, NSA, NCSC-UK joint guide sets a 30-character minimum for service accounts. The widely repeated "25 characters" has no Microsoft page behind it that I could find, so use 30 and cite the joint guide.

AES-only makes the hash 700 to 1,400 times dearer per guess, which is real and worth having. It does not stop a weak password, and Microsoft says so in as many words: "AES alone is not a solution for brute forcing and needs to be used in combination with strong passwords."

Do it per account first, which is safe and reversible, and leave domain-wide policy alone until you have data:

Set-ADUser -Identity 'svc-legacyapp' -Replace @{ 'msDS-SupportedEncryptionTypes' = 24 }
# then reset the password so AES keys are derived

The remediation project ends, and then somebody follows a vendor guide. Two controls close that loop: a daily diff of the inventory (alert on any addition, not the total), and a 5136 subscription filtered to userAccountControl so you see the write when it happens rather than at the next audit.