Microsoft's Active Directory (AD) has become an indispensable tool in the enterprise environment. Underlying its robust authentication mechanisms is the Kerberos protocol. In this article, we will delve deep into the intricacies of the Kerberos mechanism and the pivotal role it plays in AD authentication. We close the article by looking into latest methods in forging Kerberos tickets.

Introduction to Microsoft Active Directory

Active Directory is a Microsoft product that consists of several services to administer permissions and access to networked resources. It stores information about members of the domain, including devices and users, and verifies credentials and rights (Desmond, 2018).

Key Components of Active Directory:

• Domain Controller (DC): The server that responds to security authentication requests.
• Object: The distinct, individual components within AD (like users or computers).
• Schema: The blueprint dictating how data is organized and what objects can be stored.
• Trust: A relationship between two domains wherein one domain trusts the other to authenticate its users.

What is Kerberos?

Kerberos is an authentication protocol based on cryptographic tickets, designed to confirm the identity of users and systems over non-secure networks (Neuman & Ts'o, 1994). Named after the three-headed guard dog of Greek mythology, Kerberos authenticates through a trusted third party, known as the Key Distribution Center (KDC).

Components of Kerberos in AD:

• Key Distribution Center (KDC): Central to Kerberos, it authenticates users and grants tickets. In AD, the KDC role is performed by the Domain Controller.
• Ticket Granting Ticket (TGT): A ticket used to obtain additional session tickets for specific services.
• Session Ticket: Provided by the Ticket Granting Service (TGS) for access to a particular service.
• Authenticator: A time-stamped record proving the user's identity.

3. Kerberos Authentication Mechanism in AD

Understanding Kerberos means understanding its ticket mechanism. Here's how it functions:

3.1 Initial Login

1. TGT Request: Upon initial login, the user's system requests a TGT from the KDC.
2. TGT Issuance: The KDC verifies the user against the AD database. Once authenticated, it issues an encrypted TGT, which remains cached on the user's system.

3.2 Accessing a Network Service

1. Session Ticket Request: When accessing a service, the user’s system requests a session ticket, presenting the TGT as proof of authentication.
2. Session Ticket Issuance: The TGS decrypts the TGT, validates it, and then issues a session ticket for the specific service.

3.3 Service Access

1. Service Request: With the session ticket, the user's system sends a service request to the desired server.
2. Service Provision: The server decrypts the session ticket, confirms its validity, and grants the requested service (Bryant, 2019).

The diagram above creates event ID 4771.

The beauty of Kerberos lies in the use of these encrypted tickets, ensuring secure authentication without repeatedly sending passwords over the network.

Authorization in AD

While Kerberos handles authentication, the authorization process (determining access levels) in AD is managed by Access Tokens and Access Control Lists (ACL). Once authenticated, a user is provided an Access Token containing their user rights and group memberships. When accessing a resource, the system checks the token against the resource's ACL to determine the user's access level (Lowe, 2020).

The Significance of Kerberos in AD

Kerberos offers several advantages:

• Security: By not transmitting passwords and using encrypted tickets, the chances of eavesdropping are minimized.
• Scalability: Kerberos is suitable for large organizations with complex network structures.
• Interoperability: Given its standardization, Kerberos integrates well with various systems.

However, it's crucial to manage and monitor Kerberos tickets for anomalies to prevent issues like the Golden Ticket Attack, wherein attackers forge Kerberos tickets (Medin, 2017).

Forging Tickets

Some time ago, Microsoft released a security patch that changed the way Kerberos tickets are created and validated. The update added new safeguards in the Kerberos Privileged Attribute Certificate (PAC) and improved the validations in the authentication process. Bye-bye golden tickets! Bye-bye golden tickets?

Let’s see how to forge tickets in 2023 with Impacket.

To understand the issue, please note that the vulnerabilities and the corresponding patch mentioned bellow are not new, so if you’re familiar with these things, you can go straight to what’s new.

In November 2021, Microsoft released the security patch KB5008380 – Authentication updates to address CVE-2021-42287 aka Kerberos Key Distribution Center (KDC) confusion. This is a security bypass vulnerability that affects the Kerberos PAC and together with CVE-2021–42278 (sAMAccountName spoofing) allow potential attackers to impersonate domain controllers. This attack is known as noPAC.

The following are some CVE related to the issue.

CVE-2021–42278/sAMAccountName spoofing

A normal user is allowed to add up to 10 Active Directory (AD) computer accounts objects by default and renamed them. These accounts should have a trailing $ in their name, but there was no validation in place to enforce it. So, a regular user could create a computer account a rename it to a name that doesn’t end with $.

CVE-2021-42287/Kerberos KDC confusion

With a valid Ticket Granting Ticket (TGT), a user can request a service ticket to access an AD resource. If the user account of the ticket is not found by the KDC, it automatically searches again with a trailing $.

The noPAC attack consists of chaining those two vulnerabilities. An attacker in possession of a normal user creates a computer account, then renames it to a Domain Controller’s name without the trailing $, and with this account, requests a TGT. After that, the attacker removes the computer account and, using the previous TGT, requests a service ticket abusing S4U2self.

The S4U2self extension allows a service to obtain a service ticket to itself on behalf of a user. The user is identified to the KDC using the user's name and realm. Alternatively, the user might be identified based on the user's certificate. The Kerberos ticket-granting service (TGS) exchange request and response messages, KRB_TGS_REQ and KRB_TGS_REP, are used along with one of two new data structures. The new PA-FOR-USER data structure is used when the user is identified to the KDC by the user name and realm name. The other structure, PA-S4U-X509-USER, is used when the user certificate is presented to the KDC to obtain the authorization information. By obtaining a service ticket to itself on behalf of the user, the service receives the user's authorization data in the ticket.

This defines the behavior of Kerberos. The KDC won’t find the user, so it will append a $ to the name (getting the Domain Controller’s name) and lookup again. As a result, a service ticket will be granted to the requesting user, making the regular user a domain admin.

Getting back to the security patch, Microsoft updated the PAC component adding two new data structures: PAC_ATTRIBUTES_INFO and PAC_REQUESTOR.

*The Privilege Attribute Certificate (PAC) is a component used in the Kerberos authentication protocol. The PAC stores additional authorization information about a user and is attached to the Kerberos ticket, providing details about the user’s group memberships, privileges, and other security-related attributes. *

The PAC_ATTRIBUTES_INFO structure contains supplemental information about the PAC. On the other hand, the PAC_REQUESTOR structure contains the SID of the client that requested the ticket. Both new structures are required for a ticket to be accepted.

The 2023 discovery

However, the most interesting part of the patch is the new validation introduced with PAC_REQUESTOR structure. The KDC validates the username (client name) of the ticket which resolves to the same SID that is included in that structure.

The security update was released in phases. In October 2022, the enforcement phase was put in place. That means that any ticket without the new PAC structure (or for a non-existent user) will be denied.

So what happened with Impacket? When we used ticketer.py to forge a golden ticket and tried to use it with any of our examples, we got:

[-] Kerberos SessionError: KDC_ERR_TGT_REVOKED(TGT has been revoked)

So, how to forge a ticket?

It’s simple. After getting the AES key (or NTHash) of the krbtgt account using secretsdump.py, and the domain SID (+ target user SID) using lookupsid.py, we can run ticketer.py with the following command:

ticketer.py -aesKey 7873... -domain-sid S-1-5-21-228... -domain mycorporation.com -user-id 1111 username

This action forges a ticket with the new PAC structures for username in the mycorporation domain. Since KB5008380, the username must exist in the domain and have a matching RID. You have to set the user-id option.

If you need to forge tickets with the old PAC structure, you can use the old-pac option as follow:

ticketer.py -nthash f450... -domain-sid S-1-5-21-295... -domain mycorporation.com -old-pac username

Conclusion

Kerberos is the backbone of authentication in the Microsoft Active Directory environment. Its use of encrypted tickets, combined with AD's authorization mechanisms, ensures that users can securely and efficiently access the resources they need.

Understanding the intricate workings of Kerberos equips IT professionals to better manage, troubleshoot, and secure their AD environments.

References:

Bryant, B. (2019). Active Directory: The Kerberos authentication journey. Journal of Network Security, 17(2), 34-40.

Desmond, B. (2018). Mastering Active Directory. Packt Publishing.

Lowe, S. (2020). Active Directory Domain Services 2020. TechTarget.

Forging Tickets in 2023 - 0xdeaddood. (2023). Retrieved 28 August 2023, from https://0xdeaddood.rocks/2023/05/11/forging-tickets-in-2023/