Kerberoasting in plain English
In many companies, Microsoft’s Active Directory – the central user management system – controls who may sign in to which computer and which service. For sign-ins, it uses a protocol called Kerberos. It works much like a ticket counter: anyone who wants to use a service – a database or a business application, for example – picks up a digital ticket there.
Besides accounts for people, there are service accounts. Programs run under them in the background – a database server, for example. The ticket for such a service is locked with a key that is derived from the service account’s password.
Imagine a suitcase with a combination lock that anyone in the company is allowed to pick up at the counter. An attacker takes the suitcase home and tries out combinations there at their leisure. Nobody notices, because they never rattle a real door. If the combination – in other words, the password – is short or easy to guess, the suitcase is open in no time.
How Kerberoasting works
- Initial access: The attacker gains access to any user account on the network – for example, through a phishing email.
- Finding service accounts: They query Active Directory for accounts that have a service principal name (SPN). This identifier links a service to its service account.
- Requesting tickets: They request Kerberos tickets for these services. This is a normal operation that any user account is allowed to perform.
- Cracking offline: They transfer the tickets to their own computer. There, programs try out huge numbers of possible passwords – a brute-force attack that doesn’t generate any failed sign-ins on the network. This is especially fast if the tickets are still protected with the outdated RC4 encryption.
- Exploiting privileges: With the cracked password, they sign in as the service account. Because such accounts often have far-reaching privileges, this brings them a big step closer to the domain administrator – the account with full access to the entire network.
A practical example
Here’s a typical scenario: A wholesaler has been running an inventory management system with its own database for many years. The associated service account was created during the rollout, given a memorable password, and – so that “everything works” – added to the Domain Admins group. An attacker uses phishing to steal the credentials of a sales employee. With her account, the attacker requests a ticket for the database and cracks the password overnight on their own computer. By the next morning, they control the entire network. The security systems don’t raise an alarm, because every single step looks like normal operations.
Why does this matter for businesses?
Kerberoasting is attractive to attackers because it takes little effort and leaves hardly any traces. It doesn’t exploit programming errors but a regular feature of Kerberos. What makes it dangerous are typical legacy issues: service accounts with weak passwords that nobody has changed in years – and with more privileges than necessary.
If the attack succeeds, the path to domain administrator is often wide open – and with it, access to all computers, data, and user accounts. Extortionists use exactly this kind of control to deploy ransomware across the entire company. MITRE ATT&CK, the public knowledge base that documents the methods of real-world attackers, explicitly lists Kerberoasting as an attack technique.
How to protect your organization
- Long, random passwords: Give service accounts very long, randomly generated passwords – common recommendations call for 25 characters or more. This makes cracking practically hopeless.
- Use managed service accounts: Group managed service accounts (gMSA) automatically receive very long passwords that Windows changes regularly on its own.
- Disable RC4: Wherever possible, allow only modern AES encryption for Kerberos. This slows attackers down considerably but is no substitute for a strong password.
- Limit privileges: Service accounts don’t belong in the Domain Admins group. Grant only the privileges the service actually needs.
- Clean up legacy accounts: Regularly check which accounts have an SPN, and remove entries and accounts that are no longer needed.
- Detect anomalies: Monitor for unusually high numbers of ticket requests and for requests using RC4. A decoy account with an SPN that nobody uses in day-to-day operations exposes attackers.
How Rootsektor can help
In our Active Directory security assessment, we examine all accounts with an SPN, their encryption types, and their permissions, and show whether Kerberoasting opens up a path to your most critical systems. The assessment can be carried out either on-site or remotely, as you prefer. We report critical vulnerabilities immediately – while the assessment is still underway, by phone or email to the agreed contact person. You’ll receive a fixed-price quote after scoping via our Pentest Quote page.