Scoping a Suspicious Situation: Isolation, Identity Trust, and Recovery Priorities.

1. Core mechanism

This lesson separates incident triage from forest recovery. Avoid irreversible bulk changes while the scope remains uncertain. Microsoft's guide treats total forest recovery as a last resort in many cases; the decision involves business stakeholders.

Interfaces and specifications

• scope: affected identity, DC, domain, forest, admin tier, time window and dependent service set.
• identity trust: the conditions under which credentials, tickets, keys, privileged accounts and management workstations can be trusted.
• containment: a boundary that reduces spread or unauthorized access while preserving evidence and critical dependencies.
• isolation: controlled separation of an investigated or recovered system from untrusted network and identity paths.
• recovery priority: the dependency order of the identity control plane, name resolution, time, replication and business authentication.
• decision gate: an explicit threshold for revisiting containment or recovery when scope or evidence changes.

Scope is broader than a device list

A suspicious change on one DC may not be limited to that host; replicated directory data, privileged sessions, trust relationships, and backup custody also fall within the investigation scope. By contrast, a single endpoint alert is not evidence of forest compromise.

The timeline starts before the first known malicious behavior: examine credential issuance, admin logons, directory changes, log gaps and replication directions together. Missing evidence does not establish a clean period, especially when logs were cleared or a collector was absent.

Isolation and recovery are different decision gates

Isolation should close untrusted paths and create a reliable observation boundary. Separating a DC without understanding DNS, time and management dependencies can create more blind spots or an authentication outage. Identify the owner, rollback path and out-of-band access beforehand.

The forest recovery guide recommends first determining the problem and scope, evaluating full recovery as a last option, and, if recovery is needed, recovering one DC for each domain in isolation and resetting privileged accounts. This order is not an automatic playbook; it is a decision framework adapted to the environment.

State and data flow

1. Separate the roles of incident commander, evidence owner and identity recovery authority.
2. Record the affected principals, DCs, domains or forest and the untrusted time window as a hypothesis.
3. Choose containment without conflating evidence preservation with the goal of limiting spread.
4. Verify identity-control-plane dependencies and the trusted backup or recovery source.
5. Use evidence to choose object, DC, domain or forest recovery; revisit credential resets and business validation at each stage.

2. Exploitation

Broken trust assumption

A directory change, privileged credential misuse or DC compromise is suspected; the attacker's scope and persistence path have not yet been established.

Technical prerequisites

• Owners of critical authentication, DNS, time and management dependencies have been identified for the containment decision.
• Evidence copies are access-controlled, timestamped and preserved with their original source information.

Exploitation mechanism

In an identity incident, untrusted credentials and replicated state may remain effective even after containment. Shutting down only the host does not end ticket/key risk; only performing a bulk password reset also does not fix an untrusted admin path or malicious directory state.

Rushed recovery can carry the attacker’s path back

Restoring before validating scope and the trusted backup time can carry malicious state or credential risk into the recovered environment. Deleting everything can also destroy the incident timeline and business recovery options.

The decision record explains which trust assumption failed, which evidence supports that conclusion and what the next decision gate is.

3. Defense & Detection

Telemetry scope

• Keep principal, host/DC, domain/forest, admin tier, time window and confidence as separate fields in the scope ledger.
• Record each containment action's owner, approval, UTC time, expected impact and rollback path.
• Verify backup custody, backup time, encryption-key access and restore-test status before deciding on recovery.
• Mark a Security log gap or clear event as lost evidence coverage; do not automatically infer compromise or innocence.

Events and relevant fields

• 1102 records that the Windows Security audit log was cleared. Subject details in a full event can support correlation, but the event alone does not explain the previous activity.
• A log clear can be maintenance or deliberate removal of evidence; an unexpected clear on a high-value DC calls for prompt investigation.

A log gap broadens investigation, not the conclusion

The synthetic 1102 envelope identifies the log-clear event and its time in the Security channel. The parser does not model subject details inside UserData; this example therefore makes no claims about absent subject fields.

This artifact's role is to expose the visibility gap in the investigation timeline. Recovery scope is still selected independently with identity, directory, and host evidence.

Detection logic · XPath

*[System[(EventID=1102)]]

Query assumptions

• The Security channel is accessible, and event-forwarding and retention coverage are documented.
• The query selects candidates for an evidence gap; other telemetry and directory state determine incident scope.

False positives

• Authorized maintenance or testing may have cleared the log.
• The event alone is not evidence of credential theft, persistence or forest compromise.

Hardening

• Forward DC and privileged-management logs to a collector with separate access controls, and monitor forwarding delays.
• Use tiered administration, separate recovery credentials and controlled custody of offline or immutable backups.
• Rehearse the forest recovery plan regularly; keep isolation, DNS/time and business-validation steps specific to the environment.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Eventlog" Guid="{fc65ddd8-d6ef-4962-83d5-6e5cfe9ce148}"/><EventID>1102</EventID><Version>0</Version><Level>4</Level><Task>104</Task><TimeCreated SystemTime="2026-10-01T10:41:00.0000000Z"/><EventRecordID>1505001</EventRecordID><Channel>Security</Channel><Computer>dc02.outreason.example</Computer><Security/></System></Event>

Two reality checks

Assumption: If one DC is suspicious, the first trusted step is to restore the entire forest immediately.

In fact: Determine the problem and scope first. Full forest recovery is a last resort in many cases and should not start without validating a trusted backup and business impact.

Assumption: Completing isolation automatically restores identity trust.

In fact: Isolation limits spread; trust in credentials, tickets and keys, directory state, backup custody and administration paths must also be re-established.

Sources

• Microsoft · AD Forest Recovery - Steps for Restoring the forest
  Identify scope first; total forest recovery as a last option; recover one DC per domain in isolation; reset privileged accounts.
• Microsoft · AD Forest Recovery - Identify the problem
  Forest-wide failure examples and requirement to determine cause, scope and remedies.
• Microsoft · 1102(S): The audit log was cleared
  Event description, XML envelope and monitoring recommendation.