IR roles own the active response when things go wrong. These questions cover the IR lifecycle, digital forensics, evidence handling, and the live decision-making that defines whether a response goes well or badly.
Preparation: Controls, playbooks, escalation contacts, and tabletop exercises — everything done before an incident occurs. The quality of your preparation determines how well every other phase goes.
Identification: Detecting and scoping the incident. Is this a true positive? How wide is the impact? What systems are affected?
Containment: Stopping the spread without destroying evidence. Isolate affected hosts, revoke compromised credentials, block attacker infrastructure — but preserve logs and memory before acting.
Eradication: Removing the attacker's presence entirely — deleting malware, closing persistence mechanisms, patching the exploited vulnerability.
Recovery: Restoring systems to normal operations with enhanced monitoring to detect any recurrence.
Lessons Learned: Post-mortem within ~2 weeks. Document what happened, what worked, what didn't, and concrete action items with owners and deadlines.
Containment stops the spread — isolating an infected host from the network, revoking compromised credentials, blocking an attacker's C2 IP. It limits damage without necessarily removing the threat.
Eradication removes the attacker's presence entirely — deleting malware, removing persistence mechanisms, patching the exploited vulnerability.
The order matters because eradicating one system before containment gives the attacker time to pivot to a new host before you get there. If you clean one machine but the attacker is still moving laterally, they'll just re-establish access and you'll have to start over. Contain first, then eradicate — all affected systems at once where possible.
Collect before reimaging — you cannot go back once a system is wiped.
Memory dump: Captures active processes, network connections, and in-memory malware that leaves no disk artifacts. Fileless attacks only exist here.
From disk: Windows Event Logs (System, Security, Application), Prefetch files, registry hives (especially Run/RunOnce keys and Services), PowerShell history, browser history, scheduled tasks, startup entries, $MFT (Master File Table for file timeline analysis), network config (active connections, ARP table, routing table).
Document the collection process with timestamps and the identity of the collector — this is the start of your chain of custody.
Chain of custody is a documented record showing who collected evidence, when, using what tools, how it was stored, and who had access to it afterward.
It matters because if an incident leads to legal action, HR discipline, or regulatory reporting, evidence with a broken chain of custody may be inadmissible or successfully challenged. An attacker's lawyer arguing that evidence was tampered with or improperly handled can undermine an entire case.
In practice: hash all evidence files at collection (record the hash), label media with date/time/collector, store in access-controlled locations, and log every person who accesses the evidence afterward.
Attackers establish persistence so they survive reboots and credential resets. Common locations to check:
Registry: HKLM\Software\Microsoft\Windows\CurrentVersion\Run and RunOnce (and their HKCU equivalents), Services registry keys.
Scheduled tasks: schtasks /query /fo LIST /v or check the Task Scheduler library. Look for tasks with unusual names, paths, or triggers.
WMI subscriptions: Event consumers that execute on system events. Often overlooked and can survive reboots invisibly.
Other locations: Startup folder, browser extensions, COM object hijacks, DLL search order hijacking, modified system binaries (compare hashes to known-good).
Sysinternals Autoruns shows all auto-start locations in one view and can compare against VirusTotal — the fastest way to find unusual entries.
A memory dump is a snapshot of the contents of RAM at a specific moment in time. It captures everything currently in active memory: running processes, network connections, loaded DLLs, decrypted strings, and in-flight activity.
Collect one when: you suspect fileless malware (which lives only in memory and leaves no disk artifacts), you need to recover attacker tooling before it disappears, you want to extract active network connections, or you need encryption keys that exist only in memory.
Tools: WinPmem, Magnet RAM Capture, FTK Imager, or EDR built-in memory acquisition. Collect before any containment action that might change system state — especially before isolating the host, which may cause the process to crash and disappear.
Strong answers show structured behavior under stress — not just that you can handle pressure, but that you have specific practices that keep you reliable when the environment is chaotic.
Examples: using checklists and runbooks instead of relying on memory, slowing down communication deliberately to be accurate, assigning a scribe to document while you triage, taking 30 seconds to step back and confirm your current theory before your next action, and naming your uncertainty level explicitly ("I'm 70% confident this is ransomware — we should treat it as such but not rule out destructive wiper yet").
Mention a specific example if you have one — a CTF under time pressure, a lab drill, or a real event.
Communicate early and often in plain language. Lead with impact: what is affected, what is at risk, what action is being taken. Not: what techniques the attacker used.
Structure: "We have a confirmed ransomware infection on three finance servers. We've isolated them and are assessing spread. No evidence of data exfiltration yet. We'll update you in 30 minutes or immediately if scope changes."
Give a confidence level on your assessment — not false certainty. Avoid jargon. Update on a cadence they can use — not every 5 minutes (noise), not radio silence for hours (panic). Let them know what decisions you need from them: legal notification, PR hold, business continuity activation.
A strong post-mortem is blameless — it focuses on what happened and why (system and process factors), not who made a mistake. Blame-focused reviews suppress honest reporting and make the next incident harder to handle.
Structure: full timeline reconstruction, what went well (important — you want to repeat this), what didn't work and why, what would have reduced detection time (MTTD) or response time (MTTR), and concrete action items with specific owners and deadlines.
Run the post-mortem within ~2 weeks while memory is fresh. Share findings with the broader team — not just the people who responded. Every incident is a training event for the whole org.
Do not reimage immediately. You will lose evidence that determines scope, patient zero, and legal/regulatory obligations.
First actions (parallel where possible): Page the on-call team and follow the escalation chain per your IR plan. Identify scope — are these three servers isolated, or is encryption still spreading? Check backup status immediately — are they intact and offline?
Contain: Network-isolate the affected hosts (via EDR, VLAN change, or firewall rules) to stop encryption spread and sever any C2. Preserve memory dumps before isolation if possible.
Do not: Touch the ransom note beyond documenting it photographically. Make any payment decisions without legal and executive sign-off. Reboot affected systems without collecting forensic images first.
Begin scope investigation: Identify patient zero. Check for lateral movement. Determine whether any data was exfiltrated before encryption began — this affects breach notification obligations.
Don't immediately seize the device. Executives are sensitive to visible security interventions and may escalate politically before you've confirmed anything — which complicates the investigation.
Triage remotely first: Pull EDR telemetry and identity/Azure AD logs without touching the device. If the data suggests compromise, you now have a documented technical basis to act.
Coordinate before acting: Brief your manager, HR, and legal before doing anything visible. They need to be part of the decision, especially if this could become an HR or legal matter.
If confirmed: Work with the executive's assistant to schedule a "routine device refresh." Collect a forensic image before reimaging. Check the executive's mailbox and cloud storage (OneDrive, Dropbox) for signs of rule creation or bulk data access.
Brief leadership through proper channels — not hallway conversations.
Do not tip off the attacker with partial containment. If you isolate one system, they'll see it and pivot — you've lost the element of surprise and they'll establish new footholds before you've finished.
Plan a synchronized takedown: Map all affected systems, prepare containment actions for each, and execute simultaneously.
Before acting, notify: Legal (exfiltration may trigger mandatory breach notification timelines under GDPR, state laws, or contractual obligations), executive leadership, and communications (if a public breach notification is possible, they need to be ready).
Consider deception: Planting false data in the attacker's path or setting up monitoring to track their movement while you finalize the takedown.
Scope the exfiltration carefully: what data, how much, which systems, over what period. This determines your regulatory and legal reporting obligations.