Nothing matches that yet. Tell us what you were looking for and it goes on the list.
Windows Security Log · Event 4662
Something acted on an Active Directory object. It is enormously noisy and mostly useless — except for one narrow case, where it is the only practical way to catch an attacker replicating every password hash in your domain.
Also written as Event ID 4662DCSync detection4662 replication get changes
This only appears on Windows Server domain controllers in a business network.
The one reason to collect this is DCSync. An attacker with the replication permissions can ask a domain controller to hand over password hashes for any account — including krbtgt — using the same protocol a real domain controller uses. Nothing is installed, no code runs on the DC, and no other event records it. The GUIDs in the Properties field are the detection, and your only baseline exclusions should be your actual domain controllers and any directory synchronisation service account.
Sanitised. Addresses come from the RFC 5737 documentation ranges.
An operation was performed on an object.
Subject:
Security ID: CORP\jbrooks
Account Name: jbrooks
Account Domain: CORP
Logon ID: 0x3E9A11
Object:
Object Server: DS
Object Type: %%7000
Object Name: DC=corp,DC=example
Handle ID: 0x0
Operation:
Operation Type: Object Access
Accesses: Control Access
Access Mask: 0x100
Properties: Control Access
{1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}
{1131f6aa-9c07-11d1-f79f-00c04fc2dcd2}
DC=corp,DC=exampleEverything else in the log line is context.
1131f6aa-9c07-11d1-f79f-00c04fc2dcd2DS-Replication-Get-Changes. One half of what DCSync requires. 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2DS-Replication-Get-Changes-All. This is the one that returns password hashes. Seeing it from anything other than a domain controller is a serious finding. 89e95b76-444d-4c62-991a-0facbeda640cDS-Replication-Get-Changes-In-Filtered-Set. Used in some DCSync variants. Most of the time it is one of these.
What gives it awayThe replication GUIDs used by an account that is not a domain controller and not your sync service. This yields hashes for any account, including krbtgt, and it is the standard route to a golden ticket.
ATT&CK T1003.006What gives it awayA DCSync targeting the krbtgt account specifically. Whoever has that hash can forge tickets for any identity in the domain until krbtgt is reset twice.
ATT&CK T1558.001What gives it awayA permission change on the domain object followed shortly by replication requests from the newly entitled account.
ATT&CK T1098SecurityEvent | where EventID == 4662 | where Properties has_any ('1131f6aa-9c07-11d1-f79f-00c04fc2dcd2','1131f6ad-9c07-11d1-f79f-00c04fc2dcd2','89e95b76-444d-4c62-991a-0facbeda640c') | where SubjectUserName !endswith '$' | project TimeGenerated, Computer, SubjectUserName, SubjectLogonId, ObjectNameSecurityEvent | where EventID == 4662 and Properties contains '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' | join kind=leftouter (SecurityEvent | where EventID == 4624 | project SubjectLogonId = TargetLogonId, IpAddress) on SubjectLogonId | project TimeGenerated, Computer, SubjectUserName, IpAddress(Get-Acl "AD:\$((Get-ADDomain).DistinguishedName)").Access | Where-Object { $_.ObjectType -in '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2','1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' } | Select-Object IdentityReference, ActiveDirectoryRightsdetection:
selection:
EventID: 4662
Properties|contains:
- '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'
- '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'
filter:
SubjectUserName|endswith: '$'
condition: selection and not filterAn attacker with replication permissions asks a domain controller to send password data using the same protocol domain controllers use with each other. Because it is a legitimate protocol operation, nothing is installed on the domain controller and no code runs there. It returns hashes for any account you name, including krbtgt, which is why it is a standard step towards total domain compromise.
Event 4662 filtered to the replication permission GUIDs, particularly 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, where the requesting account is not a domain controller computer account. Exclude your directory synchronisation service account by name. Anything else that appears is a serious finding — there is almost no other way to see this happen.
Because it fires for object access across the whole directory, and normal operation touches directory objects constantly. Collecting it unfiltered is impractical on a busy domain controller. Filter to the replication GUIDs at collection — that reduces the volume by orders of magnitude and keeps the only part that matters.
Assume every credential in the domain is compromised, including krbtgt. Identify the source machine from the Logon ID and the matching 4624, and isolate it. Then reset krbtgt twice, with at least one full replication cycle between the resets — a single reset leaves forged tickets valid, and that mistake is common enough to be worth stating plainly.
Domain controller computer accounts, and any directory synchronisation service such as Entra Connect. That is normally the entire list. Audit the domain object's permissions directly — in most environments the actual list is longer than anyone expects, and every extra entry is a path to this attack.
Last reviewed 28 August 2026