Detecting and Preventing the Path to a Golden Ticket With Cortex XDR

This post is also available in: 日本語 (Japanese)

Executive Summary

The “Golden Ticket” attack introduced by Benjamin Delpy has been giving defenders quite the hard time. The technique can be rather evasive due to its nature as a post-exploitation technique that can blend into daily network activities.

The attack allows an adversary to gain unconstrained access to all services and resources within an Active Directory (AD) domain using a forged Kerberos ticket known as the “Golden Ticket”.

In this blog post, we’ll briefly explain what Kerberos and a Golden Ticket are and an attacker's motivation for performing a Golden Ticket attack. Then we will present some existing methods for detecting the technique and their caveats. To finish, we will demonstrate two methods of “Golden Ticket” containment and creation and explain how customers can detect and prevent the methods leading to the “Golden Ticket” using Cortex XDR.

What is a Golden Ticket?

Kerberos Refresher

Kerberos is a network authentication protocol that is primarily used in Active Directory environments. It provides strong authentication by issuing tickets to authenticate users and allow access to services.

The tickets are distributed by the key distribution center (KDC). In most environments, the KDC is installed on the domain controller (DC).

During the initial authentication, a Ticket Granting Ticket (TGT) is a ticket assigned to a user. The TGT is later used to authenticate the user to the KDC and request a service ticket from the Ticket Granting Service (TGS). Service tickets are granted for authentication against services.

A Kerberos authentication would consist of the following steps:

1. The user requests (AS-REQ) a TGT from the KDC and the KDC verifies and validates the credentials and user information.
2. After authenticating the user, the KDC sends an encrypted TGT back to the requester (AS-REP).
3. The user presents the TGT to the DC and requests a TGS (TGS-REQ).
4. The TGS is encrypted and sent back to the requesting user (TGS-REP).
5. The user connects to the server hosting the service requested and presents the TGS (AP-REQ) in order to access the service.
6. The application server sends an (AP-REP) to the client.

Kerberos authentication - Image Source

Golden Ticket - Attacker Incentive

A Golden Ticket is a forged TGT that is generated without proper authentication and would seem “pre-authenticated”, using it as false proof that authentication was performed in order to request a TGS. Using this ticket will give an attacker access to resources or allow them to execute attacks without real authentication. For example, access to all computers, files and folders in the domain.

In order to understand why and how this is possible, we will understand what the KRBTGT account is.

Microsoft TechNet states:

“The KRBTGT account is a local default account that acts as a service account for the Key Distribution Center (KDC) service. This account cannot be deleted, and the account name cannot be changed. The KRBTGT account cannot be enabled in Active Directory.

KRBTGT is also the security principal name used by the KDC for a Windows Server domain, as specified by RFC 4120. The KRBTGT account is the entity for the KRBTGT security principal, and it is created automatically when a new domain is created.

Windows Server Kerberos authentication is achieved by the use of a special Kerberos ticket-granting ticket (TGT) enciphered with a symmetric key. This key is derived from the password of the server or service to which access is requested. The TGT password of the KRBTGT account is known only by the Kerberos service. In order to request a session ticket, the TGT must be presented to the KDC. The TGT is issued to the Kerberos client from the KDC.”

More plainly, the KRBTGT account encrypts and signs all the Kerberos TGT tickets for the domain. And all verification of Kerberos tickets, including encrypting and decrypting TGTs for the KDC service, is done by the KRBTGT. This means a forged TGT will be considered a valid ticket simply because it was encrypted with the KRBTGT account.

A Kerberos authentication with a “Golden Ticket” would look like this:

Kerberos authentication with a “Golden Ticket” no AS-REQ and AS-REP - Image Source

Needless to say, a Golden Ticket can be a prized goal for an attacker. With the gained Golden Ticket the offender has full access to all resources with high privileges throughout the domain.

What is Required to Perform a “Golden Ticket” Attack?

Once an attacker has a foothold on the network they can proceed with the Golden Ticket generation.

To generate a Golden Ticket, an attacker will need the following:

• The Fully Qualified Domain Name (FQDN) of the domain.
• The Security Identifier (SID) of the domain.
• The KRBTGT password hash.
• The username of the account they want to impersonate.

Presuming the attacker with a foothold on the network can easily find the FQDN, we will cover ways the attacker can obtain the KRBTGT password hash and the domain SID later on.

Existing Golden Ticket Detections - Caveats

There are several existing Golden Ticket detections out there, but they come with caveats due to the nature of the attack and the detection method limitations.

TGS Request Without a TGT Request

One detection proposed is to look for a TGS request event log (EID 4769) without a TGT request (EID 4768), but there are a number of caveats to this detection:

When dealing with big data it is very easy to lose some events or pieces of information in the analysis or monitoring process. In such cases, this logic can produce false positives and confuse or mislead security operations analysts.

Another issue can be that the TGT has a long lifetime before expiring and the detection might consider the time delta between the TGT request to the TGS request as an indicator for a “Golden Ticket”, causing a false positive.

When considering environments with multiple DCs, a user might request a TGT from one DC, and the TGS will be requested from another DC. For this possible flow, there might be monitoring on one of the DCs and not on the other which can lead to a possible TGS without TGT assumed case.

TGT tickets with an Arbitrary Lifetime, a Blank or Fake Domain, or Account Name

A different approach is to look for anomalies in the TGT itself, for example, an arbitrary lifetime or a forged domain or account name, thus indicating that it might be fake.

The main issue with these detections is that they rely on an attacker to make a mistake with the Golden Ticket. If the attacker is engaged in the attack, these detections will not help detect a Golden Ticket.

How Can Cortex XDR Help You Detect Golden Ticket Attacks?

Cortex XDR leverages multiple data sources, behavioral detections and behavioral analytics to detect the potential attack throughout its phases.

We will now show some examples of how an attacker can obtain and generate a Golden Ticket and see how Cortex XDR prevents and detects the various steps of the attack.

The examples were conducted while the agent is in report mode in order to see the full attack chain. In standard cases, the agent Behavioral Threat Protection (BTP) rules will prevent and block the attack phases.

Obtaining a Golden Ticket - Method 1: Local NTDS.dit dump

One method for an attacker to generate a Golden Ticket attack is by dumping the Active Directory database (NTDS.dit) and extracting the information needed for the generation.

This will be done by creating a shadow copy on the DC in order to obtain the NTDS.dit file. The file will be parsed to extract the KRBTGT hash and domain SID. Then Mimikatz can be used to generate the Golden Ticket.

This method requires access to an NTDS.dit file or access to the DC.

Breakdown:

The NTDS.dit file is the database that stores the Active Directory data, including information about groups, group memberships and user objects. It also includes the password hashes for all the users in the domain. Meaning, the KRBTGT hash is there as well.

In order to fetch the password hash of the KRBTGT account, an attacker will need a copy of the NTDS.dit file. But, copying the NTDS.dit file is not as simple as just copying the file. Since the database is constantly used by Active Directory it is locked and a standard copy cannot be performed.

One way to create a copy of the NTDS.dit is by making a Volume Shadow Copy. A shadow copy is a backup copy or snapshot of the computer volumes or files even while being in use. With that understanding, it is possible to create a NTDS.dit copy by leveraging the shadow copy mechanism. Microsoft has a built-in utility for making shadow copies named Volume Shadow Copy Service (VSS).

The attack will begin with the adversary making a shadow copy on the DC with VSS. Then, the attacker will retrieve an NTDS.dit copy from the shadow copy and additionally copy the SYSTEM registry hive.

The reason for copying the SYSTEM registry hive is that it contains the BootKey/SysKey. This BootKey is an encryption key that is used to encrypt sensitive information like the NTDS.dit, machine account passwords or system certificates, etc.

The attacker will use this BootKey to decrypt the NTDS.dit in order to read its contents.

Next, the offender will extract the KRBTGT data from the NTDS.dit copy.

After the KRBTGT and SID data are acquired, a Golden Ticket can be generated.

Attacker Flow

In order to follow this flow, we start with an attacker that has gained access to a DC and can create a shadow copy.

First, the attacker will need to create the shadow copy with VSS:

Creating a shadow copy with VSSAdmin

After the shadow copy is created, the NTDS.dit is retrieved:

Retrieving the NTDS.dit from the shadow copy

Then the SYSTEM registry hive needs to be copied:

Copying the SYSTEM registry hive

The attacker can delete their tracks of the shadow copy:

Deleting the tracks of making a shadow copy

Now the attacker will use the PowerShell module DSInternals to get the BootKey/Syskey from the saved SYSTEM registry hive:

Getting the BootKey from the SYSTEM registry hive copy

When getting the NTDS.dit from a shadow copy it will need a repair in most cases. So the attacker will repair the NTDS.dit with the esentutl utility:

Repairing the NTDS.dit from the shadow copy

After the repair, the KRBTGT data can be extracted from the NTDS.dit copy with DSInternals:

Extracting the KRBTGT data from the NTDS.dit repaired copy

The extracted KRBTGT data

With the KRBTGT and domain data, the attacker generates a “Golden Ticket” with Mimikatz:

Generating a Golden Ticket with mimikatz

The Golden Ticket generated

Cortex XDR Alerts and Insights

With Cortex XDR we can see several alerts and insights triggered by the different stages of the attack flow.

When creating Volume Shadow Copy and dumping the SYSTEM registry hive, Cortex XDR alerts and insights as follows:

Alerts regarding the creation of the Volume Shadow Copy and SYSTEM registry hive dump

We can see the causality chain of the dump:

Causality chain of dumping the SYSTEM registry hive

Additional BTP rules regarding the SYSTEM registry hive dump and NTDS.dit access (extraction from the shadow copy):

Save key HKLM\SYSTEM in a suspicious way - triggered by saving the SYSTEM hive

Suspicious access to NTDS.dit

The Identity Analytics Module provides the following insights regarding the execution of esentutl:

Rare process execution + Rare LOLBIN Process Execution - triggered by the esentutl NTDS.dit repair

For Mimikatz’s execution we have the following:

Various alerts for Mimikatz regarding the tool execution and Kerberos ticket injection

We can see the causality chain for Mimikatz’s Kerberos ticket injection:

Causality chain of Mimikatz’s ticket injection

Method 2: DCSync

Another method that an attacker can use in order to generate a Golden Ticket attack is by abusing the File Server Remote VSS (MS-FSRVP) with ShadowCoerce, and the Active Directory Certificate Services (ADCS) in order to obtain a DC machine account certificate. Once the abuser has the DC certificate, they can authenticate as the DC to perform a DCSync and get the KRBTGT data in order to create a Golden Ticket.

This method is an example of escalating privileges from a low privileged user to a Golden Ticket with full access to the domain resources.

Breakdown:

ShadowCoerce is a tool that abuses the MS-FSRVP RPC.

When using the methods of IsPathSupported and IsPathShadowCopied, a server running MS-FSRVP can be coerced to authenticate as the machine account against a certain host over the Server Message Block (SMB) protocol.

An attacker can set up a listener for SMB authentications using ntlmrelayx as a relay server. Once the SMB authentication is captured, the relay server will relay the authentication to the ADCS server in order to get a certificate for the coerced machine account.

* Learn more about ADCS authentication and abuse - Detecting Active Directory Certificate Services Abuse with Cortex XDR

Once the abuser has the machine account certificate, they can use the certificate to request a TGT from the DC. With the TGT, the attacker can authenticate as the highly privileged machine account with “Pass the Ticket”. These steps are done with Rubeus.

The premise is that the attacker will coerce a DC to authenticate to the relay server, thus allowing them to authenticate as the DC. While authenticated as a DC, the offender can perform a DCSync.

In short, a DCSync is a domain controller replication technique. Abusing it can allow an offender to pull password data and hashes including the KRBTGT hash.

Once the DCSync is executed, the offender can extract the KRBTGT hash and the SID of the domain. Combining these with the FQDN of the domain the offender can now create a Golden Ticket.

With said Golden Ticket, the attacker can now access all the resources in the domain.

Attacker Flow

In order to follow this flow, we start with an attacker that has gained access to a machine in the domain with ADCS, a MS-FSRVP server, and a relay machine.

First, the attacker will set up a relay server that will wait for SMB authentication, and will relay them to the ADCS server:

Setting up the relay server with ntlmrelayx

After the relay server is set and awaiting the authentication, the attacker will use ShadowCoerce to coerce the DC to authenticate against the relay server:

Abuse of MS-FSRVP relaying authentication to the relay server

The relay server relays the authentication to the ADCS server, and a certificate is obtained:

Relay server relayed authentication to ADCS for a certificate

With the certificate at hand, the abuser gets a TGT for the DC machine account with Rubeus using “Pass the Ticket”:

Getting a TGT for the DC machine account with Rubeus

The attacker has successfully managed to get a TGT for the DC’s machine account:

Rubeus successfully got a TGT for the DC machine account

Showing the obtained TGT with klist

Next, the attacker will use Mimikatz to perform a DCSync in order to get the KRBTGT hashes and the domain SID:

Performing a DCSync with mimikatz

Finally, a Golden Ticket can be generated using the domain FQDN, SID and the KRBTGT NTLM hash with “Pass the Ticket”:

Generating a Golden Ticket with mimikatz

Output of the successful Golden Ticket

The attacker now has access to the resources in the domain:

Access to the Domain Controller’s C drive

Cortex XDR Alerts and Insights

With Cortex XDR we can see several alerts and insights triggered by the different stages of the attack flow.

When executing ShadowCoerce, Cortex XDR alerts and insights as follows:

Rare signature signed executable executed on the network - triggered by ShadowCoerce execution via CMD

Suspicious usage of File Server Remote VSS Protocol (FSRVP) - triggered by ShadowCoerce abuse

We can see the causality chain of the FSRVP abuse on the victim server:

Causality chain of the FSRVP abuse with ShadowCoerce

Additionally, the following alerts trigger regarding the SMB traffic from ShadowCoerce and the coerced SMB authentication to the relay server:

SMB Traffic from Non-Standard Process - triggered by ShadowCoerce

Causality chain of SMB Traffic from Non-Standard Process

Suspicious SMB connection from domain controller - triggered by the coerced authentication

Causality chain of Suspicious SMB connection from domain controller

The Rubeus execution triggered the following alerts and BTP prevention rules:

Various alerts for Rubeus regarding the tool execution and Kerberos interactions

The Identity Analytics Module provides the following insights regarding the execution of Rubeus and klist:

Rare process execution by user and in the organization - triggered by Rubeus an klist execution

Because a TGT for the DC machine account was requested on a machine that is not the DC, the following alert fires:

TGT request with a spoofed sAMAccountName - Event log - triggered by TGT request for the DC’s machine account

As for Mimikatz's execution, we have:

Various alerts for Mimikatz regarding the tool execution

Additionally an Identity Analytics Module insight was triggered:

Rare process execution by user - triggered by Mimikatz

We can see the causality chain for both the Rubeus ticket injection and Mimikatz’s execution:

Causality chain of Rubeus ticket injection and Mimikatz’s execution

Lastly, DCSync is blocked by a BTP rule:

DCSync alert

Conclusion

The Golden Ticket attack gives an adversary unrestricted access to all resources in the domain.

Our recommendation is to create a security policy that limits access paths to the DC, implementing a least privilege model.

In addition, deploying a security platform such as Cortex XDR will provide an additional layer of protection and visibility to the various stages of the attack.

Want to learn more about Cortex XDR? Visit the Cortex XDR webpage or read the Essential Guide to XDR.