Timelining a Malicious VHD for More Intelligence

In a previous blog post I mentioned how adversaries using VHD files to distribute malware can leave around a lot more data than they intend, including identifiable data for tracking. In this post I want to break out the best friend everyone made during SANS FOR508, Plaso, so I can process the filesystem data for a malicious VHD and illustrate how we can establish a timeline of operations for the adversary. Just like last time, the sample I’m working with is here in MalwareBazaar: https://bazaar.abuse.ch/sample/72ba4bd27c5d95912ac5e572849f0aaf56c5873e03f5596cb82e56ac879e3614/.

Get Plaso

Plaso is pretty easy to set up nowadays, and I opted for the Docker setup instructions here: https://plaso.readthedocs.io/en/latest/sources/user/Installing-with-docker.html. I used the Docker Hub option.

$ docker pull log2timeline/plaso

The only bad thing about this option is that it makes your commands to process files longer because you have to do a full docker run command. I shorten it down using a bash alias or something like this:

$ alias plaso='docker run -v ./:/data log2timeline/plaso'

In the rest of the blog post I’m going to map whatever current directory I’m working from ./ to /data inside the Plaso container, that’s the -v option I have defined in the alias. This lets me pass whatever files I want into the Plaso container and work with them.

Process that VHD

If you’ve used Plaso or log2timeline.py before, you might remember timelining as a long, laborious process that takes quite some time. That’s still potentially the case for disk forensics on large disks or if you need to mix and match multiple plugins to get output just right. For our use, we’re just going to scratch the surface of Plaso using the easiest way to create a timeline, the psteal.py command. Plaso natively understands how to work with VHD files, so we don’t even have to convert formats.

$ plaso psteal.py --source /data/invoice.vhd -o dynamic -w /data/timeline.csv

This command takes the invoice.vhd file the adversary distributed malware with, parses the filesystem details inside, and gives us a detailed timeline in timeline.csv. From here, we can import that CSV file into any tool we want to inspect it such as the number 1 forensic tool of all time: a spreadsheet.

Using the Timeline

To view the timeline, I’m using LibreOffice Calc because that’s what’s included within my REMnux system. If you want, you can use MS Excel, Google Sheets, or even fancier tools such as Timesketch.

In the Text Import menu of LibreOffice Calc I take the default values because I want to import the CSV from row 1, delimit fields by commas, and treat " as a text delimiter. Once the data is imported, I select the whole sheet and click the AutoFilter option because it will allow us to filter and work with the spreadsheet using the headers and field values.

Over on the left side of the spreadsheet we have timestamp values, but we don’t have details on what timezone the adversary was originally working from, so there is potentially a time skew. From what I can tell looking through the sections of File System Forensic Analysis on FAT/FAT32, the timezone information doesn’t seem to get saved with the filesystem. KEEP IN MIND that any information we glean from timestamps may be skewed by system clock details on the adversary system at the time of file manipulation. If for some reason the adversary used an incorrect time or calendar day, our analysis would be skewed.

If we scroll to the bottom, we can see a few entries. The main entry I want to focus on is the Creation Time for invoice.pdf.lnk, which is allegedly 2023-05-01T10:40:53.000000+00:00. This aligns with the fact that this malware sample was uploaded to MalwareBazaar on May 2, 2023. VirusTotal also reports a first submission timestamp of 2023-05-02 18:54:43 UTC, indicating that the sample was potentially known or used around May 2, 2023. So we know that distribution of this specific file occurred somewhere between 5/1 and 5/2, with it being reported by researchers fairly quickly.

Now that we have a grasp of its likely distribution time, let’s take a look at what files were deleted and what executables were written on disk. This may give us a better grasp on how often this adversary updated their distribution tooling and different methods they used for initial access. I can do this by filtering the source column to only show entries from RECBIN and PE. Filtering those entries takes us down to a handful of rows, mostly showing deleted file entries and a few EXE creation entries that have associated import table hashes. We can immediately use those hashes for more information.

The import hash ad9d11227a86b863e31ddf6019cc7ab5 has been seen with multiple files in MalwareBazaar and has been associated with distribution of NetWire in the past. This DOES NOT mean that the import hash always equals NetWire, it only means that files corresponding to that same import hash have led to NetWire.

The other import hash seen, f34d5f2d4577ed6d9ceec516c1f5a744, is a common import hash seen across ALL EXEs created with the .NET Framework so it will definitely lead to false identifications if you try to use it as a sole data point for assessment. The presence of this import hash just means that this adversary has likely worked with .NET malware families.

Looking at the deleted file entries, we can see the adversary here likes to use certain naming schemes for their initial lure. There are lots of file names that include receipt, invoice-, e-Receipt, eVoucher, order-receipt, and masquerades files as PDFs or PDF readers. The file extensions show this adversary has worked with JScript, BAT, screensaver (SCR), PIF, VBS, and EXE files. They’ve switched around their tooling from time to time, focusing mostly on JScript files while taking brief adventures into other file types.

Looking at the deleted entry timestamps, we know that the adversary likely worked on their malware distribution every few days From 2022-10-27 through 2022-11-11, taking periodic breaks. A lot of activity occurred in February and March 2023, followed by a little activity in April and May. We can get more details on the timeline by zooming back out and including all the file modification entries. Doing so provides a little more info, showing that the adversary didn’t just take a break between November 2022 and February 2023, they made some file modifications in December.

Tracking Adversaries with Forensic Data

The example in this post is relatively simple and generic with the file names. Where this gets really interesting is when the adversary uses unique file names or content that may be retained in the VHD and also available in public reporting. For example, if your adversary uses a novel invoice-HopeIsLost.js filename and that name gets reported in public documentation, you can use that as a lead to see if more data in the VHD matches with the public reporting. If so, you can potentially springboard from that public documentation into more resources to track the adversary related to your sample.

Thanks for reading and I hope this helps give you ideas on how to squeeze more data from your samples!