Most incident response teams can assemble a capable forensics and response toolkit from free tools, but only if they choose them before the incident, test them on their own systems and know which ones are genuinely open source. The open DFIR ecosystem now covers remote triage at scale, memory analysis, super timelines, Windows artefact parsing, Sigma-based event log hunting and case management. It also has gaps and traps: some well-known tools are freeware with commercial-use terms, and some former open source platforms are now commercial. This guide maps the main projects by investigation stage, explains how to deploy them safely and defensibly, and shows how to measure readiness. It is for incident responders, SOC leads and IT teams who need a working toolkit without a forensic suite budget.
Key takeaways
- Organise the toolkit by investigation stage. Collection (Velociraptor, offline collectors), memory (Volatility 3), timeline (Plaso, Timesketch), artefact parsing (Eric Zimmerman tools, Autopsy), log hunting (Hayabusa, Chainsaw) and case management (DFIR-IRIS).
- Velociraptor is the backbone for most teams. Its VQL artifacts and hunts let one analyst triage thousands of endpoints, and it can also build a self-contained offline collector.
- Licences differ more than people assume. Velociraptor and Hayabusa are AGPLv3, Chainsaw GPL-3.0, Plaso, Timesketch and Autopsy Apache 2.0, Volatility 3 uses its own Volatility Software License, and KAPE is free to download but not open source.
- Prepare before the incident. Pre-deploy the agent or collector, pre-stage symbol tables and parsers, and rehearse on a known-good host so timing and output are understood.
- Defensibility comes from process, not the tool. Hash evidence, log every action and keep chain of custody, following RFC 3227 and NIST SP 800-86, whichever tool you use.
What the tool does
An open DFIR toolkit is a set of single-purpose tools that hand data to each other. The table places the main projects by stage, using the licence stated in each project's own repository or site.
| Stage | Project | What it does | Licence (as published) |
|---|---|---|---|
| Remote collection and hunting | Velociraptor | Endpoint agent and server; VQL artifacts collect files, registry, event logs and live state; hunts run across the fleet; offline collector for unmanaged hosts | AGPL-3.0 |
| Triage collection | KAPE (Kroll) | Target and module based collection and processing on Windows, built by Eric Zimmerman | Free download, not open source; check Kroll's terms for commercial use |
| Memory analysis | Volatility 3 | Analyses Windows, Linux and macOS memory images using symbol tables; Python 3.8 or later | Volatility Software License |
| Super timelines | Plaso (log2timeline) | log2timeline extracts events from images, directories or files into a storage file; psort filters and outputs; pinfo describes; psteal combines both | Apache-2.0 |
| Timeline analysis | Timesketch | Collaborative timeline analysis in shared "sketches" with tags, comments and annotations | Apache-2.0 |
| Disk analysis | Autopsy and The Sleuth Kit | Graphical disk forensics: timeline, indexed keyword search, hash filtering of known good and known bad files | Autopsy Apache 2.0; bundled components vary |
| Windows artefact parsing | Eric Zimmerman tools (for example MFTECmd) | Command-line parsers; MFTECmd handles $MFT, $J, $LogFile, $Boot, $SDS and $I30 | MIT |
| Event log hunting | Hayabusa | Fast Windows event log timeline and hunting with full Sigma support, including correlation rules; CSV, JSON or JSONL output | AGPLv3 (rules DRL 1.1) |
| Event log hunting | Chainsaw | Searches EVTX with keywords, Sigma (via mapping files) and its own rules; parses MFT, SRUM, Shimcache and Amcache | GPL-3.0 |
| Network evidence | Arkime, Zeek | Arkime keeps indexed full packet capture; Zeek produces protocol logs for retrospective analysis | Apache 2.0; BSD |
| Case management | DFIR-IRIS | Collaborative case platform for sharing technical details, IOCs and timelines, with enrichment modules | LGPL-3.0 |
TheHive, once the usual open source case manager, now ships as a commercial product: its AGPL repository was archived in December 2025 and versions 3 and 4 have been unmaintained since 2023. Teams still running them should plan a migration.
Defender use cases
- Fleet-wide triage: when an indicator appears, a Velociraptor hunt checks every enrolled endpoint for the file hash, scheduled task, service or network connection within minutes, narrowing scope before anyone images a disk. See the Velociraptor Guide.
- Unmanaged or isolated hosts: an offline collector built from the Velociraptor server, or a KAPE target set, runs from removable media or a share and returns a zip of artefacts. See the KAPE and Triage Collection Guide.
- Credential theft and injection: Volatility 3 plugins reveal processes, network connections and injected code that never touched disk, which matters for techniques such as ATT&CK T1003.001 LSASS Memory. See the Memory Forensics Guide.
- Reconstructing the story: Plaso builds a super timeline from file system, registry, browser and event log data; Timesketch lets several analysts work the same timeline and tag key events.
- Event log hunting at scale: Hayabusa or Chainsaw run Sigma rules over collected EVTX files from one host or thousands, and Chainsaw flags gaps that may indicate selective record deletion. That supports investigation of ATT&CK T1685.005 Clear Windows Event Logs and T1685.001 Disable or Modify Windows Event Log.
- Windows artefacts: MFTECmd and the other Zimmerman parsers turn $MFT, USN journal, Shimcache and Amcache into CSV for timeline tools. See the Windows Forensic Artefacts Guide.
- Coordination: DFIR-IRIS keeps assets, IOCs, tasks and notes in one case so handovers and reports draw on the same record.
Deployment and safe use
- Choose the toolkit per stage and write it down. Record tool, version, hash of the binary, licence and owner in your incident response plan. See the Incident Response Plan Template.
- Pre-deploy collection. Install the Velociraptor client on servers and workstations through normal software deployment, or at least pre-build offline collectors for each platform. Deploying an agent mid-incident is slower and noisier.
- Build an analysis workstation. A dedicated, patched, isolated machine or VM with Volatility 3 symbol packs downloaded (Linux and macOS tables must be generated, for example with dwarf2json), Plaso, the Zimmerman tools (.NET 10 runtime or .NET Framework 4.7.2), Hayabusa and Chainsaw with a current Sigma rule set.
- Host the shared services privately. Timesketch and DFIR-IRIS run in Docker; DFIR-IRIS documents five services (app, PostgreSQL, RabbitMQ, worker, nginx), creates an administrator whose first password is written to the container log, and its maintainers advise against internet exposure and against using the master branch in production. Use tagged releases.
- Rehearse. Run a tabletop plus a technical drill on a test host: collect, image memory, build a timeline, run Sigma over EVTX. Record how long each step takes.
- Collect in order of volatility. RFC 3227 orders collection from registers, cache, routing and ARP tables, process table and memory, through temporary file systems and disk, to remote logs and archives. Do not shut a system down before collection completes.
- Preserve and record. Hash every acquisition, store it read-only, analyse copies, and keep dated notes stating whether times are UTC or local. See the Evidence Handling and Chain of Custody Guide.
- Roll back cleanly. After the incident, remove temporary collectors and accounts, rotate any credentials used by responders, and archive case data under your retention rules.
Where identity fits
Response tooling is highly privileged. The Velociraptor server can run VQL on every endpoint, and responders often need domain or cloud administrator rights to collect evidence. Give responder and tooling accounts their own identities with just-in-time elevation, require MFA on the server consoles, store API keys and collector certificates in a secrets manager, and rotate them after each major incident. Treat a compromise of the DFIR server as a compromise of the fleet. See the Identity Incident Response Playbook.
Detection and hardening value
DFIR tools do more than investigate: their output feeds detection and hardening. The mapping below shows how.
| Finding from investigation | Tool | Feeds back into |
|---|---|---|
| New persistence mechanism seen on one host | Velociraptor, Autopsy | Fleet hunt now; Sigma or VQL monitoring artifact for the future |
| Event log gaps or cleared logs | Chainsaw, Hayabusa | SIEM alert on log clearing and silent sources; log forwarding off-host |
| Credential material in memory | Volatility 3 | Credential Guard, LSASS protection, credential rotation |
| Attacker tool hash or file name | Plaso, MFTECmd | Block lists, EDR custom indicators, YARA rules |
| Command and control domain | Zeek, Arkime | DNS and proxy blocks, Suricata signature |
Metrics that show readiness and effectiveness:
- Collection coverage: percentage of endpoints with a healthy Velociraptor client, or with a tested offline collector path.
- Time to first artefacts: minutes from decision to collect until triage data is in the analysts' hands, measured in drills.
- Time to scope: hours to determine every affected host for a given indicator.
- Toolkit currency: days since Sigma rules, symbol packs and tool versions were last updated.
- Detections created per incident: number of new or improved detections fed back to the SOC after each case.
Framework mapping
| Framework | Reference | How the toolkit supports it |
|---|---|---|
| NIST CSF 2.0 | RS.AN-03 | Timeline and artefact analysis establish what happened and root cause |
| NIST CSF 2.0 | RS.AN-06, RS.AN-07 | Case notes in DFIR-IRIS, hashed collections and provenance records |
| NIST SP 800-53 Rev. 5 | IR-4, IR-5 | Incident handling and incident monitoring |
| NIST SP 800-53 Rev. 5 | AU-9 | Protecting collected log and audit evidence |
| CIS Controls v8.1 | Control 17 Incident Response Management | Documented tools, roles and exercises |
| Guidance | NIST SP 800-86; RFC 3227 | Forensic process, order of volatility, chain of custody |
See the CIS Control 17 Incident Response Management Guide.
Alternatives
| Option | Choose it when | Trade-off |
|---|---|---|
| Open source toolkit (this guide) | Skilled in-house responders, budget constraints, need for transparency in how artefacts are parsed | Integration, updates and training are your responsibility; no vendor support |
| Commercial forensic suite | Court-facing work, mobile device extraction, need for vendor validation and support | Licence cost; less flexible for fleet-wide triage |
| EDR live response | EDR already deployed everywhere; quick containment and file pulls | Limited artefact depth and retention; tied to one vendor |
| Incident response retainer | Small team, major incidents rare, need surge capacity | Responders still need your access and logs; agree tooling in advance |
Small versus large: a small team can rely on offline collectors, Hayabusa and a retainer, with Velociraptor deployed only on servers. Larger organisations usually run a permanent Velociraptor deployment, a shared Timesketch and case platform, and combine them with commercial tools for mobile and court work. See the Digital Forensics Tools Buyer's Guide and the Incident Response Retainer Buyer's Guide.
Common failure patterns
- Downloading tools during the incident: unverified binaries, missing dependencies and no symbol tables cost hours when they matter most.
- Analysing originals: running tools against the only copy of evidence, or trusting binaries on the compromised host, breaks the RFC 3227 principles.
- Shutting systems down first: memory evidence, including credential material and injected code, is lost.
- Exposed response platforms: case managers and collection servers left on the internet with default administrator credentials.
- Licence and status assumptions: using freeware commercially without checking terms, or relying on an archived project with no fixes.
- Findings that never reach detection: the case closes, but no Sigma rule, block or hardening change follows. See the Top 10 Incident Response Mistakes.
Practitioner checklist
- Document each tool, version, binary hash, licence and owner in the incident response plan.
- Deploy Velociraptor clients or pre-built offline collectors for every platform you run.
- Maintain an isolated analysis workstation with symbol packs, parsers and current Sigma rules.
- Host case management and timeline platforms privately, with MFA and tagged releases.
- Give responder and tooling accounts separate, just-in-time privileged identities and rotate their secrets after incidents.
- Collect in order of volatility, hash every acquisition and analyse copies only.
- Run a technical drill at least twice a year and record time to first artefacts and time to scope.
- Turn every case finding into a detection, block or hardening change.
Standards and references
- NIST: SP 800-86 Guide to Integrating Forensic Techniques into Incident Response
- IETF: RFC 3227 Guidelines for Evidence Collection and Archiving
- NIST: Cybersecurity Framework 2.0
- Velociraptor: Documentation overview
- Volatility Foundation: Volatility 3
- Plaso: User's Guide
- Yamato Security: Hayabusa
- DFIR-IRIS: IRIS web application
Related NHI Mgmt Group resources: Digital Forensics (DFIR) Guide · Incident Response Guide · Open Source SIEM and Detection Tools Landscape Guide · Sysinternals for Incident Responders Guide