TRR0013: Forge a Kerberos TGT (Golden Ticket)

2024/01/14

Metadata

KeyValue
IDTRR0013
External IDsT1558.001
TacticsCredential Access
PlatformsActive Directory
ContributorsAndrew VanVleet, Chris Hodson

Technique Overview

Adversaries who have the KRBTGT account password hash may forge Kerberos ticket granting tickets (TGTs) for any user in the domain. This is referred to as a “Golden Ticket” attack because the attacker can gain access to any resource in the domain, regardless of password changes, so long as the KRBTGT password remains unchanged.

Technical Background

The Kerberos Protocol

Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications by using symmetric key cryptography to sign ’tickets’ that a client can use to prove their identity and authorization to access a network resource. The Kerberos protocol consists of 3 components (hence the name, which references the 3-headed dog of Greek mythology):

The client is the user who wants access to a network resource. The AS is the server hosting the desired resource. The KDC is the authoritative source of information about users and what resources they are authorized to access. In Active Directory domains, the domain controllers are also the Kerberos KDC.

Kerberos is stateless: it relies on cryptographically signed tickets to validate the identity of clients and their authorization to access resources. Tickets are encrypted with the password hash of the account intended to use them. This requires that the cryptographic private keys are known only by the key’s owner and the KDC.

Kerberos uses 2 different ticket types:

In the Active Directory implementation of Kerberos, the KDC’s private key is the password hash of a special service account that represents the KDC in the directory. This account is created automatically when the domain is created and is named “KRBTGT.” A foundational assumption of Kerberos is that no one knows the KRBTGT password except the KDC, and thus any tickets that have been signed by the KDC’s key must have been generated previously by the KDC itself.

Kerberos Messages in Detail

The Kerberos protocol defines a series of messages exchanged between the client, the KDC, and AS. The Kerberos protocol was originally designed in the 1980’s and is on version 5. It is employed in use cases far beyond what was originally envisioned and has had dozens of extensions added to it to enable those use cases. As a result, it is a very complex protocol. What follows is a simplified summary; more detailed descriptions are available online.123

Diagram of the Kerberos protocol

  1. AS-REQ: The client authenticates to the KDC’s Authentication Server with a username and password. By default in a Windows domain, pre-authentication data is also included in the form of a current timestamp encrypted with the user’s secret key (derived from the windows password).
  2. AS-REP: The KDC validates the client’s credentials, then sends back a TGT. The TGT contains the PAC, which includes the symmetric user session key that is used in subsequent steps to encrypt communications with the KDC. The TGT also contains the username that it was issued for and an expiration timestamp. Note that the client cannot read the encrypted portions of the TGT because it does not know have the KDC’s encryption key. The AS-REP also contains the session key and expiration time encrypted with the user’s hash, which the client can read. At this point, the client has a session key that it decrypted using the user’s secret key and the TGT (which contains the same session key, encrypted with the KDC’s secret key).  In the image below, you can see an AS-REP message, with the TGT (the ticket section), PAC (the ticket->enc-part section), and data encrypted with the user’s key (the enc-part section).

Image of Kerberos TGT in Wireshark

  1. TGS-REQ: When the client wants access to a specific resource, it presents the TGT to the KDC’s Ticket Granting Service (TGS) in a message that also contains the SPN of the service it wants to access. The request is encrypted using the user’s session key, obtained from the AS-REP message earlier.
  2. TGS-REP: The KDC opens the TGT and validates the PAC checksum. If successful, it proceeds to create a service ticket that contains the PAC. A symmetric key is generated for use between the client and the requested service (the service session key). The service ticket is encrypted with the service’s password hash. The service ticket and the service session key are encrypted a second time using the user’s session key and sent to the client.
  3. AP-REQ: Client decrypts the service ticket and service session key from the TGS-REP message and sends the service ticket to the server hosting the desired resource. The client also includes an authenticator message generated by the client and encrypted with the service session key..
  4. The AS decrypts the service ticket (using its own password hash) and extract the service session key. It then decrypts the authenticator using the service session key. The AS extracts the PAC from the service ticket and grants the client access to the resource.
  5. AP-REP (optional): If mutual authentication is needed, it can send back an optional AP-REP message.
  6. PAC Validation: If the TGT is older than 20 minutes, the AP will send a PAC Validation message to the KDC to verify that the PAC’s information is valid.

The Privileged Attribute Certificate (PAC)

The Kerberos protocol is one of the most commonly used authentication mechanisms. However, the Kerberos protocol does not define any explicit group membership or logon policy information to be carried in the Kerberos tickets; applications are expected to manage their own authorization. Kerberos extensions provide a mechanism to convey authorization information by encapsulating this information within an AuthorizationData structure. The Privileged Attribute Certificate (PAC) was created to provide this authorization data for Active Directory domains.

Active Directory’s implementation of Kerberos always includes a PAC. This is included in the TGT and is signed with the KDC’s encryption key (again, derived from the KRBTGT password hash). The PAC contains the session key and information about the user’s privileges in the domain. PAC validation is generally performed by checking the signature instead of inspecting if the attributes are correct (because Kerberos assumes that only the KDC knows the key).

Here is an example of a decoded TGT.

Decoding unencrypted data in credential[0]['ticket']:
[*] Service Name : krbtgt/AD.SOSTUP.ID
[*] Service Realm : AD.SOSTUP.ID
[*] Encryption type : aes256_cts_hmac_sha1_96 (etype 18)
    ---begin PAC data---
[*] Decoding credential[0]['ticket']['enc-part']:
[*] LoginInfo
[*] Logon Time : 21/08/2024 17:31:23 PM
[*] Logoff Time : Infinity (absolute time)
[*] Kickoff Time : Infinity (absolute time)
[*] Password Last Set : 15/07/2024 20:27:57 PM
[*] Password Can Change : 16/07/2024 20:27:57 PM
[*] Password Must Change : Infinity (absolute time)
[*] LastSuccessfulILogon : Infinity (absolute time)
[*] LastFailedILogon : Infinity (absolute time)
[*] FailedILogonCount : 0
[*] Account Name : slacker
[*] Full Name : slacker
[*] Logon Script :
[*] Profile Path :
[*] Home Dir :
[*] Dir Drive :
[*] Logon Count : 1222
[*] Bad Password Count : 0
[*] User RID : 1104
[*] Group RID : 513
[*] Group Count : 4
[*] Groups : 512, 1112, 513, 518
[*] Groups (decoded) : (512) Domain Admins
[*] (513) Domain Users
[*] (518) Schema Admins
[*] +1 Unknown custom group
[*] User Flags : (32) LOGON_EXTRA_SIDS
[*] User Session Key : 00000000000000000000000000000000
[*] Logon Server : DC01
[*] Logon Domain Name : ad
[*] Logon Domain SID : S-1-5-21-338595573-2398786023-2841481039
[*] User Account Control : (528) USER_NORMAL_ACCOUNT, USER_DONT_EXPIRE_PASSWORD
[*] Extra SID Count : 1
[*] Extra SIDs : S-1-18-1 Authentication authority asserted identity (SE_GROUP_MANDATORY, SE_GROUP_ENABLED_BY_DEFAULT, SE_GROUP_ENABLED)
[*] Resource Group Domain SID :
[*] Resource Group Count : 0
[*] Resource Group Ids :
[*] LMKey : 0000000000000000
[*] SubAuthStatus : 0
[*] Reserved3 : 0
[*] ServerChecksum
[*] Signature Type : hmac_sha1_96_aes256
[*] Signature : 90dba4e477076822eb654182
[*] KDCChecksum
[*] Signature Type : hmac_sha1_96_aes256
[*] Signature : aa1cc0659f9a235eef56ce78
[*] ClientName
[*] Client Id : 21/08/2024 17:31:23 PM
[*] Client Name : slacker
[*] UpnDns
[*] Flags : (2) S_SidSamSupplied
[*] UPN : slacker@ad.sostup.id
[*] DNS Domain Name : AD.SOSTUP.ID
[*] SamAccountName : slacker
[*] UserSid : S-1-5-21-338595573-2398786023-2841481039-1104
[*] Attributes Info
[*] Flags : (1) PAC_WAS_REQUESTED
[*] Requestor Info
[*] UserSid : S-1-5-21-338595573-2398786023-2841481039-1104

Forging the TGT and Detecting Forgeries

If an attacker can gain access to the password hash of the KRBTGT account, they can use it to forge and sign TGTs for any user in the domain. Instead of requesting a TGT from the KDC, the attacker presents a forged TGT in the request for a service ticket.

Diagram of Kerberos protocol with TGT request missing

Remember that the information in the PAC is not validated unless the TGT is older than 20 minutes, so an attacker can make any claims they want, even if they are not in accordance with domain policies and configuration. For example, an attacker can forge a TGT for any user in the domain, claim any user is part of the Domain Admins group or set the expiration date of the TGT far into the future.

Logging

There are a handful of Windows events logged during the Kerberos authentication and authorization process. These are:

Additionally, the Kerberos protocol is mostly unencrypted, except for the tickets, authenticators, and other sensitive details that employ message and field level encryption. This makes it possible to identify specific messages on the network, though the most important details are found in the encrypted portions.

Finally, CrowdStrike IDP generates an ActiveDirectoryServiceAccessRequest event when a TGT is submitted to request a service ticket.

Procedures

IDTitleTactic
TRR0013.AD.AForge a TGT using the KRBTGT password hashCredential Access

Procedure A: Forge a TGT using the KRBTGT password hash

There is only one known procedure for this technique. If an attacker is careful to forge a ticket with all the details in a legitimate TGT issued by the domain’s KDC, a Golden Ticket attack is likely impossible to detect. An attacker can use a tool like Impacket’s getPAC.py to inspect a legitimate TGT in the domain and ensure their forgery matches it.

Detection Data Model

DDM - TRR0013.AD.A

In the DDM above, the TGT request is included in gray circles, showing the process that normally would occur but is skipped in a Golden Ticket attack.

The best opportunities for detecting Golden Tickets depend on adversaries making mistakes when forging their TGTs that distinguish the forgery from real KDC-issued TGTs.

For example, Rubeus (an open source tool for attacking Active Directory) generates a TGT that does not include a timestamp for the last time a user’s password was reset or information on which specific server issued the TGT. These fields are not necessary for access to a resource and not validated by the AS, but they are always included in a legitimate TGT issued by a true KDC.

Snippet of a default Rubeus-generated TGT:

[*] LoginInfo
[*] Logon Time : 20/08/2024 13:36:23 PM
[*]Logoff Time : Infinity (absolute time)
[*] Kickoff Time : Infinity (absolute time)
[*] Password Last Set : Infinity (absolute time)
[*] Password Can Change : Infinity (absolute time)
[*] Password Must Change : Infinity (absolute time)
[*] Account Name : slacker
[*] User RID : 1104
[*] Group RID : 513
[*] Group Count : 1
[*] Groups : 512
[*] Groups (decoded) : (512) Domain Admins
[*] Logon Server :
[*] Logon Domain Name : AD

Other indicators that a TGT might be forged include:

Available Emulation Tests

IDLink
TRR0013.AD.AAtomic Tests 1-2

References

  1. Kerberos and Windows Security - Robert Broeckelmann ↩︎

  2. Kerberos Wireshark Captures - Robert Broeckelmann ↩︎

  3. Designing an Authentication System - MIT.edu ↩︎