What is Kerberoasting? The Active Directory attack explained

Short answer: Kerberoasting abuses a normal Kerberos feature — any authenticated domain user can request a service ticket for any service account, and part of that ticket is encrypted with the account's password hash. The attacker requests tickets, takes them offline, and cracks the weak ones. No exploit, no privilege required, and it still works in most domains.

Of all the techniques in an internal engagement, this is the one that most often turns a normal user account into domain administrator, and it is not a vulnerability in the ordinary sense. Nothing is broken. Kerberos is doing exactly what it was designed to do in 1993, and the design assumed service account passwords would be strong.

The mechanism, in five steps

1. A service principal name (SPN) links a service — a SQL Server instance, a web application, a backup agent — to the domain account that runs it.
2. When a user wants to reach that service, they ask the domain controller for a service ticket.
3. The domain controller issues it, and encrypts part of the ticket with the password hash of the account owning the SPN, so that the service can verify it.
4. The domain controller does not check whether the requester has any business talking to that service. That check happens later, at the service itself.
5. So any authenticated user can collect tickets for every SPN in the domain, take them away, and attempt to crack them offline at whatever speed their hardware allows.

The last two steps are the whole attack. There is no exploit and no elevation: a standard user account, one query, and a file of hashes.

Why it works so well in practice

Service accounts are the weakest passwords in most organisations, for structural reasons rather than negligence:

• They were created years ago, often by a vendor's installation guide.
• Nobody knows which application would break if the password changed, so it never changes.
• They are frequently over-privileged, because granting domain administrator was faster than working out the minimum rights.
• Their passwords are often memorable, because a human typed them into an installer at three in the morning.

That combination is why a cracked service account so often turns out to be a member of a privileged group. The attack is cheap; the payoff is disproportionate.

What it looks like from the attacker's side

Enumerate the accounts with an SPN, request tickets, export them, crack offline. Tooling makes it a two-command operation, and BloodHound will happily tell you which of those accounts are worth cracking first because it maps the privileges attached to each one.

The important operational detail is that only step one and two touch the network. The cracking is offline, on the attacker's machine, at no risk of detection and no rate limit. A ten-character password with predictable structure falls in hours; a vendor default falls in seconds.

The chain that follows is the ordinary one: cracked service account, its privileges, then lateral movement, then whatever that account can reach. This is the ground Active Directory Attacks covers in a lab you control — Kerberoasting alongside AS-REP roasting, ACL abuse, delegation and DCSync, which are the other four ways the same domain falls.

AS-REP roasting, the sibling attack

The same idea, different precondition. If an account has Kerberos pre-authentication disabled, anyone can request an authentication response for it — no credentials at all — and part of that response is encrypted with the account's password hash. Same offline cracking, and it does not even require a domain user to start.

Pre-authentication is disabled far less often than SPNs exist, but the accounts that have it are usually old, and old accounts usually have old passwords.

How defenders see it

The relevant event is 4769, a Kerberos service ticket request, logged on the domain controller. It fires constantly during normal operation, which is exactly why raw 4769 alerting is useless.

What distinguishes an attack is the pattern, not the event:

• One account requesting tickets for many distinct SPNs in a short window, especially services it has never touched before.
• Requests specifying RC4 encryption (0x17) in an environment that otherwise negotiates AES. Older tooling asks for RC4 because it cracks faster, and that request is an anomaly worth alerting on.
• Ticket requests for service accounts from a workstation rather than from the servers that normally use them.

Detection engineering of this kind — taking a technique, finding the telemetry, writing a rule that fires without drowning the analyst — is the most valuable exercise a security team can run. It is the core of Infrastructure Defense, which is free with an account here, and the reason a red team operator who understands logs is worth more than one who does not.

The three fixes that actually work

Group Managed Service Accounts. The real answer. Windows generates a 240-character random password and rotates it automatically. The ticket is still crackable in theory and will not be cracked before the sun expands. Migrating legacy accounts is tedious and it is the only fix that removes the problem rather than raising its cost.

Long random passwords where gMSA is impossible. Thirty characters or more, generated, stored in a vault. The attack becomes economically pointless.

Least privilege on service accounts. Kerberoasting a low-privileged account is a nuisance; Kerberoasting one in Domain Admins is a breach. Audit the memberships — the number of service accounts holding domain administrator rights in a typical estate is the finding that makes clients uncomfortable in the debrief.

Two more that help: disable RC4 across the domain so weak encryption cannot be requested, and remove SPNs from accounts that no longer run anything, which is more common than anyone expects.

Practising this legally

Build a small domain in your own lab — a domain controller and two workstations — create a service account with a deliberately weak password, register an SPN, and run the whole chain. Then turn on the logging and watch your own attack appear.

Do not run this against an employer's domain, however curious you are, without written authorisation from someone with the authority to grant it. A single Kerberoasting run against a production domain is unauthorised access, and it is precisely the kind of anomaly a mature SOC catches. If the line is unclear, where to practise legally sets it out.

Frequently asked questions

What is Kerberoasting in simple terms?

Any authenticated domain user can ask the domain controller for a service ticket for any service account, and part of that ticket is encrypted with the account’s password hash. The attacker collects those tickets and cracks the weak ones offline, with no exploit and no special privileges.

What permissions does a Kerberoasting attack need?

A single valid domain user account. That is the reason the technique matters so much: it turns any low-privilege foothold — a phished password, a shared kiosk account — into a path toward accounts that are often far more privileged.

How do you detect Kerberoasting?

Not by alerting on event 4769 alone, which fires constantly. Look for one account requesting tickets for many distinct service principal names in a short window, requests specifying RC4 encryption in an AES environment, and service ticket requests coming from workstations rather than the servers that normally use them. The infrastructure defence course is free with an account.

How do you prevent Kerberoasting?

Group Managed Service Accounts, which use automatically rotated 240-character passwords, are the real fix. Where that is impossible, use generated passwords of thirty characters or more from a vault. Then reduce service account privileges, disable RC4, and remove service principal names from accounts that no longer run anything.

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

Kerberoasting targets accounts that have a service principal name and requires one valid domain user. AS-REP roasting targets accounts with Kerberos pre-authentication disabled and requires no credentials at all. Both end the same way: an offline crack of a hash extracted from a Kerberos message.

Is Kerberoasting still relevant in 2026?

Yes, and it remains one of the most productive techniques on internal engagements. The reason is organisational rather than technical: legacy service accounts with unchanged passwords and excessive privileges exist in most estates, and migrating them to managed accounts is slow work nobody is rewarded for.

Where to go next

Build the lab and run the chain yourself: Active Directory Attacks covers Kerberoasting, AS-REP roasting, ACL abuse and DCSync in a controlled domain, and Windows Fundamentals covers the authentication model underneath it. For the detection side, Infrastructure Defense is free with an account.