Fighting Golden Ticket Attacks with Privileged Attribute Certificate (PAC)

For the past several years, as part of security assessments and live attack scenarios, operators have attempted to pull off the well-known, but difficult-to-execute, Golden Ticket attack.

Malicious actors achieve this task by bypassing the Kerberos key distribution center (KDC) and impersonating a domain controller account (KRBTGT) to fabricate new ticket-granting tickets (TGTs) for the entire Active Directory, offline.

Later, the impersonated TGT is presented to the key distribution center (KDC) to obtain a service ticket with forged high privileges. While patch CVE-2021-42287 attempts to address Golden Ticket Attacks, attackers may still impersonate a user if they use its corresponding SID. The impersonated user privileges are non-relevant and its group membership can be forged.

Enter PAC guardrails

Authentication updates - KB5008380 patch was presented to address this vulnerability. The updates, which were made available in November 2021 and will be enforced from October 2022, intend to provide additional safeguards in the Kerberos privileged attribute certificate (PAC) with additional information about the account that requested the TGT.

In this post, we're going to talk in-depth about what PAC is, the updated PAC and how it is designed to improve the authentication process, why it's not a perfect solution, and how the enforcement will influence ticket impersonation and its detection.

What is a privileged attribute certificate?

The PAC data is responsible for user authorization. It contains permissions to access different services. The PAC data is copied from one ticket to another through the Kerberos authentication and authorization flow.

When a user first successfully authenticates to the key distribution center (AS_REQ), the user receives in response (AS_REP) a TGT containing encrypted PAC data of the user (steps one and two in the diagram below). The PAC in the TGT, contains the authorization data — a list of user memberships.

Later, when the user requests TGS to access specific services (TGS_REQ), the PAC is copied as-is from the TGT to the TGS (steps three and four below). When The TGS is used for access (AP_REQ), the service checks the PAC to validate the user's access permissions (step five).

Figure 1: PAC data in the Kerberos flow

PAC authorization data resides in “KERB_VALIDATION_INFO” structure, under “GroupIds” property. PAC data is copied along the flow from the TGT to the TGS ticket to be used to access the desired service.

The update presents a new data structure in PAC containing the user security identifier (SID). The SID is validated by the KDC (step three in the diagram above). The username (“cname”) from the ticket is resolved to SID and compared with the new PAC_REQUESTOR value:

Figure 3: Decrypted PAC_REQUESTOR from PAC of a domain user

PACRequestorEnforcement: release phases and events

The PAC update is divided into three phases: initial deployment, second deployment, and enforcement.

According to Microsoft's documentation, the Active Directory environment state can be controlled with the PACRequestorEnforcement registry key to modify the desired PAC validation behavior. Security-conscious system administrators can now enable this, allowing them to better time the rollout.

Dividing the update into three phases means organizations will have enough time to understand the implications of the changes made. Once the new PAC is enforced, every account in the organization will need to re-authenticate, rendering the old Kerberos tickets useless, which can cause disruptions in production environments.

Along with the PAC validation updates, new system events are also available. The events found to be indicative of ticket-based attacks are events related to the PAC Requestor new field:

/newPAC or /oldPAC?

Following this security update, offensive tools have also been updated to support both new and old PAC structures in forged tickets.

Figure 4: Mimikatz — Pull request, supporting new PAC structure by default

However, forging TGT with new PAC but the default user SID, or using the old PAC in updated environment, will trigger the corresponding new events once the forged TGT is used.

PAC_REQUESTOR in practice

The new structure PAC_REQUESTOR is included in the new TGT PAC, and its value validated in the KDC on TGS request. What does it mean for Golden Ticket attacks and what can be detected by the new events?

“Ticket without requestor” — a TGT without the new PAC_REQUESTOR structure used.

In a deployment environment, this event might be an indicator of a successful attack because new PAC structure is not mandatory. Once the user is authenticated by the domain controller in deployment mode for the first time, a TGT is granted using the new updated PAC containing the requestor structure. Therefore, “ticket without requestor” events should be identified as a first indication of a possibly forged TGT. The event contains the impersonated user, but unfortunately not the source client host:

In an enforcement environment, the event indicates a failed attempt to use a TGT with an old PAC, after which the TGT will be revoked. An adversary may then try creating a TGT using the /newPAC and carry out successful Golden Ticket attack. Therefore, monitoring further user activity and TGS events (4769) is highly recommended.

“Requestor mismatch” — User SID does not match the username in TGT.

The new PAC_REQUESTOR data structure contains the user SID. When the TGT is presented to the KDC in the TGS request (KRB_TGS_REQ), the KDC performs validation where the user SID in the PAC_REQUESTOR must correspond to the cname in the TGS request. If they differ, the system event 38 “requestor mismatch” is flagged.

Both in deployment and enforcement environments, when a TGT with a new PAC is used to issue a TGS, the user ID will be validated. Traditionally, forging a TGT without explicitly mentioning the user ID results in a default of “500” (a user account for the system administrator).

Using this ticket causes a “request mismatch” event, and the TGT is revoked. Using the correct corresponding user ID, with forged high-privilege GroupIds membership leads to successful Golden Ticket attack. Although the impersonated user may not be a member of the mentioned groups, this information is not validated.

In the following comparison, we can see the original users PAC compared to PAC with SID mismatch and PAC with corresponding SID:

Click image to expand

All possible scenarios:

The good news:

A “Golden Ticket attack” using an unknown user is no longer possible in deployment/enforcement environments with usernames that do not exist in the domain. In both deployment and enforcement environments, using either new or old PAC will end up with a revoked TGT once TGS is requested. Neither “ticket without requestor” nor “requestor mismatch” events are triggered in this case.

Moving forward to enforcement will also prevent successful use of forged TGT without the new PAC structures.

To summarize, although the PAC Kerberos security update cannot fully prevent a Golden Ticket attack, the new events leave meaningful indicators of compromise to help Varonis customers identify the attempted attack.