Skip to content

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–6 hours◆ Beginner to intermediate✓ Evidence required
Self-hosted · Several hours

DFIR-IRIS Full Lab

Installation required

Already have a working DFIR-IRIS lab?

Confirm the instance is isolated, create a recovery snapshot, 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.

Objective

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:

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

cd <download-directory>
sha256sum --check SHA256SUMS

All three files must return OK. If your platform changes line endings during download, download the files again rather than updating the supplied hashes.

01

Activity 1: Prepare the environment

  1. Create an isolated Ubuntu VM and follow the DFIR-IRIS installation journey.
  2. Record image and package sources, versions, checksums, VM settings, network mode, and container health.
  3. Secure administrator access and create a named analyst account with only the required permissions.
  4. Create a fictional customer named Northwind Lab and a clean recovery snapshot.
  5. Verify the synthetic evidence pack against SHA256SUMS and record the analyst who performed the check.

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
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
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
  1. Add ENG-WS04 as a computer asset and record mira as the associated identity in the description or case notes.
  2. Add 203.0.113.77 to the IOC tab as an IP address with the tag training. Record that it is a reserved synthetic address and has not been proven malicious.
  3. Upload the three fixture files to the case datastore and mark each as evidence. Record its filename, source, collector, collection time, original location, and supplied SHA-256 hash.
  4. Add all four events to the timeline in chronological order and link them to ENG-WS04 where appropriate.
  5. Record two hypotheses: authorised archive handling and suspicious staging for possible transfer. State what additional endpoint or network evidence would distinguish them.
  6. Create and assign tasks for identity validation, endpoint preservation, destination review, and business-context confirmation.

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

03

Activity 3: Report and validate

  1. Complete the tasks with these internally consistent training findings:
    • identity: mira could not confirm the activity;
    • endpoint: archive creation and deletion are recorded, but archive contents and process intent are unavailable;
    • network: an outbound TLS connection is recorded, but transferred content and volume are unavailable;
    • business context: no approved archive-transfer activity was found for the time window.
  2. Record which systems and identities are in scope and which remain unconfirmed.
  3. Use a bounded conclusion: The observed sequence warrants escalation and further endpoint collection. The available records do not prove the archive contents or successful exfiltration.
  4. Generate a DFIR-IRIS report and review it as if you were a second analyst.
  5. Confirm the timeline, evidence references, owners, and limitations are understandable without oral context.
  6. Back up the database using the case-management walkthrough, verify the archive and checksum, and record how a restore would be tested in a disposable recovery instance.

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

Full Lab evidence checklist

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

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.