Detecting Kerberoasting and AS-REP Roasting From Windows Logs: A Practical Detection Playbook

Guest contribution by Canio Campaniello, founder of Hackita.it.

Why these two attacks matter to defenders

Two Active Directory attacks keep appearing in intrusion reports because they need no special privileges. Kerberoasting and AS-REP roasting both let an attacker who already holds one ordinary domain account request Kerberos data from a domain controller, take it away, and crack it offline. If the password behind it is weak, the attacker walks away with the credentials of a service account or a user, and no failed logon is ever recorded.

The MITRE ATT&CK entries for Kerberoasting (T1558.003) and AS-REP Roasting (T1558.004) describe how cracked credentials then support persistence, privilege escalation and lateral movement through valid accounts. Because the cracking happens off the network, prevention depends on strong passwords and modern encryption, and detection depends on reading the right events on the domain controllers.

This playbook explains what each attack leaves in the logs, how to query for it, how to reduce false positives and what to fix so that a stolen ticket is worthless.

Kerberoasting in one paragraph

Any authenticated domain user can ask a domain controller for a service ticket for any service principal name (SPN). Part of that ticket is encrypted with a key derived from the service account's password. If the account uses RC4 encryption, the attacker can try password guesses against the ticket offline. MITRE's detection guidance for this technique is to monitor Event ID 4769 for RC4 encryption (encryption type 0x17), unusual numbers of service ticket requests from one account in a short time, and service accounts used outside their normal baselines.

AS-REP roasting in one paragraph

Normally a user must prove knowledge of the password (pre-authentication) before the domain controller issues a ticket-granting ticket. If an account has "Do not require Kerberos preauthentication" enabled, anyone can request data for that account without proof, and part of the response can be cracked offline. MITRE points defenders to Event ID 4768 with Pre-Auth Type 0, correlated with later service ticket activity, and to RC4 usage.

What the log events look like

Microsoft's documentation on Event 4769 lists the fields that matter:

• ServiceName: the account or computer the ticket was requested for.
• TicketEncryptionType: 0x12 (AES256) and 0x11 (AES128) are expected on modern systems. 0x17 is RC4. Microsoft states that anything other than 0x11 or 0x12 is unexpected on modern systems.
• TargetUserName: the requesting account.
• IpAddress: the source of the request.
• Status: 0x0 means success.

These events are logged on domain controllers, so the Kerberos audit policy must be enabled there and the logs must reach your SIEM.

Step 1: Hunt for RC4 service tickets

The PowerShell below reads the Security log on a domain controller from the last 24 hours and lists service ticket requests that used RC4, ignoring computer accounts:

$events = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=(Get-Date).AddHours(-24)} |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    foreach ($n in $x.Event.EventData.Data) { $d[$n.Name] = $n.'#text' }
    [pscustomobject]@{
      Time    = $_.TimeCreated
      Account = $d['TargetUserName']
      Service = $d['ServiceName']
      EType   = $d['TicketEncryptionType']
      Client  = $d['IpAddress']
    }
  } |
  Where-Object { $_.EType -eq '0x17' -and $_.Service -notlike '*$' }

$events | Format-Table -AutoSize

Adapt the query to your environment. Run it once to see your baseline: old applications and a few legacy accounts may legitimately use RC4, and those become your allow-list.

Step 2: Look for volume, not only encryption type

Attackers who roast many accounts request many tickets quickly. Group the same results by requesting account and count the distinct services:

# Reuse the $events collected in Step 1
$events | Group-Object Account |
  ForEach-Object {
    [pscustomobject]@{
      Account  = $_.Name
      Tickets  = $_.Count
      Services = ($_.Group.Service | Sort-Object -Unique).Count
    }
  } | Sort-Object Services -Descending

A single user requesting tickets for many different services within minutes is the pattern MITRE describes. Normal users request tickets for a handful of services a day.

Step 3: Find accounts exposed to AS-REP roasting

Detection is better when you remove the exposure first. This query lists accounts that do not require pre-authentication:

Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth |
  Select-Object SamAccountName, Enabled

Each result should have a documented reason. Often none exists, and clearing the setting is a quick win. For the remaining ones, alert on Event ID 4768 where pre-authentication type is 0, and follow it with a check for 4769 events from the same client address.

Step 4: Add context so the alert is usable

A raw event is not an alert. Add context before it reaches an analyst:

• Source host: is the client address a workstation, a server or an unknown device?
• Account type: is the requested service a high-value account, such as one in a privileged group?
• Time: does the request fall outside the account's normal hours?
• Follow-up activity: does the same host later access LDAP heavily or touch the LSASS process? Correlating ticket anomalies with suspicious process activity is common practice.

Severity should rise when several signals combine: RC4 request, many services, unusual source and a privileged target.

Step 5: Remove the reward

Detection should not be your only control. Between them, the two ATT&CK pages list these mitigations:

• Use AES Kerberos encryption instead of RC4 wherever possible.
• Give service accounts long, random passwords, ideally 25 characters or more.
• Prefer group Managed Service Accounts (gMSA) or a vault, so nobody has to remember or reuse a password.
• Keep service accounts out of privileged groups such as Domain Admins.
• Audit and keep Kerberos pre-authentication enabled.

If a roasted ticket belongs to an account with a 30-character random password and AES encryption, the attacker's offline effort is wasted, and your alert becomes a signal rather than an emergency.

How to test your detections safely

Detections that have never fired are assumptions. In a lab domain you own, register a test SPN on a test service account with setspn, request a ticket for it with klist get, then check that the 4769 event appears and that your query and SIEM rule fire. Test only in environments you own or are authorised to assess.

A short operating checklist

• Enable Kerberos service ticket auditing on every domain controller and forward the logs.
• Baseline RC4 use and document the exceptions.
• Alert on RC4 service tickets for non-exception accounts.
• Alert on one account requesting tickets for many services in a short time.
• List and justify every account without pre-authentication.
• Move service accounts to AES, long passwords and gMSA.
• Test each rule in a lab and re-test after every Active Directory change.

Conclusion

Kerberoasting and AS-REP roasting are quiet because they use normal protocol features. They are also very detectable, because the domain controller records every request. A few well-chosen queries on events 4768 and 4769, a baseline of who legitimately uses RC4, and strong service-account passwords turn these attacks from a silent path to a loud, low-value one.

If you are deciding where these detections should live, our SIEM vs XDR decision guide compares the options, and our Threat Ops page describes the detection and hunting coverage BlueRadius runs for clients.

Sources

1. MITRE ATT&CK, T1558.003: Steal or Forge Kerberos Tickets: Kerberoasting
2. MITRE ATT&CK, T1558.004: Steal or Forge Kerberos Tickets: AS-REP Roasting
3. Microsoft, 4769(S, F): A Kerberos service ticket was requested

Canio Campaniello is the founder of Hackita.it, an ethical hacking education platform. He studies computer science at the University of Naples Federico II and does lab-based offensive security research and bug bounty work.