"Reviewing an alert" and "investigating an incident" are not the same thing, even though both start from the same EDR screen. Reviewing an alert answers one question: whether a specific trigger deserves escalation. DFIR (digital forensics and incident response) answers a much broader set of questions: how the attack began, exactly what the attacker did, which systems and data were affected, and what needs to happen to stop the impact and prevent it from happening again.
The difference shows up most clearly at the point where teams most often lose it — the handoff between phases. A team quickly checks the alert, confirms it is not a false positive, isolates the host, and stops there, treating the incident as closed. That leaves unanswered questions about the initial access vector, whether the attacker touched other hosts, and what data they may have viewed or exfiltrated. A full investigation is what actually answers those questions.
Below is a step-by-step breakdown of DFIR: the phases an investigation goes through, what to collect from an endpoint and in what order, how to tie events together into a single timeline, the mistakes that most often undermine the evidence, and what to practice in advance so you are not learning it during a real incident. The offensive side of the attack is out of scope here — everything below is built around what the defending side sees and records.
What DFIR Covers and How It Differs from Reviewing an Alert
DFIR is the full cycle of activity around an incident: from preparing infrastructure for a future investigation to the review that happens after the incident is closed. Reviewing an alert is just one step within one phase of that cycle — it does not reconstruct the course of the attack, assess its scope, or extract lessons for the process.
The key difference is the scope of the question. An analyst reviewing an alert asks, "Is this signal real?" A DFIR investigation asks, "What happened in full, where else could it have happened, and what needs to change so it doesn't happen again?" The second question requires data from multiple hosts, a timeline rather than a single event, and a final report rather than a verdict on one alert.
The Phases an Investigation Goes Through
A full DFIR investigation moves through seven phases. Skipping any of them doesn't stop the work outright, but it leaves a gap that surfaces later — usually at the worst possible moment.
Preparation
An investigation doesn't start at the moment of the incident — it starts long before, with decisions about what telemetry gets collected at all, how long it is retained, and who has access to it during a crisis. If those questions aren't settled in advance, the first hours of the investigation go not to analysis but to figuring out what data even exists.
Detection and Triage
This phase determines exactly what is happening and how urgent it is: which host and user are affected, when the activity started, and whether similar indicators appear on other hosts. The fast-triage methodology is covered in detail in Investigating an Incident in EDR — it applies here too: the same set of questions gets asked in the first minutes of any DFIR case, before moving on to deeper analysis.
Containment
The goal of this phase is to stop further spread and impact without destroying the data the next phases will need. Containment means isolating the affected host from the network, disabling compromised accounts, and restricting the network paths the attacker could have used. This is the easiest place to make a mistake that devalues the rest of the investigation — it's covered separately below.
Artifact Collection
Data needed to reconstruct the sequence of events is collected from the affected systems: processes, network connections, logs, files, metadata. The collection order matters and is covered in a separate section below — some artifacts disappear faster than others.
Reconstructing the Sequence of Events
The collected artifacts are assembled into a coherent picture: how the attacker gained initial access, what they did next, which systems they touched, and whether and how they established persistence. This is the phase where individual events become a timeline — more on that in the corresponding section below.
Eradication and Recovery
Once the picture of the attack is clear, you can fully remove the attacker's foothold: eliminate persistence, rotate compromised credentials, close the vector that was used. Restoring systems to working order happens only after that — reversing the order risks bringing the system back up in the same vulnerable state.
Post-Incident Review
The final phase isn't a formality — it's the source of changes to the process. This is where you record what worked, what didn't, which data turned out to be unobtainable, and which processes need adjustment. The findings from this phase are a natural source of hypotheses for proactive hunting: something discovered after the fact in one investigation is worth checking across the whole infrastructure, without waiting for it to happen again. The approach to that kind of check is described in Threat Hunting: Where to Start.
What to Collect from an Endpoint and in What Order
The core principle of artifact collection is "capture what disappears first." Some data lives only in memory and vanishes on reboot; some sits in logs with a limited retention window; some is on disk and relatively durable. Collecting data in an arbitrary order risks losing the most valuable evidence to the very first careless action.
Practical collection order:
- Memory state and active network connections. This is the first thing lost on reboot or shutdown, and it often holds information that no log captures anywhere else.
- The list of running processes and their parent-child relationships. More durable than a memory snapshot, but it gets overwritten as the system keeps running.
- Host event logs and EDR telemetry for the relevant period. These last longer, but they're bound by retention limits and rotation.
- Persistence artifacts — autoruns, scheduled tasks, services, configuration changes — durable, provided the attacker didn't remove them on the way out.
- The file system and file metadata — creation, modification, and access timestamps that help reconstruct what happened and in what sequence.
- Logs outside the host — network equipment, mail gateway, DNS — the most durable data of all, because it physically sits beyond the attacker's control on the endpoint.
The order matters not only because data disappears, but because every collection action changes the state of the system in some way. The rule is simple: the more volatile the data, the earlier it needs to be captured, and the more careful any subsequent intervention has to be.
How to Build a Timeline and Correlate Events Across Sources
A timeline isn't a chronological list of every event in a row — it's a causal chain: what led to what. A single event almost never answers the question "what happened"; the answer emerges once several events from different sources line up into one sequence.
The practical way to build one is to work outward from a confirmed point in both time directions. If you know a suspicious action occurred at a specific moment, the next step is to look at what preceded it on the same host: the parent process, a network connection, a file or email being opened. Then look at what followed: files created, new network connections, attempts at persistence or lateral movement to other hosts.
Correlating sources is a separate task in itself. Endpoint telemetry, mail gateway logs, and DNS query logs are kept by different systems in different formats, but they describe the same attack path. The common anchors for correlation are usually event time, hostname or username, domain or IP address, and file hash. If a DNS log shows a lookup to a suspicious domain at the same moment as process activity on the endpoint, that isn't a coincidence — it's the same episode seen from two sides.
The final timeline has to be readable without the author standing over it explaining: anyone on the investigation who opens it later should be able to see what happened, in what order, and which artifacts support each conclusion.
Common Investigation Mistakes
- Rebooting the infected host before collecting memory. The most common and most expensive mistake: whatever was in memory is gone for good, and part of the attack picture becomes impossible to reconstruct.
- Starting cleanup before the vector is understood. Deleting malicious files and resetting accounts before you know how initial access happened leaves the same path open for re-entry — the attacker comes back the same way.
- Wiping evidence while "cleaning up." Reinstalling the system, deleting logs to free up space, manually editing configuration before artifact collection is complete — each of these shrinks the pool of data any conclusion can rest on.
- Failing to document chain of custody. If you don't record who collected each artifact, when, and how, the investigation's conclusions become hard to defend to leadership, a regulator, or in any subsequent proceeding — not because the conclusions are wrong, but because they can't be verified.
- Blending containment with investigation. Isolating a host is the right move, but doing it without first capturing the system's state loses part of the investigative data along with the containment action itself.
- Closing the incident right after the first confirmed host. No one checked whether other hosts showed the same indicators — and some time later a "repeat" incident shows up that was actually the same one, just never fully resolved.
The Questions a Report Must Answer
A DFIR report isn't a chronology of what the analyst did — it's a document that answers a specific set of questions, regardless of who ran the analysis or in what order:
- How did the attacker gain initial access?
- Which systems, accounts, and data were affected?
- What is the timeline of events from initial access to detection?
- Did the attacker establish persistence, and if so, how was it removed?
- Did the attacker move to other hosts, and if so, which ones?
- What was done for containment and eradication, and is it confirmed that the impact has stopped?
- What gaps in data or process were found, and what needs to change to avoid repeating them?
If a report leaves even one of these questions unanswered, the investigation is formally closed but practically still carries an open risk — either an unresolved vector or an unassessed scope.
What to Practice on Training Ranges
DFIR is a skill that documentation alone doesn't build well: working a real incident takes practice handling telemetry under time pressure and incomplete data. A training range is the place to rehearse exactly the actions you can't redo in a real incident: the correct artifact collection order, building a timeline from multiple sources, and writing a report that answers every required question, not just the obvious ones.
It's worth separately practicing the distinction between containment and artifact collection — a mistake that's irreversible in a real incident but costs nothing on a training range, and lets you feel firsthand, once, why the order of actions matters more than speed.
Practice on BI.ZONE Cybersecurity Labs Ranges
The course Designing and Deploying BI.ZONE EDR gives you hands-on practice with the telemetry a real investigation is built on: deploying the product in a distributed configuration, integrating it with infrastructure, and working with the data that becomes the foundation of any DFIR case. It's the same material that underlies the telemetry reading in Investigating an Incident in EDR, just with a focus on architecture and coverage completeness rather than working a single alert.
If your team still reacts to ready-made alerts more often than it frames a full investigation, go back to Threat Hunting: Where to Start — many of the questions a DFIR report has to answer are the same ones an analyst asks during proactive hunting, just in a different order.