This module provides an in-depth study of the Kerberos protocol and its authentication process within an Active Directory network. Using Kerberos, we will explore attacks, Active Directory delegation, persistence, and lateral movement techniques.
In this module, we will cover the following:
- Common Kerberos attacks
- Abusing Delegation in Active Directory
- Leveraging Kerberos for AD Persistence
- Lateral Movement with Kerberos
This module is broken down into sections with accompanying hands-on exercises to practice each of the tactics and techniques that we cover. The module ends with a practical hands-on skills assessment to gauge your understanding of the various topic areas.
As you work through the module, you will see example commands and command output for the topics introduced. It is worth reproducing as many of these examples as possible to reinforce further the concepts presented in each section.
The module is classified as "Hard" as it assumes a working knowledge of the Linux command line and an understanding of information security fundamentals.
A firm grasp of the following modules can be considered a prerequisite for the successful completion of this module:
- Networking Fundamentals
- Linux Fundamentals
- Windows Fundamentals
- Introduction To Active Directory
- Active Directory Enumeration & Attacks
Kerberos is a protocol that allows users to authenticate on the network and access services once authenticated. Kerberos uses port 88 by default and has been the default authentication protocol for domain accounts since Windows 2000. When a user logs into their PC, Kerberos is used to authenticate them. It is used whenever a user wants to access a service on the network. Thanks to Kerberos, a user doesn't need to type their password in constantly, and the server won't need to know every user's password. This is an example of centralized authentication.
Kerberos is a stateless authentication protocol based on tickets. It effectively decouples a user's credentials from their requests to consumable resources, ensuring their password is not transmitted over the network. It is a Zero-knowledge proof protocol. The Kerberos Key Distribution Center (KDC) does not record previous transactions; instead, the Kerberos
Ticket Granting Service (
TGS) relies on a valid
Ticket Granting Ticket (
TGT). It assumes that if a user has a valid TGT, they must have proven their identity.
At a very high level, when a user wants to interact with available resources on the network, the following occurs:
- They will first ask a centralized server for an "identity card".
- The user will then have to prove who they are, and in exchange, they will receive their "identity card," or Ticket Granting Ticket (TGT).
TGTwill be presented whenever they want to access a service. Thus, each time they want to access a service, they will present this ID, and if it is valid, the central server will provide a temporary ticket to present to the requested resource.
- This temporary ticket contains all the user's information, such as their name, group membership, etc.
- The resource will then receive this ticket and will be able to grant access to its services if the user has the right to do so.
This process takes place in two stages. First, via a ticket request to identify a user's
TGT, and then a request to access services using a
Ticket Granting Service (
TGS) ticket or
Service Ticket (
Ticket Granting Service (TGS) is a component of the Key Distribution Center (KDC), which is responsible for issuing service tickets.
Note: Throughout the module, when we use the term
TGS ticket, it is as if we are referring to a
Service Ticket (ST).
With all the talk about Kerberos attacks and the dangers of the Golden Ticket attack, it is easy to think it is an inferior authentication protocol. Before Kerberos, authentication happened over
NTLM, and the user's hash was stored within memory upon authentication. If a target machine was compromised and the NTLM hash was stolen, the attacker could access
anything that the user account had access to via a
Pass-The-Hash attack. As previously mentioned, Kerberos tickets do not contain a user's password and will specify the machine to which the ticket grants access.
This is why the Double Hop Problem exists when accessing machines remotely via
WinRM. When a non-Kerberos protocol is utilized to access a machine remotely, it is possible to use that connection to access other machines as that user without re-prompting for authentication because the
NTLM password hash is tied to that session. With Kerberos authentication, credentials must be specific for every machine they want to access because there is no password. For more on this topic, refer to the Kerberos "Double Hop" Problem section of the
Active Directory Enumeration & Attacks module.
Suppose a compromised machine with active sessions is authenticated via Kerberos. In that case, performing a
Pass-The-Ticket attack is possible, which will be explained and demonstrated later in this module. However, unlike
Pass-The-Hash, the attacker will be limited to the resources that the victim user authenticated against. Additionally, these tickets have a lifetime, meaning the attacker has a limited time window to access the resource(s) and attempt to establish persistence.
The following section explains the Kerberos authentication process in detail, including how the tickets are protected and what they contain. An understanding of this process is essential before diving into Kerberos-related attacks. There are many ways that Kerberos can be abused within an Active Directory environment for lateral movement, privilege escalation, and persistence. We will encounter many of these techniques during our penetration tests and red team assessments. As security practitioners, we must deeply understand how Kerberos works and how it can be abused to our benefit. It is also essential to explain how Kerberos attacks work and how customers can protect against them and set up proper monitoring to detect Kerberos abuse.