Choose your install route
Read this before starting
Checked 2026-11-09. These steps have not been executed on a clean Ubuntu VM or Windows host here. The synthetic sample is not yet supplied, so no route has a claimed passing end-to-end smoke test. Expected outputs below describe acceptance checks, not observed test results.
Upstream does not publish a reliable total duration. No totalTime is asserted in the structured data. Keep installation logs and stop if a prerequisite, verification check or installation state fails. Read the installer verification guidance before executing a downloaded package.
System requirements
- Operating system
- Ubuntu 22.04 or 24.04 according to the checked recipe README. This guide selects 24.04; it does not assume newer Ubuntu releases are supported.
- CPU
- amd64 or arm64. The checked recipe README does not specify minimum cores or clock speed. Some tools are amd64-only.
- RAM
- No minimum RAM figure is specified in the checked recipe README.
- System disk
- No minimum free-space figure is specified in the checked recipe README. Forensic images, working copies, Plaso storage files and CSV exports need their own additional space.
- Virtualization
- Native Ubuntu needs no hypervisor. WSL 2 requires hardware virtualization and the Windows virtualization features enabled by its installer. Firmware controls vary by vendor. Appliance guest sizing and compatible VMware or VirtualBox versions await the approved image.
Use a normal administrator-capable account and a reliable connection. Ensure the system clock is correct before checking signatures. Do not disable signature verification or security controls merely to get an install to finish. The workstation is for analysis; it does not automatically make evidence handling read-only or defensible.
Virtual appliance: deferred
No DFIR.com image is available. This is the release-gated procedure, not an executable installation route. Do not obtain an unverified image to work around that restriction.
Checked 2026-11-09 · Recipe README revision · Install modes · Cast release assets · Cast package instructions
1. Wait for the verified image
This route stays closed until Rob approves his own build and publishes its hash and signature. There is no image download, default password or release-specific hardware specification to use today. Source installation below is the available route. An appliance advertised elsewhere is not necessarily the build covered by this guide.
2. Verify and import
After release, verify the image and its signature before selecting the hypervisor's import-appliance function. VMware and VirtualBox compatibility, import options and screenshots must be tested against that exact image before this step is activated. Do not treat a generic import walkthrough as proof that an unpublished appliance will boot.
3. First boot and password change
Use only the credentials documented for the approved image, then change the password immediately. Default credentials have deliberately not been copied from old appliances or cloud images. A password-change command and its expected prompts will be added with the release-specific instructions; no password is guessed here.
4. Smoke test and snapshot
After first boot, perform the same smoke test used for native Ubuntu and WSL below. Only after it passes should you shut down the guest and create a clean baseline snapshot in the hypervisor. A snapshot is a recovery point, not a forensic evidence backup or a substitute for preserving source media.
Native Ubuntu with Cast
Use a fresh Ubuntu 24.04 system for this documented path. The checked recipe README lists Ubuntu 22.04 and 24.04 with amd64 and arm64 support. These instructions have been source-reviewed, not executed on a clean VM.
Checked 2026-11-09 · Recipe README revision · Install modes · Cast release assets · Cast package instructions
1. Prepare a disposable system
Sign in as your normal Ubuntu user with sudo privileges, not a persistent root shell. Back up anything valuable before installation. Cast applies Salt states that add repositories, install and update packages, create tool environments and configure the workstation. The default recipe mode is desktop. This is a system-changing installation, not an isolated application. Never run it on a machine containing original evidence.
2. Get the matching Cast package
Open the official Cast v1.0.42 release linked below in the browser. In Assets, save cast-v1.0.42-linux-amd64.deb for Intel or AMD Ubuntu, or cast-v1.0.42-linux-arm64.deb for ARM. Do not use a macOS archive. Save the release's checksums.txt and signature material too. Follow the verification page before running the package. If authenticity cannot be established, stop instead of bypassing verification. Open Ubuntu Files, open Downloads, and choose Open in Terminal so the package filename resolves in the next step.
3. Install Cast
The command below is for the amd64 package in your current directory. On ARM, replace only the package filename with the arm64 filename shown above. If your browser added a suffix to a duplicate download, resolve that filename before running the command; do not use a wildcard that might install a different package.
sudo dpkg -i cast-v1.0.42-linux-amd64.debChecked 2026-11-09 · Upstream source
The dpkg -i syntax comes from the linked Cast README; the filename is the exact amd64 asset from this release. Use the arm64 asset instead on ARM.
Expected output: dpkg reports unpacking and setting up cast without an error. A password prompt is normal; Linux does not echo password characters. Do not continue after a dependency or architecture error.
4. Install the SIFT recipe
Keep the terminal open and allow the installer to finish. It downloads tools and their dependencies, so duration depends on the network, processor and package mirrors. Upstream publishes no guaranteed total installation time; do not interpret a quiet terminal as a successful or failed install without checking its output. A reported failed state means the install has not passed.
sudo cast install teamdfir/sift-saltstackChecked 2026-11-09 · Upstream source
Expected output: Cast checks operating-system support, downloads the recipe and runs Salt. Successful runs report salt-call completed successfully. Stop on FATA, failed states, or a nonzero exit; elapsed time and package counts vary by release.
5. Run the shared smoke test
Use the common smoke-test section below from a new terminal under the same user account. Save the version output with your installation notes. Passing a version command establishes that a program starts, not that all its forensic functions are correct. The synthetic-image stage remains blocked until the author supplies the published sample and reference row count.
WSL with Cast in server mode
Use WSL 2 with an explicitly supported Ubuntu release. Run Windows commands in Administrator PowerShell and Linux commands inside Ubuntu. Do not paste the entire page into one terminal.
Checked 2026-11-09 · Recipe README revision · Install modes · Cast release assets · Cast package instructions
1. Check available distributions
Enable hardware virtualization in your computer's firmware if it is disabled. Open PowerShell with Run as administrator. Confirm that the named Ubuntu distribution is offered before installing it. Microsoft's WSL documentation, rather than the SIFT README, is the source for the Windows commands.
wsl.exe --list --onlineChecked 2026-11-09 · Upstream source
Expected output: A table of available distributions. Confirm Ubuntu-24.04 is listed. If the command is unavailable, update Windows or follow Microsoft's supported WSL setup instructions before proceeding.
2. Install Ubuntu for WSL
This is Microsoft's documented install syntax with the Ubuntu-24.04 distribution selected to match the current SIFT recipe. Restart Windows if prompted. Open the newly installed Ubuntu application, wait for initial setup, and create your own Linux username and password. This password belongs to Ubuntu; it is not your Windows password.
wsl --install -d Ubuntu-24.04Checked 2026-11-09 · Upstream source
Expected output: Windows installs the requested distribution and may request a restart. On first launch Ubuntu asks for a new UNIX username and password. Existing installations may instead report that the distribution is already installed.
3. Check WSL version
Run this in PowerShell after setup, not in the Ubuntu terminal. The selected distribution must use WSL 2 for this route. New distributions installed with the documented install command default to WSL 2. If yours reports 1, stop and follow Microsoft's conversion guidance; conversion can change storage and needs a backup.
wsl.exe --list --verboseChecked 2026-11-09 · Upstream source
Expected output: Ubuntu-24.04 appears with VERSION 2. The state may be Running or Stopped; that alone is not an error.
4. Install Cast inside Ubuntu
In the Ubuntu environment, follow native steps 2 and 3 above to download, verify and install the architecture-matched Cast .deb. Place the package in the Ubuntu directory where you open the terminal. A Windows Downloads folder and an Ubuntu Downloads folder are not interchangeable paths. The command below assumes the verified amd64 package is in the current Linux directory.
sudo dpkg -i cast-v1.0.42-linux-amd64.debChecked 2026-11-09 · Upstream source
The dpkg -i syntax comes from the linked Cast README; the filename is the exact amd64 asset from this release. Use the arm64 asset instead on ARM.
Expected output: dpkg reports unpacking and setting up cast without an error. A password prompt is normal; Linux does not echo password characters. Do not continue after a dependency or architecture error.
5. Install the server-mode recipe
Run this from your regular Ubuntu account using sudo. Server mode installs the command-line workstation rather than the desktop configuration. Use this mode rather than replaying the deprecated packages-only command in the 2018 account. Do not assume WSL has the same direct disk, USB or image-mounting capabilities as a native Ubuntu workstation.
sudo cast install --mode=server teamdfir/sift-saltstackChecked 2026-11-09 · Upstream source
The README documents the server-mode flag; the pinned manifest defines server as sift.server.
Expected output: Cast runs the server recipe and ends with salt-call completed successfully. Any failed state is a failure, even if some tools were installed successfully.
6. Run the same smoke test
Use the shared commands below inside Ubuntu, not PowerShell. Work on synthetic test data in the Linux filesystem for this test. Keep original evidence protected and plan storage separately. WSL results do not establish equivalent physical-device access or validate mounting methods for casework.
What changed since the WSL accounts?
Adam Harrison, January 23, 2018 (Q07) used the older SIFT CLI, packages-only mode and the original WSL environment. The account also describes FUSE image-mounting problems and an external X server. Today the recipe uses Cast, its server mode replaces packages-only, and new Microsoft installations default to WSL 2. That does not prove every mounting workflow from the earlier article now works. Test the specific workflow separately; this guide does not instruct you to modify or mount original evidence.
Baker Street Forensics, June 3, 2024 (Q21) used Ubuntu 22.04, Cast v0.14.30 and server mode, then checked vol.py. This guide checks the current recipe support, selects Ubuntu 24.04, records Cast v1.0.42 and checks the vol entry point installed by the current Volatility 3 state. Server mode remains appropriate for this command-line path. Neither historical success is represented as a test run of today's versions.
Shared smoke test for every route
Use these same checks after native Ubuntu or WSL installation, and after an approved appliance becomes available. Run each command separately in the Linux terminal. Keep its output with the Ubuntu release, architecture, Cast version, recipe release and test date. Version differences are not automatically failures, but they must be recorded rather than silently normalized.
1. Check Cast
cast --versionChecked 2026-11-09 · Upstream source
Expected output: Cast prints its version. For the pinned package above, the version identifies 1.0.42. Record the actual string; do not replace it with this description.
2. Check Plaso
log2timeline.py --versionChecked 2026-11-09 · Upstream source
Expected output: Plaso prints its installed version without a Python traceback or missing dependency error. The recipe can update packages, so no exact Plaso version is promised here.
3. Check Volatility
vol --help | headChecked 2026-11-09 · Upstream source
The pinned SIFT state installs the vol entry point. The help preview requested for this smoke test is not an installation command.
Expected output: The first lines identify Volatility 3 and show usage options. A command-not-found message fails the check. Because a shell pipeline can conceal the first command's exit status, inspect the output, not just the pipeline's return code.
4. Process the synthetic sample: blocked
Reserved sample path: /sift/samples/smoke.E01. The sample must be generated by Rob or an author and must not exceed 20 MB. It is not published and this text is not a download link. No real case evidence should be substituted. The author must supply its provenance, checksum, filesystem details and known expected events before the test can be reproducible.
Once supplied, save the verified sample in a new working directory and open a terminal there. Use a fresh directory for every run so old output cannot be mistaken for new results. The commands below are a documented test template, not a currently runnable sample test. The sample's partitions and parser selection must be confirmed during the first author-run test.
log2timeline.py --storage-file smoke.plaso smoke.E01Checked 2026-11-09 · Upstream source
Upstream usage with the reserved synthetic sample and output filenames substituted. Do not run until the sample is published.
Expected output: Processing completes and creates smoke.plaso without source or dependency errors. The expected event count is pending the actual sample and author-run reference test.
psort.py -o l2tcsv -w smoke.csv smoke.plasoChecked 2026-11-09 · Upstream source
Upstream CSV export syntax with the smoke-test filenames substituted.
Expected output: Creates smoke.csv in the current directory. The reference CSV data-row count is not known until the sample exists; a file merely existing does not pass the test.
Pass criterion pending: compare parsed CSV data rows, excluding the header, against an author-recorded reference count for the specified sample and Plaso version. A simple line count can be wrong for quoted multiline fields. No expected row count is invented here. Until that reference exists, record the sample stage as blocked, not passed.
Troubleshooting from upstream reports
These are five documented failure cases, not a statistically ranked list of the most common problems. Checked 2026-11-09. Fix status is attributed to the issue discussion; it is not a clean-machine reproduction by DFIR.com.
Ubuntu 22.04 dependency conflicts
The tracker documents Noble repositories being mixed into a Jammy system. Maintainers reported a fix in the latest release. Use the current recipe on a fresh supported system; do not force incompatible packages or manually downgrade an existing machine. Preserve the failed-state output if the problem recurs.
Upstream issue #677An old Salt download host no longer resolves
Older Cast/Salt paths failed when fetching the Salt single-binary archive. Maintainers state that the Salt update and Ubuntu 24.04 support resolved the old path. Update Cast from its official release and use the current recipe. Do not replace a failed download with an unsigned file from a random mirror.
Upstream issue #662WSL exits with a Salt ValueError
A WSL report shows salt-call failing with 'need more than 1 value to unpack'. The maintainer requested testing the new release, but the issue does not establish that every WSL configuration is fixed. Retry only on a disposable supported system with current Cast; report a recurrence with the log paths printed by Cast. Do not call the run successful.
Upstream issue #657Volatility is missing
The tracker records Volatility being disabled in the default install and subsequently restored in a newer release. Use the current recipe, then repeat the vol help check. Do not silently substitute the old vol.py tool: Volatility 2 and 3 are different. If the current install still lacks vol, retain the failed-state log and report it.
Upstream issue #672A Cast release has no .deb asset
Maintainers directed this packaging problem to the Cast tracker. The v1.0.42 release checked for this guide does contain amd64 and arm64 .deb assets. Use the verified release assets, not a guessed URL. If a later release lacks them, report it to Cast rather than fabricating an installation command.
Upstream issue #681
When reporting a failure, include the route, OS release, CPU architecture, exact command, versions and failed-state names. Redact usernames, personal paths, tokens and case material from logs. Keep the unmodified log privately for diagnosis. Do not repeatedly rerun privileged installs on a valuable system while guessing at fixes; reproduce on a disposable system first.
Last reviewed