How to Detect and Respond to Golden Ticket Attacks in Active Directory

The answer in fifty-five words

Detecting golden ticket attacks in Active Directory requires three layers: Kerberos event log baselining on every domain controller, Microsoft Defender for Identity sensors that learn normal Kerberos behaviour and alert on anomalies, and a regular krbtgt rotation cadence that limits the useful life of any forged ticket. Response is a double krbtgt reset combined with credential resets and log review.

Why golden ticket attacks are the AD worst case

The krbtgt account is the Kerberos Key Distribution Center service account. Its password derives the keys used to sign every Ticket Granting Ticket issued in the domain. An attacker who has extracted the krbtgt hash from a compromised domain controller — typically via mimikatz lsadump::dcsync or equivalent tradecraft catalogued under MITRE ATT&CK T1003 (OS Credential Dumping) — can forge a TGT for any user, with any group memberships, for any lifetime.

MITRE ATT&CK T1558.001 (Steal or Forge Kerberos Tickets — Golden Ticket) is the canonical reference. Microsoft's Mitigating Pass-the-Hash and Other Credential Theft v2 (2023 reissue) covers the prevention side. ASD's Restricting Administrative Privileges guidance (ACSC, 2025) reinforces the krbtgt cadence as a privileged hygiene practice.

A golden ticket bypasses every detection that relies on tracking a real user authentication. The TGT is mathematically valid; the domain controller serving it has no way to know it was not issued by itself. Detection runs on the periphery — anomalies in ticket lifetime, encryption type, and service-usage patterns.

Step 1 — Baseline Kerberos event logs

Detection starts with knowing what normal looks like. Configure auditing on every domain controller to capture the right Kerberos events at the right verbosity:

• Event ID 4768 — A Kerberos authentication ticket (TGT) was requested. The legitimate AS-REQ.
• Event ID 4769 — A Kerberos service ticket (TGS) was requested. The legitimate TGS-REQ.
• Event ID 4624 — An account was successfully logged on. The interactive logon record.
• Event ID 4672 — Special privileges assigned to new logon. Flags accounts logging on with sensitive group memberships.

Forward these events from every domain controller to Microsoft Sentinel or an equivalent SIEM. ASD ISM section Event logging and auditing (Australian Signals Directorate — Information Security Manual, accessed 16 June 2026) (November 2025 release) sets the baseline retention requirement.

The baseline takes weeks to mature. Capture:

• The distribution of ticket lifetimes for service tickets per service.
• The encryption types used for service tickets per service.
• The mix of authentication sources per privileged account.
• The expected daily volume of TGT and TGS requests per DC.

Anomalies become detectable only against this baseline. The ASD ISM auditing controls and Essential Eight Control 5 (privileged access logging) both assume the baseline exists.

Step 2 — Deploy Microsoft Defender for Identity

Microsoft Defender for Identity (Microsoft Learn, current) deploys a sensor on every domain controller. The sensor reads Kerberos traffic, ETW events, and DC performance counters; the cloud service correlates per-tenant baselines and emits alerts.

The relevant built-in detections:

• Suspected golden ticket usage (forged authorisation data) — TGT with non-default flags or PAC inconsistencies.
• Suspected golden ticket usage (encryption downgrade) — TGT using RC4 in an environment that should use AES.
• Suspected golden ticket usage (ticket anomaly) — TGT with anomalous lifetime, often well beyond the maximum lifetime policy.
• Pass-the-Ticket — the same TGT used from two different source IPs.
• Remote code execution attempt on DC — the precondition for dcsync.

Configure alerts to forward to the SOC ticketing system. For Australian organisations using Microsoft Sentinel as the SIEM, the integration is native and includes the Microsoft Defender XDR incident merger.

Step 3 — Add custom detections

The built-in Defender for Identity rules cover the common cases. Custom detections fill the gaps:

• Service tickets for accounts that should not request them. Service accounts that historically requested tickets only for SQL Server suddenly requesting tickets for the domain controller machine accounts.
• Anomalous ticket lifetimes. Tickets with lifetimes longer than the configured maximum domain TGT lifetime. The configured maximum should be in the order of ten hours; tickets with lifetimes of days or weeks are almost always forged.
• Encryption type downgrade. Tickets using RC4 (etype 23) on accounts that should be using AES (etype 18).
• Unexpected dcsync activity. Replication requests (Event ID 4662 on the Directory Service object) from accounts other than legitimate DCs and AD Connect.

Microsoft Sentinel content packs publish KQL queries for each of these. The Australian Government's ACSC Annual Cyber Threat Report 2024–25 identifies credential theft and lateral movement as recurring incident themes — these detections target both.

Step 4 — Set a regular krbtgt rotation cadence

The cheapest preventive control is a regular krbtgt password rotation. Microsoft publishes a krbtgt reset script (New-KrbtgtKeys) on GitHub that performs the reset and waits the required replication interval before the second reset.

For Australian environments, the recommended cadence:

• Every six to twelve months as a hygiene practice.
• After any suspected Tier 0 compromise (double reset, twenty-four hours apart).
• After a forest recovery (per the Microsoft AD Forest Recovery Guide).
• Before retiring a domain controller that was ever compromised.

Document the cadence in the Tier 0 register so the next administrator does not skip it.

Step 5 — Response playbook

When the alert fires, the order of operations is:

1. Validate. Is the alert credible? A spike in RC4 tickets might be a legitimate legacy application. A ticket lifetime anomaly might be a misconfigured service account. Treat the first alert as a hypothesis.
2. Contain. Disable the apparent attacker source — block the source IP, isolate the affected workstation, suspend the apparent attacker user account. Containment is not eradication.
3. Reset krbtgt twice, twenty-four hours apart. This is the only action that genuinely evicts a golden-ticket attacker. The single reset invalidates only the most recent previous key; the second reset evicts the attacker's last cached key.
4. Reset privileged account passwords. Every Domain Admin, Enterprise Admin, Schema Admin, Account Operator, and any other Tier 0 account.
5. Review every privileged group membership. Attackers often add a backdoor account before being detected. Compare current group membership against the last known-good snapshot.
6. Review Kerberos event logs for the attacker dwell window. Identify every account whose tickets the attacker might have used. Force password resets on all of them.
7. Escalate to forest recovery if Tier 0 compromise is broad. When the attacker dwell time exceeds the krbtgt rotation interval or other Tier 0 compromise is suspected, a forest recovery against a known-good backup is the only complete remedy. The Microsoft AD Forest Recovery Guide describes the procedure.

The Australian Notifiable Data Breaches scheme (Office of the Australian Information Commissioner — Notifiable Data Breaches scheme, accessed 16 June 2026) imposes a thirty-day notification window where personal information may have been accessed. The response playbook is also the start of the breach assessment under the Privacy Act 1988 (Office of the Australian Information Commissioner — Privacy Act 1988, accessed 16 June 2026).

Step 6 — Test the detection

Detections that are never tested do not exist. Annual purple-team exercises against the AD environment, with explicit authority and a known scope, are the standard practice. Tools used in Australian environments:

• BloodHound (community edition or commercial) for attack-path mapping.
• Atomic Red Team Kerberos atomic tests (T1558.001).
• Purple Knight for AD posture issues.

Test the detection from a controlled host. Confirm the alert fires, the SOC receives it, the playbook executes correctly. Update the playbook based on what was learned.

What to avoid

• Single krbtgt reset. AD retains the previous password to support replication. A single reset evicts an attacker only briefly; the second reset is required.
• Skipping the cadence after the rehearsal. The reset script is easy to run; running it every six to twelve months is a calendar discipline, not a technical one.
• Treating Microsoft Defender for Identity as set-and-forget. The baseline updates over weeks. Tune the alerts; close the false positives; document the keepers.

Where to go next

• Pillar guide: AD tier model and Essential Eight ML2 recovery.
• The backup side of the recovery playbook: AD backup verification and forest recovery rehearsal.
• Baseline your full posture: the Active Directory Security and Resilience Assessment.
• Practitioner-led deep dive: the paid Active Directory Resilience Review.

Sources cited

• Microsoft. Microsoft Defender for Identity documentation. Microsoft Learn, current.
• Microsoft. Mitigating Pass-the-Hash and Other Credential Theft v2. 2023 reissue.
• Microsoft. Active Directory Forest Recovery Guide. Microsoft Learn, 2025 reviewed.
• Microsoft. New-KrbtgtKeys reset script. GitHub Microsoft samples, current.
• ACSC. Restricting Administrative Privileges. 2025 revision.
• ACSC. Annual Cyber Threat Report 2024–25.
• ASD. Information Security Manual. November 2025 release.
• MITRE ATT&CK. T1003 OS Credential Dumping; T1558.001 Steal or Forge Kerberos Tickets — Golden Ticket. 2025.

Sources referenced in this article: ASD Information Security Manual, Notifiable Data Breaches scheme, Privacy Act 1988, Microsoft Defender for Identity documentation, Microsoft Mitigating Pass-the-Hash and Other Credential Theft v2, Microsoft Active Directory Forest Recovery Guide, Microsoft New-KrbtgtKeys reset script, ACSC Restricting Administrative Privileges, ACSC Annual Cyber Threat Report 2024-25, MITRE ATT&CK T1003 / T1558.001, BloodHound, Atomic Red Team, Purple Knight.