Kerberos authentication: A simple (& visual) guide for security pros

What is Kerberos?

Kerberos is the default protocol for authenticating service requests between trusted devices on a network. It’s been used since Windows 2000 and is a critical part of Windows Active Directory (AD) services and environments.

When a user logs into their PC, Kerberos is used to authenticate them via mutual authentication. Both the user and the server verify their identity. Kerberos is a stateless authentication protocol—it is based on tickets instead of transmitting user passwords over the network. 

The Kerberos protocol was born back in the late 1980s. Created by MIT as a “network authentication system” for the Project Athena environment (the Greek mythology is strong here) with the goal of providing a secure authentication method for the MIT network. 

Their goal? Allow secure access to systems over an open network while avoiding the exposure of clear text passwords and sensitive data being sent over the wire.

If someone (or something) were eavesdropping on the network they wouldn’t get a hold of sensitive information. 

Kerberos is currently (at the time of writing) on V5 Release 1.21.2. V5 was first published in 1993, published as a proposed standard in RFC 4120.

Why understanding Kerberos authentication is key for security pros

The name for the Kerberos authentication service was inspired by Cerberus from Greek mythology: a gigantic three-headed dog who guarded the gates of the underworld (aka the “hound of Hades”).  

Another particular trait (and perhaps the most useful) of Cerberus is that “he refused entrance to living humans”. (Not without proper authentication and authorization, of course, always following Hade's strict IAM policies. Even in hell, one must follow the principle of least privilege.)

So, was this three-headed puppy the perfect solution to protect Hade’s underworld “infrastructure?”

It sure appeared so. (In addition to those heads, and again according to mythic lore, “heads of snakes grew from his back, and he had a “serpent’s tail”. Robust security, to say the least.)

In reality, we all know there’s no such thing as a 100% secure system or infrastructure. And that applies even to the underworld. 

The mythic Orpheus, an ancient Greek hero renowned for his enchanting musical skills, managed to get past Cerberus by playing gracious tunes with his lyre that lulled the dog into a deep sleep. (Some ancient myths go even further and tell us that Orpheus was the first hacker to reach the Omniscient rank in Hack The Box.)

In a similar vein, the Kerberos protocol that’s key to most organization’s AD environments today is prone to being bypassed if misconfigured or targeted by malicious actors. This is why understanding Kerberos authentication and Active Directory is a must for all security professionals. 

By now, we all know that understanding Microsoft Active Directory is crucial for every cybersecurity professional. As Swetha Krishnamoorthi and Jarad Carleton phrased it “Active Directory holds the keys to your kingdom, but is it secure?”

Because Kerberos is widely used within an Active Directory environment, it constitutes a substantial part of the attack surface when evaluating internal networks for security vulnerabilities. 

So yes, we have to learn how it works. 

Especially if one is looking to get into penetration testing, or simply to protect AD-based network environments as a defensive security professional.

Related read: Active Directory hardening (pentester vs. SOC)

The three heads of Kerberos authentication: KDC, realms, & tickets

Back to our three-headed puppy Cerebrus. Why do we tell you that the Kerberos protocol also has three heads?

You see, in this whole mythical analogy, the three heads are represented in the Kerberos protocol by these three core components:

1. Principal: The principal is the identity that wishes to authenticate. Using Kerberos Terminology by the MIT themselves “ it is the identity you use to log on to Kerberos.” Remember that this can refer to a User Principal or to a Service Principal.

   1A: A User Principal would be a user to be authenticated, such as “[email protected]”- In this example, Orpheus is the user with the Principal of "Orpheus" in the realm "UNDERWORLD.CORP".

   1B: A Service Principal represents a common service, such as an HTTP server or a file share. Consider "HTTP/[email protected]” as a Service-Principal; This specific Service Principal pertains to an HTTP server operating within the "UNDERWORLD.CORP" realm. Within this Service Principal, "HTTP" serves as the identifier for the HTTP service, "hadesshares.underworld.com" signifies the fully qualified domain name (FQDN) of the web server, and "UNDERWORLD.CORP" designates the realm where this particular HTTP server is situated.

2. Resource: In the context of Kerberos, a resource refers to the networked asset or service a client aims to reach. This may encompass network services, systems, or data that a user or service seeks to interact with upon successfully completing the authentication process.

3. Key Distribution Center (KDC): The Key Distribution Center. A central component in Kerberos authentication. The KDC is responsible for managing authentication and distributing session keys in a realm. 

Oh, wait, realm? 

We’ve been talking about the “realm of the dead”. But in Kerberos, there is also this concept of Realms. 

Realms in Kerberos are a way of logically grouping resources and identities that use Kerberos. This means that we can group users, services, devices, or any entity that requires authentication and authorization in realms. 

Yes, for those familiar with Windows, you can think of realms as domains.

At a high level, these components are all you need to ensure proper authorization. 

Note💡: Learn more about Kerberos attacks and take other cybersecurity courses and certifications on the HTB Academy. 

The Key Distribution Center (KDC)

As mentioned earlier, our “puppy” Cerberus also had other features to safeguard the underworld. Such as “snakes on his back and a serpent’s tail”.  

Following that analogy, the Key Distribution Center (KDC) also has more components for security. We can separate these into several parts:

1. Kerberos database. This stores the necessary authentication information regarding the principal and the systems and services they can authenticate to.

2. Kerberos Authentication Server (AS). Principals use this Kerberos service to authenticate themselves to get a ticket-granting ticket (TGT), also known as an authentication ticket (more on tickets coming up next).

3. Kerberos ticket granting service (TGS). This Kerberos service accepts the TGT so that clients can access their application servers.

Kerberos tickets

The concept of tickets is crucial for Kerberos. This is where the magic happens. It’s the core feature of Kerberos that keeps passwords from being transmitted in clear text and allows for a single log-on to access multiple services and hosts.

Tickets leverage asymmetric encryption. They contain two encryption keys:

1. The ticket key: Shared between the Kerberos infrastructure and the service requested by the principal.

2. The session key: Shared between the principal and the service requested. Used to encrypt and decrypt communication with the service. (Got to watch out for those Typhon In The Middle Attacks, remember? We all know by now we’re referring to MITM or on-path attack, right?)

Kerberos network authentication process explained

Let’s break down how these components work together considering the following scenario:

Orpheus wants to connect to Hades file server to check secret information about the whereabouts of Eurydice. If Hades’ realm of the dead were a Kerberos Realm, this would be the flow for client authentication:

1. Who’s there?

1. Orpheus first needs to authenticate on the Authentication Server (AS) and not the Application server he’s trying to access.

2. AS validates the received credentials. It looks up the password hash of the user ‘Orpheus’ and decrypts the timestamp.

3. If the decryption is successful and the timestamp unique, the AS authenticates Orpheus.

4. Orpheus receives an Authentication Server Reply (AS-REP) from the AS. Comes bundled with:

• Session key, encrypted with Orpheus hash (so that Orpheus can decrypt it).

• Ticket Granting Ticket (TGT).

2. I grant you permission!

After authentication and equipped with a TGT. Orpheus can now request authorization to access the file server. Guess what? He must contact the KDC again. Now the Ticket Granting Server (TGS) on the KDC will come into play:

1. Orpheus sends a Ticket Granting Server Request (TGS-REQ) containing:

• User name and timestamp encrypted with the session key.

• Name of the resource he’s trying to access (file server with secret information about the whereabouts of Eurydice).

• The encrypted TGT he received upon authentication.

2. Upon receiving the TGS-REQ. the Ticket Granting Service on the KDC will:

• Check if the resource exists in the Realm.

• Decrypt the TGT.

• Extract session keys from the TGT.

3. If everything checks out, the TGS will respond to Orpheus with a Ticket Granting Server Reply (TGS-REP), which comes bundled with:

• Name of the service to which access has been granted.

• Session key. To be used between Orpheus and the File Server.

• Service Ticket (ST), yes, one more ticket.

3. Orpheus got a ticket to ride

Now that Orpheus is authenticated by the KDC, and has a session key and a service ticket (ST), he can now communicate with the service (finally!):

1. Orpheus sends the application server an Application Request (AP-REQ), bundled with:

   Service Ticket (ST).

   Username and timestamp encrypted with the session key.

2. Service Ticket (ST) is decrypted with the application server’s secret key (shared with the TGS).

3. The Application Server checks if the AP-REQ username matches the decrypted one from the ST.

4. Then checks if the principal (Orpheus) has privileges to use the service.

5. If everything checks out, the application server sends an Application Server Reply AP-REP granting access to the requested resource.

6. Orpheus can now authenticate himself to the file share and establish a secure session using the session key included in the AP-REP.

7. Go get Eurydice Orpheus. Just don’t look back.

Oh, you lost me there…

Got it? No? That’s perfectly fine. Kerberos may appear complex and convoluted, but that’s part of what makes it robust and secure. 

This apparent complexity is indeed a trade-off for the strong security guarantees it offers. Now we can understand why there are so many commercial solutions available, to simplify the setup and management of Kerberos in real-world environments.

Take it slow. Read it again and again. Draw your own flow chart as you read. Rinse and repeat. Remember, no one lands a kickflip first try while learning it.

The Lyre of Orpheus: Is Kerberos really bulletproof?

Kerberos is considered one of the most secure and robust authentication mechanisms out there. While no security measure is completely invulnerable, Kerberos is not an exception. 

Its long history has allowed hackers and security professionals to discover vulnerabilities, typically involving ticket forgery, repeated password guessing (brute force or credential stuffing), and employing malware to weaken encryption.

Here are some tunes you can play on your lyre, just like the mythical hacker Orpheus. These are the attacks you should study, practice, and be mindful of:

• AS-REP Roasting: If Kerberos pre-authentication is not configured, anyone can send a AS-REQ to the AS on behalf of any user. Upon obtaining the AS-REP one can crack user passwords through offline brute-force methods.

• Kerberoasting: The attacker steals the password hash of a service account. Upon obtaining them, it’s time and crack the account passwords using tools like John The Ripper.

• Kerberos Delegations: A Kerberos delegation is “a setting that allows applications to request end-user access credentials to access resources on behalf of the originating user.” These can be leveraged by attackers to get unauthorized access to resources, systems, or data and even Privilege Escalation.

• Golden Ticket: Attacker will cosplay Willy Wonka and the AD environment is the chocolate factory. This means keys to the kingdom. Attackers can forge a Ticket Granting Ticket (TGT) with arbitrary access privileges, essentially granting them full control over an Active Directory domain.

• Silver Ticket: Another forged authentication ticket. The Silver ticket is often a forged service ticket that enables access to resources on the target service.

• Pass-the-Ticket: Give me that!

  In these attacks, the goal of the adversary is to steal TGTs or TGS’ from a particular user. Then it’s time to reuse them with tools like mimikatz.

Where can I get one of those?

Kerberos has been available for free since 1987, MIT has made it Open source. The maintenance of this open-source project is under the responsibility of The Kerberos Consortium. 

The Kerberos Consortium is an organization created with the mission to keep developing the Kerberos protocol and strive to implement it in all networks, like a universal authentication platform. 

In their own words, they “foresee a day when Kerberos-based authentication and authorization will be as ubiquitous as TCP/IP-based networking itself.” So yes, go ahead and use it.

As a side note💡: MIT was an early pioneer in open-source software. Kerberos was one of the first code bases being distributed under the now-popular and then-revolutionary “MIT License.”

Kerberos is also available as a product from many different vendors, note that all of these versions derive from the Kerberos source available and created by MIT. Large companies with large networks often rely on this protocol for their authentication needs and to facilitate SSO.

 You can find Kerberos on (among many others) Linux, Windows, macOs, Solaris, AWS, Azure, Google Cloud, and of course (you were expecting this), Microsoft’s Active Directory (AD).

Time to learn Kerberos

Pretty exciting eh? Now it’s time to learn and practice.

There’s an entire module dedicated to Kerberos Attacks on HTB Academy. This module will explain how Kerberos works and provide several scenarios to practice the most common attacks against it from multiple perspectives. 

This means it will take you step-by-step to carry out and practice all these attacks. Go through them in the order we mentioned and upgrade your tool belt.

What if you’re new to Active Directory or Kerberos? 

If you’re still not familiar with Windows or Active Directory, it’s okay. Don’t rush. Take some time to learn what they are and how they work. 

Start with the Introduction to Active Directory module, which will give you a strong overview of how AD, Kerberos, and how Lightweight Directory Access Protocol (LDAP) work together. 

This is a vast topic, so break it down into little steps and go easy on yourself. Avoid the temptation of jumping straight into more advanced topics. 

Enjoy the ride!

Author bio: Pedro Correia (g4rg4m3l), Cybersecurity Lead, Red Teamer, and Instructor at Code For All_ Pedro Correia is a cybersecurity professional with a strong commitment to both learning and teaching. He currently serves as a Cybersecurity Lead, Red Teamer, and Instructor at Code For All_. He oversees a specialized team focused on penetration testing and cybersecurity assessments, with years of experience in educating students from diverse backgrounds worldwide in the domains of cybersecurity and programming. He also creates content specializing in various cybersecurity domains under the alias of “Cybersecurity Paladin.” As a Hack The Box Ambassador, Pedro hosts meetups, showcases, and live hacking demonstrations, making cybersecurity concepts more accessible to a wider audience. You can find him on HTB as “g4rg4m3l.” Pedro has embarked on a self-imposed delusional mission to infiltrate every Active Directory environment. Join him on this crusade. You can connect with him on LinkedIn.