DFIR Investigation Steps: From Alert to Report

When an alert fires at 2 a.m., the difference between a contained incident and a full breach often comes down to one thing: whether your team follows a repeatable, structured process. Ad-hoc responses burn time, miss evidence, and leave gaps that attackers exploit again. A defined incident response workflow solves all three problems.

This guide walks through the complete digital forensics investigation steps — from the moment an alert lands in your queue to the final post-incident report. It is grounded in NIST SP 800-61 Rev 2, which defines four phases: Preparation; Detection and Analysis; Containment, Eradication, and Recovery; and Post-Incident Activity. Where it makes sense, we expand those phases into the practical sub-steps you will actually execute on a case.

Phase 1: Preparation

NIST treats Preparation as the foundation everything else rests on. You cannot improvise a good incident response — you build the capability before you need it.

Establish and Maintain an IR Plan

Your incident response plan should define roles, escalation paths, communication templates, and decision thresholds. Who declares an incident? Who calls legal counsel? Who talks to customers? These questions answered in advance prevent paralysis when a real event hits. Review the plan at least annually and after every significant incident.

Pre-provision Tools and Access

Every tool you need during an investigation should be available before the incident, not requested after the fact. That means:

• Read access to your SIEM, EDR, firewall, and cloud logs
• A forensic workstation or cloud sandbox environment
• Approved network capture utilities
• Legal hold procedures understood by all relevant teams

Tooling that requires a procurement cycle during a live incident is tooling that will not get used. DFIR Lab's platform is SaaS-based and accessible immediately — analysts can be enriching IOCs or running phishing checks within minutes of account creation, with no on-premise deployment required.

Document Your Asset Inventory

You cannot scope an incident without knowing what "normal" looks like. Maintain an up-to-date inventory of critical assets, their owners, and their typical network behavior. This baseline makes anomaly detection during the analysis phase dramatically faster.

Phase 2: Detection and Analysis

NIST's second phase covers everything from the initial signal to a confirmed scope of impact. In practice this breaks into three steps.

Alert Triage

Not every alert is an incident, and not every incident starts with a high-fidelity alert. Alert triage is the process of quickly assessing whether a signal warrants escalation.

For a phishing alert, that means pulling the raw email headers, checking the sender domain, inspecting links and attachments before clicking anything, and cross-referencing against known-bad infrastructure. DFIR Lab's Phishing Email Checker runs the message through 26+ analysis modules — header authentication (SPF, DKIM, DMARC), link reputation, attachment sandbox results, and more — giving you a structured verdict in seconds rather than manually querying five separate services. Full documentation is at platform.dfir-lab.ch/docs/phishing.

Initial Scoping

Once you confirm a real event, scope it. The goal here is to answer: How far has this gone?

Work from the initial indicator outward:

1. Identify the affected host(s) and user account(s)
2. Pull authentication logs for the affected accounts — look for lateral movement, new login locations, or privilege escalation
3. Review network flow data for unusual outbound connections or data staging behavior
4. Check EDR telemetry for process execution chains that match known attacker TTPs

Map what you find to MITRE ATT&CK technique IDs as you go. This is not busywork — it structures your thinking and feeds directly into your detection improvement work later. DFIR Lab's AI Triage module does this automatically, mapping alert data to ATT&CK techniques and generating draft Sigma and YARA rules from the observed behavior. See platform.dfir-lab.ch/docs/ai/triage.

For business email compromise (BEC) scenarios specifically, the BEC Investigation module reconstructs a full inbox timeline — mailbox rule changes, forwarding configurations, and message access patterns — which is otherwise extremely tedious to build manually from raw audit logs. Documentation: platform.dfir-lab.ch/docs/bec.

IOC Extraction and Enrichment

As you scope, collect every indicator of compromise you encounter: IP addresses, domains, file hashes, email addresses, URLs. Raw IOCs are not enough — you need context.

Enrichment answers: Is this IP known-bad? What ASN does it belong to? Has this hash been seen in malware campaigns? When was this domain registered?

DFIR Lab's IOC Enrichment tool queries 14+ threat intelligence sources in a single call. From the CLI:

1dfir-cli enrich 185.220.101.47
2dfir-cli enrich d41d8cd98f00b204e9800998ecf8427e
3dfir-cli enrich malicious-domain.example.com

Full source list and API reference: platform.dfir-lab.ch/docs/enrichment. Bulk enrichment via the API is available for integrating into automated playbooks.

Phase 3: Containment

NIST groups Containment, Eradication, and Recovery into a single phase. In practice, containment happens first and has two distinct modes.

Short-Term Containment

Short-term containment is about stopping the bleeding immediately without destroying evidence. Actions depend on the incident type, but common steps include:

• Network isolation: Segment or block the affected host at the switch or firewall level. Most EDR platforms support host isolation without pulling the physical cable, which preserves running memory state.
• Account suspension: Disable compromised credentials at the identity provider. For cloud environments, revoke active sessions and API keys immediately.
• Snapshot before cleanup: If you are working in a virtualized or cloud environment, take a snapshot of the affected system before any remediation. This preserves forensic state.

Do not reimage a system before you have collected volatile data: running processes, active network connections, and memory contents are lost forever on reboot.

Long-Term Containment

Long-term containment keeps affected systems operational — where business continuity requires it — while you complete the full investigation. This might mean routing traffic through enhanced inspection, placing honeytokens on compromised accounts to detect reuse, or deploying additional log analysis coverage to the affected segment.

Credential Resets

Any account that touched the compromised system or was accessed during the incident window should have its credentials rotated. For Active Directory environments, pay particular attention to service accounts and any accounts with delegation rights. If a domain controller was involved, assume Kerberos tickets are compromised and follow Microsoft's guidance on KRBTGT key rotation.

Phase 4: Eradication

Eradication means removing the attacker's presence entirely. This is where many teams rush and create future problems.

Identify and Remove Persistence Mechanisms

Attackers establish persistence through scheduled tasks, registry run keys, WMI subscriptions, startup folders, cron jobs, web shells, or implanted accounts. A compromised system is not clean until every persistence mechanism is identified and removed — not just the initial payload.

Use your EDR telemetry and malware analysis findings to build a complete list before you start removing anything. Removing one artifact while leaving another gives the attacker a way back in.

Malware Cleanup

For each piece of identified malware:

1. Confirm the hash against your enrichment data
2. Document every file path, registry key, and network connection associated with it
3. Remove all components — not just the primary executable
4. Verify removal with a post-cleanup scan

If you identified a novel or poorly documented sample, submit it to a sandbox and check the behavioral report before cleanup. Understanding what the malware does informs your recovery and detection work.

Patch the Initial Access Vector

Eradication is incomplete if the vulnerability that let the attacker in is still open. Whether that is an unpatched VPN appliance, a misconfigured public-facing service, or a user account with a weak password, close it before you restore systems. DFIR Lab's Exposure Scanner checks your assets against 11 providers for known vulnerability data and exposed services — useful for validating that the attack surface is reduced. Documentation: platform.dfir-lab.ch/docs/exposure.

Phase 5: Recovery

Recovery is about returning to normal operations safely, not quickly. Rushing recovery after incomplete eradication is how organizations get breached twice by the same attacker.

System Restoration

Restore affected systems from known-good backups where possible. If a backup is not available or feasible, rebuild from a verified clean image rather than attempting to clean a production system in place. Before returning a system to production:

• Confirm all persistence mechanisms are gone
• Apply all available patches
• Validate the system's configuration against your baseline
• Re-enroll the endpoint in your EDR with a fresh agent install

Validate Business Services

After restoration, test the affected business services end-to-end before declaring recovery complete. A system that is forensically clean but operationally broken is still an incident.

Monitor for Re-compromise

Increase monitoring on restored systems and the accounts that were involved for at least 30 days after recovery. Set specific alerts for:

• Reuse of any IOC from the incident
• Authentication from the same geographic regions or ASNs as the attacker
• Process execution patterns that match observed attacker behavior

This monitoring posture is the bridge between recovery and your ongoing detection engineering improvements.

Phase 6: Post-Incident Activity

NIST's fourth and final phase is where organizations either improve or stagnate. Most teams treat this as optional. It is not.

Lessons Learned Meeting

Hold a structured lessons learned meeting within two weeks of incident closure, while details are still fresh. The goal is not blame assignment — it is process improvement. Cover:

• What happened and how it was detected
• What went well in the response
• What slowed the response down
• What would have prevented the incident

Document the outcomes. Follow through on action items. A lessons learned meeting with no follow-through is theater.

Detection Improvements

Every incident reveals gaps in your detection coverage. Convert what you learned into new detection rules. If your AI Triage output generated draft Sigma rules during the investigation, review them, tune them against your SIEM environment, and deploy them. Update your MITRE ATT&CK coverage map to reflect newly covered techniques.

Report Writing

The final incident report serves multiple audiences: technical teams, management, legal, and potentially regulators or customers. Structure it to address all of them:

• Executive summary: What happened, business impact, current status — in plain language, half a page or less
• Technical timeline: Chronological reconstruction of attacker activity from initial access to containment, with evidence citations. Timeline analysis is a core skill here.
• Root cause analysis: The vulnerability or control failure that enabled the incident
• Remediation actions taken: What was done during the incident
• Recommendations: What changes should be made to prevent recurrence

Keep the technical timeline factual and evidence-based. Every claim should trace back to a log entry, a forensic artifact, or an analyst observation.

Tools That Accelerate Each Phase

All tools are available at platform.dfir-lab.ch. Free tier includes 100 credits per month. Use code LAUNCH50 for 50% off your first paid month.

Walk the workflow in your browser. The DFIR API Playground lets you run enrichment, phishing triage, and exposure checks against real indicators from each phase of an investigation — 10 free calls per week, no signup. Drop in an IOC from your last alert and see what the identification step actually looks like end to end.

Conclusion

A structured DFIR workflow is not bureaucracy — it is the mechanism that keeps a bad day from becoming a catastrophic one. The NIST SP 800-61 framework gives you the right skeleton: prepare before incidents happen, analyze carefully before acting, contain and eradicate completely, recover deliberately, and extract lessons afterward.

What matters in practice is execution. That means having your tools ready, your access pre-provisioned, and your team practiced enough that the process is reflex rather than reference. The digital forensics investigation steps outlined here are not theoretical — they are the same sequence experienced practitioners follow on real cases.

Start with the free tier at dfir-lab.ch and run your first IOC enrichment or phishing check today. When the next alert fires, you will already know what step comes next.