Correlating Sessions, Kerberos, and Directory Changes in Event Records.

1. Core mechanism

Correlation is not putting timestamps side by side. Time-based matching is always probabilistic; field-based matching, on the other hand, is accurate within certain limits. Knowing these limits determines the strength of an examination result. Logon ID is unique only in the machine that produced it and among reboots; The same numerical value on two different servers does not mean the same session. Logon GUID can establish a link between the session record on the client side and the ticket records in the domain controller in sessions created with Kerberos. On the index side, when a single LDAP operation changes multiple attributes, each change produces a separate record, and these records are grouped by a common operation correlation ID. The three mechanisms have different scopes and cannot be used interchangeably.

Interfaces and specifications

• Logon ID (TargetLogonId / SubjectLogonId): Session identifier generated on a login event and reappearing on subsequent events on the same machine. Records such as session closure and privilege usage are linked to the same session through this field.
• Scope of Logon ID: The value is unique only to the computer that generated it and across reboots. Equal values ​​on different machines do not indicate the same session.
• Logon GUID: An identifier generated in sessions with Kerberos that can be mapped to Kerberos ticket events in the domain controller. It may not have any meaningful value in non-Kerberos sessions.
• Kerberos event family: TGT and service ticket requests are recorded only on domain controllers; These records do not contain the session ID on the client side, the connection is established through different domains.
• Directory change records: The event generated when a directory object changes carries information of the session that made the change and the changed attribute; The operation correlation ID groups records resulting from the same operation.
• Access initiated with open credentials: When an account initiates a transaction with another account's credentials, it is recorded in a separate event family and is one of the breaking points in the chain.

In the same machine: logon ID chain

The most reliable correlation is established within a single machine. The logon ID generated when a session is opened reappears in the records of transactions made by that session. Closing the session, assigning privileged rights, and operations initiated under the session are chained together with this field.

The power of this chain comes from the fact that the field is an identifier: the match is not a guess, but a repetition of the same value. However, the scope is narrow. The value is unique only to the computer that generated it, and the same numerical values ​​can be reused when the machine is restarted. That's why the correlation key should always be considered together with the machine name and time range.

In practice, this means that a query should not be satisfied with the condition 'logon ID equals'. The correct query uses a combination of the computer name, logon ID, and a reasonable time window. Otherwise, unrelated sessions from different servers will be mixed in the same chain.

Machine to DC: Kerberos bridge

When a domain account logs in with Kerberos, records are created on two separate machines: the domain controller records ticket requests, and the accessed machine records the session creation. The logon GUID field in the session record is used to connect these two parties; The same value may also appear in Kerberos events on the domain controller side.

This bridge is strong but conditional. If the session did not occur with Kerberos, the field has no meaningful value and cannot be bridged. Additionally, in order to find the record on the domain controller side, the relevant control subcategory must be active in that DC and the correct DC must be looked at; In an environment with many DCs, the demand may be met by another DC.

If the bridge cannot be established, all that remains is intuitive matching via time and username. This matching produces a hypothesis, not evidence, and should be expressed as such in the report language.

Directory side: single transaction, multi-record

Index changes are often not represented by a single record. When a LDAP transaction changes multiple attributes, each attribute change is written as a separate event. What indicates that these records come from the same transaction is the operation correlation ID they share.

The same records also carry the credentials of the session that made the change. So 'which account changed which attribute of which object, in which session?' The question can be answered from a single record family. However, in order for these records to be created, the relevant subcategory must be active and the object must be within the scope of SACL.

The combination of three mechanisms is the basis for building an end-to-end event narrative: the session that made the directory change, the chain on the machine where that session was opened, and, if necessary, ticket records on the domain controller side. Each ring has its own condition and its own coverage limit.

State and data flow

1. The accessed machine is logged in and a logon ID is generated; this value appears again in subsequent records on the same machine.
2. If the session occurred with Kerberos, the record carries a logon GUID; the same value can be looked up in the ticket events of the domain controller that satisfies the request.
3. When the user makes a change to the directory, the domain controller that processes the change produces the change record, and the record carries the information of the session that made the change.
4. If a single index operation changed multiple attributes, the resulting records are grouped by a common operation correlation ID.
5. When the chain breaks due to explicit credential-initiated access or an out-of-scope audit setting, the break point is clearly indicated in the report; time-based matching is marked as hypothesis.

2. Exploitation

Broken trust assumption

Assumption: “If the username and timestamp are the same, these records belong to the same event.” It follows that a causal narrative can be established by lining up session, ticket and directory change records from different machines side by side in a single timeline.

Technical prerequisites

• Correlation rules are based solely on account name and time window; Descriptive fields in records are not used.
• Queries do not include the computer name in the match key because Logon ID is not known to be unique at the machine scope.
• There are multiple domain controllers in the environment, but which DC meets the demand is not considered in the analysis.
• It is not known whether directory change records can be replicated from a single transaction; Each registration is considered a separate action.
• Clock synchronization and timestamp behavior of different sources has not been verified.

Exploitation mechanism

The error is that a probabilistic match is reported as an exact match. The username appears in many records; the same account can be represented on multiple machines, multiple service ticket requests, and multiple directory reads within the same minute. Combining these records by looking only at the name and time produces a narrative as if there was a single action. The second source of error is scope confusion: since logon ID is unique on the generating machine, unrelated sessions from different servers are chained together when the hostname does not participate in the match. The third source of error is count bloat: when a single index operation changes multiple attributes, separate records are created for each attribute; When the operation correlation ID is not used, this reads like many separate changes. The fourth is to make invisible the points where the chain actually breaks: a non-Kerberos session has no logon GUID bridge, and a record that never occurred due to an out-of-scope control setting appears in the timeline as an absence, not a gap. This lesson does not describe an attack technique; What is being said is that the strength of the correlation claim varies depending on the domain used.

Separate identifier from heuristic matching

There are two types of statements in an inspection report: 'bears the same identifier' and 'appears in the same time period'. First, it is a definitive link within the scope of the field. The latter is a hypothesis and needs to be supported by other evidence. Writing both with the same sentence structure reduces the evidentiary value of the report.

The rule of thumb is this: when writing a correlation rule, first specify which field is descriptive and what its scope is. The scope for Logon ID is the machine; The condition for logon GUID is a session with Kerberos; The scope for the operation correlation ID is a single index operation.

Mark the chain break points in advance

Every chain has known breaking points. When one account initiates a transaction with another account's credentials, it changes the direct link between the session chain and subsequent activity. In an environment where there are many domain controllers, another DC may have met the ticket request. If the control subcategory is closed or the object is outside of SACL scope, the expected ring does not occur at all.

When these breaking points are known before the analysis, when he sees a gap, the analyst asks the right question: 'why is this ring missing?' The answer is often not attacker behavior but telemetry coverage. Separating the two situations in the report prevents producing incorrect results.

Count operations, not numbers

The most common distortion of index change metrics is mistaking the number of records for the number of actions. When several attributes are changed in a single operation, the number of records increases severalfold. The 'this many index changes today' metric produced without using the operation correlation ID does not reflect the actual number of transactions.

The same problem occurs with threshold-based alerts. Thresholds set without per-transaction grouping produce false positives in a routine batch update and reduce rule reliability over time.

3. Defense & Detection

Telemetry scope

• In the correlation rules, write the match key explicitly: the computer name and logon ID together, not just logon ID.
• In rules using the Kerberos bridge, record whether the session occurred with Kerberos and which domain controller was looked at.
• Group by operation correlation ID in index change analyses; Report metrics on a transaction-by-transaction basis, not by record.
• Track access initiated with open credentials as a separate record family; These are the known breaking points in the chain.
• Regularly verify synchronization of time sources; correlation windows are sensitive to clock drift.
• Keep a scope note for each correlation rule: which field is identifier, which match heuristic, under which condition the rule remains silent.

Events and relevant fields

• The same logon ID value seen on two different machines does not mean the same session; Value is unique only in the machine that produces it.
• The absence of a meaningful logon GUID in the session recording is not an anomaly; This bridge cannot be established in non-Kerberos sessions.
• Failure to find a ticket record on the domain controller side does not indicate that the session did not occur; The request may have been met by another DC or the relevant subcategory may have been closed.
• A large number of directory change records does not imply a large number of separate actions; A single operation can produce multiple attribute records.
• The proximity of timestamps does not establish causality; If there is no domain-based link, the relationship remains hypothesized.

Identify the key before writing the rule

The quality of a correlation rule is the quality of the key it uses. If the key is an identifier, the rule will be narrow and reliable; If the key is only account name and time, the rule will be broad and noisy. Therefore, the first step in rule writing is key selection, not query.

The choice of key also determines the limit of the rule. Session ID operates within the machine; An inter-machine assertion requires another bridge. When this limit is written into the rule document, the results that the rule does not produce become clear.

Present the narrative with its rings

When presenting an event narrative, the evidence on which each link is based is shown separately: which record is connected to the previous one with which area, which connection is based only on proximity in time. This representation directly conveys to the reader at what point the narrative weakens.

A narrative thus presented remains updateable with subsequent information. If the weak link is marked, only that link is re-evaluated when a new record source is added; The entire result does not have to be reconstructed.

Detection logic · KQL

let window = 1h;
let logons = SecurityEvent
| where TimeGenerated > ago(window) and EventID == 4624
| project LogonTime = TimeGenerated, Computer, TargetUserName, TargetLogonId;
SecurityEvent
| where TimeGenerated > ago(window) and EventID == 4672
| project PrivTime = TimeGenerated, Computer, SubjectUserName, SubjectLogonId
| join kind=inner logons on $left.Computer == $right.Computer, $left.SubjectLogonId == $right.TargetLogonId
| project LogonTime, PrivTime, Computer, TargetUserName, TargetLogonId

Query assumptions

• This query is a format only example and has not been run on any platform in this session; Table and field names vary depending on the aggregation solution used.
• The merge key intentionally uses the computer name and session ID together; Joining via session ID alone confuses different machines.
• The query only builds the chain within the same machine; Kerberos records on the domain controller side are not included in this result.
• If the relevant subcategories are not active or the records are not forwarded to the hub, the query will silently return empty.

False positives

• Routine sessions for service accounts appear along with privilege assignment records; This is an expected pattern.
• Planned operation of management tools can produce large numbers of matches in short intervals.
• Negative example: the same numeric session ID can be used again after the machine is rebooted; Without a narrow time window, old and new sessions can mix.
• In a clock-skewed source, the order of events may appear incorrect and causal interpretation is distorted.

Hardening

• Document correlation rules along with domain coverage; Write under what conditions each rule applies.
• Always include the computer name in the match key in queries that establish a session chain.
• Group directory change alerts by process; Set thresholds based on number of transactions rather than number of records.
• Monitor time synchronization for critical resources; When deviation is detected, re-evaluate the correlation results of the relevant period.
• Keep 'same identifier' and 'same time period' separate in report language; Write the hypothesized bonds as hypotheses.
• Write the known breaking points of the chain in the analyst guide; When a gap is detected, the telemetry scope is first queried.

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-01T08:12:33.0000000Z"/><EventRecordID>1502001</EventRecordID><Channel>Security</Channel><Computer>dc03.outreason.example</Computer><Security/></System><EventData><Data Name="OpCorrelationID">{3f2b08c4-5d61-4a7e-9f03-2c8b14ad6e51}</Data><Data Name="SubjectUserName">ops-admin</Data><Data Name="SubjectDomainName">OUTREASON</Data><Data Name="SubjectLogonId">0x5f21c9</Data><Data Name="ObjectDN">CN=Reports Service,OU=Service Accounts,DC=outreason,DC=example</Data><Data Name="ObjectClass">user</Data><Data Name="AttributeLDAPDisplayName">servicePrincipalName</Data><Data Name="OperationType">%%14674</Data></EventData></Event>

Two reality checks

Assumption: Logon ID is a unique session ID; Every record where I see the same value belongs to the same session.

In fact: No. Logon ID is unique only to the computer that produced it and across reboots. Seeing the same numerical value on two different servers does not mean the same session, and the values ​​can be reused after a machine reboot. Therefore, any query that establishes a session chain must include the computer name and a reasonable time window in the match key. A cross-machine assertion requires a different bridge, for example the logon GUID field in sessions originating with Kerberos.

Assumption: The number of directory change records gives the number of changes made.

In fact: No. When a single index operation changes multiple attributes, each attribute change produces a separate record; These records carry a common operation correlation ID and the actual number of transactions is found by grouping them with this ID. Moreover, in order for records to be created, the relevant control subcategory must be active and the object must be within the scope of SACL; Out-of-scope changes are not recorded at all. Therefore, the raw number of records is neither an accurate measure of the number of actions nor the total volume of changes.

Sources

• Microsoft · 4624(S) An account was successfully logged on
  Use of the Logon ID field to associate events on the same computer; The logon GUID field can be mapped to Kerberos events in the domain controller; logon type descriptions.
• Microsoft · 4634(S) An account was logged off
  Use of the Logon ID field for backward attribution to the login event.
• Microsoft · 5136(S) A directory service object was modified
  EventData fields: OpCorrelationID, SubjectUserName, SubjectLogonId, ObjectDN, ObjectClass, AttributeLDAPDisplayName, OperationType; Constants %%14674 Value Added and %%14675 Value Deleted.
• Microsoft · Audit Directory Service Changes
  The subcategory is only valid for domain controllers and the SACL condition.
• Microsoft · 4769(S, F) A Kerberos service ticket was requested
  Event generation only in domain controllers and service ticket request fields.
• Microsoft · Audit Special Logon
  Event family and session ID field indicating the assignment of special privileges.