Kerberos Attacks: Understanding Kerberoasting Conceptually

Kerberos is the protocol that lets you sign in once in the morning and then open file servers, printers and applications all day without typing your password again. It is elegant, and because it is everywhere, it is also studied carefully by attackers. In this lesson you will understand how it works, why a technique called Kerberoasting exists, and how defenders neutralize it, without any attack recipe.

The ticket office analogy

Imagine a theme park. At the main gate you show your identity once and receive a wristband. Then, at each attraction, you do not show your identity again: you show the wristband and, for specific rides, you get a ride ticket from a booth. Kerberos works in a similar way, with three actors:

• You (the client).
• The Key Distribution Center (KDC), a service that runs on the domain controller and acts as gate and ticket booth.
• The service you want to use, such as a file server.

The three steps, simplified

1. Authentication: you prove who you are to the KDC, using a secret derived from your password. In return you receive a Ticket-Granting Ticket (TGT), your wristband.
2. Service ticket request: when you want to reach a service, you present your TGT and ask for a service ticket for that service.
3. Service access: you give the service ticket to the service, which can read it because it is encrypted with a secret that only the KDC and that service share.

The service is identified by a Service Principal Name (SPN), a label that links a service to the account that runs it. Services run under accounts, and these accounts have passwords just like people do.

The design detail that matters

Step 2 has a feature that surprises many beginners: the KDC will give a service ticket for a service to any authenticated user who asks. It is not the KDC's job to decide whether you are allowed to use that service; the service itself decides after receiving the ticket. This is a reasonable design choice, because the ticket is useless without being accepted by the service.

However, part of that service ticket is encrypted with a key derived from the password of the service account. So anyone who can ask for the ticket obtains a piece of data that depends on that password.

Kerberoasting, explained conceptually

Put the pieces together:

1. An ordinary, authenticated user can see which accounts have SPNs (this is directory data, as lesson 1.2 showed).
2. The same user can request service tickets for those accounts, which is normal Kerberos behavior.
3. Part of the ticket depends on the service account's password. Someone can try to guess passwords offline, on their own computer, and check whether a guess produces the same encrypted result. Offline means that no alarms ring on the domain controller during the guessing.

That is Kerberoasting. Notice what it is not: it is not a flaw in the cryptography, and it does not break Kerberos. It exploits a weak human choice, namely a service account whose password is short, predictable or old. If the password is long and random, guessing is hopeless in practice.

Why service accounts are the usual weak link

• Their passwords are chosen once by an administrator and rarely changed, because changing them might break an application.
• They often have high privileges "to make it work".
• Nobody owns them: the person who created the account left the company years ago.
• They are excluded from multi-factor authentication because they are not people.

This combination makes a service account with an SPN, a weak password and broad rights a classic high-impact finding in internal audits.

A close cousin: accounts without pre-authentication

Normally the first Kerberos step requires the user to prove knowledge of the password before the KDC returns anything (this is called pre-authentication). If an account has been configured without it, the KDC will hand over data that depends on the password to anyone who asks, and the same offline guessing logic applies. You should simply know the name of this misconfiguration, "AS-REP roasting", and the fix: do not disable pre-authentication unless there is a documented, rare reason.

Defensive measures that actually work

• Long, random passwords for every account that has an SPN. Many organizations aim for very long, machine-generated secrets.
• Managed service accounts: AD can generate and rotate passwords automatically for supported services (group managed service accounts). Nobody ever knows the password, and rotation is automatic.
• Modern encryption types: prefer the stronger AES-based types over legacy RC4 where applications allow it.
• Least privilege: a service account should have only the rights its service needs, never membership of the most powerful groups.
• Inventory and ownership: know every SPN, who owns it and why it exists. Remove what is unused.
• Detection: monitor service ticket requests. A single user requesting tickets for many different services in a short period, or requests using legacy encryption, is unusual and deserves attention. The corresponding Windows security events are collected by the SIEM that you will meet in chapter 4.

How this appears in a report

When you find a service account with an SPN and a weak password in a real, authorized audit, your finding is not "I cracked something". It is: "Account X is associated with service Y, holds privileges Z, and uses a password that can be guessed offline. Impact: compromise of Y and possibly of what Z gives access to. Recommendation: replace by a managed service account, or set a long random password, restrict rights, and monitor ticket requests." That is a professional finding.

Your turn: rate the service accounts

Here are four fictional service accounts. For each one, say whether it is a high, medium or low Kerberoasting risk and explain why.

Account	Has an SPN	Password	Rights
svc-print	Yes	Set in an old year, a short word with a number	Local rights on one print server
svc-sql	Yes	Set long ago, rarely changed	Member of a powerful administrative group
gmsa-web	Yes	Managed and rotated automatically	Limited to its web application
svc-report	No	Short and old	Read access to one database

See a solution

• svc-sql: high. SPN, old password and powerful rights give maximum impact. Priority one: managed account or long random password, and remove the group membership.
• svc-print: medium. The password is weak and the SPN makes it exposed, but the rights are limited. Still, a foothold on a server is useful for an attacker. Fix the password and review the account.
• gmsa-web: low. Password managed automatically and rights limited. This is the target design.
• svc-report: low for this technique. Without an SPN, no service ticket is tied to it. It still has a poor password, which is a separate hygiene issue for other kinds of attack.

Portfolio step

Add a page kerberoasting-explained.md to your 01-active-directory folder. Explain Kerberoasting in about 300 words for a non-technical manager, using your own analogy. Being able to explain risk simply is a core skill for the report writing you will practice in chapter 6.

In the final lesson of this chapter, you will turn the attacker's view upside down and harden the directory.