Wednesday, November 20, 2013

Sniper Forensics, Memory Analysis, and Malware Detection

I conducted some analysis recently where I used timeline analysis, Volatility, and the Sniper Forensics concepts shared by Chris Pogue to develop a thorough set of findings in relatively short order.

I was analyzing an image acquired from a system thought to have been infected with Poison Ivy.  All I had to go on were IPS alerts of network traffic originating from this system on certain dates...but I had no way to determine how "close" the clocks were for the system and the monitoring device.

I started by creating a timeline, and looking for the use of publicly documented persistence mechanisms employed by the malware in question (Windows service, StubPath values within "Installed Components" Registry keys, etc.), as well as looking for the use of NTFS alternate data streams.  All of these turned up...nothing.  A quick review of the timeline showed me that McAfee AV was installed on the system, so I mounted the image via FTK Imager and scanned it with ClamWin 0.98 and MS Security Essentials (both of which were updated immediately prior to the scan).  MSSE got a hit on a file in the system32 folder, which later turned out to be the initial installer.  I searched the timeline, as well as the Software and System Registry hives for the file name, and got no hits beyond just the existence of that file within the file system.

The system was a laptop system and had a hibernation file, which was last modified the day that the system itself had been shut down.  I exported the hibernation file for analysis, and then downloaded the Win32 standalone version of Volatility version 2.3.1, and used that to convert the hibernation file to raw format, then identify the profile (via the imageinfo plugin) and get a process list (via the pstree plugin).

I got in touch with Jamie Levy (@gleeda), who pointed me to this post, which was extremely helpful.  Based on the output of the malfind plugin, I was able to identify a possible process of interest, and I searched the timeline for the executable file name, only to find nothing.  However, I did have a process ID to correlate to the output of the pstree plugin, and I could see that the process in question was a child of services.exe, which told me not only where to look, but also that the installation process required at least Administrator-level privileges.  Correlating information between the RegRipper and plugins, I was able to see which user profiles (both local and domain) on the system were members of the appropriate group.  This also provided me with the start time for both processes, which correlated to the system being started.

A fellow team member had suggested running strings across the memory dump, and then searching the output for specific items; doing so, I found what appeared to be the configuration information used by Poison Ivy (which was later confirmed via malware RE performed by another team member).  As a refinement to that approach, I ran the Volatility vaddump plugin, targeting the specific process, and dumped all of the output files to a folder.  I then ran strings across all of the output folders, and found a similar list of items as when I'd run strings across the entire memory dump.

I validated the configuration item findings via the Volatility handles plugin, looking for mutants within the specific process.  I also dumped the process executable from the memory dump via the procmemdump plugin; the first time I did it, MSSE lit up and quarantined the file, so I disabled MSSE and re-ran the plugin (I set my command prompts with QuickEdit and Insert modes, so re-running the command line as as simple as hitting the up-arrow once, and then hitting Enter...).  I was able to ship the dumped PE file and the initial wrapper I found to a specialist for analysis while I continued my analysis.

I then ran the svcscan plugin and searched the output for the executable file name, and found the Windows service settings, to include the service name.  I also ran the dlllist plugin to see if there were any DLLs that I might be interested in extracting from the image.

I also ran the netscan plugin, and reviewing the output gave no indication of network connections associated with the process in question.  Had there been a connection established associated with the process of interest, I would've run Jamaal's ethscan module, which he talked about (however briefly) at the recent OMFW.

I had downloaded the Poison Ivy plugin, which according to the headers, is specific to one version of the PIvy server.   The plugin ran for quite a while, and because I had what I needed, I simply halted it before it completed.

Something important to point out here is that the analysis that I've described here did not take days or weeks to complete; rather, the research and memory analysis was all completed in just a few hours on one evening.  It could have gone a bit quicker, but until recently, I haven't had an opportunity to do a lot of this type of analysis.  However, incorporating a "Sniper Forensics" thought process into my analysis, and in turn making the best use of available tools and processes, allowed me develop findings in an efficient and thorough manner.

In short, the process (with Volatility plugins) looks like this:
- convert, imageinfo, pstree
- malfind - get PID
- run vaddump against the PID, then run strings against the output
- run handles against the PID
- run procmemdump against the PID (after disabling AV)
- run dlllist against the PID
- run netscan; if connections are found associated with the PID, run ethscan

At this point, I had a good deal of information that I could add to my timeline in order to provide additional context, granularity, and relative confidence in the data I was viewing.  File system metadata can be easily modified, but Windows Event Log records indicating service installation and service start can be correlated with process start times, assisting you in overcoming challenges imposed by the use of anti-forensics techniques.

It's also important to point out that Registry, timeline, and memory analysis are all tools, and while they're all useful, each of them in isolation is nowhere near as powerful as using them all together.  Each technique can provide insight that can either augment or be used as pivot points for another.

A couple of interesting items have popped up recently regarding memory acquisition and analysis, and I thought it would be a good idea to provide them here:
  • Jamie also pointed me to this post, which, while it wasn't directly helpful (the image I was working with was from a Win7SP1 system), it does show the thought process and work flow in solving the challenge
  • From MoonSols, some new features in DumpIt
  • Mark Baggett's ISC Diary posts on winpmem and its uses: here, and here
  • Page_brute - check out how you can incorporate the pagefile into your analysis, until Volatility v3 hits the streets


Anonymous said...

Speaking of Sniper Forensics, do you still update and support "Forensic Scanner"? It is such a awesome tool and if used right, can really drive the Sniper Forensics objectives.

H. Carvey said...


Contact me at keydet89 at yahoo dot com.

Alissa Torres said...

Hi Harlan,
Great post -wish I had been in a chair right next to you so I could have seen the output from each plugin. So cool!
One question: I wonder what you have found (and specifically in this case) with the correlation of the modified time/date stamp of the hiberfil.sys and the date the system was last hibernated. In my experience, they seem not to correlate directly - since the hibernation file header is modified upon resumption of the system, which could be days after a system was set to hibernate.
Any thoughts?
Thanks for sharing!

Alissa Torres

H. Carvey said...


I wonder what you have found (and specifically in this case) with the correlation of the modified time/date stamp of the hiberfil.sys and the date the system was last hibernated.

Sorry, I haven't looked at's not something that's been pertinent to the exams I've been conducting.

In this particular case, what was pertinent is that the malware was loaded into memory at the time that the system was hibernated, and attempts were made to clean the system. As such, the correlating indicators for what was seen on the network was found in the hibernation file.