Skip to content
Start with Identity
Join free
SWI-T018 · Directory and trust

Kerberoasting

Any authenticated domain user can request a Kerberos service ticket for any service principal, and that ticket is encrypted with the service account's own password hash, offline and unrateable to test.

WidespreadModerate
First observed: 2014ATT&CK T1558.003 ↗

Kerberoasting is an offline password attack on Active Directory service accounts. Any domain user can ask the domain controller for a service ticket to any account that has a service principal name (SPN), and part of that ticket is encrypted with a key derived from the service account's password. The attacker takes the ticket away and guesses the password on their own hardware, with no lockout and no failed logon anywhere. Tim Medin presented it in 2014; MITRE ATT&CK lists FIN7, Wizard Spider, and APT29 in the SolarWinds compromise among its users. It still works in 2026 wherever a human-set service account password meets an RC4 ticket.

How it works

  1. Get any domain foothold. A phished workstation, a VPN account, or a compromised appliance that holds directory credentials is enough. No privilege is needed.
  2. Enumerate SPNs. An LDAP query for user objects with a servicePrincipalName lists every service account that can be roasted. Computer accounts also have SPNs, but their passwords are long, random, and rotated automatically, so attackers filter for user accounts.
  3. Request service tickets. For each target, the attacker sends a normal TGS request. In Kerberos, requesting a ticket is not an authorization check: the KDC issues it to any authenticated requester and leaves access decisions to the service. Tools such as Rubeus and Impacket's GetUserSPNs ask for the RC4-HMAC encryption type where the account allows it, because RC4 keys are the unsalted NT hash and are far faster to guess than AES keys.
  4. Crack offline. The encrypted ticket portion is written out in a format password crackers accept. A password set by an administrator years ago, short enough to type, falls to a wordlist with rules.
  5. Use the account. Service accounts are often members of privileged groups because it was easier at install time. Microsoft Defender for Identity has a posture assessment specifically for service accounts in privileged groups for this reason.

CVE-2025-60704 (CheckSum), disclosed at Black Hat Europe in December 2025, is a related but distinct Kerberos flaw: the KDC skipped a cryptographic verification step in the S4U2self extension, letting an attacker forge an identity assertion rather than recover a password. Microsoft rated it Important (CVSS 7.5). It belongs to Kerberos delegation abuse and is listed here because both live in the same patch train. Microsoft also tracks RC4 service ticket issuance itself as CVE-2026-20833, an information disclosure flaw described as letting an attacker obtain weak-encryption service tickets for offline password recovery.

Why it works

Kerberos assumes the service key cannot practically be derived from a ticket. That holds for a 120-character random computer password and fails for Summer2019!. The control assumption that breaks is password strength and rotation on accounts nobody logs into interactively: no lockout to trip, no MFA prompt to fail, and often no owner who knows whether the password has changed since the application was installed. RC4 compounds it. An account with no explicit encryption settings historically got RC4 tickets on request, and Protected Users, the group that refuses RC4, is explicitly not for service accounts. The protocol behavior is correct; the exposure is entirely in what happens to the ticket after issuance, on hardware the defender never sees.

How to detect it

  • Event 4769 with Ticket Encryption Type 0x17. Event 4769 ("A Kerberos service ticket was requested") is logged on domain controllers. Microsoft's own guidance is to monitor for any Ticket Encryption Type other than 0x11 or 0x12 (AES), and 0x17 is RC4-HMAC. MITRE's analytic for T1558.003 pairs this with volume: one account requesting tickets for many distinct SPNs in a short window.
  • Use the new 4769 fields. Since the January 14, 2025 security update, Windows Server 2016 and later log an updated 4769 that includes the service account's supported encryption types, its available keys, and the client's advertised encryption types. A request where the client advertised AES but the ticket came back RC4, or a service account whose available keys are RC4 only, is a far better signal than raw volume.
  • KDCSVC events 201 to 209. Microsoft's CVE-2026-20833 guidance adds System log events from the KDCSVC source. Event 202 warns that a service account has only RC4 keys; 204 records the KDC blocking such a request under enforcement. These are an inventory of roastable accounts before an attacker builds one.
  • Honeypot SPNs. A user account with an SPN, a long random password, and no legitimate client generates a 4769 only when someone enumerates and requests it. This is the cleanest signal available.

The false-positive problem is real. Requesting service tickets is what every Kerberos client does all day, and inventory tools, vulnerability scanners, and older Java or non-Windows clients that default to RC4 generate the same events. Baseline per account and per source host, and treat RC4 on an account that has AES keys as the anomaly, rather than alerting on every 0x17. Expect the RC4 signal to get cleaner as enforcement removes the legitimate RC4 noise.

How to stop it

Ranked by effect:

  1. Move service accounts to group Managed Service Accounts (gMSA). Active Directory sets and rotates a long random password automatically, which makes offline cracking pointless. This is the only control that removes the attack rather than slowing it.
  2. Finish the RC4 removal. Microsoft's CVE-2026-20833 rollout began with audit events on January 13, 2026, made AES-SHA1 the KDC default for accounts without an explicit msDS-SupportedEncryptionTypes value on April 14, 2026, and removes the RC4DefaultDisablementPhase rollback in the July 2026 updates. Accounts that still have RC4 set explicitly, or a domain-wide DefaultDomainSupportedEncTypes override that re-enables RC4, stay roastable at RC4 speed. Hunt those exceptions down.
  3. Reset every remaining human-set service account password to 25 or more random characters (MITRE's M1027 guidance), which also generates AES keys for accounts that have never had a password change since the domain functional level was raised.
  4. Take service accounts out of privileged groups. A cracked account that can only reach its own database is a contained incident.
  5. Remove SPNs nobody uses and deploy a honeypot SPN for detection.
  6. Patch the KDC for CVE-2025-60704 and the rest of the Kerberos train; strong passwords do not mitigate a forgery bug. See PAM for governing the accounts that must stay privileged, and Active Directory for the wider tier-zero model.

Seen in the wild

The Identity Breach Report 2026 counts the Ivanti record under authentication, not directory trust, because the appliance bypass was the way in. That is typical: Kerberoasting is rarely the headline of a disclosure and usually appears in the forensic timeline.

Sources

Related identity CVEs and breaches

Last reviewed By SWI Community TeamSuggest a correctionHow we research

In the Identity Breach Database

Real incidents in our sourced breach database where this technique was used.

Browse the full database

Seeing this technique used differently, or have a detection rule that works better? Email community@startwithidentity.com. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.