Kerberoasting Explained: How the Attack Works, Detection and Fixes (2026)

Kerberoasting is an attack on Active Directory in which any signed-in domain user asks a domain controller for Kerberos service tickets, takes them away and guesses the service accounts' passwords offline until one fits. It needs no administrator rights and no exploit, and the guessing happens on the attacker's own hardware, where no lockout policy applies. Microsoft calls it "a low-tech, high-impact attack", and it is still in use: on 30 October 2026, Google Threat Intelligence Group and Mandiant reported an AI agent framework that ran Kerberoasting scripts across compromised domains and, after a pause for offline cracking, ran DCSync scripts to steal the domain's krbtgt key.

This guide explains how the attack works in plain terms, why Microsoft's 2026 RC4 changes do not end it, how an Active Directory security assessment finds the exposed accounts, which event IDs detect it and which fixes stop it. It describes the attack at the level a defender needs. It does not include attack commands.

Kerberoasting at a glance

How a Kerberoasting attack works

Kerberos is the main authentication protocol in Active Directory. When a user wants to reach a service, such as a SQL Server database or an internal web application, their computer asks a domain controller for a service ticket. The domain controller looks up the account that runs the service, which it finds through a label called a service principal name, and encrypts part of the ticket with a key derived from that account's password. The service later decrypts the ticket with the same key, which is how it knows the ticket is real.

The domain controller does not check whether the requester is allowed to use the service. That decision belongs to the service. Joint guidance on detecting and mitigating Active Directory compromises from the Australian Signals Directorate, CISA, the NSA and their Canadian, New Zealand and UK counterparts, revised in September 2026 (the Five Eyes guidance below), says so directly: if a user account has an SPN, any other account, "including unprivileged users", can request its service ticket "from a Domain Controller", and "this functionality is by design".

Kerberoasting abuses that design in five stages.

Three properties set Kerberoasting apart from password spraying and other online guessing:

• No failed logons and no lockout. The guessing in stage 4 never touches the domain, so account lockout thresholds and failed-logon alerts do not apply.

• The service is never contacted. The abstract of Tim Medin's DerbyCon 2014 talk, where the technique was presented, describes "a way to attack the credentials of a remote service without sending traffic to the service".

• The result is a real password. The attacker does not forge anything at this point. They sign in as the service account, and everything that account is allowed to do is now theirs.

That last point is where the damage comes from. The Five Eyes guidance notes that service accounts "may be members of highly privileged security groups, such as the Domain Admins security group", and that compromising one of those "often results in the complete compromise of a domain". MITRE ATT&CK lists FIN7, Wizard Spider and Indrik Spider among the groups that have used the technique.

Why Kerberoasting still works in 2026

The technique is twelve years old and well documented. It survives for five reasons, and only one of them is cryptography.

Ticket requests are a feature. Every domain user can request a ticket for every SPN. There is nothing to patch in stage 3.

Service account passwords are set by people. Microsoft's December 2025 guidance on threats to Active Directory Domain Services says "many service accounts use weak or non-expiring passwords". A password chosen by an administrator years ago and never rotated is exactly what an offline guessing run is built to find.

Service accounts are over-privileged. NSA and CISA's top ten misconfigurations advisory explains that such accounts "are often granted elevated permissions within the domain due to the nature of the service", and calls Kerberoasting "one of the most time-efficient ways to elevate privileges and move laterally throughout an organization's network".

RC4 made guessing cheap. The speed of stage 4 depends on how the ticket's key is derived from the password. For RC4, the IETF's RFC 8429 describes the derivation as "a single iteration of the MD4 hash function applied to the UTF-16 encoded password, with no salt at all". For AES, RFC 3962 uses PBKDF2 with a salt and a default of 4,096 iterations, so each guess costs far more work. Microsoft's Kerberoasting guidance puts it in one line: RC4 "uses no salt or iterated hash when converting a password to an encryption key, allowing the cyberthreat actor to guess more passwords quickly". The same guidance adds that the attack's "effectiveness is growing because of the use of GPUs to accelerate password cracking techniques".

It looks like normal activity. In the words of the Five Eyes guidance, "Detecting Kerberoasting can be difficult as this technique mirrors legitimate Active Directory activity."

Evidence from 2024 to 2026

Kerberoasting keeps appearing in government advisories, incident response reports and vendor guidance. Every row below links to the primary source.

Two of these deserve a closer look. The CORNFLAKE.V3 case shows how early in an intrusion Kerberoasting now happens: the infection began with a fake CAPTCHA page that tricked a user into running a script, and a ticket harvesting script was among the first things run through the backdoor from that one workstation. The CISA red team case shows the detection gap: the defenders were looking for tool names, and the technique does not need them.

What Microsoft changed in 2026: CVE-2026-20833 and RC4

On 13 January 2026 Microsoft published CVE-2026-20833, a Windows Kerberos information disclosure vulnerability rated Important with a CVSS base score of 5.5. Its support article describes the flaw as one that "might allow an attacker to obtain service tickets with weak or legacy encryption types such as RC4 to perform offline attacks to recover a service account password". That is Kerberoasting, written as a CVE.

The fix arrived in three phases.

Before this, Microsoft's own 2024 wording was that "RC4 is currently enabled by default, meaning a cyberthreat actor can attempt to request tickets encrypted using RC4". After enforcement, that request fails for any service account that relies on the default. This is a real improvement, and it should be finished rather than rolled back.

What the RC4 change does not fix

• Weak passwords behind AES tickets. Microsoft is explicit: "AES alone is not a solution for brute forcing and needs to be used in combination with strong passwords. A weak password can still be brute forced even if AES is used for encryption." AES raises the cost of each guess. It does not make Summer2019! a good password.

• Explicit RC4 settings. Microsoft's support article says it "will honor any configuration explicitly set by an administrator". A service account whose msDS-SupportedEncryptionTypes attribute includes RC4 still gets RC4 tickets, and a domain-wide DefaultDomainSupportedEncTypes value that includes RC4, in Microsoft's words, "leaves all accounts in the domain vulnerable to CVE-2026-20833". Event 205 flags that setting each time the KDC service starts and never turns into a block.

• Domain controllers that are not updated. The protection lives on the domain controller. One that has not taken the April 2026 or later updates, and was not switched to enforcement manually, still behaves the old way.

• RC4 itself. Microsoft's Directory Services team wrote in January 2026 that "there are currently no plans to remove RC4 from Windows".

• RC4-only detections. Many detection rules look for RC4 tickets, because attackers used to ask for them. Where RC4 is no longer issued, an attacker simply receives AES tickets, and a rule that only watches for RC4 stays quiet. MITRE already records Wizard Spider stealing "AES hashes" through Kerberoasting tooling.

The CVSS score describes the protocol weakness. It says nothing about what a cracked account can do, and that is the question that matters in your environment.

Kerberoasting vs AS-REP roasting

The two are often tested and fixed together, and often confused.

The Five Eyes guidance notes that attackers "have fewer opportunities to perform AS-REP Roasting than Kerberoasting", because accounts require pre-authentication by default. Where an account is exposed, though, the bar is lower: the same guidance says AS-REP roasting "can be executed prior to authentication", so the attacker does not need a domain account at all. There is also a third variant worth knowing. An attacker who can write to another account can add an SPN to it, request its ticket and remove the SPN again. This is usually called targeted Kerberoasting, and the same guidance lists events 4738 and 5136 for catching the SPN change.

How an Active Directory assessment finds Kerberoastable accounts

An Active Directory security assessment treats Kerberoasting as a question about accounts, not about tools: which accounts can be roasted, which of those passwords would fall, and what each one reaches. The method below is what to expect from a competent tester. It leaves out the commands on purpose.

Start where an attacker starts. The tester works from one or two ordinary domain accounts, the same position a phished employee gives away. No administrator access is needed to assess this exposure, which is the point.

Inventory every account with an SPN. For each one the tester records who owns it, when its password was last set, which encryption types it allows, whether it is enabled and in use, and what it is a member of, directly and through nested groups. Password age matters more than it looks: a password set years ago was chosen under whatever rules applied then and has been exposed to every ticket request since.

Request tickets inside the rules of engagement. The tester requests service tickets the way an attacker would. This doubles as a detection test. Agree before the engagement whether the security operations team is told in advance, because whether anyone noticed a burst of ticket requests from one user is one of the most useful results the test can produce.

Run a time-boxed offline password audit. The tickets are tested offline against the kinds of passwords people choose: organization and product names, seasons and years, keyboard patterns and passwords known from breaches. The time box is agreed up front and stated in the report, because a password that survived the agreed window has not been shown to be strong. Recovered passwords are sensitive data. They should be handled under the engagement's data rules and reported by account, not printed in the report.

Show what each recovered account reaches. A cracked account with no rights is a hygiene finding. A cracked account with local administrator rights on every server, replication rights on the domain, or membership of Domain Admins is a path to full control. The tester proves the shortest path within agreed limits and stops.

Check the configuration around the accounts. That includes whether domain controllers are in enforcement mode for CVE-2026-20833, whether RC4 is explicitly re-enabled anywhere, which accounts can write SPNs on other accounts, and which accounts skip pre-authentication.

The output should be a table your team can act on: one row per Kerberoastable account, with its privilege, password age, encryption types, whether the password fell inside the time box, what it reached and the recommended fix.

Stingrai's StingAD walkthrough shows the whole chain in a lab domain built to be vulnerable, where one roasted service account turned out to be a Domain Admin. In Stingrai's State of Penetration Testing 2026 dataset, internal network tests returned a median of 11 verified findings and 92% of them were rated High or Critical, which is why the inside of the network deserves its own scope. For how this fits a wider engagement, see the guides to Active Directory penetration testing services and internal network penetration testing.

How to detect Kerberoasting

Detection has one hard limit: stage 4 happens off your network. Almost everything you can see happens in stage 3, when the tickets are requested, and in stage 5, when the account is used. Canary objects, described below, can also catch the directory enumeration in stage 2.

Start by making sure the data exists. Event 4769, "A Kerberos service ticket was requested", is written on domain controllers by the Audit Kerberos Service Ticket Operations subcategory. Microsoft recommends both Success and Failure auditing and rates the event volume as "Very High on Kerberos Key Distribution Center servers", so the events need to go to a SIEM, where the patterns below can be searched.

Three practical notes on using these signals:

• Do not key on tool names. The CISA red team case above failed on exactly this: rules matched strings such as kerberoast in command lines, and the activity produced none. Detect the behavior in the ticket log.

• A decoy account is one of the highest-signal rules. Create a service account that runs nothing, with no privileges or group memberships, an SPN that matches no real service and a long random password, and alert on any 4769 that names it. Identity security tools, vulnerability scanners and authorized tests that request a ticket for every SPN will trip it too, so allow for those and treat anything else as an incident. The Five Eyes guidance describes a related approach, canary objects that log event 4662 when anything tries to read them, as "an effective technique" that "does not rely on correlating event logs", and lists Kerberoasting among the compromises it detects. It also gives the limit of this family of detections: attackers "may choose to only target a single or a small number of user objects", and one who roasts a few chosen accounts never touches the decoy. Defender for Identity offers a honeytoken tag for dormant accounts, which alerts if the account itself is ever used to sign in, a second tripwire behind the 4769 rule.

• Do not rely on RC4 alone. An attacker who accepts AES tickets produces no 0x17 events. Volume, unusual targets and decoys still work.

Detection buys time, and it is not a fix. Google's ARTEX report makes the point bluntly: "simply detecting the attack in time does little to hinder objective completion".

How to fix Kerberoasting

The fixes all work on the same principle: make the password impossible to guess, and make the account worth less if it falls anyway. In priority order:

How long should a service account password be?

The primary sources do not agree on one number, so here they are side by side.

Length only helps if the password is random. A 30-character phrase built from the company name and the year is still a dictionary entry. For any account that cannot become a managed service account, generate at least 25 to 30 random characters and treat Microsoft's 14 as a floor for accounts you have not reached yet.

What AI agent frameworks change

Google's ARTEX report documents an AI agent framework running this technique in intrusion activity that Google and Mandiant investigated. Its table of observed ARTEX activity, which does not say whether a row comes from one intrusion or several, records that the framework ran Kerberoasting scripts across compromised domains, used SQL injection to dump database credentials and, after a pause for offline cracking, ran DCSync scripts to steal the domain krbtgt key, cloud directory sync credentials and domain controller machine hashes. The same report records that its attempts to move laterally onto domain controllers ended when endpoint protection blocked execution and defenders cut off access to the server.

Google's own summary is that this tooling "does not fundamentally change the techniques attackers use. It reduces the time required to combine them." Work that "previously required hours of operator effort can now occur in minutes".

For Kerberoasting, that changes the arithmetic in one specific way. The technique was already cheap. What an agent shortens is the work on either side of the cracking: getting from a foothold to the ticket requests, and from a recovered password to its use. The cracking itself still takes as long as the password allows, and Google's table records a pause for it. A defense that depends on an analyst noticing a 4769 burst and responding before the account is used has less slack than it used to. Fixes that remove the weak password, such as managed service accounts and long random passwords, do not depend on anyone being fast. Stingrai's analysis of the report, ARTEX and agentic offensive frameworks, covers the rest of what Google observed and what a test should now include.

Where Kerberoasting fits in a penetration test

Three kinds of engagement touch it, and they answer different questions.

Questions worth putting to any provider before the work starts:

• Will every user account with an SPN be listed in the report, or only the ones that were cracked?

• How long is the offline password audit, and what wordlists and rules does it use?

• How are recovered passwords stored, reported and destroyed?

• Will the test check enforcement of the CVE-2026-20833 changes and explicit RC4 settings?

• Is detection in scope, and will the security operations team be told beforehand?

• Is a retest of the fixed accounts included?

Where Stingrai fits

Stingrai is a CREST-accredited penetration testing company offering fully human-led and hybrid (human penetration testers plus AI agents) penetration tests, delivered by experienced penetration testers who are also world-class security researchers and bug bounty hunters. It was founded in Toronto, Canada in 2021 and works with companies from startups to enterprises.

Active Directory work is human-led. In the Active Directory security assessment, Stingrai's penetration testers start from the position of an ordinary domain user and attempt to reach control of the directory, then report every path they proved with the specific object and attribute behind each hop. Coverage includes Kerberos attacks such as Kerberoasting and AS-REP roasting, ACL and delegation abuse, coerced authentication, Active Directory Certificate Services, Group Policy, domain and forest trusts, credential exposure and the Tier 0 boundary, with data collected through PingCastle and BloodHound and validated manually.

• Who does the work: two named penetration testers from a team holding OSCE³, OSEP, CRTE, CRTO and CREST CRT certifications, with 18 published CVEs across the team. The team lead has 16 years in penetration testing, red teaming and exploit development, and the team maintains its own open-source Active Directory tooling, StingAD.

• How findings arrive: each confirmed finding is posted to the PTaaS platform as it is confirmed, with remediation guidance, so a roastable Domain Admin account does not wait for the final report.

• What happens after: a reassessment confirms the fixed accounts and closed paths, and the report gives your auditors penetration testing evidence for SOC 2, ISO 27001 and PCI DSS programs.

Engagements run as one-time annual tests or as continuous programs. Active Directory, network and red team work is scoped per engagement.

Kerberoasting defender checklist

• Enable Success and Failure auditing for Kerberos Service Ticket Operations on every domain controller and send event 4769 to the SIEM.

• List every user account with an SPN, with its owner, password age, encryption types and group memberships.

• Convert each one to a gMSA, or a dMSA on Windows Server 2025, wherever the application supports it.

• For the rest, set a random password of at least 25 to 30 characters, store it in a vault and schedule rotation.

• Set those accounts to AES only and reset the password afterward so AES keys exist.

• Remove SPNs from accounts that no longer run a service and from any interactive user account.

• Remove service accounts from Domain Admins and other privileged groups, and remove replication (DCSync) rights.

• Confirm every domain controller has the April 2026 or later updates and runs in enforcement mode for CVE-2026-20833.

• Review KDCSVC events 201 to 209 and remove explicit RC4 settings that are no longer needed.

• Create a decoy service account with no privileges and alert on any ticket request for it that does not come from your own tooling or an authorized test.

• Add detections for 4769 bursts and unusual targets that do not depend on RC4 or tool names.

• Have the result checked in your next Active Directory or internal network test, detection included.

Frequently Asked Questions

What is Kerberoasting?

Kerberoasting is an Active Directory attack in which any authenticated domain user requests Kerberos service tickets for accounts that have a service principal name, then guesses those accounts' passwords offline until one decrypts a ticket. It needs no administrator rights and no software vulnerability. MITRE ATT&CK tracks it as technique T1558.003, and it is used to move from an ordinary user account to a service account that often holds far more privilege.

How does a Kerberoasting attack work?

It runs in five stages. The attacker gets any domain account, asks the directory which user accounts have a service principal name, requests a service ticket for each one from a domain controller, and then tries candidate passwords against those tickets on their own hardware. When a guess decrypts a ticket, they have the account's real password and sign in as that account. Only the ticket requests are visible to the domain, as event 4769.

Is Kerberoasting still possible in 2026 after Microsoft's RC4 changes?

Yes. Windows updates for CVE-2026-20833 stopped domain controllers issuing RC4 service tickets for accounts with no explicit encryption setting, with enforcement from 14 April 2026 and the rollback option removed from July 2026. That makes each password guess more expensive, but Microsoft states that a weak password can still be brute forced when AES is used, and explicit RC4 settings on an account or a domain are still honored.

How do you detect Kerberoasting?

Collect event 4769 from every domain controller and look for one account requesting tickets for many service accounts in a short time, tickets issued with RC4 (Ticket Encryption Type 0x17), and any request for a decoy service account that runs nothing. Ticket Options values of 0x40800000 or 0x40810000 are supporting evidence only, because Microsoft lists 0x40810000 among the most common values in normal requests. The 2026 Windows updates also added KDCSVC events 201 to 209 in the System log, which record RC4 requests that were flagged or blocked.

How do you prevent Kerberoasting?

Make service account passwords impossible to guess and make the accounts worth less. Move services to group Managed Service Accounts or, on Windows Server 2025, delegated Managed Service Accounts. Where that is not possible, set a random password of 25 to 30 characters, allow only AES and reset the password afterward. Remove unneeded service principal names, and keep service accounts out of Domain Admins and other privileged groups.

What is the difference between Kerberoasting and AS-REP roasting?

Kerberoasting targets accounts that have a service principal name and needs a valid domain account to request their service tickets. AS-REP roasting targets accounts that are set to not require Kerberos pre-authentication, which is not the default, and cracks the authentication reply instead of a service ticket. It can be run without a domain account. Kerberoasting shows up in event 4769 and AS-REP roasting in event 4768. Both end with offline password guessing.

Which event ID shows Kerberoasting?

Event 4769, "A Kerberos service ticket was requested", logged on domain controllers when the Audit Kerberos Service Ticket Operations subcategory is enabled. One event is written per ticket. The fields that matter are Account Name, Service Name, Client Address, Ticket Encryption Type and Ticket Options. Events 4738 and 5136 can show a service principal name being added to an account and removed, the sign of targeted Kerberoasting.

Does a penetration test check for Kerberoasting?

An internal network penetration test usually checks whether a Kerberoastable account forms part of a path to critical systems. An Active Directory security assessment goes further: it lists every account with a service principal name, runs a time-boxed offline password audit, shows what each recovered account reaches and reviews the encryption settings around them. A red team or purple team exercise tests whether the ticket requests are detected.

Related reading

• StingAD: From One Low-Priv Account to Domain Admin

• Active Directory Penetration Testing Services (2026): Scope, Attack Paths and Cost

• Active Directory Security Assessment: What It Covers, What It Finds, What It Costs

• Top 10 Network Security Vulnerabilities to Watch in 2026

• ARTEX and Agentic Offensive Frameworks: What Google Observed and What to Test (2026)

• Internal Penetration Testing (2026): Scope, Delivery, Cost Drivers and Requirements

• The Kerberos Double Hop Problem Is Not a Problem

• Red Team Detection Benchmarks 2026

• Password Spraying: How the Attack Works, Detection and Defense (2026)

• Evil Twin Attack: How Fake Wi-Fi Works, Detection and Fixes (2026)

• Lateral Movement Explained: Attack Paths, Detection and Testing (2026)

• Best Network Penetration Testing Companies (2026): External, Internal and Active Directory

• Network Penetration Testing: What It Is, Types, Process and Cost (2026)

Talk to Stingrai

Want to know which of your service accounts would fall, and what they reach? Stingrai scopes Active Directory security assessments and internal network tests with a reassessment, as a one-time annual engagement or a continuous program. Get a quote.