Kerberoasting Attack Explained: From a Normal AD User to Domain Admin

Hand us one valid domain account on almost any Active Directory network and there is a good chance we walk out with a service account password before lunch. No exploit. No malware. No admin rights. Just Kerberos doing exactly what it was designed to do. That is a Kerberoasting attack, and it is still one of the most dependable routes from an ordinary user to Domain Admin that we hit on internal tests.

What makes it stubborn is that there is no patch for it. The weakness is a pile of service accounts with weak, human-chosen passwords that never rotate, sitting behind a protocol that will hand any authenticated user the material needed to crack them. A Kerberoasting attack is quiet, patient, and almost entirely offline. That combination is exactly why defenders keep missing it.

Below we walk through how Kerberos service tickets work, why a Service Principal Name (SPN) puts service accounts in the crosshairs, how the attack chains toward domain dominance, and the mitigations that actually survive contact with production. The technique maps to MITRE ATT&CK T1558.003.

Key takeaways

• A Kerberoasting attack lets any authenticated domain user request Kerberos service tickets for accounts that have an SPN, then crack those tickets offline to recover the plaintext password. No elevated privileges required.
• The ticket is encrypted with a key derived from the service account password, so weak or stale passwords fall to hashcat fast, especially when RC4 (encryption type 0x17) is still allowed.
• Service accounts are routinely over-privileged, so one cracked password often means local admin across many hosts, access to sensitive data, or a direct path to Domain Admin.
• Detection leans on Kerberos event 4769 anomalies (RC4 requests, high volume from a single user) and honeypot SPN accounts that no real service should ever query.
• The durable fix is group Managed Service Accounts (gMSAs) or 25-plus character random passwords, AES enforcement, pruning unused SPNs, and least privilege backed by admin tiering.

What is a Kerberoasting attack?

A Kerberoasting attack is an offline password-cracking technique aimed at Active Directory service accounts. Any domain user can ask a Domain Controller for a service ticket to any account that has a registered SPN. Part of that ticket is encrypted with a key derived from the service account password. The attacker grabs the ticket, walks away, and brute-forces the password on their own kit, never touching the Domain Controller again.

The danger is in the asymmetry. Requesting a ticket is a normal action that every workstation performs hundreds of times a day, so it blends into the noise. The cracking happens on the attacker’s hardware, invisible to your logs. And the accounts most likely to carry an SPN, things like SQL Server, IIS app pools, and various HTTP or MSSQL services, are usually the ones with the broadest access and the oldest passwords. That is the worst possible combination.

How do Kerberos service tickets actually work?

Kerberos authentication has three moving parts: the client, the Key Distribution Center (KDC, which lives on every Domain Controller), and the target service. When you log in, the client sends an AS-REQ and gets back a Ticket Granting Ticket (TGT) in the AS-REP. The TGT is proof of who you are.

When you want to reach a service, the client presents that TGT and sends a TGS-REQ naming the SPN, say MSSQLSvc/db01.acme-corp.local:1433. The KDC responds with a TGS-REP containing a service ticket. Here is the detail that matters: the ticket is encrypted with the long-term key of the account that owns the SPN. For RC4, that key is literally the account’s NT hash. For AES, it is a key derived from the password and a salt.

Now the part attackers love. The KDC never checks whether you are actually allowed to use the service. It only verifies that you hold a valid TGT, then hands back a ticket encrypted with the service account’s key. Authorization happens later, at the service itself. So the KDC will cheerfully give any authenticated user an encrypted blob derived from any service account’s password. You have to ask nicely, and it says yes.

What is an SPN and why are service accounts the target?

A Service Principal Name is a unique string that ties a service instance to the account running it, so Kerberos knows whose key to use when it encrypts the ticket. Computer accounts have SPNs too, but their passwords are long random strings that rotate on their own, which makes them effectively uncrackable. The soft targets are user accounts with SPNs: the domain service accounts a human created and configured by hand.

That is where the risk pools. In our engagements we regularly find service accounts with passwords set five or more years ago, picked by an admin who wanted something they could remember, and frequently reused across environments. Password-policy exceptions are the norm here because “the app breaks if the password rotates.” Finding these accounts is trivial for any domain member, since SPNs are readable directory attributes. A single line pulls them:

# Native, no tooling required
setspn -Q */*

# Impacket, from a non-domain-joined attacker box
GetUserSPNs.py acme-corp.local/lowpriv:'Password123' -dc-ip 10.0.0.10 -request

# Or on-host with Rubeus
Rubeus.exe kerberoast /outfile:hashes.txt

How does the Kerberoasting attack work step by step?

The attack is short and it needs nothing but one working domain account. Enumerate accounts that have an SPN, request a TGS for each, extract the encrypted portion of every ticket, then crack it offline. Four moves, and only the first two touch the network.

The request phase is where Rubeus and Impacket’s GetUserSPNs do their work. They query the directory for user objects with a servicePrincipalName set, fire a TGS-REQ for each, and format the returned tickets into hashcat-ready strings. Most tools will also let you force RC4 to get the fastest hash type back, which is precisely the behaviour a defender can watch for. An RC4 Kerberoast hash starts with $krb5tgs$23$; AES256 comes back as $krb5tgs$18$.

The cracking phase is pure offline compute. RC4 tickets use hashcat mode 13100. AES tickets are slower but still crumble against a decent wordlist, using modes 19600 (AES128) and 19700 (AES256).

# RC4 (etype 23 / 0x17) - fastest to crack
hashcat -m 13100 hashes.txt rockyou.txt -r rules/best64.rule

# AES256 (etype 18) - slower, still viable against weak passwords
hashcat -m 19700 hashes.txt rockyou.txt

Note that nothing calls back to the Domain Controller while cracking runs. Once the tickets are captured, the attacker can pull the network cable and keep grinding. A short or dictionary-based password can fall in minutes. This is why the strength of the service account password is the entire game.

Why do weak service-account passwords make this so deadly?

Because the whole defense of the encrypted ticket rides on password entropy, and nothing else. Kerberos does not rate-limit offline guessing. There is no account lockout. There is no alert once the ticket leaves the KDC. A ten-character password built from a dictionary word and two digits is not a speed bump against a modern GPU. A genuinely random 25-character password is a brick wall.

Reuse and staleness make it worse. Service account passwords almost never change, so one you crack today may have been valid for years, and valid across test, staging, and production at the same time. We have watched a single cracked account unlock dozens of servers simply because it was dropped into the local Administrators group on every box it ran on.

How does Kerberoasting chain toward Domain Admin?

Cracking the password is the pivot, not the finish. What comes next depends on how privileged the account is, and service accounts are famous for privilege creep. The chains we see most often look like this:

• The account is a local administrator on many hosts, so we get code execution and dump more credentials out of LSASS on each one, sweeping up cached domain admin sessions along the way.
• The account was added straight into Domain Admins or a similarly powerful group, usually “for now” during a migration, then never removed. That is the whole engagement in one line.
• The account holds dangerous directory rights, like the ability to reset other users’ passwords or write membership to a group, which BloodHound will draw as a path into Tier 0.

The point is that a Kerberoasting attack rarely ends at one account. It is a foothold that turns into lateral movement and then privilege escalation, and the shortest paths to Domain Admin are almost always the ones nobody knew existed. BloodHound makes those paths quick to find, for the attacker and for you.

How do you detect a Kerberoasting attack?

Detection centers on Kerberos service ticket requests, logged as event 4769 on Domain Controllers. On their own these events are pure noise. The signal is in the shape. Watch for one user account requesting tickets for a large number of distinct SPNs in a tight window, and especially for requests that specify RC4 (ticket encryption type 0x17) in an environment that should be running AES. Modern clients negotiate AES by default, so a burst of RC4 requests is a classic Kerberoasting fingerprint.

The highest-signal control we recommend is a honeypot SPN. Stand up a decoy user account, attach an SPN that maps to no real service, give it a long random password, and never touch it. No legitimate process should ever request its ticket, so a single 4769 naming that account is a near-certain intrusion indicator with almost no false positives. Pair it with alerting on abnormal RC4 volume and you catch most opportunistic roasting before the cracking even finishes.

How do you prevent Kerberoasting?

Prevention comes down to killing the two ingredients: weak passwords and needless exposure. In priority order, this is what we tell clients to do.

• Move to gMSAs. Group Managed Service Accounts get long random passwords that the domain rotates on its own, so their tickets are effectively uncrackable. Migrate every service account that can support one.
• Use long random passwords where gMSAs will not fit. For accounts that must stay standard user objects, set a 25-plus character random password. At that length even an RC4 ticket is not worth cracking.
• Enforce AES and phase out RC4. Set msDS-SupportedEncryptionTypes to AES only and retire RC4 domain-wide. It slows any crack attempt and turns every remaining RC4 request into a clean detection signal.
• Apply least privilege. Pull service accounts out of Domain Admins and other Tier 0 groups, grant only the rights the service genuinely needs, and audit local admin membership.
• Prune stale SPNs. Every SPN on a user account is attack surface. Strip SPNs off accounts that no longer run that service.
• Adopt admin tiering. Isolate Tier 0 identities so a cracked application service account can never reach domain controllers or domain admin credentials in the first place.

How CyberXplore helps

Kerberoasting is one of the first things our team reaches for on any internal engagement, because it is fast, quiet, and so often works. Our Active Directory security assessment maps your real attack paths the way an intruder would: enumerating SPNs, testing service account password strength, and tracing every chain that ends at Domain Admin, then handing you a prioritized fix list built around gMSAs, AES enforcement, and tiering. If you want to know whether one phished user could own your whole domain, get a quote and we will show you exactly how far it goes.

FAQ

Does a Kerberoasting attack need admin privileges?

No, and that is why it is everywhere. Any authenticated domain account, including a low-privilege user or a compromised service, can enumerate SPNs and request service tickets. The KDC does not check authorization before issuing the ticket, so no special rights are needed to walk away with crackable material.

Does switching to AES stop Kerberoasting completely?

No, but it helps a lot. AES tickets are far slower to crack than RC4, so a strong password behind AES is effectively safe. That said, a weak password behind AES can still fall, so AES is not a replacement for long random passwords or gMSAs. Enforcing it also converts any leftover RC4 request into a useful detection signal.

How long does it take to crack a Kerberoast hash?

It depends entirely on password strength and encryption type. A weak RC4 ticket built on a dictionary word can fall in seconds to minutes on a modern GPU. A genuinely random 25-character password, or a gMSA password, will not crack in any practical timeframe. There is no server-side lockout to slow the attacker down, so entropy is the only defense that counts.

What is the difference between Kerberoasting and AS-REP roasting?

Both crack Kerberos material offline, but they hit different things. Kerberoasting (T1558.003) attacks service accounts with SPNs by cracking service tickets. AS-REP roasting (T1558.004) targets accounts that have Kerberos pre-authentication disabled and cracks the AS-REP instead. AS-REP roasting can be done without any valid credentials at all, as long as you know a target username.

Are gMSAs really immune to Kerberoasting?

For practical purposes, yes. A gMSA password is a long random value that the domain rotates automatically, so even though its ticket can be requested and captured, cracking it is infeasible. The one caveat: anyone granted the right to read the gMSA’s managed password can retrieve it directly, so guard that permission carefully.

How can I test whether my domain is vulnerable?

Run a controlled enumeration of accounts with SPNs and assess their password strength, ideally as part of a full Active Directory assessment. Impacket’s GetUserSPNs or Rubeus will surface every roastable account, and honeypot SPNs plus event 4769 monitoring will tell you whether attempts are already underway. Doing this as an authorized exercise gives you the same view an attacker gets, before they take it.