DFIR-IRIS Hands-on Labs

Use the Interactive Lab to assemble a timeline from synthetic evidence, or the Full Lab to document a complete investigation in your own isolated DFIR-IRIS deployment.

Beginner terminology used in these labs

DFIR

Digital forensics and incident response: investigating security events while preserving evidence and coordinating response.

VM

Virtual machine: an isolated software-based computer used to run the lab safely.

TLS

Transport Layer Security: encryption used to protect network connections.

IOC

Indicator of compromise: an observable such as an IP address that may be relevant to an investigation; it is not proof of compromise by itself.

P2

Priority 2: an important case that needs prompt investigation but is below the most urgent priority.

SHA-256

Secure Hash Algorithm 256-bit: a value used to identify and integrity-check an evidence file.

Also useful: an asset is a system or account involved in the case, while provenance records where evidence came from and how it was collected.

Hands-on proof of concept

Preserve it. Sequence it. Explain it.

Build a defensible incident timeline, connect evidence to affected assets, and report what the records support without overstating them.

4–7 hours core Guided intermediate Evidence required

Start building

Self-hosted · Several hours

DFIR-IRIS Full Lab

Installation or working instance required

Already have a working DFIR-IRIS lab?

Confirm the instance is isolated, create a recovery snapshot, create or confirm the fictional Northwind Lab customer, download the synthetic evidence pack below, and begin with Activity 2.

Do not generate a real attack

This exercise uses synthetic records. You can complete it without executing malware, brute-force tools, or other attack simulation.

Before you begin

You need: an isolated DFIR-IRIS instance, a recovery point, a named analyst account that can manage cases and evidence, and a workstation that can verify SHA-256 hashes. Building from scratch also requires basic Ubuntu, Docker, file-transfer, and network-administration skills.

How to use this lab

Complete one session at a time. Stop when a checkpoint fails and fix that boundary before continuing. DFIR-IRIS labels can differ between 2.4.x releases; use the equivalent case, asset, IOC, datastore, timeline, task, and report views in your version.

Recommended first

Investigation Core Lab

Use an existing isolated DFIR-IRIS instance. Verify the supplied evidence, scope the case, construct the timeline, make an escalation decision, and produce a peer-reviewable report.

Expected time: 2–3 hours after the platform is working.

Build extension

Build from Scratch

Prepare the air-gapped deployment, secure access, validate container health, and take a baseline snapshot before starting the investigation.

Expected time: 2–4 hours, excluding unexpected troubleshooting.

1. Session 1Prepare and verify
2. Session 2Scope and sequence
3. Session 3Decide and report

Objective

Use or build an isolated DFIR-IRIS environment, create an investigation from a supplied fictional event set, construct a reliable timeline, preserve evidence metadata, and generate a reviewable report.

Synthetic evidence pack

Download these safe text fixtures. They contain no malware and use reserved example addresses:

• Identity sign-ins
• Endpoint events
• Network connections
• Analyst task results
• SHA-256 manifest

Keep the files unchanged and verify them before creating the case:

cd <download-directory>
sha256sum --check SHA256SUMS

All four evidence files must return OK. If a check fails, stop and download the named file again. Do not edit an evidence file or replace a supplied hash to force a successful result.

01

Activity 1: Prepare the environment

Use this activity only when you need to build the platform. Keep this page open and return after each linked checkpoint.

1. The build is recordedRecord image and package sources, versions, checksums, VM settings, network mode, and the planned snapshot name.
2. DFIR-IRIS is healthyCreate the isolated Ubuntu VM, follow the installation journey, and confirm every required container passes its documented health check.
3. Access is scopedSecure administrator access. Create a named analyst that can manage customers, cases, assets, IOCs, evidence, timelines, tasks, and reports without retaining platform-administrator access for routine casework.
4. The training tenant existsCreate the fictional customer Northwind Lab and confirm the named analyst can select it.
5. The baseline is recoverableCreate a clean snapshot named iris-working-baseline and record how to restore it.

Milestone 1Working baselineThe named analyst can sign in, select Northwind Lab, open a new case, and return to a known-good snapshot.

Expected result DFIR-IRIS is healthy, isolated, access-controlled, and ready for a synthetic case.

02

Activity 2: Build the investigation

Create the case with these values:

The fields follow the workflow described in the official case operations guide.

Field	Value
Customer	Northwind Lab
Case name	Unexpected archive and outbound connection
Owner	Your named analyst account
Priority	P2 — prompt investigation is required, but the supplied evidence does not establish an immediate enterprise-wide emergency
Status	Open
Classification	Information-Content-Security: Unauthorised access to information
Short description	Archive creation followed by an outbound TLS connection
SOC ticket ID	SOC-2026-042

Use these records from the supplied fixtures:

Time	Source	Event
09:57	Identity	Service account svc-update signs in to UPD-SRV01 during approved maintenance
10:02	Identity	User mira signs in to ENG-WS04
10:08	Endpoint	powershell.exe creates C:\Temp\project.zip
10:11	Network	ENG-WS04 connects to 203.0.113.77:443
10:14	Endpoint	Archive is deleted

Preserve and scope the evidence

1. Verify all four evidence files against SHA256SUMS. Record the verification time and analyst; do not continue unless every file returns OK.
2. Create or confirm the Northwind Lab customer, then create the case using the values above.
3. Add ENG-WS04 as a computer asset and record mira as the associated identity in the description or case notes.
4. Review the 09:57 maintenance sign-in. Record svc-update and UPD-SRV01 as reviewed but excluded because the supplied task results identify it as expected maintenance unrelated to the later activity.
5. Add 203.0.113.77 to the IOC tab as an IP-address observable with the tag training. The IOC view is being used to track the value; record that the reserved synthetic address has not been proven malicious.
6. Upload all four fixtures to the case datastore and mark each as evidence. For each file, record its filename, source, collector, verification time, original download location, and supplied SHA-256 hash.

Navigation hint: use Cases → Add case, then open the case and use Assets, IOCs, and the datastore’s Evidences → Add file action. Uploading preserves the source files; it does not automatically create timeline events from their contents.

Build the timeline and investigation plan

1. Read the preserved fixtures and manually add the four in-scope events from 10:02–10:14 to the timeline in chronological order. Link them to ENG-WS04 where appropriate. Do not add the excluded 09:57 event to the incident sequence.
2. Record two hypotheses: authorised archive handling and suspicious staging for possible transfer. State what additional endpoint or network evidence would distinguish them.
3. Create tasks for identity validation, endpoint preservation, destination review, and business-context confirmation.
4. Assign every task to a named owner, set a due date within the lab session, and leave it open until its corresponding result in analyst-task-results.txt is recorded as a task log.

Navigation hint: use the case Timeline → Add event action for the sequence and the case task view for assignments, due dates, and analyst logs.

Milestone 2Evidence scoped and sequencedThe source files are preserved, the unrelated maintenance event is excluded with a reason, and every in-scope timeline fact points back to evidence.

Expected result The timeline separates facts from hypotheses and every important claim points to a preserved evidence record.

03

Activity 3: Report and validate

Record the supplied task results

Use analyst-task-results.txt as the source for the four task logs. Record the named source owner and result, then complete the corresponding task. Do not present these findings as if they came from the CSV or JSONL telemetry.

Make the analyst decision

Before reading the recommended outcome, choose one disposition and record a one-sentence rationale:

• close as expected authorised activity;
• escalate for further endpoint collection; or
• declare confirmed data exfiltration.

The supported decision is escalate for further endpoint collection. Mira could not confirm the activity, no approved transfer was found, and the archive and outbound connection form a suspicious sequence. However, the records do not reveal archive contents, process intent, transferred content, or volume, so confirmed exfiltration would overstate the evidence.

Generate and peer-review the report

1. Record ENG-WS04 and mira as in scope. Record UPD-SRV01 and svc-update as reviewed and excluded. Keep the ownership or intent behind the archive unconfirmed.
2. Use this bounded conclusion: The observed sequence warrants escalation and further endpoint collection. The available records do not prove the archive contents or successful exfiltration.
3. Confirm an investigation report template is available, then generate a DFIR-IRIS report from Case summary → Generate report. Use safe mode if your template or environment contains untrusted images.
4. Review the output as a second analyst. The report passes when it identifies the owner and P2 rationale, cites the four preserved files, distinguishes the excluded maintenance event, orders the four in-scope events, separates facts from hypotheses, states the next collection action, and preserves the limitations above.
5. Correct the case record and regenerate the report if any item is missing. Record the review date and reviewer name.

Milestone 3Decision reviewableAnother analyst can reproduce the sequence, understand why it was escalated, and see why successful exfiltration remains unproven.

Optional operations extension: back up and restore

Use a platform-administrator account—not the routine analyst account—to follow the database-backup section of the case-management walkthrough. Verify the archive and checksum, then test the documented restore process only in a disposable recovery instance. A valid checksum proves file integrity; only a successful recovery test proves restorability.

Expected result A second analyst can reproduce the sequence, trace every conclusion to evidence, and understand the investigation's limitations.

Full Lab evidence checklist

• Build record, access controls, container health, and recovery point.
• All four synthetic fixtures verified successfully against the supplied SHA-256 manifest.
• Customer, owner, P2 rationale, in-scope assets and identity, tracked observable, and documented maintenance exclusion.
• Evidence provenance, collection times, original locations, and hashes.
• Chronological timeline with facts separated from hypotheses.
• Named task owners, due dates, supplied task-result logs, and completion states.
• Peer-reviewed report with supported escalation, uncertainty, evidence references, and recommended next action.
• Sanitised exports retained and synthetic case, temporary access, and disposable test state cleaned up.

0 of 8 recorded Mark each item after saving the evidence.Reset

Clean up

Export the sanitised report and evidence notes you intend to keep. Remove the synthetic case and temporary accounts if the instance will be reused, or revert the disposable VM to its clean snapshot. Do not retain generated administrator credentials in screenshots or lab submissions.

PreviousManage a caseNextReturn to overview