Agent Foskett Academy • SOC Analyst Academy • Module 7 • Lesson 64 • Incident Response: Containment, Evidence & Escalation

Lesson 64 — What Evidence Must We Preserve?

The endpoint was compromised.

The account was contained.
The recovery team was ready to rebuild the device.

Then someone said:

“Let's wipe it and get the user working again.”

Agent Foskett looked at the incident timeline.

“Not yet. What evidence disappears when we do that?”

Remediation changes evidence. Preserve what you need to explain the incident before you destroy the state that tells the story.
Agent Foskett preserving incident evidence before remediation
What disappears when remediation begins?

Preserve the telemetry, artefacts, timestamps and investigation context needed to reconstruct what happened later.

✓ Preserve volatile context
✓ Record timelines
✓ Protect original evidence
✓ Document collection

Case briefing

INCIDENT: FIN-WS-044 / mia@contoso.com 11:08 — Endpoint compromise confirmed 11:16 — Device isolated 11:24 — Identity containment initiated 11:31 — Suspicious cloud activity stops 11:38 — Recovery team requests rebuild 11:42 — Analyst reviews evidence status KNOWN EVIDENCE: Process execution PowerShell command line Network connections Suspicious file Account activity Cloud access Mailbox activity Related device activity QUESTION: WHAT MUST BE PRESERVED BEFORE REMEDIATION CHANGES THE ENVIRONMENT?

Investigation objective

Identify and preserve the evidence required to reconstruct the incident, support response decisions, scope impact and enable later technical, legal, regulatory or business review.

Investigator's rule

Before changing the environment, ask which evidence the change could remove, overwrite or make harder to interpret.

Stage 1 — separate evidence from assumptions

EVIDENCE: Timestamped process event Command line Network connection File hash Sign-in record Cloud action Mailbox rule Alert record INTERPRETATION: "Attacker gained access" "Credential theft occurred" "Data was stolen" "Persistence was established" PRESERVE THE UNDERLYING EVIDENCE. YOUR INTERPRETATION MAY CHANGE LATER.

Evidence should survive the analyst's theory

A good incident record lets another analyst review the original observations and reach their own conclusion. Preserve the facts that support the finding, not only the finding itself.

Do not preserve only screenshots

Screenshots can provide useful visual context, but searchable event data, timestamps, identifiers, exported records and original artefacts are often more valuable for correlation and later review.

Stage 2 — preserve the endpoint timeline

01-preserve-process-timeline.kql
1234567891011
DeviceProcessEvents
| where Timestamp between (datetime(2026-09-03 10:30:00) .. datetime(2026-09-03 12:00:00))
| where DeviceName =~ "FIN-WS-044"
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          SHA256
| order by Timestamp asc

Preserve ancestry and command lines

The relationship between processes can explain how execution began, which process launched the suspicious activity and what commands were attempted.

Hashes help future correlation

Where available, preserve cryptographic hashes alongside filenames and paths. A filename can change; a hash can help correlate the same file elsewhere.

Stage 3 — preserve network evidence

02-preserve-network-timeline.kql
1234567891011
DeviceNetworkEvents
| where Timestamp between (datetime(2026-09-03 10:30:00) .. datetime(2026-09-03 12:00:00))
| where DeviceName =~ "FIN-WS-044"
| project Timestamp,
          DeviceName,
          InitiatingProcessFileName,
          RemoteIP,
          RemotePort,
          RemoteUrl,
          ActionType
| order by Timestamp asc

Connections add sequence

Preserve when the connection occurred, which process initiated it, the destination and how it relates to execution. Those relationships can become critical when the incident expands.

Do not reduce network evidence to “bad IP”

The evidentiary value comes from context: which device, process, account and timestamp were associated with the connection.

Stage 4 — preserve identity and cloud context

03-preserve-cloud-activity.kql
1234567891011
CloudAppEvents
| where Timestamp between (datetime(2026-09-03 10:30:00) .. datetime(2026-09-03 12:00:00))
| where AccountId =~ "mia@contoso.com"
| project Timestamp,
          AccountId,
          Application,
          ActionType,
          IPAddress,
          UserAgent,
          RawEventData
| order by Timestamp asc

Identity evidence can outlive the device

Endpoint remediation does not erase cloud telemetry, but relevant records may still be subject to retention limits. Preserve the incident window and identifiers needed for later correlation.

Capture state-changing evidence

If authentication methods, roles, OAuth relationships, mailbox rules or sharing settings changed during the incident, record what changed, when it changed and the evidence that established it.

Stage 5 — prioritise evidence that may disappear

EvidenceWhy preservation matters
Running processes / current stateMay change when processes stop, the host reboots or remediation occurs.
Suspicious filesMay be quarantined, deleted or replaced.
Command lines / process ancestryCritical for reconstructing execution.
Network activityProvides destination, process and timing context.
Identity / cloud eventsShows access and activity beyond the endpoint.
Authentication / permission stateMay change during containment and recovery.
Incident notes and decisionsExplain what responders knew and why actions were taken.

Volatility changes priority

Evidence that can disappear quickly may need to be collected before evidence that is already retained centrally. Follow organisational forensic and incident-response procedures.

Retention matters

Know how long your relevant security and audit data is retained. An investigation reopened weeks later is much harder if important telemetry has already aged out.

Stage 6 — preserve the timeline, not just individual events

10:58 Browser launches PowerShell 11:01 Suspicious command executes 11:03 External connection 11:07 Credential-access behaviour 11:12 Cloud activity begins 11:16 Device isolated 11:19 Cloud activity continues 11:24 Identity containment begins 11:31 Last suspicious cloud event 11:38 Recovery requested THE TIMELINE SHOWS: WHAT HAPPENED WHAT HAPPENED NEXT WHAT RESPONSE CHANGED WHAT CONTINUED AFTER CONTAINMENT INDIVIDUAL EVENTS ARE EVIDENCE. ORDER GIVES THEM MEANING.

Preserve response timestamps too

Containment actions belong in the same timeline as attacker activity. Without them, later reviewers cannot tell whether an event happened before or after the response should have taken effect.

Time consistency matters

Record timestamps in a consistent time basis and retain the original event time where possible. Time-zone confusion can break an otherwise strong incident reconstruction.

Stage 7 — protect evidence integrity

PRESERVE: Original source Original timestamp Relevant identifiers Collection time Collector / analyst Collection method Export / file name Hash where appropriate Storage location Access controls Any transformation performed IF FORMAL FORENSIC OR LEGAL REQUIREMENTS APPLY: FOLLOW YOUR ORGANISATION'S CHAIN-OF-CUSTODY AND EVIDENCE-HANDLING PROCEDURES.

Do not casually modify original artefacts

Where formal evidence handling is required, work from approved copies and preserve originals according to procedure. The SOC investigation record should make clear what was collected and how.

Evidence requirements depend on the incident

A routine malware case, insider-risk investigation, regulatory matter and potential legal proceeding may have different preservation requirements. Escalate to the appropriate internal teams when necessary.

Stage 8 — preserve decision evidence

DO NOT RECORD ONLY: "DEVICE ISOLATED" "ACCOUNT DISABLED" RECORD: What evidence existed? What was the risk? What alternatives were considered? Who authorised the action? When was it performed? What result was expected? What happened afterwards? What remained unknown? THE INCIDENT RECORD SHOULD EXPLAIN THE RESPONSE — NOT JUST LIST IT.

Decisions are part of the evidence

Incident response is a sequence of decisions made under uncertainty. Preserve enough context for another analyst to understand why each action was reasonable at that point in the timeline.

Unknowns should remain visible

If initial access, data exfiltration or attacker identity is undetermined, record that explicitly. Do not turn uncertainty into certainty merely to make the report look complete.

Stage 9 — decide when remediation can proceed

BEFORE REBUILD: ✓ Endpoint timeline preserved ✓ Relevant process evidence preserved ✓ Network evidence preserved ✓ Suspicious artefacts handled per procedure ✓ Identity / cloud timeline preserved ✓ Authentication / permission changes recorded ✓ Incident and alert identifiers recorded ✓ Containment actions timestamped ✓ Known scope recorded ✓ Important unknowns recorded ✓ Required forensic / legal escalation completed THEN: REMEDIATION CAN PROCEED UNDER THE RESPONSE PLAN.

Preservation should not paralyse response

The objective is not to collect everything forever. Preserve what is material to the incident, its scope, impact, response decisions and any formal evidence requirements.

Active harm can override collection

If delaying containment would expose the organisation to unacceptable ongoing harm, protect the environment first according to approved emergency procedures and document the evidence that could not be collected.

Example evidence-preservation note

INCIDENT: FIN-WS-044 / mia@contoso.com PRESERVED: Endpoint process timeline PowerShell command-line evidence Relevant file hashes Endpoint network activity Cloud application activity Account and device identifiers Containment timestamps Relevant incident / alert IDs STATE CHANGES RECORDED: Device isolation Identity containment Suspicious activity cessation KNOWN GAPS: Full initial-access mechanism not yet confirmed. No conclusion yet on data exfiltration. RECOVERY STATUS: Device rebuild approved after required evidence was preserved according to incident procedure. NEXT: Retain evidence with incident record. Continue cross-environment scoping. Update findings if new evidence changes the timeline.

Lesson 64 key takeaways

  • Remediation can remove or alter evidence that explains the incident.
  • Preserve underlying observations, not only analyst conclusions.
  • Process ancestry, command lines, hashes and network context can be critical endpoint evidence.
  • Preserve identity and cloud evidence alongside endpoint telemetry.
  • Prioritise evidence that is volatile or likely to disappear.
  • Retention periods can affect what remains available later.
  • A complete timeline is often more useful than disconnected screenshots.
  • Record containment and remediation actions in the same timeline as attacker activity.
  • Preserve evidence integrity and follow formal evidence-handling procedures when required.
  • Document the rationale, authority and timing behind response decisions.
  • Keep unknowns visible rather than inventing certainty.
  • Preserve what matters — but do not allow evidence collection to enable ongoing harm.

Module 7 — Incident Response: Containment, Evidence & Escalation

Lesson 64 preserved the evidence before remediation changed the environment. Lesson 65 raises the pressure: the attacker has not stopped. The malicious activity is still happening while the SOC is responding.

Next: Lesson 65 — The Attack Was Still Active

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

What evidence should a SOC preserve before remediation?

Lesson 64 of the Agent Foskett SOC Analyst Academy teaches analysts how to identify and preserve endpoint, identity, cloud, network and incident-response evidence before containment or remediation changes the environment.

Incident evidence preservation with Microsoft Defender XDR

Learn how to preserve process timelines, command lines, network events, cloud activity, response timestamps, investigation decisions and important unknowns while maintaining evidence integrity and supporting later incident review.