January 2020, the last time I had work related travel, seems like an eon ago. Later that year I had planned my first attendance at the Magnet User Summit in Nashville. Then COVID entered the scene and every event going forward for me was remote only. Don’t get me wrong, I’m an introvert and being able to work from home in my fortress of solitude the past few years has been great. I even managed to present at Magnet Enterprise Pulse and the HTCIA International Summit, both remotely. Fast forward to the present and events are starting to open back up.
Getting the band back together
The Magnet User Summit in April will be supporting in-person and virtual attendance. After two years as virtual participant I’ll finally be able to attend in person. As it turns out I’ll be presenting at the conference as well! It’s taken me a few years to get here, but now I get to attend as a speaker (and and employee!)
You can register for the Magnet User Summit (in person or virtual) here:
Earlier today I was asked for a ‘quick and easy’ PowerShell to grab a packet capture on a Windows box. I didn’t have anything on hand so I set off to the Google and returned with the necessary ingredients.
The star of the show is netsh trace, which is built into Windows. If we wanted to capture for 90 seconds, start the trace, wait 90 seconds, and stop it the syntax would be:
Note there are 3 lines (the first may wrap depending on windows size)
Like Wireshark, you need to specify what interface you want to capture traffic from. In the example above 192.168.1.167 is the active interface I want to capture. But what if I want to use this for automation and won’t know in advance what the active IP address will be?
We can grab the local IPv4 address and save it as a variable.
Perfect. Automated packet capture without having to install Wireshark on the host. The only item you should need to adjust will be the capture (sleep) timer.
But wait, the request was for a pcap file. Not a .etl. Lucky for us there’s an easy conversion utility etl2pcapng. Execution is as simple as giving the exe the source and destination files.
That’s it. We’re now able to collect a packet capture on Windows hosts without adding any additional tools. We can then take those collections and convert them with ease to everyone’s favorite packet analyzer.
I’ve combined everything above into QuickPcap.ps1 available on my GitHub site.
QuickPcap.ps1
In this case the capture and conversion are running as one contiguous process, but it’s easy to imagine them as separate automation elements being handled through scripting by different processes. After all, we all build our Lego’s differently, don’t we?
“The Game is On!”
Post-update
Since this continues to be one of the most searched for topics, be sure to check out detonaRE, a malware detonation and capture utility that uses the same pcap functionality.
detonaRE initiates packet capture and process monitor, detonates the malware, ends pcap collection, completes evidence capture with Magnet RESPONSE. PCAP, Zip, and CSV outputs.
Windows Subsystem for Linux (WSL) adds a lot of capability and convenience for running DFIR applications on a Windows host. Previously I wrote about how to add a SIFT/REMnux Ubuntu distribution to WSL.
Another tip I’d like to share with you is setting up separate profiles for frequently used applications.
Volatility is one of the applications I’m in frequently, whether for work or lab(work). Sure, I can open a command window and then navigate to the appropriate application path; but why not make it a one-click option.
To begin, open Windows Terminal, and go to the Settings menu.
On the bottom left choose select ‘Add a new profile.’
PowerShell (Core) is my default shell environment. I’ll select this as the profile to duplicate.
After you hit ‘Duplicate’ you’ll be presented with a copy of the profile.
Update the Name and Starting directory to reflect the application path.
You can customize the Icon and Tab title. Under the Appearance tab you can assign a custom background for the WSL profile. Be sure to click Save when you’ve made your changes.
Now when I want to open a Volatility session, it’s right there on the drop down in WSL.
If you have WSL parked on the Taskbar, you can select the new profile (or any other profile) with a right-click.
If you want to have your WSL instances in separate windows, versus the default tabbed layout, right clicking from the taskbar will open the selected session in a new window.
CSIRT-Collect USB can be found in the main repository for CSIRT-Collect. CSIRT-Collect is a PowerShell script to collect memory and (triage) disk forensics for incident response investigations.
CSIRT-Collect USB is designed to run directly from a USB device. While a network deployment certainly supports automation, as an Incident Responder I can think of several examples where that wouldn’t be an option:
An air-gapped manufacturing environment
Hospital/Medical Environments
Ransomware incidents when the assets have been detached from the network
Preparation is the first phase of the Incident Response lifecycle. (PICERL) Once you’ve tested and/or adapted the collection for your environment, consider prepping a handful of drives and having them pre-deployed to sites where you’re likely to need them.
The Setup
First off you’re going to need a high-capacity USB device. Larger sized flash drives will work. Personally I’m a fan of Samsung (T series) SSD drives, both for their size and their write speeds during acquisitions.
On the root of the USB device:
A (initially empty) folder named ‘Collections’
KAPE directory from default KAPE installation
EDD.exe in \KAPE\Modules\bin\EDD (Encrypted Disk Detector)
CSIRT-Collect_USB.ps1
MRC.exe (Magnet RAM Capture)
Launch
To run the script, open an elevated PowerShell prompt and browse to the USB device. Then simply
.\CSIRT-Collect_USB.ps1
CSIRT-Collect_USB.ps1 starting
What it Captures
The first process the script runs is Magnet RAM Capture. Once the RAM has been captured, the windows build (profile) is captured. The RAM image and the build info are named to reflect the asset hostname being collected.
The next process is the KAPE Triage collection. Host artifacts are acquired and then assembled as a .vhdx (portable hard disk) image. After the KAPE Targets portion completes, KAPE calls the Encrypted Disk Detector module which checks the local physical drives on a system for TrueCrypt, PGP, VeraCrypt, SafeBoot, or Bitlocker encrypted volumes. This information is saved into the Collections directory, as well as displayed to the responder to identify other volumes that may need to be collected while the system is live.
Lastly, if BitLocker is enabled for the OS drive the script will capture that information as well and back-up the recovery key.
Disk Encryption Check
Collection Contents
Inside the Collections folder, a subfolder will be created for each asset collected. The size of the USB device will determine how many collections can be captured before the results need to be offloaded.
The \Collections\%hostname% directory will include:
Console log capturing all KAPE targets activity
.vhdx of the host artifacts
collection complete date/time .txt
Memory acquisition .raw
Windows profile (build information) .txt
In the \Collections\%hostname%\Decrypt folder you will find
console log for KAPE modules (EDD)
recovery key for BitLocker (C) volume .txt
Live Response directory with the output of EDD .txt
Baker Street Forensics 