How to Hunt for Kerberoasting After the 2026 RC4 Changes

Kerberoasting lets any authenticated domain user request a service ticket for an account with a Service Principal Name (SPN), take it away and crack the service account password offline. For years, most hunts leaned on one shortcut: look for RC4 encrypted tickets. Microsoft's 2026 Kerberos hardening has made RC4 rare by default, so that shortcut now finds very little. This guide is for threat hunters in banks, payment firms and trading businesses, where service accounts run the systems that move money.

Understand what changed in 2026

Kerberoasting works because the Key Distribution Center (KDC) on a domain controller hands out a service ticket for any SPN to any authenticated user. Part of that ticket is encrypted with a key derived from the service account's password. If the ticket uses RC4, the key comes straight from the account's NT hash and cracks quickly. MITRE ATT&CK's detection strategy for T1558.003 still lists RC4 tickets in Event ID 4769 as a primary signal, alongside unusual volumes of ticket requests and requests outside a service account's normal baseline.

Microsoft tied its RC4 phase out to CVE-2026-20833 and rolled it out in stages:

• January 2026: updates added nine new KDCSVC audit events, IDs 201 to 209, in the System log of domain controllers, plus a temporary RC4DefaultDisablementPhase registry value.
• April 2026: enforcement switched on by default. Accounts with no explicit msDS-SupportedEncryptionTypes value are now assumed to support AES only, with a manual rollback still possible.
• July 2026: updates removed the registry rollback. RC4 now works only for accounts explicitly configured to allow it.

Attackers have not stopped Kerberoasting because of this. They either hunt for the legacy accounts that still allow RC4, or they request AES tickets and accept slower cracking. A service account with a short or reused password still falls to AES cracking. Your hunts need to cover both routes.

Confirm every domain controller sends 4769

A clean hunt only counts if the data was there. Event ID 4769 is logged when the Audit Kerberos Service Ticket Operations subcategory is enabled under Account Logon in Advanced Audit Policy. Enable both success and failure, because failed requests matter more now than before. Also forward the System log from domain controllers so you collect the KDCSVC events.

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4769
| summarize Tickets = count(), LastSeen = max(TimeGenerated) by Computer
| order by Tickets asc

Compare the result with your list of domain controllers. A DC missing from the list, or one with a tiny count, is a gap an attacker could use without you noticing, because a tool can target any DC.

Hunt RC4 tickets that should no longer exist

In an enforced domain, a successful RC4 service ticket means the target account is explicitly configured to allow RC4. Those accounts are now the easiest targets in your estate, so treat every RC4 ticket as a lead and every requester as worth a look.

Sentinel version

SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4769
| parse EventData with * 'ServiceName">' SpnName '<' *
| parse EventData with * 'TicketEncryptionType">' EncType '<' *
| parse EventData with * 'Status">' FailureCode '<' *
| where EncType == "0x17" and FailureCode == "0x0"
| where SpnName !endswith "$" and SpnName !~ "krbtgt"
| where TargetUserName !contains "$"
| summarize Tickets = count(), Spns = dcount(SpnName), SpnList = make_set(SpnName, 25),
    FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by TargetUserName, IpAddress
| order by Spns desc

Splunk version

index=wineventlog source="XmlWinEventLog:Security" EventCode=4769 TicketEncryptionType="0x17" Status="0x0"
    ServiceName!="*$" ServiceName!="krbtgt" TargetUserName!="*$*"
| stats count dc(ServiceName) AS distinct_spns values(ServiceName) AS spns BY TargetUserName IpAddress
| sort - distinct_spns

Then list which accounts can still be roasted with RC4. In msDS-SupportedEncryptionTypes, the value 0x4 is the RC4 bit, 0x8 is AES128 and 0x10 is AES256. Run this read only query from an admin workstation and share the output with the directory team.

Get-ADUser -LDAPFilter "(servicePrincipalName=*)" -Properties servicePrincipalName, msDS-SupportedEncryptionTypes, PasswordLastSet |
    Where-Object { $_.'msDS-SupportedEncryptionTypes' -band 0x4 } |
    Select-Object SamAccountName, msDS-SupportedEncryptionTypes, PasswordLastSet |
    Sort-Object PasswordLastSet

An RC4 enabled service account with a password set many years ago, on a system like a payments database or a market data feed, is the account an attacker will roast first. Put it at the top of the remediation list.

Hunt bursts of service tickets regardless of cipher

This is the signal that keeps working after RC4 has gone. Normal users request tickets for a small, stable set of services: file shares, intranet sites, a few databases. A roasting tool requests tickets for many SPNs in quick succession. The query below builds a per account baseline over the previous two weeks and flags hours where an account requested far more distinct SPNs than usual.

let window = 1h;
let Tgs = SecurityEvent
    | where TimeGenerated > ago(14d)
    | where EventID == 4769
    | parse EventData with * 'ServiceName">' SpnName '<' *
    | parse EventData with * 'Status">' FailureCode '<' *
    | where FailureCode == "0x0"
    | where SpnName !endswith "$" and SpnName !~ "krbtgt"
    | where TargetUserName !contains "$";
let Baseline = Tgs
    | where TimeGenerated < ago(1d)
    | summarize HourlySpns = dcount(SpnName) by TargetUserName, bin(TimeGenerated, window)
    | summarize TypicalMax = max(HourlySpns) by TargetUserName;
Tgs
| where TimeGenerated >= ago(1d)
| summarize RecentSpns = dcount(SpnName), SpnList = make_set(SpnName, 50)
    by TargetUserName, IpAddress, bin(TimeGenerated, window)
| join kind=leftouter Baseline on TargetUserName
| extend TypicalMax = coalesce(TypicalMax, 0)
| where RecentSpns >= 5 and RecentSpns > TypicalMax * 3
| order by RecentSpns desc

Accounts with no baseline get a TypicalMax of zero, so any account requesting five or more distinct SPNs in its first hour of activity appears. That is deliberate: a freshly compromised account that has never touched Kerberos before is exactly what you want to see.

Expect some legitimate results and tune them by name, not by broad exclusions:

• Vulnerability scanners and asset discovery tools running authenticated scans.
• Monitoring platforms that check the health of many services.
• Admin jump hosts during maintenance windows, which your change records should explain.

Two supporting details raise confidence. First, the TicketOptions value 0x40810000 is commonly seen in requests from roasting tools, though it is not unique to them. Second, look at the source host: a payments operations laptop requesting tickets for SQL, SWIFT and backup services in one hour has no business reason to do so.

Plant a decoy SPN account

A decoy, or honeytoken, account is a fake service account with an SPN that no real system ever uses. Because nothing legitimate requests its ticket, a single 4769 for it is worth an alert at any hour. In a bank, name it so it looks valuable to an attacker scanning for payment systems.

• Raise a change, because a new privileged looking account needs approval and a named owner.
• Create a standard user with a long random password, no group memberships beyond Domain Users and no logon rights to servers.
• Register a believable SPN, for example MSSQLSvc/swiftbackup01.corp.example:1433, pointing at a host that does not exist.
• Document it in your SIEM watchlist so analysts know any activity is malicious.
• Tag it as a honeytoken in Defender for Identity if you use it.

let DecoyAccount = "svc_swiftbackup";
SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID == 4769
| parse EventData with * 'ServiceName">' SpnName '<' *
| parse EventData with * 'TicketEncryptionType">' EncType '<' *
| where SpnName =~ DecoyAccount
| project TimeGenerated, Computer, TargetUserName, IpAddress, EncType

Defender for Identity adds two useful alerts here. Honeytoken authentication activity (external ID 2014) fires on activity involving tagged accounts, and Suspected Kerberos SPN exposure (external ID 2410) looks for tools enumerating service accounts and requesting their tickets. You can also hunt the enumeration step, since tools usually query LDAP for accounts with SPNs before requesting tickets.

IdentityQueryEvents
| where Timestamp > ago(7d)
| where ActionType == "LDAP query"
| where Query has "servicePrincipalName"
| summarize Queries = count(), Targets = make_set(QueryTarget, 20) by AccountName, DeviceName
| order by Queries desc

Triage a hit and tie it to business risk

When a hunt returns a likely true positive, your first questions are which accounts were targeted and whether any of them have been used since. A roasted ticket is useless to the attacker until the password is cracked, so you often have a window to act.

In financial services, connect the technical finding to the business service early. If a targeted account supports an important business service under the FCA and PRA operational resilience rules, the service owner needs to know. If the incident grows, DORA classification and reporting timelines may apply to EU entities, so record each finding with times as you go. Hunts like these also make good evidence for threat led penetration testing debriefs, where red teams routinely try Kerberoasting.

Key takeaways

---

Run the RC4 account listing and the burst hunt this week, then compare the results with your list of service accounts that support payment and trading systems. The overlap tells you where a weak password would hurt the business most, and which passwords to rotate first.

Written by Riz, Senior Cybersecurity Consultant, Finance