Thoughts on Analysis

Warning - before you get started reading this blog post, it's only fair that I warn you...in this post, I make the recommendation that you document your analysis process. If you find this traumatic, you might want to just move on. ;-)

Robert Jan Mora, a name that I've known for some time within the DFIR community, recently posted something pretty fascinating on LinkedIn, having to do with a case that he worked a bit ago. His post, in turn, leads to this The Wire article, from India, and includes an interview with him. 

The "so what" of the article itself has to do with an initial report that states that no malware was present, and two subsequent reports, one of which is from Robert Jan's analysis, stating that malware was found on a USB device.

In his LinkedIn post, Robert Jan emphasizes the need for malware scans in a law enforcement environment. Back when I first started working cases, even internally, in the early 2000s, I recommended the same thing, albeit with AV scanners not installed on imaged endpoint. Even more tools are available these days; for example, consider Yara, or something more along the lines of the Thor Scanner from Nextron Systems.

To learn a bit more about this man, check out this Forensic Focus interview. 

Okay, but so what? Why does this matter, or why is it important?

When looking to see if malware exists, or did exist on an endpoint, there are different approaches you can take, perhaps using AV scanners, or something like Yara. Or, sometimes, we may not find the actual malware itself, maybe not right away, but we will see clear indications of it's presence, or that it had executed. For example, if you've created a timeline of system activity, you may find a cluster of activity with different components derived from different sources, such as the Registry, Windows Event Log, file system, etc. Separately, these may not be entirely conclusive, but when viewed together, and within a narrow timeframe, they may provide clear indications of something having happened, much like finding footprints, disturbed earth, broken branches, and matted grass following the passage of an animal through a wilderness area.

You can even find indications of malware having been or even executed on a system, while the executable itself no longer exists on the endpoint at the time of the investigation. Using sources such as the SRUM DB and/or AmCache.hve and PCA log files may provide valuable insights, even if the malware has been removed from the endpoint.

When I was working PCI forensic investigations, our team had found that some of the malware used by the threat actors was based on a "compiled" Perl script, used to retrieve credit card numbers from a process memory dump. When run, the program extracted the Perl runtime from the EXE, and placed it in a particular folder path, and each time it was run, the path was slightly different; the final folder name changed. However, using file system metadata, we were able to determine a very explicit timeline of the compromise.

Or, we may find indications that an attempt was made to execute the malware, but it failed, either because it was detected and quarantined, or because something caused it to crash. PCA log files and application pop-up/WER messages in the Application Event Log have proved to be very illuminating on some of the cases with which I've engaged.

The key to all of this is to document your analysis process; if you don't know what you did, you can't make modifications or adjustments to the process. For example, if you have a memory dump, how did you go about searching for indications of a specific IP address? Volatility? Bulk_extractor? Don't remember/don't know? If you mounted the image and scanned it with AV, which one/version did you use? Knowing what you did, and what you found, means that you can then make adjustments and improvements to the process over time.