Detecting Kerberoasting: A Practical Walkthrough with Sigma

Why this is still worth your time in 2026

Kerberoasting has been public since Tim Medin presented it in 2014, so it's tempting to file it under "solved." It isn't. CrowdStrike's 2025 Global Threat Report lists it among the top post-compromise techniques they observe, and IBM X-Force reported a roughly 100% year-over-year increase in Kerberoasting seen during incident-response engagements. The reason it persists is structural: the attack abuses how Kerberos is supposed to work, so there's no patch that makes it disappear.

There's also a 2026-specific wrinkle. Microsoft is finally retiring RC4: new Active Directory domains built on Windows Server 2025 have RC4 disabled by default as of Q1 2026. That's real progress — but existing domains keep RC4 enabled for backward compatibility unless an admin changes it. So for most organizations, the weak encryption that makes Kerberoasting fast is still sitting there, and detection still matters.

How the attack actually works

Kerberos lets any authenticated domain user request a service ticket (a TGS) for any account that has a Service Principal Name (SPN). That's not a bug — it's how a user gets access to, say, a SQL service. The catch is what's inside the ticket: a portion encrypted with a key derived from the service account's password.

1. The attacker, using any low-privilege domain account, enumerates accounts that have an SPN set (these are usually service accounts).
2. They request a TGS for one or more of those SPNs. The domain controller happily issues the tickets.
3. They extract the encrypted blob and crack it offline, on their own hardware, to recover the service account's plaintext password.
4. Because the cracking happens off the network, there are no failed logons, no account lockouts, and nothing to trip a brute-force alarm.

Service accounts are a juicy target precisely because they're often over-privileged, rarely rotated, and set up years ago with passwords that predate any modern policy. Crack one and you may inherit a foothold that's effectively permanent.

RC4 is the part that hurts

The crackability depends almost entirely on the ticket's encryption type. When a ticket is issued with RC4-HMAC (etype 0x17, decimal 23), the key is derived directly from the account's unsalted NT hash — fast to attack with a GPU. Modern cracking rigs running Hashcat exceed 100 billion guesses per second, so a weak service-account password falls in minutes.

AES tickets (0x11/AES-128 and 0x12/AES-256) are dramatically harder — on the order of tens of thousands of times more cracking effort — because of salting and key derivation. That's why Kerberoasting tooling frequently requests RC4 on purpose: the attacker downgrades to the weakest option the domain will hand out. That deliberate downgrade is your single best detection signal.

What you need flowing into your SIEM

Everything here keys off one Windows event generated on domain controllers: Event ID 4769 — "A Kerberos service ticket was requested." If you're not collecting it yet:

• Enable Audit Kerberos Service Ticket Operations (Success) via Group Policy: Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy → Account Logon.
• Make sure your collector ships the Security log from every domain controller — a Kerberoasting request can be serviced by any DC, so a gap on one DC is a blind spot.
• Expect volume. 4769 fires constantly during normal operation, which is why the filtering below matters as much as the matching.

The fields you'll lean on in each 4769 event:

Detection strategy

No single rule is a silver bullet. The reliable approach layers three detections, from highest-precision to broadest. This mirrors MITRE ATT&CK's own detection strategy for the technique (DET0157).

1. RC4 ticket requested in an AES environment (high precision)

If your domain functional level and accounts support AES, legitimate clients should almost never request RC4. So an RC4 4769 becomes a strong signal. We exclude computer accounts ($) and krbtgt, which generate benign RC4 traffic in many environments.

title: Kerberoasting - RC4 Service Ticket Requested
id: 8f1e2c33-6a4b-4d9e-9a1f-2b7c0d5e4a10
status: experimental
description: >
    A Kerberos TGS (Event 4769) was issued using RC4-HMAC encryption.
    In AES-capable domains this is a common indicator of Kerberoasting,
    where tooling downgrades to RC4 to ease offline cracking.
references:
    - https://attack.mitre.org/techniques/T1558/003/
    - https://umbrasec.dev/research/detecting-kerberoasting.html
author: UMBRASEC
date: 2026/06/10
tags:
    - attack.credential_access
    - attack.t1558.003
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4769
        TicketEncryptionType: '0x17'   # RC4-HMAC
        TicketOptions: '0x40810000'     # see tuning note - remove if too narrow
    filter_machine:
        ServiceName|endswith: '$'
    filter_krbtgt:
        ServiceName: 'krbtgt'
    filter_failures:
        Status: '0x1b'                  # only count issued tickets, drop S4U/failed
    condition: selection and not 1 of filter_*
falsepositives:
    - Legacy applications or appliances that genuinely require RC4
    - Some Linux/macOS or third-party Kerberos clients
    - Accounts whose msDS-SupportedEncryptionTypes still allow only RC4
level: medium

2. One account, many service principals (velocity / fan-out)

Roasting frameworks frequently pull tickets for every SPN they can find in one burst. A normal user touches a handful of services a day; an account requesting tickets for dozens of distinct SPNs in minutes is anomalous regardless of encryption type. This one is best expressed as an aggregation, so it's a natural fit for a Sigma correlation rule (or the equivalent stats query in your SIEM):

title: Kerberoasting - High Volume of Distinct SPN Requests
id: 1c9d4b77-2e55-4f01-bb3a-6d8e9f0a1b22
status: experimental
description: >
    A single account requested Kerberos service tickets (4769) for an
    unusually large number of distinct service principals in a short
    window - consistent with bulk Kerberoasting enumeration.
references:
    - https://attack.mitre.org/techniques/T1558/003/
author: UMBRASEC
date: 2026/06/10
tags:
    - attack.credential_access
    - attack.t1558.003
correlation:
    type: value_count
    rules:
        - kerberoasting_4769_base
    group-by:
        - TargetUserName
    timespan: 5m
    condition:
        gte: 15
        field: ServiceName
---
title: Kerberoasting 4769 base
id: 2d0e5c88-3f66-4012-cc4b-7e9f0a1b2c33
name: kerberoasting_4769_base
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4769
        Status: '0x0'
    filter_machine:
        TargetUserName|endswith: '$'
    condition: selection and not filter_machine

The gte: 15 threshold and 5m window are starting points, not gospel. Run it in report-only mode for a week, look at your top talkers (vulnerability scanners and monitoring accounts will show up — allowlist them), and set the threshold above your noisiest legitimate account.

3. The honeypot SPN (near-zero false positives)

This is the highest-value, lowest-effort detection in the whole post, and it deserves more attention than it gets. Create a decoy service account:

• Give it a tempting SPN (e.g. MSSQLSvc/sql-prod-01.corp.example:1433) so it shows up in any SPN enumeration.
• Make sure nothing legitimately uses it — no real service, no app config points at it.
• Give it a long, random password (so even if cracked, it's worthless) and minimal privileges.

Now any 4769 naming that account is suspicious by construction, because no honest workload ever requests its ticket. This converts a fuzzy anomaly problem into a binary alarm.

title: Kerberoasting - Honeypot SPN Ticket Requested
id: 3e1f6d99-4a77-4123-dd5c-8f0a1b2c3d44
status: experimental
description: >
    A Kerberos service ticket (4769) was requested for a decoy service
    account that no legitimate workload uses. Any hit is high-confidence
    evidence of SPN enumeration / Kerberoasting.
references:
    - https://attack.mitre.org/techniques/T1558/003/
author: UMBRASEC
date: 2026/06/10
tags:
    - attack.credential_access
    - attack.t1558.003
    - attack.deception
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4769
        ServiceName: 'svc-honeypot-sql'   # <-- your decoy sAMAccountName
    condition: selection
falsepositives:
    - A misconfigured scanner that was pointed at the decoy (investigate anyway)
level: high

Mitigation, not just detection

Detection buys you time; these changes shrink the attack surface. Microsoft's October 2024 guidance is the authoritative reference and worth reading in full.

• Use Group Managed Service Accounts (gMSAs) where you can. They use 120-character, automatically-rotated passwords that are not practically crackable.
• Kill RC4. Move accounts and domains to AES-only (msDS-SupportedEncryptionTypes), after you've used detection #1 to find what still needs RC4. This is the same direction Microsoft is pushing with the Windows Server 2025 defaults.
• Fix weak service-account passwords. Long and random beats clever. AES raises the cost, but a short AES-protected password still falls eventually.
• Audit SPNs and privilege. Remove SPNs from accounts that don't need them, and strip service accounts of Domain Admin-tier rights they were over-granted years ago.

Honest limitations

A "low and slow" attacker who requests a single high-value ticket and waits will sail past the velocity rule (#2) and, if they target an account that's still RC4-only for legitimate reasons, may not stand out in rule #1 either. That's not a reason to skip these — it's the reason the honeypot (#3) exists, and the reason mitigation matters as much as detection. Layer all three, and pair them with the non-crackable passwords that make a stolen ticket useless even if it slips through.

These rules are written to be readable and tunable, not dropped in blind. Test them in report-only mode, baseline your own environment, and treat the thresholds as dials. If one misbehaves for you, that's a great GitHub issue — corrections make the next version better.

References

• MITRE ATT&CK — T1558.003: Steal or Forge Kerberos Tickets: Kerberoasting
• MITRE ATT&CK — Detection Strategy DET0157 (Detect Kerberoasting Attempts)
• Microsoft Security Blog — Guidance to help mitigate Kerberoasting (Oct 2024)
• CrowdStrike — What is a Kerberoasting Attack?
• The Hacker News — Kerberoasting Detections: A New Approach to a Decade-Old Challenge (Jul 2025)