Decoding Kerberos: Understanding the Authentication Process and Main Attacks

Navigating the Active Directory Maze: Unveiling Hacking Strategies

Table of contents

Unraveling Kerberos: A Deep Dive into Authentication and its Vulnerabilities

Welcome back to our ongoing series on mastering the nuances of cybersecurity! In this chapter, we pivot our focus to the Kerberos authentication protocol, dissecting its complexities and exploring the vulnerabilities inherent in its design. Kerberos, a cornerstone of modern authentication frameworks, plays a pivotal role in user authentication and authorization within networked environments.

Our journey will take us through the labyrinth of the Kerberos process, from ticket requests to the intricacies of ticket-granting services. As we traverse this terrain, we'll demystify each component of the protocol, shedding light on both its strengths and potential weaknesses.

In addition to understanding the theoretical aspects of Kerberos, we'll dive into practical applications. We'll examine how to replicate some of the most notorious Kerberos-based attacks in a lab setting, providing a hands-on perspective on how these vulnerabilities can be exploited. This approach not only aids in better understanding the protocol but also equips us with the knowledge to anticipate and mitigate real-world threats.

As we embark on this chapter, prepare to delve into the world of Kerberos authentication, unraveling its secrets and learning how to safeguard against its exploitation. Whether you're a seasoned security professional or an enthusiastic learner, this chapter promises to be a valuable addition to your cybersecurity repertoire. Let's get started on this fascinating journey!

Understanding Kerberos Authentication: The Ticket-Based Journey

Summarized Process

Diving into the realm of network security, let's unravel the complexities of Kerberos - a pivotal protocol in user authentication and authorization. Imagine Kerberos as a digital gatekeeper, managing access in a domain through a system of tickets. Here's the deal: when a user seeks entry into the domain kingdom, they knock at the door of the Key Distribution Center (KDC), essentially the domain controller. If the KDC approves, it hands over a golden key, the Ticket Granted Ticket (TGT). This TGT is like a passport, granting the user the privilege to request access to various domain services.

Now, whenever the user desires to engage with a specific service within the domain, they present their TGT to the KDC. In response, the KDC issues a new key, the Ticket Granted Service (TGS). The user then takes this TGS to the service's doorstep. The service, upon verifying the authenticity and authorization level of the TGS, rolls out the red carpet, allowing access.

This whole ticket-exchanging ceremony might seem intricate, but it's a dance of security and efficiency. Don't stress if it seems a bit tangled at first glance - we'll unravel each step, ensuring clarity in this digital ballet of authentication.

Delving into Kerberos: The First Step to Domain Authentication

Let's break down the Kerberos authentication process, starting from square one. Imagine you're at the gates of the digital domain, ready to prove your identity. This is where the Kerberos magic begins, a process initiated by the user sending a special request called "AS-REQ" to the domain's Key Distribution Center (KDC).

In this request, the user includes:

1. Their username - like calling out your name to the gatekeeper.
2. A request for the Ticket Granted Ticket (TGT) - akin to asking for an entry pass.
3. A timestamp, but not just any timestamp. It's encrypted with the user’s NT hash, a secret code that ensures the user's authenticity.

This initial interaction lays the groundwork for Kerberos-based authentication. It's also the stage vulnerable to specific attacks like "Pass the Key" or "Over Pass the Hash," which we'll explore later. Think of it as the opening scene of a cybersecurity drama, where the stage is set for both secure access and potential exploits.

Step 2: The KDC Rolls Out the Red Carpet with a TGT Ticket

Once the user's initial appeal passes the security checks, the server, playing the role of a grand host, presents the coveted Ticket Granted Ticket (TGT) along with a session key. This ceremonial pass is wrapped up in a message dubbed “AS-REP,” marking the user's successful entry into the domain’s digital ballroom.

Here's what the AS-REP message ceremoniously unveils:

1. Authenticated Username: Like a badge of honor, confirming the user's identity.
2. The TGT’s Duration and a Session Key: Encrypted with the user’s NT hash, this session key is a skeleton key of sorts for the upcoming requests to various domain services. It's a promise of future accesses.
3. The TGT Itself: This ticket is not just a simple pass. It's imbued with the session key, its validity period, and the Privilege Attribute Certificate (PAC). The PAC is like a detailed résumé of the user – listing their domain groups and roles. Importantly, this ticket is sealed with the NT hash of the KRBTGT account – a special account nestled within the domain controllers. Think of KRBTGT as the master key holder, with its hash being a master key. If someone were to replicate this hash, they could potentially unlock the entire domain, creating their own TGT tickets.

In essence, Step 2 is where the server grants the user a golden ticket to access the domain's resources, ensuring that the journey ahead is authenticated and authorized.

Step 3: Knocking on the Service's Door with a TGS Request

Now, the user, equipped with the TGT from the previous step, is ready to step up and request a specific domain service. This quest for access is encapsulated in a message known as "KRB-TGS-REQ," a formal request to the Kerberos gods for a Ticket Granting Service (TGS) ticket.

Here's what the user packs into this request:

1. The Service Name (SPN): Think of it as dialing the extension of the specific department in a vast corporate building. The Service Principal Name or SPN precisely identifies the service the user wishes to access. It's like saying, "I need to talk to the manager of the 'File Sharing' department."
2. Username and a Time-stamped Token: To prove their identity and intention, the user includes their username coupled with a timestamp. But it's not just any timestamp; it's encrypted with the service key handed over in the previous message. It’s akin to showing a secret handshake – a way to confirm their authenticity.
3. The TGT Ticket: This is the golden ticket received earlier. Presenting this ticket is like showing a VIP pass, proving that the user has been previously authenticated and is cleared to make further requests within the domain.

In a nutshell, Step 3 is where the user, armed with their TGT, makes a specific request to access a domain service. It's like approaching a concierge with a verified pass and asking for entry into an exclusive club within the grand domain estate.

Step 4: Receiving the Golden Pass - The TGS Ticket

The moment of truth arrives in Step 4 of the Kerberos process. If the TGT sent by the user passes muster with the Key Distribution Center (KDC), it responds with a prized possession: the TGS (Ticket Granting Service) ticket, encapsulated in a message known as "KRB-TGS-REP." This ticket is the user's gateway to the requested service. Here's what's inside this all-important response:

1. Client-Only Decipherable Content: This section of the message is a treasure trove, but only for the client's eyes. It contains the service's name, a fresh timestamp, and a unique session key for the service. This part is like a confidential memo, sealed in an envelope that only the client can open, as it's encrypted using the session key provided in Step 2.
2. Service-Specific TGS: The second part of the message is the TGS itself, tailored specifically for the requested service. This section is encrypted with the NT hash of the service owner, meaning only the server hosting the service can decrypt it. Packed inside are the user's name, the service name, the service's session key, a token detailing the user's privileges in the domain, and a timestamp.

In essence, Step 4 is where the KDC validates the user's request and bestows upon them the TGS ticket - a golden pass, granting access to the requested service. It’s as if the concierge, after verifying the VIP pass, hands over a special key that unlocks the doors to the exclusive club the user wished to enter.

Step 5 to 7: The Final Stages of Kerberos Authentication

The Kerberos journey reaches its climax in these final steps, where the client's request meets the service's scrutiny, and mutual verification takes place.

Step 5: Delivering the TGS to the Service Server

Ticket Presentation (KRB-AP-REQ): In this crucial phase, the client sends the TGS ticket to the desired service. This is done through a message known as the KRB-AP-REQ. It's akin to presenting an exclusive pass at a high-security event. The service, acting as a vigilant bouncer, examines the ticket to validate its authenticity, ensuring it's signed with the service's unique key.

Step 6: Optional Service Ticket Verification

Guarding Against Silver Ticket Attacks: This step, while optional, acts as an additional layer of security. The service can use it to verify the integrity of the KRBTGT account's hash. This check is a safeguard against potential Silver Ticket attacks, where attackers forge tickets to gain unauthorized access to services.

Step 7: Confirming the Server's Identity

Server's Assurance (KRB-AP-REP): The final acknowledgment comes from the server, which sends back a message, the KRB-AP-REP. This message includes a timestamp and the known service key. It’s the server's way of saying, "Yes, it's really me." This mutual authentication ensures both parties are confident in each other's identity, akin to a secret handshake in a spy movie.

These steps complete the intricate dance of Kerberos authentication. It's a process where trust is established through a series of coded messages, each playing a critical role in maintaining the security and integrity of the communication between a user and the services within a domain.

Main Kerberos Attacks: Unraveling Kerberos' Vulnerabilities

Kerberos, the guardian of authentication in many domains, isn't impervious to attacks. Let’s delve into the primary attacks targeting the Kerberos protocol and how they can be executed.

Kerberos Brute-Force Attack: Cracking the Code

Kerberos, being an authentication protocol, is susceptible to brute-force attacks. These attacks aim to validate credentials within the domain. The Kerberos system provides specific error messages for various scenarios, making it possible to identify the nature of the failure. Examples include:

• KDC-ERR-PREAUTH-FAILED: Indicates an incorrect password.
• KDC-ERR-C-PRINCIAPL-UNKOWN: Flags an invalid username.
• KDC-ERR-WRONG-REALM: Signals an invalid domain.
• KDC-ERR-CLIENT-REVOKED: Denotes a disabled or blocked user.

These distinct responses facilitate not just the brute-forcing of passwords, but also the enumeration of users.

Harnessing Kerbrute for Non-Intrusive User Enumeration

Kerbrute stands out as a highly recommended tool for user enumeration in Kerberos-based systems, particularly for its ability to perform the task without risking account lockouts. This feature is invaluable during internal pentesting, allowing for the accumulation of a user list without alerting system administrators or disrupting user activities.

The command ./kerbrute_linux_amd64 userenum -d shadow.local usernames.txt serves as a gateway to effectively enumerate users within the domain 'shadow.local', using a list of potential usernames. This list can be curated from various sources, including the insightful GitHub repository "insidetrust/statistically-likely-usernames".

This GitHub repository offers a compilation of wordlists specifically designed for creating statistically probable usernames. These lists are tailored for password attacks and security testing, making them a perfect companion for tools like Kerbrute. The advantage of using these lists lies in their non-intrusive nature, ensuring that the enumeration process does not trigger account lockouts, thus maintaining stealth and efficiency in pentesting scenarios.

The usernames identified through this process can serve as a foundation for further attacks, such as the “ASREProast” technique, which will be discussed in subsequent sections. The ability to accumulate a list of potential targets without alerting the network's defenses marks a significant step in the penetration testing process.

For those interested in exploring and utilizing these wordlists, visit the GitHub repository: insidetrust/statistically-likely-usernames. This resource provides an array of wordlists that are pivotal for successful user enumeration and subsequent penetration testing strategies.

Brute Force and Password Spraying

While kerbrute can also perform brute force and password spraying attacks to discover valid domain credentials, caution is advised. These methods can lead to account lockouts, contingent on the domain's password policy. An example of a password spraying attack would be testing a common password across multiple users, with a safety feature to halt the attack if lockouts are detected.

./kerbrute_linux_amd64 passwordspray -d shadow.local usernames.txt Password123 --safe

User=Pass Technique

An intriguing method involves testing scenarios where the username is the same as the password. It's surprisingly effective at times.

cat userpass.txt | ./kerbrute -d shadow.local bruteforce -

Unlocking Secrets with ASREProast: A Deep Dive into Kerberos Authentication Exploitation

Imagine a scenario where we've successfully enumerated domain users, but without acquiring any passwords. This is where the "ASREProast" attack, a sophisticated method targeting the second step of the Kerberos authentication process (AS-REP), comes into play. The crux of this technique lies in requesting Ticket Granting Tickets (TGTs) without needing the user's NT hash, effectively bypassing pre-authentication requirements.

This vulnerability stems from an option in Active Directory settings that allows certain users to bypass pre-authentication. By leveraging this setting, attackers can intercept the AS-REP message from the server, which includes a part encrypted with the user’s NT hash. The ultimate goal? To decrypt this hash and reveal the user's plaintext password.

One of the potent tools in executing the ASREProast attack is the "impacket-GetNPUsers" script from the Impacket suite. For instance, the command impacket-GetNPUsers 'shadow.local/beruinsect:Password3' -dc-ip 192.168.253.130 -outputfile asreproast-hashes.txt is designed to exploit this vulnerability. However, it's crucial to note that this attack only works if the user’s account is configured to bypass Kerberos pre-authentication.

In cases where this configuration is not set, and the attack yields an error, one can enable this option via Active Directory management tools. By modifying user settings to disable pre-authentication, attackers can then re-run the attack to capture the hash successfully.

Once the hash is obtained, it can be subjected to password cracking tools like Hashcat. A typical command like hashcat -m 18200 --force -a 0 asreproast-hashes.txt pass.txt can be employed to crack the hash and expose the user’s password.

For broader exploitation, the "impacket-GetNPUsers" script also permits the use of a user list file, enhancing the attack's efficiency by allowing the extraction of AS-REP messages from multiple users simultaneously. The command for this broader approach would be:

impacket-GetNPUsers -userfile usernames.txt -dc-ip 192.168.253.130 -format hashcat -outputfile asreproast-hashes.txt

Harnessing Kerberoast: Targeting the Heart of Kerberos TGS Exchange

Kerberoast is a formidable attack vector that targets a critical juncture in the Kerberos authentication process—the point where the user receives the Ticket Granting Service (TGS) ticket, a key step in the Kerberos TGS Exchange (Step 4: KRB-TGS-REP). This attack is particularly insidious because it exploits the encryption of part of the message with the NT hash of the service account. By cracking this encryption, attackers can unveil the clear text password of the service account.

The attack is primarily directed at service accounts linked to user accounts, rather than those tied to computer accounts. The latter often possess complex, automatically generated passwords, making them less vulnerable. However, user-linked service accounts often have weaker, user-defined passwords and tend to carry high-level domain privileges, making them ripe targets for exploitation.

Understanding Service Principal Names (SPNs) is crucial for this attack. SPNs are unique identifiers for services within an Active Directory environment, formatted as service_class/machine_name[:port][/path]. To register a service tied to a user account in a domain, one would use a command like:

setspn -a DC-SHADOW/SQLService.shadow.local:60111 SHADOW\SQLService

This command creates an SPN for a service, linking it to a specific user account. Verification of the SPN creation can be done using:

setspn -T shadow.local -Q */*

For executing the Kerberoast attack, one needs a valid domain account, as it requires a TGT to request TGSs from the domain controller. The GetUserSPNs.py script from Impacket, for instance, is designed to facilitate this process:

GetUserSPNs.py 'shadow.local/beruinsect:Password4' -dc-ip 192.168.253.130 -outputfile kerberoast-hashes.txt

Once the TGS ticket is acquired, attackers can employ password-cracking tools like Hashcat to decrypt the service account password:

hashcat -m 13100 --force -a 0 kerberoast-hashes.txt pass.txt

Mastering 'Over Pass the Hash' in Kerberos Authentication

The 'Over Pass the Hash' attack is a clever maneuver in the Kerberos authentication landscape, focusing on a key aspect of the process: In Step 1 (Domain Authentication), a user's clear password isn't mandatory for requesting TGT (Ticket Granting Ticket) tickets; instead, their NT hash suffices. This attack exploits this facet by substituting the user's NT hash for their actual password to acquire valid TGT tickets, enabling domain authentication.

The primary tool for this attack is Impacket's getTGT, which facilitates the acquisition of TGT tickets using a user's NT hash. Here's an example of how the getTGT command is used:

impacket-getTGT shadow.local/ironhammer -hashes :7247e8d4387e76996ff3f18a34316fdd -dc-ip 192.168.253.130

Post-acquisition of the TGT ticket, attackers can leverage tools like psexec for authentication and accessing target machines. Remember, Kerberos authentication demands the hostname, not the IP address of the target. Setting the appropriate environment variable is essential:

export KRB5CCNAME=/home/rsgbengi/Desktop/lab/kerberos/ironhammer.ccache

impacket-psexec -dc-ip 192.168.253.130 -target-ip 192.168.253.131 -no-pass -k shadow.local/[email protected]

An intriguing facet of this attack is its versatility: it can be executed using Kerberos keys as an alternative to the NT hash. Kerberos keys, pivotal in ticket and message encryption, are often cached in the Local Security Authority Subsystem Service (LSASS). Tools like Mimikatz or secretsdump are adept at extracting these keys. For instance, a dump of the NTDS (Active Directory database) using secretsdump can reveal these keys.

Understanding 'Pass the Ticket' in Kerberos Authentication

The 'Pass the Ticket' attack revolves around the strategic acquisition and utilization of Kerberos tickets, specifically TGT (Ticket Granting Ticket) and TGS (Ticket Granting Service). The core idea is to use these tickets—obtained through LSASS content dumping via tools like Mimikatz or lsassy—for accessing various domain services.

The process begins with ticket extraction. For instance, using the lsassy tool, we can retrieve Kerberos tickets with a command like:

lsassy -d shadow.local -u ironhammer -p Password4 192.168.253.131 -K tickets

Exploring the extracted tickets reveals a treasure trove of information, including multiple user TGTs and TGSs for various services, such as Samba (cifs_dc-shadow) or LDAP (ldap_dc-shadow). Each ticket is linked to a specific user, providing insights into their domain access privileges.

To make these tickets usable for attacks, they often need to be converted to a different format. This is where the 'impacket-ticketConverter' tool comes into play, transforming tickets from .kirbi to .ccache format. Once converted, setting the KRB5CCNAME environment variable is crucial for leveraging these tickets with various tools. For instance:

export KRB5CCNAME=/home/rsgbengi/Desktop/lab/kerberos/tickets/beru.ccache

This setup enables the use of tools like Impacket's psexec for authentication, similar to what is done in 'Pass the Hash' but with the added advantage of utilizing actual Kerberos tickets.

The Intricacies of Golden and Silver Tickets in Kerberos

Golden and Silver Tickets represent two potent forms of attacks within the Kerberos authentication protocol, each leveraging different aspects of the system.

Golden Tickets: These are akin to master keys, allowing attackers to forge TGT (Ticket Granting Tickets) for any user. The linchpin for this attack is the krbtgt account – the central figure in the Kerberos ticketing system. Compromising this account, specifically obtaining its NT hash, is crucial. Once this is achieved, attackers can use tools like Impacket’s ticketer to create TGTs for any user, thus gaining broad access to domain services.

To execute this attack, one needs the domain's SID and the krbtgt account’s NT hash. With these in hand, crafting a TGT for even the domain administrator is possible. For example:

impacket-ticketer -domain-sid  S-1-5-21-1545742773-2923955266-673312136 -nthash 011948128d80ec39af3a837c5d153dea -domain shadow.local administrator

Post-creation, the ticket can be used for domain authentication as seen in:

export KRB5CCNAME=/home/rsgbengi/Desktop/lab/kerberos/administrator.ccache
impacket-psexec -dc-ip 192.168.253.130 -target-ip 192.168.253.130 -no-pass -k shadow.local/[email protected]

Silver Tickets: These focus on forging TGS (Ticket Granting Service) tickets for specific services. Instead of needing the krbtgt account’s NT hash, the Silver Ticket attack requires the NT hash of the account running the targeted service. This specificity makes Silver Tickets less sweeping in scope compared to Golden Tickets but still incredibly powerful for accessing particular services.

Embracing Kerberos: Understanding and Safeguarding

In this exploration of the Kerberos authentication protocol, we've journeyed through its intricate workings and uncovered the potent attacks that target its core mechanisms. From the fundamental steps of the Kerberos process to the sophisticated strategies of Golden and Silver Ticket attacks, our expedition into this realm has been enlightening.

We delved into various attack methodologies, such as Kerberos brute-force, ASREProast, Kerberoast, and the Over Pass the Hash technique. Each of these exploits highlights a unique vulnerability within the Kerberos system, underscoring the importance of robust security practices in managing and safeguarding authentication processes.

This chapter not only enhances our understanding of Kerberos but also arms us with the knowledge to replicate these attacks in a controlled lab environment. Such practical insights are invaluable in fortifying our defenses against real-world threats.

As we wrap up this chapter, it's clear that the Kerberos protocol, while robust and sophisticated, is not impervious to exploits. Vigilance, constant learning, and adapting to emerging threats remain our best tools in the ever-evolving landscape of cybersecurity. Let's continue to embrace these challenges with a keen eye and a readiness to evolve, ensuring the integrity and security of our digital realms. Happy hacking!

Tips of the article

Could you explain to me at a high level what Kerberos is and how it works ?

Kerberos, as discussed in previous chapters, is a protocol that enables user authentication and authorization processes. This is done from what is known as Kerberos tickets. When a user wants to authenticate in the domain from Kerberos, he does it against the KDC or Key Distribution Center (it is the domain controller) which, in case of success, will return a ticket called TGT or Ticket Granted Ticket. This ticket will be sent by the user to the KDC every time he wants to authenticate against any service of the domain. Likewise, the KDC will return a TGS or Ticket Granted Service to the user. This ticket will be sent by the user to the machine that has the service running and it will check if the ticket is valid, as well as if the user has the sufficient level of authorization. This whole process is summarized in the following diagram:

What tool can I use to enumerate kerberos users? Can this enumeration process block users?

We could use "Kerbrute". This tool does not block users through the user enumeration process because it does not cause login errors.We could use "Kerbrute". This tool does not block users through the user enumeration process because it does not cause login errors.

What is the ASPREPRoast attack? What information do I need to perform the ASPREProast attack? Which tool can I use to perform it ?

The ASPREProast attack mainly consists in requesting TGTs without providing the timestamp signed with the user’s NT hash, thus making it unnecessary to pre-authenticate. To perform this attack I only need a list of users that I know exists in the domain. To perform this attack I can use the impacket tool getNPUsers.

What does the "Kerberoast" attack consist of? What tool could you use to carry out this attack?

This attack consists of requesting service tickets or TGS from the domain controller and then trying to crack them. These service tickets must correspond to user accounts, otherwise it will be impossible to crack them due to the complexity of the password. To carry out this attack we can use the impacket tool getUsersSPNs

What is Over Pass The hash ? What tool can we use to carry out this attack?

It consists of requesting TGT tickets but without knowing the user's password but his NT hash. To perform this attack I can use the impacket script getTGT.

What does the "Pass the Ticket" attack consist of? What environment variable do I have to configure in Linux to use this ticket?

It consists of using TGTs or TGSs to authenticate to a certain service. The environment variable to be configured is called "KRB5CCNAME".

What do we mean by "Golden Ticket" and "Silver Ticket"? What do I need to form a "Golden Ticket"?

First, in case of gold tickets, it consists of the ability to generate TGT tickets from any user. To be able to do this, it is required to have comrpromised the user krbtgt, which, as we saw in the kerberos authentication process, its credentials are the ones used to encrypt the TGT content.
Silver tickets, on the other hand, refers to the possibility of creating TGS tickets for a given service. In order to do this, we must have obtained the NT hash of the account that is running the service. Let’s put now a use case to forge a gold ticket.

To make a goro ticket I need to know the domain sid as well as have the NT hash or password of the user krbtgt.

Resources

Attacking Active Directory: 0 to 0.9 | zer1t0

zer1t0

Chapters

Mastering NTLM: Exploring Authentication, Vulnerabilities, and Exploits

Previous chapter

Mastering Active Directory Pivoting: Advanced Techniques and Tools

Next chapter

arrow_upward