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

Lesson 70 — From Detection to Recovery — Run the Incident

The alert arrived at 08:14.

By 08:20, it was no longer just an alert.
By 08:35, the investigation had crossed identity and endpoint telemetry.
By 09:10, the attacker was still active.
By 09:30, multiple teams were involved.
By 10:15, the scope had expanded again.

This time there was no single query that solved the case.

There was only the incident — and the decisions the SOC made next.

Agent Foskett looked at the timeline.

“Follow the evidence. Control the risk. Keep the incident moving.”

This is the Module 7 capstone: run the complete response lifecycle from detection and investigation through containment, coordination, recovery and handover.

Run the Incident Back to SOC Analyst Academy

Agent Foskett running a complete cyber security incident response lifecycle

Detection is where response begins.

Build the timeline, preserve evidence, contain active risk, coordinate teams, verify outcomes and move safely into recovery.

✓ Detect and validate

✓ Scope and preserve

✓ Contain and verify

✓ Recover and hand over

Capstone briefing

08:14 — ALERT ↓ 08:20 — VALIDATED ↓ 08:35 — CROSS-DOMAIN EVIDENCE ↓ 09:10 — ACTIVE ATTACK ↓ 09:18 — CONTAINMENT BEGINS ↓ 09:30 — MULTIPLE TEAMS ↓ 10:15 — SCOPE EXPANDS ↓ 11:05 — CONTAINMENT VERIFIED ↓ 12:10 — RECOVERY BEGINS ↓ 13:00 — HANDOVER YOUR JOB: DO NOT JUST INVESTIGATE IT. RUN THE INCIDENT.

Investigation objective

Apply the complete Module 7 response model to a realistic incident and make defensible decisions about escalation, evidence preservation, containment, coordination, scope, recovery and handover.

Investigator's rule

The incident moves whether the SOC is ready or not. Your process must move with the evidence.

Phase 1 — detection becomes an incident

08:14 ALERT: Suspicious PowerShell execution DEVICE: FIN-WS-044 USER: mia@contoso.com INITIAL QUESTIONS: Is the activity malicious? Is it isolated? Is the user affected? Is activity continuing? What else is connected? 08:20 EVIDENCE SUPPORTS COMPROMISE. STATUS CHANGE: ALERT INVESTIGATION ↓ SECURITY INCIDENT

Do not wait for the whole story

The SOC needs enough evidence to justify coordinated response, not a completed forensic report. Once malicious activity and material risk are established, the response model changes.

Record the transition

Capture when the investigation became an incident, what evidence supported that decision and who assumed incident ownership under the organisation's process.

Phase 2 — build the first timeline

12345678

DeviceProcessEvents
| where Timestamp > ago(4h)
| where DeviceName =~ "FIN-WS-044"
| project Timestamp, DeviceName, AccountName,
          FileName, ProcessCommandLine,
          InitiatingProcessFileName
| order by Timestamp asc

Timeline before theory

Start with what happened, when it happened and which entities were involved. The timeline gives later containment and scoping decisions a factual foundation.

Mark confidence

Separate confirmed malicious events from suspicious observations and unresolved hypotheses. The incident record should become more precise as evidence improves.

Phase 3 — preserve what remediation could destroy

BEFORE HIGH-IMPACT REMEDIATION: PRESERVE WHAT IS REQUIRED: Process ancestry Command lines Relevant files / hashes Network evidence Identity activity Cloud activity Mailbox changes Application / permission state Response timestamps Decision rationale BUT: IF HARM IS ACTIVE, DO NOT DELAY URGENT APPROVED CONTAINMENT JUST TO MAKE THE EVIDENCE COLLECTION PERFECT.

Preservation and containment compete for time

The response team must balance evidence requirements against immediate risk. Follow organisational and legal requirements, but do not protect the attacker in the name of collecting a prettier timeline.

Record defender actions too

Isolation, session revocation, permission changes and remediation alter the environment. Add them to the timeline so later analysts can distinguish attacker activity from response activity.

Phase 4 — prove whether the attack is still active

12345678

DeviceNetworkEvents
| where Timestamp > ago(1h)
| where DeviceName =~ "FIN-WS-044"
| project Timestamp, DeviceName,
          InitiatingProcessFileName,
          RemoteIP, RemotePort, RemoteUrl
| order by Timestamp asc

09:10 — the incident is moving

Fresh suspicious activity means the SOC is no longer reconstructing only historical events. Immediate risk now drives prioritisation.

Contain known capability

Use approved response actions to reduce the attacker's ability to continue: endpoint, identity, messaging, cloud, application or network controls as the evidence requires.

Phase 5 — containment becomes coordinated

Workstream	Immediate objective
Endpoint	Control affected devices and verify malicious execution stops.
Identity	Address known compromised access paths and sessions.
Messaging	Preserve and remove malicious mailbox persistence where confirmed.
Cloud / SaaS	Address malicious access, permissions or data actions.
Network	Apply relevant approved controls and review related activity.
Business	Manage operational impact and critical-process continuity.
Incident lead	Maintain priorities, timeline, decisions, dependencies and status.

One incident, many action owners

The SOC does not need to perform every technical action. It does need to know what changed, when it changed, who authorised it and whether it achieved the intended result.

Coordinate state-changing actions

One team may need evidence that another team's remediation could alter. Sequence actions where possible, while allowing urgent containment to proceed under approved authority.

Phase 6 — scope expands

ORIGINAL: mia@contoso.com FIN-WS-044 NEW: FIN-WS-061 Finance SharePoint site Mailbox persistence OAuth application path alex@contoso.com under review FOR EACH NEW ENTITY: Why did it appear? What evidence connects it? Is it confirmed affected? Is it suspected? Is it merely related? Does it need containment? What new pivot does it create?

Do not confuse a pivot with a verdict

New entities expand the investigation. They enter confirmed scope only when the evidence supports that classification.

Update containment when scope changes

If another device or access path is confirmed, revisit the containment plan immediately. A response designed for yesterday's scope may not contain today's incident.

Phase 7 — maintain the operational picture

INCIDENT BOARD — 10:30 STATUS: Containment in progress CONFIRMED: 2 endpoints 1 identity 1 mailbox 1 SharePoint resource 1 application access path INVESTIGATING: alex@contoso.com ACTIONS COMPLETE: FIN-WS-044 isolated FIN-WS-061 isolated Identity containment applied IN PROGRESS: Cloud verification Scope validation OPEN: Initial access Full data impact NEXT DECISION: Do containment criteria now hold?

Separate facts, decisions and unknowns

A clean operational picture prevents assumptions from becoming facts and keeps technical teams and business stakeholders aligned.

Communicate for the audience

Technical responders need exact entities, timestamps and evidence. Business stakeholders need current impact, risk, decisions, dependencies and what happens next.

Phase 8 — verify containment

1234567

CloudAppEvents
| where Timestamp > ago(2h)
| where AccountId =~ "mia@contoso.com"
| project Timestamp, AccountId, Application,
          ActionType, IPAddress, UserAgent
| order by Timestamp asc

Actions are not outcomes

Confirm that isolation, identity controls, persistence removal and cloud remediation actually changed attacker capability as expected.

11:05 — containment criteria are met

Known malicious access paths are addressed, relevant response actions are verified, scope has stabilised sufficiently and no renewed known malicious activity is observed during the defined review period.

Phase 9 — move from containment toward recovery

CONTAINED DOES NOT MEAN CLOSED. NEXT WORK: Eradication as required Persistence review Root-cause investigation Impact assessment System rebuild / restoration Credential or access remediation Business validation Post-containment monitoring Evidence retention Lessons learned RECOVERY QUESTION: CAN WE RETURN SERVICES WITHOUT REINTRODUCING THE RISK?

Recovery needs security criteria

Restoring a system because the business needs it is not enough. Define what must be true before affected assets or identities return to normal operation.

Recovery can reveal missed scope

If suspicious activity reappears, a persistence mechanism survives or another entity becomes affected, move back into active investigation and containment as required.

Phase 10 — hand over what remains

13:00 HANDOVER STATUS: Contained — recovery / monitoring underway. CONFIRMED SCOPE: mia@contoso.com FIN-WS-044 FIN-WS-061 mia mailbox Finance SharePoint resource Relevant application path ACTIONS: Known containment actions verified. OPEN: Initial access root cause Final data-impact assessment alex account final disposition NEXT: Complete open reviews Continue defined monitoring Coordinate recovery RE-ESCALATE IF: New malicious activity New affected entity Containment control fails Recovery reveals persistence

The incident survives the shift change

The next analyst receives the current state, evidence, decisions, risk and next actions — not a vague instruction to “keep an eye on it.”

Response is continuous decision-making

Detection, investigation, containment and recovery are not isolated boxes. Evidence can move the team backwards or forwards through the response lifecycle.

The complete Module 7 response loop

DETECT ↓ VALIDATE ↓ DECLARE / COORDINATE ↓ BUILD TIMELINE ↓ PRESERVE EVIDENCE ↓ ASSESS ACTIVE RISK ↓ CONTAIN ↓ VERIFY ↓ RESCOPE ↓ COORDINATE TEAMS ↓ VERIFY CONTAINMENT ↓ ERADICATE / RECOVER ↓ MONITOR ↓ HAND OVER / CLOSE ↖───────────────↙ NEW EVIDENCE CAN CHANGE THE PLAN.

There is no magic query

KQL, Defender XDR and other security tools help expose evidence. The analyst still has to decide what that evidence means, what risk exists and what action is justified.

The timeline remains the backbone

Throughout the incident, keep attacker events, defender actions, decisions and changes in scope anchored to time. When the story becomes complicated, the timeline keeps it defensible.

Final decision exercise

AT 13:15: A NEW SIGN-IN APPEARS FOR mia@contoso.com. DO YOU: A. Ignore it because the incident was already contained? B. Close the incident because recovery has started? C. Validate the event against the containment assumptions, determine whether attacker capability has returned, and reopen active response if the evidence requires it? AGENT FOSKETT: "THE STATUS DOESN'T OVERRULE THE EVIDENCE."

The answer is C

Incident status is a conclusion based on the evidence available at that time. New evidence can invalidate it. Validate the event, update the timeline, reassess scope and return to containment if required.

That is what running the incident means

You are not following a checklist blindly. You are using a repeatable response model while allowing evidence, risk, authority and business impact to determine the next decision.

Lesson 70 key takeaways

Know when an alert investigation has become a coordinated security incident.
Build the timeline early and keep it current.
Preserve evidence that remediation may change or destroy.
When malicious activity is active, containment urgency increases.
Coordinate endpoint, identity, messaging, cloud, network and business workstreams.
Incident scope is dynamic and must be reassessed as evidence expands.
Containment actions must be verified, not merely recorded as completed.
Containment is a milestone; recovery, impact assessment and monitoring can continue.
Recovery must not silently reintroduce the original risk.
A strong handover preserves status, scope, evidence, decisions, unknowns and next actions.
New evidence can move the incident back into active investigation and containment.
The status never overrules the evidence.

Module 7 complete — Incident Response: Containment, Evidence & Escalation

You have now worked from the moment an investigation becomes an incident through containment decisions, evidence preservation, active attack response, cross-team coordination, expanding scope, containment verification and operational handover.

MODULE 7 COMPLETE 61 — The Investigation Became an Incident 62 — Do We Isolate the Device Now? 63 — Do We Disable the Account? 64 — What Evidence Must We Preserve? 65 — The Attack Was Still Active 66 — The Incident Crossed Multiple Teams 67 — The Scope Kept Growing 68 — When Do We Call It Contained? 69 — Writing the Incident Handover 70 — From Detection to Recovery — Run the Incident FOLLOW THE EVIDENCE. BUILD THE TIMELINE. CONTROL THE RISK. THE LOGS ALREADY KNEW.

Module 7 Complete • 70 SOC Analyst Academy lessons reached

Continue your SOC Analyst training

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

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 7: Incident Response: Containment, Evidence & Escalation

Module 7 complete — from detection and escalation through evidence preservation, containment, coordination, recovery and handover.

← Previous lesson

Lesson 69 — Writing the Incident HandoverTransfer status, evidence, actions and unanswered questions.

✅ Current lesson

Lesson 70 — From Detection to Recovery — Run the IncidentWork the full response lifecycle.

✓ Module complete

Return to SOC Analyst AcademyContinue the investigation from the Academy roadmap.

How do SOC analysts run a cyber security incident from detection to recovery?

Lesson 70 of the Agent Foskett SOC Analyst Academy is the Module 7 capstone, bringing together incident declaration, timeline building, evidence preservation, active attack containment, cross-team coordination, scoping, containment verification, recovery and handover.

Complete SOC incident response lifecycle

Learn how evidence drives response decisions throughout a security incident and how analysts use Microsoft Defender XDR telemetry, coordinated containment and repeatable incident-management practices to move safely from detection toward recovery.