Golden Ticket attacks are the closest thing Active Directory has to a skeleton key. By stealing one account’s password hash, an attacker gains the ability to mint Kerberos tickets for any user, in any group, valid for as long as they like. Password resets do not stop it. Disabling the compromised account does not stop it. Deleting the account does not stop it.
For CISSP candidates the attack sits at the intersection of several Domain 5 themes: authentication protocol design, privileged account management, adversary persistence, and the uncomfortable managerial question of what you do when remediation itself takes the business offline.
This is the second article in the Kerberos attack chain series. If the six step Kerberos flow is not fresh, start with the Kerberos authentication guide, because a Golden Ticket is best understood as a short circuit in that flow.
What is a Golden Ticket attack?
A Golden Ticket attack forges Kerberos Ticket Granting Tickets using a compromised krbtgt account hash.
The krbtgt account is a built in Active Directory account that exists in every domain. It is disabled, nobody logs in with it, and most administrators never think about it. Its job is to be the service account for the Key Distribution Center itself: its password hash is the key used to encrypt and sign every TGT the domain issues. That makes it the master cryptographic key for the entire authentication system.
Key concept: the krbtgt account
Think of krbtgt as the plate that stamps every passport your country issues. Border control does not verify passports by phoning the passport office, it verifies them by checking the stamp. Steal the plate and you can issue passports for people who were never born, and every border in the country will wave them through. That is precisely the position an attacker holding the krbtgt hash is in.
Why “golden”?
The name reflects what these tickets are worth. A stolen user credential is fragile: the password can be changed, the account disabled, multi factor authentication added. A Golden Ticket is none of those things. It survives password resets, lockouts, and even deletion of the account it claims to be, because nothing in the ticket is checked against the live directory when it is validated.
Golden Tickets let an attacker impersonate any user, including Domain Admins, and grant themselves membership of any group at the moment of forgery. Attackers commonly set the lifetime to ten years. If the organisation never rotates the krbtgt password, that access remains live for as long as the domain exists, which is why this ranks among the most dangerous post exploitation techniques in enterprise security.
Prerequisites and attack path
The critical prerequisite: domain administrative access
Golden Tickets are a post exploitation technique. To extract the krbtgt hash an attacker must already hold domain administrator rights or the equivalent, because that hash lives on domain controllers and nowhere else.
This point matters more than any technical detail in this article. A Golden Ticket is not how an attacker gets in. It is what they do once they are in, to make sure they can get back in tomorrow.
CISSP Exam Note
Golden Ticket attacks require prior administrative compromise. Exam questions test whether you know they are a persistence mechanism rather than an initial access vector. The realistic chain runs phishing or exploitation first, then credential theft, then lateral movement, then privilege escalation to domain admin, and only then ticket forgery. If a scenario asks how the attacker gained their initial foothold, the answer is somewhere earlier in that chain.
Common paths to domain admin
Attackers reach domain admin along well documented routes. Phishing remains the most common opening move, particularly against people holding administrative rights. Once inside, credential theft tools harvest passwords and tokens from memory, and Kerberoasting yields service account passwords that often carry more privilege than they should. The attacker moves laterally from host to host until a domain admin credential appears.
Exploitation of unpatched systems provides another route, especially where domain controllers or privileged workstations have fallen behind on patching. DCSync deserves particular attention: using tools such as Mimikatz, an attacker holding directory replication permissions simply asks a domain controller to send them account password data, using the same mechanism domain controllers use with each other. Because the request is a legitimate protocol operation, it looks entirely normal to monitoring that is not specifically watching for it.
| Attack path | Description | Detection difficulty |
|---|---|---|
| Phishing | Harvesting credentials from privileged users | Medium |
| Lateral movement | Progressive privilege escalation across systems | Medium to high |
| Vulnerability exploitation | Exploiting unpatched systems to gain admin access | Variable |
| DCSync | Mimicking domain controller replication to extract password hashes | High |
How Golden Ticket attacks work
The attack runs as a systematic three step process that turns stolen cryptographic material into durable domain access.
Step 1: Information gathering
Before forging anything, the attacker collects four pieces of information. The domain’s fully qualified domain name identifies the target. The domain security identifier, or SID, is the unique fingerprint that all account SIDs in the domain are built from. The krbtgt NTLM hash is the cryptographic key that will make the ticket valid. Finally, they choose a username to impersonate.
Technical note
The impersonated identity does not have to exist. A Golden Ticket can name an account that was never created in Active Directory, because the ticket carries its own authorisation data and nothing validates that data against the directory. Security teams occasionally find authentication events for users who simply do not exist, which is one of the few unambiguous indicators of this attack.
Step 2: Ticket forgery
Forging the ticket gives the attacker complete editorial control over its contents. They can set any username, insert any group memberships they like, including Domain Admins, Enterprise Admins, and Schema Admins, and set a validity period of years rather than the normal 10 hours.
The ticket is then signed and encrypted with the stolen krbtgt hash. This is the heart of the problem: domain controllers validate TGTs with that same key, so there is no cryptographic test that can separate a forged ticket from a genuine one. The check the KDC performs is “does this decrypt correctly”, and a forged ticket passes it every time.
Step 3: Ticket injection and usage
The finished ticket is injected into the attacker’s own logon session, usually straight into memory. From that moment the attacker’s session holds what looks like a fully authenticated domain identity. They have skipped the Authentication Service exchange entirely: steps 1 and 2 of the normal flow never happened, so no domain controller ever verified a password.
What they have not skipped is the Ticket Granting Server. Unlike a Silver Ticket, which is presented directly to a service, a Golden Ticket is a TGT, and a TGT’s only use is to request service tickets. The attacker therefore presents the forged TGT to the TGS whenever they want to reach a resource. Because it is signed with the valid krbtgt key, the TGS issues service tickets without hesitation, and the attacker can reach any resource in the domain, create or modify accounts, and exfiltrate data at will.
Attack flow summary
- Gather: domain FQDN, domain SID, and the krbtgt hash
- Forge: build a TGT with a chosen identity, chosen group memberships, and an extended lifetime
- Inject: load the ticket into memory, skip the AS exchange, and request service tickets from the TGS
Detection challenges and indicators
Why detection is difficult
Forged tickets are cryptographically identical to legitimate ones because they are signed with the real krbtgt key. Every check the protocol performs passes. Nothing in the ticket is wrong in a way a cryptographic validation could notice.
Native Windows security logging then compounds the problem. It was designed to record events, not to reason about whether a sequence of events makes sense. Organisations generally need a SIEM platform or a dedicated Identity Threat Detection and Response (ITDR) tool to correlate authentication events across the environment well enough to notice the gap.
Critical detection challenge
A Golden Ticket does not eliminate KDC contact, it eliminates the logon half of it. Because the TGT was forged rather than issued, there is no Kerberos authentication ticket event (Windows Event ID 4768) for that session. The attacker still requests service tickets, so service ticket events (Event ID 4769) do appear. The signature of the attack is therefore an absence: resource access and service ticket requests for an identity that never logged on. Almost no organisation alerts on a missing event, which is exactly why this works.
Key detection indicators
Some warning signs are within reach even without specialised tooling.
Legitimate TGTs live for 10 hours by default. Golden Tickets frequently carry lifetimes of days, months, or years, so any TGT whose validity exceeds domain policy is a red flag. Authentication activity involving accounts absent from the directory, or dormant for months, deserves immediate attention.
Unusual privilege escalation is another. A standard user account suddenly exercising Domain Admin rights, with no corresponding group membership change recorded in the directory, cannot be explained legitimately. So are access patterns that violate physics: one identity reaching resources from two continents within minutes.
Advanced detection techniques
Reliable detection means going beyond the default logs.
| Detection technique | What it identifies |
|---|---|
| Ticket lifetime analysis | TGTs whose validity exceeds the domain’s configured 10 hour default |
| Behavioural analysis | Access patterns that deviate from an identity’s established baseline |
| Audit log correlation | Resource access with no corresponding authentication event |
| Network traffic analysis | Authentication flows that skip expected KDC exchanges |
| Directory reconciliation | Ticket identities and group claims that do not match Active Directory |
Best practice
Build continuous monitoring that correlates KDC authentication events with subsequent resource access. When an identity accesses resources without a matching TGT issuance event from a domain controller, treat that as an alert rather than a curiosity. This one correlation rule catches the attack that no cryptographic check ever will.
Mitigation and defence strategies
Immediate response: the krbtgt double reset
When a Golden Ticket attack is suspected, the krbtgt password must be reset twice, and the reason is worth understanding rather than memorising.
Kerberos keeps two krbtgt password versions, current and previous. This exists so that tickets issued moments before a routine rotation continue to validate rather than breaking every session in the domain. The consequence is that the first reset pushes the compromised hash from “current” to “previous”, where it remains perfectly usable by the attacker.
The second reset finally evicts it. But it must not follow immediately. You wait for the maximum ticket lifetime to elapse, typically 10 hours, so that legitimate tickets issued under the old key have expired naturally, and you confirm the first change has replicated to every domain controller in the domain. Reset twice in quick succession and you invalidate every ticket in the environment at once, which turns an incident into an outage.
CISSP Exam Note
The double reset is one of the most reliably examined facts in this topic. First reset invalidates use of the current hash. Second reset, performed after the maximum ticket lifetime and after replication has converged, invalidates the previous hash. Expect temporary authentication disruption, and plan the work through change management rather than improvising it.
Preventive controls
Everything that stops an attacker reaching domain admin also stops the Golden Ticket, so prevention is mostly about privilege. Least privilege limits the blast radius of any single compromise. Tiered administration is the structural version of the same idea: domain admin credentials are used only on domain controllers and never on workstations, so an attacker who owns a laptop cannot harvest a credential that unlocks the directory.
Regular Active Directory security audits find the misconfigurations that shorten the path to domain admin. Give particular attention to privileged group membership, delegation settings, service account rights, and anyone holding the directory replication permissions that make DCSync possible.
Advanced protection measures
Privileged Access Management (PAM) provides just in time administrative access with session recording, so a domain admin credential exists only during the minutes it is needed rather than sitting in a group permanently. Endpoint Detection and Response tools watch for the behaviour of credential extraction rather than for known tool signatures, which matters because attackers change tools constantly.
Identity Threat Detection and Response solutions focus specifically on identity attacks and are the category most likely to flag anomalous ticket behaviour. Zero Trust architecture helps differently: by continuously verifying identity and device posture rather than trusting anything simply because it presented a valid ticket, it reduces what a forged ticket actually buys.
Defence in depth
No single control stops this attack. Preventive controls keep the attacker away from domain admin, detective controls surface the attack in progress, and responsive controls contain and remediate it. A programme with only one of the three fails in a predictable way: prevention alone means you never find out, detection alone means you find out and cannot act.
Organisational controls
Technical measures need process behind them. Security awareness training reduces the phishing success rate that starts most of these chains. Tested incident response plans matter enormously here, because the krbtgt reset is a procedure nobody wants to be reading for the first time during an incident. Threat hunting suits a threat whose defining characteristic is that it generates no alert, and vendor security assessments close the third party routes into the environment.
Conclusion
Golden Ticket attacks exploit the trust every domain controller places in the krbtgt account to achieve persistent, unlimited domain access. They demonstrate a principle worth carrying into the exam: when authentication is anchored on a single shared secret, the security of the whole system collapses to the security of that one secret.
The controls that prevent this attack, tiered administration, least privilege, credential hygiene, and identity focused monitoring, improve Active Directory security broadly. The spend does not buy protection against one exotic technique, it buys a directory that is harder to own.
For the exam, focus on the prerequisites, the role of the krbtgt account, why cryptographic detection is impossible, and the double reset procedure with its timing requirement. Then think like a manager: what is the business impact, and which governance failure allowed the escalation in the first place?
Scenario questions on this topic rarely say “Golden Ticket”. They describe an intruder who keeps returning after every password reset, and ask what you do first. The LSM CISSP practice tests put you in exactly that position under exam pressure, which is where the difference between recognising a term and reasoning with it shows up.
Quick reference for the CISSP exam
Golden Ticket attacks forge Kerberos TGTs using a compromised krbtgt hash, granting domain wide access that bypasses the initial authentication exchange. They are a post exploitation persistence mechanism requiring prior domain admin compromise. The underlying protocol is covered in the Kerberos glossary entry.
Attack prerequisites
- Domain admin access: required to extract the krbtgt hash from a domain controller
- krbtgt hash: the master key that encrypts and signs every TGT in the domain
- Domain SID: the unique domain identifier the forged ticket must carry
- Domain FQDN: the fully qualified name of the target domain
Attack execution steps
- Information gathering: collect the domain FQDN, domain SID, and krbtgt hash
- Ticket forgery: build a TGT with a chosen identity, arbitrary group memberships, and an extended lifetime
- Ticket injection: load the forged TGT into memory, skip the AS exchange, request service tickets from the TGS
Detection indicators
- Abnormal TGT lifetime: tickets valid for days, months, or years instead of 10 hours
- Non existent identities: authentication activity for accounts absent from the directory
- Missing logon events: service ticket requests with no preceding TGT issuance
- Anomalous access: behaviour inconsistent with the identity’s established profile
Critical response: krbtgt reset
- Twice, not once: Kerberos retains the current and previous password versions
- Timing matters: perform the second reset after the maximum ticket lifetime, roughly 10 hours, and after replication has converged
- Business impact: expect temporary authentication disruption and manage it as a change
Exam tips
- Golden Tickets are persistence, not initial access
- Forged tickets are cryptographically indistinguishable from legitimate TGTs
- Standard Windows logging alone is insufficient for detection
- The double krbtgt reset is required because of password version history
- Golden Tickets still use the TGS, whereas Silver Tickets bypass the KDC completely
Exam focus: the executive risk perspective
Do not just memorise the attack. Manage the business impact.
The change management dilemma. Remediation causes authentication failures. A security manager weighs the certainty of operational downtime against the probability of continued data theft, judged against the organisation’s tolerance for outage, formally its recovery time objective. Do you declare an emergency change and disrupt the business, or schedule it and accept the exposure in the meantime?
A defensible security budget. Native logs are effectively blind to this attack. Use the scenario to justify identity threat detection tooling: you are not buying software, you are buying mean time to detect for a threat that generates no alert.
The root cause fallacy. If you are fighting a Golden Ticket, you have already lost the battle for domain admin. The managerial fix is not the password reset. It is the governance that prevents the privilege escalation which made the attack possible.