Event ID 5136: A directory service object was modified

Event 5136 is the directory change record of the Audit Directory Service Changes subcategory. A domain controller writes it every time an attribute of an Active Directory object is modified, provided the object carries a SACL entry that audits Write on that attribute. One Microsoft caveat: some objects and properties do not generate audit events at all because of settings on the object class in the schema. The subcategory only logs on domain controllers, volume is high there, and Microsoft recommends Success auditing for it. It has no failure events. If you want to see attempts that were refused, you have to look at the Directory Service Access subcategory and its 4662 failures.

A single change is not a single event. Microsoft describes the typical pattern as two 5136 events per action, one with OperationType Value Deleted (%%14675) holding the previous value and one with Value Added (%%14674) holding the new one. OpCorrelationID is the same on both, and it is also shared with any 5137 or object-move event produced by the same LDAP operation. Alert on Value Added because it carries the new value, then join to the Value Deleted event with the same correlation ID when you need the before picture. Adding one value to a multi-valued attribute such as servicePrincipalName produces only the Value Added half.

The fields describe the object and the change. DSName is the domain and DSType is Active Directory Domain Services. ObjectDN is the distinguished name, ObjectGUID is the immutable identifier you can resolve with an LDP search after reordering its bytes, and ObjectClass is the schema class, such as user, group, domainDNS or groupPolicyContainer. AttributeLDAPDisplayName names the attribute, AttributeSyntaxOID gives its storage type (2.5.5.12 is a Unicode string, 2.5.5.9 an integer, 2.5.5.15 a security descriptor, 2.5.5.1 a distinguished name) and AttributeValue holds the value. AppCorrelationID is always a hyphen. Like 4662, the event has no source address; take SubjectLogonId to the 4624 on the same controller to find where the LDAP bind came from.

In the sample, j.smith, a standard user, adds the servicePrincipalName HTTP/inv-update.corp.socsimulator.example to the service account svc.inventory. An SPN on a user account makes that account a Kerberoasting target (MITRE T1558.003): the attacker asks for a service ticket and cracks it offline. The 4769 service ticket requests for that SPN that follow are the second half of the story. Nobody sets an SPN on a service account by accident, and the Subject is not an administrator.

Build a watchlist of attributes instead of auditing everything. servicePrincipalName on user objects covers targeted Kerberoasting. msDS-AllowedToActOnBehalfOfOtherIdentity and msDS-KeyCredentialLink are written to let a controlled principal act as, or authenticate as, the target; legitimate writers are rare enough to review each one. nTSecurityDescriptor on the domain root, the AdminSDHolder object and the privileged groups records ACL changes, which is how an account is granted replication rights before a DCSync that the 4662 page covers. gPLink on an OU or the domain links a Group Policy Object, and versionNumber on a groupPolicyContainer changes when someone edits a GPO.

That last point has a blind spot. MITRE notes that a GPO is a container plus files in the SYSVOL Policies folder, and the settings that do the damage, such as a scheduled task added to ScheduledTasks.xml, live in those files. A 5136 shows the link and the version bump, not the content. Pair it with file auditing on SYSVOL, 4663 or 5145, if you want the setting itself.

Event 5137 is the creation half of the same design, which is why it lives on this page. It fires when an object is created, but the SACL sits on the parent: an entry that audits the Create action for a class, for example creating Computer objects in an organizational unit. The fields match 5136 without the attribute and operation fields, and ObjectDN is the new object. Microsoft advises against auditing every creation; choose important containers and a few classes. Three are worth the cost. Computer objects created by anyone outside your provisioning accounts matter because the default machine account quota lets any authenticated user add computers, and a self-made computer account is a common first step in delegation attacks. New groupPolicyContainer objects mean a new GPO. And server or nTDSDSA objects in the Configuration partition are how a rogue domain controller registers itself, which MITRE lists among the detections for T1207.

Directory changes are mostly legitimate, so context decides. Computers register and refresh their own SPNs, which shows up as the computer account writing servicePrincipalName on itself. Provisioning and identity tooling updates dozens of attributes per joiner. Administrators use consoles that rewrite several attributes per click, and GPO owners link policies during change windows. Keep an allowlist of provisioning accounts, split by attribute, and a way to match changes against approved tickets.

The true positives have a different look. The Subject is an ordinary user or a service account writing an SPN or a delegation attribute on another account. An nTSecurityDescriptor value is added to the domain root by someone outside Domain Admins. A gPLink lands on the domain object or the Domain Controllers OU outside any change window. A 5137 for a computer object by a standard user is followed within minutes by a 5136 on a different computer's msDS-AllowedToActOnBehalfOfOtherIdentity under the same SubjectLogonId. Because OpCorrelationID and SubjectLogonId link these, you can chain them without guessing.

Triage in four moves. Read the Deleted and Added pair to see what changed. Check the Subject against the change record. Take SubjectLogonId to the 4624 to find the source address and authentication package. Then follow the consequence: 4769 requests for a newly set SPN, 4662 replication rights after an ACL change, or a Group Policy refresh effect on the hosts under the linked OU. If an SPN was added to a user account, treat that account's password as exposed to offline cracking and rotate it after you restore the previous value.

Coverage is where this event fails quietly. The SACL decides what is recorded and a missing entry looks exactly like a quiet directory. Make a harmless test change on a monitored object, such as a description on a test user, and confirm that a Value Added event arrives from every domain controller you collect. Any controller can accept the write, so collect the log from all of them and not just the one you happen to query.