What is a golden ticket attack? It is a Kerberos-based technique in which an adversary who has stolen the password hash of a domain's krbtgt service account forges Ticket Granting Tickets (TGTs) for Active Directory, effectively minting unlimited, self-issued proof of identity for any user, including Domain Admins, without ever touching a domain controller's authentication logic. Because the krbtgt account signs and encrypts every TGT in the domain, whoever holds its hash can build tickets offline, set arbitrary group memberships and expiration dates, and present them as fully legitimate credentials. First publicized by security researcher Benjamin Delpy through the Mimikatz tool, the golden ticket attack remains one of the most dangerous Active Directory attack techniques because it survives password resets for ordinary accounts and grants persistence that can last, by default, up to ten years. Understanding how it differs from related Kerberos abuse like silver tickets is essential for any organization defending a Windows domain.
What Is a Golden Ticket Attack?
A golden ticket attack is the forgery of a Kerberos TGT using the krbtgt account's secret key, allowing an attacker to impersonate any user in an Active Directory domain indefinitely. In a normal Kerberos exchange, a user authenticates once to the Key Distribution Center (KDC), receives a TGT, and uses that TGT to request service tickets for specific resources without re-entering credentials. The TGT itself is only trustworthy because it is encrypted and signed with the krbtgt account's hash, a secret known only to the domain controllers. When an attacker extracts that hash, typically via a DCSync attack, a compromised domain controller, or a memory dump using Mimikatz, they no longer need to authenticate at all. They construct a TGT from scratch, specifying whatever username, Security Identifier (SID), and group memberships they want, sign it with the stolen krbtgt hash, and present it to any service on the network. The domain controller has no way to distinguish this forged ticket from one it legitimately issued, because the cryptographic signature checks out.
How Does Kerberos Authentication Normally Work, and Where Does It Break Down?
Kerberos normally works by having the KDC vouch for a user's identity once, then letting that vouching (the TGT) be reused to obtain access to many services without repeated password checks — and it breaks down the moment the vouching key itself is stolen. This is the core of Kerberos golden ticket explained in plain terms: Kerberos was designed around the assumption that the krbtgt secret is unreachable by attackers, so the protocol places enormous, almost unconditional trust in any ticket that key can validate. There is no secondary check against a live database of "tickets we actually issued." A domain controller receiving a service ticket request simply verifies the TGT's signature and, if it validates, honors whatever claims are embedded inside — including a SID History field that can claim membership in the Enterprise Admins or Domain Admins group. This design decision, reasonable when the krbtgt hash is properly protected, becomes catastrophic once that single secret leaks, because it converts one credential theft into unlimited, unauditable impersonation.
Why Is the Krbtgt Account the Crown Jewel of Active Directory?
The krbtgt account is the crown jewel of Active Directory because its password hash is the single cryptographic root of trust for every Kerberos ticket issued in the domain, making krbtgt hash compromise equivalent to owning the domain permanently. Unlike a regular user or even a Domain Admin account, krbtgt is disabled for interactive logon and rarely rotated — many organizations have never changed its password since the domain was created, sometimes a decade or more earlier. Attackers typically obtain the hash through a DCSync operation, which abuses legitimate Active Directory replication permissions (Replicating Directory Changes and Replicating Directory Changes All) to request the krbtgt secret from a domain controller as though the attacker's machine were another DC. Because DCSync looks like normal replication traffic to many monitoring tools, it frequently goes unnoticed. Once the hash is exfiltrated, remediation is unusually painful: Microsoft recommends resetting the krbtgt password twice, with a delay between resets equal to the maximum Kerberos ticket lifetime, or attackers who cached the old hash can simply keep forging tickets against it.
What's the Difference Between a Silver Ticket and a Golden Ticket?
The core difference in the silver ticket vs golden ticket comparison is scope: a golden ticket forges the domain-wide TGT using the krbtgt hash, while a silver ticket forges a narrower service ticket (TGS) using the password hash of a specific service account, granting access only to that one service. A silver ticket built against a SQL Server service account's hash, for example, lets an attacker impersonate any user against that SQL instance, but it won't grant access to file shares, other servers, or domain controllers the way a golden ticket does. Silver tickets are also stealthier in one important respect: because they never touch the KDC to request a service ticket, they leave no corresponding Event ID 4769 (TGS request) log on the domain controller, whereas golden ticket usage typically does generate DC-side logs once the forged TGT is used to request service access, just for services and users that may not otherwise make sense together. In practice, red teams and real attackers use both: silver tickets for quiet, targeted access to a specific system, and golden tickets when they want durable, domain-wide control.
How Do Attackers Actually Execute a Golden Ticket Attack in Active Directory?
Attackers execute a golden ticket attack in four fairly mechanical steps: gain sufficient privilege to read the krbtgt hash, extract that hash, forge a TGT offline with a tool like Mimikatz or Impacket's ticketer.py, and inject the forged ticket into a session to access domain resources. The privilege escalation step usually arrives well before the ticket forging — an attacker needs Domain Admin rights, direct access to a domain controller's memory or NTDS.dit database, or DCSync-equivalent replication rights, meaning the golden ticket is almost always a persistence and lateral-movement technique used after an initial compromise, not the initial breach itself. This pattern shows up repeatedly in ransomware incident response: Mandiant, CrowdStrike, and other IR firms have documented Ryuk, Conti, and other affiliate operators dumping the krbtgt hash within hours of reaching Domain Admin, specifically so they retain the ability to regenerate valid credentials even after the victim organization resets passwords and rebuilds affected servers. That is what makes the golden ticket such an effective Active Directory attack technique for ransomware crews — it decouples "we still have access" from "we still know a working password," letting attackers reappear on a network weeks after what defenders believed was full eradication.
What Are the Warning Signs of a Golden Ticket Attack?
The warning signs of a golden ticket attack center on tickets and account behavior that don't match how the domain actually operates: TGTs with unusually long lifetimes, tickets encrypted with RC4 (etype 0x17) in an environment standardized on AES, service ticket requests for usernames that don't exist in Active Directory, and SID History entries referencing privileged groups the account was never actually added to through normal provisioning. Because forged tickets can name arbitrary usernames, defenders sometimes see TGS requests (Event ID 4769) for accounts that were deleted years earlier or that never existed at all — a strong indicator that the corresponding TGT was fabricated rather than issued. Tools like Microsoft Defender for Identity and other AD-aware detection platforms specifically watch for these anomalies, along with abnormal replication requests that suggest DCSync activity preceding the theft. Because prevention after the fact is difficult, the more durable defenses are structural: rotating the krbtgt password on a regular schedule (not just after a confirmed incident), tightly restricting replication permissions, enabling PAM/tiered administration models, and minimizing standing Domain Admin membership so there are fewer paths to the krbtgt hash in the first place.
How Safeguard Helps
Safeguard helps by closing the identity and infrastructure gaps that let a golden ticket attack turn a single compromised build server or CI/CD credential into domain-wide persistence across your software supply chain. Build agents, artifact repositories, and release pipelines are frequently domain-joined or rely on service accounts with far more Active Directory privilege than the job requires, which makes them attractive stepping stones toward krbtgt access. Safeguard continuously maps the trust relationships and privilege paths between your CI/CD systems and the identity infrastructure behind them, flagging service accounts and build agents that carry excessive replication rights or Domain Admin-adjacent access before an attacker can exploit them. Where legacy authentication and long-lived AD trust are unavoidable, Safeguard layers in anomaly detection tuned to supply-chain-relevant behavior — unexpected service ticket requests against build and signing infrastructure, unusual replication traffic from build agents, and credential use patterns inconsistent with your pipeline's normal cadence. Combined with provenance and attestation for every artifact that leaves your pipeline, this means that even if an attacker achieves persistence through a golden ticket, tampered builds and unauthorized deployments are still caught before they reach production, keeping a domain compromise from silently becoming a software supply chain compromise.