Detecting DCSync and Golden Ticket Attacks Using Only Windows Event Logs
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
DCSync and Golden Ticket attacks are post-exploitation techniques that attackers use after obtaining Domain Admin or equivalent access. DCSync lets an attacker extract every password hash in the domain without ever logging into a Domain Controller interactively. Golden Ticket lets an attacker forge authentication tokens that persist for years using a hash that was extracted via DCSync or other means.
Detecting these attacks without a dedicated identity security tool (Microsoft Defender for Identity, CrowdStrike Identity Protection) requires specific Windows audit policy configuration on Domain Controllers and knowledge of the exact field values that distinguish attack activity from legitimate operations. Both are detectable. Neither will generate useful events unless the required audit policy is configured in advance.
This guide covers the required configuration, the detection logic for each attack, and the containment procedure when an attack is confirmed.
Required audit policy configuration before anything else
Neither DCSync nor Golden Ticket attack activity will generate useful Windows Event Log entries without specific audit policy configuration. Verify and configure these before attempting detection.
For DCSync detection (Event ID 4662): navigate to Group Policy Management, edit the Default Domain Controllers Policy, and under Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > DS Access, enable Audit Directory Service Access (Success and Failure).
This alone is not sufficient. You also need a System Access Control List (SACL) on the domain root object in Active Directory. The SACL tells Windows to generate an audit event when specific extended rights are accessed on that object. Configure this in Active Directory Users and Computers (enable View > Advanced Features), right-click the domain root object, select Properties > Security > Advanced > Auditing, and add an entry for Everyone (or Authenticated Users) with Audit: Success and Type: All Extended Rights on This object only.
Verify audit policy is active: on a Domain Controller, run auditpol /get /subcategory:"Directory Service Access". The result should show Success and Failure.
For Golden Ticket detection (Event ID 4769): enable Audit Kerberos Service Ticket Operations under Account Logon in the advanced audit policy. Verify: auditpol /get /subcategory:"Kerberos Service Ticket Operations" should show Success.
Detecting DCSync via Event ID 4662
When a DCSync attack is performed, the attacker's workstation or server sends directory replication requests to a Domain Controller using the MS-DRSR (Directory Replication Service Remote) protocol. The DC generates Event ID 4662 for each replication request.
The critical fields in a 4662 event:
- Object Class: domainDNS (the domain root object was accessed)
- Properties: contains the GUID of the accessed attribute
- Subject Account Name: the account performing the replication request
The replication attribute GUIDs that indicate DCSync:
- DS-Replication-Get-Changes: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
- DS-Replication-Get-Changes-All: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
- DS-Replication-Get-Changes-In-Filtered-Set: 89e95b76-444d-4c62-991a-0facbeda640c
Legitimate DC replication generates these same events, but from the DC computer accounts. A DCSync attack generates them from a workstation or user account that is not a Domain Controller.
Detection logic: filter Event ID 4662 where Properties contains 1131f6ad (DS-Replication-Get-Changes-All) AND Subject Account Name does not end in $ (computer accounts end in $) AND the event source is not a known Domain Controller.
PowerShell query to surface from Security event log on a DC: Get-WinEvent -ComputerName [DC] -FilterHashtable @{LogName='Security'; Id=4662} | Where-Object {$.Message -match '1131f6ad'} | Select-Object TimeCreated, @{N='Account';E={$.Properties[1].Value}}, @{N='ObjectClass';E={$_.Properties[7].Value}}
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Detecting Golden Tickets via Event ID 4769
Golden Tickets are forged Kerberos ticket-granting tickets (TGTs) that bypass normal KDC validation. When a Golden Ticket is used to request a service ticket, the KDC generates Event ID 4769 for the service ticket request. The forged TGT itself does not trigger a 4768 event because it was never issued by the KDC.
Detection indicators in Event ID 4769:
-
Encryption type 0x17 (RC4-HMAC) when your domain enforces AES: if you have configured accounts to use AES encryption, legitimate Kerberos tickets use 0x12 (AES256). A 4769 event showing 0x17 for a user account in an AES-enforced domain is anomalous and warrants investigation.
-
Account Name that does not exist in Active Directory: Golden Ticket tools allow embedding arbitrary account names in forged TGTs. A 4769 event where the Account Name field contains a name that does not resolve to a valid AD account is a high-confidence Golden Ticket indicator.
-
Unusually long ticket lifetime: legitimate Kerberos tickets expire in 10 hours (default domain policy). A service ticket requested from a Golden Ticket with a 10-year embedded lifetime will show a corresponding expiry far beyond the domain maximum. This is visible in network captures of Kerberos traffic but harder to see in Event ID 4769 alone.
-
Mismatch between account domain in the ticket and the expected domain: Golden Tickets can embed incorrect domain SIDs or domain names. This shows as a domain field in 4769 that does not match the expected domain.
PowerShell query for RC4 service ticket requests: Get-WinEvent -ComputerName [DC] -FilterHashtable @{LogName='Security'; Id=4769} | Where-Object {$.Properties[5].Value -eq '0x17'} | Select-Object TimeCreated, @{N='Account';E={$.Properties[0].Value}}, @{N='ServiceName';E={$.Properties[2].Value}}, @{N='EncryptionType';E={$.Properties[5].Value}}
The krbtgt double-reset procedure when Golden Ticket is confirmed
A confirmed Golden Ticket attack requires resetting the krbtgt account password twice with a specific wait period between resets. A single reset is insufficient because attackers who captured the old krbtgt hash before the reset can immediately forge new tickets using the previous key, which the KDC still accepts during the transition period.
The procedure:
Step 1: Verify all Domain Controllers are online and replicating. Check replication status: repadmin /replsummary. All DCs must replicate the new key before the second reset or some DCs will continue accepting old Golden Tickets.
Step 2: Reset krbtgt password once. In Active Directory Users and Computers, find the krbtgt account under Users, right-click > Reset Password, generate a random complex password and do not save it. Alternatively in PowerShell: Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString -AsPlainText (New-Guid).Guid -Force)
Step 3: Verify the password change replicated to all DCs. Run repadmin /syncall /AdeP and confirm no replication errors. Check that all DCs show the same krbtgt PasswordLastSet value: Get-ADUser krbtgt -Properties PasswordLastSet
Step 4: Wait for the Kerberos maximum ticket lifetime to pass. The default is 10 hours. Do not perform the second reset before this wait completes or some legitimate user sessions that received tickets from the pre-reset KDC will be broken.
Step 5: Reset krbtgt password a second time, repeating steps 2 through 4.
After the second reset, any Golden Ticket forged with the original compromised krbtgt hash is invalid. Monitor Event ID 4769 for continued anomalies that would indicate the attacker generated new Golden Tickets using the hash from the first reset key.
The bottom line
DCSync and Golden Ticket detection with Windows Event Logs requires the SACL on the domain root object and Kerberos service ticket auditing to be configured before the attack. Without that configuration, the events are never generated and detection is impossible regardless of SIEM capability. With it in place, 4662 events from non-DC accounts with the DS-Replication-Get-Changes-All GUID and 4769 events with RC4 encryption in an AES environment are high-confidence attack indicators. The krbtgt double-reset is the only complete remediation for a confirmed Golden Ticket attack.
Frequently asked questions
What Event ID detects DCSync attacks in Active Directory?
Event ID 4662 (An operation was performed on an object) on a Domain Controller, filtered for the DS-Replication-Get-Changes-All attribute GUID (1131f6ad-9c07-11d1-f79f-00c04fc2dcd2) in the Properties field and a Subject Account Name that is not a Domain Controller computer account (does not end in $). This event is only generated if Directory Service Access auditing is enabled AND a SACL is configured on the domain root object in Active Directory for All Extended Rights. Without both configurations, DCSync does not generate any Windows event log entries.
Why does krbtgt need to be reset twice to stop a Golden Ticket attack?
Active Directory maintains two krbtgt password versions simultaneously to allow in-progress Kerberos operations to complete without disruption. A Golden Ticket is signed with the krbtgt password hash. After the first reset, the previous hash is still valid as the secondary version, meaning an attacker who captured it before the reset can still forge new tickets that the KDC accepts. After the second reset, the original hash is fully replaced by two new versions, making any Golden Ticket forged with the original hash cryptographically invalid. The wait between resets must be at least as long as the maximum Kerberos ticket lifetime (10 hours by default) to avoid invalidating legitimate in-progress sessions.
Can Golden Ticket attacks be detected after the attacker has left the environment?
Partially. Event ID 4769 logs from the period of malicious activity can be analyzed retroactively if they were forwarded to a SIEM with sufficient retention. Indicators to look for: Account Name values in 4769 events that do not exist in current AD, RC4 encryption type requests in environments that should be using AES, and service ticket requests for domain admin-equivalent services from unexpected source systems. If SIEM retention does not cover the attack period, check DC Security event logs directly as they may have longer local retention than the SIEM forwarding window.
What is the difference between a DCSync attack and a Golden Ticket attack?
DCSync is an attack technique that simulates Domain Controller replication behavior to extract password hashes from Active Directory without requiring physical access to a DC. An attacker with Replication privileges (Domain Admins, Enterprise Admins, or accounts with the Replicating Directory Changes All permission) runs a tool like Mimikatz sekurlsa::dcsync to pull the NTLM hash of any account including krbtgt. A Golden Ticket attack uses the krbtgt hash captured via DCSync (or another method) to forge Kerberos Ticket Granting Tickets that are cryptographically valid but not created by the KDC, allowing authentication as any user without the actual password.
What is a Silver Ticket attack and how does it differ from a Golden Ticket?
A Silver Ticket attack forges a Kerberos Service Ticket (TGS) for a specific service using that service's account hash rather than the krbtgt hash. It does not require the krbtgt hash (harder to obtain) but provides access only to the specific service whose account hash was compromised. A Golden Ticket forges a TGT using the krbtgt hash, which the KDC then validates to issue service tickets for any service: it provides unrestricted access across the entire domain. Silver Tickets are harder to detect because they never pass through the KDC for validation: the target service validates them directly, so no corresponding authentication event appears on the Domain Controller.
What is the immediate response when a Golden Ticket is confirmed in your environment?
A confirmed Golden Ticket means the krbtgt account hash is compromised and all Kerberos tickets in the domain are potentially forged. The response requires two consecutive krbtgt password resets (not one): reset the krbtgt password, wait for replication to complete across all domain controllers (allow 10 hours to account for the default 10-hour Kerberos ticket lifetime), then reset again. The second reset invalidates tickets created with the first reset's new hash that may still be in circulation. After both resets, all existing TGTs across the domain are invalidated and users must re-authenticate. Expect widespread authentication disruption. Simultaneously, investigate how the krbtgt hash was obtained: DCSync (Event ID 4662 with replication permissions on the domain object), domain controller compromise, or NTDS.dit extraction.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.