# SnapshOT | An Open-Source ICS/OT Incident Response Operating System > SnapshOT is our open-source Debian 13 operating system for ICS/OT incident response: offline, reproducible, quiet on the wire, with read-only triage collectors. Canonical: https://blackbirdcyber.com/resources/snapshot Blackbird Cyber · https://blackbirdcyber.com/ · sales@blackbirdcyber.com Article · 13 min · Matthew McManus · Published Oct 11, 2026 Tags: Incident response, OT forensics, ICS security, Open source, Field triage, Chain of custody, Debian ## The laptop is part of the incident When something goes wrong on a control network, someone has to walk a laptop onto it. That laptop is usually a general-purpose machine: a corporate build, a penetration-testing distribution, or a vendor's engineering laptop that was on another site last week. Once its cable is plugged in, it starts talking. It announces itself over mDNS and LLMNR, asks for the time, checks for internet, looks for updates and, with Wi-Fi on, sends probe requests for every network it remembers. On an office LAN that is background noise. On a control segment it is unexpected traffic on a network that should be predictable. It lands in the capture the team needs to read, and to the site's monitoring it looks like an intruder's discovery. Then there is what the laptop carries: tools downloaded the morning of the job at versions nobody wrote down, evidence from the previous client still on the disk, a browser that phones home, a collector script that might install something, start a service or open a serial port and reset the equipment behind it. None of this is malicious. All of it is risk the plant did not agree to take. We built SnapshOT because availability is the first control. The responder's own equipment should never be the thing that disturbs the process. ## What SnapshOT is SnapshOT is a Debian 13 (trixie) live image for incident response and assessment on OT and ICS networks. It boots from a USB stick or in a VM to an Xfce desktop of OT tools, documents each tool in an offline wiki, and installs to an encrypted disk with no network. It is built the way Kali is built, with Debian's `live-build`, from one fixed snapshot of the Debian archive. *[Image: The SnapshOT Xfce desktop with the Whisker menu open on 01 - Recon & Discovery, listing arp-scan, fping, mDNS listen (passive), nbtscan, netdiscover, nmap, nmap ICS scripts and p0f, over a dark wallpaper with the SnapshOT lockup.]* *The SnapshOT desktop, with the tools menu open on 01 Recon & Discovery.* Two images come from the same tree and the same pin: - **amd64** for x86-64 laptops, desktops and VMs, booting on BIOS or UEFI. - **arm64** for arm64 VMs on Apple Silicon (UTM, Parallels, VMware Fusion) and UEFI arm64 hardware. It boots on UEFI only and does not boot an Apple Silicon Mac directly. The current release is **[v0.3.0-alpha](https://github.com/Blackbird-Cyber/SnapshOT/releases/tag/v0.3.0-alpha)**, the first public release. It is pinned to snapshot.debian.org `20260901T022952Z`, the first trixie snapshot of September 2026. SnapshOT's code, configuration and packaging are under the Apache License 2.0, and its documentation and wiki under CC BY 4.0. Debian packages and third-party tools keep their own licenses. ## Five design decisions ### Offline and reproducible Every apt source in the build points at one snapshot.debian.org timestamp, and every file is stamped with the matching `SOURCE_DATE_EPOCH`, so two builds of a release resolve the same packages. Each image records its version, architecture, pin and build commit in `/etc/snapshot-release`, and every package and vendored tool in `/usr/share/snapshot/reference/BUILD-MANIFEST.txt`. The installer copies the live system to disk and needs no network at any point. An air-gapped site is the wrong place to find out a tool is missing, and a finding is only as defensible as the toolchain that produced it. With the manifest on the image, a report can name the exact version of the tool that read a register or decoded a capture. ### Quiet on the wire Nothing on the image sends traffic until the operator brings an interface up: - avahi and `systemd-timesyncd` are masked, and ModemManager is not installed. - LLMNR and multicast DNS are off, and so are IPv6 autoconfiguration and router advertisements. - NetworkManager creates no automatic wired profile and runs no connectivity check. - Firefox ESR runs under a policy that turns off telemetry, updates, DNS over HTTPS, captive-portal checks, prefetching and Safe Browsing, and its Remote Settings hosts resolve to loopback. A build check runs it on the wiki for 45 seconds and fails on any packet. - The Wi-Fi client ships with its radio switched off, live and installed, so the laptop sends no probe requests at a site. Turning it on is a deliberate click, and probes then use a random MAC address. - The radio tools only receive. RTL-SDR and gqrx listen, and airodump-ng is the only 802.11 tool on the menu. The first hour on site is when the team most needs a clean passive capture, and it is the hour a chatty laptop does the most damage to it. > The safest action on a control network is to listen. SnapshOT starts there and makes every step past it a deliberate one. ### Documented for OT response Every tool has a page in the SnapshOT Wiki, an offline site on the image, that says what the tool does on the wire and where it fits in the response. Incident response on a plant floor is done by people who know the process, not only by people who know the tools. A responder who has not used `mbpoll` in a year should see, before pressing Enter, that it can write to a controller and that the rules require the engineer to be present. ### A field triage kit SnapshOT prepares a USB stick of read-only collectors for Windows XP to 11 and Linux hosts. Its results come back into a case folder with hash checks and a chain-of-custody log. The hosts that supervise a process are often old, often unpatched and rarely allowed to change, so a collector that installs an agent or starts a service is not acceptable on them. ### One client per image The installer puts the root filesystem in LUKS2, and the laptop is wiped and re-imaged between engagements. An engineering laptop that moves from utility to utility carries one client's network details, credentials and evidence into the next site. Re-imaging makes "nothing from the last job" part of the procedure. ## What is on the image The tools sit in eight numbered menu folders, in the order of an engagement: | Folder | Tools | |---|---| | 01 Recon & Discovery | nmap with its ICS scripts, Redpoint NSE, netdiscover, arp-scan, p0f, fping, nbtscan, a passive mDNS listener | | 02 Traffic Analysis | Wireshark, tshark, termshark, tcpdump, tcpflow, tcpreplay, Suricata, Scapy | | 03 Protocol Tools | mbpoll; pymodbus, pycomm3, BACpypes3, BAC0, asyncua and python-snap7 in an ICS Python shell; OPC UA command-line tools; opcua-client (amd64 only); plcscan | | 04 Firmware & Hardware | binwalk, flashrom, OpenOCD, sigrok-cli, PulseView, sdcc, minicom, picocom, tio, screen, QEMU | | 05 Wireless & SDR | airodump-ng, rtl-sdr, gqrx (receive only) | | 06 Host Forensics | the SnapshOT field triage kit, The Sleuth Kit, TestDisk/PhotoRec | | 07 Reporting & Documentation | LibreOffice, CherryTree, Flameshot, pandoc, KeePassXC, nwipe | | 08 Reference | offline reference folder, the build manifest, the SnapshOT Wiki | The protocol folder covers Modbus, S7comm, EtherNet/IP, OPC UA and BACnet. Wireshark, tshark and termshark capture without `sudo`, because the operator's account is in group `wireshark`. Tools Debian does not package live in a vendor layer. Each is installed under `/opt/snapshot//` with its own runtime (a pinned CPython for the ICS Python libraries), from hash-pinned, wheels-only installs, and reached through wrappers in `/opt/snapshot/bin`. That directory is appended to `PATH`, so the operating system's own commands always win. Each vendored tool records its source, SHA-256 and license in a manifest that feeds the build manifest. ## The SnapshOT Wiki The wiki is built with MkDocs Material and opens in Firefox ESR from `file://`. Nothing in it loads from the network: search, tags and the interactive graphs all work offline. *[Image: The SnapshOT Wiki home page in a dark theme, with a platform guide in the left sidebar and cards for Lifecycle, Tools, Rules of engagement, Playbooks, Protocols and Platform.]* *The SnapshOT Wiki home page, opened offline in Firefox ESR on the image.* **Lifecycle** follows an engagement through the six SANS PICERL phases, each read for a plant floor, with the NIST CSF 2.0 functions and the MITRE ATT&CK for ICS tactics in play (all 12 tactics, from ATT&CK v19). A crosswalk maps the phases against CSF 2.0, NIST SP 800-61r3, NIST SP 800-82r3 and the SANS Five ICS Cybersecurity Critical Controls. This half also holds: - **Rules of engagement:** written authorization naming targets, actions, protocols, window and approver; the process owner's final say; an engineer present for anything that writes; one fragile host at a time, slowly; extra care for serial, JTAG and SPI work. - **Evidence handling:** one case folder per engagement, UTC timestamps, a running `SHA256SUMS` and an append-only chain-of-custody log. - **Playbooks:** passive baseline, active enumeration, protocol interrogation, firmware acquisition, wireless survey, incident response triage, and reporting and handover, each with go and no-go checks. **Tools** has a page per tool with fixed sections (on the wire, PICERL mapping, ATT&CK for ICS mapping, quick start, output and evidence) and protocol primers for Modbus, S7comm, EtherNet/IP, OPC UA, BACnet and DNP3. Every tool page carries a wire class: **Passive** never transmits, **Active** sends queries but only reads, **Writes** can change a device, its configuration or a disk. The build is strict. It validates every page's metadata against the data files, fails on broken links or anything loaded from the network, and checks that every launcher in the menu is documented by exactly one page. *[Image: The SnapshOT Wiki lifecycle graph: six numbered PICERL phase nodes linked to tool nodes colored by menu folder, including nmap, tshark, Wireshark, Suricata, flashrom, the SnapshOT field kit and The Sleuth Kit.]* *The lifecycle graph links each tool page to the PICERL phases it serves.* ## The field kit **Prepare.** `snapshot-fieldkit-prep` offers only USB, removable or hot-plug disks. It refuses the disk holding the SnapshOT boot medium, the disk holding the running system, a partition instead of a whole disk, and any non-removable disk, whatever the command line says. The operator types the device name and then `ERASE`. It writes an exFAT stick (FAT32 with `--fat32` for bare Windows XP hosts) with a `MANIFEST.sha256` over every kit file. **Collect.** On Windows, `collect-triage.cmd` starts the PowerShell 2.0-compatible collector when PowerShell exists and runs a built-in-only collection when it does not. If policy blocks PowerShell it says so and suggests the `cmd` path, but never falls back on its own, so a fragile host is never collected twice. On Linux, `collect-triage.sh` runs under any POSIX shell, BusyBox included. Every collector prints a banner with the expected duration and waits for Enter so the operator can abort. The `quick` profile takes 2 to 5 minutes on Windows; `full` takes 10 to 60 and is for hosts that can bear it. The collectors gather processes with hashes, network connections, services, drivers, scheduled tasks, autostart locations, local accounts and installed software. For OT they also list COM ports, OPC servers, ICS vendor software and ICS project files by extension (`.s7p`, `.acd`, `.stu` and others). Project files are listed, never copied. The safety rules are in the code and checked by the build: - No network, no installs, no services started or stopped, no registry or configuration writes, no log clearing. - Serial ports are never opened. Opening a port can toggle DTR and RTS and reset the equipment behind it. - Installed software is read from the registry, never from `Win32_Product`, which can trigger MSI repairs. - The known footprint, such as Prefetch entries and process-creation audit events, is logged for the report. **Import.** Back on the laptop, the import runs as the operator, never as root, and mounts the stick read-only: ```sh snapshot-fieldkit-import --case ACME-2026-10 --examiner "Jane Doe" ``` It checks each collection against the collector's manifest. A mismatch prints a **TAMPER** banner and that collection is not imported. Verified collections are copied into `~/cases//fieldkit/`, made read-only and hashed into an import manifest, and the append-only `chain-of-custody.log` records the UTC time, examiner, operator, the stick's identity and serial, and each collection's result. SnapshOT ships only its own scripts. Sysinternals and KAPE may not be redistributed, so operators add them to the stick themselves. ## An engagement, start to finish **Preparation.** Verify the image before it touches a laptop: ```sh sha256sum -c --ignore-missing SHA256SUMS # Linux, next to the downloaded ISO shasum -a 256 snapshot-amd64.hybrid.iso # macOS certutil -hashfile snapshot-amd64.hybrid.iso SHA256 # Windows ``` Install with **Erase disk** and **Encrypt system**, or run live. Agree the rules of engagement in writing, prepare the field kit stick, print the chain-of-custody form and create a KeePassXC database for the client's credentials. **Identification.** Start passive: a tshark capture on a SPAN port or TAP, p0f fingerprinting from observed traffic, Suricata run offline over the capture. Active tools such as nmap come second, one host at a time, inside an agreed window. On suspect HMIs and engineering workstations, run the quick field kit profile while the capture keeps running, then import and verify. The wiki's triage playbook pairs the two: a host reaching across zones in the capture and a matching process on that host is a strong finding. **Containment.** Take only actions the plan already authorized, with the process owner, and verify them from fresh captures on both sides of the boundary. Confirm safety, alarm and protection functions still respond. **Eradication and recovery.** Collect again from a cleaned host and compare it with the first collection. With the engineer present, read set points back with mbpoll and compare them with the known-good list before a controller returns to automatic, and compare a flash dump's hash with a known-good image. **Lessons learned.** Build a timeline with The Sleuth Kit, pull statistics from the case captures, and use the import manifests and custody log as the record of what was collected, when and by whom. Deeper disk analysis happens on a separate workstation, after the case folder is copied and verified against a transfer manifest. **Reset.** Wipe the client's media with nwipe once retention is agreed, wipe the laptop, and install a fresh image. A sample of tools, their wire class and the phases their wiki pages map them to: | Tool | Wire class | PICERL phases | |---|---|---| | tshark | Passive | Preparation, Identification, Containment, Recovery, Lessons Learned | | Suricata | Passive | Identification, Containment, Lessons Learned | | nmap | Active | Preparation, Identification, Containment, Recovery | | mbpoll | Writes | Identification, Eradication, Recovery | | flashrom | Writes | Eradication, Recovery | | SnapshOT field kit | Writes (preparing formats the stick) | Preparation, Identification, Eradication, Lessons Learned | | The Sleuth Kit | Passive | Identification, Eradication, Lessons Learned | | nwipe | Writes | Preparation, Lessons Learned | ## How it is built and verified SnapshOT builds on a Debian trixie host or, on macOS, inside the repository's Docker build container. The only online steps are fetching Debian packages from the pin and fetching the vendor layer, whose every artifact is checked against a SHA-256 in a lock file. The image build itself installs everything offline. The checks run in containers and fail on any error: - `check-installer.sh` validates the installer configuration and the Secure Boot bootloader wrapper. - `check-fieldkit.sh` greps the collectors for state-changing commands, runs the Linux collector and confirms nothing changed outside its results folder, exercises the prepare refusals, and tests import and TAMPER handling. A linter enforces PowerShell 2.0 compatibility. - `check-wiki.sh` builds the wiki twice and checks the builds are identical. - `check-firefox-quiet.sh` proves the browser sends nothing on its own. - `verify-repro.sh` builds the image twice from a clean state, compares the ISOs and runs diffoscope when they differ. CI runs `reuse lint` and the installer, desktop and wiki checks on every push and pull request. Each release publishes a `SHA256SUMS` covering both ISOs. The live image and amd64 installs boot with Secure Boot on through Microsoft-signed shim, with GRUB and the kernel signed by Debian; arm64 installs carry the same shim and signed GRUB but have not yet been booted with Secure Boot enforced. ## Limits, stated plainly - **Field kit manual QA is pending** on real USB sticks and Windows XP, 7 and 10. The collectors are tested in containers. - **It is an alpha.** Menus, scripts, file locations and the package selection may change between releases. Re-imaging is the way to move between them. - **Firefox gets no Remote Settings updates,** so no certificate revocation or blocklist updates. That is the cost of a browser that never calls home. - **No GUI forensics suite.** Autopsy was tried and removed; deeper analysis belongs on a separate workstation. Ghidra, Zeek and GRASSMARLIN have wiki pages marked not shipped, with alternatives. - **Platform gaps.** opcua-client is amd64 only. With Secure Boot on the kernel runs in lockdown, so flashrom's internal programmer (the laptop's own firmware) is blocked; external programmers work. On QEMU's arm64 `virt` machine, which UTM uses, the live boot shows no splash until the desktop appears. There is no hibernation. - **It is not a safety net.** Every tool on the image can disturb a control system. SnapshOT is for authorized OT engagements only, it comes with no warranty, and the decision to run a tool rests with the team and its written authorization. > A tool that says what it does on the wire before it says what it can do is a tool an operator can trust. ## Availability SnapshOT is public. [v0.3.0-alpha](https://github.com/Blackbird-Cyber/SnapshOT/releases/tag/v0.3.0-alpha) is the first public release: ISOs for amd64 and arm64 with a `SHA256SUMS` file, from the [releases page](https://github.com/Blackbird-Cyber/SnapshOT/releases). The source, build scripts and documentation are on [GitHub](https://github.com/Blackbird-Cyber/SnapshOT) under the Apache License 2.0, and the release notes cover writing the image to a USB stick or running it in a VM. We built it for OT security teams, plant and utility engineers, incident responders and the integrators who support them, and we want to hear how it behaves on your hardware and your networks. Report problems in [GitHub issues](https://github.com/Blackbird-Cyber/SnapshOT/issues), and vulnerabilities through private vulnerability reporting as [SECURITY.md](https://github.com/Blackbird-Cyber/SnapshOT/blob/main/SECURITY.md) describes. If you want help putting SnapshOT to work on an engagement, [talk to us](/contact).