The Road to CRTP Cert — Part 15

Introduction

Dear Professionals, welcome back to “The Road to CRTP Blog” series! In our previous post, we explored Offensive .NET, let’s shift our attention to Kerberos.

Let’s continue this exciting journey towards CRTP success!

Overview

We have completed the phases of Domain Enumeration, Local Privilege Escalation, Admin Reconnaissance, and Lateral Movement. Currently, we are focusing on Domain Admin Privilege Escalation.

Note: Gaining Domain Admin access is merely the starting point for compromising an enterprise. It opens up numerous possibilities, such as establishing persistence, evading Enterprise Admins, and performing cross-trust attacks. However, before escalating to Enterprise Admin or executing cross-trust attacks, we should first secure our privileges.

Our goal is to ensure that we can maintain Domain Admin access whenever needed, without relying on a single set of credentials. This is essential to truly dominate the target domain. Achieving this requires implementing persistence mechanisms to remain a Domain Admin on demand. This approach forms the essence of persistence and domain dominance.

Before diving into persistence, let’s revisit Kerberos with a quick overview.

What is Kerberos?

Active Directory primarily relies on Kerberos as its authentication mechanism. For example:

Accessing a file share on another domain-joined machine? Use Kerberos.Accessing an IIS application using domain credentials? Use Kerberos.

In Active Directory, nearly all authentications are handled using Kerberos.

Here’s how Kerberos works:
Clients (applications or machines acting on behalf of a user) obtain a ticket from the Domain Controller (DC) via the Key Distribution Center (KDC). These tickets effectively serve as client credentials. Understanding this process is crucial due to its significance.

Kerberos Authentication Workflow

Step 1:
The client generates a timestamp, encrypts it using the user’s NTLM hash or AES key (commonly AES), and sends it to the DC. Since the DC has access to all domain secrets, it decrypts the timestamp and validates the clock skew (verifying time synchronization between the client and DC). If valid, the DC responds with a Ticket Granting Ticket (TGT).

Step 2:
The DC sends the TGT to the client. This ticket is encrypted and signed using the secrets of a special DC account called KRBTGT (Kerberos Ticket-Granting Ticket account).

Can the client decrypt the TGT? No. Only the KRBTGT account can decrypt it.

Step 3:
The client sends the TGT back to the DC as proof of possession, requesting a Service Ticket (TGS) for a specific service identified by its Service Principal Name (SPN) (e.g., MSSQLSVC/server.domain.local).
The DC validates the TGT by decrypting it using the KRBTGT account’s secrets. If successful, the DC assumes the TGT contents are valid (though recent updates by Microsoft prevent complete trust in the TGT contents).

Step 4:
It then responds with a TGS. The TGS (or Service Ticket) is encrypted using the AES key or NTLM hash (RC4 encryption) of the target service account.

Can the client decrypt the TGS? No. Only the service account can decrypt it.

Step 5:
The client presents the TGS to the target service and requests access. The service decrypts the ticket using its own secrets and decides the client’s privileges (e.g., admin access, normal user access, or no access).

This step highlights that the service, not the DC, decides authorization.

Step 6 (Optional):
Optional Mutual Authentication ensures the client is communicating with the intended service and not a rogue server.

Additionally, Privilege Attribute Certificate (PAC) validation can be enabled to verify service ticket contents. However, enabling PAC increases requests to the DC, so it is often disabled in production environments.

Key Kerberos Concepts

Clock Skew:
The default clock skew policy in Microsoft environments is 5 minutes. If the time difference between a client and DC exceeds this, authentication fails.

TGT and TGS Roles:
- TGT handles authentication.
- TGS handles authorization.

SPN and Service Accounts:
An SPN is an attribute tied to an account. If an account has an SPN assigned, it is treated as a service account. Even if no service actively uses the account, having an SPN enables TGS requests for that account.

Common Questions

What about users logging in via VPN from different time zones?
Domain Controllers act as time providers (NTP servers) in a domain. They adjust for time zone differences. However, if the post-conversion time difference exceeds 5 minutes, login will fail.What happens in Step 4 regarding SPN?
The TGS is encrypted using the service account’s AES key or NTLM hash. The service account is identified by its SPN.How is an SPN associated with an account?
If an account’s SPN attribute is populated, the KDC treats it as a service account, even if no actual service is running on it.

Updated Overview of Steps for Kerberos Authentication:

Pre-Authentication:
The client encrypts a timestamp with the user’s AES key and sends it to the DC.TGT Issuance:
The DC validates the timestamp and responds with a TGT encrypted using the KRBTGT account’s secrets.TGS Request:
The client presents the TGT to the DC and requests a TGS for a specific SPN. The DC validates the TGT and issues a TGS encrypted with the target service account’s keys.Service Ticket Use:
The client sends the TGS to the target service, which decrypts it and decides the user’s access level.Optional Steps:
Mutual Authentication and PAC validation can add layers of security but are often disabled in production.

With sufficient privileges, most of these steps are susceptible to abuse, making Kerberos a critical component in persistence and attack strategies.

Thank you for taking the time to read my blog. Wishing you a joyful learning experience ahead!