Kerberoasting has stuck around for years, and not because anyone forgot to patch it. The technique targets Kerberos, the authentication protocol that sits at the heart of every Active Directory domain, and it abuses a feature of that protocol rather than a bug. That makes it one of the easiest credential attacks to pull off in an AD environment: an attacker who has compromised even a single low-privilege domain account can ask a domain controller for Kerberos service tickets tied to privileged service accounts, walk away with the encrypted material, and crack it on their own hardware at their own pace.

There's no exploit involved and no vulnerability to fix in the traditional sense. The attack rides on top of how Kerberos is designed to work, which is exactly why it keeps showing up in real-world intrusions long after defenders first learned the name.

• Kerberoasting works by abusing normal Kerberos ticket requests to obtain service tickets that can be cracked offline.

• The most exposed targets are SPN-backed user accounts with weak or long-lived passwords and unnecessary privilege.

• Useful detection has to focus on ticket requests, encryption types, and precursor SPN enumeration before cracking succeeds.

• The strongest defenses combine AES enforcement, service account modernization, password resets, and reduced privilege.

A kerberoasting attack follows a predictable sequence: identify SPN-backed targets, request tickets, and crack them offline. It works because Kerberos issues service tickets before authorization is checked, which means the attacker can request the ticket and attack the encrypted material without ever presenting it to the target service.

A user proves identity to the KDC by encrypting a timestamp with a password-derived key and receives a Ticket-Granting Ticket (TGT). The user then presents the TGT and requests a service ticket for a specific Service Principal Name (SPN). The KDC issues that ticket without checking whether the user should have access.

The protocol delegates authorization to the service itself, which is expected to check permissions after decrypting the ticket. In a kerberoasting attack, the attacker never presents the ticket to the service, so that authorization check never occurs.

The KDC encrypts the service ticket using a key derived from the service account's password. Anyone who captures that ticket possesses ciphertext they can attack offline. No lockout threshold, failed-login logging, or rate limiting applies offline. The attacker can test password candidates without generating any network traffic.

Services running under built-in computer accounts use long, complex, machine-generated passwords that are automatically rotated, while services running under domain user accounts rely on human-chosen passwords that are often weaker. This distinction is where the vulnerability lives.

Service accounts frequently carry passwords that have not been changed in years. Many organizations set the "password never expires" flag on service accounts to avoid service disruptions during rotation windows, and those accounts can accumulate risk over time when passwords remain unchanged. A typical enterprise Active Directory may contain dozens or hundreds of SPN-bearing user accounts, each one a potential target.

The attacker identifies which domain user accounts have SPNs registered. Impacket's GetUserSPNs.py can be used to get Service Principal Names (SPNs) for user accounts. Rubeus offers a kerberoast /stats command that enumerates without requesting tickets. These queries use standard LDAP filters, and defenders monitoring for queries filtering on servicePrincipalName across user objects can detect this precursor signal.

Any authenticated domain user can request one or more Kerberos ticket-granting service (TGS) service tickets for any SPN from a domain controller. The KDC returns service tickets encrypted with each target account's password-derived key.

Sophisticated attackers may spread ticket requests over time to avoid volume-based alerts. Some tool options also change which Kerberos events are produced, which matters for defenders who rely on only one event stream.

Captured service tickets can be taken offline and formatted for cracking tools like John the Ripper and Hashcat. Weak service account passwords are more likely to be recovered.

This offline phase is invisible to security tools monitoring the domain. Recovered credentials grant whatever privileges the service account holds, and if the account carries Domain Admin membership, a single cracked password leads to full domain compromise.

The difference between RC4 and AES for Kerberos tickets changes the practical feasibility of offline cracking.

RC4 uses MD4, a single-pass hash function. The result is identical to the account's NTLM hash, so each password guess requires just one hash operation. AES-based Kerberos encryption types such as AES256-CTS-HMAC-SHA1-96 and AES128-CTS-HMAC-SHA1-96 use SHA-1 in the HMAC component. Every guess must go through all of those rounds before the attacker can test it.

On modern hardware, RC4 ticket cracking runs much faster than AES. A weak service account password that falls quickly under RC4 becomes much harder to recover under AES because of that higher per-guess cost. Disabling RC4 is a high-impact encryption-related control for defenders, particularly for reducing Kerberoasting risk.

The etype field in a TGS-REQ is set by the client, not the server. An attacker can explicitly request RC4 encryption even when the target account supports AES, and the KDC will honor that request unless a policy prevents it.

Many organizations created service accounts years before AES was available or enforced. Those accounts silently carry undefined encryption type attributes to this day. Accounts created before AES enforcement was configured silently remain subject to downgrade risk. Microsoft's Kerberoasting guidance identifies moving service accounts to AES and manually disabling RC4 where possible as important mitigations.

Detection must happen at the ticket-request stage because the cracking phase generates zero network traffic.

Event ID 4769 logs every Kerberos service ticket request on domain controllers, but only if the "Audit Kerberos Service Ticket Operations" policy is enabled. The most important field is TicketEncryptionType: a value of 0x17 indicates RC4, while 0x12 indicates AES-256. The ServiceName field identifies which SPN was requested, distinguishing user-account targets from machine-account targets.

A detection rule targeting Event 4769 where TicketEncryptionType equals 0x17, the requesting account is not a machine account, and the service name targets a user-account SPN creates a high-fidelity signal for the most common kerberoasting pattern.

Event ID 4768 logs TGT requests and can be important for Kerberos detection coverage, especially when defenders want visibility beyond rules that focus only on Event ID 4769.

Beyond signature-based detection, volume anomalies matter. SIEM correlation logic can calculate the average service ticket requests per account per time window and alert when counts exceed the normal baseline for that environment. This approach is platform-agnostic and adapts to each environment's traffic patterns.

A honey account is a decoy user account with an SPN registered but no legitimate purpose. Any single Event 4769 targeting its SPN is a true positive with no threshold required. Effective honey accounts should use a long, strong, generated password that cannot be brute-forced. Current guidance does not recommend enabling RC4, and organizations are shifting Kerberos accounts toward AES and away from RC4.

Precursor LDAP monitoring adds a second detection layer. Before requesting tickets, attackers must enumerate which accounts have SPNs. These queries typically precede the actual ticket requests.

Prevention centers on how service accounts are provisioned, which encryption types are allowed, and how much privilege those accounts carry.

Group managed service accounts (gMSAs) are a recommended mitigation for reducing service account credential risk. Their passwords are long, randomly generated, and automatically rotated by Active Directory.

Most modern Windows services support gMSAs, but some legacy or third-party applications cannot run under a gMSA identity, so compatibility testing is a prerequisite. For accounts that cannot migrate, a fine-grained password policy enforcing a minimum of more than 25 characters is the fallback.

Configuring the Group Policy setting "Network Security: Configure encryption types allowed for Kerberos" to permit only AES-256 and future encryption types can help disable RC4 on devices, but preventing the KDC from issuing RC4 tickets also depends on the target account's msDS-SupportedEncryptionTypes configuration. The recommended sequence is to audit AES support across SPN-bearing accounts, set msDS-SupportedEncryptionTypes to AES on each account, verify no tickets fall back to RC4, then disable RC4 via Group Policy.

Equally important: Microsoft guidance states that user accounts with SPNs should be audited and SPNs should be removed from accounts where they are not needed to reduce the attack surface. Orphaned SPNs pointing to services that no longer exist still make accounts targetable.

Accounts with Domain Admin membership that also carry an SPN are especially high risk because the impact of a cracked service account increases with its privileges.

One frequently overlooked step: changing msDS-SupportedEncryptionTypes to AES without resetting the account's password does not remove the vulnerability. The old RC4 or NTLM hash remains valid until the password is actually reset. Password resets should happen in the same maintenance window. According to the Verizon 2025 DBIR, credential abuse remains a leading initial access vector for breaches.

Kerberoasting differs from related Kerberos ticket attacks because it starts with ordinary domain access and targets service tickets for offline cracking rather than forged tickets or preauthentication gaps.

Both kerberoasting and AS-REP roasting produce encrypted material for offline cracking, but they target different stages of the Kerberos protocol. Kerberoasting exploits the TGS exchange and works against any account with an SPN, requiring only a valid domain user. AS-REP roasting targets the AS exchange and works only against accounts where Kerberos preauthentication is disabled, a specific misconfiguration. Preauthentication is enabled by default, so AS-REP roasting requires an explicit misconfiguration. Kerberoasting abuses normal protocol behavior against every user account with a registered SPN.

A silver ticket requires a specific service account's password hash and forges TGS tickets for a single service without contacting the KDC.

These attacks form a progression along the Kerberos attack chain. Kerberoasting is generally considered a low-privilege ticket-based attack because it can be performed with a standard domain user account. Successfully cracked service account hashes then supply the input for silver ticket forgery. Golden tickets typically require prior compromise of Active Directory, such as access to a domain controller or the KRBTGT account hash, before they become possible. MITRE ATT\&CK notes kerberoasting as one method for obtaining the service account hashes that enable silver ticket forgery.

Kerberoasting persists because it exploits protocol design, not software flaws, and the cracking happens where defenders have no visibility. The practical response is a layered set of decisions: choosing the right account types, enforcing the right encryption, logging the right events, and reducing privilege.

Kerberoasting remains operationally important because documented intrusions continue to use the technique or its prerequisites. CISA advisory AA24-190A documents APT40 using a kerberoasting attack within a DMZ intrusion. CISA advisory AA24-290A describes Iranian cyber actors performing SPN enumeration and receiving RC4 tickets.

The technique can be initiated with valid domain credentials. Any adversary who gains an initial foothold through phishing, infostealers, or purchased credentials can begin requesting service tickets immediately.

Kerberoasting risk drops when service accounts are modernized, RC4 use is reduced, and privileges are kept narrow. Treating service account management as ongoing hygiene, rather than a one-time cleanup, helps reduce how useful a stolen ticket becomes over time.