Recommended Free Tools
A Kerberos Golden Ticket attack is the use of a forged ticket-granting ticket (TGT) created with the Active Directory KRBTGT account’s password hash or other key material. An attacker cannot normally create one from a regular workstation account: they must first obtain this domain-critical secret, usually after compromising a domain controller or gaining equivalent privileged access. The forged TGT can then be used to request service tickets (TGS tickets) while impersonating Active Directory accounts.
Because a forged ticket can remain useful until it expires and can be made to resemble legitimate Kerberos traffic, treat a suspected Golden Ticket as a domain-level identity incident. Detection depends on correlating ticket, logon, endpoint, domain-controller, and resource-access evidence. Containment requires two coordinated KRBTGT password resets, with replication confirmed between resets.
As an Amazon Associate I earn from qualifying purchases.
What a Kerberos Golden Ticket actually is
Kerberos uses tickets rather than sending a user password to every service. In a normal Active Directory exchange, a client authenticates to the Key Distribution Center (KDC) and receives a ticket-granting ticket (TGT). The client presents that TGT when it asks the KDC for a ticket-granting service (TGS) ticket for a particular service, such as a file server, database, or application. The service validates the resulting ticket before creating a session.
A Golden Ticket is a counterfeit TGT. The attacker signs or encrypts it with the KRBTGT account key, which is the secret the KDC uses to protect legitimate TGTs. MITRE ATT&CK identifies this activity as T1558.001, Golden Ticket. Once the attacker has the key, they can put an Active Directory account name, group memberships, validity period, and other ticket fields into forged authentication material and then interact with the KDC to obtain TGS tickets.
#1 Best Overall
The ticket is not a universal bypass of every authorization check. Access still depends on the target service, trust relationships, group and resource permissions, ticket flags, and how the environment validates Kerberos. It is nevertheless a severe compromise because the attacker can manufacture credentials for highly privileged identities and move through services that trust the domain.
What an attacker must already have
The KRBTGT password hash or key
The non-negotiable prerequisite is the current KRBTGT password hash or equivalent key material. Possession of an ordinary employee password, a local administrator account, or a single service account does not by itself enable Golden Ticket creation. The attacker must obtain the domain-level secret used to sign TGTs.
Typical acquisition paths
MITRE describes credential dumping and privileged access to a domain controller as possible routes. Microsoft’s Active Directory guidance also warns that adversaries may combine Golden Ticket activity with DCSync or other credential-dumping techniques. DCSync abuses replication permissions to request password data from a domain controller; it does not require interactive logon to the controller, but it does require powerful directory-replication rights.
- Compromise of a domain controller or its credential material.
- Unauthorized accounts granted directory-replication permissions.
- Credential theft from an administrator who can access domain-controller secrets.
- Existing domain compromise that lets the attacker run tooling in a highly privileged security context.
Consequently, evidence of a Golden Ticket should trigger investigation for the earlier breach that exposed the key, not just removal of one suspicious endpoint.
Why the impact is so serious
Impersonation and service-ticket requests
A forged TGT can represent an account and its claimed privileges in the ticket data. The attacker can use it to request TGS tickets for selected services and attempt access to file shares, servers, applications, and administrative interfaces. The breadth of access depends on what the target services trust and what authorization rules they apply.
Persistence and stealth
Microsoft characterizes the result as potentially broad, persistent, and stealthy. A forged TGT can outlive the original compromise of an administrator workstation, so deleting that workstation account or killing one session may not remove the attacker’s ability to authenticate. An adversary can also choose fields that look normal, including familiar account names and plausible lifetimes. The joint U.S. government guidance published by CISA and partner agencies on September 25, 2024, specifically warns that malicious actors may make forged TGTs resemble legitimate tickets.
What it does not guarantee
A Golden Ticket does not automatically open every system. A service may require a particular group, deny the account, use a different trust boundary, or reject a malformed or expired ticket. Cross-forest trusts, resource-based permissions, smart-card requirements, and application-specific authorization can all change the result. Investigators should therefore identify the services actually accessed rather than assume that every resource was compromised.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →How to detect a possible Golden Ticket
Detection is a correlation problem, not a single-event rule. MITRE’s DET0144 detection strategy (version 1.0, created October 21, 2025, and modified May 12, 2026) recommends combining several anomalies and tuning them to the organization’s domain policy and normal encryption configuration.
Rank #3
- Mastering Active Directory: Design, deploy, and protect Active Directory Domain Services for Windows Server 2022, 3rd Edition
- ABIS BOOK
- Packt Publishing
Signals worth correlating
| Signal | Why it matters | How to qualify it |
|---|---|---|
| Ticket lifetime exceeds domain policy | Forged tickets may be issued for an unusually long period. | Compare the observed lifetime with the policy applied by the relevant domain and account. A long lifetime alone is not proof. |
| Unexpected encryption type | An attacker may use an encryption type that is unusual for the environment; MITRE gives RC4 in a modern domain as an example. | Build an allowlist from your actual domain-controller and client baseline. Legacy systems can legitimately require older types. |
| Malformed logon or logoff fields | Inconsistent timestamps, identifiers, or session metadata can indicate forged authentication material. | Validate the field against neighboring events, the endpoint clock, and the domain controller that processed it. |
| TGS request without the expected TGT sequence | A service-ticket request that lacks a preceding, plausible TGT request is suspicious. | Account for caching, logging gaps, multiple domain controllers, and collection latency before escalating. |
| Unexpected process access to credential material | Process behavior can reveal attempts to obtain secrets needed for ticket forgery. | MITRE includes Sysmon event 10 as a possible endpoint signal; interpret it with process identity and host role. |
Windows events to collect
MITRE’s strategy calls out Windows Security events 4672 and 4634 for logon-session metadata and event 4769 for TGS requests. Collect these from all domain controllers and retain the fields needed to correlate account, service name, client address, encryption type, timestamps, and requesting host. Sysmon event 10 can add process-access context on monitored endpoints.
Event 4769 without an immediately adjacent TGT event is an investigation lead, not a verdict. Kerberos tickets can be cached, domain controllers can be selected in ways that separate events, and a logging pipeline can drop or delay records. Compare the event with account behavior, endpoint telemetry, domain-controller logs, and the service’s own access records.
Use identity analytics as an additional layer
Microsoft identifies Defender for Identity as a source of real-time alerts for Golden Ticket use, DCSync or DCShadow activity, and unusual Kerberos behavior. Treat that capability as one sensor in a layered program, not as a guarantee that every forged ticket will be detected. Validate alerts against the underlying domain-controller and endpoint evidence.
Investigation workflow
- Preserve evidence. Export relevant Security and Sysmon events from every domain controller, affected endpoint, and accessed service. Record the domain, forest, trust relationships, current
KRBTGTpassword-change history, and time synchronization status. - Scope the suspected identity. Identify the account names, group claims, client addresses, service names, ticket lifetimes, and encryption types associated with the anomalous activity. Search backward for the first suspicious TGS request and forward for subsequent resource access.
- Check for key theft. Review domain-controller logons, privileged process creation, credential-dumping indicators, DCSync permissions, and replication requests. Determine which identities could read or replicate password data.
- Trace lateral movement. Correlate ticket activity with administrative shares, remote service creation, PowerShell or other command execution, database connections, and changes to directory objects.
- Assess trust boundaries. Examine child domains, forests, external trusts, and applications that accept the affected domain’s tickets. Each trust or service may require separate containment actions.
- Declare the incident scope. If the
KRBTGTkey may have been exposed, handle the case as a domain compromise even if only one forged ticket has been observed.
How to invalidate Golden Tickets safely
MITRE’s mitigation guidance and the joint government guide both require two resets of the built-in KRBTGT account password. The sequence matters because existing tickets can remain verifiable with the previous key.
Rank #4
- Used Book in Good Condition
- Prepare the change. Confirm domain-controller inventory, replication health, administrative access, emergency contacts, and a maintenance window. Review applications and scripts that may be sensitive to Kerberos key changes.
- Perform the first
KRBTGTpassword reset. Use your approved Active Directory procedure and document the exact time and domain controller that processed it. - Force or verify replication. Wait for the new password data to replicate across all domain controllers. Check replication status rather than relying only on elapsed time. A reset that has not reached every controller leaves an inconsistent validation state.
- Perform the second reset. After replication is confirmed, change the
KRBTGTpassword again. This advances the key history so tickets derived from the old key no longer validate. - Verify service health. Test representative logons, file access, scheduled tasks, and applications. Investigate failures as possible replication, time, service-account, or ticket-cache issues instead of immediately rolling back the reset.
- Expire attacker footholds. Reset or disable other privileged accounts, remove unauthorized replication rights, rotate exposed service credentials, isolate compromised hosts, and invalidate active sessions where the platform supports it.
- Continue hunting. Keep enhanced Kerberos and directory monitoring enabled. Search for tickets issued before and after the reset sequence and document any continuing access.
Two rapid, uncoordinated password changes are not sufficient. Microsoft’s 2025 guidance and MITRE both emphasize replication between resets; the operation must be coordinated across the domain and backed by healthy replication.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Prevention and hardening controls
Protect domain controllers first
Preventing theft of the KRBTGT material is more effective than relying on ticket detection after compromise. Restrict interactive logon to domain controllers, apply administrative tiering, patch the operating system and directory services, control remote administration paths, and monitor privileged process execution. Microsoft’s 2025 Active Directory guidance recommends protecting domain-controller credential material with LSA Protection.
Control replication privileges
Inventory every principal with directory-replication rights, including “Replicating Directory Changes” permissions and their extended variants. Remove non-administrator accounts that do not have a documented operational need, review nested groups, and alert on new grants. A replication-rights review should include service accounts, delegated help-desk roles, and stale groups—not just named domain administrators.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteAudit Kerberos and directory activity
Enable Kerberos audit logging on domain controllers and centralize the relevant Security events. Store enough history to establish normal ticket lifetimes, encryption types, service-request patterns, and administrator behavior. Pair domain-controller logs with endpoint telemetry and service access logs so analysts can reconstruct the complete sequence.
Rotate the KRBTGT account on a schedule
Microsoft’s December 9, 2025 guidance recommends rotating the KRBTGT password at least every 180 days, in addition to the two-reset procedure required after suspected compromise. Treat the schedule as a dated vendor recommendation and validate it against current Microsoft instructions, replication capacity, legacy applications, and your change-management process.
Build and rehearse recovery
Document who can authorize a reset, which administrators perform it, how replication is checked, how applications are tested, and how evidence is preserved. Rehearse the procedure in a representative environment. Include time synchronization checks, domain-controller failures, disconnected sites, and recovery of systems that cache Kerberos tickets.
Operational pitfalls and how to avoid them
- Calling one anomaly conclusive: RC4, a long ticket, or a missing event can have a legitimate explanation. Require correlated identity, endpoint, and service evidence.
- Resetting only once: One change does not reliably invalidate all tickets derived from the previous key. Complete both resets with confirmed replication.
- Ignoring replication health: A controller that has not received the new key can continue validating or issuing tickets inconsistently. Check every site and controller.
- Assuming account deletion solves the incident: A forged ticket can represent a different account. Investigate the stolen key and all privileged identities, not just the name in one alert.
- Overlooking legacy encryption: Older systems may explain an unexpected encryption type. Baseline by domain, site, operating-system generation, and application before blocking.
- Failing to test applications: Scheduled tasks, service accounts, trusts, and line-of-business systems can expose replication or ticket-cache problems after a reset. Use a written validation list.
A practical control-selection framework
When choosing between monitoring and response investments, evaluate each control against the same four questions:
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
| Question | What good looks like |
|---|---|
| Does it reduce the chance of KRBTGT theft? | It hardens domain controllers, limits privileged logon, protects credential material, or removes unnecessary replication rights. |
| What can it observe? | It collects the domain-controller events, endpoint process telemetry, identity context, and service-access records needed for correlation. |
| Does it use a local baseline? | It detects deviations in lifetime, encryption, TGT-to-TGS sequence, account behavior, and resource access without treating a fixed threshold as universal. |
| Can the organization complete both resets? | It includes tested authority, replication checks, application validation, communications, and a documented recovery path. |
Administrator checklist
- Confirm which domain controllers, forests, trusts, and services are in scope.
- Inventory and remove unjustified DCSync or equivalent replication permissions.
- Enable and centralize Kerberos audit events, including 4672, 4634, and 4769 where applicable.
- Baseline ticket lifetimes and encryption types for each environment segment.
- Protect domain-controller credentials with LSA Protection and restrictive administration paths.
- Monitor for credential dumping, DCSync, DCShadow, and unusual process access.
- Maintain a tested two-reset
KRBTGTrunbook with replication verification. - After a suspected incident, investigate the original key-theft path and continue hunting after both resets.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
