Reconstructing Scope, Sequence, and Alternative Explanations

Reconstructing Scope, Sequence, and Alternative Explanations

Move from a chronological record to defensible conclusions about affected entities, causal sequence, common versus mixed causes, and the evidence that would change scope or containment decisions.

Estimate scope through entities, behavior, and visibility

Incident scope is an assessment about which entities, behaviors, relationships, and consequences belong to the activity under investigation. It is not simply the number of alerts or artifacts collected. A defensible scope estimate combines positive evidence, negative evidence under adequate visibility, entity relationships, temporal boundaries, and explicit uncertainty.

Operational scope should answer:

• Which entities are confirmed affected?
• Which are suspected, and why?
• Which related entities show no relevant activity under adequate visibility?
• Where is visibility insufficient to assess status?
• Which behaviors and objectives have been observed, inferred, or ruled against?
• Which business services, identities, partners, or data could be exposed?
• Which evidence would expand or narrow the current scope?

Use multidimensional scope

A single list of “affected systems” is rarely enough. Track scope across dimensions:

One entity can be confirmed in one dimension and uncertain in another. Host A may be confirmed affected by script execution, while successful credential extraction and downstream identity use remain unknown.

Assign evidence-based entity states

Use nuanced categories:

Always attach the behavior, period, and visibility to a clearance statement:

Host D is cleared for the observed interpreter-to-task sequence between 08:30 and 13:00 UTC based on complete endpoint process and task telemetry. This does not rule out other behaviors or earlier activity.

Build an entity-behavior-visibility matrix

For Project Lantern:

The matrix prevents “no alert” from becoming “not affected” and shows which gaps limit containment decisions.

Scope through relationships, not labels

Expand scope when evidence connects an entity to relevant behavior—not merely because it shares a broad attribute.

Strong relationships may include:

• the same or derived payload with compatible delivery and execution timing;
• a shared account, token, or session sequence linked to affected activity;
• a full or materially similar behavior chain;
• direct process, file, task, message, or authentication ancestry;
• infrastructure active during the event window and used in the same behavioral context;
• a service dependency that an affected identity accessed during the assessed period.

Weak relationships include:

• a common administration tool;
• one shared hosting address;
• a generic technique used by many actors;
• similar filenames without content or execution context;
• organizational proximity alone;
• an external actor label applied to both events.

Treat weak relationships as leads until additional evidence makes them decision-relevant.

Define the scope window dynamically

The initial time window should cover plausible precursor and follow-on activity, but expansion should be evidence-driven.

Ask:

• What is the earliest confirmed or suspected relevant event?
• Which prerequisite behavior could have occurred earlier?
• Which persistence or identity activity could continue later?
• How far does suitable evidence retention extend?
• Did defender action change later observability?
• Which external reports describe a compatible historical window?
• Would expanding the period change the operational decision?

For Project Lantern, the initial visible sequence begins with messages at 09:06. Evidence that one account authenticated unusually at 07:40 may expand identity scope backward if the session is plausibly related. A generic failed sign-in from the previous month should not expand the incident without stronger linkage.

Distinguish compromise, exposure, and consequence

These terms answer different questions:

• Compromise or affected status: Evidence supports relevant unauthorized activity on an entity.
• Exposure: A plausible pathway or condition could allow harm, but activity is not established.
• Consequence: Business, legal, privacy, safety, or operational impact occurred or could follow.

An account may be exposed because a host accessed its credential store without evidence that credentials were successfully extracted. A payment service may be exposed because the account had access, without evidence that the service was entered. Communicate these layers separately to prevent speculative scope from becoming confirmed impact.

Use negative evidence carefully

Negative evidence can narrow scope when the expected observation should have appeared and visibility was suitable.

Before treating absence as evidence, document:

1. The behavior expected under the hypothesis
2. The source capable of observing it
3. Entity and period coverage
4. Query or examination method
5. Retention and ingestion health
6. Evasion or tampering possibilities
7. Expected benign and false-negative conditions

Example:

No matching scheduled-task creation was found on Host B. Task telemetry was complete for the assessed window, so persistent use of the observed task mechanism is unlikely on Host B. This does not rule out other persistence methods.

This is stronger than “No persistence occurred.”

Separate detection coverage from incident scope

A hunt may cover 92 of 104 endpoints. Its result describes those 92 endpoints under the query’s logic—not the entire finance environment.

Report:

• population intended for search;
• entities actually searched;
• source and field coverage;
• query version and behavior represented;
• true, partial, and benign matches;
• entities excluded or unavailable;
• behaviors the query cannot detect;
• validity period of the result.

Use explicit denominators:

Query v3 searched 92 of 104 in-scope endpoints. Eight lacked command-line capture and four were offline. No additional full-sequence matches were found; three partial matches require triage.

Avoid “No other affected hosts were found” when 12 endpoints were not adequately evaluated.

Connect scope to containment options

Scope categories should guide proportionate choices:

Intelligence does not dictate one action. The decision owner combines the scope assessment with impact, urgency, reversibility, service continuity, and risk tolerance.

Project Lantern scope update

At the 13:20 information cutoff:

• Confirmed affected: Hosts A and B, with related message and execution evidence.
• Suspected: Payment account P-7 because of timing and account relevance, though direct credential linkage is absent.
• Related, not affected within current visibility: Host D received a related message but complete endpoint evidence shows no execution.
• Host C: Initially suspected because of a partial process match. A signed approved package, matching maintenance window, and owner confirmation explain the complete behavior, so Host C is removed from suspected incident scope.
• Limited visibility: Twelve endpoints lack fields required for the full behavioral query.
• Exposed service: Payment support is potentially exposed through P-7, but access or harm beyond the sign-in is unconfirmed.

The updated scope supports targeted identity containment and additional collection rather than immediate isolation of the whole finance segment.

Scope review checklist

Before stating scope, confirm:

• Scope is tracked across hosts, identities, behaviors, services, time, dependencies, and information where relevant.
• Confirmed, suspected, exposed, related, cleared, limited-visibility, unknown, and out-of-scope states are distinguishable.
• Every status identifies the evidence, behavior, period, and coverage supporting it.
• Weak associations are not treated as compromise.
• Time-window expansion is evidence-driven.
• Compromise, exposure, and consequence are communicated separately.
• Negative evidence is supported by suitable visibility.
• Search denominators, exclusions, query limitations, and partial matches are reported.
• Scope expansion and narrowing conditions are explicit.
• Operational options reflect uncertainty and reversibility.

Key takeaways

• Incident scope is a multidimensional judgment, not an alert count or artifact list.
• Use evidence-based entity states and attach behavior, time, and visibility to every status.
• Expand scope through meaningful behavioral and relational evidence rather than broad similarity.
• Distinguish confirmed compromise, plausible exposure, and actual or potential consequence.
• Negative evidence narrows scope only when collection could reveal the behavior.
• Report search coverage with explicit denominators and limitations.
• Connect scope uncertainty to proportional containment, collection, and review choices.

Analyst habit: Never write “no other systems were affected” without naming the population examined, behavior sought, time window, coverage, and remaining blind spots.

Compare reconstructions and target decisive evidence

Incident reconstruction moves beyond chronology by comparing explanations for the observed evidence. The analyst asks which reconstruction best accounts for sequence, entities, relationships, gaps, and defender actions—and which obtainable evidence could most change the operational decision.

For Project Lantern, four reconstructions remain plausible:

• R1 — Coordinated malicious operation: Related messages produced similar host activity, credential access, and subsequent identity use.
• R2 — Authorized activity plus unrelated suspicious messages: Approved administration explains the host sequence; message and identity events are separate.
• R3 — Telemetry or processing error: Duplication, parsing, clock misalignment, or source defects created false relationships.
• R4 — Mixed causes: Hosts A and B share malicious activity, while Host C and some identity events are benign or unrelated.

These are reconstructions of what occurred, not actor attributions.

Compare expected evidence

For each reconstruction, state what should be present if it is correct:

The table identifies diagnostic evidence. Many observations are compatible with several reconstructions and therefore contribute little by themselves.

Use sequence constraints

A reconstruction must respect established temporal and mechanistic constraints.

Ask:

• Could the proposed cause occur before the observed effect after clock uncertainty is considered?
• Does the source establish process, file, message, or session ancestry?
• Are claimed dependencies technically possible in the environment?
• Did a defender action interrupt or create the later sequence?
• Does the reconstruction require an unobserved step, and was that step observable?
• Can one event plausibly explain several observations, or are multiple causes required?

Project Lantern establishes that the archive opened before the interpreter sequence on Host A and that the scheduled task referenced the extracted script. It does not establish that credential material left the host or enabled the payment sign-in. A reconstruction that states “stolen browser credentials caused the sign-in” exceeds current evidence.

Test causal links explicitly

Use a causal-link record:

A chain is only as strong as its weakest consequential link. One unsupported step may be decisive for account containment or notification.

Identify load-bearing assumptions

A reconstruction often depends on assumptions such as:

• endpoint clocks are aligned within the modeled range;
• process ancestry is complete and authentic;
• the authorized software inventory is current;
• the payment account maps to the affected user’s credential context;
• identity telemetry captures the relevant authentication path;
• Hosts A and B did not receive the same package through a legitimate channel;
• shared infrastructure relationships were active during the incident window.

For each assumption, ask:

1. Which reconstruction depends on it?
2. What supports it?
3. How could it be tested?
4. Would failure change likelihood, confidence, scope, or action?

If the answer to the fourth question is yes, prioritize it.

Prefer discriminating collection

A priority gap has different expected answers under competing reconstructions and can change a decision.

Avoid low-value collection such as gathering more reputation scores for a domain when direct host and identity evidence can distinguish the leading reconstructions.

Evaluate mixed causes deliberately

Analysts often assume all observations share one cause. Mixed explanations are common:

• one malicious event overlaps with authorized maintenance;
• a benign tool is used maliciously on one host and legitimately on another;
• a real intrusion and a telemetry defect coexist;
• copied phishing material is used by separate operators;
• defender actions generate events that appear adversary-driven.

For Project Lantern, Host C’s partial match initially appears related. Signed package evidence, the maintenance window, owner confirmation, and differences from the extracted script support authorized activity. Hosts A and B remain likely malicious. R4 explains the evidence better than treating all three hosts identically.

Mixed reconstruction prevents both scope inflation and premature dismissal.

Use counterfactual checks

A counterfactual asks what evidence should look different if the preferred reconstruction were false.

Examples:

• If the host activity were entirely authorized, why did it follow similarly constructed archive messages?
• If the new-device sign-in were unrelated, what ordinary account or device evidence should exist?
• If records were duplicated, should raw identifiers, host-local artifacts, and ingestion paths also repeat?
• If one coordinated operation affected all three hosts, why does Host C contain a signed approved package while Hosts A and B contain extracted scripts?

Counterfactuals reveal hidden assumptions and guide targeted validation. They are not proof by themselves.

Separate reconstruction confidence by claim

Do not assign one confidence label to the entire incident story. Different propositions have different support:

This prevents strong evidence for one link from inflating confidence in another.

Decide when the reconstruction is sufficient

Operational reconstruction is sufficient when it supports the open choice with remaining uncertainty visible. For the containment decision, the analyst may need:

• confirmed and suspected entity scope;
• leading and strongest alternative reconstructions;
• confidence for material propositions;
• decisive gaps and collection status;
• current implications and proportional options;
• escalation, narrowing, and update triggers.

The analyst does not need complete actor attribution or the entire historical campaign before recommending targeted containment.

Project Lantern reconstruction assessment

At the 13:20 cutoff:

We assess Hosts A and B were likely affected by one coordinated malicious operation, with moderate confidence. Similar delivery, matching execution, distinct raw events, and task creation support a common cause. Host C is unlikely to be part of the malicious activity because a signed approved package, maintenance timing, and owner confirmation explain its partial match. We cannot yet determine whether browser credential access succeeded or caused the later payment-account sign-in. Current evidence supports targeted host containment and bounded identity action rather than finance-segment isolation. Matching full-sequence behavior elsewhere or direct session linkage would expand scope; validated benign script behavior or processing defects would narrow it.

The assessment favors a mixed reconstruction and states which unresolved links matter.

Update the reconstruction transparently

When new evidence arrives:

1. Add it to activity and knowledge timelines.
2. Validate provenance, time, scope, and transformation.
3. Reevaluate every reconstruction, not only the favored one.
4. Update affected entity states and causal links.
5. Revise likelihood and confidence at the proposition level.
6. Identify decisions or controls based on the prior version.
7. Issue an update or correction when the change is material.

Do not silently reinterpret earlier evidence to make the new outcome appear inevitable.

Reconstruction review checklist

• Competing reconstructions include malicious, authorized, telemetry-error, and mixed causes where plausible.
• Each reconstruction predicts observable evidence.
• Established sequence is distinguished from inferred causation.
• Causal links expose their support, alternatives, and decisive evidence.
• Load-bearing assumptions are identified and tested by decision value.
• Collection questions discriminate between leading reconstructions.
• Mixed causes are considered rather than forcing one explanation across all entities.
• Likelihood and confidence are assigned to distinct propositions.
• The reconstruction is sufficient for the decision without claiming completeness.
• New evidence triggers transparent reevaluation, versioning, and action review.

Key takeaways

• Incident reconstruction compares explanations for sequence, relationships, scope, and gaps.
• Define what evidence each reconstruction predicts and focus on inconsistencies and discriminating evidence.
• Temporal order alone does not establish a causal mechanism.
• Test load-bearing assumptions and individual causal links.
• Mixed causes often explain operational evidence better than one universal story.
• Keep confidence proposition-specific so strong support for one event does not inflate an entire narrative.
• Stop when the reconstruction is sufficient for the open decision, then update transparently as evidence changes.

Analyst habit: For every asserted causal link, ask: What evidence shows this event enabled the next one, and what alternative mechanism could produce the same sequence?