Kerberoasting in April 2026: Why CVE-2026-20833 Enforcement Is Not Enough Without AD Mines

Here's a statistic worth pinning to the wall: 30. That's the percentage of all enterprise intrusions in 2025 where the attack chain involved stolen or abused credentials, according to IBM's X-Force Threat Intelligence Index. Not ransomware payloads, not zero-days, not nation-state exploits — credentials. And the technique responsible for a sizable slice of that 30% is one that has existed since Windows 2000, has never been patched away, and this month is getting its most significant regulatory attention in two decades.

That technique is Kerberoasting. And for anyone running Windows Active Directory, April 2026 is a pivotal moment.

Kerberoasting Isn't Going Anywhere

Kerberoasting is an elegant attack. It needs no elevated privileges. It leaves minimal forensic artifacts. It runs entirely inside the legitimate Kerberos authentication protocol. And it has been the default lateral movement technique of every major threat actor — from nation-state APTs to ransomware affiliates — for years.

The mechanics are straightforward. Any authenticated domain user can request a Kerberos service ticket (TGS) for any Service Principal Name (SPN) registered in Active Directory. That ticket is encrypted with a hash derived from the service account's password. The attacker receives the encrypted blob and takes it offline — away from any monitoring — to crack it with tools like Hashcat on commodity GPU hardware. Modern GPU rigs crack eight-character complex passwords in under four hours. Twelve-character passwords that don't include truly random characters fall within days.

I've built detections for this attack for years, and the reason it's so frustrating to catch is that it bypasses every network-based and endpoint-based control teams deploy. The Kerberos ticket request looks identical to what Exchange, SQL Server, or any other legitimate service generates every day. Your SIEM sees a normal authentication event. Your EDR sees nothing — no malicious code is running on any endpoint. Your network monitoring sees normal Kerberos traffic on port 88. The attacker walks out with crackable credential material for your most privileged service accounts, and you never knew they were there.

What CVE-2026-20833 Changes, and What It Doesn't

This month is a critical inflection point. CVE-2026-20833 is a Windows Kerberos information disclosure vulnerability with a CVSS score of 5.5 that reflects the use of broken cryptographic algorithms — specifically RC4-HMAC — in Kerberos ticket issuance. Microsoft began shipping hardening updates in January 2026, and the April 2026 Windows security updates change the default ticket issuance behavior to AES-SHA1 for all accounts without explicit encryption settings.

This is meaningful progress. RC4 is cryptographically broken. Its output is biased and predictable. Modern cracking tools exploit those weaknesses to crack service account tickets in a fraction of the time AES requires. The phased enforcement timeline — audit in January, default change in April, mandatory removal in July 2026 — represents a genuine hardening of the Kerberos attack surface.

But here's what the CVE-2026-20833 enforcement does not fix: it does not eliminate Kerberoasting. It eliminates the weakest version of Kerberoasting.

AES-encrypted Kerberos tickets are still offline-crackable. The cracking process is slower than RC4, but it's not computationally infeasible. Service accounts with weak or dictionary-derived passwords fall in hours even against AES tickets. Accounts with moderate complexity passwords fall within days given enough GPU resources. Nation-state actors and well-funded ransomware groups maintain exactly those GPU resources. And the April 2026 patch does nothing about the structural problem: enterprises have accumulated dozens to hundreds of over-privileged service accounts over years of infrastructure growth, and the vast majority lack the password complexity required to resist offline cracking at modern GPU speeds.

Semperis, which specializes in Active Directory security, estimates that 78% of enterprise AD environments contain service accounts with SPNs registered and passwords that have never been rotated or were set to comply with minimum complexity requirements rather than genuine strength. These accounts survive the April 2026 enforcement exactly as vulnerable as before — just slightly more expensive to crack.

AD Mines Turn Kerberoasting Into a Trip Wire

Every reactive Kerberoasting defense — SIEM rules, honeypot SPNs from open-source tools, user behavior analytics — shares one limitation: it tries to tell malicious Kerberos ticket requests apart from legitimate ones. That's an extraordinarily hard problem. Most large enterprises generate tens of thousands of TGS requests per day. Behavioral baselines are noisy. Tuning alerts to cut false positives inevitably opens blind spots that attackers exploit. I've watched plenty of well-intentioned SOC runbooks get quietly evaded for exactly this reason.

Mine2 inverts the problem. Instead of watching real service accounts and hunting for anomalies, AD Mines plant fake service accounts with registered SPNs that no legitimate application or service will ever request a ticket for.

The logic is absolute. If any Kerberos ticket request arrives for an AD Mine service account, it's an attack. No legitimate workflow touches these accounts. No application needs a ticket for them. No scheduled task queries them. No monitoring system authenticates against them. When an attacker enumerates your AD environment, identifies SPNs, and fires a TGS request to harvest a crackable ticket — as every Kerberoasting playbook instructs — they will inevitably request a ticket for one of the decoy accounts. That single request generates an immediate, zero-false-positive alert.

This detection fires before the attacker has cracked anything. It fires before they've moved laterally. It fires at the reconnaissance and credential collection phase, giving defenders a window that traditional monitoring consistently misses. It's the same principle we describe for service account lateral movement after FortiGate intrusions and for ransomware crews moving through the network with stolen identities.

The operational implications are significant. AD Mine accounts are crafted to blend with your real naming conventions — they look like genuine SQL service accounts, backup agents, or application pool identities. An attacker scanning your AD for Kerberoastable targets sees a list of accounts with no basis to tell real from decoy. The decoy accounts are specifically configured to look like high-value targets: names that suggest access to databases, backup systems, or administrative infrastructure — exactly the accounts attackers prioritize.

A single deployment of AD Mines turns Kerberoasting from an invisible offline attack into a visible, instantly alerted intrusion attempt.

Why Traditional Monitoring Fails Against Kerberoasting

The most common defensive recommendation for Kerberoasting is to watch for anomalous TGS request volumes: an attacker requesting tickets for dozens of SPNs in rapid succession should look anomalous. That's sound in theory and unreliable in practice.

Sophisticated Kerberoasting tools including Rubeus, the current preferred tool in ransomware actor playbooks, have implemented "slow roasting" techniques that space requests over hours or even days, mimicking natural service authentication patterns. Rubeus can be configured to request exactly one TGS per hour, staying well under any volumetric threshold. CrowdStrike's 2025 Global Threat Report documented this evolution: "attackers have adapted their tooling to operate below detection thresholds, specifically countering SOC runbooks built around legacy Kerberoasting indicators."

SIEM platforms face a structural challenge here. Kerberos Event ID 4769 — generated for every TGS request — fires thousands of times daily in any enterprise environment. Filtering for TGS requests with RC4 encryption was a useful signal before the April 2026 enforcement, but attackers who request AES tickets generate Event ID 4769 entries indistinguishable from legitimate service authentication. After April 2026, the RC4 filter becomes irrelevant. SIEM-based detection regresses to volumetric or behavioral approaches, both of which sophisticated attackers have learned to evade.

EDR tools are simply out of scope. Kerberoasting harvests credential material from the Domain Controller, not from the attacker's workstation. The malicious TGS request originates from a legitimate domain-joined machine — maybe a workstation the attacker has compromised, maybe an internal server — and the DC returns a legitimate encrypted ticket. No malicious code executes. EDR sees nothing, which is the same gap we covered when looking at why deception survives EDR killers.

The only control that consistently detects Kerberoasting — regardless of encryption type, request pacing, or which legitimate machine the attacker operates from — is one that watches for requests to accounts that should never be touched.

Kerberoasting, Breach Notification, and Audit Trails

Kerberoasting sits in a legally ambiguous but practically important spot in breach notification frameworks. An attacker who successfully kerberoasts a service account and cracks its password has obtained valid credentials for your environment. If those credentials reach systems that process personal data — and service accounts frequently do — the moment of credential theft may constitute a personal data breach, even before any data is exfiltrated.

GDPR (Articles 33 and 34): Under the GDPR, a personal data breach triggering the 72-hour notification requirement includes any breach of security leading to accidental or unlawful access to personal data. Credential theft targeting systems that process EU personal data may trigger this obligation. Demonstrating that you detected the intrusion attempt at the Kerberoasting phase — before any data was accessed — is the strongest possible defense against both regulatory penalties and data subject notification requirements. An AD Mine alert at the reconnaissance phase gives you exactly that detection timestamp.

India Digital Personal Data Protection Act (DPDP): The DPDP Act requires Data Fiduciaries to implement reasonable security safeguards and to notify the Data Protection Board upon breach. AD Mines that create an early detection perimeter around Active Directory demonstrate reasonable security measures in exactly the terms regulators will evaluate. Proactive detection at the credential collection phase strengthens your compliance posture substantially over reactive breach discovery.

PCI-DSS (Requirement 11): Requirement 11.5 mandates change-detection mechanisms and requires testing of intrusion detection systems at least every six months. AD Mines that fire on any attempted Kerberoasting provide continuous, automated validation of your intrusion detection capabilities. Every quarter, you can show that your deception layer successfully detected the adversarial behavior — satisfying the ongoing testing requirement with operational data rather than synthetic test runs.

RBI/SEBI Directives and CERT-In 6-Hour Reporting: India's CERT-In 2022 directive mandates reporting of cyber incidents — including unauthorized access — within six hours of detection. For financial institutions under RBI and SEBI oversight, this timeline is existential. An AD Mine alert fires the moment a Kerberoasting attempt occurs, not hours or days later when damage has accumulated. The six-hour clock starts at the point of detection, and Mine2's immediate alert means that point is the very beginning of the attack chain.

HIPAA: Healthcare organizations processing Protected Health Information face breach notification obligations under the HIPAA Breach Notification Rule. Service accounts with access to electronic PHI systems are prime Kerberoasting targets. AD Mines seeded in healthcare AD environments provide early warning before any PHI is reachable — keeping organizations on the right side of the notification threshold.

A Practical Playbook for 2026

Teams preparing for the post-April 2026 Kerberos landscape should run the following in parallel with — not instead of — the CVE-2026-20833 patch deployment.

Audit your SPN inventory immediately. Run setspn -Q */* across your domain and export every registered SPN. Flag service accounts that have SPNs registered but whose passwords haven't rotated in more than 90 days, are less than 20 characters, or were set to comply with minimum complexity requirements rather than genuine randomness. These are your highest-risk Kerberoasting targets. Prioritize rotation for accounts with access to sensitive systems.

Implement Group Managed Service Accounts (gMSA) for all new deployments. gMSAs use 256-bit randomly generated passwords that rotate automatically every 30 days. An attacker who cracks a gMSA ticket finds a 256-bit random value — computationally infeasible to crack offline. Migrate existing high-risk service accounts to gMSA as a medium-term project.

Deploy AD Mines alongside your real SPN accounts. Mine2's single-click deployment creates realistic decoy service accounts with SPNs that blend with your naming conventions. Any TGS request for these accounts fires an immediate alert. It takes less than 30 minutes to deploy and provides permanent early warning. The accounts need zero maintenance and have zero performance impact on your domain infrastructure.

Enable Kerberos audit logging and route it to your SIEM with AD Mine exceptions. Configure Windows to log all Kerberos TGS requests (Event ID 4769). Establish a baseline of normal service account request patterns. Create high-priority alerts specifically for TGS requests targeting your AD Mine accounts — these should be P1 alerts requiring immediate response.

Test your detection capability quarterly. Use a non-privileged test account to run a controlled Kerberoasting simulation against your AD Mine accounts. Verify alerts fire within the expected timeframe. Document the results for PCI-DSS Requirement 11.5 compliance evidence.

The Bottom Line

CVE-2026-20833 and Microsoft's April 2026 RC4 enforcement are necessary steps. Apply these updates and complete the migration to AES before the July 2026 mandatory enforcement deadline.

But closing the RC4 door doesn't close the Kerberoasting door. As long as service accounts exist — and they will, in every enterprise environment — their Kerberos tickets remain offline-crackable. The question isn't whether Kerberoasting is still viable after April 2026. The answer is yes. The question is whether attackers can run it without triggering an immediate, certain detection.

AD Mines make the answer to that no.

Deception planted inside Active Directory creates a detection perimeter no patch can replicate and no attacker can avoid without abandoning the attack entirely. The moment a threat actor requests a Kerberos ticket for a Mine2 decoy service account, your security team knows — before the ticket is cracked, before the password is recovered, before any lateral movement begins.

That's the Mine2 proposition: not another monitoring layer that generates alerts you have to investigate, but a detection layer where every alert is real, every alert is early, and every alert means one thing — there's an attacker in your Active Directory right now, and you caught them before they got what they came for.

Start protecting your Active Directory today at https://www.mine2.io/product.