Kerberoasting is not dead — it just moved to the cloud

Kerberoasting was supposed to be a solved problem. It is documented, detected, and covered in every hardening guide written since 2015. It also still works, because hybrid identity did not remove the attack — it removed the boundary that used to contain it. The service account you never rotated is no longer just a route to a file server. It is a route to a tenant.

The mechanics have not changed. Any authenticated domain user can ask a domain controller for a service ticket for any account that has a service principal name. The KDC does not check whether the requester has any business talking to that service; that is the service's job, later. Part of the ticket it hands back is encrypted with a key derived from the service account's password. Take it offline and you can attack that password on your own hardware, at your own pace, with no failed logons, no lockouts, and nothing further on the wire.

Why the ticket is still crackable

Two conditions have to hold, and in most estates both still do.

The first is that the account has an SPN and a human-chosen password. Machine accounts and group managed service accounts have 120-character random secrets and are not worth a cracking rig's time. An account created in 2014 so an application could reach a database, with a password someone typed and a PasswordNeverExpires flag, is a different proposition.

The second is encryption type. AES-encrypted tickets are slower to attack, but "slower" is not "safe" — it changes the hashcat mode and the rate, not the outcome, and a weak password falls either way. What matters more is that RC4 is frequently still available. The KDC issues what the requester asks for from the set the account supports, so if msDS-SupportedEncryptionTypes is unset or still permits RC4, the requester picks RC4 and gets it. That is not an exploit. It is negotiation working exactly as designed, in favour of whoever is asking.

# Request tickets for every SPN-bearing account the requester can see
GetUserSPNs.py -request -dc-ip 192.0.2.10 acme.local/analyst

# etype 23 (RC4) tickets
hashcat -m 13100 tickets.txt wordlist.txt

# etype 18 (AES256) tickets — different mode, same idea
hashcat -m 19700 tickets.txt wordlist.txt

Everything above happens with a standard user token. No elevation, no exploit, no malware.

What hybrid identity actually changed

The attack is the same. The consequences are not.

When on-premises accounts synchronise to Entra ID, a password recovered from a Kerberos ticket may authenticate somewhere the on-premises directory never reached. Under password hash synchronisation, the credential is usable against cloud resources directly. The service account that existed to run a nightly report now has an attack path that ends in a SaaS console, and the team that owns the report has never heard of the tenant's conditional access policy.

The connective tissue between the two directories is itself worth a look. Entra Connect runs under accounts with substantial on-premises rights, and Seamless SSO creates a computer object named AZUREADSSOACC$ in Active Directory whose Kerberos key is shared with Entra ID. That key is not crackable — it is machine-generated and long. It is also, by default, never rotated. Microsoft's guidance is to roll it over periodically; the mechanism is manual, which in practice means a key created during a migration years ago is still valid today. Nothing about that requires roasting. It requires someone reaching the directory once, and then never being locked out again.

Rotating a service account password is a ticket in a backlog. Not rotating it is a standing invitation with no expiry date.

The practical failure is organisational rather than technical. On-premises identity and cloud identity are usually owned by different teams with different change windows, and the accounts that bridge them belong to neither. They are the accounts nobody wants to touch because nobody is certain what breaks.

What to watch, and where

The crack is invisible to you. It happens on hardware you do not control, against a file that left your network as an ordinary Kerberos response. There is no detection opportunity there at all.

The request is a different matter. Event ID 4769 on a domain controller records every service ticket issued, including the encryption type of the ticket. On a healthy modern estate, an RC4 ticket for a user account carrying an SPN is unusual enough to be worth a look every time it happens.

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"          // RC4-HMAC
| where ServiceName !endswith "$"               // exclude machine accounts
| where ServiceName != "krbtgt"
| summarize
    Requests = count(),
    DistinctServices = dcount(ServiceName)
    by Account, bin(TimeGenerated, 10m)
| where DistinctServices > 3 or Requests > 10

Two signals sit in that query and they behave differently. Encryption type is the precise one and it produces very little noise once legacy applications are catalogued. Volume is the blunt one: a person's workstation asks for the handful of services that person uses, whereas an enumeration pass asks for everything with an SPN in the space of a minute. The blunt signal survives an attacker who requests AES, so keep both.

The strongest detection available here costs almost nothing. Create an account with no purpose, give it an SPN that looks plausible, place it in the right OU, give it a genuinely random 100-character password, and alert on any ticket request for it whatsoever. It has no legitimate consumers, so it has no false positives. It is one of the few detections in Active Directory whose precision does not decay as the estate changes.

The work that actually closes it

Detection tells you it happened. These stop it happening.

• Audit which accounts hold an SPN, and why. This list is almost always longer than the team responsible for it expects, and a portion of it is dead.
• Convert what you can to group managed service accounts. Their passwords are random, long, and rotated by the domain, which removes the offline attack entirely rather than making it slower.
• Where a gMSA does not fit, treat the password like the credential it is: 25 characters or more, generated, stored in a vault, rotated on a schedule that exists.
• Set msDS-SupportedEncryptionTypes to AES only, once you have found the legacy consumers that will break. Doing this without that inventory is how a change window becomes an outage.
• Assign the accounts that bridge on-premises and cloud identity to a named owner, and put their rotation on a calendar. AZUREADSSOACC$ included.

None of this is new advice, which is the uncomfortable part. Kerberoasting is not a clever attack and it has not needed to be for a decade. It persists because service accounts are created under deadline pressure by people who will not be the ones who own them, and because nothing in the directory ever asks whether the password chosen in 2014 is still appropriate for the resources it now reaches.