TL;DR for defenders. Turn on Audit Kerberos Service Ticket Operations on your domain controllers, then watch Event ID 4769 for two things: (1) service-ticket requests using RC4 (TicketEncryptionType 0x17) in an environment that should be using AES, and (2) a single account requesting tickets for an unusual number of distinct service principals. A decoy "honeypot" SPN turns this from anomaly-hunting into a near-zero-false-positive alarm. Rules below.

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 2023 Threat Hunting Report recorded a 583% year-over-year increase in Kerberoasting attacks, and IBM's 2024 X-Force Threat Intelligence Index reported a 100% increase in Kerberoasting attacks across 2023. Those figures are a few years old now, but the mechanics they describe haven't changed. 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 in Kerberos, and it's doing it in phases on every domain controller version it still updates (Windows Server 2012 under ESU through Windows Server 2025), not just in new domains. The January 2026 Windows updates added KDC audit events (System log, events 201 to 209) that flag RC4 use without changing behaviour. The April 2026 updates switched the domain controller default to AES-only for accounts that have no explicit msDS-SupportedEncryptionTypes value, with a registry rollback to audit mode still available. The July 2026 updates will remove that rollback. (Windows Server 2025 domain controllers already refuse to issue RC4 ticket-granting tickets, but the service tickets Kerberoasting targets follow the account's encryption settings, which is why this change is the one that matters.) That's real progress - but any account whose msDS-SupportedEncryptionTypes explicitly includes RC4 still gets RC4 service tickets, and Microsoft's own guidance is to set exactly that on anything that still needs RC4. Those tend to be the old, over-privileged service accounts an attacker wants anyway. So for most organizations, the weak encryption that makes Kerberoasting fast is still sitting on some accounts, 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. Be careful with the headline numbers, though: the figures in the hundreds of billions per second that get quoted are for raw NTLM. A single RTX 4090 running Hashcat 7.0.0 benchmarks at about 272 billion NTLM guesses per second (hash-mode 1000) but about 3.4 billion per second against an RC4 TGS-REP (hash-mode 13100), because each guess also has to run the HMAC key derivation and an RC4 decryption. Three billion a second on one consumer card is still enough that a short or dictionary-based service-account password falls in minutes to hours, and a multi-GPU rig multiplies it.

AES tickets (0x11/AES-128 and 0x12/AES-256) are dramatically harder - on the same GPU, Hashcat runs AES-256 TGS-REP (hash-mode 19700) roughly a thousand times slower than the RC4 variant, and AES-128 (hash-mode 19600) several hundred times slower - because the key comes from salted PBKDF2 rather than straight from the NT hash. 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:

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

FieldWhy it matters
TicketEncryptionType0x17 = RC4 (the downgrade signal). 0x12 = AES-256, 0x11 = AES-128.
ServiceName / ServiceSidThe account whose ticket was requested - i.e. the roast target. Names ending in $ are computer accounts (usually benign).
TargetUserName / Account NameThe principal that made the request - the account you'd investigate.
TicketOptionsRoasting tools often produce recognizable option flags (commonly 0x40810000), though this varies and shouldn't be relied on alone.
Status0x0 = the ticket was successfully issued.

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
        Status: '0x0'                   # only count successfully issued tickets
    filter_machine:
        ServiceName|endswith: '$'
    filter_krbtgt:
        ServiceName: 'krbtgt'
    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

Tuning note. The TicketOptions: '0x40810000' line tightens precision but will miss tools that vary their flags. Start without it to measure your baseline of RC4 requests, identify the legitimate RC4-only accounts, add those to filter_machine as an allowlist, and only then decide whether the TicketOptions constraint earns its keep.

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:

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.

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

Scope note. This is a defensive writeup. It explains the technique only to the depth needed to detect and mitigate it, and deliberately does not provide roasting tooling or cracking instructions. UMBRASEC publishes defense, not offense.