Kerberos — The Three Headed Dog and How to Kill it?

When I’d just started reading about Kerberos, my brain immediately went to that three-headed dog from Greek mythology. You know, the one guarding the gates of the Underworld, keeping the damned in hell. And honestly, the first thing that came to mind was that scene in God of War where Kratos fights a smaller version (Cerberus) of it.

What is Kerberos?

In Windows environments, Kerberos is basically that three-headed dog keeping the unauthenticated hordes out of your domain. It’s the primary authentication method your domain controller relies on.

So why a three-headed dog? Because Kerberos has three critical components: the Client, the Target Service, and the Key Distribution Center (KDC). Pretty straightforward once you see it laid out. Here’s where it gets interesting though. Instead of targeting a specific device, Kerberos targets a service. That’s different from what you might expect, especially if you’re used to thinking about compromising user accounts. The architecture shifts the attack surface.

And the best part? You don’t even have to interact with the service to gain access. You can get authenticated without ever touching it. Kind of mind-bending when you think about it, right?

Kerberos is a stateless protocol, working on tickets. It is more like “a ticket to rule it all”. as this is a stateless protocol, all the state data is stored in the ticket. The Kerberos tickets are encrypted by various password hashes (remember the three components).

Flow

Figure -1: Kerberos Workflow

A Kerberos flow can be divided in three phases,

Phase — 1: a. the client uses its Password hash to encrypt a timestamp and send it to the KDC (DC). This also knows as AS-REQ (Authentication Service Request) b. the KDC decrypts the timestamp and validates it, if validated it then send a TGT (ticket grant ticket) to the client. This is known as the AS-REP (Authentication Service Response). Note: that TGT’s good for 10 hours. After that, you need a fresh one.

Phase — 2: b. with the TGT the client then asks the KDC to share a service ticket (ST) for the target service. This is known as TGS-REQ (Ticket Granting Service Request). c. the KDC again validates the TGT and then allocates a ST to the client. This is known as TGS-REP (Ticket Granting Service Response). This ticket is encrypted with the target service password hash.

Phase — 3: e. the client then sends the ST to the target service, which then decrypts it and validates the signatures and gives access to the service as per the privilege. Here’s where it gets wild: the target service doesn’t actually validate anything back with the KDC. It’s stateless. All the validation info lives inside the ticket itself. The service just trusts what’s in there. Scary, right?

Optional: if you notice the dotted lines, you can see that the service does validates with the KDC, but it happens rarely.

Killing the BEAST

We will look into the common Kerberos Attacks.

1. Kerberoasting

Here’s the thing: the KDC doesn’t keep track of every relationship between every client and every service. If it did, the computational overhead would be massive. Instead, the KDC takes a shortcut. It hands out tickets and lets the service do the verification work. The service checks whether a user should actually have access.

This design choice creates an interesting side effect. Users never need to directly communicate with the service to grab its password hash. Remember, a Service Ticket is encrypted with the service’s password hash. The ticket itself carries all that sensitive material.

So, here’s the vulnerability: if we can get our hands on that Service Ticket, we’ve got something we can attack offline. No need to interact with the service in real time. No need to trigger alarms. Just grab the ticket and start cracking. That’s where Kerberoasting comes in. But how exactly do we exploit this?

The attack itself is pretty straightforward. You query Active Directory for SPNs registered to user accounts, request service tickets for those SPNs, and dump them to a file. Then you let hashcat crack them offline.

Why target user accounts instead of machine accounts? Because user account SPNs are way more crackable. Machine account passwords are randomly generated and rotate every 30 days, which makes them practically impossible to brute-force. User passwords? Those tend to be weaker and stick around longer.

Read further from the creator Tim Medin.

2. Silver Ticket Attack

Now that we’ve got the service’s password from Kerberoasting, we can forge our own Service Ticket and use it to access that service directly.

Here’s why this works: when a service account runs as a system account, the service never validates the ticket with KDC for the KRBTGT signature on the ticket. It only checks the Service Ticket’s signature, the one we just created with the service password we cracked. Since we’ve got that password, our forged ticket looks completely legitimate to the service. And that’s it. We’re in.

The service doesn’t care that the KDC never validated our ticket. It just sees a properly signed Service Ticket and grants access based on whatever permissions are embedded in it.

Once we’ve got the ticket, we load it into memory using Rubeus or Mimikatz. From there, we can use it to access the service whenever we want.

What do we actually need to pull this off?

The service account’s password hash (which we’ve already cracked from Kerberoasting), the full domain name, the domain SID, the target service’s SPN, a user ID, and a group RID. Honestly, that’s not much.

And here’s the fun part: the username in the ticket doesn’t actually have to be a real user. You could put literally anything in there. The service will still accept it as long as the ticket signature’s valid and the permissions check out.

3. Golden Ticket

Remember how we said the TGT contains the KRBTGT password hash, the one that signs everything? If we can crack it, we can forge TGTs ourselves. And here’s the thing: when we send that forged TGT to the KDC, it validates it without question. We look legitimate.

Microsoft patched this in 2023 by adding a check to see if the user actually exists in Active Directory. But if we can bypass that validation, we’re in business. We can modify group memberships, request Service Tickets for any service we want, and escalate all the way to Domain Admin. All we need to do is tweak the PAC (Privilege Attribute Certificate) that contains the user’s group memberships and permissions.

What do we actually need?

The KRBTGT account’s password hash (cracked during our initial attack), the full domain name, the domain SID, a user ID, and a group RID. That’s it. With those pieces, we can forge a TGT that the KDC will accept.

One critical warning: The KRBTGT password needs to rotate every 12 hours. If you use a golden ticket and the KRBTGT hasn’t changed yet, you’re fine. But wait too long, at least 10 hours need to pass before the rotation happens or you risk breaking functionality across the entire domain. This is the nuclear option. Use it carefully.

4. Overpass-the-Hash

If we’ve got a user’s password hash, we can use it to ask the KDC for a TGT directly. Here’s the key part: the KDC will hand us a completely legitimate TGT. We never needed the actual password, just the hash. Once we’ve got that TGT, we can use it to request Service Tickets from the KDC for any service the user can access.

5. Pass the Ticket

This one’s even simpler. If we manage to get our hands on a valid TGT from a user, we can use it to ask the KDC for Service Tickets. The KDC doesn’t know we’re not the original user. It just sees a valid TGT and grants us access to whatever services that user can reach.

Tools you can use

To pull off these attacks, you’ve got a solid toolkit at your disposal: impacket, Rubeus, and Mimikatz. Each one handles different parts of the attack chain, and once you know how to use them, you’re dangerous.

Further Reading

Kerberoasting Revisited — harmj0y Securing Active Directory: Performing an Active Directory Security Review

That’s all, folks. Happy hunting!

~m1kU