DAY 03 · LAB PROJECT 01 5 HOURS · 2-3-3 PONDERATION DUE · MIDNIGHT EST · SUN MAY 3, 2026 OPEN-TOOL POLICY

First Response
& Evidence Handling

A hands-on lab project for the cumulative Incident Management portfolio. Five hours of work — not five hours of reading — to secure a digital crime scene, capture volatile and persistent evidence, and produce a five-page research report a lawyer could actually use.

5 hWorking time
2 + 3 + 3Weighting
5 ppA4 deliverable
1 / 9Portfolio chapter
What you'll hand in

One ZIP, five things inside

Submit to the LMS — Learning Management System — on or before the due date.
  • report.pdf — the graded 5-page report + cover
  • case-archive.tar.gz — sealed evidence directory
  • master_sha256.txt — integrity hash of the archive
  • coc_form.pdf — completed and signed chain of custody
  • ir_notebook.txt — full unedited responder notebook
!
Read this before you touch a virtual machine. Every technique below is taught for the academic objective of preparing students to defend networks and respond to incidents inside their own employer or client engagement. The procedures stay strictly inside virtual machines you control on your own laptop. Use against any system you do not own — or do not have explicit, written authorisation to test — is unlawful. The instructor and Cyber.SoHo Educational Hub are not responsible for use of these techniques outside the lab boundary defined in the Disclaimer section at the bottom of this page.
Overview

How this lab fits into your nine-week portfolio

Each week of the Incident Management course produces one chapter of your final individual project. Today's report becomes your Chapter 1 — write it cleanly enough that the version you bind at the end of term is the version you submit tonight.

WeekChapter (your portfolio section)
2Securing Crime Scenes & Collecting Digital Evidence ← this lab
3Malware Detection, Analysis & Containment
4Analysing Email Headers & Tracing Attacks
5Mid-Term Review
6Mid-Term Examination
7Network Traffic Analysis & Incident Validation
8Detecting & Eradicating Insider Activity
9Mobile & IoT (Internet of Things) Forensics and Analysis
10Final Review and Examination

📌 The five-hour rule

Five hours of work, not five hours of reading. Read this whole brief once, fast — call it a 20-minute warm-up that does not eat your budget. The clock starts when you open your terminal for Step A.1.

If you reach the five-hour mark before completing every step, stop and submit what you have. A partial, well-documented response is graded; a complete but rushed and undocumented one is not.

Learning objectives

By the moment you upload your ZIP, you will be able to:

  1. Secure a digital crime scene to a defensible standard before any evidence is touched.
  2. Capture volatile and non-volatile digital evidence in the order recommended by the IETF in RFC 3227 — Guidelines for Evidence Collection and Archiving.
  3. Hash each captured artefact with SHA-256 (Secure Hash Algorithm, 256-bit) and record the hash on a chain-of-custody form.
  4. Document every action with the 5W+H discipline (Who, What, Where, When, Why, How) in a contemporaneous IR (Incident Response) notebook.
  5. Produce a five-page professional research report with proper screenshots, hyperlinks, copyright-safe images, and academic citations.

These objectives align with NIST SP 800-61 Revision 2 — published by the National Institute of Standards and Technology — and with ISO/IEC 27037:2012, the international standard published jointly by the International Organization for Standardization and the International Electrotechnical Commission.

Setup · before the clock starts

What to install on Saturday so Sunday counts

Time spent installing software does not count against your five-hour budget. Set everything up the day before, snapshot both VMs (Virtual Machines), and verify network reachability between them. If you cannot snapshot, you are not ready.

  1. Virtualisation platform on your laptop — either Oracle VirtualBox 7.x (free) or VMware Workstation Player 17.x (free for personal use). Either works; pick one and learn it.
  2. Responder VM — Kali Linux 2025.4 or Parrot Security 6.4, both available as pre-built OVA (Open Virtualization Appliance) images.
  3. Target VM ("the victim") — Ubuntu 22.04 LTS (Long Term Support) Desktop with at least 2 GB RAM and 20 GB disk.
  4. Shared folder on your host laptop named lab03_evidence/ — this represents the removable USB drive in the scenario; share it into the responder VM as a read-write mount.
  5. Plain-text editor that does not auto-format — Notepad++, VS Code, or nano.
  6. Report toolchain — either LibreOffice Writer, Microsoft Word, or a Markdown-to-PDF tool such as Pandoc.
Open-tool policy

Every tool listed in this lab is a suggestion, not a requirement. If you prefer QEMU/KVM over VirtualBox, use it. If you want to write your own evidence-capture script in Go, Rust, or Python instead of Bash — please do, and explain your choice in the report. The lab grades the process, not the toolset.

The scenario you will work in

NorthBridge Health Cooperative · Tuesday, 28 April 2026

A small, fictional clinic in the lab simulation. Any resemblance to a real organisation, patient, or ransomware family is coincidental — the names, dates, and IP addresses below are invented for didactic purposes.

Case ID: CASE-NBH-2026-04-28-001
Reported: 08:51 local · 13:51 UTC
Affected user: "Anna" (office manager)
Suspected nature: Ransomware
NorthBridge Health Cooperative is a small medical clinic with 28 staff and a single Linux file server. On the morning of Tuesday, 28 April 2026, the office manager — Anna — arrives at her desk at 08:47 local time and finds her Ubuntu workstation showing an unfamiliar terminal window. The text on the screen reads:
Your files have been visited.
Do not turn off this computer.
Wait for further instructions.

Several patient appointment files on the shared drive return a "permission denied" error from her terminal. Anna calls the IT (Information Technology) helpdesk at 08:51. You are the on-call first responder.

Your task for the next five hours: secure the scene, collect digital evidence in a forensically sound manner, and produce a five-page report that the clinic's lawyer can hand to the Agencia Española de Protección de Datos (AEPD) within the seventy-two-hour breach-notification window mandated by Article 33 of the GDPR — the General Data Protection Regulation.

The "Anna's workstation" in this scenario is your Target VM. You will simulate the responder workflow against it from your Responder VM.

Time budget at a glance

PartTitleWeightWorking time
ASecuring the digital crime scene2 / 8≈ 60 min
BCollecting digital evidence3 / 8≈ 120 min
CWriting the 5-page research report3 / 8≈ 120 min
Total8 / 8300 min · 5 h
⚒

Open tools, open techniques, open creativity

Every command, library, and workflow that follows is one defensible way to reach the lab outcome. You are encouraged to substitute any of them with a tool you find yourself in the open-source ecosystem, a script you write from scratch, or a method described in a paper you have read. The point of the exercise is the discipline of the response, not loyalty to any particular utility.

Research thoroughly — read the RFC, read the NIST guide, read recent DFIR (Digital Forensics and Incident Response) blog posts from SANS, read the FIRST incident handler guidelines — then make your own choices and defend them in the report.

A
Part A · ≈ 60 minutes

Securing the digital crime scene

Establish the scene before anything is touched: define perimeter, document state, restrict access, identify evidence sources. You will not touch the keyboard of the target VM until Part B.

2 / 8 POINTS 5 STEPS · A.1 → A.5
A.1
Set up the lab clock and your IR notebook
10 MIN

Open a terminal on your responder VM and confirm the system clock is in UTC (Coordinated Universal Time). Every timestamp in your notebook from this point forward must be UTC — local time is forbidden.

Bashresponder VM · check & set clock
# expected output similar to: Tue Apr 28 13:47:00 UTC 2026
$ date -u
# if your VM is on local time, switch it
$ sudo timedatectl set-timezone UTC

Create your case directory on the shared folder, then create the IR notebook file:

Bashcase directory bootstrap
$ mkdir -p ~/lab03_evidence/CASE-NBH-2026-04-28-001/{notebook,volatile,nonvolatile,photos,custody}
$ cd ~/lab03_evidence/CASE-NBH-2026-04-28-001
$ touch notebook/ir_notebook.txt

Make the first three entries in the notebook now. Use this exact entry format — copy it; do not invent your own:

Notebookir_notebook.txt — first three entries
=== ENTRY 0001 ===
WHEN  : 2026-04-28T13:47:00Z
WHO   : <Your Full Name>, Student ID <…>, Cyber.SoHo Lab Project 01
WHAT  : Started case file CASE-NBH-2026-04-28-001
WHERE : Responder VM (Kali 2025.4) on host laptop
WHY   : Anna at NorthBridge Health called helpdesk at 08:51 local;
        suspect ransomware on her Ubuntu workstation
HOW   : Created /home/<user>/lab03_evidence/CASE-NBH-2026-04-28-001/

=== ENTRY 0002 ===
WHEN  : 2026-04-28T13:48:30Z
WHO   : <Your Full Name>
WHAT  : Confirmed Responder VM clock is on UTC
WHERE : Responder VM
WHY   : All evidence timestamps must be UTC per Lesson 4
HOW   : `date -u` returned <paste literal output here>

=== ENTRY 0003 ===
WHEN  : 2026-04-28T13:50:00Z
WHO   : <Your Full Name>
WHAT  : About to take baseline photograph of Target VM screen
WHERE : Target VM console (no input yet)
WHY   : Preserve scene-as-found before any interaction
HOW   : Will use host-OS screenshot tool, save to photos/00_scene_as_found.png
Discipline reminder

From here on, write at least one notebook entry before every step. Forgot? Add it retrospectively — but mark it as such with both WHEN-RETRO: and WHEN-LOGGED: timestamps. Never silently fix the past — that is the difference between a defensible record and a fabricated one.

A.2
Photograph the scene-as-found
10 MIN

Without clicking anything on the target VM, capture three baseline images:

  1. Full-screen screenshot of the target VM's current state → photos/00_scene_as_found.png
  2. Screenshot of the target VM's network adapter settings (right-click VM → Settings → Network) → photos/01_network_settings.png
  3. Screenshot of the responder VM terminal showing date -u output and the directory listing → photos/02_responder_baseline.png

Hash each image and add the hash to the matching notebook entry.

Bashhash baseline screenshots
$ sha256sum photos/00_scene_as_found.png
$ sha256sum photos/01_network_settings.png
$ sha256sum photos/02_responder_baseline.png
Why hash a photograph?

Two months from now, in a hearing or audit, the question will be: "has this image been edited since the night of the response?" The hash printed in your notebook entry is the answer.

A.3
Establish the logical perimeter
15 MIN

Isolate the target VM from the public internet without powering it off. In your virtualisation platform, change the target VM's network adapter from NAT (Network Address Translation) or Bridged to Internal Network named crime-scene. The VM stays running but cannot phone home to a C2 (Command and Control) server.

Move the responder VM onto the same internal network so you keep reachability. Both VMs now share crime-scene; both are isolated from your home network and the public internet.

Bashverify isolation from responder
# adapt the range to your internal network
$ nmap -sn 192.168.99.0/24

Capture photos/03_isolation_before.png and photos/04_isolation_after.png with hashes and notebook entries for every change.

A.4
Identify and label evidence sources
15 MIN

Walk the responder through this checklist; in your notebook record yes / no for each, with a one-line justification. This is your evidence-source inventory.

#Potential evidence sourceIn scope today?
1Target VM RAM (live process memory)yes / no
2Target VM running processes listyes / no
3Target VM open network connectionsyes / no
4Target VM logged-in usersyes / no
5Target VM /var/log/ system logsyes / no
6Target VM /etc/ configuration filesyes / no
7Target VM /home/anna/ user directoryyes / no
8Target VM full disk imageyes / no
9Network packet capture from crime-scene LAN (Local Area Network)yes / no
10Office camera footageyes / no (out of lab scope)

For each yes, name the tool you intend to use, the output filename, and the sequential evidence ID — EVIDENCE-001, EVIDENCE-002, and so on. Save the inventory as nonvolatile/evidence_inventory.md; this becomes Appendix A of your report.

A.5
Build the chain-of-custody form
10 MIN

Inside custody/, create coc_form.md using the template below. You will fill it in as Part B progresses; it does not need to be complete at the end of Part A.

Markdowncustody/coc_form.md — template
CHAIN OF CUSTODY FORM
=====================
Case ID         : CASE-NBH-2026-04-28-001
Case description: Suspected ransomware incident at NorthBridge Health Cooperative
Custody opened  : 2026-04-28T13:47:00Z
Custody closed  : <to be filled at end of Part B>

Acquiring person : <Your full name>, Student ID <…>
Affiliation      : Cyber.SoHo Educational Hub / Schiller International University

EVIDENCE MANIFEST
-----------------
| Item ID       | Filename       | Type | SHA-256                     | Acquired (UTC)        |
|---------------|----------------|------|-----------------------------|-----------------------|
| EVIDENCE-001  |                |      |                             |                       |
| EVIDENCE-002  |                |      |                             |                       |
| ...           |                |      |                             |                       |

TRANSFER LOG
------------
| Date/Time (UTC)       | From          | To              | Method     | Initials |
|-----------------------|---------------|-----------------|------------|----------|
| 2026-04-28T13:47:00Z  | (acquisition) | <Your initials> | first cap. |          |

INTEGRITY DECLARATION
---------------------
I declare that the evidence above was acquired in accordance with IETF RFC 3227,
ISO/IEC 27037:2012, and NIST SP 800-61 Rev. 2 procedures, and that the SHA-256
hashes were computed at the time of acquisition.

Signed: ________________________      Date: ________________________
Marker for Part A

When Part A is finished you should have: a populated case directory; an IR notebook with at least eight numbered entries; four to six baseline photographs (each hashed); a completed evidence-source inventory; and a chain-of-custody template ready to fill in.

B
Part B · ≈ 120 minutes

Collecting digital evidence

Climb the volatility pyramid. For every artefact: capture, hash, log, transfer, repeat. The original is sacred — analysis runs on a copy.

3 / 8 POINTS RFC 3227 ORDER

Part B follows the order of volatility prescribed by IETF RFC 3227. For each artefact you will: (1) capture it on the target VM, (2) push it to the responder over SCP (Secure Copy Protocol), (3) hash it on the responder with SHA-256, (4) record the hash on the chain-of-custody form, and (5) add a notebook entry. Every capture in this part is performed from the responder VM, over the internal network.

One-time SSH-key push

On the target VM, as Anna, run ssh-copy-id <responder_user>@<responder_ip> once. From that point you can scp files to the responder without typing a password.

B.1 — Capture volatile evidence (60 min)

1
Process table
ps -auxef --forest — what is running, in what parent-child tree
2
Network connections
ss -tunap · lsof -i -nP — every open socket and the process behind it
3
Logged-in users
who -a · last · w — who is on the box, who has been on it
4
Open files
lsof — every file descriptor held by every process
5
ARP & routing
ip neigh · ip route — neighbours seen, paths taken
6
RAM image
Built using LiME — Linux Memory Extractor — the most important capture in the lab
B.1
Process table, network, users, open files, ARP
21 MIN total · 5 + 5 + 3 + 5 + 3

Each artefact is captured on the target into /tmp/vol/, then pushed to the responder where it is hashed and logged. The EVIDENCE-001 through EVIDENCE-005 identifiers go on the chain-of-custody form in the same order.

Bashtarget VM · capture & push
$ sudo mkdir -p /tmp/vol

# EVIDENCE-001 — process table
$ ps -auxef --forest > /tmp/vol/01_processes.txt 2>&1
$ scp /tmp/vol/01_processes.txt <responder>@<ip>:~/lab03_evidence/CASE-NBH-2026-04-28-001/volatile/

# EVIDENCE-002 — network connections
$ ss -tunap > /tmp/vol/02_network_connections.txt
$ sudo lsof -i -nP >> /tmp/vol/02_network_connections.txt 2>&1

# EVIDENCE-003 — logged-in users
$ who -a > /tmp/vol/03_logged_in.txt
$ last -F -n 50 >> /tmp/vol/03_logged_in.txt
$ w >> /tmp/vol/03_logged_in.txt

# EVIDENCE-004 — open files
$ sudo lsof > /tmp/vol/04_open_files.txt 2>&1

# EVIDENCE-005 — ARP and routing
$ ip neigh show > /tmp/vol/05_arp_table.txt
$ ip route show >> /tmp/vol/05_arp_table.txt

On the responder, hash each file as it arrives, take a screenshot of the hash output, and log a notebook entry referencing the matching EVIDENCE-XXX identifier:

Bashresponder VM · hash on arrival
$ cd ~/lab03_evidence/CASE-NBH-2026-04-28-001/volatile/
$ sha256sum 01_processes.txt
$ sha256sum 02_network_connections.txt
$ sha256sum 03_logged_in.txt
$ sha256sum 04_open_files.txt
$ sha256sum 05_arp_table.txt
B.1.6
RAM acquisition with LiME — the headline capture
35 MIN

The most important capture in the whole lab. LiME is a Linux kernel module specifically designed for forensic memory acquisition; it produces an image you can later analyse with Volatility 3.

Bashtarget VM · build LiME and acquire RAM
# 1) Install build prerequisites and clone LiME from upstream
$ sudo apt update
$ sudo apt install -y build-essential linux-headers-$(uname -r) git
$ git clone https://github.com/504ensicslabs/lime.git ~/lime
$ cd ~/lime/src
$ make

# 2) Acquire RAM directly to disk in LiME format
$ sudo insmod ./lime-$(uname -r).ko "path=/tmp/vol/06_ram.lime format=lime"
$ sudo rmmod lime
$ ls -lh /tmp/vol/06_ram.lime

# 3) Push to responder (1–3 minutes typically)
$ scp /tmp/vol/06_ram.lime <responder>@<ip>:~/lab03_evidence/CASE-NBH-2026-04-28-001/volatile/

On the responder: hash as EVIDENCE-006, take two screenshots — one for the hash, one for the file size, since the RAM-image size is itself a piece of evidence. Then add the notebook entry.

Why memory matters more than the disk

Most ransomware encryption keys live in RAM at the moment of detonation. Capturing memory before the malware process completes and exits is often the difference between recovering data and paying. See your Day 02 lecture notes, Lesson 3.

B.1.7
Volatile manifest
4 MIN
Bashresponder VM · build the manifest
$ cd ~/lab03_evidence/CASE-NBH-2026-04-28-001/volatile/
$ sha256sum *.txt *.lime > MANIFEST.sha256
$ sha256sum MANIFEST.sha256 > MANIFEST.sha256.itself

Paste the literal output of cat MANIFEST.sha256 into a notebook entry and record both manifest hashes on the chain-of-custody form.

B.2
Capture non-volatile evidence — targeted, not full disk
45 MIN

Imaging the entire disk would consume the whole five-hour budget. Capture three targeted areas instead: the system-log archive, user-directory metadata, and a sample of the encrypted files.

B.2.1 · System logs (15 min)

Bashtarget → responder · /var/log archive
$ sudo tar -czf /tmp/vol/10_var_log.tar.gz /var/log/ 2>/dev/null
$ scp /tmp/vol/10_var_log.tar.gz <responder>@<ip>:~/lab03_evidence/CASE-NBH-2026-04-28-001/nonvolatile/

On the responder, hash as EVIDENCE-010. Then copy the archive into a working directory and extract that copy for analysis. The original in nonvolatile/ is never modified — that is the "original is sacred" principle from the chain-of-custody lecture.

B.2.2 · User-directory file listing (10 min)

Do not copy Anna's whole home directory — it may contain PHI (Protected Health Information). Capture metadata only: filenames, sizes, modification times, hashes.

Bashtarget VM · metadata-only capture
$ sudo find /home/anna -type f -exec ls -la {} \; > /tmp/vol/11_anna_filelist.txt 2>/dev/null
$ sudo find /home/anna -type f -exec sha256sum {} \; > /tmp/vol/12_anna_filehashes.txt 2>/dev/null
$ scp /tmp/vol/11_anna_filelist.txt /tmp/vol/12_anna_filehashes.txt <responder>@<ip>:~/lab03_evidence/CASE-NBH-2026-04-28-001/nonvolatile/

Hash both as EVIDENCE-011 and EVIDENCE-012; notebook entries for each.

B.2.3 · Three encrypted-file samples (15 min)

Identify three files in 12_anna_filehashes.txt with anomalous extensions — .locked, .encrypted, .crypt — and copy only those three. This minimises PHI exposure while preserving the malicious modification.

Bashtarget → responder · sample copy
$ mkdir -p /tmp/vol/encrypted_sample
$ sudo cp /home/anna/Documents/*.locked /tmp/vol/encrypted_sample/  2>/dev/null
$ sudo chown -R anna:anna /tmp/vol/encrypted_sample
$ scp -r /tmp/vol/encrypted_sample <responder>@<ip>:~/lab03_evidence/CASE-NBH-2026-04-28-001/nonvolatile/

Hash each file individually as EVIDENCE-013, EVIDENCE-014, EVIDENCE-015. Screenshots and notebook entries.

B.2.4 · Non-volatile manifest (5 min)

Bashresponder VM
$ cd ~/lab03_evidence/CASE-NBH-2026-04-28-001/nonvolatile/
$ find . -type f -exec sha256sum {} \; > MANIFEST.sha256
B.3
Sealing and closing custody
15 MIN

Compute a master hash that covers the entire case directory:

Bashresponder VM · master archive & hash
$ cd ~/lab03_evidence/
$ tar -czf CASE-NBH-2026-04-28-001.tar.gz CASE-NBH-2026-04-28-001/
$ sha256sum CASE-NBH-2026-04-28-001.tar.gz

Screenshot the master hash → photos/99_master_hash.png; hash the screenshot; log the entry.

Update custody/coc_form.md: set Custody closed to the current UTC timestamp, append the master hash to the integrity declaration, sign your name and date. Final notebook entry: custody is closed; all subsequent work is analysis on a copy.

Marker for Part B

You should have six volatile artefacts (EVIDENCE-001…006), six non-volatile artefacts (EVIDENCE-010…015), two manifests, a master hash, a complete chain-of-custody form, and a notebook with at least 30 entries — every one in UTC, every one with 5W+H.

C
Part C · ≈ 120 minutes

Writing the 5-page A4 research report

A strict 5-page A4 maximum, plus cover. Reports of six pages or more receive zero on Part C. Write it cleanly enough that you bind the same version into your final portfolio at the end of term.

3 / 8 POINTS PDF ONLY

C.1 — Document skeleton (10 min)

Use any tool that produces a clean A4 PDF: LibreOffice Writer, Microsoft Word, Google Docs with PDF export, or Markdown + Pandoc. Submit only the PDF — never .docx, .odt, or .md.

Format requirementValue
Page sizeA4 — 210 × 297 mm
Margins2.5 cm on every side
FontCalibri or Carlito — 11 pt, body justified
HeadingsSame family, 13–16 pt bold — do not invent a different font
Line spacing1.15
Page numbersCentred footer, Page X of 5
Header (every page)Left: Cyber.SoHo · Day 03 · Project 01 · Lab Report · Right: your name + student ID
Cover page (page 0, not counted)Title · your name · student ID · course · instructor · date · Cyber.SoHo logo

C.2 — Required chapters (5 pages total · written in this order)

1
Executive Summary — ½ page · page 1 top
≤ 150 WORDS

One paragraph in plain English: what was the incident, what did you do, what was the most important finding, what is your main recommendation. Write this last but place it first.

2
Lab Environment & Scope — ½ page · page 1 bottom

Host laptop specs, virtualisation platform and version, both VMs (responder + target), the internal network used for isolation, the date, and the responder identity. Include one labelled topology diagram — sketch in draw.io or Excalidraw and export as PNG.

3
Methodology — ~ 1 page · page 2

Numbered subsections describing Part A and Part B. Do not paste raw command output — paste the commands and reference the resulting evidence by its EVIDENCE-XXX identifier. Cite NIST SP 800-61 Rev. 2, RFC 3227, and ISO/IEC 27037:2012. No more than 2 figures in this chapter.

4
Findings & Evidence Summary — ~ 1.5 pages · pages 3 and top of 4

The analytical heart of the report. Provide:

  • An evidence table with item ID, filename, size, SHA-256 (truncated to first 16 hex characters), brief description.
  • At most three annotated screenshots of meaningful findings — a suspicious process tree from EVIDENCE-001, an anomalous outbound socket from EVIDENCE-002, the rename pattern in EVIDENCE-013/014/015.
  • A short narrative connecting the artefacts into a working hypothesis of what happened on Anna's workstation.
5
Discussion & Lessons Learned — ½ page · page 4

What went well, what would you do differently, what was harder than expected, what evidence might exist that you did not capture, what is the next investigative step. Be concrete and self-critical — graders reward honesty here.

6
References — ¼ page · page 5 top

IEEE numeric citation style (Institute of Electrical and Electronics Engineers) throughout the body. Five sources minimum, twelve maximum.

A
Appendix A — Evidence Inventory — ¼ page · page 5 bottom

Reproduce nonvolatile/evidence_inventory.md from Part A.4. If anything does not fit on page 5, cut it — do not add a page.

C.3 — Screenshots — six rules (15 min)

  1. Crop to the relevant region. Never paste a full 1920×1080 desktop into a report — crop to the terminal, the dialog, the figure region. 600–900 px wide is the sweet spot.
  2. Annotate every screenshot with at least one arrow, box, or callout pointing to the thing the screenshot is about. Use Greenshot, Flameshot, ShareX, or your operating system's built-in markup. Red boxes / yellow arrows are conventional.
  3. Caption every screenshot directly underneath: Figure 1: SHA-256 hash of EVIDENCE-001 captured on the responder VM at 13:55 UTC. Reference figures by number from the body text.
  4. Redact PII / PHI with a solid black rectangle. Never blur — blur can be reversed with publicly available tools.
  5. Format: PNG (Portable Network Graphics) for terminal output and screenshots; JPEG (Joint Photographic Experts Group) for photographs of physical equipment. Never a phone-camera photo of a screen if a digital screenshot is possible.
  6. Resolution: at least 150 DPI (Dots Per Inch). Pandoc and Word downscale by default; verify text readability at the printed size.
Never embed evidence files into the PDF

The 4 GB RAM image does not appear inside report.pdf. You reference it by EVIDENCE-006 and its hash. The PDF stays small, the evidence stays sealed.

C.4 — Hyperlinks (5 min)

C.5 — Images — protect the original authors (10 min)

Whenever you use an image you did not create yourself — a logo, an icon, a stock photograph, a diagram from a paper — you must protect the rights of the original author. Only four licence categories are acceptable for this lab:

Licence categorySource examplesRequired attribution caption
Public domain (CC0 — Creative Commons Zero) Wikimedia Commons CC0-tagged · Pixabay · Unsplash Source: <author>, public domain (CC0), <link>
Creative Commons Attribution (CC BY) Wikimedia Commons CC BY · Flickr Commons · Wikipedia Source: <author> / <platform>, CC BY <version>, <link>
Government / standards-body works NIST · CISA · ENISA Source: NIST (US Government work, public domain), <link>
Your own screenshot or your own diagram You produced it Source: own work, <date>
Forbidden — automatic zero on Part C

Images saved from a Google Images search whose origin you cannot prove · paid stock photographs without your active licence · movie / TV stills, copyrighted comic-book characters, brand mascots · screenshots from a paid course, paid book, or paywalled website · anything where you cannot identify the licence in writing under the image. If you have any doubt, do not use the image. A diagram you sketched yourself in five minutes in Excalidraw is always preferable to an unattributed image.

C.6 — Pre-submission checklist (10 min)

Walk through this immediately before exporting your PDF:

Submission

One ZIP to the LMS — five files inside

Filename convention: <lastname>_<firstname>_day03_project01.zip. The Schiller International University LMS clock is the canonical clock — do not depend on your laptop's.

📦 lastname_firstname_day03_project01.zip
└── report.pdf ← the graded 5-page report + cover
└── evidence/CASE-NBH-2026-04-28-001.tar.gz ← sealed case directory
└── evidence/CASE-NBH-2026-04-28-001.master_sha256.txt ← master integrity hash
└── evidence/coc_form.pdf ← signed chain of custody
└── notebook/ir_notebook.txt ← full unedited IR notebook
Late policy

The LMS submission window closes at midnight EST on Sunday, May 3, 2026 and re-opens only by request to the instructor for documented serious illness or family emergency. Equipment failure, broken VMs, lost passwords, internet outages, and "I forgot" are not accepted excuses. Submit a partial report by the deadline rather than a complete one after.

Grading rubric — eight points total

ItemPtsWhat graders look for
Part A · Securing the scene2Lab clock on UTC; case directory present; ≥4 baseline photos hashed; isolation evidence; populated evidence inventory; chain-of-custody template ready.
Part B · Evidence collection3Six volatile artefacts in correct order; non-volatile sample correct; every artefact hashed; manifests present; master hash & signed chain of custody.
Part C · Research report3Exactly 5 A4 pages + cover; six required chapters; ≤6 annotated & captioned figures; every image attributed; IEEE references; abbreviations expanded; clean PDF; working hyperlinks.
Penalties

−2 pts any unattributed image or image from a forbidden category  ·  −1 pt report body > 5 pages  ·  −1 pt per missing UTC timestamp in the IR notebook  ·  −1 pt any broken hyperlink in the PDF  ·  0 on Part C if the deliverable is not a PDF.

An invitation

Tools are open. Techniques are open. Be creative.

The lab brief lists one defensible path through a five-hour incident response. It is not the path — it is a path, chosen because it teaches the underlying principles cleanly with a small toolset that fits on a USB key. You are explicitly encouraged to:

★

The grade is on the discipline of the response

What we measure is whether you preserved before you investigated, whether you climbed the volatility pyramid in the right order, whether you hashed and logged contemporaneously, whether your report is a document a regulator could read. The specific binary you used to capture RAM is — to a first approximation — irrelevant.

References

Standards bodies, regulators, tools — every link is a starting point, not a ceiling

Standards bodies and frameworks

Regulators and legal frameworks

Tooling — open-source, freely substitutable

Spanish national authorities

Cyber.SoHo Educational Hub

Disclaimer · read in full

Educational use only · authorisation, proportionality, accountability — always

1 · Educational scope & lab boundary

This material is delivered as part of a university-level Incident Management course at Schiller International University through Cyber.SoHo Educational Hub. Every technique described above is taught for the academic objective of preparing students to defend networks and respond to incidents inside their own employer or client engagement, with explicit written authorisation. The procedures must stay strictly inside virtual machines you own and control, on hardware you own. Anything outside that boundary is outside this course's scope.

2 · Instructor protection — no liability for misuse

The instructor and Cyber.SoHo Educational Hub provide this lab in good faith for educational purposes only. Neither the instructor nor Cyber.SoHo Educational Hub accepts liability — civil, criminal, contractual, professional, or reputational — for any use of the techniques described herein outside the authorised lab boundary defined above. Students who deviate from that boundary do so on their own initiative, against the explicit written instruction of the instructor, and bear sole legal and professional responsibility for the consequences.

3 · Open tools, open techniques

Every tool, library, command, framework, and standard cited above is suggested as one defensible path. Students are explicitly encouraged to substitute any of them with open-source alternatives, with their own scripts in any language, or with techniques drawn from their own research. The lab grades the discipline of the response, not loyalty to a particular utility. Students are encouraged to research thoroughly, cross-reference primary sources, and to build their own tools when no off-the-shelf option fits.

4 · Intellectual property & plagiarism

All original lecture text, lab instructions, code, diagrams, and reference tables in this course are the intellectual property of Cyber.SoHo Educational Hub, prepared by the instructor for educational use within affiliated programmes of Schiller International University. Submitted student reports must be each student's own work; the academic-integrity policy of the University applies in full. Students are responsible for citing every external source — text, image, diagram, code snippet — and for using only properly licensed third-party material as defined in Part C.5 above. Failure to attribute is plagiarism and is sanctioned at the institutional level.

5 · No vendor or organisation affiliation

This lab references organisations, regulators, vendors, standards bodies, and software projects for educational illustration. Cyber.SoHo Educational Hub has no affiliation, sponsorship, partnership, or endorsement relationship with any of them. References are factual; trademarks are the property of their respective owners.

6 · Verify before you click

Submit any external URL — including the ones in this lab brief — to VirusTotal before clicking, especially when the link arrives via email, chat, or any forwarded medium. The Cyber.SoHo Educational Hub copyright disclaimer states that even reputable channels can have descriptions edited if an account is compromised. The URL check costs ten seconds and prevents weeks of incident response.

7 · Legal frameworks that apply outside the lab

Use of these techniques against systems you do not own — or do not have explicit, written authorisation to test — is illegal under several instruments simultaneously, including the Spanish Código Penal (Articles 197 and 264), the European Union NIS 2 Directive, the Budapest Convention on Cybercrime, the U.S. Computer Fraud and Abuse Act, and the U.K. Computer Misuse Act 1990. Penalties include imprisonment, fines, civil damages, and loss of professional certifications. Authorisation, proportionality, accountability — always.

8 · Fictional scenario disclaimer

The "NorthBridge Health Cooperative" scenario, the user "Anna", the case identifier CASE-NBH-2026-04-28-001, and any IP addresses, hostnames, or filenames in this brief are fictional. Any resemblance to a real organisation, individual, ransomware family, or attack campaign is coincidental and unintentional.

From the Industry to the Classroom — Building the IT's Future, Today and Together!