What is it?
A Golden Ticket is a forged Kerberos TGT created with the KRBTGT account’s secret. Domain controllers trust tickets signed with that key, allowing an attacker to invent identities, group memberships, and long-lived domain access.
How it works in plain English
Use this three-part model to understand the attack without memorizing a tool name.
The system accepts a credential, token, ticket, recovery decision, or identity assertion as proof of who the requester is.
The attacker obtains, guesses, forges, replays, or changes that authentication material.
Focus on how the identity was acquired, where it was used, what device and network context changed, and what happened immediately after success.
Worked example: how the sequence may look
The KRBTGT hash or Kerberos key material.
Construct a forged TGT with chosen authorization data.
4769 requests with unusual accounts, hosts, lifetimes, or encryption.
Detect privileged Kerberos use from devices where those accounts never log on.
If successful, the attacker may continue with Pass-the-Ticket. This is a possibility, not a guaranteed next step.
This is a defensive learning scenario. Real incidents vary, and the listed outcome is only one possible path.
Why do attackers use it?
Maintain durable domain-level persistence.
Impersonate almost any domain identity.
Request service tickets throughout the domain.
Regain access after individual passwords change.
Prerequisites
The KRBTGT hash or Kerberos key material.
Domain name, SID, and related identifiers.
Domain-level compromise or equivalent access.
Connectivity to domain controllers and target services.
Attack path possibilities
Attack chains are not fixed. These links show common possibilities to investigate before and after this behavior.
A stolen Kerberos ticket is reused to access resources without the account password.
T1098 Account ManipulationExisting accounts are altered to preserve or increase access.
T1021 Remote ServicesRDP, SMB, SSH, WinRM, VNC, or similar services are used to access remote systems.
T1486 RansomwareFiles or systems are encrypted or disrupted for extortion.
Step-by-step attack flow
Gain highly privileged Active Directory access.
Extract the KRBTGT secret and domain identifiers.
Construct a forged TGT with chosen authorization data.
Use it to request service tickets.
Access domain resources without normal password validation.
Persist until KRBTGT is correctly rotated and the original compromise removed.
MITRE ATT&CK mapping
ATT&CK is updated over time. Verify the live technique before operationalizing a detection.
Logs and artifacts
4769 requests with unusual accounts, hosts, lifetimes, or encryption.
4624 logons with inconsistent account, SID, groups, or source device.
Privileged service access without normal TGT observations.
Directory replication or credential-dumping activity preceding use.
Realistic log examples
These records use realistic field names and formats but synthetic organizations, users, addresses, and identifiers. A single event is not proof; correlate time, identity, source, target, and the resulting action.
Kerberos service-ticket request; useful for roasting, ticket abuse, and unusual service access.
2026-07-16T14:25:10Z EventID=4769 Computer=DC01.corp.example
TargetUserName=analyst@CORP.EXAMPLE ServiceName=MSSQLSvc/sql01.corp.example:1433
IpAddress=10.24.18.77 IpPort=53110 TicketEncryptionType=0x17
TicketOptions=0x40810000 Status=0x0 TransmittedServices=-Detect privileged Kerberos use from devices where those accounts never log on.
Cloud sign-in context including identity, application, source, result, device, and conditional access.
2026-07-16T14:24:51Z UserPrincipalName=j.singh@corp.example
AppDisplayName="Office 365 Exchange Online" IPAddress=203.0.113.48
ResultType=50126 ResultDescription="Invalid username or password"
ClientAppUsed=Browser ConditionalAccessStatus=notApplied
DeviceDetail.operatingSystem=Windows Location=SGCorrelate service-ticket requests with TGT issuance and identity inventory.
Failed authentication; useful for guessing, spraying, exposed remote services, and account targeting.
2026-07-16T14:22:31Z EventID=4625 Computer=DC01.corp.example
TargetUserName=j.singh TargetDomainName=CORP LogonType=3
AuthenticationPackageName=NTLM WorkstationName=WKSTN-442
IpAddress=203.0.113.48 IpPort=51842
Status=0xC000006D SubStatus=0xC000006A FailureReason="Unknown user name or bad password"Find impossible username, RID, group, domain, and source combinations.
- Who or what identity acted?
- From which device, process, IP, or workload?
- What target and operation were involved?
- Did it fail, succeed, or change state?
- What correlated event happened immediately before and after?
Detection logic / SIEM queries
Detect privileged Kerberos use from devices where those accounts never log on.
Correlate service-ticket requests with TGT issuance and identity inventory.
Find impossible username, RID, group, domain, and source combinations.
Prioritize evidence of KRBTGT theft or unauthorized directory replication.
let tgt = SecurityEvent
| where EventID == 4768
| project Account, IpAddress, TgtTime=TimeGenerated;
SecurityEvent
| where EventID == 4769
| join kind=leftouter tgt on Account, IpAddress
| where isempty(TgtTime) or TimeGenerated - TgtTime > 10h
| project TimeGenerated, Account, IpAddress, ServiceNameMitigations
Treat KRBTGT exposure as a domain-compromise incident.
Remove attacker access and persistence before key rotation.
Reset KRBTGT twice, allowing replication between resets.
Use tiered administration and protected privileged identities.
Monitor and restrict directory replication rights.
Real-world examples
Advanced actors and post-exploitation frameworks use Golden Tickets after domain compromise.
Ordinary user password resets do not change the KRBTGT key.
Empire and Mimikatz include related Golden Ticket capabilities.
Common questions
01Why reset KRBTGT twice?
Active Directory retains current and previous KRBTGT keys; two coordinated resets retire both.
02Is it an initial-access attack?
No. Obtaining KRBTGT normally means the attacker already has domain-level privilege.