Modern Kerberoasting detection has moved far beyond watching for bulk ticket requests. In 2026, sophisticated threat actors use targeted requests to blend seamlessly into normal network traffic. With Microsoft’s mandatory move to AES-256, defenders must focus on advanced KQL queries and specific bitmask signatures in Event ID 4769.
Tactical Identity Defense: Mastering Kerberoasting Detection in 2026
Identity is the primary target for every modern cyberattack. For over a decade, Kerberoasting has been the easy button for attackers looking to gain more privileges. Now, standard security rules that only look for too many ticket requests are no longer enough to stop a professional hacker.
Today’s threat actors use AI-driven tools to perform targeted Kerberoasting. They request a single, high-value service ticket and then vanish into the background noise of your network.
Detecting these subtle moves takes more than just buying automated tools. It requires a researcher-led approach. This means you must fully understand the technical mechanics of the Kerberos protocol.
At 7ASecurity, we know that every network has its own traffic patterns. Generic detection rules always fail. This is why we fully customise our penetration tests. We accurately model the latest attack techniques. This helps your internal team to adjust your specific Kerberoasting detection tools so they can find the real threats.
What We'll Cover
- The 2026 cryptographic mandate: Moving from weak RC4 to AES-256.
- How to use First Seen KQL math to hunt for targeted anomalies.
- Deciphering bitmasks to find hacking tool signatures in Event ID 4769.
- The critical KDCSVC Event IDs in your System log you must monitor.
- The best way to verify your defensive settings.
The 2026 Cryptographic Mandate: The Actual Weight of AES
The biggest shift in identity security this year is the final death of the RC4-HMAC algorithm. For years, attackers loved RC4 because its hashes are incredibly fast to crack. They could test billions of keys per second on a single high-end GPU.
Following recent updates stemming from KB5021131, the Windows 2026 Security Baseline enforces a strict AES-only environment. RC4 is now disabled by default for network authentication.
This makes the attacker’s job much harder. AES-256 (Etype 18) forces the attacker to compute PBKDF2-HMAC-SHA1 with 4,096 iterations. This very demanding process slows down cracking speeds by roughly 15,000x compared to RC4's simple MD4 hash.
What took an attacker minutes now takes months. However, a weak password will still fall under AES-256. Detection remains your most important line of defence.
Advanced Thread Hunting: Moving Beyond Static Thresholds
Most Security Operations Centres (SOCs) use a simple rule: Alert if a user requests more than 50 service tickets in 10 minutes. Sophisticated hackers know this. So, they’ll simply request one ticket every few hours.
To catch a targeted attack, you must look at statistical anomalies. But you can't just use basic averages because ticket requests happen in bursts. If a user returns from holiday, their sudden jump from zero to ten tickets will trigger a false alarm in a basic system.
If you use Microsoft Sentinel or Defender XDR, your KQL query must use the make-series operator and series_stats_dynamic(). The function accurately calculates the 3-Sigma score while it accounts for the zeros on days when no tickets were requested.
Professional hunters pair this with First Seen logic. This flags when a user requests a ticket for a service account they’ve never accessed in the last 30 days.
The Kerberoasting Detection Blueprint
Use this KQL query in the IdentityDirectoryEvents table to find targeted anomalies. This version includes the First Seen logic. This logic prevents false positives from users simply returning from vacation.
// 3-Sigma Statistical Detection for Targeted Kerberoasting with First Seen Logic
let BaselineWindow = 14d;
let FirstSeenLookback = 30d;
let Threshold = 3;
// 1. Identify users accessing a service account for the first time in 30 days
let NewAccess = IdentityDirectoryEvents
| where Timestamp >= ago(FirstSeenLookback)
| where ActionType == "KerberosServiceTicketRequest"
| where TargetAccountDisplayName !endswith "$" // Ignore machine accounts
| summarize FirstSeen = min(Timestamp) by AccountUpn, TargetAccountDisplayName
| where FirstSeen >= ago(1d) // Filters for genuinely new access today
| summarize NewServices = make_set(TargetAccountDisplayName) by AccountUpn;
// 2. Calculate the 3-Sigma anomaly for ticket request volume over the last 14 days
let VolumeAnomaly = IdentityDirectoryEvents
| where Timestamp >= ago(BaselineWindow)
| where ActionType == "KerberosServiceTicketRequest"
| where TargetAccountDisplayName !endswith "$"
| make-series DailyTickets = count() default=0 on Timestamp from ago(BaselineWindow) to now() step 1d by AccountUpn
| extend stats = series_stats_dynamic(DailyTickets)
| extend AvgTickets = todouble(stats.avg), StdDevTickets = todouble(stats.stdev)
| extend CurrentTickets = todouble(DailyTickets[-1]) // Gets the most recent day's count
| extend SigmaScore = (CurrentTickets - AvgTickets) / iff(StdDevTickets == 0, 1.0, StdDevTickets)
| where SigmaScore >= Threshold;
// 3. Combine both detection methods to eliminate vacation false positives
VolumeAnomaly
| join kind=inner NewAccess on AccountUpn
| project AccountUpn, SigmaScore, CurrentTickets, AvgTickets, StdDevTickets, NewServices
| order by SigmaScore desc.
Deciphering the Bitmask: Finding the Tool Signatures
Attackers rarely use the standard Windows Kerberos client to roast your tickets. They use tools like Rubeus or Impacket. These tools often leave a technical fingerprint inside the Ticket Options field of Event ID 4769.
Kerberos Ticket Options bitmasks are read from left to right. A standard Windows request combines the Forwardable (0x40000000), Renewable (0x00800000), and Canonicalise (0x00010000) flags. Together, the combination equals 0x40810000.
Hacking tools often leave out the Canonicalise flag. When they do, the hex shifts from 81 to 80. This leaves a signature of 0x40800000. By hunting for these non-standard bitmasks, you can identify hacking tools in your network logs even if the attacker is quiet.
Monitoring Kerberos Telemetry
As part of the recent hardening roadmap, Microsoft introduced new audit events. You’ll find these in the standard Windows System log under the source Microsoft-Windows-Kerberos-Key-Distribution-Center (KDCSVC).
You must monitor Event ID 202. This event triggers specifically when RC4 usage is detected. This happens because a target service account lacks the required AES keys. Finding this event helps your hunters to fix structural weaknesses before an attacker uses them.
The Benefit of Manual SOC Tuning
Automated security scanners are excellent for finding missing software patches. But they can’t tell you if your Kerberoasting detection rules actually work in the real world. A scanner won't tell you if your KQL query has a schema error. They also can’t tell you if an attacker has bypassed your filters.
This is why elite security teams choose 7ASecurity. We don't just run an automated tool and hand you a PDF. We use the same manual, researcher-led techniques as modern threat groups to test your defences. Our teams help you verify that your logging is capturing the right data and that your alerts fire when it matters most.
Harden Your Identity Defence
Don't wait for a data breach to find out your detection rules are failing. Get a custom, expert-led security audit to verify your Kerberos defences today.
Secure Your Network Today
Frequently Asked Questions About Kerberoasting Detection
What is Kerberoasting?
Kerberoasting is an attack where a user requests an encrypted service ticket (TGS) for a specific account. The attacker then takes that ticket offline and uses brute-force tools to discover the account’s password.
What is Targeted Kerberoasting?
Targeted Kerberoasting is when an attacker requests a single ticket for one high-value account. This method is different from harvesting many tickets at once. They do this to bypass standard SOC detection rules that look for high-volume requests.
Is Kerberoasting still a threat with AES-256?
Yes. AES-256 is roughly 15,000 times harder to crack than the old RC4 algorithm. However, a simple password will still be discovered eventually. AES-256 raises the cost of the attack but doesn't eliminate the risk.
Why aren't I seeing the new 200-series Kerberos events in my logs?
Even if you have the January 2026 patches installed, the new diagnostic events (201–209) aren’t active by default. You must first create the RC4DefaultDisablementPhase registry key on your Domain Controllers and set it to a value of 1.
This enables the audit mode. You need this mode active to see which legacy accounts are still falling back to RC4. It helps you fix them before the full enforcement phase breaks their authentication.
Does Kerberos Pre-Authentication stop a Roasting attack?
No. Kerberos Pre-Authentication is designed to prevent AS-REP Roasting. That type of attack targets the initial login (TGT) phase.
Standard Kerberoasting targets the service ticket (TGS) phase. This phase happens after a user has already successfully logged in. Because any authenticated user has the right to ask for a service ticket, Pre-Authentication provides no protection against an attacker who has already compromised a single low-level account.
Can I use Honeytoken accounts to detect Kerberoasting?
Yes, and it is an effective strategy.
- Create fake service accounts with enticing names like
svc-sql-adminorbackup-internal-vault. - Give these accounts a valid Service Principal Name (SPN) but no actual permissions.
Since no legitimate user or service should ever request a ticket for these accounts, any Kerberos service ticket request (TGS-REQ) in your logs for these specific accounts is a 100% positive indicator of active reconnaissance or roasting.
How can I stop Kerberoasting entirely?
The most effective fix is to use Group Managed Service Accounts (gMSA). These accounts use 120-character, random passwords that Windows rotates automatically. This makes them mathematically uncrackable.
