Comparing Configuration with Effective Behavior: Evidence Quality and False Positives.

1. Core mechanism

This lesson follows the path from a setting to an outcome. Which DC supplied the value, when was it collected, and on which target did it take effect? Keep a configuration snapshot separate from runtime observations, and evaluate each item with its source, time and scope.

Interfaces and specifications

• Configured state: the value written in the directory, registry, GPO or service configuration.
• Effective state: the setting in effect on the target after scope, precedence, inheritance and local conditions have been evaluated.
• Observed behavior: an operation observed for a particular principal and target within a defined time interval.
• Telemetry coverage: operations visible within the audit-policy, SACL, collector, retention and query scope.
• Provenance: the system, time and method from which a record was collected.
• Confidence: describing the strength of a conclusion by distinguishing direct evidence, correlation and missing information.

The setting was written; what happened on the target?

Writing an attribute can change its directory value. Another DC converging on that value, GPO scope evaluation, token renewal or a service rereading the setting are separate steps. Which steps matter depends on the setting being examined.

For a covered directory change, 5136 can identify AttributeLDAPDisplayName and AttributeValue. It does not establish that a client received the value or changed its behavior; a separate target observation is needed.

Many records do not mean independent verification

Record the source identity, UTC time, object identity, collection method and known gaps alongside the evidence. Many records with the same Event ID are not independent verification on their own; all may be affected by the same collection problem.

Evaluating an alert involves more than labeling activity malicious or benign. The query may select a broader candidate set than intended; an authorized change, an old configuration snapshot or missing context can support different explanations.

State and data flow

1. Record the intended setting and the change evidence.
2. Identify the steps needed for this setting to reach and take effect on the target.
3. Check the effective state for the chosen principal and target through a separate observation.
4. Observe runtime behavior and user impact within the same time interval.
5. State the missing evidence and alternative explanations when drawing the conclusion.

2. Exploitation

Broken trust assumption

A suspicious or erroneous operation may have changed the setting. A single change record establishes neither effective misuse nor user impact.

Technical prerequisites

• The object, attribute, subject and correlation fields are retained with the change record’s provenance.
• Replication, policy-evaluation and runtime conditions required for the claimed behavior are identified separately.

Exploitation mechanism

Inspecting only a written setting can miss a stale replica or a precedence difference. Inspecting only the change event can make an unapplied setting look effective. The Red perspective also evaluates the change, its application and its outcome through separate evidence.

One record can lead to two different mistakes

A configuration snapshot from one DC can look correct while another DC still shows an older value. A suspicious change record can exist while another policy takes precedence on the target. Check these possibilities at the relevant sources.

State both what was observed and what it does not prove. A severity label does not fill an evidence gap.

3. Defense & Detection

Telemetry scope

• Retain the configuration snapshot with its source DC, object GUID/DN, attribute and UTC collection time.
• Correlate the change record with the effective-state observation without presenting them as the same kind of evidence.
• Check audit policy, SACL coverage, collector health, retention and clock differences.
• Even for an authorized change, evaluate runtime verification and rollback conditions separately.

Events and relevant fields

• 5136 records a directory change within the applicable audit and SACL scope; it does not by itself establish policy application on an endpoint or its security impact.
• A missing event does not prove that no change occurred; audit policy, SACL, collection or retention may be incomplete.

5136 shows the change, not the target’s behavior

The synthetic example is a Value Added record for msDS-SupportedEncryptionTypes on a computer object. The parser displays fields; it does not compute the endpoint’s negotiated Kerberos encryption type, replication convergence or setting application.

These are complementary forms of evidence: the directory record describes the change, while a target observation describes the behavior.

Detection logic · XPath

*[System[(EventID=5136)]]

Query assumptions

• The query selects 5136 candidates. Narrow them by object, attribute and OperationType; this example was not executed against a live Event Log.
• Effective state and runtime outcomes require observations separate from the change record.

False positives

• Authorized administration and automation changes can produce the same event.
• One change can have a Value Deleted record and a Value Added record; do not count these as two independent incidents. Check replication freshness through separate sources rather than treating replication itself as the cause of duplicate 5136 records.

Hardening

• Verify critical written settings alongside target effective state and observed behavior.
• Do not classify directory changes solely by an object/attribute list; also examine the responsible role, change window and correlation context.
• Use separate health checks for collector clocks, audit coverage and retention problems.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Security-Auditing"/><EventID>5136</EventID><Version>0</Version><Level>0</Level><TimeCreated SystemTime="2026-10-01T10:24:00.0000000Z"/><EventRecordID>1504001</EventRecordID><Channel>Security</Channel><Computer>dc01.outreason.example</Computer><Security/></System><EventData><Data Name="OpCorrelationID">{15A40000-0000-4000-8000-000000000001}</Data><Data Name="AppCorrelationID">-</Data><Data Name="SubjectUserSid">S-1-5-21-1987654321-1234567890-2468013579-1106</Data><Data Name="SubjectUserName">kayra</Data><Data Name="SubjectDomainName">OUTREASON</Data><Data Name="SubjectLogonId">0x15a4</Data><Data Name="DSName">outreason.example</Data><Data Name="DSType">%%14676</Data><Data Name="ObjectDN">CN=APP01,OU=Servers,DC=outreason,DC=example</Data><Data Name="ObjectGUID">{15A40000-0000-4000-8000-000000000002}</Data><Data Name="ObjectClass">computer</Data><Data Name="AttributeLDAPDisplayName">msDS-SupportedEncryptionTypes</Data><Data Name="AttributeSyntaxOID">2.5.5.9</Data><Data Name="AttributeValue">24</Data><Data Name="OperationType">%%14674</Data></EventData></Event>

Two reality checks

Assumption: If the right value appears in the directory, every client must behave correctly.

In fact: The written value is the starting point; replication, scope, precedence and runtime evaluation affect the target outcome.

Assumption: A security event confirms the claim; its absence refutes the incident.

In fact: The meaning of an event and conclusions drawn from its absence depend on audit, SACL, collection and retention coverage.

Sources

• Microsoft · 5136(S): A directory service object was modified
  Event XML, field descriptions and Value Added/Value Deleted operation types.
• Microsoft · Audit Directory Service Changes
  Audit subcategory and SACL-dependent directory change visibility.