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

There is a statistic that should be on every Active Directory administrator's wall: 30. That is 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 attack technique responsible for a significant 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 April 2026 is a pivotal moment for every organization running Windows Active Directory.

The Kerberoasting Problem Is Not Going Away

Kerberoasting is an elegant attack. It does not require elevated privileges. It leaves minimal forensic artifacts. It operates entirely within 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 infrastructure — to crack it using tools like Hashcat running 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.

The attack is attractive because it bypasses every network-based and endpoint-based detection that organizations have deployed. 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 — there is no malicious code 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 marks 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 RC4's weaknesses to crack service account tickets in a fraction of the time required for AES. The enforcement phased timeline — audit in January, default change in April, mandatory removal in July 2026 — represents a genuine hardening of the Kerberos attack surface.

But here is 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 is 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 sufficient GPU resources. Nation-state actors and well-funded ransomware groups maintain exactly those GPU resources. Moreover, 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 they were before — just slightly more expensive to crack.

The Deception Angle: AD Mines Turn Kerberoasting Into a Trip Wire

The fundamental limitation of every reactive Kerberoasting defense — SIEM rules, honeypot SPNs from open-source tools, user behavior analytics — is that they try to distinguish malicious Kerberos ticket requests from legitimate ones. That is an extraordinarily hard problem. Most large enterprises generate tens of thousands of TGS requests per day. Behavioral baselines are noisy. Tuning alerts to reduce false positives inevitably creates blind spots that attackers exploit.

Mine2's approach inverts this problem entirely. Instead of watching real service accounts and trying to detect anomalous behavior, AD Mines plants 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 is an attack. There is no legitimate workflow that 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 them to do — 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 have moved laterally. It fires at the reconnaissance and credential collection phase, giving defenders a detection window that traditional monitoring consistently misses.

The operational implications are significant. AD Mines accounts are crafted to blend seamlessly 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 and has no basis to distinguish the real from the decoy. The decoy accounts are specifically configured to appear as high-value targets: they carry names that suggest access to databases, backup systems, or administrative infrastructure — exactly the accounts attackers prioritize.

A single deployment of AD Mines transforms 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 monitor for anomalous TGS request volumes: an attacker requesting tickets for dozens of SPNs in rapid succession should appear anomalous. This is sound in theory and unreliable in practice.

Sophisticated Kerberoasting tools including Rubeus, which is 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."

Security Information and Event Management platforms face a structural challenge here. Kerberos Event ID 4769 — the event 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 that are 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.

Endpoint Detection and Response 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 — possibly a workstation the attacker has compromised, possibly an internal server — and the DC returns a legitimate encrypted ticket. No malicious code executes. EDR sees nothing.

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

The Compliance Dimension: Kerberoasting, Breach Notification, and Audit Trails

Kerberoasting occupies a legally ambiguous but practically important position 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 provide access to systems that process personal data — and service accounts frequently do — the moment of credential theft may constitute a personal data breach, even if no data has yet been exfiltrated.

GDPR (Articles 33 and 34): Under the GDPR, a personal data breach triggering the 72-hour notification requirement to supervisory authorities includes any breach of security leading to the accidental or unlawful access to personal data. Credential theft targeting systems that process EU personal data may trigger this obligation. Demonstrating that your organization detected the intrusion attempt at the Kerberoasting phase — before any data was accessed — provides 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. Deception technology — specifically AD Mines that create an early detection perimeter around Active Directory — demonstrates 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 the use of 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 demonstrate that your deception layer successfully detected the simulated adversarial behavior — satisfying the ongoing testing requirements 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 regulatory 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 accessible to attackers — keeping organizations on the right side of the notification threshold.

A Practical Playbook: Defending Active Directory Against Kerberoasting in 2026

Organizations preparing for the post-April 2026 Kerberos landscape should execute the following steps 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 have not been 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 password 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 will find 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. This takes less than 30 minutes to deploy and provides permanent early warning. The accounts require 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 that alerts fire within the expected timeframe. Document the test 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. Organizations should apply these updates and complete the migration to AES before the July 2026 mandatory enforcement deadline.

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

AD Mines ensure the answer to that question is no.

Deception technology planted inside Active Directory creates a detection perimeter that 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 is the Mine2 proposition: not another layer of monitoring that generates alerts you have to investigate. A detection layer where every alert is real, every alert is early, and every alert means one thing: there is 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.