Enterprise customers running Windows Defender for Endpoint have a lot of capability at their fingertips. This includes the Live Response console, a limited command shell to interact with any managed Defender assets that are online. Besides its native commands you can also use the console to push scripts and executables to endpoints.
Note: there is a specific security setting in the Defender console if you want to allow unsigned scripts.
Microsoft has its own triage package capability, but you can also push your own tools like Magnet RESPONSE or KAPE. With a little bit of PowerShell mojo you can use your favorite collection utilities using the Defender Live Response console as your entry point into the remote asset.
The console enables you to pull back files from the remote endpoint, even when it’s been quarantined. One limitation of this console function is that you’re limited to retrieving files of 3GB or less.
For many triage collections this could be under the limit, but depending on the artifacts you’re collecting you might exceed that. So what do you do when you have an isolated endpoint but you need to pull back files over 3GB? That’s where Ginsu comes in.
Ginsu is a PowerShell script that you can upload to your Defender console along with the command line version of 7zip. You configure the script with the directory with the contents you want to transfer. The script acts as a wrapper for 7zip and will create a multipart archive, splitting the files into 3GB segments.
Once you pull the archives back to your workstation, you can use 7zip to extract the files back into their original properties.
In testing, the file transfer capabilities were a bit buggy, whether it was transferring 3GB Ginsu files or other smaller files from the asset. I’m hoping this improves as the Defender console matures. If you’re able to text Ginsu in your environment, I’d love to hear how it performs.
A couple weeks ago, a reader commented on the post Adding RAM collections to KAPE triage, “Couldn’t this be implemented by using linear processing with KAPE in batch mode?” and I couldn’t be more grateful for their inquiry.
When I was first introduced to KAPE, ‘batch mode’ didn’t exist yet as a feature. From the documentation:
“Batch mode works by placing one or more command lines (without the kape.exe part) into a file named _kape.cli. This file should contain one full command line on each line. This allows you to preconfigure KAPE to perform a given action (for example, collect certain files, zip them, then SFTP them to somewhere).”
Essentially it allows you to string together multiple KAPE jobs and run them together. This could be useful when you want to send the output of one command to a network share, and another to S3. I’m sure there are many other use cases, but I haven’t explored many as of yet.
KAPE has supported memory collection from its very early days. In fact I wrote the original DumpIt plugin for KAPE back in May ’19 (Pepperidge Farm Remembers). I later wrote the module for Magnet RAM Capture. Rounding out the triad is Winpmem which was added by another contributor around the same time (hours apart if I remember) as the DumpIt plugin.
At the time I thought I’d finally solved my Incident Responders ultimate dream of ‘give me RAM and a selective triage image – and give it to me quickly.’ While using any of the memory modules with KAPE, and an appropriate Targets selection for triage would yield both results, to me there was still a problem. The way KAPE operates it initiates the Targets operations (collections) and then the Modules (execution) operations. If I selected a triage image and included the memory collection module, the triage collection would run first and after would run the memory collection (module). While I was pretty giddy over having made what would be my first public contributions to DFIR software, I really wanted to grab the memory first and then do any other operations. The goal was to preserve as much volatile data as possible. It was out of that need to control the order of operations that led me to write CSIRT-Collect.
Via PowerShell, CSIRT-Collect would collect a RAM image first (evolving over the years experimenting with DumpIt, Magnet RAM Capture and Winpmen – and now back to DumpIt again) and then invoke KAPE to handle the triage collection. There were two versions of the code, mostly identical but adapted for use via network share or via USB drive. We used this script within my IR team for a few years before I shared it to GitHub where it’s continued to develop (and be the topic of numerous webcasts.)
ARM64 processors
DumpIt, which was recently added to the Magnet Forensics Free Tools site, supports x64, x86 and ARM processors on Windows. With CSIRT-Collect and KAPE, I was able to run the triage and RAM collections on my (regular suspects) Windows instances, as well as a Windows ARM virtual machine running on an M1 Mac. That introduced my next problem though, that there wasn’t a means within KAPE to detect ARM64 vs x64, just 32bit vs. 64bit. Since the architecture support wasn’t there, I whipped up a new KAPE module specific to the ARM version of DumpIt which has been added to the latest version of KAPE. Once you update KAPE, grab the ARM version of DumpIt, name it DumpIt_arm.exe, drop it in the /bin and you’re good to go. The latest version (4.0) of CSIRT-Collect queries the architecture and will direct KAPE to utilize the appropriate .exe for the architecture.
Back to batch mode
The first line of the _kape.cli had the (modules) arguments for DumpIt and Encrypted Disk Detector. The next line called the KAPE-Triage (targets) collection.
By default all the KAPE instances called by the _kape.cli will execute simultaneously. When I was first experimenting with it both the RAM collection and the triage collection would initiate at the same time. While this made for even faster collections on larger targets, there was still the issue of preserving the most volatile data. Back to the documentation, (it helps to read to the very last line… )
“Should you want to limit things to a single KAPE process running at once, adding --ul to one of the entries (it should be the first one in most cases) tells KAPE to wait for each instance of KAPE to exit before starting the next. When using this mode, you will only see one active instance of KAPE vs. multiple instances starting at once.”
Adding a –ul to the first KAPE argument ensured that the memory collection operations would take place first and only then when completed start the next phase of the triage collection.
Another bit about batch mode. When kape.exe executes and there is a _kape.cli in the root path it will use those arguments and then renames the file to $timestamp_kape.cli. So the next time KAPE executes from this directory, a _kape.cli will not be present. Since the intention of the script is to be reusable and repeatable without intrevention, I needed the _kape.cli to be persistent. I decided the solution was to have the script create the _kape.cli at runtime. This also allowed me to accommodate for the x64 vs ARM64 issue. If ARM is detected, the _kape.cli will be generated with the instructions for the ARM module. Otherwise the x64 module will be used.
Up until recently the script required specific folder configurations in place (collections folder, memory folder, KAPE, etc.) That’s been simplified now. Just sit CSIRT-Collect.ps1 next to your KAPE directory (whether on network or USB) and the script will take care of any folder creation necessary.
v4.0 Features:
– “One Script to Rule them All” – Admin permissions check before execution
– Memory acquisition will use Magnet DumpIt for Windows (previously used Magnet RAM Capture). – Support for x64, ARM64 and x86 architectures. – Both memory acquistion and triage collection now facilitated via KAPE batch mode with _kape.cli dynamically built during execution. – Capture directories now named to $hostname-$timestamp to support multiple collections from the same asset without overwriting.
$collection = $env:COMPUTERNAME+$tstamp
– Alert if Bitlocker key not detected. Both display and (empty) text file updated if encryption key not detected. If key is detected it is written to the output file.
(Get-BitLockerVolume -MountPoint C).KeyProtector > $CollectionHostpath\LiveResponse\$collection-key.txt
If ($Null -eq (Get-Content "$CollectionHostpath\LiveResponse\$collection-key.txt")) {
Write-Host -Fore Yellow "Bitlocker key not identified."
Set-Content -Path $CollectionHostpath\LiveResponse\$collection-key.txt -Value "No Bitlocker key identified for $env:computername"
}
Else {
Write-Host -fore green "Bitlocker key recovered."
}
– More efficient use of variables for output files rather than relying on renaming functions during operations – Now just one script for Network or USB usage. Uncomment the “Network Collection” section for network use.
## Network Collection - uncomment the section below for Network use
<#
Write-Host -Fore Gray "Mapping network drive..."
$Networkpath = "X:\"
If (Test-Path -Path $Networkpath) {
Write-Host -Fore Gray "Drive Exists already."
}
Else {
# map network drive
(New-Object -ComObject WScript.Network).MapNetworkDrive("X:","\\Server\Triage")
# check mapping again
If (Test-Path -Path $Networkpath) {
Write-Host -Fore Gray "Drive has been mapped."
}
Else {
Write-Host -Fore Red "Error mapping drive."
}
}
Set-Location X:
#>
## Below is for USB and Network:
$tstamp = (Get-Date -Format "_yyyyMMddHHmm")
$collection = $env:COMPUTERNAME+$tstamp
...
– Stopwatch function will calculate the total runtime of the collection. – ASCII art 😉 “Ceci n’est pas une pipe.”
I’m very pleased with how this project has continued to develop. Special thanks to Brian Maloney whos question got things started down a new path. If you have other questions or suggestions, feel free to leave them here – or better yet, submit a PR at the GitHub repo.
On February 21, I’ll be discussing CSIRT-Collect Free Tools to Bolster Your IR Toolkit at #MVS2023. Register today!
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
A PowerShell script to collect memory and (triage) disk forensics for incident response investigations
There’s a number of tools that support a one-to-many remote operation capability. However, not all organizations have that level of capability. I’ve also seen that in some large organizations how things are designed to work with remote assets, and how they actually work, may not be the same. What I wanted was a repeatable pre-defined collection mechanism, that could scale out to be supported by non-forensics team members to participate in forensic evidence collection for incident response examinations. The intent is that the collection process can be distributed among remote team members, be it site support or Security Operations Center (SOC). The script can also be integrated into SOAR and EDR platforms.
CSIRT-Collect leverages a network share, from which it will access and copy the required executables and subsequently upload the acquired evidence to the same share post-collection.
Permission requirements for said directory will be dependent on the nuances of the environment and what credentials are used for the script execution (interactive vs. automation). In the demonstration code, a network location of \\Synology\Collections can be seen. This should be changed to reflect the specifics of your environment.
The Collections folder will need to include: – subdirectory KAPE; copy the directory from any existing install – subdirectory MEMORY; 7za.exe command line version of 7zip and winpmem.exe
CSIRT-Collect Operations:
Maps to existing network drive –
Subdir 1: “Memory” – Winpmem and 7zip executables
Subdir 2: ”KAPE” – directory (copied from local install)
Creates a local directory on asset
Copies the Memory exe files to local directory
Captures memory with Winpmem
When complete, ZIPs the memory image
Renames the zip file based on hostname
Documents the OS Build Info (no need to determine profile for Volatility)
Compressed image is copied to network directory and deleted from host after transfer complete
New temp Directory on asset for KAPE output
KAPE !SANS_Triage collection is run using VHDX as output format [$hostname.vhdx] **
VHDX transfers to network
Removes the local KAPE directory after completion
Writes a “Process complete” text file to network to signal investigators that collection is ready for analysis.
** Note: you can build different KAPE collection profiles by modifying just one line of code. Profiles can be chosen to support the requirements of the investigation.
CSIRT-Collect_USB
This is a separate script that performs essentially the same functionality as CSIRT-Collect.ps1 with the exception that it is intended to be run from a USB device. There is no need for a temporary host directory as the information is written direct to the USB device. The extra compression operations on the memory image and KAPE .vhdx have also been omitted. There is a slight change noted below to the folder structure for the USB version. On the root of the USB:
CSIRT-Collect_USB.ps1
folder (empty to start) titled ‘Collections’
folders for KAPE and Memory – same as above
Execution: -Open PowerShell as Adminstrator -Navigate to the USB device -Execute ./CSIRT-Collect_USB.ps1
To see a demonstration of CSIRT-Collect in action please register for my talk this Thursday, PowerShell Tools for IR Forensics Collection as part of the Enterprise Pulse lecture series hosted by Magnet Forensics.
Baker Street Forensics 