DFIR – Page 5 – Baker Street Forensics

CyberPipe-Timeliner: From Collection to Timeline in One Script

You know how these things go. A colleague asks a simple question, and before you know it, you’re knee-deep in PowerShell creating something that didn’t exist a few weeks ago. That’s exactly how CyberPipe-Timeliner came to be.

After a recent update to CyberPipe, someone asked whether there was a way to pipe Magnet Response collections through to something like ForensicTimeliner. It was one of those “that should exist” moments. So I made it exist.

A Quick History Lesson

For those who haven’t been following along, CyberPipe (formerly CSIRT-Collect) has been around since my IR days. It went public in 2021 and has been steadily maintained and updated since then. The tool has proven itself useful for rapid incident response collection, and it’s evolved based on real-world needs and feedback from the community.

CyberPipe-Timeliner is its companion project—taking that collection data and turning it into something immediately actionable: a unified forensic timeline.

What It Actually Does

The script automates the entire workflow from collection to timeline:

Extraction – It unpacks your Magnet Response archive, whether that’s a ZIP file or an already-extracted directory.

Processing – All the heavy lifting happens here using Eric Zimmerman’s EZ Tools to generate CSVs from your artifacts.

Organization – The CSVs get structured specifically for ForensicTimeliner compatibility, because nobody wants to spend time wrestling with file formats.

Aggregation – Everything merges into a consolidated timeline, giving you that unified view we’re all after.

Built for Real-World Use

The script includes some practical features that came from actual use cases:

Date filtering – Need to focus on a specific incident window? Use -StartDate and -EndDate to narrow your timeline to what matters.
Flexible input – Point it at a ZIP file or an already-extracted collection folder. Either works.
Verbose and diagnostic modes – Because sometimes you need to see exactly what’s happening under the hood.
Auto-generated output folders – Timestamped folders keep your timelines organized without any extra effort.

Getting Started

Setting it up is straightforward. You’ll need PowerShell 7+, Eric Zimmerman’s EZ Tools, ForensicTimeliner, and Microsoft .NET SDK (v9 recommended). The GitHub repository has detailed setup instructions, including handy one-liners for downloading and configuring the required tools.

Once you’re set up, a basic run looks like this:

.\CyberPipe-Timeliner.ps1 -InputFile "collection.zip"

That’s it. The script handles the rest, creating a timestamped output folder with your complete timeline.

Why It Matters

Forensic timeline generation shouldn’t be a multi-tool, multi-step headache. CyberPipe-Timeliner takes what would normally be several manual processes and condenses them into a single automated pipeline. You collect with Magnet Response or CyberPipe, run the timeliner script, and get actionable timeline data.

It’s available now on GitHub, and as always, feedback and contributions are welcome. If you run into issues or have ideas for improvements, open an issue or reach out.

Sometimes the best tools come from simple questions and the willingness to build the answer.

CyberPipe v5.3: Enhanced PowerShell Compatibility and Reliability

DFIR, Forensics, PowerShell, RAM, Triage, USB, Windows

I’m pleased to announce the release of CyberPipe v5.3, bringing critical compatibility improvements for Windows PowerShell 5.1 and enhanced reliability across all PowerShell environments.

The Problem

After releasing v5.2 with the new unified banner design, several users reported an interesting issue: CyberPipe would execute perfectly in PowerShell Core, but in Windows PowerShell 5.1, the script would complete the Magnet Response collection successfully—then immediately fail with an exit code error and stop before running EDD and BitLocker key recovery.

The collected artifacts were there. The output looked successful. But the script refused to continue.

The Root Cause

This turned out to be a known quirk in Windows PowerShell 5.1: the $process.ExitCode property isn’t always reliably populated after calling WaitForExit() on a process object. Even when Magnet Response completed successfully with exit code 0, PowerShell 5.1 would sometimes report a non-zero value, causing CyberPipe to think the collection had failed.

The Solution

Version 5.3 introduces dual validation logic that checks both the exit code and verifies that files were actually collected. If Magnet Response reports a non-zero exit code but artifacts were successfully collected, CyberPipe recognizes this as a PS 5.1 reporting issue and continues the workflow with a warning message.

The script now validates success based on what actually matters: did we collect the evidence?

Bonus: Adaptive Banners

While fixing the PS 5.1 compatibility, I also enhanced the banner display:

PowerShell Core: Displays the full Unicode box-drawing banner with visual flair
Windows PowerShell 5.1: Shows a clean ASCII banner optimized for automation, EDR deployment, and environments where Unicode rendering may be inconsistent

The script automatically detects which PowerShell edition is running and adjusts accordingly.

Testing & Validation

CyberPipe v5.3 has been tested and verified on:

✅ Windows PowerShell 5.1
✅ PowerShell Core 7.x
✅ All collection profiles (Volatile, RAMOnly, RAMPage, RAMSystem, QuickTriage, Full)

The script now executes flawlessly in both environments with no workflow interruptions.

Compatibility Notes

This is a drop-in replacement for v5.2 with no breaking changes:

All command-line parameters work identically
Existing automation scripts require no modifications
All collection profiles function as before

Why This Matters

For incident response work, reliability is non-negotiable. When you’re collecting evidence from a potentially compromised system, you need tools that work consistently across different Windows environments—corporate workstations running PS 5.1, modern systems with PS Core, virtual machines, and physical hardware.

CyberPipe v5.3 ensures that whether you’re running an interactive collection or deploying via EDR automation, the script executes reliably from start to finish.

Get CyberPipe v5.3

Download: CyberPipe v5.3 on GitHub

Documentation: GitHub Repository

As always, feedback and issue reports are welcome on the GitHub repository.

CyberPipe is a free, open-source incident response collection tool for Windows systems, automating memory capture, triage collection, encrypted disk detection, and BitLocker key recovery.

Streamline Digital Evidence Collection with CyberPipe 5.2

DFIR, Forensic Imaging, Forensics, PowerShell, Triage, USB

I first wrote CyberPipe when I was on the front lines of incident response, driven by the need for more robust and efficient triage collections, whether online or off. Over the years, CyberPipe continues to adapt and improve, addressing the ever-changing challenges faced by incident response practitioners.

CyberPipe (formerly CSIRT-Collect) is a PowerShell script that is designed to streamline the collection of digital evidence using Magnet Response in enterprise environments, ensuring that responders can gather critical data efficiently and effectively. Other features include detection of encrypted drives, BitLocker key recovery, and memory image collection.

The most recent update includes enhancements in three areas: Collection, Capabilities, and Reliability.

🔍 What’s New in 5.2

Intelligent Collection

The script now includes dual disk space validation, checking both the target drive and the system drive with profile-aware thresholds to prevent sudden failures due to insufficient space.
A pre-collection volatile snapshot captures uptime, users, connections, and processes to preserve transient state before heavy operations begin.
Reports virtual environment detection (VMware, Hyper-V, VirtualBox, etc.) to help analysts understand collection limitations.
Real-time progress indicators provide accurate size tracking during the collection, offering responders visibility into the remaining data capture.

Enhanced Capabilities

The new QuickTriage profile allows for rapid collection of volatile and system artifacts when time is ticking.
BitLocker recovery now includes all volumes, not just the C: drive.
A single-file report (CyberPipe-Report.txt) consolidates metadata and a summary of collected artifacts in a human-readable format.
All collected artifacts and logs are hashed using SHA-256 to enhance integrity and chain of custody.
Output compression is available via the -Compress flag, aiding in storage and transfer.
Network collection is simplified with the -Net parameter, eliminating the need for manual network path or configuration edits.

Improved Reliability

Profile-aware space checks alert when free space is insufficient for a chosen profile, preventing silent failures.
The script now validates exit codes from MAGNET Response to detect failures more effectively.
Artifact verification after collection ensures that all expected items were gathered.
Error handling and messaging have been refined to provide clearer feedback to the operator.

What I’m hoping this delivers

CyberPipe 5.2 aims to address some challenges observed in real-world triage and live-response operations:

Resilience in constrained environments — dual drive checks and profile awareness help prevent mid-collection failures.
Better transparency and oversight — real-time progress display and post-collection verification enhance confidence.
Faster response options — the QuickTriage profile is suitable when speed is paramount.
Stronger forensic hygiene — SHA-256 hashing, improved error detection, and full-volume BitLocker key recovery contribute to defensibility.
Easier network deployments — built-in ‘-Net‘ support facilitates smoother remote collection.

As always, CyberPipe is freely available at https://github.com/dwmetz/CyberPipe. Forks and Contributions welcome and appreciated.

Is there a feature you’d like to see? I think next I might work on support for copying output to AWS/Azure. Thoughts?

Is your USB device slowing down your forensic investigation?

DFIR, Forensic Imaging, Rust, USB

In digital forensics and incident response, reliable storage isn’t a luxury — it’s a requirement. Whether you’re capturing evidence from a live system, processing large data sets with specialized tools, or running a virtual machine in the middle of a case, storage throughput can make or break your workflow.

The challenge? Reported specifications from manufacturers often don’t tell the full story. A drive rated for up to 400 MB/s might only deliver a fraction of that in real-world use. And performance isn’t determined by the drive alone: the quality of your USB cable, the number of hops between your system and the media (direct vs. through a hub), and the system’s own caching behaviors all play a part.

To eliminate the guesswork, I built Crabwise, a simple USB benchmarking utility designed with forensic workflows in mind.

How Crabwise Works

Crabwise calculates read and write speeds by creating a temporary file on the target device and measuring throughput under direct (uncached) conditions.

Write Test: The tool writes a pseudo-random 1 GiB file (size adjustable) to the USB drive in blocks, ensuring that system caching doesn’t skew results.
Read Test: It then reads the file back from the device, again bypassing caches, so the reported numbers reflect device-level throughput rather than RAM speeds.
Progress Feedback: While testing, Crabwise shows real-time percentages and MB/s estimates, so you can spot performance bottlenecks as they happen.

The result is a clean, standardized benchmark of the USB device’s true performance.

Building a Reference Table

One of the most useful features in Crabwise comes after the test: you’re prompted to save the results to the root of the device. If you choose to do so, Crabwise appends the results to a simple log file called crabwise.log.

Each entry includes:

Session name (you provide this — e.g., “coil cable via hub” or “direct to Mac”),
Read speed,
Write speed,
Timestamp of the test.

When you cat the file, you get an instant side-by-side comparison of your runs:

=== crabwise.log ===
coil cable, usb-c hub          |  293.87 Mbps |  295.97 Mbps | 2025-08-27 11:27:09
dual 90 deg cable, usb-c hub   |  293.77 Mbps |  298.57 Mbps | 2025-08-27 11:29:11
dual 90 cable, to mac          |  327.16 Mbps |  331.88 Mbps | 2025-08-27 11:31:02
coil cable, to mac             |  324.74 Mbps |  330.94 Mbps | 2025-08-27 11:32:53

Over time, this builds into a practical reference table that lets you quickly compare how different cables, hubs, and ports affect performance. What looks like a subtle cabling change can sometimes mean the difference between a VM booting smoothly or crawling.

Closing Thoughts

In forensic and investigative work, you don’t always get to choose the hardware you’re handed — but you can make informed decisions about how you connect and use it. Tools like Crabwise give you a way to validate your environment, document your results, and avoid unpleasant surprises when timing matters most.

Whether you’re testing cables, validating a new hub, or verifying a forensic workstation setup, Crabwise turns USB benchmarking into a repeatable, documented process.

Download crabwise from GitHub: https://github.com/dwmetz/crabwise/