Detecting and Mitigating AS-REP Roasting (T1558.004)

Kerberos preauthentication is a small check with a big job. It makes a user prove they know their password before the domain controller hands anything back. Turn it off for an account and the domain controller will give crackable data to anyone who asks. AS-REP Roasting (T1558.004) is a Windows Credential Access technique and a subtechnique of Steal or Forge Kerberos Tickets.

How attackers use it

MITRE describes the normal flow. With preauthentication on, a user sends an Authentication Server Request (AS-REQ) with a timestamp encrypted with the hash of their password. Only if the domain controller can decrypt that timestamp does it send an Authentication Server Response (AS-REP) containing the ticket-granting ticket. Part of the AS-REP is signed with the user's password.

For each account found without preauthentication, an adversary can send an AS-REQ with no encrypted timestamp and receive AS-REP data that may be encrypted with an insecure algorithm such as RC4. That data can be cracked offline, similar to Kerberoasting, and may expose plaintext credentials.

Any domain-registered account, privileged or not, can be used to list the accounts that have preauthentication disabled, for example with PowerShell and an LDAP filter. Alternatively the adversary can send an AS-REQ for each user and see which ones the domain controller answers without error.

How to detect it

MITRE's analytic watches for:

• Event ID 4768 where the Pre-Auth Type is 0.
• Follow-on service ticket requests (event ID 4769).
• Requests using weak RC4 encryption, etype 0x17.
• Excessive enumeration of accounts that have the "Do not require Kerberos preauthentication" setting.

How to reduce the risk

MITRE lists three mitigations.

1. Audit. Preauthentication is enabled by default. Older protocols may not support it, so the setting can end up disabled. Make sure all accounts use preauthentication wherever possible, and audit changes to the setting. PowerShell makes it easy to find accounts with it disabled.
2. Password policies. Use long, complex service account passwords that expire, and consider Group Managed Service Accounts or a vault.
3. Encrypt sensitive information. Enable AES Kerberos encryption rather than RC4 where possible.

Why accounts end up without preauthentication

MITRE notes that preauthentication is on by default and that older protocols might not support it. That is the usual story. An old application or appliance could not do preauthentication, so an administrator unchecked the box to make it work, and the setting stayed. Years later the application is gone and the exception is still there.

So the fix is part technical and part archaeology. For each account the earlier query returns, find the owner, find the system, and ask whether it still needs the exception. Where it does, give the account a long random password, which makes offline guessing impractical, and watch it specifically.

Also add a control for the future. Audit changes to the setting, as MITRE advises, so that a new exception triggers a review instead of silently appearing.

Check your own environment

# Windows: list accounts that do not require Kerberos preauthentication (Active Directory module, read-only)
Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth | Select-Object SamAccountName,Enabled

For each account returned, decide whether the legacy system behind it can be fixed. If it cannot, give the account a very long password and monitor event 4768 for it specifically.

Quick check

Sources

• MITRE ATT&CK T1558.004: AS-REP Roasting