One Access Incident, Multiple Trust Boundaries: Evidence to Decision

1. Core mechanism

This lesson combines earlier mechanisms in one case. 08.01 explained context lifetime, 10.07 replica views and 05.05 resource rights. Here you produce an evidence choice and decision rationale rather than accept a ready-made conclusion.

Interfaces and specifications

• Observation: record producer, time, identity and scope together.
• Hypothesis: it can explain the symptom but needs distinguishing evidence before acceptance.
• Intervention: it changes state owned by a particular actor; it does not refresh unrelated contexts automatically.
• Closure: evaluate trusted identity state, new resource behavior and legitimate workflow separately.

One observation, three explanations

At 09:00 the user belongs to Finance. At 10:00 membership is removed at DC-A. At 10:05 the file still opens. Candidate explanations are an old directory view, an old target session and another permission path granting READ. The symptom alone does not distinguish them.

Only the main cause changes across the three variants. A uses an old replica, B has a current replica but old target context, and C has current directory/context with READ granted by another ACE. The synthetic dossier reveals the distinguishing fact only when the relevant evidence card is opened.

Why choose this evidence next?

Checking the actual DC, naming context and object identity tests the replica hypothesis. If current, target-session creation and context age test the old-session explanation. If those are current too, inspect requested READ and its matching ACE or membership path.

4624 provides conditional evidence of target logon creation; 4769 concerns a ticket request at a KDC. Neither alone establishes file access or all effective permissions. State which questions the observation does not answer.

Predict intervention effects before acting

Restored replication can refresh a directory view without refreshing an open session context. Creating a controlled new context does not remove a right granted through another ACE. Each proposed action must name the hypothesis it addresses.

Group removal, password change and account disable are different actions. A fresh authentication attempt can face current account, policy and DC checks; continuation of an accepted session is separate. Avoid universal claims such as a TGT guarantees every future access or disable ends every session instantly.

Write the closure evidence

A sound finding separates symptom, tested hypothesis, observed effect, confidence and scope. “DC-B membership is current; the target reuses its 09:10 context” supports the old-session explanation. It does not establish user intent or access to every service.

Closure requires expected new behavior rather than merely a completed change: is unnecessary READ removed in a new context, can authorized users continue work, and are the relevant replica and identity trust verified? Object visibility after restore does not substitute for these criteria.

State and data flow

1. Bound the symptom by identity, resource, requested right and time.
2. Keep replica, old-context and alternate-permission hypotheses separate.
3. Choose directory evidence for the actual DC and target object.
4. Examine target-context creation time and the READ permission path.
5. Predict the selected intervention’s owner and state effects before revealing its outcome.
6. Verify closure through new behavior, identity trust and legitimate workflow.

2. Exploitation

Broken trust assumption

Treating one success record, group removal or restored visibility as proof of re-established trust.

Technical prerequisites

• An impact claim requires the relevant target, effective right and observed context.

Exploitation mechanism

Intervening at the wrong owner can hide a symptom while leaving the actual permission path intact. Discovering a right does not establish intent; actor and approved-change context remain separate. This case uses benign state observations.

Separate effect from intent

Opening the file is an observed effect. The user may be reusing an old session without knowing membership changed. Intent requires independent evidence beyond this outcome.

An incorrect intervention produces false closure

Clearing a ticket alone does not resolve an alternate permission path. Removing broad permissions without identifying the ACE and legitimate dependencies can disrupt work. Tie the recommendation to the narrowest established scope.

3. Defense & Detection

Telemetry scope

• Read each card’s producer, time, identity, scope and evidence boundary. Distinguish hypotheses using that data and record the rationale as well as the outcome.

Events and relevant fields

• Event records reflect their producer’s decision under applicable generation and collection conditions; they do not establish the entire access chain.

Preserve the scope of evidence

Read each card’s producer, time, identity, scope and evidence boundary. Distinguish hypotheses using that data and record the rationale as well as the outcome.

Do not treat an absent event as negative evidence without generation and collection coverage. Verify new behavior at its responsible owner.

Detection logic · XPath

*[System[(EventID=4768 or EventID=4769 or EventID=4624)]]

Query assumptions

• This selects candidate events only in applicable Windows Security logs. The lesson JSON worksheet is not a Windows event.
• Read each card’s producer, time, identity, scope and evidence boundary. Distinguish hypotheses using that data and record the rationale as well as the outcome.

False positives

• Legitimate changes, context/cache reuse or temporary connectivity issues can produce the same symptom; this selection does not classify an attack.

Hardening

• Establish the actual caller, target, DC and interval before using signals to claim certainty.
• Tie the change to its owner/state and verify both new context and legitimate workflow.
• Document remaining uncertainty and services outside the closure scope.

Read the examples

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "N04",
  "episode": "Finance membership removed, access continues",
  "facts": [
    "09:00 local token contains Finance SID",
    "10:00 DC-A membership removed",
    "10:03 DC-B same current membership",
    "10:05 resource reuses 09:10 session"
  ],
  "hypotheses": [
    "stale directory",
    "old target context",
    "another permission path"
  ],
  "nextEvidenceOptions": [
    "DC+NC+identity snapshot",
    "target session creation/context",
    "target requested right and matching ACE"
  ]
}

Two reality checks

Assumption: The same symptom means the same cause.

In fact: An old replica, old session or alternate ACE can produce the same READ outcome. Distinguishing evidence is required.

Assumption: The change completed, so the case is closed.

In fact: Verify expected new behavior, identity trust and authorized workflow separately. A completed operation does not substitute for them.

Sources

• Access tokens
  Access token contents; primary and impersonation tokens
• AD DS replication behavior
  Replication behavior overview
• Troubleshoot AD replication
  Dependencies; resolution methods; event/error tables; showrepl fields
• SSPI model
  SSPI Model paragraphs 1–3
• Choose hybrid authentication
  Scope; PHS/PTA/federation; business continuity and account-state timing
• Enterprise access model
  Control/management/data planes; privileged pathways; evolution from AD tiers
• AD forest recovery guide
  Guide scope and recovery planning overview