Detecting Kerberoasting with PowerShell and logs

Kerberoasting is an Active Directory attack technique where an attacker requests Kerberos service tickets (TGS) for accounts that have Service Principal Names (SPNs), then cracks the ticket offline to recover the service account password. Because it uses legitimate Kerberos flows, the key to detection is understanding what “normal” looks like for service ticket requests—and alerting on the patterns that don’t match.

If you want a refresher on how Kerberos fits into AD authentication, start with NTLM authentication and Kerberos Authentication Protocols Explained and the broader user authentication and user authorization process.

What Kerberoasting “Looks Like”

In a typical Kerberoast, the attacker (often a normal domain user) enumerates SPNs and then requests service tickets for one or many SPNs. The offline cracking happens elsewhere, so your best signals are:

• Unusual volume of Kerberos service ticket requests from a user or host (bursty TGS requests).
• Unusual targets (requesting tickets for many service accounts, or high-value services they don’t normally use).
• Unusual encryption types (e.g., RC4/HMAC requests in environments where AES is expected).
• SPN changes (attackers may add an SPN to an account they control, then request a ticket for it).
• Endpoint execution clues (PowerShell script blocks, suspicious processes like Rubeus/Kekeo, etc.).

Logs You Need (and Where to Collect Them)

You can detect Kerberoasting with built-in Windows logs, but the detection quality depends on the right audit configuration and reliable log collection from Domain Controllers (DCs).

Key Windows Event IDs

Event ID	Where	Why it matters
4769	DC Security log	Kerberos service ticket (TGS) request — primary signal for Kerberoasting hunting.
4768	DC Security log	Kerberos TGT request — helps with session context and correlation (not the roast itself).
4771	DC Security log	Kerberos pre-auth failures — can help spot password spraying, misconfigs, or noisy attackers.
5136	DC Security log (Directory Service Changes)	Directory attribute changes — use to detect SPN additions/modifications.
4738 / 4742	DC Security log	User/computer changes — sometimes useful pivots around account modifications.

Audit policy essentials

• Enable Audit Kerberos Service Ticket Operations (Success) so you reliably capture 4769 on DCs.
• Enable Directory Service Changes to capture attribute modifications like servicePrincipalName (e.g., 5136).
• Centralize DC logs (WEF, SIEM, or similar). If you’re using Microsoft Defender for Identity, make sure DC event collection is configured correctly: Event collection with Microsoft Defender for Identity.

Practical Detection Strategy

1) Baseline normal TGS behavior

Start by answering: which users normally request which service tickets, and how many per hour/day? Most environments have predictable patterns: workstation users request a handful of tickets for common services, while app servers and automation identities may request more.

• Baseline by requesting user
• Baseline by client host / source IP
• Baseline by service name (SPN)
• Baseline by encryption type (RC4 vs AES mix)

2) Alert on suspicious patterns

High-signal patterns for Kerberoasting include:

• Burst requests: A single user requests many distinct service tickets in a short time window.
• Wide SPN sweep: A user requests tickets for lots of different SPNs they don’t normally access.
• RC4-heavy tickets: Many TGS requests where the ticket encryption type is RC4 (common in older or misconfigured service accounts).
• “New” SPNs: An SPN attribute change followed by immediate TGS requests for that SPN.

Hunting Kerberoasting with PowerShell (DC Security Logs)

The scripts below are designed for investigation and detection engineering. Run them from a machine that can query DC Security logs (permissions required), or adapt them to your centralized log platform.

Step 1: Pull 4769 events from all DCs

# Requires RSAT ActiveDirectory module on the machine running this
Import-Module ActiveDirectory

$start = (Get-Date).AddHours(-24)
$dcs = (Get-ADDomainController -Filter * | Select-Object -ExpandProperty HostName)

$events = foreach ($dc in $dcs) {
  Get-WinEvent -ComputerName $dc -FilterHashtable @{ LogName='Security'; Id=4769; StartTime=$start } -ErrorAction SilentlyContinue |
    ForEach-Object {
      $xml = [xml]$_.ToXml()
      $data = @{}
      foreach ($d in $xml.Event.EventData.Data) { $data[$d.Name] = $d.'#text' }

      [pscustomobject]@{
        TimeCreated          = $_.TimeCreated
        DC                   = $dc
        TargetServiceName    = $data['ServiceName']
        TargetServiceAccount = $data['TargetUserName']
        RequestingUser       = $data['SubjectUserName']
        RequestingDomain     = $data['SubjectDomainName']
        ClientAddress        = $data['IpAddress']
        TicketEncryptionType = $data['TicketEncryptionType']
        TicketOptions        = $data['TicketOptions']
        Status               = $data['Status']
      }
    }
}

$events | Sort-Object TimeCreated | Select-Object -First 20

Step 2: Find bursty users (high volume in the last 24 hours)

# Tune the threshold based on your baseline (start conservative, then refine)
$threshold = 200

$events |
  Group-Object RequestingUser |
  ForEach-Object {
    $svcCount = ($_.Group | Select-Object -ExpandProperty TargetServiceName -Unique).Count
    [pscustomobject]@{
      RequestingUser = $_.Name
      Total4769      = $_.Count
      UniqueServices = $svcCount
      FirstSeen      = ($_.Group | Sort-Object TimeCreated | Select-Object -First 1).TimeCreated
      LastSeen       = ($_.Group | Sort-Object TimeCreated | Select-Object -Last 1).TimeCreated
    }
  } |
  Where-Object { $_.Total4769 -ge $threshold -or $_.UniqueServices -ge 40 } |
  Sort-Object Total4769 -Descending

Step 3: Show which SPNs a suspicious user is targeting

$suspect = "jdoe"  # set this

$events |
  Where-Object { $_.RequestingUser -ieq $suspect } |
  Group-Object TargetServiceName |
  Sort-Object Count -Descending |
  Select-Object Count, Name -First 30

Step 4: Flag RC4-heavy tickets (common Kerberoast cracking target)

In many environments, you’ll see encryption type values like 0x17 (RC4-HMAC). The exact representation can vary by parsing, policy, and OS. The goal here is not perfection—it’s surfacing anomalies to investigate and then tuning.

# Common RC4 indicator for TicketEncryptionType in many 4769 payloads
$rc4Values = @("0x17","23")

$events |
  Where-Object { $rc4Values -contains $_.TicketEncryptionType } |
  Group-Object RequestingUser |
  Sort-Object Count -Descending |
  Select-Object -First 20 Name, Count

Step 5: Detect “SPN change → immediate TGS requests” (high-signal chain)

Attackers sometimes add an SPN to an account they control, then request a ticket for it. Monitor SPN modifications, then correlate with 4769 activity.

# Pull recent Directory Service Changes (5136) and look for servicePrincipalName changes
$start = (Get-Date).AddHours(-24)

$spnChanges = foreach ($dc in $dcs) {
  Get-WinEvent -ComputerName $dc -FilterHashtable @{ LogName='Security'; Id=5136; StartTime=$start } -ErrorAction SilentlyContinue |
    ForEach-Object {
      $xml = [xml]$_.ToXml()
      $data = @{}
      foreach ($d in $xml.Event.EventData.Data) { $data[$d.Name] = $d.'#text' }

      if ($data['AttributeLDAPDisplayName'] -eq 'servicePrincipalName') {
        [pscustomobject]@{
          TimeCreated  = $_.TimeCreated
          DC           = $dc
          ObjectDN     = $data['ObjectDN']
          Attribute    = $data['AttributeLDAPDisplayName']
          SubjectUser  = $data['SubjectUserName']
          Operation    = $data['OperationType']
        }
      }
    }
}

# Pivot: if an SPN changed, inspect TGS requests around the change window
$change = $spnChanges | Sort-Object TimeCreated -Descending | Select-Object -First 1
$windowStart = $change.TimeCreated.AddMinutes(-30)
$windowEnd   = $change.TimeCreated.AddMinutes(30)

$events |
  Where-Object { $_.TimeCreated -ge $windowStart -and $_.TimeCreated -le $windowEnd } |
  Sort-Object TimeCreated |
  Select-Object TimeCreated, RequestingUser, ClientAddress, TargetServiceName, TargetServiceAccount, DC

How to Investigate a Suspected Kerberoast

1. Validate the requesting identity: Is the requesting user a normal workstation user, a service identity, or an admin? Do they usually access these services?
2. Check the source host: Are the TGS requests coming from a workstation that’s never done this before?
3. Check the target service accounts: Are they high-value (database, backups, SSO, management tools)? Do they have elevated rights?
4. Correlate endpoint telemetry: Look for suspicious process execution (4688/Sysmon), PowerShell Script Block logs (4104), or known tool indicators.
5. Check for SPN tampering: Any recent SPN additions or changes tied to unusual actors?

Response Playbook (When You Think It’s Real)

• Contain the source: isolate the host generating the suspicious TGS requests.
• Reset impacted service account credentials: prioritize those with privileged access.
• Review service account privileges: remove unnecessary group memberships, rights, and delegation.
• Hunt laterally: look for additional bursty 4769 patterns, endpoint artifacts, and persistence.
• Document and tune detections: convert the investigative pivots into repeatable alerts in your SIEM/Defender tooling.

Hardening That Makes Kerberoasting Harder

Detection is necessary, but the best outcome is that “roasting” yields nothing useful or takes too long to matter. Focus on service account hygiene and SPN governance.

• Prefer gMSA where possible (automatic password rotation and strong secrets).
• Use long, randomly generated passwords for service accounts and rotate on a schedule.
• Minimize privileged rights for service accounts (no Domain Admin, no unnecessary local admin spread).
• Control and monitor SPN writes: treat SPN modification as a high-risk permission. See: How to delegate OU permissions with minimal risk.
• Regularly review delegation and SPN exposure: understand where SPNs exist and why. The Active Directory Computer Delegation tab discussion is a useful primer on how services and SPNs relate operationally.

Common Pitfalls (So You Don’t Drown in False Positives)

• “High 4769 volume” isn’t always bad: app servers and middleware can legitimately request many tickets.
• Encryption type alone isn’t proof: treat RC4-heavy patterns as a clue, not a conviction.
• Missing baselines leads to alert fatigue: start with a few high-signal rules, then tune with real data.
• Short log retention breaks investigations: ensure DC security logs are forwarded and retained.

Related reading on windows-active-directory.com

• NTLM authentication and Kerberos Authentication Protocols Explained
• User authentication and user authorization process: An explanation
• Active Directory Computer Delegation tab
• Event collection with Microsoft Defender for Identity
• How to delegate OU permissions with minimal risk

FAQ

Does Kerberoasting always generate 4769?

If the attacker is requesting service tickets normally through Kerberos, you should see 4769 on DCs (with the right auditing enabled). The challenge is separating “normal Kerberos” from “Kerberoast-shaped Kerberos” using baselines and patterns.

Is RC4 required for Kerberoasting?

No. RC4 is a common cracking target, but service tickets can be requested with other encryption types too. Use encryption type as one feature among several, not the only trigger.

Can I detect Kerberoasting without endpoint telemetry?

You can often surface strong suspicions from DC logs alone (especially burst patterns and SPN change correlation), but endpoint telemetry helps confirm tooling and identify the originating process/user context faster.