Golden ticket attack: What it is and how to defend against it

In many Windows environments, Active Directory (AD) is responsible for authenticating users and controlling access to systems. When attackers gain deep access to these identity systems, they can forge Kerberos authentication tickets.

These forged tickets, known as golden tickets, are accepted as legitimate by the domain, turning a single breach into broad and persistent access if not detected. This guide explains what a golden ticket attack is and the common steps teams use to detect it, reduce risk, and respond.

What is a golden ticket attack?

A golden ticket attack is an AD attack where an attacker forges Kerberos tickets to sign in as almost any identity in the domain. The attacker creates a forged Ticket Granting Ticket (TGT) that is cryptographically valid and accepted as legitimate by the domain, then uses it to request access across the environment.

This is a post-compromise technique. It usually follows high-privilege access in AD, often after a domain controller (DC) compromise or another path that provides access to the KRBTGT account secret (password hash) used to sign TGTs. The attacker can then use this secret to create Kerberos authentication tokens that may resemble normal authentication traffic and remain valid longer than a typical session.

Golden ticket attack objectives

Common objectives in golden ticket attacks include:

• Persistent domain access: Maintain ongoing access within AD, even if individual user account passwords are reset.
• Privilege impersonation: Act as a domain admin or other privileged identity without using standard authentication flows.
• Broad lateral access: Access file servers, apps, and admin systems across the domain using Kerberos authentication, depending on privileges and network controls.
• Trust abuse at scale: Leverage domain trust relationships to access resources in connected domains when sufficient AD privileges are obtained.

Why golden ticket attacks matter in enterprise environments

Teams care about golden ticket attacks because they can:

• Target core identity systems: AD and Kerberos handle authentication for file servers, internal apps, admin tools, and many service-to-service connections. When an attacker can forge Kerberos tickets, those requests may resemble normal enterprise sign-in activity.
• Outlast common cleanup steps: Resetting user passwords may not revoke access created through forged tickets, complicating containment and recovery planning.
• Widen impact through trust: In environments with multiple domains, domain trust relationships can extend the scope of where forged identity claims are accepted. This increases the potential impact in large enterprises and merged IT environments.

Key components involved in a golden ticket attack

A golden ticket attack depends on a small set of Kerberos authentication and AD building blocks. These components are the parts of the identity system that an attacker targets after gaining deep access, often through DC compromise.

Kerberos authentication

Kerberos is a network protocol used for authentication and is the default sign-in system in many AD networks. Instead of sending a password repeatedly, a trusted service issues short-lived tickets that prove identity.

Kerberos tickets

These are time-limited credentials used across the network so users and services don’t keep sending passwords around. As a result, defenders often focus on which tickets exist and which systems issued them, not just password-based authentication events. It’s also tightly tied to domain trust inside AD, which means forged or misused tickets can affect multiple systems across an enterprise environment.

The key Kerberos ticket types involved in golden ticket attacks are:

• Ticket Granting Ticket (TGT): The first ticket issued after authentication to the domain. You use it to ask the KDC for other tickets to specific services.
• Ticket-Granting Service (TGS) ticket: Often called a service ticket. It’s what you present to a specific service, such as a file server, after the key distribution center approves the request.

Active Directory (AD) domain

AD stores user and group identities and determines who can sign in and what they can access. Golden ticket attacks target AD because it serves as the central identity store for many Windows environments and underpins many internal authentication processes.

Domain controller (DC)

A DC is a server that runs AD services and hosts the Kerberos service that issues and validates tickets. When people say “domain controller compromise” in the context of golden tickets, they refer to a level of access where the attacker can obtain the secrets that protect ticket validation.

Key distribution center (KDC)

KDC is the gatekeeper that hands out proof-of-identity tokens for the domain. In an AD environment, it runs on a DC and checks identity upon login and issues tickets you present to other systems, like file servers, without re-entering credentials.

KRBTGT account

It’s a special AD account used by Kerberos on the DC to sign and encrypt TGTs. If an attacker gets the KRBTGT secret (often described as its hash), they can create forged TGTs that a DC will accept as valid.

Privileged identities and groups

Accounts like Domain Admins and service accounts have broad access in many environments. A forged ticket that claims high privilege may grant wide access across systems that trust AD for login decisions.

Domain trust relationships

Many organizations connect domains so users in one domain can access resources in another. These trust relationships can expand the attacker’s reach if the attacker’s forged identity is accepted across trusts.

How golden ticket attacks work

Incidents vary, but most follow this sequence at a high level:

1. Initial access and positioning

Before ticket forgery becomes possible, the attacker needs a foothold and a path toward AD control. Common routes include:

• Reaching a DC or identities and systems that effectively grant the same influence over AD.
• Obtaining high-trust credentials or session tokens and using them to gain domain-wide permissions.
• Moving laterally across internal systems, looking for higher privileges.

2. Privilege escalation in AD

The attacker escalates from initial access to privileges that grant broad control. Teams often describe this as Domain Admin-level access or directory replication rights.

3. KRBTGT account secret exposure

With access to AD data, the attacker steals the KRBTGT secret (password hash) used to sign and validate TGTs.

4. Domain details gathered

The attacker gathers domain details required to construct a valid Kerberos ticket, such as identifiers used by the domain.

5. Forged TGT created

The attacker creates a forged TGT that claims a chosen identity and group membership. Since the stolen KRBTGT secret can validate that ticket, AD treats it as legitimate.

6. Ticket used for ongoing access

The attacker uses the forged TGT to request service tickets and access resources across the domain without a normal interactive sign-in. A forged golden ticket may remain valid until the KRBTGT password is reset, which invalidates existing ticket-signing keys.

Consequences of a successful golden ticket attack

A successful golden ticket attack shifts the incident from one compromised account to domain-level access. Once the attacker can use forged Kerberos tickets that AD accepts, the potential impact can expand quickly and may be difficult to contain.

Long-term unauthorized access

Golden tickets often act like a durable backdoor into AD. The attacker can keep coming back as trusted identities for extended periods of time, even after defenders take common cleanup steps such as resetting user passwords. Disabling a user account may not remove the attacker’s access if the attacker can keep presenting forged tickets that still validate.

Data exposure and operational risk

With the ability to authenticate broadly across the domain, attackers can reach many systems that trust AD for access decisions. This can include Server Message Block (SMB) file shares, email systems, databases, and backup infrastructure. From a business perspective, this raises the risk of large-scale data theft and the likelihood of disruption across teams that rely on those systems every day.

Compliance and regulatory implications

For organizations subject to frameworks or laws such as the General Data Protection Regulation (GDPR), the Health Insurance Portability and Accountability Act (HIPAA), or the Payment Card Industry Data Security Standard (PCI DSS), this kind of AD compromise may create breach notification duties. This can lead to possible regulatory penalties, depending on what the attacker accessed and what evidence the organization can confirm.

Financial and reputational damage

Organizations face direct costs from incident response and recovery, as well as potential fines for regulatory non-compliance (e.g., GDPR or HIPAA violations), and the loss of trust from customers and partners.

Detection and remediation can be challenging due to the persistence of forged tickets. In severe cases, organizations may need to rebuild parts of the domain or perform extensive remediation, which can take significant time and cause operational disruption.

How to detect a golden ticket attack

Golden tickets can look valid on the surface, so detection is less about one specific alert and more about finding Kerberos ticket activity that doesn’t match real, normal sign-ins in your environment.

Start with DC security logs

DCs record the Kerberos events commonly used to spot ticket misuse:

• Event ID 4768: This is logged when the domain’s KDC receives a request that leads to a TGT being issued. It provides a starting point for identifying ticket-backed sign-ins.
• Event ID 4769: This is logged when a client requests a TGS ticket to access a specific service. It helps answer “what services did this identity try to reach?”
• Event IDs tied to ticket lifecycle and failures (4770, 4771): These help you spot odd renewal and failure patterns that can show up alongside other Kerberos abuse.

Look for golden ticket indicators in ticket behavior

Look for patterns that feel “off” when compared to how your users and systems normally authenticate.

TGTs that don’t line up with expected sign-in behavior

This includes tickets tied to nonexistent usernames or tickets with unusual lifetimes. Use this as a starting point, then confirm whether the user and host activity make sense for the business.

Service ticket requests without a believable trail back to authentication

In many environments, service ticket bursts make sense only when they follow a real logon pattern. A spike in 4769 activity that doesn’t match expected workstation or service behavior can be worth a closer look.

Ticket lifetimes that stand out from your policy

Golden tickets are often discussed in the context of unusually long ticket lifetimes. Instead of hard-coding one number, check for outliers compared to your own baseline so you catch the weird cases without flagging normal operations.

Ticket activity tied to identities that should not behave that way

Examples include disabled accounts showing ticket use, rarely used admin accounts suddenly touching many services, or admin-like behavior that doesn’t match historical patterns for that identity.

Watch for false positives before you escalate

Kerberos logging can be noisy in real enterprises. Microsoft documents situations where Event ID 4769 can appear as an audit failure tied to normal SharePoint service behavior. Treat single events as clues, then confirm them with the surrounding context before calling it an incident.

Follow a practical detection workflow

Use a repeatable workflow, so the team stays consistent:

1. Review DC logs for 4768 and 4769 for the time window you care about.
2. Identify outliers, like unusual users, unusual source hosts, unusual service targets, and unusual ticket lifetimes.
3. Correlate those outliers with endpoint and identity data. Look for a real user session that explains the ticket activity, or a service account pattern that matches known operations.
4. If the pattern still doesn’t make sense, treat it as a high-confidence lead and move into containment and validation steps in your incident response process.

How to reduce the risk of golden ticket attacks

Golden ticket risk drops when two things are done well. Make it hard for an attacker to reach the KRBTGT account secret, and limit what happens if they still get in.

Monitor Kerberos ticket activity

Monitoring won’t stop ticket forgery on its own, but it does help you spot conditions that often indicate abuse of Kerberos. Start with a small set of signals and tune them to your environment:

• Collect and retain Kerberos event logs from DCs: This allows you to investigate quickly when something looks off. Extending Kerberos logging across the relevant event IDs should be part of basic hygiene.
• Watch privileged account behavior: Look for sudden bursts of access across many systems. This pattern doesn’t prove a golden ticket, but it often shows up in the same incidents.
• Keep the goal simple: you want fast triage. The deeper analysis belongs in your detection and incident response workflow.

Protect and rotate the KRBTGT account

This is one of the most direct controls that breaks forged-ticket persistence.

• Rotate the KRBTGT password on a schedule: Regular KRBTGT rotation is recommended to invalidate stolen ticket material and reduce long-term access.
• Plan and test KRBTGT resets: A KRBTGT reset can disrupt authentication for services that rely on long-lived tickets. The process needs careful planning to avoid breaking authentication services.

Implement strict least privileged access

Golden tickets typically become possible after high privilege in AD is obtained. Least privilege reduces the number of ways an attacker can reach that level. Focus on the privileges that matter most in AD:

• Reduce Domain Admin use: Keep the number of standing Domain Admin accounts small, and use time-bound elevation for admin work where your tooling supports it.
• Limit who can interact with DCs: Tighten who can log into DCs and who can administer them. Golden ticket attacks often follow DC compromise or equivalent AD-level control.
• Harden credential theft paths on endpoints: Windows features like Credential Guard are commonly used to reduce credential theft from memory on compromised machines.

Use a tiered administration model

A tiered model separates high-trust administration from everyday computing, so a single compromised workstation doesn’t easily become an AD takeover. A simple way to think about it:

• Tier 0: DCs and identity systems (AD, public key infrastructure, identity admin tools).
• Tier 1: Servers and business applications.
• Tier 2: User workstations and standard devices.

Use identity threat detection and response (ITDR) tools

Golden tickets target identity, so tools that understand identity signals can help identify activity that endpoint-only tools may not capture. ITDR can add:

• Identity-focused anomaly detection: Behavioral analytics for Kerberos authentication patterns, privilege changes, and unusual lateral access that spans systems. Detection often needs identity protection capabilities since forged tickets can look valid.
• Cross-signal correlation: Combines telemetry across endpoints, AD, and identity logs so suspicious ticket activity doesn’t sit in isolation.

What to do if a golden ticket attack is suspected

You should treat a suspected golden ticket attack as an AD security incident, not a single-host problem. A forged TGT can keep working until you invalidate the signing material, so speed and coordination matter.

1. Preserve the evidence you’ll need

The artifacts that will be the most helpful during an investigation will be the ones that show where the intrusion started and what the attacker did after they got in. These artifacts include:

• DC security logs around Kerberos activity: Timely collection matters more than perfect completeness.
• Identity and admin audit trails: Include new accounts, group membership changes, delegation changes, and privilege assignments.
• Endpoint telemetry: Get evidence from systems tied to suspicious admin sign-ins or unusual Kerberos use.

2. Begin containment phase

In parallel, start limiting what the attacker can touch while you validate the activity.

• Restrict access to Tier 0 systems: Limit DCs and identity admin tooling to known admin workstations only. This reduces the chance that the attacker keeps moving while you investigate.
• Temporarily block risky admin paths: These can include privileged interactive sign-ins from user workstations. Attackers often rely on stolen admin material collected from lower-trust devices.
• Isolate systems: Quarantine those involved in suspicious Kerberos ticket activity so you can collect evidence and stop further use.

Where it’s safe to do so, consider temporarily restricting high-risk accounts involved in the suspicious activity. This should be done with caution at this stage, however, because resetting accounts or rotating credentials may destroy evidence needed in an investigation.

3. Investigate the scope of the impact

Golden ticket incidents often come with other AD abuse. Aim for a short, defensible scope statement you can refine. Consider identifying:

• Which identities showed suspicious ticket use: Check privileged accounts, dormant accounts, and accounts that should never authenticate.
• Which systems were reached: Include file servers, email, backups, and identity tooling.
• Whether trust paths expanded: Assess if attackers extended the incident across domains through domain trust relationships.

4. Cut off forged tickets the right way

If evidence confirms or strongly suggests KRBTGT exposure or a DC compromise, reset KRBTGT twice. Microsoft’s guidance says you should perform the reset twice and wait (10 hours by default) between resets so ticket lifetimes and replication behavior don’t leave a half-rotated state.

Additionally, plan for service impact. Some services rely on long-lived Kerberos behavior, so coordinate with IT owners before you pull the trigger.

5. Rotate privileged credentials and remove attacker footholds

Don’t stop at KRBTGT. An AD compromise usually means more secrets are exposed. Reset privileged accounts and service accounts that could have been captured, starting with Domain Admins and accounts used on DCs.

Then, review new accounts, new group memberships, and delegation settings created during the suspected window, and remove anything that doesn’t belong.

6. Decide whether you can trust the DCs

If you suspect DC compromise, you may need to rebuild DCs from known-good media and known-good backups rather than trying to “clean” them in place. According to CISA’s AD compromise guidance, this is a common requirement when attackers reach deep directory control.

7. Handle reporting and governance early

Golden ticket incidents often touch regulated data or systems tied to business operations. Bring legal, compliance, and leadership in early so your team can preserve evidence, make defensible decisions, and meet any applicable notification requirements.