Key Points
- Kerberoasting lets a domain user request a service account’s Kerberos ticket, then crack it offline to recover its password.
- The attack requests a ticket-granting service (TGS) ticket for a service account, then brute-forces the ticket’s encrypted portion offline.
- Kerberoasting is common because any domain user can request service tickets, and many service accounts run on weak passwords.
- Microsoft’s 2026 AES-only Kerberos rollout narrows the attack, but weak service account passwords stay crackable regardless of encryption type.
- Detecting kerberoasting means watching Windows Event IDs 4768 and 4769 for unusual ticket requests and outdated encryption types.
Active Directory service accounts run the applications, databases, and scheduled tasks that keep a network running. Many of those accounts were created years ago, never rotate their passwords, and hold far more privilege than they need. That combination makes them a reliable target for kerberoasting, an attack that requires no exploit and no malware to get started.
This guide breaks down how the Kerberos protocol makes kerberoasting possible, walks through the attack step by step, and covers the detection and prevention controls that actually reduce risk.
What Is Kerberoasting?
Kerberoasting is an attack that targets the Kerberos authentication protocol that Windows Active Directory networks use to authenticate users and devices. Specifically, kerberoasting is a technique in which an attacker abuses a valid Kerberos ticket, or captures ticket traffic, to obtain a ticket-granting service (TGS) ticket for a service account. The attacker then cracks that ticket offline, away from any domain controller logging, to recover the service account’s plaintext password.
Kerberoasting does not require administrator rights, malware, or a zero-day exploit. Any authenticated domain user can request a service ticket for any account with a registered service principal name (SPN). That low bar is what makes the technique attractive to attackers who have already landed a foothold, even through a low-privilege phished account.
A Quick Primer on Kerberos Authentication and Service Principal Names
Kerberos authenticates users through two different kinds of tickets, issued at two different stages:
- Ticket-granting ticket (TGT): A domain controller’s Key Distribution Center (KDC) issues a TGT once a user first proves their identity. Think of it as a day pass — proof that the user is who they say they are.
- Ticket-granting service (TGS) ticket: The user presents their TGT to request a TGS ticket for a specific service they want to reach, without entering a password again. One TGT can be exchanged for many TGS tickets, one per service.
Kerberoasting targets that second ticket type. When a domain controller issues a TGS ticket for a given service, part of that ticket is encrypted with a key derived from the target service account’s own password. That single design detail is the entire reason kerberoasting works: crack the ticket, and you have effectively cracked the account’s password.
What makes an account a target is a service principal name (SPN) — the value that uniquely identifies each instance of a Windows service. An account’s registered SPN is what marks it as a service account, and it’s what lets any domain user request a TGS ticket for it in the first place.
The Kerberos protocol was formally standardized in Request for Comments (RFC) 4120, published in 2005.
How Does Kerberoasting Work?
Kerberoasting follows a consistent sequence regardless of the specific tool an attacker uses.
- Gain a foothold: The attacker obtains valid domain credentials, often through phishing or a low-privilege compromised account. No elevated rights are needed at this stage.
- Enumerate SPNs: The attacker queries Active Directory for accounts that have a registered SPN, since these are the candidate service accounts.
- Request TGS tickets: The attacker requests a service ticket for each target SPN. Common tools for this step include Rubeus and Impacket, and threat groups such as Wizard Spider have paired Rubeus with the Mimikatz Kerberos module.
- Extract the ticket: The domain controller returns a valid TGS ticket. Part of it is encrypted using a key derived from the service account’s password.
- Crack it offline: The attacker takes the extracted ticket off the network and brute-forces the encrypted portion using GPU-accelerated password cracking, with no further contact with the domain controller and no further logged authentication attempts.
- Reuse the credential: Once cracked, the attacker authenticates as the service account directly, often moving laterally or escalating privilege depending on what that account can access.
Every step up through ticket extraction looks like normal Kerberos traffic. The cracking happens entirely offline, which is why kerberoasting is difficult to catch in the act.
Why Are Kerberoasting Attacks so Prevalent?
Kerberoasting attacks are common for four structural reasons that most Active Directory environments share.
- Low barrier to entry: Any authenticated domain user, not just an administrator, can request a TGS ticket for any SPN. No special privilege is required to start the attack.
- Weak service account passwords: Service accounts are often created once and never revisited. Unlike human users, they rarely face forced rotation or complexity enforcement.
- Legacy encryption still in use: Tickets encrypted with RC4 are especially vulnerable because RC4 derives its key from the password with no salt and no iterated hashing, which lets an attacker test password guesses far faster than against an AES-protected ticket.
- Named threat activity: Groups including FIN7, Wizard Spider, and APT29 have all used kerberoasting during real intrusions, which keeps it a standard step in commodity and targeted attack playbooks alike.
Is Kerberoasting Still Effective in Modern Active Directory?
Yes, though the margin is narrowing.
Microsoft is in the middle of a phased rollout that disables RC4 by default for Kerberos service ticket issuance, tied to CVE-2026-20833, an information disclosure vulnerability tracking RC4’s continued exposure to offline cracking. An audit phase began in January 2026, an enforcement phase that defaults domain controllers to AES-SHA1-only began in April 2026, and the registry-based rollback option is scheduled to disappear entirely in July 2026.
That timeline removes the easiest version of kerberoasting from environments that keep pace with Microsoft’s updates. It does not remove the underlying weakness.
AES alone is not a defense against brute forcing; it only raises the computational cost. A service account with a short, guessable password is still crackable under AES; it just takes longer. Environments that have not applied the RC4 hardening updates, and environments that still assign human-chosen passwords to service accounts, remain squarely exposed.
The difference comes down to how each encryption type derives its keys:
| Encryption Type | Key Derivation | Cracking Speed | Kerberoasting Risk |
| RC4 (legacy) | No salt, no iterated hashing | Fast | High, even with moderately strong passwords |
| AES 128/256 (current default) | Computationally expensive key derivation | Much slower | Lower, but not eliminated for weak passwords |
How to Detect Kerberoasting
Kerberoasting detection relies on domain controller log monitoring rather than endpoint alerts, since the actual password cracking happens offline. The ticket request itself still leaves a trail worth watching.
- Monitor Event ID 4768: This event logs every ticket-granting ticket request and includes the account’s supported encryption types, which helps flag accounts still configured for weak encryption.
- Monitor Event ID 4769: This event logs every service ticket request and generates only on domain controllers, making it the primary signal for kerberoasting activity.
- Flag ticket encryption type 0x17: A 4769 event showing encryption type 0x17 indicates an RC4-encrypted ticket, which is the encryption type kerberoasting tooling typically requests because it is far faster to crack.
- Watch request volume and pattern: A single user account requesting tickets for many different SPNs in a short window, especially outside that user’s normal service usage, is a strong kerberoasting indicator.
How to Prevent Kerberoasting
Kerberoasting prevention comes down to removing the crackable password behind each service account. The most effective defenses target the two things kerberoasting actually depends on: a crackable password and a slow-to-crack encryption type.
Follow these steps to prevent keberoasing in your network:
- Move service accounts to managed accounts: Group managed service accounts (gMSA) generate long, complex, randomly rotated passwords automatically, removing the human-chosen password that makes kerberoasting worthwhile.
- Enforce AES over RC4: Configure service accounts to support AES 128/256-bit Kerberos encryption and reset the account password after the change so it re-encrypts under AES.
- Set a strong minimum password policy: Where a managed account is not possible, enforce at least a 14-character, randomly generated password for every service account and audit for weak passwords on a recurring basis.
- Apply least privilege to service accounts: Limit what each service account can access so a cracked credential has limited value to an attacker.
- Remove unused SPNs: Audit Active Directory for SPNs registered on accounts that no longer need them, which shrinks the pool of targets available to enumerate.
Beyond Service Accounts: Eliminating Crackable Secrets Across the Network
Kerberoasting is an Active Directory-specific attack, and the fixes above (gMSA, AES enforcement, password policy, least privilege) are the direct defenses. But the underlying lesson extends past service accounts.
Any authentication method that relies on a password-derived secret, whether that secret appears in a Kerberos ticket or in a Wi-Fi or VPN login prompt, gives an attacker something to crack or steal.
The same logic that pushes Active Directory teams toward gMSA for service accounts applies to user and device network authentication. Passwords and shared secrets used for 802.1X network authentication, often enforced at the RADIUS server that checks each login, can be phished, guessed, or replayed. Replacing them with certificate-based authentication eliminates the password-derived secret entirely, since there is no password hash for an attacker to extract or crack.
Learn more about certificate-based authentication in this video:
That is the philosophy behind JoinNow Dynamic PKI: issue non-exportable digital certificates to users and devices for Wi-Fi and VPN access instead of relying on passwords or pre-shared keys. It will not stop a kerberoasting attack against your domain controllers, and we don’t claim it does. What it does is close the same category of gap on the network access side, so a crackable secret is not the next kerberoasting-style shortcut into your environment.
Reduce Crackable Credentials With Certificate-Based Access
Service account hardening and phishing-resistant network authentication solve different problems, but they come from the same principle; they stop giving attackers a password to crack. If your team is already auditing Active Directory for weak service account passwords, it’s worth applying the same scrutiny to how users and devices authenticate to Wi-Fi and VPN.
JoinNow Dynamic PKI replaces password-based network authentication with certificate-based access, so there is no service password or shared secret left for an attacker to phish or crack.
Schedule a demo to see how certificate-based authentication fits into a broader plan to reduce crackable, password-derived secrets across your network.
Frequently Asked Questions
What is a kerberoasting attack?
A kerberoasting attack is a technique in which an authenticated domain user requests a Kerberos service ticket for an account with a service principal name, then cracks the encrypted portion of that ticket offline to recover the account’s password. It targets Active Directory service accounts specifically and requires no elevated privilege to begin.
What Windows Event IDs indicate kerberoasting?
Event ID 4768 logs ticket-granting ticket requests, and Event ID 4769 logs the service ticket requests that kerberoasting depends on. Security teams typically correlate 4769 events showing RC4 ticket encryption type 0x17 with unusual request volume from a single account to flag likely kerberoasting activity.
Do you need admin rights to run a kerberoasting attack?
No — that's what makes it dangerous. Any authenticated domain user can request a service ticket for any account with a registered SPN, so an attacker only needs one valid low-privilege account, often obtained through phishing. No administrator access, malware, or exploit is required to begin the attack.
How long does it take to crack a kerberoasted ticket?
It depends almost entirely on the password, not the encryption. A short or dictionary-based service account password can fall to GPU-accelerated cracking in minutes to hours, even under AES. A long, randomly generated password can push the cracking time beyond any practical window — which is why moving service accounts to gMSA or 25+ character random passwords is the core defense.
Does disabling RC4 stop kerberoasting?
Not on its own. Microsoft's 2026 rollout of AES-only Kerberos defaults removes the fastest cracking path, but AES only raises the computational cost — it doesn't make a weak password uncrackable. A service account with a guessable password stays exploitable under AES; it just takes longer. Password strength and managed accounts still matter more than the encryption type alone.
