Magnet RESPONSE PowerShell

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

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

Hunting for Indicators with PowerShell: New Files

When analyzing the impact of malware execution on a system, it’s important to identify what additional files the malware has introduced to the system. Have other exe’s been dropped? Are there .vbs files being sprinkled around by the malware fairies?

What other file types would you be concerned with showing up on your systems?

Maybe it’s the inverse and it’s the file extension itself that’s the outlier and you need to identify all the .m41z files, as an example.

I wanted an easy way to identify new files on the system, and yet be flexible to incorporate different extensions and durations. As usual, a PowerShell script seemed the easiest way to address it.

There are 2 inputs, file extension, and duration. What are the kind of new files are you looking for and how far back do you want to look?

<#

GetNewFiles.ps1
@dwmetz, 19-july-2023
A simple script to find any new files on the file system for a specific filetype within x # of days

#>
Write-host " "
$script:filetype = Read-host -Prompt 'Enter the file type to look for (ex. txt, ps1, exe)'
$script:time = Read-host -Prompt 'How many days back do you want to look?'
$ErrorActionPreference = "SilentlyContinue"
Write-host " "
$NewFiles = Get-ChildItem -Path c:\ -Recurse  -Filter "*.$script:filetype" |
Where-Object { $_.CreationTime -gt (Get-Date).AddDays(-$script:time) }
"Number of $script:filetype files found: $($NewFiles.Count)"
$NewFiles | Select-Object Fullname,CreationTime

Running the script on a suspected infected asset, I can look for new files of interest and if need be work backwards for a larger time sampling.

In the example above, one of the executables bears looking into. The other is benign and related to software updates.

For the .ps1 results we see the script we’re running “GetNewFiles.ps1” as well as another hit for a script that was created on the system the day before.

NOTE: If a file is no longer there when you run the script, for example created and deleted during the malware operation, you won’t see it here as it’s no longer present on the system.

If you run the malware on multiple samples, can you see a commonality among the new files? Does it always drop ‘notAsafeFILE.exe‘ in the same path, or is there a randomization in the file naming and location? PowerShell can be a quick way to come to that answer and identify what other files require investigation.

Mal-Hash Updates

Mal-Hash.ps1

  • The script takes the input of a file, calculates the hashes (MD5, SHA1, SHA256), and then submits the SHA256 hash to Virus Total* for analysis.
  • The script will also run Strings against the sample.
  • The script will check Malware Bazaar to see if a sample matching the hash is available.
  • The hashes, strings, Virus Total and Malware Bazaar results are both displayed on screen and saved to a text report.
  • Timestamp of the analysis is recorded in UTC.

VTHashSub.ps1

  • The script takes a hash value as input and submits the hash to Virus Total* for analysis.
  • The script will check Malware Bazaar to see if a sample matching the hash is available.
  • The hashes, Virus Total and Malware Bazaar results are both displayed on screen and saved to a text report.
  • Timestamp of the analysis is recorded in UTC.

Mal-Hash.ps1 and VTHashSub.ps1 will operate (via PowerShell) on Windows, Mac & Linux.

* Virus Total API key expected in vt-api.txt.

Latest updates:

  • n of x vendors detected
  • VT permalink
  • Malware Bazaar results

Both scripts available on my GitHub page:

https://github.com/dwmetz/Mal-Hash