Doing Analysis

I had an opportunity to perform some pretty fascinating analysis recently, and I thought some might appreciate it if I were to take a moment and describe what I did, and how I went about the analysis.

Situation
The situation was pretty straight-forward; a system (Win7SP1) had been identified as having been infected with malware at one point.  What had been determined from the initial analysis that had been conducted was that the system have been infected in Sept, 2014.  As it turned out, the malware in question had been deleted by an AV scan around mid-Aug, 2015, and the image had been acquired near the end of Sept, 2015.  Two user profiles had been identified as having been involved in the initial infection.

Goals
The goal of this analysis was pretty simple.  Essentially, the initial analysis work had already been done, and a report had been delivered to the client. My objective for this analysis was to gain greater insight into the infection process, and to see if I could develop threat intelligence from anything else that I found.

Tools
I performed all of my work using free and open-source tools.

• Timeline Tools
• RegRipper
• FTK Imager
• Volatility

I conducted my analysis using Notepad++.

Timeline
I created a timeline of system activity using:

• File system metadata
• Selected Windows Event Logs
• Registry hives (Software, System, Security)
• NTUSER.DAT and USRCLASS.DAT from the two profiles of interest
• User WebCacheV01.DAT IE browser history files

The process I used to create my timeline is pretty much exactly what's listed in Windows Forensic Analysis 4/e, in ch. 7.  The process took only a couple of minutes to put together a timeline and begin analyzing it.  From the time I opened the image in FTK Imager, I had a timeline in less than 30 min. Also, something I really like about it is that the process can be used in such a manner that only those files required are sent to another analyst to construct a timeline.

The system did have Prefetch files but given the time frame, there were no files of interest in the Prefetch folder.

Once I created the timeline, I was able to easily add context to what I was looking at using other tools.  For example, I parsed the user's WebCacheV01.dat files initially using esedbexport.exe, and then using ESEDatabaseView.  An important take-away from this is data interpretation...entries have several time stamps associated with each visited URL, and the incorrect identification and interpretation of those time stamps can significantly impact your findings.  For example, the visited URL has an expiry date time stamp; assuming that this is when the site was last accessed can have a significant (and perhaps detrimental) impact on your overall analysis.

I took a look at IE session recovery files using the Structured Storage Viewer; I got what I needed out of the particular streams of interest, and added notes to my timeline.

Mapping the user's TypedURLs values with the TypedURLsTime values was pretty fascinating, although all it really did was support findings that didn't pertain directly to the malware.  Still...it was pretty cool.

User shellbags proved to be very illuminating, and the UserAssist information added additional context to what I was seeing.  In the case of one user profile, the combination of those two artifacts illustrated intentional, purposeful activity...the user navigated to a specific subfolder, and double-clicked a specific .exe file, launching it.  File system and Registry events following this activity indicated the execution of the application.

Hibernation File
It turned out that the system was a laptop, and had a hibernation file.  I extracted the file, and used Volatility 2.5 to convert it to raw format.  The "imageinfo" command told me that the hibernation file had been created on 13 Sept 2015,  a bit before the image was acquired.  I didn't expect to find anything of value from the memory image, but I ran a couple of commands (pslist, psxview) anyway.  Doing so essentially validated my suspicions, but better to do it than not.  Besides, I wasn't stopping my other analysis...the command prompt where I ran the commands simply went to the background, and I examined the output files when the commands completed.

The previous analysis had indicated that strings/IOCs associated with the malware had been found in the hibernation file.  I used strings.exe, and then the Volatility 'strings' command, and found that those strings were in free space.

Working with VSCs
A quick check of the image indicated that there were volume shadow copies (VSCs) available, which was great.  Most corporate systems I've dealt with for the past couple of years have had VSCs disabled for some reason, and here was one that didn't.  I ran vhdtool.exe to "convert" the image, which essentially added a footer to the file.  As my analysis system is Windows 10, I renamed the file to have the ".vhd" file extension.  I opened the Disk Management utility and attached the newly-created VHD, and used the following command to list the available VSCs:

vssadmin list shadows /for=g:

Interestingly, I basically followed the process laid out in this blog post.  The output of the vssadmin command showed me that there was a VSC that had been created on 13 Jul 2015, which was about a month prior to the malware being detected and quarantined by AV.  I linked the VSC to a folder on my analysis system, and added the contents of the folder to FTK Imager; however, this didn't give me the level of access I wanted, as I wanted to get, among other things, a copy of the $MFT from the VSC.

That's where Jimmy's blog post on mounting shadow volumes can into play.  Using vss.exe, I added the VSC in question to my analysis system as X:\, which appeared as a RAM image.  I then added the logical volume to FTK Imager, and was able to extract the $MFT, as well as other files.   By creating a timeline using files extracted from the VSC, I was able to create a bit more context around the

Conclusion
Creating the timeline in the manner that I did allowed me to get started on my analysis in fairly short order, identify what needed a closer look, and then add context and notes to the timeline.  I didn't have to wait for an automated tool to complete, and then trudge through a lot of data that didn't pertain to what I was trying to determine.  I admit, I had a bit of a leg up because of the initial analysis that had been conducted, but the process I used would have led me to the initial indicators pretty quickly.  Specifically, the use of eventmap.txt in parsing Windows Event Logs allows for a number of event records to be auto-tagged, and then easily searched for in the timeline.  Searching the timeline for the "[MalDetect]" tag would've taken me to the "Symantec Endpoint Protection Client" event ID 51 record that identified what would be my initial pivot point.

As it turns out, there were a number of "Symantec Endpoint Protection Client/51" events in the timeline, so an easy fix to that would have been to do something like this:

type events.txt | find "[MalDetect]" > av_events.txt

The above command runs through the events file and locates all malware detection events, putting them into a separate file.  From there, I could have run:

parse -f av_events.txt > av_tln.txt

This would give me a nano-timeline of just AV detection events, giving me a much smaller set of data to analyze, and on which I could pivot.  This would also pick up all malware detection events, for any such events mapped in the eventmap.txt file.

Accessing the shadow volume allowed me to collect copies of files that were not otherwise accessible, as well as get a look at the state of the system prior to the malware being removed.  In this case, the malware employed two persistence mechanisms, which meant that two copies of the malware existed on the system.  My initial timeline provided an indication of this, as immediately prior to the AV writing it's detection and quarantine message to the Windows Event Log, there were changes to two locations within the file system, and to one Registry key.  Accessing the shadow volume from a time when the malware existed on the system allowed me to confirm what I had suspected.  It only took a few minutes, and to be honest, it was worth time to close the loop on the speculation.

I should note that I exported the hibernation file from the shadow volume, but once I converted it to raw format, the "imageinfo" command showed me that it had the same "image date and time" as the one from the image.  Running "pslist" and "psxview" gave me the exact same information as running those commands on the original hibernation file.  I need to look into this more, but it seems that the hibernation file is not tracked in shadow volumes, although the $MFT is.