Event ID 4662: An operation was performed on an object

Event 4662 belongs to the Audit Directory Service Access subcategory and exists only on domain controllers. It fires when something performs an operation on a directory object and a system access control list entry on that object matches the operation. No SACL means no event, and a disabled subcategory means no event either, so an empty 4662 log proves nothing about whether DCSync is happening. Microsoft's guidance for domain controllers leaves Success auditing off for this subcategory and recommends Failure, because the volume on a busy DC is high. The detection value comes from a narrow, deliberate SACL, not from switching the whole subcategory on.

The classic complaint is a Security log drowning in 4662. The Microsoft Q&A thread on it lists normal directory operations and third-party applications that query AD as the usual causes. The mechanical reason is typically a SACL set on All Properties for Everyone, which turns every attribute read into an event. Read Property (0x10) against user objects from a monitoring or mail service is most of that volume. If you inherit a log like this, find the SACL before you touch the policy, because narrowing the SACL fixes the noise and keeps the events you want.

Read the event from the object outward. ObjectServer is DS. ObjectType is the schema class of the thing touched, written as a class GUID (user, group, domainDNS and groupPolicyContainer are the common ones). ObjectName is the distinguished name, or a GUID when the name cannot be resolved. HandleId ties the event to a 4661 handle request when there is one, and it is often 0x0. OperationType is normally Object Access. The Subject fields name the requester, and SubjectLogonId is the link back to the 4624 that opened the session.

Two fields carry the meaning. AccessMask is the sum of the rights exercised: 0x10 is Read Property, 0x20 Write Property, 0x100 Control Access, 0x10000 DELETE, 0x40000 WRITE_DAC and 0x80000 WRITE_OWNER. AccessList holds the same rights as message codes. Properties starts with the access type and continues with a tree of GUIDs naming the classes, attributes or property sets involved. To read a GUID, reorder the bytes of its first three groups, strip the hyphens, escape each byte pair with a backslash, and search schemaIDGUID under the Schema container with LDP. Property-set GUIDs are listed in the Rights-GUID column of Microsoft's extended rights reference.

DCSync is why most teams look at this event. A domain controller will hand password data to any principal holding the extended right DS-Replication-Get-Changes-All on the domain object, alongside DS-Replication-Get-Changes. Microsoft publishes the rights as 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (Get-Changes), 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (Get-Changes-All) and 89e95b76-444d-4c62-991a-0facbeda640c (Get-Changes-In-Filtered-Set). When Mimikatz lsadump or a similar tool asks a DC to replicate, the DC checks those rights and, if the domain root carries a matching audit entry, writes a 4662 with AccessMask 0x100 and the GUID inside Properties. MITRE tracks the behavior as T1003.006 and notes that members of Administrators, Domain Admins and Enterprise Admins, as well as DC computer accounts, can run it.

The sample on this page shows the shape: adm.lopez, a user account, using Control Access with the Get-Changes-All GUID against the domain object. Real tools produce a short burst, one event per right checked, inside a single second and one SubjectLogonId. One caution from the MITRE entry: lsadump also includes NetSync, which does the same job over a legacy replication protocol. Microsoft does not document the audit trail that path leaves, so test it in a lab before relying on the GUID filter alone.

4662 has no source address. It says who asked and which right was used, not from where. For DCSync that is the missing half of the story, because a request from a workstation and a request from a peer DC look identical in this event. Carry the SubjectLogonId to the 4624 on the same controller: a network logon (type 3) from an address that is not another domain controller is what separates an attack from replication.

Scope the SACL tightly. An audit entry on the domain root for the three replication rights, set for Everyone, is enough for DCSync and costs far less than auditing all property reads. A second entry on CN=AdminSDHolder,CN=System covering Write Property, WRITE_DAC and WRITE_OWNER watches the object that controls permissions on protected groups, another target Microsoft names for this event.

Start with who the Subject is. Domain controller computer accounts end in a dollar sign and replicate constantly, so they are the expected population for the replication GUIDs. The next group is directory synchronization: the MSOL_ account that Microsoft Entra Connect creates holds replication rights by design, and some migration, backup and identity-governance products ask for the same. Build the allowlist from the permissions on the domain object, not from what the log shows this week. A list built from the log quietly approves whatever the attacker did first.

A true positive reads like this: a user or service account that is not on the allowlist, AccessMask 0x100, one or more replication GUIDs in Properties, and a type 3 logon for the same SubjectLogonId from a workstation or server address, often an administrator account used outside its usual hours. Two replication GUIDs from one logon inside a minute is the tool-shaped version, and it is the cheapest rule to run first.

When you get a hit, the question that sets severity is how the account obtained the right. Accounts rarely hold DS-Replication-Get-Changes-All by accident; someone granted it. Look for a 5136 on the domain object changing nTSecurityDescriptor shortly before the first 4662, or a 4670 permissions change on the same object. An attacker with write access to the domain root's ACL can grant the right to an account they control, run DCSync, and remove the entry afterwards. The ACL change is evidence that survives even when replication events were never audited.

Treat a confirmed DCSync as domain-level exposure. The attacker can read any hash the directory holds, krbtgt included, so containment is about what that data enables, such as forged tickets and password reuse, and not about the one host the request came from. Scope the rest of the work with the 4768 and 4769 events that follow, looking for tickets requested by accounts whose passwords the actor now holds.

Failure events matter as well. A 4662 audit failure from a low-privilege account against a sensitive object is an attempt that did not work, often reconnaissance by a tool that probes rights before using them. Microsoft recommends Failure auditing for this subcategory on domain controllers, so you will usually have these even when Success is off.