Doug Metz

Magnet RESPONSE PowerShell

DFIR, Forensic Imaging, PowerShell, Presentations, RAM

I’m excited to share with you a new script I’ve written, Magnet RESPONSE PowerShell.

Magnet RESPONSE is a free tool from Magnet Forensics that makes it easy for investigators as well as non-technical operators to collect triage collections quickly and consistently.

Released initially as a GUI tool for law-enforcement investigators, it’s a single executable that requires no installation. The available command line syntax also makes it very flexible for enterprise use.

So what do I do when there’s a command line interface available, I PowerShell the hell out of it.

If you’ve been following my CyberPipe project, you’ll definitely want to check this one out.

MagnetRESPONSEPowerShell.ps1

Functions:

💻 Capture specified triage artifacts using profiles with Magnet RESPONSE,
🐏 Capture a memory image with DumpIt for Windows or Magnet RAM Capture,
💾 Save all artifacts, output, and audit logs to network drive.
🪟 Supports x86, x64 and ARM64 versions of Windows

Prerequisites:

Magnet RESPONSE

Web server where you can host MagnetRESPONSE.zip that’s accessible to endpoints.

File server repository to save the file collections to.

Please note this is not a Magnet supported product. This script is open source. If you have comments, updates, or suggestions – please do so here or on GitHub via discussion or pull request.

There are two areas of the script for you to customize.

The Variable Setup contains the case identification, file server and web server locations.

The second section, Collection Profiles, define which artifact groups you want to collect. You can see all the options available in the Magnet RESPONSE CLI Guide.

VARIABLE SETUP

$caseID = "demo-161" # no spaces

$outputpath = "\\Server\Share" # Update to reflect output destination.

$server = "192.168.4.187" # "192.168.1.10" resolves to http://192.168.1.10/MagnetRESPONSE.zip

COLLECTION PROFILES

Within the script we need to have at least one set of collection arguments defined. In this case I’ve built multiple profiles, which are simply un-commented to mark the profile as active. You only want to have one profile enabled at a time. You can design your own collection profiles using any of the available CLI options, just follow the format below.

#### Extended Process Capture

$profileName = "EXTENDED PROCESS CAPTURE"

$arguments = "/capturevolatile /captureextendedprocessinfo /saveprocfiles"

Execution

Once your environment and collection variables are defined, go ahead and run the script on your endpoints. Every host that executes the script will download RESPONSE from the web server, run the specified collection profile, and then save the output to the file server. All data defined in the collection profile will be collected and organized by case name, hostname and timestamp of collection in the central location. The returned files can be examined manually, using open source tools, or products like Magnet AXIOM Cyber.

If you’d like to learn more about the script, and how I integrated it with AXIOM Cyber and Magnet AUTOMATE, you can register for my webcast, Responding at Scale with Magnet RESPONSE. I hope to see you there.

You can download the script at https://github.com/MagnetForensics/Magnet-RESPONSE-PowerShell

Capturing malware evidence with detonaRE

DFIR, Malware, PowerShell, RAM

Lately I’ve been experimenting with a lot of varieties of different malware strains. Each time the malware executes, I have a process where I’ll initiate a packet capture, give the malware some time to spin up, and then execute an evidence capture while the malware is running. Then I’ll revert to a snapshot, make some modifications to the environment, and run the process again.

To make things easier on myself (and to help with late afternoon brain fog) I decided to script out the process with PowerShell.

detonaRE – from Latin, to detonate

initiates packet capture
launches malware sample
terminates packet capture after specified interval
initiates evidence collection with Magnet RESPONSE (memory, process, and triage capture)
converts collected .etl file (network capture) to .pcap with etl2pcapng.

## variable configuration:
$malwspath = “E:” ## malware source path
$malwdpath = “C:\Users\REM\Desktop\Malware\” ## malware destination path
$malware = “redline-76ca4a.exe” ## malware executable
$pcaptime = 180 ## duration in seconds for pcap capture
$toolsdir = “E:\Tools” ## MagnetRESPONSE.exe and etl2pcapng.exe

In my case I’ve got my malware file on the root of a USB device (E:) that will be attached to the VM. I want to copy the malware to the ‘Malware’ folder on the VM desktop. For this example the malware file is redline-76ca4a.exe. Any tools needed will be stored in E:\Tools.

I’m using the netsh command to capture any network traffic in .etl format. Later on, we’ll convert the .ett to .pcap. This is the same process I utilized in the QuickPcap PowerShell script.

Once the packet capture is running, the malware file gets detonated. The packet capture will continue running for the set duration, the default being 180 seconds or 3 minutes. It’s important not to terminate the packet capture too early. As you can see in the demonstration video below, once this particular malware sample is detonated, it sleeps for a bit and doesn’t show as active on the system until about 45 seconds into the capture.

Once the packet capture is completed, I’m running the command line version of Magnet RESPONSE. If you’re a fan of CyberPipe this is definitely one you’ll want to check out. Using Magnet RESPONSE I collect the memory (Comae DumpIt), pagefile, running processes (full process dumps) and triage system collection. Note, these artifacts can be scaled down by adjusting the Magnet RESPONSE CLI parameters.

Finally, when that’s all done, the .etl file gets converted to .pcap via etl2pcapng.exe. Then I transfer the collected files to my analysis machine and then the real fun begins.

update: (a day later) version 1.1 now also initiates Process Monitor with a filter applied for the malware to be detonated.

Github link for detonaRE

detonaRE v1.0

detonaRE.ps1 v1.1 now includes Process Monitor

detonaRE version 1.2 demo

Upcoming MAGNET Webinar: Magnet2Go

DFIR, DIY, Forensic Imaging, Presentations, RAM, USB

On August 2, join me on behalf of Magnet Forensics, to learn how to build your own ‘Windows to Go’ drive to support offline collections with Magnet OUTRIDER & Magnet ACQUIRE, as well as free tools for live collections like Magnet RESPONSE, Magnet DumpIt, & Magnet RAM Capture. Registration link below.

If you’re looking for the hard drive referrenced in the talk: [amazon] Samsung T7 SSD

Magnet2Go: Building a ‘Windows to Go’ Drive to Support Live and Offline Collections

Designing Internet Access for Compromised Systems

DFIR, DIY, Malware, USB

Virtual machines are a godsend when it comes to malware analysis. Granted there a many malware samples that may have capabilities to detect if they are operating in a virtualized environment and thus respond differently. Many, though not all of these, can be mitigated by patching the malware binary, or tricking it into a false result before needing to look at the sample on a bare-metal system.

When I’m looking at a piece of malware, I’ll run it through a number of environments, gradually permitting external access once I have an idea of what the malware’s capabilities look like. Initially when detonating samples, I’ll have the target endpoint and a REMnux virtual machine running inetsim operating on an isolated network. Rather than re-invent the wheel, here’s a solid article on setting up an isolated network on VMware ESXi.

At some point I want to enable access to the internet to observe command and control (C2) and any dropper activity. I don’t want there to be an avenue for the malware to be able to interact with any other assets whether on my lab network, or outside it. One way to solve this would be networking and introducing a router to broker the network access. It’s been a while since I had my CCNA and I had some hesitations about getting it right without impacting other services in a very internet dependent household. What I wound up going with instead is a completely separate internet connection for the malware network utilizing a LTE hot-spot.

I run my lab environment on ESXi environment using an Intel NUC. The model I have only has one onboard NIC. The easiest way to add another physical adapter was with a USB Gigabit Ethernet adapter for a measly $13 on amazon. ESXi will not detect this adapter out of the box. Follow the process on this article to configure the USB network adapter for ESXi. You will need to download the USB Network Native Driver for ESXi. Be sure to select the appropriate version to match the version of ESXi you’re running. I’m sure there’s an interesting story on why VMWare calls these ‘Flings’ but that knowledge escapes me.

If all goes as it should, and doesn’t it always, you should see second physical adapter (vusb0) in the ESXi console.

For the secondary internet access, I wound up going with a Netgear LM1200 LTE Hotspot. I like this device because you can configure it to use an LTE connection as a backup if your primary wired internet service is down. I may utilize that in the future but for now it’s only used on the malware network without any connection to the primary LAN. Based on my current cellular plan I was able to add the minimum hotspot plan for $10/mo. A worthy investment for me for the peace of mind that I’m (less likely) to compromise the rest of my network when experimenting with live malware. It will also (one would hope) keep my home IP off any watchlists for malware beacons, or anyone else tracking where different samples are detonated from. As Mr. Heller sagely said, “Just because you’re paranoid doesn’t mean they aren’t after you.”

The same setup could be very useful for responding to compromises in isolated enterprise or manufacturing environments. If you need to have the device access the internet (maybe to upload evidence to you Forensics Service Provider (FSP)), but don’t want to maintain a connection to the corporate LAN due to suspected compromise, this solution would work for that.

Once I had the hotspot up and running, the LAN connection on the hotpot gets connected to the USB ethernet adapter. Then go back to ESXi to the isolated network you created before, the one that you were warned “NO UPLINK”, and use the ‘Add uplink’ function and add the vusb0 device. You can adjust the settings on the LTE hotspot for DHCP if needed as long as the device is in Router (not Bridged) mode.

Malware network with external internet access

That’s it. Now when the infected computer needs to get to the internet, all traffic will go through the LTE connection and the infected systems remain isolated from the primary network.

If I’m in a situation where I absolutely need to run the malware on a bare-metal system I can connect using the LTE modem without threat to any of the other physical systems.