Forensics – Page 9 – Baker Street Forensics

CyberPipe version 5.0

DFIR, Forensic Imaging, PowerShell, RAM, Triage, USB

The latest update to CyberPipe (the code formerly known as CSIRT-Collect), has been revised to leverage the free triage collection tool, MAGNET Response. As with previous versions it also runs Encrypted Disk Detector, another free tool from MAGNET.

Script Functions:

Capture a memory image with MAGNET DumpIt for Windows, (x32, x64, ARM64), or MAGNET RAM Capture on legacy systems,
Create a Triage collection* with MAGNET Response,
Check for encrypted disks with Encrypted Disk Detector,
Recover the active BitLocker Recovery key,
Save all artifacts, output and audit logs to USB or source network drive.

* There are collection profiles available for:

Volatile Artifacts
Triage Collection (Volatile, RAM, Pagefile, Triage artifacts)
Just RAM
RAM & Pagefile
or build your own using the RESPONSE CLI options

Prerequisites:

The setup is simple. Save the CyberPipe script to a USB drive. Next to the script is a Tools folder with the executables for MAGNET Response & EDD. Before running, customize the script to select a collection profile. Run the script from the USB drive and collect away. Move on to the next PC and run it again.

Network Usage:

CyberPipe 5 also has the capability to write captures to a network repository. Just un-comment the # Network section and update the \\server\share line to reflect your environment.

In this configuration it can be included as part of automation functions like a collection being triggered from an event logged on the EDR.

Prior Version (KAPE Support):

If you’re a prior user of CyberPipe and want to use the previous method where KAPE facilitates the collection with the MAGNET tools, or have made other KAPE modifications, use v4.01.

Download:

Download the latest release of CyberPIpe on GitHub.

https://github.com/dwmetz/CyberPipe

Ginsu: A tool for repackaging large collections to traverse Windows Defender Live Response

DFIR, M365, PowerShell, Triage

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.

You can download Ginsu from my GitHub repo at https://github.com/dwmetz/Ginsu

Huntress CTF: Week 4 – Forensics: Bad Memory

CTF, DFIR, Forensics, Memory Analysis

Bad Memory

I spent a bit of time on this trying to get Volatility 2 to work with the Mimikatz plug-in. I was not successful. I was able to run the Volatility hashdump module.

I switched to Volatility3 and ran hashdump. For whatever reason the output of Volatility3 was different.

The only user besides the default accounts is for ‘Congo.’ Copy the hashed password and head over to https://hashes.com/en/decrypt/hash where we can search for the hash.

Yay, we got a match.

[Note: anecdotally I was advised that you could do this offline as well with Hashcat and the rockyou wordlist. I had tried that earlier but was using the Volatility2 output. 😦 ]

The last step is to convert ‘goldfish#’ to MD5.

Now just wrap it in the flag { } and you’re good to go.

Use the tag #HuntressCTF on BakerStreetForensics.com to see all related posts and solutions for the 2023 Huntress CTF.

Huntress CTF: Week 3 – Forensics: Rogue Inbox, Texas Chainsaw Massacre: Tokyo Drift

CTF, DFIR, Forensics

Rogue Inbox

Originally I was looking at this in Timeline Explorer, but decided to switch to Excel.

Swimming and scanning through a sea of log entries, an anomaly showed itself.

For this one I just copied the values out by hand.

Huntress CTF: Week 3 – Forensics: Rogue Inbox, Texas Chainsaw Massacre: Tokyo Drift

The download is Application Logs.evtx

If you open the log with Event Viewer, you may see there’s an entry for a (non-actual) event ID of 1337.

The error content isn’t very helpful.

Let’s take a hint from the title and run the event log through Chainsaw.

Nothing significant when using the stock rules. What if we poke specifically at Event ID 1337.

That looks interesting.

Copy the binary data and bring it over to CyberChef

From unintelligible binary to unintelligible PowerShell.

Copy the output and save it is a .ps1 file. We can run the script through PowerDecode.

PowerCode works down through the obfuscation layers, finally revealing the plain text of the command.

Now that the code has been deobfuscated, time to figure out what it does. I copied the code into PowerShell ISE and start isolating the different command sections.

One of the commands does a DNS lookup and directs the output into a string.

If we run the command on its own we can see the output. The last part of the script checks to see if the output matches the pattern of a Base64 encoded string, and if so, decodes it.

Now what was that about Tokyo?

Use the tag #HuntressCTF on BakerStreetForensics.com to see all related posts and solutions for the 2023 Huntress CTF.