Disclaimer
This post is dedicated to Ethical Hacking and legal Penetration Testing. All information is for educational use only. Never attempt to use these techniques on or against systems that you do not own, or have express permission to do so.
What is Kerberos?
Kerberos is a protocol for authenticating service requests between trusted hosts across an untrusted network, such as the internet. Kerberos support is built into all major computer operating systems, including Microsoft Windows, Apple macOS, FreeBSD and Linux. Kerberos was developed for Project Athena at the Massachusetts Institute of Technology (MIT). The name was taken from Greek mythology; Kerberos (Cerberus) was a three-headed dog who guarded the gates of Hades. The three heads of the Kerberos protocol represent the following:
- the client or principal
- the network resource, which is the application server that provides access to the network resource
- a key distribution center (KDC), which acts as Kerberos’ trusted third-party authentication service
Users, systems and services using Kerberos need only trust the KDC. It runs a single process and provides two services: an authentication service and a ticket granting service (TGS)
Kerberos Protocol Flow
Here are the principal entities involved in the typical Kerberos workflow:
- Client : the client acts on behalf of the user and initiates communication for a service request
- Server : the server hosts the service the user wants to access
- Authentication Server (AS) : the AS performs the desired client authentication. If the authentication happens successfully, the AS issues the client a ticket called TGT (Ticket Granting Ticket). This ticket assures the other servers that the client is authenticated
- Ticket Granting Server (TGS) : the TGS is an application server that issues service tickets as a service
- Key Distribution Center (KDC) : in a Kerberos environment, the authentication server is logically separated into three parts:
- A database
- The Authentication Server (AS)
- The Ticket Granting Server (TGS)
These three parts, in turn, exist in a single server called the Key Distribution Center
Kerberos Crucial Keys
Crucial secret keys involved in the Kerberos flow.
- Client/User : Hash derived from the user’s password
- TGS secret key : Hash of the password employed in determining the TGS
- Server secret key : Hash of the password used to determine the server providing the service
Kerberos Protocol Flow
Steps
- Initial client authentication request
- The user asks for a Ticket Granting Ticket (TGT) from the authentication server (AS). This request includes the client ID.
- KDC verifies the client’s credentials.
- The AS checks the database for the client and the TGS’s availability. If the AS finds both values, it generates a client/user secret key, employing the user’s password hash.
- The AS then computes the TGS secret key and creates a session key (SK1) encrypted by the client/user secret key. The AS then generates a TGT containing the client ID, client network address, timestamp, lifetime, and SK1. The TGS secret key then encrypts the ticket.
- The client decrypts the message.
- The client uses the client/user secret key to decrypt the message and extract the SK1 and TGT, generating the authenticator that validates the client’s TGS.
- The client uses the TGT to request access.
- The client requests a ticket from the server offering the service by sending the extracted TGT and the created authenticator to TGS.
- The KDC created a ticket.
- The TGS then uses the TGS secret key to decrypt the TGT received from the client and extracts the SK1.
- The TGS decrypts the authenticator and checks to see if it matches the client ID and client network address.
- The TGS also uses the extracted timestamp to make sure the TGT hasn’t expired.
- Note : If the process conducts all the checks successfully, then the KDC generates a service session key (SK2) that is shared between the client and the target server. The KDC created a service ticket that includes the client id, the client network address, timestamp, and SK2. This ticket is then encrypted with the server’s key obtained from the db. The client receives a message containing the service ticket and the SK2, all encrypted with SK1.
- The client uses the file ticket to authenticate.
- The client decrypts the message using SK1 and extracts SK2. This process generates a new authenticator containing the client network address, client ID, and timestamp, encrypted with SK2, and send it and the service ticket to the target server.
- The target server receives decryption and authentication.
- The target server uses the server’s secret key to decrypt the service ticket and extract the SK2.
- The server uses SK2 to decrypt the authenticator, performing checks to make sure the client ID and client network address from the authenticator and the service ticked match.
- The server also checks the service ticket to see if it’s expired.
Requirements & Attack Types
Pass-the-Key
To be able to pass the key we need to have plaintext credentials for the users account, this is the most basic of attacks but once you have the plaintext credentials you can always generate tickets for the account and have other abilities that tickets won’t give you easily such as UAC by passing when on the device via RDP.
Pass-the-Ticket
Tickets can be collected from intercepting traffic on the network which we will talk about in later posts. These tickets can be used to impersonate the account that the ticket belongs to and access the same devices the ticket is generated for.
Silver Ticket
In order to perform a Silver Ticket attack, there are a couple of things that we need: Domain Name, Domain SID, and NT Hash of the target service. We can use this information to then generate a ticket on behalf of the target service to attempt to gain access to the service.
Golden Ticket
Similar to the Silver Ticket, there are a few pieces of information we need in order to generate a valid golden ticket: Domain Name, Domain SID, and the NTLM password hash of the krbtgt account. Using this information we can generate a golden ticket for any account that is in the domain including accounts that don’t actually exist.
ADCS
We can use Active Directory Certificate Services (ADCS) Certificates to gain further access to the domain via privilege escalation, some of the templates that are vulnerable to this type of abuse are:
- Templates Allows SAN (ESC1)
- Any Purpose EKU (ESC2)
- Certificate Agent EKU (ESC3)
- Web Enrollment (ESC8)
- No Security Extension (ESC9)
- Weak Certificate Mapping (ESC10)
During these posts we will only be covering ESC1, ESC2 and ESC8 which are commonly found during engagements.
Print Nightmare
Using the Print Nightmare exploit we can create an administrative user account on the domain controller and use it to perform a DCSYNC attack.
Forged PAC (MS14-068)
This is a known exploit that has affected many versions of Windows Servers and is still common to see in modern networks running Windows Server 2016 or prior. One of the requirements of the noPac attack is that the Machine Account Quota (MAQ) attribute must be greater than 0. This attack is used to impersonate a Domain Admin from a standard user account then perform a DCSYNC attack.
Wrapping Up
In our latest blog post, we took a deep dive into the intricate world of Kerberos, unraveling its history, dissecting its protocol flow, and exploring a spectrum of attacks, each with its unique purpose and implications. As we immerse ourselves in the realm of cybersecurity, we’re setting the stage for the highly anticipated sequel, Part 2. In the forthcoming installment, our focus will pivot to the critical phase of basic reconnaissance. This essential groundwork lays the foundation for attackers to identify key information, a crucial stepping stone toward orchestrating the pivotal process of gaining initial access to the domain.