I received a new RegRipper plugin from Chakib today, rdpnla.pl. In short, the plugin checks the SecurityLayer value of the HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp key in order to determine if network level authentication is enabled or not.
So what?, you ask? Well, for one, this is a way to help prevent the Sticky Keys attack from succeeding. If you've found that a system had been subject to the attack and wanted to see if it would succeed, be sure to run this plugin.
This HowToGeek page has a graphical discussion of what some of the other settings look like for this key.
Thanks, Chakib!
Thursday, December 17, 2015
Wednesday, December 16, 2015
Working with Shadow Volumes
I had an opportunity recently to do some interesting work with Volume Shadow Copies within an image acquired from a Windows 7 system. In this instance, I got some great information from a specific VSC, and I wanted to go back and do some testing. Through exchanges with David Cowen, I got access to some tools and decided to share my findings.Goal
The goal of this analysis, after completing the analysis I originally intended to do with the image, was to see if the hibernation file (hiberfil.sys) existed as a "previous version" in a VSC.
My original analysis involved creating a timeline in order to develop a detailed understanding of a malware infection associated with a targeted threat group. The system had been infected over a year ago, and at one point late this past summer, the AV had quarantined the malware and "cleaned" the persistence mechanisms.
 |
| VSCs in FTK Imager |
I accessed the VSC of interest using the VHD method outlined here (note: this blog post contains the commands used). I still have a copy of vhdtool.exe (seems to no longer be available, possible replacement linked here), so I used the "convert" option to change the *.001 file to a VHD format; this operation essentially adds a footer to the image file. In order to attach the VHD via the Disk Management utility on my Win10 analysis system, I had to change the file extension from "*.001" to "*.vhd"; the file still opens just fine in FTK Imager.
Everything went fine using the vssadmin and mklink commands to access the VSC of interest, and I then added the resulting folder as an evidence item to FTK Imager (choosing 'contents of a folder'). I was able to extract the files I wanted at the time, but I did not that this method did not provide me with the necessary access to extract files such as the $MFT, etc. At the time, for the analysis I was doing, that was not an issue.
The issue came up later when I mentioned to Jamie Levy that I had Windows 7 system with VSCs available, and that the hibernation file within the image itself was not a useful source of information about the malware, because the malware had been quarantined about a month prior the hibernation file being created. Jamie said she was curious to see through testing if the hibernation file was covered by VSCs; that is, could I go back to the VSC of interest and retrieve/extract a previous version of hiberfil.sys?
VSS
Jimmy Weg has a good number of blog posts that address VSS; Jimmy's done a lot of great work and shared it. In fact, I initially used information from his 13 Jul 2012 blog post entitled Mounting Shadow Volumes to mount the VSC of interest as a RAM disk on my analysis system. At the time that I did this, I was simply interested in collecting a copy of the $MFT, which is why I was pursing it...at the time, I wasn't interested in comparing hibernation files.
After attaching the VHD and running the vssadmin command to enumerate VSCs from the newly-attached volume, I used the following command:
D:\Tools>vss x: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy16
This resulted in a RAM disk being added to my analysis system. I didn't see it in Explorer, nor in the Disk Management utility, but I could add it as a logical volume to FTK Imager.
Removing the drive was easy:
D:\Tools>vss x:
Drive X: removed
If you're interested in mounting multiple VSCs sequentially, take a look at Jimmy's blog posts and consider using Dan Mare's vss.exe.
Libvshadow
While chatting with David, he mentioned that the method used to access VSCs may have an effect on what I was seeing, or what I could access, and he suggested that I take a look at using libvshadow to access the VSCs.
Step 1: Get the tools..look for "...windows compiled version of libvshadow..."
Step 2: Install Dokan (I went with v.0.7.4, as David mentioned via chat that 0.7.something was the latest stable release)
Step 3: Run mmls to get the sector offset to the partition of interest
mmls -i raw -t dos z:\image.vhd
This gave me a sector offset of "0000002048" to the partition.
Step 4: Run vshadowinfo (not really necessary)
I'm including this step for completeness...vshadowinfo and vshadowmount require byte offsets, and 2048 x 512 = 1048576, so we will use 1048576 to designate the byte offset to the partition we're interested in:
vshadowinfo -o 1048576 z:\image.vhd
Step 5: Run vshadowmount
vshadowmount -o 1048576 -X allow_other z:\image.vhd x:
 |
| X:\ volume contents |
Note: After hitting "enter" following the above command line, the command prompt did not return; this is normal. Don't do anything...don't hit "ctrl-C" and do not close the command prompt. You can minimize it, but do not forget that it's there.
Step 6: Access VSS1 using FTK Imager
I opened FTK Imager and added VSS1 as an image file. It parsed and opened a little slower than a "normal" image would (the image itself is on a USB drive, and the VSC had to be parsed...). However, I now have access to the VSC as a raw/dd image. This VSC was created on 13 July 2015, and I can not only extract files that were quarantined on 13 Aug 2015, but I can also extract a previous version of the $MFT and other system files. I can even mount the contents of the VSC by choosing "File->Image Mounting..." via FTK Imager.
If you left the command prompt up in the background, you'll see stuff scrolling by...when you're done doing what you want to do with the VSC and have closed FTK Imager, or just removed the evidence item, bring the command prompt into focus and hit "Ctrl-C"; the prompt will return, and you'll no longer have an X:\ volume on your system.
Testing
I opted to use libvshadow to access the VSC and extract hiberfil.sys. I did that, and use Volatility to convert the file to a raw memory dump, and then ran the imageinfo command; even though the VSC that I'd "extracted" the file from had been created on 13 July 2015, the output of the imageinfo command said that the file had been created on 13 Sept 2015. I then hashed both hiberfil.sys files and got the exact same hash.
As such, using this method it appears that the hibernation file is not "tracked" or affected by the Volume Shadow Service; that is, you don't get previous versions of the file.
Addendum: After publishing this post, David Cowen pointed me to this MSDN page that discusses files excluded from VSCs. Checking the Registry key HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup on my analysis system, I see that the hibernation file is listed (as is the pagefile).
Addendum, 29 Dec: I had a chance recently to work with another Windows 7 image file, and found that it contained two difference files. I then used Arsenal Image Mounter to mount the image read-only, and was able to enumerate VSCs using vssadmin.
If you perform your own testing and find something different, I'd greatly appreciate knowing the process and tools you used.
Other Take-Aways
The research, testing, and most importantly, interaction with other analysts really demonstrates that there a number of methods available for accessing historical information on Windows systems that do not require dongles, and do not require the purchase of commercial applications. Also, you don't need to know Linux, or how to install and compile libraries. Using native Windows tools, you can access the contents of a VSC as you would any other folder, but with a couple of freely available tools, you can get even deeper access, to the point of accessing the $MFT within the shadow volume.
During my initial analysis (prior to the testing outlined here), I extracted a couple of specific files from the VSC and created a mini-timeline in order to add context to my original timeline, and develop a clearer picture. And it all took just a couple of minutes.
And it doesn't end there. David Cowen's been producing a series of blog posts on automating DFIR work, and he has a blog post that walks you through accessing VSCs within an acquired image programmatically, via Python. The final Python script that David makes available essentially accesses each VSC, searches across it for specific files, and collects information about those files.
Resources
VhdxTool - possible replacement to vhdtool (Note: I have not tried this tool)
Friday, December 11, 2015
New RR Plugin: Identities.pl
This past week, I read an interesting FireEye blog post that discussed malware that targets the volume boot record. As I read through the post, I got to step 4 ("Component Installation") for the malware, and the Registry values listed caught my eye. I know...go figure, right?
The blog post states that a number of values are created within a specific hive file, and that these values refer to the various components of the malware itself. As such, I looked at these values as a great way to determine if a system was infected, through either digital forensic analysis, or even active hunting within the enterprise.
The key path for the values listed in the blog post is "HKCU\.Default". Hhhmmm...okay, so...where is that hive on the system? As you can see in the figure to the right, taken via RegEdit on my Windows 10 system, the path should be listed as "HKU", which stands for "HKEY_USERS", rather than "HKCU", which stands for "HKEY_CURRENT_USER" (which would be me). Regardless, we see the ".Default" key in the figure. This MSDN blog post lets us know that it's not what we think...no, not at all. That is, this key is not for the "Default User", from which the new user profiles are created, but instead for the Local System account.
The RegRipper profilelist.pl plugin will show us the paths to the NTUSER.DAT hives for various accounts on the system, including not only the users but the other SIDs, as well:
Path : %systemroot%\system32\config\systemprofile
SID : S-1-5-18
LastWrite : Tue Jul 14 04:53:25 2009 (UTC)
Path : C:\Windows\ServiceProfiles\LocalService
SID : S-1-5-19
LastWrite : Thu Dec 30 20:51:42 2010 (UTC)
Path : C:\Windows\ServiceProfiles\NetworkService
SID : S-1-5-20
LastWrite : Thu Dec 30 20:51:42 2010 (UTC)
As such, you can extract the NTUSER.DAT file from any of these profiles, and run the identities.pl plugin (uploaded to the GitHub repository today) against it.
Addendum, 13 Dec: I added a plugin to the repository this morning called latentbot.pl that parses the persistence location for LatentBot (as reported by FireEye), and attempts to determine the plugins, as well. YMMV...extremely limited test suite.
The blog post states that a number of values are created within a specific hive file, and that these values refer to the various components of the malware itself. As such, I looked at these values as a great way to determine if a system was infected, through either digital forensic analysis, or even active hunting within the enterprise.
 |
The RegRipper profilelist.pl plugin will show us the paths to the NTUSER.DAT hives for various accounts on the system, including not only the users but the other SIDs, as well:
Path : %systemroot%\system32\config\systemprofile
SID : S-1-5-18
LastWrite : Tue Jul 14 04:53:25 2009 (UTC)
Path : C:\Windows\ServiceProfiles\LocalService
SID : S-1-5-19
LastWrite : Thu Dec 30 20:51:42 2010 (UTC)
Path : C:\Windows\ServiceProfiles\NetworkService
SID : S-1-5-20
LastWrite : Thu Dec 30 20:51:42 2010 (UTC)
As such, you can extract the NTUSER.DAT file from any of these profiles, and run the identities.pl plugin (uploaded to the GitHub repository today) against it.
Addendum, 13 Dec: I added a plugin to the repository this morning called latentbot.pl that parses the persistence location for LatentBot (as reported by FireEye), and attempts to determine the plugins, as well. YMMV...extremely limited test suite.
Saturday, December 05, 2015
WRF 2/e
Note: The OFFICIAL (re: ONLY) location of RegRipper is the GitHub repository. Do not send me emails about the Google Code site, or about the Wordpress page. Please stop referring to the Wordpress site, and please stop referring others (i.e., your students) to the site.
What I hoped to do with this edition is spend much less time focused on the basics of the Registry (where the files are located) and how to extract data from the Registry, and spend more time on data interpretation. I retained the basic material, as I think it's important to have that foundation before proceeding, but in chapters 3 and 4, I wanted to spend more real estate talking about how the available data needs to be interpreted correctly.
What it is
The second edition is a significant (albeit not complete) rewrite of the first edition. Some of the material remains the same because quite frankly, it doesn't change. There's some new stuff in there (new keys/values, AmCache.hve, etc.), and some stuff has been updated.
There is some discussion that includes new versions of Windows, and there are examples specific to Windows 8, 8.1, and 10.
In this edition, I separated various Registry artifacts by category, in hopes that it would be easier to follow, or visualize. We'll see...
Throughout the book, as with my other books, I've used examples of how Registry analysis has had a significant impact on the analysis I've done. Unfortunately, most of the stories are from analysis I've done. Prior to starting the book, I held an online contest to see if folks from the community would be willing to send in little stories and vignettes about how Registry analysis had impacted their analysis; I offered a free copy of the book, once it was published, for any and all submissions that appeared in the book. I got one submission.
There is more content in this book that discusses using RegRipper. In fact, there's an entire chapter just on RegRipper.
There is discussion of "new" plugins that I've written and added to the GitHub repository. In fact, here's a blog post that describes a couple of the ones I wrote and added to the repository; these plugins are meant to be run intentionally, and I did not add them to any of the profiles.
Speaking of new plugins, I'd like to ask that if you have a question about RegRipper, please do not post it to a forum first...because doing that makes it likely that you won't get an answer. Here's an example of a blog post where someone decided that RegRipper didn't do something, and instead of asking about it, just announced it. If there is something you'd like RegRipper to be capable of, please feel free to reach to me first...most times that results in RegRipper being able to do just that, usually within a few hours.
What it is NOT
This edition is NOT a complete compendium of all possible Registry keys and values that may be of interest to an analyst, in part because...quite simply...I don't know everything.
I did not address all devices that contain Windows Registry hives, for the simple reason that I could not...I do not have access to Windows phones or other devices that include hives. I do get those questions (i.e., "What about Registry files from ....?"), so I thought I'd just go ahead and answer them ahead of time.
As for the rest of the questions, like, "...did you cover this?", and "...did you talk about this?", you're SOL and missed your chance to get it included in the book, my friend...sorry.
What's next?
I've been thinking for some time now about a scanner, where I'd be able to point the tool at a mounted image or shadow volume, make a couple of simple choices, and have the tool spit out the data. I like the idea of basing this on artifact categories and an analysis matrix.
Resources
InfoSecInstitute - Registry Forensics
Wednesday, December 02, 2015
Links
NTFS Tools
A while back, David and his cohorts released NTFS TriForce, a great tool that allowed you to correlate several NTFS data sources...the MFT, $LogFile, and the USN change journal, using various data elements as "pivot points" to join tables within the database. The folks over at StrozFriedberg came out with their own version of a similar tool called NTFS-Linker.
Program Execution
Not 'new' (this one is from earlier this year), but Chad recommended that if you're looking for artifacts of program execution, you should consider taking a look at SuperFetch artifacts. This is another artifact to add to the category, given information such as can be found here.
Registry
The folks over at CodeReversing have an interesting post on "Stealth Techniques: Hiding Files in the Registry". This is not new...about 15 years ago, I developed a proof of concept tool that downloaded an executable file that had been renamed as a *.gif file, and parsed up the file into discrete sections, putting those sections in the Registry. The second half of the PoC re-assembled the file in the Recycle Bin and launched the executable.
Don't get me wrong...just because something isn't new doesn't mean that it's not relevant. I see that in pretty much ever targeted threat response engagement that I'm involved in, either directly or peripherally...the adversary or intruder uses some technique that are really very simple, so much so that it's overlooked; the Sleeper Agent blog post is a great example of that.
RegRipper
Reminder: The OFFICIAL (re: only) location of RegRipper is GitHub. Do not send me emails about the Google Code site, or about the Wordpress page.
Plugins
I caught something in the archives for one of the mailing lists I access...someone had reached to the list about the auditpol.pl plugin, saying that it wasn't working for them. Well, I hadn't touched that plugin since I wrote it, and it was intended for Windows XP and 2003 systems, due to the fact that those were the only systems on which I had documentation.
Well, someone responded with a link to a PDF document that illustrates how to parse the audit configuration for Vista+ systems. I renamed the current plugin to auditpol_xp.pl, and updated the auditpol.pl plugin to work for Windows 7 and 10 systems ONLY, because I don't have data from other systems available for testing.
Again, the new auditpol.pl plugin has only been tested against Windows 7 and Windows 10 systems, and only one Security hive from each platform. What it does is allow you to see the effective audit policy on the system, or the equivalent of running:
auditpol /get /category:*
Both plugins are in the Github repository; however, again, I do not maintain the RegRipper profiles, so as plugins are added to the repository, I am not updating the profiles to remain current based on the available plugins.
On Sharing
I'm a huge proponent for sharing; sharing information or intel, even just engaging and asking questions. I recently came across this article on sharing that just sort of reinforced my thoughts on the subject.
A while back, David and his cohorts released NTFS TriForce, a great tool that allowed you to correlate several NTFS data sources...the MFT, $LogFile, and the USN change journal, using various data elements as "pivot points" to join tables within the database. The folks over at StrozFriedberg came out with their own version of a similar tool called NTFS-Linker.
Program Execution
Not 'new' (this one is from earlier this year), but Chad recommended that if you're looking for artifacts of program execution, you should consider taking a look at SuperFetch artifacts. This is another artifact to add to the category, given information such as can be found here.
Registry
The folks over at CodeReversing have an interesting post on "Stealth Techniques: Hiding Files in the Registry". This is not new...about 15 years ago, I developed a proof of concept tool that downloaded an executable file that had been renamed as a *.gif file, and parsed up the file into discrete sections, putting those sections in the Registry. The second half of the PoC re-assembled the file in the Recycle Bin and launched the executable.
Don't get me wrong...just because something isn't new doesn't mean that it's not relevant. I see that in pretty much ever targeted threat response engagement that I'm involved in, either directly or peripherally...the adversary or intruder uses some technique that are really very simple, so much so that it's overlooked; the Sleeper Agent blog post is a great example of that.
RegRipper
Reminder: The OFFICIAL (re: only) location of RegRipper is GitHub. Do not send me emails about the Google Code site, or about the Wordpress page.
Plugins
I caught something in the archives for one of the mailing lists I access...someone had reached to the list about the auditpol.pl plugin, saying that it wasn't working for them. Well, I hadn't touched that plugin since I wrote it, and it was intended for Windows XP and 2003 systems, due to the fact that those were the only systems on which I had documentation.
Well, someone responded with a link to a PDF document that illustrates how to parse the audit configuration for Vista+ systems. I renamed the current plugin to auditpol_xp.pl, and updated the auditpol.pl plugin to work for Windows 7 and 10 systems ONLY, because I don't have data from other systems available for testing.
Again, the new auditpol.pl plugin has only been tested against Windows 7 and Windows 10 systems, and only one Security hive from each platform. What it does is allow you to see the effective audit policy on the system, or the equivalent of running:
auditpol /get /category:*
Both plugins are in the Github repository; however, again, I do not maintain the RegRipper profiles, so as plugins are added to the repository, I am not updating the profiles to remain current based on the available plugins.
On Sharing
I'm a huge proponent for sharing; sharing information or intel, even just engaging and asking questions. I recently came across this article on sharing that just sort of reinforced my thoughts on the subject.
Tuesday, December 01, 2015
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.
I conducted my analysis using Notepad++.
Timeline
I created a timeline of system activity using:
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.
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 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.