Kerberoasting: cracking service account passwords without ever touching the domain controller

REDTEAM OXYDIAN
7 May 2026

During Active Directory audits, Kerberoasting is one of the attacks checked systematically, as the technique is so effective, fast and stealthy. In a few seconds, an ordinary user account without the slightest privilege can retrieve enough material to crack, offline and silently, the passwords of sometimes very powerful accounts. This article explains how it works, why it succeeds so often, and above all how to defend against it.

A little Kerberos and SPN background

In a Windows domain, authentication relies on Kerberos, a protocol based on tickets issued by the domain controller. The principle dates back to the 1980s (MIT’s Project Athena), and Microsoft has used it as the default authentication mechanism since Windows 2000. Every service reachable via Kerberos is identified by an SPN, for Service Principal Name, a label such as MSSQLSvc/serveur.entreprise.local:1433 that links a service (a SQL database, a web server, a share) to a service account in the directory.

As a reminder, a service account is a user account dedicated to running an application. It often carries high privileges and its password is rarely changed, because changing it risks breaking the application that depends on it. It is a secret that ages badly.

Why service accounts are such a magnet

These accounts combine every weakness an attacker looks for. They were created long ago, often when a piece of software was installed, with a password chosen by hand by a busy administrator. That password generally never expires, since expiry would mean an application outage. To top it all, these accounts frequently end up as members of highly privileged groups, sometimes Domain Admins, “just to get the application working”, and nobody ever goes back to undo it. Attackers know this and target these SPNs first.

How the attack works

The key point fits in one sentence: any authenticated user in the domain can request a service ticket (a TGS, for Ticket-Granting Service) for any SPN. This is perfectly normal Kerberos behaviour, not a vulnerability. However, part of this ticket is encrypted with a key derived directly from the service account’s password. Obtaining the ticket therefore means obtaining an encrypted sample that can be attacked at leisure.

The attacker enumerates the SPNs in the directory, requests the corresponding tickets, then extracts them. With GetUserSPNs.py, from the Impacket suite, a single command from Linux is enough:

GetUserSPNs.py entreprise.local/utilisateur:MotDePasse -request -outputfile tickets.txt

On Windows, the Rubeus tool does the same from an already compromised workstation, and can target the most interesting accounts:

Rubeus.exe kerberoast /outfile:tickets.txt

Crucial point: at no time does the attacker need to write to the domain controller or test passwords against it. All the cracking then takes place on the attacker’s own machine, offline. There is therefore no locked account and no visible spike of authentication failures in the logs.

Offline cracking

Once the tickets have been retrieved, the attacker feeds them to a cracking tool such as hashcat. The Kerberos TGS format corresponds to mode 13100:

hashcat -m 13100 tickets.txt dictionnaire.txt -r regles.rule

The -r parameter applies a rule set that reproduces human habits: initial capital, trailing digit, classic substitutions. Against a weak password such as Serveur2021, the result comes within seconds on an ordinary laptop with a graphics card. And that is the whole problem:

service accounts often have short passwords, chosen by a human years ago;
they are almost never renewed;
they accumulate high privileges, sometimes up to full domain administration.

A single weak password cracked, and the attacker directly inherits the account’s rights, with no exploit and no further privilege escalation. It is a spectacular shortcut from “I am an ordinary user” to “I control the directory”.

RC4, the quiet fuel of the attack

A technical detail often makes matters worse: for compatibility reasons, many tickets are still encrypted with the RC4 algorithm, derived from the password’s NTLM hash. RC4 lends itself particularly well to large-scale cracking. Enforcing AES for service accounts makes cracking considerably more expensive. Attack tools know this: Rubeus, for example, readily requests RC4 tickets when they are available, precisely because they are easier to process.

What field experience shows

On a typical engagement, enumeration regularly returns several dozen SPNs. A single one tied to an account with an outdated password is enough to open a breach. Backup, monitoring and database accounts come up frequently, often with high privileges, protected by a password made of the software vendor’s name followed by a year. The business impact is immediate: whoever controls such an account controls authentication for the entire company. The Oxyscan BOX identifies precisely these service accounts exposed to Kerberoasting across an entire directory, so they can be fixed before an attacker finds them.

Fixing the weakness: moving to managed service accounts

Since Kerberoasting exploits not a software flaw but a weak password, the fix consists in making that password impossible to crack. Group managed service accounts (gMSA, for group Managed Service Accounts) meet exactly this need: their password is randomly generated by the domain, spans 240 bytes and is renewed automatically, without any human intervention. An attacker who retrieves a ticket encrypted with such a secret can throw every graphics card available at it and will never recover it.

As a reminder, this is already how computer accounts behave (those whose name ends with a $): their password is random and very long, which makes them immune to Kerberoasting. A gMSA simply extends this principle to the accounts that run application services.

Setting it up takes three PowerShell commands on the domain controller side. First, the Key Distribution Service (KDS) root key is generated, once for the whole domain:

Add-KdsRootKey -EffectiveImmediately

Despite its name, the -EffectiveImmediately option only makes the key usable after it has replicated to all domain controllers, with a safety delay of up to ten hours. This delay must be respected in production. Next, the managed account is created, specifying its DNS name and the host or hosts allowed to retrieve its password:

New-ADServiceAccount -Name sql-service -DNSHostName sql-service.exemple.local -PrincipalsAllowedToRetrieveManagedPassword "GRP-SRV-SQL$"

Then the account is installed on the machine that will run the service:

Install-ADServiceAccount sql-service

All that remains is to set this account as the service identity. In Server Manager, the managed account, recognisable by its $ suffix, is entered as a custom account, here for the identity of an IIS application pool:

Not all software can work with a gMSA yet. For these remaining cases, the rule is twofold: a password of at least twenty-five characters, randomly generated and kept in a vault, and strict adherence to least privilege, since a service account almost never needs to belong to Domain Admins. AES encryption of tickets should also be enforced, as it is far more expensive to crack than legacy RC4, and abnormally high volumes of service ticket requests should be monitored, as they are often the first sign of an ongoing Kerberoasting campaign.

Conclusion

Kerberoasting does not exploit a bug: it exploits a poor password set on an overly powerful account. That is why it ranks among the most profitable techniques for an internal attacker, and among the easiest to overlook on the defensive side. The good news is that the countermeasures are known, documented (notably by MITRE and ANSSI) and effective.

Recommendations: give service accounts very long passwords (25 characters or more) or, better still, migrate to group managed service accounts (gMSA), whose password is renewed automatically by the domain; apply the principle of least privilege (no service account should be a domain administrator without solid justification), enforce AES encryption rather than RC4, and monitor bulk TGS ticket requests, often the first sign of an attack in progress.