Kerberoasting: Detection and Investigation in Active Directory

For two weeks, an attacker asked a domain controller for service account tickets and took them away to crack offline. The production identity server at the center of it ran no endpoint agent, so nothing on that machine recorded any of it. Every request succeeded because every request was a legitimate Kerberos operation.

The attack is known as Kerberoasting: someone holding any ordinary user account in your domain asks a domain controller for a service ticket, then cracks a privileged service account's password out of that ticket offline. They exploit no flaw to do it. Nothing fails, nothing locks out, and no alarm has to fire.

The mechanism is ordinary Kerberos. Any authenticated user in an Active Directory domain can ask a domain controller for a service ticket, and the domain controller encrypts that ticket with a key derived from the service account's password. You don't need a special privilege to ask. Nothing about the request may look out of place. The attacker takes the ticket away and works on cracking the password on their own hardware, where none of your monitoring tools can detect their activity.

That two week case comes from Prophet Security's Q3 2026 threat report. What exposed it was the pattern of ticket requests arriving at the domain controller, reconstructed from authentication logs and from telemetry belonging to a different host.

This guide details the assets an attacker steals during an attack and explains why monitoring the domain controller is essential for reliable Kerberoasting detection. Additionally, it addresses the evolving significance of the encryption type field, outlines step-by-step investigation procedures, and provides strategies to harden directory accounts against roasting. For foundational concepts on handling security alerts, refer to our overview on alert triage.

What an attacker gets from Kerberoasting

MITRE ATT&CK tracks Kerberoasting as T1558.003, a sub-technique of Steal or Forge Kerberos Tickets (T1558). The target is any user account carrying a service principal name, or SPN, in its servicePrincipalName attribute. Computer accounts carry SPNs too, but their passwords are long and machine-generated, so nobody bothers. The SPN tells Kerberos which account a service runs as, and the key distribution center will issue a ticket for that account to anyone who asks.

The ticket is not the prize. The password behind it is. And a cracked service account password lasts, where a stolen session does not. These accounts usually have no person attached, no MFA in front of them, and a password nobody has changed in years. Most of them can do more than they need to, because whoever set the account up granted whatever made the application work instead of taking the time to scope the permission to least privilege.

Two things follow from that. An attacker who cracks one useful SPN account often does not need to escalate again. And there is no failed login burst to alert on, unlike the patterns behind a credential stuffing investigation, because every request in a Kerberoasting run is a legitimate, successful Kerberos operation.

Why Kerberoasting detection happens at the domain controller

The request and the crack happen in two different places. One touches your domain controller. The other happens on hardware you do not own and cannot instrument. In between, the attacker's own machine still leaves evidence, though you rarely have visibility into it. Common Kerberoasting tools have known detections, and the LDAP enumeration and service ticket requests they generate can be tracked in domain controller event logs. That evidence can be hard to sort through, but it is still worth collecting.

You have very little endpoint telemetry to work with here, and that is a real departure from most of what arrives in the queue. The techniques in our guide to investigating EDR alerts assume the attacker's process did something on a host you are watching. Kerberoasting does not require that. In the case above, the machine under attack carried no agent, so there was nothing to investigate on the asset that mattered.

So the main event to collect is 4769, "A Kerberos service ticket was requested." It is written to the Security log on domain controllers only. The common gap is that the DCs generate it and nobody forwards it. Check what your SIEM is actually receiving before assuming the data is there. Microsoft also extended the event schema in the January 2025 cumulative update for Windows Server 2016 and later. It now carries the account's supported encryption types and the encryption types advertised in the request, both useful here.

{{ebook-cta}}

The encryption type signal, and why it catches less than it used to

The classic detection is the Ticket Encryption Type field on event 4769. These are the values you will see:

• 0x17 RC4-HMAC, the legacy default before Windows Vista and Server 2008
• 0x18 RC4-HMAC-EXP
• 0x11 AES128-CTS-HMAC-SHA1-96
• 0x12 AES256-CTS-HMAC-SHA1-96
• 0x1 and 0x3, the DES variants, disabled by default since Windows 7 and Server 2008 R2
• 0xFFFFFFFF, which appears on failure events

Attackers target accounts with legacy encryption types, like 0x17. The RC4 key comes straight from the password, with no salting and no iteration, so an RC4 ticket cracks far faster than an AES one. Microsoft's own guidance says to expect only 0x11 and 0x12 in a current environment, and to treat DES or RC4 as odd.

Before relying on this indicator to build a detection, consider two factors that have already diminished its efficacy.

The first is that Microsoft has already turned RC4 off. The change addresses CVE-2026-20833, and it landed in three phases through 2026. January was audit only. From April, the KDC issued AES-only tickets for any account with no explicit msDS-SupportedEncryptionTypes value. In July the rollback option went away and enforcement became permanent.

So RC4 still works, but only where somebody has explicitly configured an account to accept it. What decides that now is the account's msDS-SupportedEncryptionTypes attribute, the domain controller's DefaultDomainSupportedEncTypes registry value (which is what the April 2026 change flipped to AES), and the Group Policy setting for allowed Kerberos encryption types. Domain functional level is not what decides whether RC4 is issued.

Plenty of environments still allow RC4 on purpose, usually for a legacy system that can't do AES, such as an old appliance, a storage array, a Java app or Linux keytab running an old Kerberos config, or a vendor product nobody has touched in years. A 0x17 rule fires every time those services authenticate, and the easy move is to suppress it. Don't. List the accounts that still allow RC4 and the hosts that normally request tickets for them, then alert on anything outside that list: RC4 for an account that isn't on it, or a ticket for a listed account requested from a host that has never asked before. Those accounts are also the easiest to crack in the domain, so put them first in line for the hardening steps below.

The second is that attackers were already declining the tell. Tools exist that ask for AES tickets on purpose, to get past RC4-based detections. AES tickets are slower to crack, not impossible. A weak password is still weak either way. And RC4-only detection fires on things that are not attacks, because until the April 2026 change, user accounts with SPNs defaulted to RC4 wherever msDS-SupportedEncryptionTypes was unset.

Keep the encryption type check. Before you rely on it, find out what your domain actually enforces, and pair it with detections that do not depend on the attacker choosing the noisy option.

How to detect Kerberoasting without relying on the encryption type

Rather than relying solely on encryption types, three stronger signals offer more reliable detection.

1. Request volume and spread per account. Trimarc's research recommends flagging a single account that requests service tickets for many distinct services in a short window, and any account generating an unusual count of 4769 events. A real application asks for the few services it talks to. An enumeration run asks for everything it found. Two filters make a 4769 rule survivable at domain controller volume: exclude service names ending in $, which are computer, trust, and managed service accounts with machine-generated passwords nobody can crack, and look for Ticket Options 0x40810000, the value common Kerberoasting tools set. Neither is proof on its own, but together they cut most of the noise. Microsoft Defender for Identity's Suspected Kerberos SPN exposure alert (external ID 2410) fires on this pattern, SPN enumeration followed by a burst of service ticket requests, and is a reasonable starting point if you run it.
2. Decoy SPN accounts. Sean Metcalf's guidance at ADSecurity is to create a bait account with a unique, made-up SPN that corresponds to no real service, set its AdminCount attribute to 1 so it looks privileged, and alert on any service ticket request for it. A weak password is optional bait; the ticket request alone is the signal. No real service will ever ask for that ticket. Legitimate tools can still request it, though. Internal AD auditing and scanning tools, for example, can request tickets to check whether accounts are crackable, so expect some tuning.
3. Requests that break the account's own history. This is the one that catches a careful attacker. Baseline which accounts normally request tickets for which services, then alert when an account requests one it never has before. It needs more data retention than the other two, and it takes the most tuning. But it does not care which encryption type the attacker picked. No off-the-shelf alert does this well; it is custom detection work. Building the baseline yourself is close cousin to the work in threat hunting with AI.

How to investigate a Kerberoasting attack

Once a Kerberoasting alert fires, follow the steps below to understand what happened and what's at risk.

1. Scope the requests. Pull every 4769 in the window, not only the events for the alerting account. Record the requesting account, the distinct service names requested, the source addresses, the encryption types, and the start and end of the burst. A run that touched three SPN accounts is a different problem from one that touched sixty.
2. Find out which account made the ticket requests, then judge whether that account had any business making them. A request from a workstation account, a brand new account, or an account that has never touched the directory this way matters more than one from a jump host that does this daily. And if the requester is itself a service account, you may be looking at the second hop, not the first.
3. Identify the source IP and pivot from it. The Client Address field on each 4769 shows where the requests came from. If you suspect an attacker has access to the environment, the type of address tells you which other sources to check. For example, a VPN address is a big red flag, so go to the VPN logs. For an internal workstation address, check that host's 4688 events for RDP session processes and Kerberoasting tooling, and its 4624 type 10 logons for the source of the remote session.
4. Establish which accounts were exposed. List the SPN accounts the run requested tickets for, then check what each one can do. What is at risk is whatever that account can reach, not the ticket. Domain admin, delegation rights, and local admin on servers are the ones that change your response.
5. Check what came before. Kerberoasting is rarely the first step. Look for the preceding LDAP enumeration, for how the requesting account was obtained, and for prior alerts on the same account or address in the trailing month. Where the account is a user identity, the entry point is often an ordinary compromise of the kind covered in our guide to investigating Okta alerts. A geographic mismatch on that login is worth checking against the impossible travel criteria.
6. Assume the crack may already have worked. You cannot watch offline cracking, so you have to work it out from the other side. Look for the exposed accounts logging in from places or at hours that do not match their history. Look for new sessions on hosts they can reach, and for any change made with them. Until you know, treat the account as compromised. Nothing you can find would prove it was not cracked.
7. Rotate, then verify the rotation held. Reset the passwords on the exposed accounts, then check that the services using them picked up the new credential. Rotation often fails quietly. A rotation that broke an application tends to get rolled back at 2am by someone who will not file a security review. Rotation does not evict existing sessions either. Service tickets already issued under the old key remain valid until they expire (10 hours by default, renewable for 7 days), so a rotated account can still be in use for the rest of the day.

The exposure is usually on an asset nobody is watching

The Prophet Security case in the Q3 report is instructive in that the Kerberoasting ran for over two weeks against a production identity server with no endpoint coverage. Several of the longest-running intrusions in that dataset were surfaced through telemetry from a host other than the one the attacker worked from.

Building the picture from other machines is slow, and it may turn up nothing. So it gets skipped when four hundred other alerts are waiting. What came back in that investigation included something nobody asked for: a list of assets authenticating to the directory with no agent reporting on them.

That list underscores the need to reconcile your endpoint agent coverage against your authentication logs rather than your asset inventory. An inventory tells you what someone wrote down. The authentication log tells you what is actually talking to your directory. That includes machines nobody ever inventoried, and ones whose agent went quiet months ago. Dormant and orphaned accounts sit in the same blind spot, which is what we found unmasking zombie credentials in an acquired subsidiary.

Making Kerberoasting not worth the effort

You cannot block Kerberoasting outright. Handing service tickets to authenticated users is what Kerberos is for. What you can do is make the stolen ticket worthless.

Group managed service accounts are the strongest answer. A gMSA password is 120 characters, randomly generated, and rotated automatically on a schedule that defaults to 30 days. An attacker can still Kerberoast a gMSA and still request the ticket, but nobody will crack a 120-character random password before it rotates. Windows Server 2025 also introduced delegated managed service accounts, which bind authentication to specific machine identities and keep the secret on the domain controller. They are worth adopting, with the caveat that the BadSuccessor technique disclosed in 2025 showed that write access to a dMSA object can be abused for privilege escalation, so lock down who can create or modify them.

Where a gMSA will not work, length is what matters. Microsoft sets a 14 character floor for service accounts and wants much longer, fully random, and not a word from any dictionary. Microsoft says plainly that moving to AES is not enough on its own. It has to come with strong passwords.

Then find out what you have. You can query the same attribute the attacker does. List every user object with a non-null servicePrincipalName, and for each one write down the password age, what it can do, and whether the service behind it still exists. Any account that fails the third check is the cheapest thing on this list to fix, since you can usually disable it rather than rotate it. That audit has a blind spot. An account with GenericWrite, GenericAll, or Validated-SPN rights over another user object can write an SPN onto it and roast it, so an account with no SPN today is still exposed if the wrong people can edit it. Review who holds write rights over privileged user objects as part of the same exercise. Turning that audit into standing coverage is the job of an AI detection engineer.

Where this leaves the analyst

You cannot take the usual shortcuts with Kerberoasting. The alert that fires is a normal Kerberos operation. RC4 is gone as a default, and RC4 is what most existing detections key on. The offline half of the attack is invisible by design. And the assets where it runs longest are the ones carrying the least instrumentation. Answering it properly means pulling the full request set, mapping exposed accounts to their privilege, and reconstructing events from directory telemetry when the host has none.

That work is procedural and it takes time, which is why it competes badly against a queue. Prophet AI SOC Analyst investigates every alert to that depth without prioritizing. It scopes the request window, maps the exposed service accounts, and follows what those accounts did afterwards, recording the evidence behind each step. Request a demo of Prophet AI to see how it runs a full investigation against your own alerts.

Frequently asked questions

What is the difference between Kerberoasting and pass-the-hash?

Kerberoasting recovers a service account's plaintext password by cracking a Kerberos service ticket offline. Pass-the-hash reuses a stolen password hash directly for authentication without ever recovering the password. Kerberoasting needs no privilege to start and no access to the target host, only a valid domain account. Pass-the-hash requires first obtaining the hash, usually from memory on a compromised machine.

Which event ID should I alert on for Kerberoasting?

Event 4769, A Kerberos service ticket was requested, written to the Security log on domain controllers only. A default domain controller logs it on success, but Failure auditing is off by default and the event is only useful if it is being forwarded. Check that it is actually being collected before building any detection on it, because many environments generate it and never ship it anywhere.

Has AES encryption made Kerberoasting obsolete?

No. AES tickets are slower to crack than RC4 tickets, not impossible, and a weak service account password remains crackable either way. Microsoft states that moving to AES is not sufficient on its own and must be paired with strong passwords. What did change is the RC4 signal: under CVE-2026-20833 Microsoft removed RC4 as a default through 2026, so alerting on encryption type 0x17 catches less than it used to.

How do I find which accounts are exposed to Kerberoasting?

Enumerate every user object with a non-null servicePrincipalName attribute, which is the same attribute an attacker queries. For each account, record the password age, the privilege it holds, and whether the service behind it still exists. Accounts supporting a service that no longer runs are the cheapest exposure to remove, since they can usually be disabled rather than rotated.

Are group managed service accounts immune to Kerberoasting?

Not immune, but impractical to crack. A group managed service account with a service principal name can still be Kerberoasted and its ticket can still be requested. The password is 120 characters, randomly generated, and rotated automatically on a 30 day default schedule, so no practical cracking effort will recover it before the next rotation.

How can I tell whether a Kerberoasted password was actually cracked?

You cannot observe the cracking, because it happens offline on the attacker's own hardware. The determination has to come from the exposed account's later behavior: authentication from sources or at times that do not match its history, new sessions on hosts it can reach, or changes made using it. Treat the account as compromised, since no available evidence would prove otherwise.