Approximating Program Execution via VSC Analysis with RegRipper
I recently listened to Ovie and Corey on the latest CyberSpeak podcast, and wanted to combine what I'd heard them discuss with respect to the latest release of RegRipper, and provide a technique for analysis that incorporates VSCs.
Now, one of the things we may run across during our analysis, if we create a timeline, is that we may have a Registry key that was modified in some way during a particular time window of interest. There are a number of Registry keys for which all we have available is a LastWrite time (which is analogous to a files last modification time) but we do not know what that modification entailed.
For example, some keys maintain a "most recently used" (MRU) list, and we know that whatever the most recent activity was (user accessed/viewed a file, etc.), we can be pretty sure that, in most cases, the activity we see is associated with the key's LastWrite time. However, we may see other keys that simply contain values and subkeys, with LastWrite times that occur during our window of interest. Examples of these keys include the Run key (in both the Software and NTUSER.DAT hives), the MUICache key, etc. We don't know, simply by looking at the contents of the key, what change may have occurred; was a value or subkey added or deleted?
So, given that we have an image of a Windows 7 (or Vista) system, which may have a number of VSCs available, how can we attempt to determine what that change may have been?
Well, the first thing you want to do is mount the image as a volume on your Windows 7 analysis system in a manner that allows you to access the VSCs within the image; perhaps the easiest way to do so is via the VHD method. Once you have the image mounted (let's call it V:\), you'll want to determine which VSCs are available using the vssadmin command:
You'll see a bunch of stuff go by, and you'll want to look for lines that look like this:
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8
A really easy way to cut through all of that stuff is to use the following command line:
Okay, so now you should have a list of VSCs from the image; for the sake of this example, let's say that you have VSCs numbered 23 through 30. How can we use this information to compare the values in, say, the Run key from the Software hive? We know that the 'soft_run.pl' plugin lets us output the contents of this key, but how can we easily retrieve information from the previous versions of the Software hive within the VSCs?
Let's create a batch file to automate this for us. A simple 'for' loop in a batch file looks like this:
If you put the above command in a batch file ('test.bat') and then run the batch file, you'll see the numbers 23 through 30 echo'd to the console. We can use variables in our batch file by substituting the first and last numbers with '%1' and '%2', respectively:
Okay, that's easy enough. Now, all we need to do is get RegRipper to parse this information for us. We can do that using the latest version (2.5) of RegRipper, and specifically rip.exe.
We would save this command into a batch file (name it "vsc_run.bat") in the same directory where we have rip.exe, and then run it using the following command line:
That's it. That's all it takes. And the cool thing is that we can save this batch file and use it again and again, or modify it in some way for future use. One way to modify it would be to output everything to a file, rather than just allowing everything to fly by at the console. To do that, simply add " >> output.txt" to the end of the command within the batch file. You can also add comments to the batch file, via normal batch file scripting techniques.
This is just another example of how we can use already-available tools and techniques to build better and more efficient analysis methodologies. Why sit around staring at your monitor when there are easy and efficient ways to extract the data that you need for analysis?
Here's another use for this technique; at the request of a member of LE, I recently modified the currently available 'ares.pl' plugin (for parsing Registry keys for the Ares P2P application) to parse out just specific information, which includes decoding the search terms typed in by the user. If a Windows 7 (or Vista) system was being examined, you could use this technique to see the change of of several of the values, including the user typing in search terms, over time. The key that maintains the search terms does not include an MRU value, so you can use this technique to easily parse out exactly what you're looking for, and rather than seeing "between these two dates, the user typed in 30 search terms", you could see the progression of the terms typed in over time, across the available VSCs.
Following that same technique, I've seen instances where administrators have "taken remediation actions" and "cleaned up" prior to systems being reported as compromised and acquired. Using the contents of the MUICache key (located in the USRCLASS.DAT hive on a Win7 system), I found that this little bundle of joy had been run on the system, but "cleaned up". Using this technique, I could narrow down when the application had been run, and then go into my timeline to see what else was going on around that time.
Note that this technique can be used to approximate the time of program execution on systems where application Prefetch files are not available, either because they were deleted, or because the system is a server (Win2003, Win2008) and doesn't have application prefetching enabled by default.
With that kind of pin-point, surgical accuracy, this kind of sounds like Sniper Forensics to me!
Now, one of the things we may run across during our analysis, if we create a timeline, is that we may have a Registry key that was modified in some way during a particular time window of interest. There are a number of Registry keys for which all we have available is a LastWrite time (which is analogous to a files last modification time) but we do not know what that modification entailed.
For example, some keys maintain a "most recently used" (MRU) list, and we know that whatever the most recent activity was (user accessed/viewed a file, etc.), we can be pretty sure that, in most cases, the activity we see is associated with the key's LastWrite time. However, we may see other keys that simply contain values and subkeys, with LastWrite times that occur during our window of interest. Examples of these keys include the Run key (in both the Software and NTUSER.DAT hives), the MUICache key, etc. We don't know, simply by looking at the contents of the key, what change may have occurred; was a value or subkey added or deleted?
So, given that we have an image of a Windows 7 (or Vista) system, which may have a number of VSCs available, how can we attempt to determine what that change may have been?
Well, the first thing you want to do is mount the image as a volume on your Windows 7 analysis system in a manner that allows you to access the VSCs within the image; perhaps the easiest way to do so is via the VHD method. Once you have the image mounted (let's call it V:\), you'll want to determine which VSCs are available using the vssadmin command:
vssadmin list shadows /for=v:\
You'll see a bunch of stuff go by, and you'll want to look for lines that look like this:
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8
A really easy way to cut through all of that stuff is to use the following command line:
vssadmin list shadows /for=v:\ | find "Shadow Copy Volume: \\?\GLOBALROOT"
Okay, so now you should have a list of VSCs from the image; for the sake of this example, let's say that you have VSCs numbered 23 through 30. How can we use this information to compare the values in, say, the Run key from the Software hive? We know that the 'soft_run.pl' plugin lets us output the contents of this key, but how can we easily retrieve information from the previous versions of the Software hive within the VSCs?
Let's create a batch file to automate this for us. A simple 'for' loop in a batch file looks like this:
for /L %%i IN (23,1,30) DO @echo %%i
If you put the above command in a batch file ('test.bat') and then run the batch file, you'll see the numbers 23 through 30 echo'd to the console. We can use variables in our batch file by substituting the first and last numbers with '%1' and '%2', respectively:
for /L %%i IN (%1,1,%2) DO @echo %%i
Okay, that's easy enough. Now, all we need to do is get RegRipper to parse this information for us. We can do that using the latest version (2.5) of RegRipper, and specifically rip.exe.
for /L %%i IN (%1,1,%2) DO rip.exe -r \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy%%i\Windows\system32\config\Software -p soft_run
We would save this command into a batch file (name it "vsc_run.bat") in the same directory where we have rip.exe, and then run it using the following command line:
vsc_run.bat 23 30
That's it. That's all it takes. And the cool thing is that we can save this batch file and use it again and again, or modify it in some way for future use. One way to modify it would be to output everything to a file, rather than just allowing everything to fly by at the console. To do that, simply add " >> output.txt" to the end of the command within the batch file. You can also add comments to the batch file, via normal batch file scripting techniques.
This is just another example of how we can use already-available tools and techniques to build better and more efficient analysis methodologies. Why sit around staring at your monitor when there are easy and efficient ways to extract the data that you need for analysis?
Here's another use for this technique; at the request of a member of LE, I recently modified the currently available 'ares.pl' plugin (for parsing Registry keys for the Ares P2P application) to parse out just specific information, which includes decoding the search terms typed in by the user. If a Windows 7 (or Vista) system was being examined, you could use this technique to see the change of of several of the values, including the user typing in search terms, over time. The key that maintains the search terms does not include an MRU value, so you can use this technique to easily parse out exactly what you're looking for, and rather than seeing "between these two dates, the user typed in 30 search terms", you could see the progression of the terms typed in over time, across the available VSCs.
Following that same technique, I've seen instances where administrators have "taken remediation actions" and "cleaned up" prior to systems being reported as compromised and acquired. Using the contents of the MUICache key (located in the USRCLASS.DAT hive on a Win7 system), I found that this little bundle of joy had been run on the system, but "cleaned up". Using this technique, I could narrow down when the application had been run, and then go into my timeline to see what else was going on around that time.
Note that this technique can be used to approximate the time of program execution on systems where application Prefetch files are not available, either because they were deleted, or because the system is a server (Win2003, Win2008) and doesn't have application prefetching enabled by default.
With that kind of pin-point, surgical accuracy, this kind of sounds like Sniper Forensics to me!