# DFIR-LABS: Windows forensic scenarios graded from easy to insane

> DFIR-LABS is a MIT licensed collection of incident response exercises spanning digital forensics, malware analysis and threat hunting, built as CTF style scenarios with flags and graded difficulty. It is a practice corpus for analysts and students rather than a tool, and its current edition covers Windows only, with some challenge files that are genuinely dangerous by design.

**Azr43lKn1ght/DFIR-LABS** — DFIR LABS - A compilation of challenges that aims to provide practice in simple to advanced concepts in the following topics: Digital Forensics, Incident Response, Malware Analysis and Threat Hunting.

- Repository: https://github.com/Azr43lKn1ght/DFIR-LABS
- Stars: 610 · Forks: 75
- Language: Python
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/azr43lkn1ght-dfir-labs

## A practice corpus, not an investigation toolkit

DFIR-LABS is a pile of exercises. The README describes it as a compilation of challenges meant to provide practice in simple to advanced concepts across four areas: digital forensics, incident response, malware analysis and threat hunting.

The stated audience is broad and worth quoting in spirit: professionals, security researchers, students, CTF players, and DFIR and malware analysis enthusiasts. In other words, the material is meant for someone who already understands what a Windows event log is and wants to apply that knowledge under realistic conditions.

What the repository is not is a tool. There is no analysis framework, no parser, no timeline builder and no command line. The primary language recorded for the repository is Python, which is the language the challenge files and helper scripts are written in, but the deliverable is the scenario, not the software. Every top-level directory in the tree corresponds to one challenge, and the README table indexes them by name, difficulty and author.

That structure matters for how you adopt it. You clone a directory of evidence, work the scenario, and move on. There is nothing to install and no pipeline to wire into, which also means there is no toolchain to keep current.

## Thirty eight scenarios on a four rung difficulty scale

The catalogue is the substance of the project. The README table lists challenges from Easy through Medium and Hard up to Insane, each with credited authors, and the table alone runs to thirty six entries.

The Easy set includes Gotham Hustle, Trinity Of Secrets, 2-layer security and Winserpart. The Medium band holds titles such as Covid Crime Scenario, pf-ing, Famous AMOS and The Malware Crusade. The Hard band carries Stealth, Interesting, Batman Investigation I, Master of DFIR - Phishing and ReAL File System. The Insane rung closes the list with Breadcrumbs, the DFIR 2025 II and III entries, the long Batman Investigation series up to VI, Kn1ghtw4r3, S4nct1m0ny, Kage No Nazo.

Two features of the catalogue are worth noticing. The Batman Investigation series runs across six numbered entries that begin at Hard and continue into Insane, which reads as a deliberately threaded storyline rather than a set of unrelated cases. And the three DFIR 2025 entries, covering a router, fake news and a spyder scenario, are dated in their names, which suggests the collection is versioned by edition rather than by release tag.

The README is careful about the grading itself, noting that the difficulty level of each challenge is subjective and may vary based on individual experience and skill level. Treat the labels as a rough ordering, not a benchmark.

## Flags for scoring, scenarios for the actual learning

The README makes an important distinction about format. Although the final goal of the challenges is CTF styled flags, most of the challenges use the traditional and effective learning method of answering an incident response scenario.

That is the useful bit for an analyst. A flag tells you whether you finished. A scenario asks you to work an investigation the way you would on a call: establish what happened, work out which host or user was involved, and produce a written answer. The two formats are compatible, since the flag can still be the answer to the scenario question, but the framing means the exercise is closer to a case file than to a puzzle box.

Order is another point of friction. The README states that the challenges are designed to be completed in a specific order, with each one building on the previous, while also noting that participants are free to attempt them in any order they prefer. The design intent is a progression from easy to insane, so a learner who jumps to the Insane tier first is choosing a harder path than the authors planned for.

Nothing in the tree documents how answers are checked or graded beyond the flag convention, and the README does not describe a scoring system, a leaderboard or an automated checker, so progress tracking is a manual affair.

## Challenge files that can compromise the machine running them

This repository deserves its warning section read carefully. The README states that individuals are strongly advised against executing any executables or binaries provided in the challenge files, because they may contain potentially malicious software, and that the authors hold no responsibility for consequences including system compromise, data loss or operational disruptions.

The warning is repeated and made more specific: the challenges are designed to simulate real-world scenarios and may contain potentially harmful software such as ransomware, trojan, stealers and command and control code. The stated mitigation is to conduct all activity inside a secure, isolated environment such as a virtual machine or sandboxed setup, with testing infrastructure configured to handle potential threats.

This is the central design trade-off of the project. A malware analysis exercise is weaker if the sample has been defanged, so the corpus ships realistic artifacts, and the reader accepts the risk in exchange for realism. The README's own advice is that the isolated environment is not optional.

The environment setup section begins with an isolated virtual machine as its first bullet, and the visible portion of that section is cut off there. The remaining setup guidance is therefore not available in the README text at hand, which is a gap for anyone setting up their own lab from the repository alone.

## Windows now, other platforms as a stated intention

The scope is narrower than the topic list suggests. The README says the first release of DFIR LABS focuses primarily on Windows based challenges, and that future and upcoming editions will broaden the scope to include Linux, macOS and Android.

That is a plan, not a shipping state, so an evaluator should read the repository as a Windows corpus. That is still a large surface, since the challenge topics named in the README cover ransomware style scenarios, phishing, command and control activity, file system artefacts, memory and disk images and network evidence such as router logs.

The repository layout reinforces the picture. Beyond the challenge directories there is a LICENSE, a README, a CONTRIBUTING.md and the logo image. There are no releases published on GitHub, so there is no version to pin and no changelog to read, and the only version marker is the edition naming inside the challenge titles. The repository is not archived and the last push was on 2026-09-20.

Licensing is the easy part. The project is MIT licensed, with a LICENSE file at the top level, so the scenarios, images and any scripts can be reused and remixed in a classroom or an internal training programme, provided the licence and copyright notice travel with them. The licence covers the exercise files; it says nothing about the third-party samples inside them, which is a separate question for anyone planning public distribution.

## Narrative packs versus your own evidence lab

There is a second way to build practice capability, and the difference in approach is worth spelling out.

One route is what DFIR-LABS does: a curated narrative with a fixed set of artefacts, a difficulty label and a verifiable answer. The artefacts are self contained, the environment is under your control, and the feedback is a flag. The cost is that the scenario is closed. You cannot ask a different question of the evidence, because the narrative was written for one question, and the realism is bounded by what the author chose to include.

The other route is to stand up your own evidence lab, with disk images, memory captures and network traffic you collect or generate yourself, and work them without a scripted answer. Nothing is pre-labelled, the questions are open, and a mistake in your triage has no consequence beyond wasting time. The cost is that you must build or source the dataset, and the feedback is only as good as your own checking.

For a team that already has tooling and wants to test judgement under uncertainty, the self built lab produces better transfer. For a learner who needs a curriculum, a difficulty ladder and a definite right answer, a scenario pack is far more efficient. The two are complements rather than substitutes, and the cheapest path for many people is to work a challenge pack first and then move to their own evidence.

## Conclusion

Adopt DFIR-LABS when you want a graded corpus of Windows incident response scenarios to rehearse triage, timeline building and malware triage before touching live evidence, and you have an isolated virtual machine ready to absorb challenge files that the README warns may contain ransomware, trojans, stealers and command and control code. Do not adopt it as a reference for Linux, macOS or Android work, since the first edition is Windows focused and the README describes broader platform coverage only as a future intention, and do not run any challenge outside a sandbox given the README's explicit warning about executing the provided binaries. Before starting, build the environment the setup section asks for, isolate a virtual machine, and read the difficulty note, since the grading from Easy to Insane is described as subjective and the challenges are meant to build on each other in order.

## FAQ

### What is DFIR-LABS and who is it for?

It is a compilation of challenges for practising digital forensics, incident response, malware analysis and threat hunting. The README aims it at professionals, security researchers, students, CTF players and DFIR enthusiasts.

### Is it safe to run the files included in DFIR-LABS challenges?

The README strongly advises against executing any executables or binaries in the challenge files, since they may contain ransomware, trojans, stealers and command and control code. Work on them only inside a virtual machine or sandbox.

### Which operating systems do the DFIR-LABS challenges cover?

The first release focuses primarily on Windows based challenges. Broader coverage of Linux, macOS and Android is described in the README as future and upcoming editions rather than as a current state.

### Do the DFIR-LABS challenges have answers or flags?

The final goal of the challenges is CTF styled flags, but the README says most challenges use the traditional method of answering an incident response scenario. The difficulty labels from Easy to Insane are described as subjective.

### What licence is DFIR-LABS released under?

The project is MIT licensed and a LICENSE file sits at the top level of the repository, so the challenge files can be reused and remixed provided the licence and copyright notice are retained.

## Sources

- [Azr43lKn1ght/DFIR-LABS on GitHub](https://github.com/Azr43lKn1ght/DFIR-LABS)
- [Issues](https://github.com/Azr43lKn1ght/DFIR-LABS/issues)
- [License: MIT](https://github.com/Azr43lKn1ght/DFIR-LABS/blob/main/LICENSE)
- [README](https://github.com/Azr43lKn1ght/DFIR-LABS/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/azr43lkn1ght-dfir-labs