PowerShell – Page 2 – Baker Street Forensics

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?

CyberPipe v5.1 – Streamlined Profiles, Better Flexibility

DFIR, Forensics, PowerShell, RAM, Triage, USB

CyberPipe v5.1 is out with a few targeted improvements to make live response a bit smoother.

What’s New:

Collection profiles can now be passed directly as arguments using -CollectionProfile. No need to modify the script or hardcode anything — just run with the profile you need.
Improved support for saving to network shares, ideal for remote collections triggered by EDR.
Better error handling and logging, including clearer messages when tools are missing or when BitLocker key recovery fails.

The default profile still covers the most common triage needs:

✔️ Memory dump (RAM)

✔️ Pagefile

✔️ Volatile data (network config, hives, running procs)

✔️ System artifacts

But now, you can swap that out on the fly:

Usage Examples:

.\CyberPipe.ps1 ## default profile, capture RAM, Pagefile, Volatile and System Files

.\CyberPipe.ps1 -CollectionProfile RAMOnly ## just the RAM

.\CyberPipe.ps1 -CollectionProfile RAMSystem ## just the RAM and System Files (triage lite)

.\CyberPipe.ps1 -CollectionProfile RAMPage ## RAM & Pagefile

.\CyberPipe.ps1 -CollectionProfile Volatile ## Just Volatile data

Useful for tailoring collections based on available time, scope, or system stability — especially during incident response where conditions change quickly.

CyberPipe still captures memory with DumpIt or RAM Capture, grabs volatile system data, checks for encryption, and recovers the BitLocker key when possible. But now it’s just a bit easier to tailor to the job at hand — whether you’re responding interactively or invoking it remotely via EDR integration.

As always, no dependencies beyond what’s in the Tools folder, and no assumptions about the system you’re collecting from.

See the full changelog and usage notes in the README on GitHub.

Exploring Magnet Virtual Summit 2025 CTF Challenges, Part II (Windows)

CTF, DFIR, Forensics, PowerShell, Windows

This is part II of this series; for part I see Exploring Magnet Virtual Summit 2025 CTF Challenges (iOS).

If we jump into Axiom and head to the User Accounts, we can see that the SID for chick is S-1-5-21-493923485-410185161-2094537482-1001.

Windows Event Logs will track user login and logoff activity. The primary event IDs for Windows logoff are:
1. Event ID 4647: This is logged when a user manually initiates a logoff process. It is typically associated with interactive and remote-interactive logon types and indicates user-initiated activity.
2. Event ID 4634: This is logged when a logon session is terminated and no longer exists. It can result from system actions (e.g., idle timeout or shutdown) rather than explicit user action. It often follows Event ID 4647 if the logoff was user-initiated.

In Axiom we can find the most recent 4634 event at 11/24/2024 5:36:55 PM, formatted for the challenge as 2024-11-24 17:36:55.

The download source from the crow.jpg URL is https://www.treehugger.com/thmb/EmZOvx28sGNqCtDqQQBMGv-aezM=/4288×2848/filters:fill(auto,1)/__opt__aboutcom__coeus__resources__content_migration__mnn__images__2019__10__american-crow-portrait-01-b3f0cfbdbf164de59831c9725bfdbf67.jpg

In the Installed Programs under Application Usage we can see that com.CandyCrushSaga was installed. This is the package name for Candy Crush.

Under the Web Related artifacts, specifically Edge Chromium Web History we can see traffic to https://x.com/bfp_news which is the Twitter/X site for Burlington Free Press.

Refined Results, Social Media URLs, shows that the user visited the subreddit of https://reddit.com/r/coding.

The question itself practically gives it away, but we’ll check the Installed Programs to be safe. Sure enough the user had Python installed.

Event ID 4720 is a Windows Security Log event that is generated whenever a new user account is successfully created on a system. The creation date for Mary’s account is 2024-09-24 15:11:51.

As someone who used to geocache frequently, this question was a pleasant surprise. Already having an account on geocaching.com also helped.

There’s a fair amount of results if you search on geocaching, but there is only reference in the history to an actual geocache location (GCM70J) titled “Something’s Fishy.”

First we need to identify what counter-forensics tools may have been in use. In the user’s download activity we see that SDelete was downloaded.

If we look at the PowerShell history, ConsoleHost_history.txt, we can see that the command sdelete success.txt.txt was executed.

There are multiple evidence items indicating that the user was also using Proton Mail on the device with the account hackergotyou@proton.me.

The default browser can be identified from the Registry at Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice. In this instance the user was using Edge, the default, as their browser.

In the browser history we see that the user accessed a video at the url, https://www.tiktok.com/@dochristmass/video/7436518844501347616?is_from_webapp=1

To get the time the video was posted, we can copy the url into UNFURL. This reveals the timestamp the video was posted as 2024-11-22 22:11:09.

Again with a filter on ‘geocaching’ we see a fair amount of activity. There is a url with “join” that appears to be part of the user sign in, including username=geomaryr

We also have an entry under Edge Chromium Autofill, as the user opted to save the login ID on that page.

Lastly we can double-check the geocaching.com site with the log for “Something’s Fishy” which matches the timestamp of the web activity. geomaryr is Mary’s username on geocaching.com

The first thought would be to go to the Passwords and Tokens Refined Result. We see a hash for the chick user account. But Wait!

The key is in “Shadow.” It’s not the Windows account we’re looking for.

Looking at Installed Programs we identify that the user installed KALI in Windows Subsystem for Linux (WSL). I knew I wanted to get the /etc/shadow file from the KALI installation – but I was hitting a wall on how.

Finally I wound up exporting the ext4.vhdx (the virtual hard drive for the KALI instance) and running strings against it, and piped the results to ag (grep on steroids) with a search for ‘chick:’.

Much like the way my father would describe my shots back when we would play golf together, ugly but effective. The hash for the user account chick is $fRLLkVPTrLiLVAGhQRWjQd.kKDyvvj040aDd5zoJRt4.

There were a few more challenges under the Windows category but that was as far as I made it in the time allotted.

I hope you’ve enjoyed these walk throughs on my approach to solving the challenges.

If you’d like to access the images used for the CFT for your own training and investigation, you can find them at https://cfreds.nist.gov/all/Hexordia/2025MVSCTF. In addition to the Windows 11 image used here, there is also full file system extractions of Android and iOS, as well as two Google Takeout exports. It’s a great reference set for practicing.

Beyond Hashes: Simplifying Malware Identification with Python and MpCmdRun

DFIR, Forensics, Malware, PowerShell, Python

In an earlier post titled “Growing Your Malware Corpus”, I outlined methods for building a comprehensive test corpus of malware for detection engineering. It covers using sources like VX-Underground for malware samples and details how to organize and unzip these files using Python scripts.

In today’s post we’re going to cover using Python to apply a standard naming methodology to all our malware samples.

Depending on where you curate your samples from, they could be named by their hash, or as they were identified during investigation, like invoice.exe. Depending on the size of your collection, I’d surmise it’s highly unlikely that they have a consistent naming format.

I don’t know about you, but a title that indicates the malware family and platform is a lot more useful to me than a hash value when perusing the corpus for a juicy malware sample. We can rename all our malware files using Python and the command line utility for Windows Defender.

Step 1: You’ll need to install Python on a Windows box that has Windows Defender.

Install Python

If you don’t have Python installed on your Windows machine, you can do so by downloading the installer from python.org, or alternatively, installing from the Windows store.

*Windows Store installer for Python versions 3.7 to 3.12*

Directory Exclusion

Within the Windows Defender Virus & Threat protection settings, add an exclusion for the directory you’re going to be using with the malware. Make sure the exclusion is in place before connecting the drive with the malware so it doesn’t get nuked.

Note: Doing this assumes you’ve evaluated the potential risks associated with handling malware, even in controlled settings, and have taken safety precautions. This is not an exercise to be conducted on your corporate workstation.

*Screenshot of the D:\Malware Directory being excluded from Windows Defender.*

Automatic Sample submission

It’s up to you if you want to disable the Automatic Sample submission. If you do, you’ll still may get prompted to send some.

*Windows Defender requesting to send samples to Microsoft for further analysis.*

Rename_Malware.py

The star of this show is the python script that was shared on ~~twitter~~ from vx-underground.

The post walks through various options for utilizing Windows Defender command line, MpCPmdRun.exe. Using that information a Python script was developed to loop through the contents of a directory, analyze those files with Windows Defender, and then rename the files accordingly based on the malware identification.

*Python code for rename_malware.py in VS Code.*

You can grab the code from the linked post, or a copy on my Github here.

Once you’ve got Python installed, directory exclusion configured, and a pocketful of kryptonite (malware), – you’re ready to go.

python rename_malware.py D:\Malware

Windows Defender command line will run through each file and rename them based on its detection.

*The script recursively renames the analyzed files.*

I’m running this on a copy of my malware corpus of 30,000+ malware samples.

Counting the Corpus

A bit of handy PowerShell math. Before and after the process I wanted to be sure of how many files were present to ensure that the antivirus didn’t remove any. I also wanted to exclude counting pdfs as many of the samples in my corpus also have accompanying write-ups.

*Using PowerShell for selective file counting.*

Get-ChildItem -Recurse -file | Where-Object { $_.Extension ne *.pdf" } | Measure-Object | Select Count

Back at the console the script is still running.

*The script continues recursively renaming the analyzed files.*

Finally… not begrudgingly at all considering over 30,000 samples were analyzed, the script has reached the end of the samples.

*Script has reached the end of the files.*

If we do a directory listing on the contents of the malware directory, we see that the majority of the files have all been renamed based on their malware identification.

*File listing showing malware files named Trojan.Powershell… Trojan.Script… etc.*

Hooray!

That makes it much easier to search and query through the malware repository.

The last step… make a BACKUP. 😉