I wrote this article because I personally couldn’t find anyone on the internet explaining Kerberos detailed enough separately or while teaching Kerberoasting, most of them just ran tools. And if they did, they didn’t dive deep enough.

What can you expect from this article?

This article breaks down the working of Kerberos to its tiniest bits in a beginner friendly way.

Later in the article, I discuss how an attacker under very specific condition can exploit Kerberos Ticketing system using a technique called Kerberoasting.

The article doesn’t include lab build used for Kerberoasting. It includes a basic network structure and environment brief, required to understand the concept. If you guys would want me to make detailed lab guide separately, then let me know on linkedin or here.

Prerequisites

I assume no knowledge of Active Directory from readers as I explain each topics on the go or keep the technical terms to minimal ( while also explaining those ) but having a bit of familiarity with AD would be helpful.

Special Credit

The diagrams below showing Kerberos authentication flow is taken from TryHackMe. It is the best possible diagram that I could find to match the level of breakdown I’ve done on Kerberos in this article. I do not own these images and give full credit to them.

Okay, now let’s get on with it!

So first of all, What is Kerberos?

Kerberos word is derived from Greek mythology where the name is referred to a 3-headed dog that guards the gate of underworld ( no dead leaves through this gate or no living enters through it ). In the mythology, it gatekeeps the underworld. And that’s the same thing the Kerberos protocol does here, it gatekeeps the Active Directory domain network. Let’s see what Kerberos is technically.

It is the default authentication protocol used in a MS Windows Active Directory environment that enables the user authenticated once to access different services without needing to authenticate again for service access ( Single Sign On ).

It works by giving users tickets which they can present to the resource ( service ) that they want to access proving that they already have been authentication. Think of tickets as "now authorized to use or access".

In AD environment, the entity that handles authentication and ticket generation is called Key Distribution Center ( KDC ). Kerberos uses a central authority and that’s Key Distribution Center (KDC). KDC comes inbuilt in the Domain Controller.

But wait, what’s Domain Controller?

Well, it is about time I introduced you to a few important Active Directory components necessary to grasp Kerberoasting. So before I tell you what Domain Controller is, you’ll need to understand the Active Directory a bit.

So what’s Active Directory?

Active Directory (AD) is a directory service by Microsoft that manages and authenticates users, computers, and resources in a Windows domain network ( you’ll understand what a domain network is when I explain what the domain is and show how a domain is created later ).

It uses LDAP ( Lightweight Directory Access Protocol ) for directory access and Kerberos for authentication.

The core service is Active Directory Domain Services (AD DS), running on Domain Controllers (DCs). Don’t know what an AD DS or a DC is? Let’s find that out below.

This AD section is bit of a detour from the topic of the article, Kerberos. Those who want to skip it can continue reading from “Why does Kerberos use Tickets?”

---

Important Active Directory Components

This section is optional to those who’re familiar with Active Directory Concepts.

If I started talking about Active Directory in detail then this article would turn pretty lengthy so I’m only explaining the few required components of AD which will make Kerberoasting easier to understand.

Before I explain, let’s see how a Windows Server after installation is setup to use Active Directory. This will make things pretty easy to understand.

So assuming that I’ve downloaded Windows Server 2022 ISO image file and have installed it on Virtual Machine, and then have booted it up

The first screen that you see after server boot is:

Now we need to setup a few things. You don’t need to understand these things while you setup or read the setup. Just read how it’s done for now. The terms in the setup section that you don’t understand like forests, AD DS, Domain Controller etc will be explained later ( My aim here to introduce you to those terms only and how they come in play when setting the AD up ) so don’t worry about it, for now.

I’ve renamed my PC ( server ) VM to HYDRA-DC and rebooted it.

At the time the local server is at its default, it has nothing configured and hence is not serving anything in the network.

Setting Up core service of AD : AD DS ( Active Directory Domain Services )

The following series of screenshot shows the steps to install AD DS on the server:

HYDRA-DC is the only server PC ( virtual machine ).

next to the confirmation page

after a bit, you’ll be led to results page. The installation of AD DS is done.

Now to configure Domain Controller, let’s start with the results page.

Setting up Domain Controller ( Promoting the server to Domain Controller )

Now as soon as the core service of Active Directory, AD DS is installed. We’ll be given option to configure the domain controller too. The flow makes sense right?

Now the next few screenshots will show the steps to create a domain controller and a domain too:

Click on “Promote this server to a domain controller”

Doing so will open the following up:

Now we can’t choose first two options as we don’t have an existing domain or an existing forest either so choose the “Add a new forest”. I’ll explain what a forest is, in a bit.

So we’re going to create a new forest and it’s gonna have just one domain in it, named as MARVEL.local (and that is the first domain in the forest hence will be called the Root domain)

next, fill the password.

Now next, skip to the Prerequisites Check:

click install. After installation it will reboot and now we can login to the new as domain admin.

As the domain we created was MARVEL.local, the admin account for that would be MARVEL\Administrator

So now we’ve seen how Domains, AD DS, and Domain Controller are setup.

Let’s now try to understand briefly what are these.

Domain

Simply put, it’s a logical grouping of objects ( machines, users etc ) that share the same database. So it works like a boundary, any object inside this boundary ( domain ) has access to the resources within this boundary ( domain ).

Example name of a domain would be: redteamers.local, a domain can have child domains too like blog.redteamers.local and test.redteamers.local. And this structure of parent and child domains forms what is called a tree

Tree

Tree is a special hierarchical structure formed based on Parent and Child domain that looks like the following:

In trees, parent and child domain both trust each other, this trust is 2 way ( called 2 way transitive trust ).

Forest

In lab setup section, we came across something called Forest.

If I try to explain it in the simplest words, a forest is a group of domain trees linked together by trust relationships, where each domain tree has its own hierarchy.

AD DS ( Active Directory Domain Service )

The core service of AD that enables a server’s directory system and managed by AD DS itself. What’s a directory in AD’s Context? Think of Directory like a database that keeps records of everything ( literally everything ) in the network. For example, AD DS will manage directory for users, computers, domains, trusts between those domains, permissions, groups etc.

The directory is stored on Domain Controller, only managed by AD DS. so What’s a Domain Controller?

Domain Controller

Every Domain in a tree or a forest has at least one Domain Controller. Yes there can be multiple DC to manage single domain.

DC has few important roles which includes:

• Storing the directory ( AD DS managed directory ), mentioned priviously.

• Providing authentication and authorization services

• replicate/reflect the updates in the domain and the forest that the domain is part of.

So that’s it.

---

At this point I want to show you a comparison between a few components, which will further clarify the concepts:

These three are correlated, but the prime part of it all is DC. All these three are at the same machine.

---

That’s most of what we needed to understand for things up ahead.

We’ve deviated quite a bit, so let’s get back at Kerberos. You now know what Kerberos is but there’s a question that needs answered before we proceed further.

Why does Kerberos use tickets?

Tickets help prevent passing credential over the network hence making the authentication more secure ( not entirely secure though ).

This ticket system helps verify a user's identity and allows services ( that the user wants to access ) to trust users without repeatedly asking for passwords.

In the Kerberos flow discussed up ahead, you’ll see that credentials ( hash ) are never passed over the network while authenticate, instead a signed ( encrypted ) tickets are passed.

Assume a network of multiple workstations ( each with users aka clients ) and a central server ( which has KDC inbuilt ) in a windows environment network. One of the client starts authentication process and it goes something like:

Kerberos working flow

Below comes the entire Kerberos authentication flow, I recommend that you read and refer the corresponding image simultaneously to properly grasp the concept. Be warned, it gets lengthy. But I’ve got you.

1️⃣ User Requests TGT ( Ticket Granting Ticket ):

In this, user(client) sends its username and a timestamp (encrypted with the key derived from user's password) to the KDC, requesting a TGT ( Ticket Granting Ticket ), a type of ticket that, when presented to the next authorized entity ( KDC again ), will grant another type of ticket ( in simpler words, a ticket that grants another type of ticket ).

NOTE: timestamps are used in kerberos because the tickets generated in this are set to expire after a certain period, it helps prevent other attacks ( like replay attacks ).

2️⃣ KDC’s Response to user’s TGT request

KDC receives the TGT request and after user validation it sends back the requested TGT along with a session key together encrypted with krbtgt hash ( hash derived from krbtgt account - kerberos TGT account, an inbuilt account in KDC responsible for assigning tickets ) and a session key encrypted using user's hash key.

Clearing something that might be confusing for some readers:

A thing here that needs to be made clear is that the same session key is sent together with TGT ( encrypted using krbtgt hash ) and another one separately by encrypting it with user's hash.

This is done because TGT can’t be decrypted by user and hence the session key ( and TGT ) won’t be accessible to the user but if the same session key is sent separately by encrypting it with a key that user has ( user’s hash ), it will be able to decrypt the encrypted session key and use it in the next steps of the Kerberos authentication.

I’ve highlighted the same session keys in the response below ( yellow keys are same session keys ):

Look at the entire diagram below to understand it better.

NOTE - here TGT can't be decrypted by the user requesting it as it doesn't have the key ( krbtgt hash ). krbtgt account, is only at KDC which is the part of Domain Controller.

1st and 2nd request/response together looks like:

( image credit - tryhackme )

3️⃣ Reqeusting TGS

User first decrypts the session key received in the previous response using it's own hash, then it sends a request including username and timestamp ( together encrypted using the decrypted session key ), the TGT ( that it received in the previous response ) and the SPN ( Service Principle Name includes service details that it wants to access, here it's MSSQL server and the server that hosts it )

4️⃣ KDC’s Response to user’s request for TGS

KDC receives the request and verifies the encrypted TGT first by decrypting it with krbtgt hash.

Once that's done, it will generate another ticket, TGS ( Ticket Granting Service, a ticket that grants access to service ) and encrypts it using service owner hash ( In MS Active Directory environment, a service also has an associated account called as service account. So what's being referred to as service owner hash here is same as service account user's hash ).

There’s another key generated here called Svc Session Key. The encrypted TGS also contains this Svc Session Key ( service Session key ) in it.

The same Svc Session Key is separately encrypted using the session key ( the key to which user has so it can decrypt it and use it in the next step ).

The blue key in the diagram ( Svc Session key ) below follows the similar type of process as the session key ( yellow key ) in the 2nd step above ( refer to the response in the previous diagram and compare the yellow keys from it to the blue keys in this step, you’ll understand it ).

User after receiving the response first decrypts the encrypted Svc Session Key using the Session Key ( yellow key ). It uses yellow to decrypt and get the blue key. Then the following happens.

5️⃣ Authentication to the Service

User when wanting to access the service will now send it’s username and timestamp encrypted together with the decrypted Svc Session Key, blue key ( received in previous step ).

And with that it will take the TGS received in the previous step and forward it to the Service Server ( SRV ) just as it received it ( remember the user doesn’t need to decrypt TGS, it just needs to forward it to the Service Server ).

Ther Service Server will now first use Service account user’s hash ( Service Owner hash ) and will try to decrypt the TGS. If it’s a valid TGS, it will successfully be decrypted.

Decryption will provide the Service Server; the TGS itself and the blue key ( the Svc Session Key ).

The Svc Session Key will then be used to decrypt the username and timestamp. This will help Service identify the user who is supposed to be given access to it’s service and for what period of time is this ticket ( TGS or service ticket ) valid.

After this period the service access to the user will be terminated mostly ( Access isn't forcefully cut off, but future requests with expired tickets are denied ).

And that is the entire working of Kerberos authentication. A pretty good protocol, involving quite a few keys and tickets just to authenticate a single user. That sounds like a protocol almost entirely secure, yes you’re right, almost it is. Almost!

So, the entire Kerberos authentication flow looks something like following when summed up in one image:

Kerberos Flow Summary

I hope you understand how Kerberos works now.

Now we’ll look at how Kerberos can be exploited by attacker using Kerberoasting, which comparatively is easy to understand if you’ve read the Kerberos section and understood the flow well.

Kerberoasting - bypassing 3-headed GateKeeper

---

Now that you have a full understanding of Kerberos, let’s see how to do Kerberoasting.

What’s the purpose of Kerberoasting?

Remember the typical flow of Kerberos? Well, in that flow, an attacker just needs to get to the 4th step i.e., getting a TGS is the goal attacker intends to achieve while attacking Kerberos.

Why, how’s that going to be helpful?

The attacker aim is to get the TGS because TGS is encrypted using Service account hash ( Service Owner hash ). After receiving TGS the attacker’s intends to decrypt the server’s account hash ( service account hash, same thing ). So in conclusion, compromising Service Account is Attacker’s final target.

Why would the attacker want to decrypt or compromise service account hash? What’s so special about it?

There’s a few reason why would the attacker want to compromise Service Account, but the main reason is that most service accounts are not configured/created keeping least privilege in mind and they often are added in the Domain Admin group ( giving the service running and the associated service account, admin level privileges ).

The Domain Admins don’t want to handle this assigning precise permissions to the service account as and when needed, and so, to avoid that, they simply put the Service account in the Domain Admin group.

Specific Condition Kerberoasting requires

If you have read everything so far then it should be obvious what attacker needs for Kerberoasting to be a successful attack.

Assuming that the attacker is in the target network of multiple workstations ( PC ) and a D.C. ( Server ) with a single domain in a forest

1. It is first required that the attacker has already compromised any standard user from the Active Directory environment ( typically, from any of the workstations ). It doesn’t matter what privileges the compromised account holds, it just needs to be a valid user account from the target Active Directory environment. In the hands-On section above, fcastle is the compromised user of the MARVEL.local domain.

2. Service accounts needs to be the members of Domain Admin group. More than often it is going to be the case that it will have the Domain Admin privileges,

   • but it needs to be mentioned this separately that it is possible that the domain admin has followed least privilege and has assigned very precise permissions to the Service account instead of adding it straight to the Domain Admin Group.

That’s mostly it.

Hands On - How to do Kerberoasting as an attacker ( Pentester )

---

There are a few tools out there that can be used to do Kerberoasting but I personally have experience with using Impacket’s GetUserSPNs.py ( I’ve included the links, you may go ahead and clone the repo and install it locally on your Kali VM, if you’re following along ).

Lab Scenario

Consider a network of multiple workstations and a Domain Controller ( named HYDRA-DC ) joined to a single domain ( named MARVEL.local ). I, attacker, have compromised one of the accounts in the domain through a workstation with the fcastle and now have its credentials and its access.

Network that I as an attacker, am a part of: 192.168.57.0/24

fcastle is the user that we’ve compromised ( the required compromised standard user for the attack to be successful, as mentioned previously in the Kerberoasting’s requirement )

I’ve found Domain Controller’s ( hosting KDC ) IP in the network, 192.168.57.250 ( using enumeration ).

Getting the TGS ticket:

In a kali linux terminal that has Impacket installed and GetUserSPNs.py available, run the following:

sudo GetUserSPNs.py MARVEL.local/fcastle:password@1 -dc-ip 192.168.57.250 -request

Breakdown

• GetUserSPNs.py is the tool name from Impacket we’re using.

• Then we’re providing the compromised account details. MARVEL.local is the domain name fcastle is the user with password “password@1”.

• Then we provide Domain Controller IP ( -dc-ip ) which is where KDC is located. Our request for TGS following TGT will be made to this DC’s KDC using fcastle’s credential ( a valid user of MARVEL domain )

GetUserSPNs’s Output

Output Breakdown

• The output shows Service Principle Name ( service details ) like it’s name, what groups is it a member of etc

We can see in the SPN above that the service is a SQL Service.

• IMPORTANT FOR US: this portion of output is what we needed. The next long portion in the screenshot that looks like a long hash of something is TGS.

Do you notice tgs in the initial part of the ticket?

Also, keep the following highlighted part “23” after “$krb5tgs$” from TGS in my mind, it will soon be used to explain a thing in the next section

• Anyways, now that we have the TGS, let’s grab it and store it in a file.

Brute Forcing the TGS ticket using hashcat

We have the TGS, what now?

• Attacker’s next step is to brute force TGS with a good password wordlist, converting every password to hash one by one, and trying every hash on TGS and see if it’s able to decrypt a part of TGS.

• If it’s able to decrypt part of TGS, that means we’ve found the valid password for Service account ( because that’s what was used to encrypt TGS ).

• This process is handled by hashcat. We just have to run the command with the right mode ( modes in hashcat means the type of protocol hash we’re targeting, based on that the hashcat will run those passwords from wordlist through the same protocol hash function so that it computes the right hash ).

Hashcat will take TGS ( krbt.txt ) and wordlist as inputs.

It will take password from wordlist, look at the mode selected and run the password through the corresponding hash algorithm to get a password hash, try that password hash on TGS. That’s the flow it will follow.

cracking the TGS ticket hash

First let’s find out what mode we need to select for the TGS we’ve obtained.

Assuming that you have hashcat installed. Run the following in the terminal

sudo hashcat --help | grep Kerberos

There’s 3 different modes available for TGS-REP, which one should we choose?

Let’s look the column with etype.

etype ( encryption type )

So look at the initial portion of the TGS

• You see the number “23” after $krb5tgs, that number tells us what algorithm is used by KDC to generate these tickets. That number is what’s called etype.

There are three numbers “etypes” ( encryption types ) that you’ll see there typically. I’ve mentioned those numbers and their corresponding encryption algorithm with corresponding hashcat mode number below

• 23 = RC4 → 13100 Mode

• 17 = AES128 → 19600 Mode

• 18 = AES256 → 19700 Mode

So we’ll choose the mode 13100 as it’s the one with etype 23 ( that matches our TGS )

hashcat -m 13100 krbt.txt /usr/share/wordlists/rockyou.txt

We’ve run the hashcat using the mode 13100 on krbt.txt ( TGS ) and have provided rockyou.txt as wordlist.

Output

so we got service account ( which is a domain admin as it is a member of domain admin group ) cred “MYpassword123#”.

Why does Kerberoasting in real-world matter?

Kerberoasting is dangerous because it allows attackers to extract service account hashes without sending suspicious traffic across the network. As cracking is done offline, detection becomes harder.

Once cracked, the attacker gains direct access to a domain account, often with elevated privileges, which may lead to the way for lateral movement or even full domain compromise.

And that’s it. Let’s briefly talk Mitigation also ( just for FYI ).

Mitigation

It’s obvious actually

• Don’t use weak password, if Service account password wasn’t weak its hash wouldn’t have been so easily cracked.

• Don’t put Service Account in Domain Admin group. Even if somehow attacker compromises the Service account, it would be useless with standard privileges.

And that’s where it all ends. Hope you grasped it all, if not, this article is not going anywhere. You can give it another go.

I also hope that you enjoyed reading this because I’ve invested quite a bit of time writing this.

If you want to give me feedback on the article, you can write me on linkedin.

---

I’ll be seeing you in the next one.