Tag: 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

Hunting for Indicators with PowerShell: New Files

DFIR, Malware, PowerShell

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

DFIR, Malware, PowerShell

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

NSRL Query from the Command Line

DFIR, PowerShell, Python

In digital forensics, we’re frequently trying to separate the signal from the noise. When examining operating systems – including mobile, it can be helpful to know what files came with the operating system. By filtering those out we can concentrate on what’s new on the device as we start looking for activity.

The National Software Reference Library (NSRL) is designed to collect software from various sources and incorporate file profiles computed from this software into a Reference Data Set (RDS) of information. The RDS can be used by law enforcement, government, and industry organizations to review files on a computer by matching file profiles in the RDS. This will help alleviate much of the effort involved in determining which files are important as evidence on computers or file systems that have been seized as part of criminal investigations.

https://www.nist.gov/itl/ssd/software-quality-group/national-software-reference-library-nsrl

Recently I came across a site that, among other capabilities, has the option of doing an NSRL lookup using curl from the command line.

Me being Mr. PowerShell I wanted to see what the syntax would be to do the same lookup with PowerShell. So where did I turn? No, not to Jeffrey Snover. I went to ChatGPT. I’d heard quite about how services like these, while not trustworthy for anything of historical accuracy, are pretty good at translating code.

The original syntax:

curl -X 'GET' \
  'https://hashlookup.circl.lu/lookup/sha1/09510d698f3202cac1bb101e1f3472d3fa399128' \
  -H 'accept: application/json'

Sure enough it returned functional code to do the same operation in PowerShell. What I really appreciated though is the detailed information beneath that explains the parallel functions between the two, and what the different values represent. I could see myself using ‘explain this code to me’ in the future.

PowerShell NSLR Query Syntax:

Invoke-RestMethod -Uri 'https://hashlookup.circl.lu/lookup/sha1/3f64c98f22da277a07cab248c44c56eedb796a81' -Headers @{accept='application/json'} -Method GET

I also asked it to convert the curl command to Python which it handled equally well, and once again the same level of explanation of what’s going on beneath the code.

Python NSRL Query Syntax:

import requests
response = requests.get('https://hashlookup.circl.lu/lookup/sha1/09510d698f3202cac1bb101e1f3472d3fa399128', headers={'accept': 'application/json'})
print(response.json())

Curl script & output

Python script & output

PowerShell script & output

Of the three, I prefer the output of the PowerShell command as the output is the most readable. In the screenshot above, four queries were run. For the first two there wasn’t a matching hash detected, so we can’t confirm whether those were included with the operating system. For the second two queries, which happen to be for executable names that are frequently misused by bad actors, we see that the hashes queried do match the published NSRL.