Golden Ticket, Silver Ticket and DCSync Guide: Detecting and Preventing Kerberos Abuse

Once an intruder holds the secret of the krbtgt account, a service account or a computer account, Active Directory will accept forged Kerberos tickets as genuine, and the directory replication protocol hands those secrets to anyone holding replication rights. Golden Tickets, Silver Tickets and DCSync are the three techniques that turn a domain compromise into long-term, quiet control. This guide is written for identity and Active Directory administrators and for the detection engineers who support them. It covers what each technique looks like from the defender's side, then spends its length on controls: the privileged access model, replication rights, krbtgt and machine account rotation, AES-only Kerberos, the event IDs worth collecting, and how to recover. Kerberos fundamentals and Kerberoasting are covered separately in the Kerberos Security Guide, and delegation abuse in the Kerberos Delegation Security Guide.

Key takeaways

• These are post-compromise techniques. Each one needs a secret or a permission that should only exist in Tier 0, so the strongest control is keeping Tier 0 small, separate and watched.
• DCSync is usually the source of the other two. Any account with the replication extended rights on the domain root can request every password secret in the domain, so audit those rights and alert on event 4662 from anything that is not a domain controller.
• The krbtgt double reset is the only way to invalidate Golden Tickets. Microsoft and the Five Eyes agencies describe resetting it twice, with replication and the maximum ticket lifetime allowed to pass between the resets.
• Silver Tickets never touch a domain controller. Detection has to come from the target servers, and prevention comes from strong, rotated service and computer account passwords, ideally gMSAs.
• AES-only Kerberos and PAC validation remove easy tells and easy wins. Retiring RC4 makes forged or downgraded tickets stand out, and the PAC signature enforcement in KB5020805 closes a class of ticket tampering.

How the attack works

The three techniques are described here only in the terms a defender needs. MITRE ATT&CK tracks them as T1558.001 Golden Ticket, T1558.002 Silver Ticket and T1003.006 DCSync.

• Golden Ticket (T1558.001): every Kerberos ticket-granting ticket in a domain is protected by the krbtgt account's key. An intruder who has obtained that key can create tickets for any user, with any group membership, that domain controllers will honour. What the defender sees is a ticket that the domain controller never issued: service ticket requests (event 4769) with no matching ticket-granting ticket request (event 4768), tickets for accounts that do not exist, group memberships that do not match the directory, and sometimes RC4 encryption or lifetimes that differ from policy. Capable actors copy legitimate ticket characteristics, so these signals are useful but incomplete.
• Silver Ticket (T1558.002): a service ticket is protected by the key of the service or computer account that runs the service. With that key, an intruder can create a ticket for that one service (file shares, LDAP, SQL Server or host services are typical) without contacting a domain controller at all. The defender sees a logon on the target host (event 4624) with no corresponding ticket request on any domain controller, and group or SID information in the logon that does not match the user's real membership.
• DCSync (T1003.006): domain controllers copy password data to each other through directory replication. An account holding the "Replicating Directory Changes" and "Replicating Directory Changes All" rights (or full control) on the domain root can ask a domain controller to replicate secrets for any account, including krbtgt. The defender sees a directory service access event (4662) carrying the replication rights GUIDs, raised by an account or from an IP address that is not a domain controller.

Where it shows up

These techniques appear late in an intrusion, and the routes to them are almost always privilege sprawl rather than Kerberos weaknesses.

Read-only domain controllers have their own krbtgt_<number> accounts. Tickets forged with an RODC key are only accepted within that RODC's scope, but those accounts still need rotation and monitoring. Theft of the database itself is covered in the Credential Dumping Guide.

Impact

• Golden Ticket: domain-wide impersonation of any identity, including accounts that are disabled or that never existed, for as long as the stolen krbtgt key remains valid. Password resets of user accounts do not remove it.
• Silver Ticket: persistent access to one service on one host. Scoped, but often a file server, database or the host itself, and invisible to domain controller logging.
• DCSync: every password secret in the domain, which in practice means the attacker can create Golden and Silver Tickets and authenticate as anyone. Treat a confirmed DCSync by a non-DC as full domain compromise.

Detection

Collect domain controller Security logs centrally and enable the audit subcategories that produce these events. Event 4662 needs "Audit Directory Service Access" and a SACL on the domain object; 4768 and 4769 need "Audit Kerberos Authentication Service" and "Audit Kerberos Service Ticket Operations". Event 4627 on member servers needs "Audit Group Membership".

Microsoft's 4769 guidance recommends alerting on any encryption type other than the two AES values and monitoring high-value and disabled accounts. The 1131f6aa GUID is the base "Replicating Directory Changes" right; the joint guidance also lists 19195a5b-6da0-11d0-afd3-00c04fd930c9 as a value to match.

• Identity threat detection: Microsoft Defender for Identity documents classic alerts for suspected DCSync (2006) and several Golden Ticket variants: encryption downgrade (2009), nonexistent account (2027), ticket anomaly (2032), time anomaly (2022) and forged authorisation data (2013). It lists no Silver Ticket alert, which reinforces that Silver Ticket detection is a host logging problem. Product-neutral guidance is in the ITDR Guide.
• PAC signature events: after the KB5020805 enforcement (full enforcement from 10 October 2023), domain controllers log events 43 and 44 when tickets fail PAC signature validation.

Metrics that show the controls are working

• Replication rights holders: number of non-default principals with replication rights on each domain root (target: zero).
• krbtgt age: days since the last krbtgt password change, per domain and per RODC (target: under 365).
• RC4 share: percentage of 4768 and 4769 events with encryption type 0x17 (target: falling to zero).
• Service account posture: percentage of SPN accounts converted to gMSA, and count of remaining accounts with passwords older than 12 months.
• Stale machine passwords: count of enabled computer accounts with passwords older than 30 days.
• Tier 0 exposure: count of Tier 0 account logons on non-Tier 0 hosts per week (target: zero).

Prevention and hardening

Privileged access model and tiering

Microsoft's enterprise access model replaces the older three-tier model with control, management and data planes; the old Tier 0 becomes the control plane, and lower planes must never be able to control higher ones. For these techniques that means domain controllers, AD CS, identity synchronisation servers, backup systems holding DC images, and every account that administers them are one security boundary. Tier 0 accounts sign in only from privileged access workstations and only to Tier 0 systems. See the Tiered Administration and Enterprise Access Model Guide.

Restrict replication rights

• Review the domain root ACL: by default only Domain Admins, Enterprise Admins, Administrators and domain controllers hold replication rights. Remove any other principal, including GenericAll or AllExtendedRights grants that imply them.
• Service accounts that need replication: where a product genuinely requires "Replicating Directory Changes" (for example some synchronisation tools), treat that account and its host as Tier 0, do not give it an SPN, and document the exception. The joint guidance advises keeping accounts with these rights off lower-tier systems and reviewing them at least every 12 months.

krbtgt and RODC krbtgt rotation

The joint guidance recommends resetting krbtgt at least every 12 months and immediately on suspected compromise. Because AD keeps a history of two krbtgt passwords, a single reset leaves tickets signed with the previous key valid; the second reset removes it. Microsoft's forest recovery procedure is the reference: reset on a writeable domain controller, allow replication to complete, wait at least the maximum user ticket lifetime (10 hours by default, longer if you have changed it), then reset again. A routine reset is low impact; a reset during an incident should be planned with the Identity Recovery Guide. Rotate each RODC krbtgt_<number> account on the same schedule.

Service and computer account keys

• Use gMSAs: group managed service accounts have 120-character passwords that AD rotates automatically, which shortens the life of any stolen key. See the Group Managed Service Accounts (gMSA) Guide.
• Remaining service accounts: the joint guidance suggests passwords of at least 30 characters, rotated on a schedule and after any suspected exposure.
• Computer accounts: keep the default 30-day machine password change enabled (do not set "Domain member: Disable machine account password changes"), alert on computers that stop rotating, and keep computer accounts out of privileged groups.

AES-only Kerberos and PAC validation

• Inventory first: use the encryption type fields in 4768 and 4769 to find RC4 use. Microsoft notes that accounts created before AES support need a password reset to gain AES keys.
• Set encryption types: the Group Policy setting "Network security: Configure encryption types allowed for Kerberos" with only AES128_HMAC_SHA1 and AES256_HMAC_SHA1, msDS-SupportedEncryptionTypes value 24 on accounts with SPNs, and DefaultDomainSupportedEncTypes 0x18 on the KDC once legacy dependencies are gone. Windows Server 2025 domain controllers no longer issue RC4 ticket-granting tickets, and Microsoft has announced the removal of RC4 as the default assumed encryption type (CVE-2026-20833).
• Roll out in stages: pilot one OU, watch for 4769 failure code 0xE (no common encryption type), fix the target's attribute, then widen. Roll back by re-adding RC4_HMAC_MD5 to the policy for the affected OU only.
• PAC signatures: confirm all domain controllers are patched to the KB5020805 enforcement level so tickets with tampered authorisation data are rejected.

Protected Users and LAPS

Adding human Tier 0 administrators to the Protected Users group removes NTLM, DES and RC4 for them, blocks delegation and caps their ticket-granting ticket lifetime at four hours, which limits what can be harvested on any host they touch. Do not add service or computer accounts. Windows LAPS gives each machine a unique, rotated local administrator password and can back up the DSRM password of domain controllers, removing a common shared secret. See the LAPS Guide.

Implementation sequence

1. Enable the audit subcategories above on domain controllers and forward the events; build the 4662 non-DC alert first.
2. Export and review the domain root ACL in every domain; remove non-default replication rights after confirming each owner.
3. Record krbtgt and RODC krbtgt password ages; perform a planned double reset in a quiet period, observing the replication and lifetime wait.
4. Run the RC4 inventory; reset legacy passwords and set AES encryption types in pilot OUs, then domain-wide.
5. Convert SPN accounts to gMSA in priority order (most privileged first); set long random passwords where conversion is not possible.
6. Enforce Tier 0 logon restrictions and Protected Users membership for human administrators, testing each change with a pilot group and keeping a documented rollback (group removal, GPO unlink).
7. Schedule the next krbtgt reset and a 12-month rights review as standing changes.

Decision guidance

• Routine versus incident krbtgt reset: routine resets can wait the full replication and lifetime interval. During confirmed compromise, the second reset still needs replication to finish, but you may accept some service disruption to shorten the window, and you must first contain the attacker's access or they will simply take the new key.
• Large or multi-forest estates: rights reviews and krbtgt resets must be done per domain, legacy RC4 dependencies are more likely, and an ITDR capability that correlates DC and host events is usually worth the effort.

Framework mapping

Lessons from incidents

• Old hashes stay dangerous: in the Cisco Active Directory credentials leak, AD data from a 2022 intrusion, including service and machine account hashes and reportedly krbtgt, was republished in 2025. If any of those secrets were not rotated, they could still be used to forge tickets. A domain compromise is not closed until krbtgt has been reset twice and every exposed account has been rotated.
• Replication rights granted for a project and never removed: migration, sync and audit tools are common holders of DCSync rights long after their purpose ends.
• Silver Tickets missed because only DCs are logged: server Security logs, including 4624 and 4627, are needed for any chance of detection.

Practitioner checklist

• Confirm only default principals hold replication rights on every domain root, and review that ACL at least every 12 months.
• Alert on event 4662 with replication GUIDs from any non-domain controller account or address.
• Reset krbtgt (and each RODC krbtgt account) twice, with replication and the maximum ticket lifetime between resets, at least yearly and after any suspected compromise.
• Collect 4768 and 4769 centrally and alert on non-AES ticket encryption and on service tickets with no matching TGT request.
• Collect 4624 and 4627 on high-value servers to give Silver Ticket detection a chance.
• Convert service accounts to gMSA; give the rest 30+ character passwords with scheduled rotation.
• Keep machine account password rotation on and alert on computers that stop rotating.
• Move Kerberos to AES only and confirm KB5020805 PAC enforcement on every domain controller.
• Put human Tier 0 administrators in Protected Users and restrict them to privileged access workstations and Tier 0 hosts.

Standards and references

• ASD ACSC, CISA, NSA and partners: Detecting and Mitigating Active Directory Compromises
• Microsoft Learn: AD Forest Recovery, Resetting the krbtgt password
• Microsoft Learn: Detect and remediate RC4 usage in Kerberos
• Microsoft Learn: Event 4769, A Kerberos service ticket was requested
• Microsoft Learn: Enterprise access model
• Microsoft Learn: Defender for Identity security alerts (classic)
• MITRE ATT&CK: Steal or Forge Kerberos Tickets: Golden Ticket
• MITRE ATT&CK: OS Credential Dumping: DCSync

Related NHI Mgmt Group resources: Pass-the-Hash and Pass-the-Ticket Guide · Active Directory and Entra ID Hardening Guide · BloodHound and Active Directory Attack Path Guide · Identity Incident Response Playbook