I found myself bamboozled at many points throughout the journey of learning about Windows Kerberos Authentication. It's obviously a topic that's been written about ad nauseam, given it's prevalence in enterprise networks. There are tons of articles, some better than others. Visual representations, presentations with useful metaphors, even a mind map. Heck, name your favorite AI chatbot, and I'm sure you'll get plenty of additional ad-hoc writeups. Just be careful of hallucinations!

However, I found there was a need for a more offensively-minded technical mind map. One which gives foundational insight for an offsec specialist to understand what you're actually doing when performing a Kerberoasting attack, or even running a Rubeus command. Not at the level of diving into sysinternals, but more than just scratching the surface. Or to answer the question "Can you explain Kerberos?" in a technical interview. I might plan to cover some of the attacks in a separate post.

The goal of this post is to turn the chaos and alphabet soup of REQs and REPs into a logical flow of inputs and outputs - or at least as logical and continuous as possible. After all, we are talking about a protocol named after a 3 headed mythical creature 😄

We'll cover all these items of the mind map, starting in the upper right hand corner, and going clockwise. Zooming in on each of the components. This counter-clockwise rotation also explains why parts of the graphics below will look flipped. Along the way we'll use an analogy - of international travel - to help reinforce the material. The mind map could even be utilized to build a memory palace. If you do, please share how you're able to build a memory palace in the comments!

What is Kerberos?

Kerberos is a stateless, ticket-based network authentication protocol used in a Microsoft Active Directory Domains. The protocol allows two parties to authenticate over an insecure network channel, provided both parties each trust a third party. It is stateless, as no central authority is tracking ticket validity, but instead transmitting the relevant data and referencing it during the applicable step in the process.

The Analogy - International Travel

Caveat - I wrote this entire blog post, and then discovered this post: https://adsecurity.org/?p=227 - written in 2014. Fully proving there's no such thing as originality when it comes to Kerberos. So credit to Sean Metcalf for the OG analogy. My analogy below is a bit more detailed. But shout out to that article regardless, as it supplements with additional information that's useful to know. So even if you read this article, be sure to check out the AD Security post.

Right off the bat - the analogy is a bit of an imperfect comparison. Keep an open mind and remain a bit flexible, and it should work.

One of the most popular metaphors for the Kerberos tickets is a theme park. I've seen it best explained by Elad Shamir (first ~20 slides), in a DEF CON workshop. Sadly, since it was a workshop, I couldn't find a recording on YouTube. As a millennial who was fortunate enough to go to Disney World in the late 90s/early 2000s and experience FastPass - this is an alternative metaphor resonates with me.

However, in an interest of providing an analogy differentiates itself a bit more than amusement parks, we'll go with international travel. Below is a brief table for the comparison. We cover these terms and their analogies in greater detail as we progress.

The mind map graphics include a small airplane, indicating the Kerberos' travel analogy.

The "Who" in Kerberos - Explaining the "3 Heads" of the Beast

Before we talk about how Kerberos works, it helps to first define the stakeholders involved. Kerberos is named after the Greek mythical creature Cerberus. The primary reasoning being there are three "heads" – or what we'll call "Stakeholders" –involved in the protocol.

Note that each of these stakeholder have a "Long Term Key", "Long Term Secret Key" or even "LT Key". All of these are just highfalutin ways of saying "passwords". Or at least we'll assume as much for the purposes of simplifying this post. This helps for understanding Kerberos Authentication, but also the weak points in the process which are the source of some of the Kerberos attacks.

Client/Principal

The Client or Principal is the user (or service or computer) requesting access to a particular resource. For simplicity's sake, we'll assume a user account. This is the stakeholder which utilizes the various tickets throughout the authentication flow. The client attempts to access resources on the network.

Travel Analogy: You! The Traveler!

This one's easy. The client or principal in Kerberos is the equivalent of YOU, the jet setter. You're hoping to expand your horizons by traveling internationally.

Target Service

The second stakeholder is a the Target Service, or resource that the client is attempting to access. An example target service might be a file share, or web server.

Travel Analogy: Customs/Immigration of Travel Destination

The Target Service in Kerberos is akin to the foreign country you're looking to visit. For the purposes of the analogy, let's just assume (for now) that every country you travel to would require you to submit a visa. Furthermore, you're rolling the dice and visiting the country with all the necessary information with a hard copy of the visa application.

Key Distribution Center (KDC)

The KDC or Key Distribution Center is the final stakeholder, and the "trusted third party" mentioned earlier. The KDC is integrated within the Domain Controller's Active Directory Services. It runs on the Domain Controller as a single process, which provides two services: the Authentication Service (AS) and the Ticket-Granting Service (TGS).

The Authentication Service issues the Ticket Granting Ticket (TGT), while the Ticket-Granting Service issues the Service Ticket (ST). It might be confusing if you assume the service is named after what's provided by the service. Instead, view the Ticket-Granting Service as getting its name from what needs to be provided to the service.

Travel Analogy: "The Governments"

This one is a bit trickier if you look at it from the whole, aka the KDC. Think of the KDC as the Government Entities which support you on your travel.

The Authenticating Service is the State Department - who validates your identity, and provides you with a passport. In order to get a passport, you authenticate yourself with documents (i.e. social security card, birth certificate), in lieu of a password for Kerberos.

The Ticket Granting Service is the Visa Application Office in the foreign country you're visiting. Typically prior to entering a country, you need to apply to a visa. Technically some countries have treaties which don't require visa applications from it's citizen, but we'll assume that doesn't exist in this context. Also, we're going to assume countries don't provide notice of your visa application online, as many countries do nowadays.

Key Terms

After establishing the stakeholders involved in the protocol, it's helpful to discuss a few key terms. There will be plenty more we introduce during the actual authentication flow. However, Kerberos Authentication gets in the weeds very quickly with Windows-specific lingo that it helps to have a base definition. If you're familiar with Windows or Active Directory, you can likely skip this section. The main purpose is to level set on terminology so we have to take as few detours during the authentication flow as possible.

Service Principal Name (SPN)

The Service Principal Name definition from Microsoft is best. A SPN is a unique identifier which maps a service to an underlying domain account. It has a format of serviceclass/host:port. The SPN is needed by the client to request access to a service. For the client, it lets the KDC know which service the client is requesting access. For the KDC, the SPN is used to provide the appropriate service ticket to the client, as well as know the long term key (read: password) by which to encrypt the Service Ticket.

Travel Analogy: Destination Country Name

Think of the SPN as the name of the country you're looking to visit. You'll need the country's name when googling "[Country] Visa Application Website".

Security Identifier (SID)

Again, bravo Microsoft for having another accurate definition (it's not always the case). A Security Identifier is a unique identifier for a security principal. A security principal is any user, computer account, or thread/process which runs in the security context of either. SIDs are used to define permissions, group membership, and authorization boundaries.

Travel Analogy: Countries Allowed List

Think of a SID as your Passport Number. This is the least effective components of the analogy. But let's assume that your Passport Number is used by countries to look up if you're allowed to visit or not.

Realm

The term comes from the original RFC for the Kerberos standard. In Windows, this is an Active Directory Domain. The terminology for Windows implementation of Kerberos keeps with the standard, and uses realm. We don't cover Realm too much in this article, but it's helpful to know as you learn more about Kerberos.

Travel Analogy: Regions/Interplanetary Travel

A realm might equate to regions of similar countries you're looking to visit. Realms define the security domain, and the validity of the tickets issued, much like a country's visa is typically only valid in that country.

If you want to be a bit more out there with a futuristic analogy - imagine you're traveling to a different planet or solar system. The realm would be a different planet. Bit far fetched, but perhaps that hyperbole helps the analogy stick.

Kerberos Tickets

Before we jump into the authentication flow, it might help to discuss the tickets themselves prior to diving into the authentication flow. The idea is to focus on the tangible items obtained through the process,

You might be thinking we're jumping the gun - talking about the goods before even how we go about getting them. However, most of the posts I've seen introduce these items while also discussing the authentication flow. It's a chicken or the egg situation, which most folks prefer discussing the chicken first. However, there's plenty to discuss regarding these items during the authentication flow (i.e. how they're transported securely). Hopefully by introducing the tickets first, it simplifies the process, since we'll know what we're attempting to obtain.

Ticket Granting Ticket (TGT)

The Ticket Granting Ticket enables a client to request Service Tickets. The TGT is provided by the KDC - specifically the Authenticating Service (AS) - to a client. It expires, usually after 10 hours, to limit security risk. There's a start and end date (ticket invalid), and a max renew date (requires reauthentication, typically +7 days from the start date). There's a client/TGS session key, which is a symmetric key to be used for future communications between the client and the TGS Service (KDC). There's a whole bunch of other metadata, such as the client name - username and realm - and flags.

The most important component of the TGT is the the Privilege Attribute Certificate (PAC). The PAC is used by the target service to identify the user, as well as the authorization of the user - in the form of SIDs and group membership SIDs. We'll cover how those components are used later on. For the TGT, the PAC is actually signed twice by the KDC's (krbtgt) long term key - to validate the authenticity of the PAC. These signatures will be replaced later. To prevent the TGT from being tampered with, it is encrypted using the KDC long-term key.

Travel Analogy: TGT = Passport; PAC = Passport Number;

Think of the Ticket Granting Ticket as your passport. Technically passports have a much long lifespan than 10 hours/7 days, but that's a small difference that isn't too relevant.

And in order for the analogy to stick that the TGT is encrypted - think of it as you're too lazy to open up your passport ever, and you just hand it to TSA/Customs in the future closed (jerk move, but alas). The TGT is encrypted using the KDC's LT Key which is akin to something like "The Governments" secrets, aka password.

Within your passport is your passport number and other relevant information which correlates to your access of other countries, which for Kerberos is the PAC. As previously mentioned, you get your passport (TGT) from the State Department (KDC AS).

Service Ticket (ST)

Note: many diagrams display the service ticket as Service Ticket (TGS). This is to denote that the Service Ticket came from the TGS (Ticket Granting Service).

The Service Ticket is provided by the Ticket Granting Service (TGS) of the KDC to the client. It's used by the client to request access to the target service. The ST contains two parts - a client portion and a server portion.

The client portion contains a session key for the client to communicate securely with the Target Service. Additionally, there's a validity time for the Service Ticket - so the client is aware when to request a new ST. These items are encrypted using the client/TGS key provided in the TGT.

The Server portion of the Service Ticket is a tad bit more fruitful. It has that same session key as the client. It also then has the user's PAC, taken from the TGT (more on that in the Authentication Flow section). These contents are encrypted using the Target Service's long term key.

Travel Analogy: Visa Application

Think of the Service Ticket as your visa application for your travel destination. In this scenario, the client portion of the ST is what you can see after submitting your application (i.e. application status). The server portion of the ST could be all the additional important information that the country uses to determine if you should be granted access to the country prior to making a decision on your acceptance/denial.

For the sake of the analogy - we'll assume you're feeling risky, and do not wait for an approval/denial from the visa office before traveling to visit the country.

Authentication Flow

Now that we know what the artifacts of the Kerberos process, and the players in the whole process, lets dive into the process itself.

Authentication Request (AS-REQ)

Assuming pre-authentication is enabled (as is the case with the vast majority of enterprises this day and age) the client sends an AS-REQ to the KDC's Authenticating Service. The authentication request contains the domain, username, SPN value of KRBTGT, and pre-authentication data. The Pre-Authentication data is a timestamp encrypted with the user's password hash.

The KDC AS analyzes the AS-REQ, looks up the password hash from the domain/username provided, and attempts to decrypt the Pre-Authentication data with the hash. If decryption fails, an error returns to the user. If it succeeds, it moves onto the next step...

Travel Analogy: Passport Application

This step in the process is the equivalent of you the traveler applying for a passport. You need to prove who you are, so you provide a few documents (i.e. your password) which proves your identity to the State Department.

Authentication Response (AS -REP)

With successful decryption of the encrypted timestamp, the KDC AS provides an Authentication Response (AS-REP) to the client. The response contains two items - a TGT, as well as a Client/TGS session key and other metadata (i.e. expiration time, user nonce).

The TGT is a ticket for the krbtgt service and can be used to request additional tickets, as mentioned previously. As a reminder, the TGT is encrypted with the KDC's long term key to prevent tampering by a nefarious actor.

The client/TGS session key is encrypted with the user's password hash. It's intended for use between the client and TGS for future communication.

Travel Analogy: Passport Returned

After a successful passport application, you finally get your passport! Get ready to travel the world!

Service Ticket Request (TGS-REQ)

To then gain access to a specific service, the client uses their TGT to submit a Service Ticket Request (TGS-REQ) to the KDC, but this time the Ticket Granting Service (TGS). The core components include an authenticator message (another timestamp) which is encrypted with the client/TGS key and the TGT. The KDC can decrypt the TGT to retrieve the client/TGS session key. After which, it uses the session key to validate the authenticator message and formulate the response.

Travel Analogy: Visa Application - Part 1

The TGS-REQ is the equivalent to you completing a country's visa application. However, don't think modern day where you can track your visa online and know whether your visa is approved in advanced. Instead, you're filling out a paper visa application. More on that in a bit...

Service Ticket Response (TGS-REP)

Assuming a valid TGS-REQ was provided, the KDC (TGS) generates a Service Ticket (ST) to send back to the client.

The service ticket is broken into two parts, a client portion and a server portion. The client portion is encrypted with the Client/TGS session key provided in the AS-REP. It includes a service session key for the client to communicate with the target service. There's other metadata, but we'll skip that for now.

The target service's long term key encrypts the server portion of the ST. It contains the PAC of the client, as well as the service session key (same key in the client portion of the Service Ticket). The KDC will resign the PAC, replacing the Server Signature with the Target Service's LT key, and then the KDC's LT key. Signing the PAC allows the target service to validate its integrity, without requiring communication with the KDC.

An important note, the KDC will return a service ticket to the client regardless if the client is authorized to access that service. The KDC relies upon the the target service to handle authorization to the service with the information provided within the PAC.

Travel Analogy: Visa Application - Part 2

So this portion would be like someone from the destination's visa office taking the application, validating completion of the form properly and returning the application to you. The visa office doesn't bother to validate if you're allowed in the country. To avoid overburdening their staff, they assume someone else (customs/border control) will handle this.

Application Request (AP-REQ)

Armed with the Service Ticket (ST), the client sends an Application Request (AP-REQ) to the target service. The ST is encrypted with the password hash of the target service account. As a reminder, the server portion of the ST includes the client's PAC data, the session key to use for the target service to establish communication with the client. Separately, within the AP-REQ is the username and timestamp encrypted with the session key. After decrypting the username and timestamp to verify the contents, the target service checks the client's PAC to ensure the client's SIDs/GUIDs provided authorize the client to access the target service.

Travel Analogy - Customs/Immigration

The AP-REQ is the equivalent of going through Customs at your travel destination. You're providing your visa application (Service Ticket), hoping that you filled everything out your visa application properly, walking up to the booth, and handing the officer your visa application. You anxiously await their response, hoping you're not waiting in the airport for the next return flight home...

Application Response (AP-REP)

The target service responds to the AP-REQ with the Application Response (AP-REQ). The AP-REQ contains the authentication and authorization result from the provided Service Ticket (ST).

Travel Analogy - Customs/Immigration Decision

The AP-REQ is the equivalent of the customs or immigration officer reviewing the contents of your visa application. Assuming all goes well, you're granted access to the country, able to enjoy your vacation!

Mind Map Complete

With that, we've concluded our Kerberos Authentication mind map! We started with the stakeholders, to first understand who's involved in the protocol. From there, we covered a few key terms. We zigged where most blog posts zag, first covering the Kerberos Ticket types, their contents, and importance in the process. Finally, we discussed the Kerberos authentication flow, making sense of the REPs and REQs. Along the way, trying to use an international travel analogy to help reinforce all the material.

There's plenty more to cover in the world of Kerberos. We've just begun to scratch the surface. This mind map doesn't cover the Kerberos attacks, some of the more complex Kerberos use cases like delegations, or even the full technical process. However, there's plenty to grapple with these foundational components. Familiarizing yourself with these items will help make those additional topics easier to understand.

Resources

I distilled my thoughts thanks to reading lots of resources, which helped explain various components of Kerberos to different extents. Below are those resources. I'd recommend reviewing these in greater detail if you're interested in learning more. While this post was intended to be for a wide audience, it helps to continue to dive deeper.

Kerberos Delegation Attacks by Elad Shamir - Slide deck with the most comprehensive analogy of Kerberos Authentication to a theme park for the first ~20 slides.

How to Secure Kerberos Authentication Protocol - 1 | Forestall Security

How to Secure Kerberos Authentication Protocol - 1 | Forestall Security | Emerging Threats, Advanced Solutions.

Forestall Securityuser

[MS-KILE]: Kerberos Protocol Extensions

Specifies the Microsoft implementation of the Kerberos Protocol Extensions, as specified in [RFC4120], by specifying any

Microsoft Learn