Timeline Analysis
I recently taught another iteration of our Timeline Analysis course, and as is very often the case, I learned somethings as a result.
First, the idea (in my case, thanks goes to Corey Harrell and Brett Shavers) of adding categories to timelines in order to increase the value of the timeline, as well as to bring a new level of efficiency to the analysis, is a very good one. I'll discuss categories a bit more later in this post.
Second (and thanks goes out to Cory Altheide for this one), I'm reminded that timeline analysis provides the examiner with context to the events being observed, as well as a relative confidence in the data. We get context because we see more than just a file being modified...we see other events around that event that provide indications as to what led to the file being modified. Also, we know that some data is easily mutable, so seeing other events that are perhaps less mutable occurring "near" the event in question gives us confidence that the data we're looking at is, in fact, accurate.
Another thing to consider is that timelines help us reduce complexity in our analysis. If we understand the nature of the artifacts and events that we observe in a timeline, and understand what creates or modifies those artifacts, we begin to see what is important in the timeline itself. There is no magic formula for creating timelines...we may have too little data in a timeline (i.e., just a file being modified) or we may have too much data. Knowing what various artifacts mean or indicate allows us to separate the wheat from the chaff, or separate what is important from the background noise on systems.
Categories
Adding category information to timelines can do a great deal to make analysis ssssooooo much easier! For example, when adding Prefetch file metadata to a timeline, identifying the time stamps as being related to "Program Execution" can do a great deal to make analysis easier, particularly when it's included along with other data that is in the same category. Also, as of Vista (and particularly so with Windows 7 and 2008 R2), there have been an increase in the number of event logs, and many of the event IDs that we're familiar with from Windows XP have changed. As such, being able to identify the category of an event source/ID pair, via a short descriptor, makes analysis quicker and easier.
One thing that is very evident to me is that many artifacts will have a primary, as well as a secondary (or even tertiary) category. For example, let's take a look at shortcut/LNK files. Shortcuts found in a user's Recents folder are created via a specific activity performed by the user...most often, by the user double-clicking a file via the shell. As such, the primary category that a shortcut file will belong to is something akin to "File Access", as the user actually accessed the file. While it may be difficult to keep the context of how the artifact is created/modified in your mind while scrolling through thousands of lines of data, it is oh so much easier to simply provide the category right there along with the data.
Now, take a look at what happens when a user double-clicks a file...that file is opened in a particular application, correct? As such, a secondary category for shortcut files (found in the user's Recents folder) might be "Program Execution". Now, the issue with this is that we would need to do some file association analysis to determine which application was used to open the file...we can't always assume that files ending in the ".txt" extension are going to be opened via Notepad. File association analysis is pretty easy to do, so it's well worth doing it.
Not all artifacts are created alike, even if they have the same file extension...that is to say, some artifacts may have to have categories based on their context or location. Consider shortcut files on the user's desktop...many times, these are either specifically created by the user, or are placed there as the result of the user installing an application. For those desktop shortcuts that point to applications, they do not so much refer to "File Access", as they do to "Application Installation", or something similar. After all, when applications are installed and create a shortcut on the desktop, that shortcut very often contains the command line "app.exe %1", and doesn't point to a .docx or .txt file that the user accessed or opened.
Adding categories to your timeline can bring a great deal of power to your fingertips, in addition to reducing the complexity and difficulty of finding the needle(s) in the hay stack...or stack of needles, as the case may be. However, this addition to timeline analysis is even more powerful when it's done with some thought and consideration given to the actual artifacts themselves. Our example of LNK files clearly shows that we cannot simply group all LNK files in one category. The power and flexibility to include categories for artifacts based on any number of conditions is provided in the Forensic Scanner.
RegRipper
Sorry that I didn't come up with a witty title for this section of the post, but I wanted to include something here. I caught up to SketchyMoose's blog recently and found this post that included a mention of RegRipper.
In the post, SM mentions a plugin named 'findexes.pl'. This is an interesting plugin that I created as a result of something Don Weber found during an exam when we were on the ...that the bad guy was hiding PE files (or portions thereof) in Registry values! That was pretty cool, so I wrote a plugin. See how that works? Don found it, shared the information, and then a plugin was created that could be run during other exams.
SM correctly states that the plugin is looking for "MZ" in the binary data, and says that it's looking for it at the beginning of the value. I know it says that in the comments at the top of the plugin file, but if you look at the code itself, you'll see that it runs a grep(), looking for 'MZ' anywhere in the data. As you can see from the blog post, the plugin not only lists the path to the value, but also the length of the binary data being examined...it's not likely that you're going to find executable code in 32 bytes of data, so it's good visual check for deciding which values you want to zero in on.
SM goes on to point out the results of the userinit.pl plugin...which is very interesting. Notice that in the output of that plugin, there's a little note that indicates what 'normal' should look like...this is a question I get a lot when I give presentations on Registry or Timeline Analysis...what is 'normal', or what about what I'm looking at jumps out at me as 'suspicious'. With this plugin, I've provided a little note that tells the analyst, hey, anything other than just "userinit.exe" is gonna be suspicious!
USB Stuff
SM also references a Hak5 episode by Chris Gerling, Jr, that discusses mapping USB storage devices found on Windows systems. I thought I'd reference that here, in order to say, "...there are more things in heaven and earth than are dreamt of in your philosophy, Horatio!" Okay, so what does quoting the Bard have to do with anything? In her discussion of her dissertation entitled, Pitfalls of Interpreting Forensic Artifacts in the Registry, Jacky Fox follows a similar process for identifying USB storage devices connected to a Windows system. However, the currently accepted process for doing this USB device identification has some...shortcomings...that I'll be addressing. Strictly speaking, the process works, and works very well. In fact, if you follow all the steps, you'll even be able to identify indications of USB thumb drives that the user may have tried to obfuscate or delete. However, this process does not identify all of the devices that are presented to the user as storage.
Please don't misunderstand me here...I'm not saying that either Chris or Jacky are wrong in the process that they use to identify USB storage devices. Again, they both refer to using regularly accepted examination processes. Chris refers to Windows Forensic Analysis 2/e, and Jacky has a lot of glowing and positive things to say about RegRipper in her dissertation (yes, I did read it...the whole thing...because that's how I roll!), and some of those resources are based on information that Rob Lee has developed and shared through SANS. However, as time and research have progressed, new artifacts have been identified and need to be incorporated into our analysis processes.
Propagation
I ran across this listing for Win32/Phorpiex on the MS MMPC blog, and it included something pretty interesting. This malware includes a propagation mechanism when using removable storage devices.
While this propagation mechanism seems pretty interesting, it's not nearly as interesting as it could be, because (as pointed out in the write up) when the user clicks on the shortcut for what they think is a folder, they don't actually see the folder opening. As such, someone might look for an update to this propagation mechanism in the near future, if one isn't already in the wild.
What's interesting to me is that there's no effort taken to look at the binary contents of the shortcut/LNK files to determine if there's anything odd or misleading about them. For example, most of the currently used tools only parse the LinkInfo block of the LNK file...not all tools parse the shell item ID list that comes before the LinkInfo block. MS has done a great job of documenting the binary specification for LNK files, but commercial tools haven't caught up.
In order to see where/how this is an issue, take a look at this CyanLab blog post.
Malware Infection Vectors
This blog post recently turned up on MMPC...I think that it's great because it illustrates how systems can be infected via drive-bys that exploit Java vulnerabilities. However, I also think that blog posts like this aren't finishing the race, as it were...they're start, get most of the way down the track, and then stop...they stop before they show what this exploit looks like on a system. Getting and sharing this information would serve two purposes...collect intelligence that they (MS) and others could use, and help get everyone else closer to conducting root cause analyses after an incident. I think that the primary reason that RCAs aren't being conducted is that most folks think that it takes too long or is too difficult. I'll admit...the further away from the actual incident that you detect a compromised or infected system, the harder it can be to determine the root cause or infection vector. However, understanding the root cause of an incident, and incorporating it back into your security processes, can go a long way toward helping you allocate resources toward protecting your assets, systems, and infrastructure.
If you want to see what this stuff might look like on a system, check out Corey's jIIr blog posts that are labeled "exploits". Corey does a great job of exploiting systems and illustrating what that looks like on a system.
Wednesday, November 21, 2012
Wednesday, November 07, 2012
PFIC2012 slides
Several folks at PFIC 2012 asked that I make my slides from the Windows 7 Forensic Analysis and Timeline Analysis presentations available...so here they are.
I'll have to admit, I've become somewhat hesitant to post slides, not because I don't want to share the info, but because posting the slides from my presentations doesn't share the info...most of the information that is shared during a presentation isn't covered in the slides.
I'll have to admit, I've become somewhat hesitant to post slides, not because I don't want to share the info, but because posting the slides from my presentations doesn't share the info...most of the information that is shared during a presentation isn't covered in the slides.
Wednesday, October 31, 2012
Shellbag Analysis, Revisited...Some Testing
I blogged previously on the topic of Shellbag Analysis, but I've found that in presenting on the topic and talking to others, there may be some misunderstanding of how these Registry artifacts may be helpful to an analyst. With Jamie's recent post on the Shellbags plugin for Volatility, I thought it would be a good idea to revisit this information, as sometimes repeated exposure is the best way to start developing an understanding of something. In addition, I wanted to do some testing in order to determine the nature of some of the metadata associated with shellbags.
In her post, Jamie states that the term "Shellbags" is commonly used within the community to indicate artifacts of user window preferences specific to Windows Explorer. MS KB 813711 indicates that the artifacts are created when a user repositions or resizes an Explorer windows.
ShellItem Metadata
As Jamie illustrates in her blog post, many of the structures that make up the SHELLITEMS (within the Shellbags) contain embedded time stamps, in DOSDate format. However, there's still some question as to what those values mean (even though the available documentation refers to them as MAC times for the resource in question) and how an analyst may make use of them during an examination.
Having some time available recently due to inclement weather, I thought I would conduct a couple of very simple tests in to begin to address these questions.
Testing Methodology
On a Windows 7 system, I performed a number of consecutive, atomic actions and recorded the system time (visible via the system clock) for when each action was performed. The following table lists the actions I took, and the time (in local time format) at which each action occurred.
The purpose of having some time pass between actions is so that they can be clearly differentiated in a timeline.
Once these steps were completed, I restarted the system, and once it came back up, I extracted the USRCLASS.DAT hive from the relevant user account into the D:\shellbag directory for analysis (at 1:42pm). I purposely chose this directory in order to determine how actions external to the shellbags artifacts affect the overall data seen.
Results
The following table lists the output from the shellbags.pl RegRipper plugin for the directories in question (all times are in UTC format):
Let's walk through these results. First, I should remind you that that MRU Time is populated from Registry key LastWrite times (FILETIME format, granularity of 100 ns) while the MAC times are embedded within the various shell items (used to reconstruct the paths) in DOSDate time format (granularity of 2 seconds).
First, we can see that the Created dates for both folders correspond approximately to when the folders were actually created. We can also see that the same thing is true for the Modified dates. Going back to the live system and typing "dir /tw d:\shell*" shows me that the last modification time for the directory is 1:42pm (local time), which corresponds to changes made to that directory after the USRCLASS.DAT hive file was extracted.
Next, we see that MRU Time values correspond approximately to when the D:\shellbag\test folder was opened and then resized/repositioned via the Explorer shell, and not to when the Explorer window was actually closed.
Based on this limited test, it would appear that the DOSDate time stamps embedded in the shell items for the folders correspond to the MAC times of that folder, within the file system, at the time that the shell items were created. In order to test this, I deleted the d:\shellbag\test\test.txt file at 2:14pm, local time, and then extracted a copy of the USRCLASS.DAT and parsed it the same way I had before...and saw no changes in the Modified times listed in the previous table.
In order to test this just a bit further, I opened Windows Explorer, navigated to the D:\shellbag folder, and repositioned/resized the window at 2:21pm (local time), waited 2 minutes, and closed the window. I extracted and parsed the USRCLASS.DAT hive again, and this time, the MRU Time for the D:\shellbag folder had changed to 18:21:48 (UTC format). Interestingly, that was the only time that had changed...the Modified time for the D:\shellbag\test folder remained the same, even though I had deleted the test.txt file from that directory at 2:14pm local time ("dir /tw d:\shellbag\te*" shows me that the last written time for that folder is, indeed, 2:14pm).
Summary
Further testing is clearly required; however, it would appear that based on this initial test, we can draw the following conclusions with respect to the shellbag artifacts on Windows 7:
1. The embedded DOSDate time stamps appear to correspond to the MAC times of the resource/folder at the time that the shell item was created. If the particular resource/folder was no longer present within the active file system, an analyst could use the Created date for that resource in a timeline.
2. Further testing needs to be performed in order to determine the relative value of the Modified date, particularly given that events external to the Windows Explorer shell (i.e., creating/deleting files and subfolders after the shell items have been created) may have limited effect on the embedded dates.
3. The MRU Time appears to correspond to when the folder was resized or repositioned. Analysts should keep in mind that (a) there are a number of ways to access a folder that do not require the user to reposition or resize the window, and (b) the MRU Time is a Registry key LastWrite time that only applies to one folder within the key...the Most Recently Used folder, or the one listed first in the MRUListEx value.
I hope that folks find this information useful. I also hope that others out there will look at this information, validate it through their own testing, and even use it as a starting point for their own research.
In her post, Jamie states that the term "Shellbags" is commonly used within the community to indicate artifacts of user window preferences specific to Windows Explorer. MS KB 813711 indicates that the artifacts are created when a user repositions or resizes an Explorer windows.
ShellItem Metadata
As Jamie illustrates in her blog post, many of the structures that make up the SHELLITEMS (within the Shellbags) contain embedded time stamps, in DOSDate format. However, there's still some question as to what those values mean (even though the available documentation refers to them as MAC times for the resource in question) and how an analyst may make use of them during an examination.
Having some time available recently due to inclement weather, I thought I would conduct a couple of very simple tests in to begin to address these questions.
Testing Methodology
On a Windows 7 system, I performed a number of consecutive, atomic actions and recorded the system time (visible via the system clock) for when each action was performed. The following table lists the actions I took, and the time (in local time format) at which each action occurred.
| Action | Time |
|---|---|
| Create a dir: mkdir d:\shellbag | 12:54pm |
| Create a file in the dir: echo "..." > d:\shellbag\test.txt | 1:03pm |
| Create another dir: mkdir d:\shellbag\test | 1:08pm |
| Create a file in the new dir: echo "..." > d:\shellbag\test\test.txt | 1:16pm |
| Delete a file: del d:\shellbag\test.txt | 1:24pm |
| Open D:\shellbag\test via Explorer, reposition/resize the window | 1:29pm |
| Close the Explorer window opened in the previous step | 1:38pm |
The purpose of having some time pass between actions is so that they can be clearly differentiated in a timeline.
Once these steps were completed, I restarted the system, and once it came back up, I extracted the USRCLASS.DAT hive from the relevant user account into the D:\shellbag directory for analysis (at 1:42pm). I purposely chose this directory in order to determine how actions external to the shellbags artifacts affect the overall data seen.
Results
The following table lists the output from the shellbags.pl RegRipper plugin for the directories in question (all times are in UTC format):
| Directory | MRU Time | Modified | Accessed | Created |
|---|---|---|---|---|
| Desktop\My Computer\D:\shellbag | 2012-10-29 17:29:25 | 2012-10-29 17:24:26 | 2012-10-29 17:24:26 | 2012-10-29 16:55:00 |
| Desktop\My Computer\D:\shellbag\test | 2012-10-29 17:29:29 | 2012-10-29 17:16:20 | 2012-10-29 17:16:20 | 2012-10-29 17:08:18 |
Let's walk through these results. First, I should remind you that that MRU Time is populated from Registry key LastWrite times (FILETIME format, granularity of 100 ns) while the MAC times are embedded within the various shell items (used to reconstruct the paths) in DOSDate time format (granularity of 2 seconds).
First, we can see that the Created dates for both folders correspond approximately to when the folders were actually created. We can also see that the same thing is true for the Modified dates. Going back to the live system and typing "dir /tw d:\shell*" shows me that the last modification time for the directory is 1:42pm (local time), which corresponds to changes made to that directory after the USRCLASS.DAT hive file was extracted.
Next, we see that MRU Time values correspond approximately to when the D:\shellbag\test folder was opened and then resized/repositioned via the Explorer shell, and not to when the Explorer window was actually closed.
Based on this limited test, it would appear that the DOSDate time stamps embedded in the shell items for the folders correspond to the MAC times of that folder, within the file system, at the time that the shell items were created. In order to test this, I deleted the d:\shellbag\test\test.txt file at 2:14pm, local time, and then extracted a copy of the USRCLASS.DAT and parsed it the same way I had before...and saw no changes in the Modified times listed in the previous table.
In order to test this just a bit further, I opened Windows Explorer, navigated to the D:\shellbag folder, and repositioned/resized the window at 2:21pm (local time), waited 2 minutes, and closed the window. I extracted and parsed the USRCLASS.DAT hive again, and this time, the MRU Time for the D:\shellbag folder had changed to 18:21:48 (UTC format). Interestingly, that was the only time that had changed...the Modified time for the D:\shellbag\test folder remained the same, even though I had deleted the test.txt file from that directory at 2:14pm local time ("dir /tw d:\shellbag\te*" shows me that the last written time for that folder is, indeed, 2:14pm).
Summary
Further testing is clearly required; however, it would appear that based on this initial test, we can draw the following conclusions with respect to the shellbag artifacts on Windows 7:
1. The embedded DOSDate time stamps appear to correspond to the MAC times of the resource/folder at the time that the shell item was created. If the particular resource/folder was no longer present within the active file system, an analyst could use the Created date for that resource in a timeline.
2. Further testing needs to be performed in order to determine the relative value of the Modified date, particularly given that events external to the Windows Explorer shell (i.e., creating/deleting files and subfolders after the shell items have been created) may have limited effect on the embedded dates.
3. The MRU Time appears to correspond to when the folder was resized or repositioned. Analysts should keep in mind that (a) there are a number of ways to access a folder that do not require the user to reposition or resize the window, and (b) the MRU Time is a Registry key LastWrite time that only applies to one folder within the key...the Most Recently Used folder, or the one listed first in the MRUListEx value.
I hope that folks find this information useful. I also hope that others out there will look at this information, validate it through their own testing, and even use it as a starting point for their own research.
Monday, October 29, 2012
Links
Being socked in by the weather, I thought it would be a good time to throw a couple of things out there...
Mounting an Image
Folks...in order to test or make use of the Forensic Scanner, you first need to have an image. If you don't have an image available, you can download sample images from a number of locations online. Or you can image your own system, or you can use virtual machine files (FTK Imager will mount a .vmdk file with no issues). However, the Forensic Scanner was not intended to be run against your local, live system.
Once you have an image to work with, you need to mount it as a volume in order to run the Forensic Scanner against it. If you have a raw/dd image, a .vmdk or .vhd file, or a .E0x file, FTK Imager will allow you to mount any of these in read-only format.
If you have a raw/dd format image file, you can use vhdtool to add a footer to the file, and then use the Disk Manager to attach the VHD file read-only. If you use this method, or if you mount your image file as VMWare virtual machine, you will also be able to list and mount available VSCs from within the image, and you can run the Scanner against each of those.
If you have any version of F-Response, you can mount a remote system as a volume, and run the Forensic Scanner against it. Don't take my word for it...see what Matt, the founder of F-Response, says about that!
If you have issues with accessing the contents of the mounted image...Ken Johnson recently tried to access a mounted image of a Windows 8 system from a Windows 7 analysis system...you may run into issues with permissions. After all, you're not accessing the image as a logical volume...so, you might try mounting the image as "File System/Read-Only", rather than the default "Block Device/Read-Only", or you may want to run the Scanner using something like RunAsSystem in order to elevate your privileges.
If your circumstances require it, you can even use FTK Imager (FTK Imager Lite v3.x is now available and supports image mounting) to access an acquired image, and then use the export function to export copies of all of the folders and files from the image to a folder on your analysis system, or on a USB external drive, and then run the scanner against that target.
Okay, but what about stuff other than Windows as your target? Say that you have an iDevice (or an image acquired from one...)...the Forensic Scanner can be updated (it's not part of the current download, folks) to work with these images, courtesy of HFSExplorer. Caveat: I haven't tested this yet, but from the very beginning, the Forensic Scanner was designed to be extensible in this manner.
Again, if you opt to run the Forensic Scanner against your local drive (by typing "C:\Windows\system32" into the tool), that's fine. However, I can tell you it's not going to work, so please don't email me telling me that it didn't work. ;-)
Forensic Scanner Links
Forensic Scanner Links - links where the Forensic Scanner is mentioned:
F-Response Blog: F-Response and the ASI Forensic Scanner
Grand Stream Dreams: Piles o' Linkage
SANS Forensics Blog: MiniFlame, Open Source Forensics Edition
Apparently, Kiran Vangaveti likes to post stuff that other people write...oh, well, I guess that imitation really is the sincerest form of flattery! ;-)
Observables
The good folks over at RSA have had some interesting posts of late to their "Speaking of Security" blog, and the most recent one by Branden Williams is no exception. In the post, Branden mentions "observables", as well as Locard's Exchange Principle...but what isn't explicitly stated is the power of correlating various events in order to develop situational awareness and context, something that we can do with timeline analysis.
An example of this might be a failed login attempt or a file modification. In and of themselves, these individual events tell us something, but very little. If we compile a timeline using the data sources that we have available, we can begin to see much more with regards to that individual event, and we go from, "...well, it might/could be..." to "...this is what happened."
SANS Forensic Summit 2013
The next SANS #DFIR Summit is scheduled for July 2013 (in Austin, TX) and the call for speakers is now open.
Prefetch Analysis
Adam posted recently regarding Prefetch file names and UNC paths, and that reminded me of my previous posts regarding Prefetch Analysis. The code I currently use for parsing Prefetch files includes parsing of paths that include "temp" anywhere in the path (via grep()), and provides those paths separately at the end of the output (if found). Parsing of UNC paths (any path that begins with two back slashes, or begins with "\Device") can also be included in that code. The idea is to let the computer extract and present those items that might be of particular interest, so that the analyst doesn't have to dig through multiple lines of code.
Mounting an Image
Folks...in order to test or make use of the Forensic Scanner, you first need to have an image. If you don't have an image available, you can download sample images from a number of locations online. Or you can image your own system, or you can use virtual machine files (FTK Imager will mount a .vmdk file with no issues). However, the Forensic Scanner was not intended to be run against your local, live system.
Once you have an image to work with, you need to mount it as a volume in order to run the Forensic Scanner against it. If you have a raw/dd image, a .vmdk or .vhd file, or a .E0x file, FTK Imager will allow you to mount any of these in read-only format.
If you have a raw/dd format image file, you can use vhdtool to add a footer to the file, and then use the Disk Manager to attach the VHD file read-only. If you use this method, or if you mount your image file as VMWare virtual machine, you will also be able to list and mount available VSCs from within the image, and you can run the Scanner against each of those.
If you have any version of F-Response, you can mount a remote system as a volume, and run the Forensic Scanner against it. Don't take my word for it...see what Matt, the founder of F-Response, says about that!
If you have issues with accessing the contents of the mounted image...Ken Johnson recently tried to access a mounted image of a Windows 8 system from a Windows 7 analysis system...you may run into issues with permissions. After all, you're not accessing the image as a logical volume...so, you might try mounting the image as "File System/Read-Only", rather than the default "Block Device/Read-Only", or you may want to run the Scanner using something like RunAsSystem in order to elevate your privileges.
If your circumstances require it, you can even use FTK Imager (FTK Imager Lite v3.x is now available and supports image mounting) to access an acquired image, and then use the export function to export copies of all of the folders and files from the image to a folder on your analysis system, or on a USB external drive, and then run the scanner against that target.
Okay, but what about stuff other than Windows as your target? Say that you have an iDevice (or an image acquired from one...)...the Forensic Scanner can be updated (it's not part of the current download, folks) to work with these images, courtesy of HFSExplorer. Caveat: I haven't tested this yet, but from the very beginning, the Forensic Scanner was designed to be extensible in this manner.
Again, if you opt to run the Forensic Scanner against your local drive (by typing "C:\Windows\system32" into the tool), that's fine. However, I can tell you it's not going to work, so please don't email me telling me that it didn't work. ;-)
Forensic Scanner Links
Forensic Scanner Links - links where the Forensic Scanner is mentioned:
F-Response Blog: F-Response and the ASI Forensic Scanner
Grand Stream Dreams: Piles o' Linkage
SANS Forensics Blog: MiniFlame, Open Source Forensics Edition
Apparently, Kiran Vangaveti likes to post stuff that other people write...oh, well, I guess that imitation really is the sincerest form of flattery! ;-)
Observables
The good folks over at RSA have had some interesting posts of late to their "Speaking of Security" blog, and the most recent one by Branden Williams is no exception. In the post, Branden mentions "observables", as well as Locard's Exchange Principle...but what isn't explicitly stated is the power of correlating various events in order to develop situational awareness and context, something that we can do with timeline analysis.
An example of this might be a failed login attempt or a file modification. In and of themselves, these individual events tell us something, but very little. If we compile a timeline using the data sources that we have available, we can begin to see much more with regards to that individual event, and we go from, "...well, it might/could be..." to "...this is what happened."
SANS Forensic Summit 2013
The next SANS #DFIR Summit is scheduled for July 2013 (in Austin, TX) and the call for speakers is now open.
Prefetch Analysis
Adam posted recently regarding Prefetch file names and UNC paths, and that reminded me of my previous posts regarding Prefetch Analysis. The code I currently use for parsing Prefetch files includes parsing of paths that include "temp" anywhere in the path (via grep()), and provides those paths separately at the end of the output (if found). Parsing of UNC paths (any path that begins with two back slashes, or begins with "\Device") can also be included in that code. The idea is to let the computer extract and present those items that might be of particular interest, so that the analyst doesn't have to dig through multiple lines of code.
Friday, October 19, 2012
DOSDate Time Stamps in Shell Items
Since this past spring, the term "shellbags" has been heard more and more often. Searching for "shellbag analysis" via Google reveals a number of very informative links. I'm going to gloss over the specifics of these links, but my doing so in no way minimizes any of the research, analysis and documentation by those who have contributed to the understanding of these Windows artifacts.
What I want to get to directly is the underlying data structures associated with the shellbags artifacts, specifically, the shell items and shell item ID lists, structures that Joachim Metz and others such as Kevin Moore have worked to identify and define. Again, mentioning the contributions made by these two individuals is in no way intended to take away from work performed by others in this area.
Shell items and shell item ID lists are used in a number of artifacts and data structures on Windows systems. Perhaps one of the most well known of those structures is the Windows shortcut/LNK files; you can see from the MS specification regarding the file format where the shell items exist within the structure. A number of Registry keys also use these data structures, including (but not limited to) Shellbags, ComDlg32, and MenuOrder.
Several of the data structures that make up the shell item ID lists include embedded data, to include time stamps. In many cases (albeit not all), these embedded time stamps are DOSDate format, which is a 32-bit time stamp with a granularity of two seconds.
Now, since a lot of the analysis that we do is often based heavily upon not simply that an event or action occurred, but when it occurred, often having additional sources of time stamped data can be extremely valuable to an analyst. However, there is much more to timeline analysis than simply having a time stamp from an artifact...the analyst must understand the context of that artifact with respect to the time stamp in question.
The question I would like to pose to the community is...what is the value of the embedded DOSDate time stamps within the shell items?
Let's first consider shellbags. The keys that store these artifacts are mentioned in MS KB 813711, so we have an idea of how these artifacts are created. In short, it appears that the shellbags artifacts are created (or modified) when a user accesses a folder via the Windows Explorer shell, and then repositions or resizes the window that appears on the desktop. So let's say that I open Windows Explorer, navigate to the "C:\Windows\Temp" directory, and resize the window. I would then expect to find indications of the path in the shellbags artifacts. At this point, we would expect that the time stamps embedded within the shellbags artifacts (and keep in mind, more testing is required in order to verify this...) refer to the MAC times from the "Windows" and "Temp" folders at the time that the artifact was created.
If we can agree on this, even for the moment, can we then also agree that other activities outside of those that create or modify the shellbags artifacts will also act upon the MAC times for those folders? For example, adding or deleting files or subfolders, or any other action that causes those folders to be modified will cause the last modified ("M") date to be...well...modified.
On Vista systems and above, the updating of last access times for file system objects has been disabled by default. Even if it weren't, other actions and events not associated with the shellbags artifacts (AV scans, user activity, normal system activity, etc.) would also cause these times to be modified.
The same thing could be said for the ComDlg32 artifacts. On Vista systems and above, several of the subkeys beneath the ComDlg32 key in the user's NTUSER.DAT hive contain values that are consistent with shell items, and are parsed in a similar manner. The data structures that describe the files and folders in these shell items contain embedded DOSDate time stamps, but as with the shellbags, these artifacts can be affected by other actions and events that occur outside of the scope of the ComDlg32 key.
Given this, I would like to reiterate my question: what is the value of the "M" and "A" DOSDate time stamps embedded within shell item data structures? The "C" time is defined as the creation date, and even with a 2 second granularity, I can see how this time stamp can be of value, particularly if (a) the described resource no longer exists on the system, or (b) the described resource is on remote or removable storage media. However, I would think that adding the "M" and "A" times for a resource to a timeline could potentially add considerable noise and confusion, particularly if the nature and context of the information is not completely understood. In fact, simply having so many artifacts that are not easily understood can have a significant detrimental impact on analysis.
What are your thoughts?
What I want to get to directly is the underlying data structures associated with the shellbags artifacts, specifically, the shell items and shell item ID lists, structures that Joachim Metz and others such as Kevin Moore have worked to identify and define. Again, mentioning the contributions made by these two individuals is in no way intended to take away from work performed by others in this area.
Shell items and shell item ID lists are used in a number of artifacts and data structures on Windows systems. Perhaps one of the most well known of those structures is the Windows shortcut/LNK files; you can see from the MS specification regarding the file format where the shell items exist within the structure. A number of Registry keys also use these data structures, including (but not limited to) Shellbags, ComDlg32, and MenuOrder.
Several of the data structures that make up the shell item ID lists include embedded data, to include time stamps. In many cases (albeit not all), these embedded time stamps are DOSDate format, which is a 32-bit time stamp with a granularity of two seconds.
Now, since a lot of the analysis that we do is often based heavily upon not simply that an event or action occurred, but when it occurred, often having additional sources of time stamped data can be extremely valuable to an analyst. However, there is much more to timeline analysis than simply having a time stamp from an artifact...the analyst must understand the context of that artifact with respect to the time stamp in question.
The question I would like to pose to the community is...what is the value of the embedded DOSDate time stamps within the shell items?
Let's first consider shellbags. The keys that store these artifacts are mentioned in MS KB 813711, so we have an idea of how these artifacts are created. In short, it appears that the shellbags artifacts are created (or modified) when a user accesses a folder via the Windows Explorer shell, and then repositions or resizes the window that appears on the desktop. So let's say that I open Windows Explorer, navigate to the "C:\Windows\Temp" directory, and resize the window. I would then expect to find indications of the path in the shellbags artifacts. At this point, we would expect that the time stamps embedded within the shellbags artifacts (and keep in mind, more testing is required in order to verify this...) refer to the MAC times from the "Windows" and "Temp" folders at the time that the artifact was created.
If we can agree on this, even for the moment, can we then also agree that other activities outside of those that create or modify the shellbags artifacts will also act upon the MAC times for those folders? For example, adding or deleting files or subfolders, or any other action that causes those folders to be modified will cause the last modified ("M") date to be...well...modified.
On Vista systems and above, the updating of last access times for file system objects has been disabled by default. Even if it weren't, other actions and events not associated with the shellbags artifacts (AV scans, user activity, normal system activity, etc.) would also cause these times to be modified.
The same thing could be said for the ComDlg32 artifacts. On Vista systems and above, several of the subkeys beneath the ComDlg32 key in the user's NTUSER.DAT hive contain values that are consistent with shell items, and are parsed in a similar manner. The data structures that describe the files and folders in these shell items contain embedded DOSDate time stamps, but as with the shellbags, these artifacts can be affected by other actions and events that occur outside of the scope of the ComDlg32 key.
Given this, I would like to reiterate my question: what is the value of the "M" and "A" DOSDate time stamps embedded within shell item data structures? The "C" time is defined as the creation date, and even with a 2 second granularity, I can see how this time stamp can be of value, particularly if (a) the described resource no longer exists on the system, or (b) the described resource is on remote or removable storage media. However, I would think that adding the "M" and "A" times for a resource to a timeline could potentially add considerable noise and confusion, particularly if the nature and context of the information is not completely understood. In fact, simply having so many artifacts that are not easily understood can have a significant detrimental impact on analysis.
What are your thoughts?
Thursday, October 18, 2012
Motivations behind the Forensic Scanner
At the recent OSDFC, I presented on and announced the release of the Forensic Scanner.
Since then, I've been asked to talk about things like the motivations behind the development of the Scanner, and what need I was trying to fill by creating it. At the conference, shortly after my presentation, it was suggested to me that I should talk about what's different about the Scanner, how it's different from the other available frameworks, such as Autopsy and DFF.
One of the reasons I wrote the Scanner (and this applies to RegRipper, as well) is that over the years of performing analysis, I've found that as I've maintained a checklist of things to "look for" during an exam, that checklist has grown, become a spreadsheet, and continued to grow...but no matter how well-organized the spreadsheet is, it's still a spreadsheet and doesn't help me perform those checks faster. If I have preconditions (something else that needs to be checked first) listed in the spreadsheet for a specific check, I have to go back into the image, do the initial check, and then see if the conditions have been met to perform the check I have listed in that row in the spreadsheet.
One good example of this is the ACMru Registry key in Windows XP. This key can exist within the user's NTUSER.DAT hive, and illustrates what the user searched for on the system. With Windows Vista, indications of the user's searches were moved out of the Registry, and with Windows 7, they were added back into the Registry, into the WordWheelQuery key. So, if you wanted to see what a user had searched for, you had to first check the version of the Windows operating system (the "precondition"), and then refer to the checklist and follow the appropriate path to the Registry key for that particular platform.
All of this can be hard to remember over time, and this is true not only for someone who performs a good deal of research into the Windows Registry. Imagine what this would be like for someone who doesn't spend a great deal of time analyzing Windows systems in general. The fact is that even with an extensive checklist or spreadsheet, this still requires a good deal of time and effort to maintain, as well as to engage. After all, you can't just lay a spreadsheet over your acquired image and have all the answers pop up...yet, anyway. An analyst has to actually sit down with the checklist and the acquired image and do something.
The plugins used by the Forensic Scanner, like those used by RegRipper, can be as simple as you want them to be. For example, with RegRipper, you may not want to look for specific values in the the Run key, because malware names and paths can change. As such, you may want to dump all of the values in order to present them to the analyst. You can also perform a modicum of analysis by grepping for terms such as "temp", to find any executables being launched from a temp directory (i.e., "Local Settings\Temp", or "Temporary Internet Files", etc.). The plugins used by the Forensic Scanner can do something very similar. For example, remember the ntshrui.dll issue? You can write a plugin that specifically checks for a file with that name in the Windows directory, or you can write a plugin that dumps a list of all of the DLLs in the Windows directory, and either apply a whitelist ("these are the known good files"), or a blacklist.
Note: The above paragraph is intended as an example, and does not indicate that current RegRipper plugins will work with the Forensic Scanner. They won't. A small amount of work is necessary to get the current RegRipper plugins to work with the Forensic Scanner.
Here's another good example...ever seen these blog posts? Do they make sense? How would you check for this? Well, I'd start with a plugin that parses the shell item ID lists of all of the LNK files on the user Desktop, and compares those elements to the ASCII in the LinkInfo block, if there is one. You could then extend this to the Recents folder, and because it's all automated, it will be done the same way, every time, no matter how many user profiles are on the system.
A final example...Corey Harrell reached to me a bit ago, asking me to create a plugin for a couple of Registry keys (discussed here, in an MS KB article). I did some looking around and found this valuable blog post on the topic of those keys. The Order values beneath the subkeys in question contain shell item ID lists, much like the values found in the ShellBags, as well as ComDlg32 entries. The linked blog post explains that the Order values often contain references to items the user explicitly selected, even after the application or resource has been deleted. As such, why not include this in every scan you run...who knows when something of critical value to your examination is going to pop-up? Most of us are aware that the one time we don't check these Registry keys will be the time that critical information is found to reside within the keys. So...write the plugin once, and run it with every scan, automatically; if you don't need it, ignore it. However, if you do need the information, it's right there.
One of the motivations for this sort of automation is to bridge a critical gap and get more organizations to perform root cause analysis, so that they can develop the necessary intelligence they need to properly defend themselves. Right now, many organizations will react to an apparent compromise or infection by wiping the system in question, and trying to address all of the vulnerabilities that are out there..that is, if they do anything at all. However, if they performed a root cause analysis, and determined the initial vector of compromise or infection, they could provide an intelligence-driven defense, reducing and optimizing their resources. One of the reasons for this sort of reaction may be performing a root cause analysis takes too long...the Forensic Scanner does not obviate analysis; rather, it is intended to get you there faster.
I understand that the idea of the Forensic Scanner is outside what most would consider "normal" thinking within the community. This is also true for RegRipper, as well as Timeline Analysis. The idea is not to obviate the need for analysis...rather, it's to get analysts to the actual analysis faster. After all, tools like RegRipper and now the Forensic Scanner will extract in seconds what currently takes an analyst hours or even days to do.
NOTE: In order to run the Scanner, you'll want to either disable UAC on your Windows 7 analysis system, or right-click on the program icon and choose "Run as administrator".
Finally, it appears that the Forensic Scanner is already making it's rounds at least one conference. Also, the Forensic Scanner was designed to work with F-Response, and Matt Shannon has a blog post indicating that F-Response + Forensic Scanner = Awesome!
Since then, I've been asked to talk about things like the motivations behind the development of the Scanner, and what need I was trying to fill by creating it. At the conference, shortly after my presentation, it was suggested to me that I should talk about what's different about the Scanner, how it's different from the other available frameworks, such as Autopsy and DFF.
One of the reasons I wrote the Scanner (and this applies to RegRipper, as well) is that over the years of performing analysis, I've found that as I've maintained a checklist of things to "look for" during an exam, that checklist has grown, become a spreadsheet, and continued to grow...but no matter how well-organized the spreadsheet is, it's still a spreadsheet and doesn't help me perform those checks faster. If I have preconditions (something else that needs to be checked first) listed in the spreadsheet for a specific check, I have to go back into the image, do the initial check, and then see if the conditions have been met to perform the check I have listed in that row in the spreadsheet.
One good example of this is the ACMru Registry key in Windows XP. This key can exist within the user's NTUSER.DAT hive, and illustrates what the user searched for on the system. With Windows Vista, indications of the user's searches were moved out of the Registry, and with Windows 7, they were added back into the Registry, into the WordWheelQuery key. So, if you wanted to see what a user had searched for, you had to first check the version of the Windows operating system (the "precondition"), and then refer to the checklist and follow the appropriate path to the Registry key for that particular platform.
All of this can be hard to remember over time, and this is true not only for someone who performs a good deal of research into the Windows Registry. Imagine what this would be like for someone who doesn't spend a great deal of time analyzing Windows systems in general. The fact is that even with an extensive checklist or spreadsheet, this still requires a good deal of time and effort to maintain, as well as to engage. After all, you can't just lay a spreadsheet over your acquired image and have all the answers pop up...yet, anyway. An analyst has to actually sit down with the checklist and the acquired image and do something.
The plugins used by the Forensic Scanner, like those used by RegRipper, can be as simple as you want them to be. For example, with RegRipper, you may not want to look for specific values in the the Run key, because malware names and paths can change. As such, you may want to dump all of the values in order to present them to the analyst. You can also perform a modicum of analysis by grepping for terms such as "temp", to find any executables being launched from a temp directory (i.e., "Local Settings\Temp", or "Temporary Internet Files", etc.). The plugins used by the Forensic Scanner can do something very similar. For example, remember the ntshrui.dll issue? You can write a plugin that specifically checks for a file with that name in the Windows directory, or you can write a plugin that dumps a list of all of the DLLs in the Windows directory, and either apply a whitelist ("these are the known good files"), or a blacklist.
Note: The above paragraph is intended as an example, and does not indicate that current RegRipper plugins will work with the Forensic Scanner. They won't. A small amount of work is necessary to get the current RegRipper plugins to work with the Forensic Scanner.
Here's another good example...ever seen these blog posts? Do they make sense? How would you check for this? Well, I'd start with a plugin that parses the shell item ID lists of all of the LNK files on the user Desktop, and compares those elements to the ASCII in the LinkInfo block, if there is one. You could then extend this to the Recents folder, and because it's all automated, it will be done the same way, every time, no matter how many user profiles are on the system.
A final example...Corey Harrell reached to me a bit ago, asking me to create a plugin for a couple of Registry keys (discussed here, in an MS KB article). I did some looking around and found this valuable blog post on the topic of those keys. The Order values beneath the subkeys in question contain shell item ID lists, much like the values found in the ShellBags, as well as ComDlg32 entries. The linked blog post explains that the Order values often contain references to items the user explicitly selected, even after the application or resource has been deleted. As such, why not include this in every scan you run...who knows when something of critical value to your examination is going to pop-up? Most of us are aware that the one time we don't check these Registry keys will be the time that critical information is found to reside within the keys. So...write the plugin once, and run it with every scan, automatically; if you don't need it, ignore it. However, if you do need the information, it's right there.
One of the motivations for this sort of automation is to bridge a critical gap and get more organizations to perform root cause analysis, so that they can develop the necessary intelligence they need to properly defend themselves. Right now, many organizations will react to an apparent compromise or infection by wiping the system in question, and trying to address all of the vulnerabilities that are out there..that is, if they do anything at all. However, if they performed a root cause analysis, and determined the initial vector of compromise or infection, they could provide an intelligence-driven defense, reducing and optimizing their resources. One of the reasons for this sort of reaction may be performing a root cause analysis takes too long...the Forensic Scanner does not obviate analysis; rather, it is intended to get you there faster.
I understand that the idea of the Forensic Scanner is outside what most would consider "normal" thinking within the community. This is also true for RegRipper, as well as Timeline Analysis. The idea is not to obviate the need for analysis...rather, it's to get analysts to the actual analysis faster. After all, tools like RegRipper and now the Forensic Scanner will extract in seconds what currently takes an analyst hours or even days to do.
NOTE: In order to run the Scanner, you'll want to either disable UAC on your Windows 7 analysis system, or right-click on the program icon and choose "Run as administrator".
Finally, it appears that the Forensic Scanner is already making it's rounds at least one conference. Also, the Forensic Scanner was designed to work with F-Response, and Matt Shannon has a blog post indicating that F-Response + Forensic Scanner = Awesome!
Wednesday, October 03, 2012
Forensic Scanner
I've posted regarding my thoughts on a Forensic Scanner before, and just today, I gave a short presentation at the #OSDFC conference on the subject.
Rather than describing the scanner, this time around, I released it. The archive contains the Perl source code, a 'compiled' executable that you can run on Windows without installing Perl, a directory of plugins, and PDF document describing how to use the tool. I've also started populating the wiki with information about the tool, and how it's used.
Some of the feedback I received on the presentation was pretty positive. I did chat with Simson Garfinkel for a few minutes after the presentation, and he had some interesting thoughts to share. The second was on making the Forensic Scanner thread-safe, so it can be multi-threaded and use multiple cores. That might make it on to the "To-Do" list, but it was Simson's first thought that I wanted to address. He suggested that at a conference were the theme seemed to revolve around analysis frameworks, I should point out the differences between the other frameworks and what I was presenting on, so I wanted to take a moment to do that.
Brian presented on Autopsy 3.0, and along with another presentation in the morning, discussed some of the features of the framework. There was the discussion of pipelines, and having modules to perform specific functions, etc. It's an excellent framework that has the capability of performing functions such as parsing Registry hives (utilizing RegRipper), carving files from unallocated space, etc. For more details, please see the web site.
I should note that there are other open source frameworks available, as well, such as DFF.
The Forensic Scanner is...different. Neither better, nor worse...because it addresses a different problem. For example, you wouldn't use the Forensic Scanner to run a keyword search or carve unallocated space. The scanner is intended for quickly automating repetitive tasks of data collection, with some ability to either point the analyst in a particular direction, or perform a modicum of analysis along with the data presentation (depending upon how much effort you want to put into writing the plugins). So, rather than providing an open framework which an analyst can use to perform various analysis functions, the Scanner allows the analyst to perform discrete, repetitive tasks.
The idea behind the scanner is this...there're things we do all the time when we first initiate our analysis. One is to collect simple information from the system...it's a Windows system, which version of Windows is it, it's time zone settings, is it 32- or 64-bit, etc. We collect this information because it can significantly impact our analysis. However, keeping track of all of these things can be difficult. For example, if you're looking at an image acquired from a Windows system and don't see Prefetch files, what's your first thought? Do you check the version of Windows you're examining? Do you check the Registry values that apply to and control the system's prefetching capabilities? I've talked with examiners who's first thought is that the user must have deleted the Prefetch files...but how do you know?
Rather than maintaining extensive checklists of all of these artifacts, why not simply write a plugin to collect what data it is that you want to collect, and possibly add a modicum of analysis into that plugin? One analyst writes the plugin, shares it, and anyone with that plugin will have access to the functionality without having to have had the same experiences as the analyst. You share it with all of your analysts, and they all have the capability at their fingertips. Most analysts recognize the value of the Prefetch files, but some may not work with Windows systems all of the time, and may not stay up on the "latest and greatest" in analysis techniques that can be applied to those files. So, let's say that instead of dumping all of the module paths embedded in Prefetch files, you add some logic to search for .exe files, .dat files, and any file that includes "temp" in the path, and display that information? Or, why not create whitelists of modules over time, and have the plugin show you all modules not in that whitelist?
Something that I and others have found useful is that, instead of forcing the analyst to use "profiles", as with the current version of RegRipper, the Forensic Scanner runs plugins automatically based on OS type, class, and then organizes the plugin results by category. What this means is that for the system class of plugins, all of the plugins that pertain to "Program Execution" will be grouped together; this holds true for other plugin categories, as well. This way, you don't have to go searching around for the information in which you're interested.
As I stated more than once in the presentation, the Scanner is not intended to replace analysis; rather, it's intended to get you to the point of performing analysis much sooner. For example, I illustrated a plugin that parses a user's IE index.dat file. Under normal circumstances when performing analysis, you'd have to determine which version of Windows you were examining, determine the path to the particular index.dat file that you're interested in, and then extract it and parse it. The plugin is capable of doing all of that...in the test case, all of the plugins I ran against a mounted volume completed in under 2 seconds...that's scans of the system, as well as both of the selected user profiles.
So...please feel free to try the Scanner. If you have any questions, you know where to reach me. Just know that this is a work-in-progress, with room for growth.
Addendum
Matt Presser identified an issue that the Scanner has with identifying user profiles that contain a dot. I fixed the issue and will be releasing an update once I make a couple of minor updates to other parts of the code.
Rather than describing the scanner, this time around, I released it. The archive contains the Perl source code, a 'compiled' executable that you can run on Windows without installing Perl, a directory of plugins, and PDF document describing how to use the tool. I've also started populating the wiki with information about the tool, and how it's used.
Some of the feedback I received on the presentation was pretty positive. I did chat with Simson Garfinkel for a few minutes after the presentation, and he had some interesting thoughts to share. The second was on making the Forensic Scanner thread-safe, so it can be multi-threaded and use multiple cores. That might make it on to the "To-Do" list, but it was Simson's first thought that I wanted to address. He suggested that at a conference were the theme seemed to revolve around analysis frameworks, I should point out the differences between the other frameworks and what I was presenting on, so I wanted to take a moment to do that.
Brian presented on Autopsy 3.0, and along with another presentation in the morning, discussed some of the features of the framework. There was the discussion of pipelines, and having modules to perform specific functions, etc. It's an excellent framework that has the capability of performing functions such as parsing Registry hives (utilizing RegRipper), carving files from unallocated space, etc. For more details, please see the web site.
I should note that there are other open source frameworks available, as well, such as DFF.
The Forensic Scanner is...different. Neither better, nor worse...because it addresses a different problem. For example, you wouldn't use the Forensic Scanner to run a keyword search or carve unallocated space. The scanner is intended for quickly automating repetitive tasks of data collection, with some ability to either point the analyst in a particular direction, or perform a modicum of analysis along with the data presentation (depending upon how much effort you want to put into writing the plugins). So, rather than providing an open framework which an analyst can use to perform various analysis functions, the Scanner allows the analyst to perform discrete, repetitive tasks.
The idea behind the scanner is this...there're things we do all the time when we first initiate our analysis. One is to collect simple information from the system...it's a Windows system, which version of Windows is it, it's time zone settings, is it 32- or 64-bit, etc. We collect this information because it can significantly impact our analysis. However, keeping track of all of these things can be difficult. For example, if you're looking at an image acquired from a Windows system and don't see Prefetch files, what's your first thought? Do you check the version of Windows you're examining? Do you check the Registry values that apply to and control the system's prefetching capabilities? I've talked with examiners who's first thought is that the user must have deleted the Prefetch files...but how do you know?
Rather than maintaining extensive checklists of all of these artifacts, why not simply write a plugin to collect what data it is that you want to collect, and possibly add a modicum of analysis into that plugin? One analyst writes the plugin, shares it, and anyone with that plugin will have access to the functionality without having to have had the same experiences as the analyst. You share it with all of your analysts, and they all have the capability at their fingertips. Most analysts recognize the value of the Prefetch files, but some may not work with Windows systems all of the time, and may not stay up on the "latest and greatest" in analysis techniques that can be applied to those files. So, let's say that instead of dumping all of the module paths embedded in Prefetch files, you add some logic to search for .exe files, .dat files, and any file that includes "temp" in the path, and display that information? Or, why not create whitelists of modules over time, and have the plugin show you all modules not in that whitelist?
Something that I and others have found useful is that, instead of forcing the analyst to use "profiles", as with the current version of RegRipper, the Forensic Scanner runs plugins automatically based on OS type, class, and then organizes the plugin results by category. What this means is that for the system class of plugins, all of the plugins that pertain to "Program Execution" will be grouped together; this holds true for other plugin categories, as well. This way, you don't have to go searching around for the information in which you're interested.
As I stated more than once in the presentation, the Scanner is not intended to replace analysis; rather, it's intended to get you to the point of performing analysis much sooner. For example, I illustrated a plugin that parses a user's IE index.dat file. Under normal circumstances when performing analysis, you'd have to determine which version of Windows you were examining, determine the path to the particular index.dat file that you're interested in, and then extract it and parse it. The plugin is capable of doing all of that...in the test case, all of the plugins I ran against a mounted volume completed in under 2 seconds...that's scans of the system, as well as both of the selected user profiles.
So...please feel free to try the Scanner. If you have any questions, you know where to reach me. Just know that this is a work-in-progress, with room for growth.
Addendum
Matt Presser identified an issue that the Scanner has with identifying user profiles that contain a dot. I fixed the issue and will be releasing an update once I make a couple of minor updates to other parts of the code.
Tuesday, September 18, 2012
Network Artifacts found in the Registry
My Twitter account lit up with the "#HTCIACON" hash tag this passed Monday morning, apparently due to the HTCIA Conference. I was seeing a lot of tweets from HBGary, etc., so I went by the conference web page and took a look at the agenda. As you can imagine, anything with the word "Registry" in it catches my eye immediately, and I saw that there was a lab that had to do with "network artifacts in the Registry". I took a look at the abstract for the lab, and it seemed to focus on the NetworkList key in the Vista+ Registry...that's great for showing wired and wireless networks that a system has connected to, as well as providing some useful information that can be used in WiFi geolocation (discussed here, updated tool named "macl.pl" is here).
This is a great start, but what about after the system is connected to particular networking media? What other "network artifacts" can be found in the Registry? That's where we can dig into additional sources of information, specifically other Registry keys and values, to look for those additional network artifacts.
Something else to think about is, what if some of the artifacts that you're pursuing have been deleted? Some tools (CCleaner, etc.) will "erase" lists of known artifacts. Some tools, such as USB Oblivion, are targeted to more specific artifacts. As such, knowing more about the artifacts or artifact categories that you're interested in will help you determine (a) if some sort of "cleaning" has likely occurred, and (b) provide you with other indicators that you might be able to pursue.
This information can be useful in cases involving violations of acceptable use policies within organizations; however, they are not specifically restricted to such cases. I've used these artifacts in a number of intrusion cases, particularly where the compromised system was accessed remotely via RDP.
Here are some of the RegRipper plugins you can use to collect some other network artifacts, primarily from the user's hives:
networklist.pl - The networklist.pl plugin gives me what was described in the abstract for the conference lab I mentioned; network profile, first/last connection date (in SYSTEMTIME format, based on the system's localtime), gateway MAC address, and the network type (wired, wireless, broadband). The TLN version of this plugin will allow you to incorporate this information into your timeline.
shellbags.pl - As I mentioned previously, shellbags can provide a great deal of information regarding access to network resources; you might not only find indications of access to UNC paths, but also the use of Windows Explorer to access FTP resources (my publisher used to have me do this in order to transfer chapters...). I should note that I've found entries such as these during exams. If you do find information regarding access to FTP in the user's shellbags, you might also want to check out the Software\Microsoft\FTP\Accounts subkeys within the user hive, as well...not only will you find the host connected to, as well as the username used to access the site (if successful).
muicache.pl - If the user uses the command line FTP utility that is native to Windows (ftp.exe), rather than Windows Explorer, to access an FTP site, you may find a reference to that executable in the user's MUICache key (in Windows 7, located in the USRCLASS.DAT hive). Of course, if another GUI FTP client was used, you might expect to find information about that usage via the userassist.pl plugin.
mndmru.pl - This plugin parses the users "Map Network Drive MRU" key data, showing the network drives that the user has mapped via the Map Network Drive Wizard.
runmru.pl - A user may decide to click the Start button, and then simply type a UNC path into the "Run:" box; this information will be available via the runmru.pl plugin.
typedpaths.pl - The TypedPaths key maintains a history of the locations typed into the Windows Explorer Address Bar; similar to the RunMRU key, a user can type UNC paths to network resources into this location.
tsclient.pl - If the user accesses other systems via RDP, you will find references to those connections in the Software\Microsoft\Terminal Services Client subkeys, specifically beneath the Default and Servers subkeys. Of course, if you do find indications of off-system communications via this key, and you're analyzing a Windows 7 system, be sure to include the user Jump Lists in your analysis, as well.
There are also application-specific Registry entries to consider, as well. For example, the vncviewer.pl plugin is in version 20080325 at the moment, which means that it was originally written almost 4 1/2 years ago.
Are there any other network artifacts within the Registry that you might be interested in that aren't covered here? If so, let me know, or comment here.
This is a great start, but what about after the system is connected to particular networking media? What other "network artifacts" can be found in the Registry? That's where we can dig into additional sources of information, specifically other Registry keys and values, to look for those additional network artifacts.
Something else to think about is, what if some of the artifacts that you're pursuing have been deleted? Some tools (CCleaner, etc.) will "erase" lists of known artifacts. Some tools, such as USB Oblivion, are targeted to more specific artifacts. As such, knowing more about the artifacts or artifact categories that you're interested in will help you determine (a) if some sort of "cleaning" has likely occurred, and (b) provide you with other indicators that you might be able to pursue.
This information can be useful in cases involving violations of acceptable use policies within organizations; however, they are not specifically restricted to such cases. I've used these artifacts in a number of intrusion cases, particularly where the compromised system was accessed remotely via RDP.
Here are some of the RegRipper plugins you can use to collect some other network artifacts, primarily from the user's hives:
networklist.pl - The networklist.pl plugin gives me what was described in the abstract for the conference lab I mentioned; network profile, first/last connection date (in SYSTEMTIME format, based on the system's localtime), gateway MAC address, and the network type (wired, wireless, broadband). The TLN version of this plugin will allow you to incorporate this information into your timeline.
shellbags.pl - As I mentioned previously, shellbags can provide a great deal of information regarding access to network resources; you might not only find indications of access to UNC paths, but also the use of Windows Explorer to access FTP resources (my publisher used to have me do this in order to transfer chapters...). I should note that I've found entries such as these during exams. If you do find information regarding access to FTP in the user's shellbags, you might also want to check out the Software\Microsoft\FTP\Accounts subkeys within the user hive, as well...not only will you find the host connected to, as well as the username used to access the site (if successful).
muicache.pl - If the user uses the command line FTP utility that is native to Windows (ftp.exe), rather than Windows Explorer, to access an FTP site, you may find a reference to that executable in the user's MUICache key (in Windows 7, located in the USRCLASS.DAT hive). Of course, if another GUI FTP client was used, you might expect to find information about that usage via the userassist.pl plugin.
mndmru.pl - This plugin parses the users "Map Network Drive MRU" key data, showing the network drives that the user has mapped via the Map Network Drive Wizard.
runmru.pl - A user may decide to click the Start button, and then simply type a UNC path into the "Run:" box; this information will be available via the runmru.pl plugin.
typedpaths.pl - The TypedPaths key maintains a history of the locations typed into the Windows Explorer Address Bar; similar to the RunMRU key, a user can type UNC paths to network resources into this location.
tsclient.pl - If the user accesses other systems via RDP, you will find references to those connections in the Software\Microsoft\Terminal Services Client subkeys, specifically beneath the Default and Servers subkeys. Of course, if you do find indications of off-system communications via this key, and you're analyzing a Windows 7 system, be sure to include the user Jump Lists in your analysis, as well.
There are also application-specific Registry entries to consider, as well. For example, the vncviewer.pl plugin is in version 20080325 at the moment, which means that it was originally written almost 4 1/2 years ago.
Are there any other network artifacts within the Registry that you might be interested in that aren't covered here? If so, let me know, or comment here.
Monday, September 17, 2012
News
Tools
Autopsy v3 is in beta...check it out here. There are lots of screenshots, so if you're looking for a free, open source alternative to commercial analysis frameworks, take a look. Also, consider DFF, another useful framework (discussed in DFwOST) to help get you started in analysis, or to use side-by-side with your other tools in order to validate what you're seeing. If you're in Chantilly, VA, during the first week of Oct, be sure to sign up for OSDFC; it looks like Brian's going to be talking about Autopsy there.
Speaking of open source tools, Volatility has really taken off, with the establishment of the Volatility Labs blog, as well as month of Volatility Plugins (MoVP). In the month of September alone, there have been half a dozen or so posts. I really like how the descriptions of the plugins are laid out, as each provides several sections, including the Effects on Forensics, a description of what the plugin helps reveal. What I really like about this is that too often, in our age of "social" media, too many times, simply linking to something, or clicking "Like" or "Favorite" or retweeting something means that we miss out on the valuable insight that could easily be provided. Good on the folks from Volatility for contributing to the growth of the community in more ways than simply providing a tool to make memory collection and analysis achievable, for a variety of platforms.. To see more of what these folks bring to the table, be sure to check out the Open Memory Forensics Workshop prior to OSDFC, albeit a short distance from the OSDFC venue; OMFW is a half-day conference on 2 Oct, in Chantilly, VA, with presentations by some of the big names (and big heads!!) in memory forensics.
If you're not sure about using Volatility for analysis, check out the SemperSecurus post regarding using Volatility to analyze the Cridex malware. In the post, Andre refers to a number of the useful Volatility commands for extracting information from a memory dump.
If you're using Volatility, or want to, be sure to check out MemGator, for memory sample automated extraction and HTML reporting. According the write-up, MemGator is also capable of extracting TrueCrypt keys. If you do have access to a memory dump from a supported OS, this is a great tool to run through that dump through initial processing, before you move on to more targeted analysis.
Blogosphere
Christian Buia has an interesting EMC blog post where he discusses threat actor's lateral movement within an infrastructure via the Task Scheduler.
The latest rendition of the jobparse.pl Perl code that I wrote, which Christian mentions in the post, can be found here, and Jamie's Python tool is discussed here.
Christian's blog post is very valuable to the community, as there have been a number of times (such as at the DC3 conference last January) where presenters have stated that "..lateral movement was used...", but don't go beyond that; I heard several attendees lament this fact, because without knowing what this "looks like", how would they find it within their infrastructure. Christian gives an example of what this can "look like" within the infrastructure. Some things you might find via host-based analysis would be indications of the use of at.exe on the primary node (Prefetch file, etc.), and artifacts of a Scheduled Task having been run on the secondary node (Windows Event Log entries, Scheduled Task logs, etc.). Now, this is not the only means of lateral movement that can be used; there is also psexec and it's variants, as well.
Sploited has some updates to TLN tools, which is pretty cool. So far, three tools have been posted on the Google Code site for the project. I haven't tried these tools yet, but I am looking for an opportunity to do so soon. This is a great example of how someone in our industry sees a need and decides to step up and fill it...too many times, I think that many of us are hesitant to do so much as express a need...I'm not saying sit down and learn to program, I'm saying simply express a need..."...it would be useful to have X." After all, most of the folks in the community, from the Volatility crew to the person who writes a DOS batch file to tie RegRipper rip.exe commands together all start that way.
Windows 8 is more than on it's way out...check out Claus's Windows 8 Linkage post to see some of the new stuff available.
Threat Intel
I found this very interesting Trend Micro write-up on the Tinba banking trojan, said to be the "smallest", as it reportedly weighs in at 20KB. Write-ups like these can often provide a great deal of threat intelligence, but they can also sometimes fall a bit short with respect the amount of intelligence that can be derived from them and used within your own infrastructure. I don't think that this is necessarily an intentional omission; rather, I think that in most cases, it's due to the perspective of the organization (in this case, an AV vendor), as well as the analyst(s) performing the actual analysis (malware RE folks). What I mean by that is that if you're a reverse engineer who's really good at using a debugger and analyzing memory, your analysis is going to be slanted in that direction. Very often what I try to do is read between the lines and see what isn't said, and what host-based artifacts should be there that aren't discussed, so that the information provided can be used as part of a root cause analysis.
A couple of things I found interesting within the write-up:
This malware apparently uses the user's Run key for persistence. Many sites, including Microsoft themselves, have stated this persistence mechanism allows the malware to remain persistent following a system boot...however, it is more correct to say that it allows the malware to start automatically the next time the user logs in to the system. Yes, the malware will run after a reboot, but only after that user logs in again.
Note: the write-up states that the malware creates a Registry "key" for itself; this is incorrect - it creates a Registry value beneath the Run key. This may not be a huge distinction to many, but when it comes to things like incorporating Registry data into timeline analysis, it will make a significant difference. Registry keys include embedded time stamps within their structure, referred to as the key "LastWrite" time; Registry values do not have this element in their structure.
I did not find any mention within the write-up as to which platform was used to analyze the malware; we can assume, based on a couple of the screen captures, that it was likely Windows XP, but there's no indication as to whether the platform is 32- or 64-bit. This is important to consider, because if the malware is 32-bit and infects a 64-bit system, the location of the persistence mechanism will be slightly different.
The malware also apparently modifies another Registry value that controls Internet Explorer; specifically, within the "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3" key, the value "1609" is modified to 0. There is other malware out there that makes similar modifications, and MS is kind enough to provide a KB article that describes what the various values beneath these keys refer to.
Something else that the malware does is modify the user.js Firefox file within the user's profile; as there doesn't seem to be any indication of time stamp manipulation, this should show up as an "M..." entry for that file in your timeline. The modification that the malware makes apparently disables anti-phishing warnings in Firefox.
While there is some discussion of the malware communications mechanism, it mostly centers on the fact that comms are encrypted. Earlier in the write-up, the report states that the malware primarily uses 4 DLLs, one of which is ws2_32.dll. This may provide it's off-system communications capabilities, and for host-based analysts, it can tell us something else. For example, if this is the only DLL utilized for off-system communications, and others such as wininet.dll are not used, then this would tell us that we should not expect to see artifacts of the communications in the user's index.dat file, and we should probably consider spelunking into the pagefile for artifacts of communications.
Autopsy v3 is in beta...check it out here. There are lots of screenshots, so if you're looking for a free, open source alternative to commercial analysis frameworks, take a look. Also, consider DFF, another useful framework (discussed in DFwOST) to help get you started in analysis, or to use side-by-side with your other tools in order to validate what you're seeing. If you're in Chantilly, VA, during the first week of Oct, be sure to sign up for OSDFC; it looks like Brian's going to be talking about Autopsy there.
Speaking of open source tools, Volatility has really taken off, with the establishment of the Volatility Labs blog, as well as month of Volatility Plugins (MoVP). In the month of September alone, there have been half a dozen or so posts. I really like how the descriptions of the plugins are laid out, as each provides several sections, including the Effects on Forensics, a description of what the plugin helps reveal. What I really like about this is that too often, in our age of "social" media, too many times, simply linking to something, or clicking "Like" or "Favorite" or retweeting something means that we miss out on the valuable insight that could easily be provided. Good on the folks from Volatility for contributing to the growth of the community in more ways than simply providing a tool to make memory collection and analysis achievable, for a variety of platforms.. To see more of what these folks bring to the table, be sure to check out the Open Memory Forensics Workshop prior to OSDFC, albeit a short distance from the OSDFC venue; OMFW is a half-day conference on 2 Oct, in Chantilly, VA, with presentations by some of the big names (and big heads!!) in memory forensics.
If you're not sure about using Volatility for analysis, check out the SemperSecurus post regarding using Volatility to analyze the Cridex malware. In the post, Andre refers to a number of the useful Volatility commands for extracting information from a memory dump.
If you're using Volatility, or want to, be sure to check out MemGator, for memory sample automated extraction and HTML reporting. According the write-up, MemGator is also capable of extracting TrueCrypt keys. If you do have access to a memory dump from a supported OS, this is a great tool to run through that dump through initial processing, before you move on to more targeted analysis.
Blogosphere
Christian Buia has an interesting EMC blog post where he discusses threat actor's lateral movement within an infrastructure via the Task Scheduler.
The latest rendition of the jobparse.pl Perl code that I wrote, which Christian mentions in the post, can be found here, and Jamie's Python tool is discussed here.
Christian's blog post is very valuable to the community, as there have been a number of times (such as at the DC3 conference last January) where presenters have stated that "..lateral movement was used...", but don't go beyond that; I heard several attendees lament this fact, because without knowing what this "looks like", how would they find it within their infrastructure. Christian gives an example of what this can "look like" within the infrastructure. Some things you might find via host-based analysis would be indications of the use of at.exe on the primary node (Prefetch file, etc.), and artifacts of a Scheduled Task having been run on the secondary node (Windows Event Log entries, Scheduled Task logs, etc.). Now, this is not the only means of lateral movement that can be used; there is also psexec and it's variants, as well.
Sploited has some updates to TLN tools, which is pretty cool. So far, three tools have been posted on the Google Code site for the project. I haven't tried these tools yet, but I am looking for an opportunity to do so soon. This is a great example of how someone in our industry sees a need and decides to step up and fill it...too many times, I think that many of us are hesitant to do so much as express a need...I'm not saying sit down and learn to program, I'm saying simply express a need..."...it would be useful to have X." After all, most of the folks in the community, from the Volatility crew to the person who writes a DOS batch file to tie RegRipper rip.exe commands together all start that way.
Windows 8 is more than on it's way out...check out Claus's Windows 8 Linkage post to see some of the new stuff available.
Threat Intel
I found this very interesting Trend Micro write-up on the Tinba banking trojan, said to be the "smallest", as it reportedly weighs in at 20KB. Write-ups like these can often provide a great deal of threat intelligence, but they can also sometimes fall a bit short with respect the amount of intelligence that can be derived from them and used within your own infrastructure. I don't think that this is necessarily an intentional omission; rather, I think that in most cases, it's due to the perspective of the organization (in this case, an AV vendor), as well as the analyst(s) performing the actual analysis (malware RE folks). What I mean by that is that if you're a reverse engineer who's really good at using a debugger and analyzing memory, your analysis is going to be slanted in that direction. Very often what I try to do is read between the lines and see what isn't said, and what host-based artifacts should be there that aren't discussed, so that the information provided can be used as part of a root cause analysis.
A couple of things I found interesting within the write-up:
This malware apparently uses the user's Run key for persistence. Many sites, including Microsoft themselves, have stated this persistence mechanism allows the malware to remain persistent following a system boot...however, it is more correct to say that it allows the malware to start automatically the next time the user logs in to the system. Yes, the malware will run after a reboot, but only after that user logs in again.
Note: the write-up states that the malware creates a Registry "key" for itself; this is incorrect - it creates a Registry value beneath the Run key. This may not be a huge distinction to many, but when it comes to things like incorporating Registry data into timeline analysis, it will make a significant difference. Registry keys include embedded time stamps within their structure, referred to as the key "LastWrite" time; Registry values do not have this element in their structure.
I did not find any mention within the write-up as to which platform was used to analyze the malware; we can assume, based on a couple of the screen captures, that it was likely Windows XP, but there's no indication as to whether the platform is 32- or 64-bit. This is important to consider, because if the malware is 32-bit and infects a 64-bit system, the location of the persistence mechanism will be slightly different.
The malware also apparently modifies another Registry value that controls Internet Explorer; specifically, within the "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3" key, the value "1609" is modified to 0. There is other malware out there that makes similar modifications, and MS is kind enough to provide a KB article that describes what the various values beneath these keys refer to.
Something else that the malware does is modify the user.js Firefox file within the user's profile; as there doesn't seem to be any indication of time stamp manipulation, this should show up as an "M..." entry for that file in your timeline. The modification that the malware makes apparently disables anti-phishing warnings in Firefox.
While there is some discussion of the malware communications mechanism, it mostly centers on the fact that comms are encrypted. Earlier in the write-up, the report states that the malware primarily uses 4 DLLs, one of which is ws2_32.dll. This may provide it's off-system communications capabilities, and for host-based analysts, it can tell us something else. For example, if this is the only DLL utilized for off-system communications, and others such as wininet.dll are not used, then this would tell us that we should not expect to see artifacts of the communications in the user's index.dat file, and we should probably consider spelunking into the pagefile for artifacts of communications.
Thursday, September 06, 2012
32-bit EXEs on a 64-bit System
Anyone who's done digital analysis of Windows systems knows that they can be pretty complex beasts to analyze. To add a little "fun" to the mix, the location of artifacts on a 64-bit Windows system will depend on whether the programs used are 32- or 64-bit programs.
Wait...what?
Now, what does all this mean? Let's say you have a copy of a malware sample, and you submit it to VirusTotal, or you already know what the malware is identified and known as to some of the various AV vendors. When you read the AV vendor write-ups on the malware, you'll notice that they very rarely identify the analysis platform used; so, if the malware uses the Run key for persistence, you might open the Software hive in a viewer and navigate to the Run key, not find any unusual entries, and then simply assume that the malware either didn't execute, or failed to completely install and run.
You should be aware that 64-bit Windows system perform redirection when it comes to 32-bit applications. What this means is that if you check the PE header of the malware file and find that it was compiled for 32-bit platforms, and the system you're analyzing is a 64-bit platform, you're going to need to look in a few additional (maybe I should say "other", instead) areas for your artifacts.
Registry redirection primarily affects the Software and NTUSER.DAT hives; there's (apparently) no "WOW6432Node" subkey in the System hive (I haven't seen one yet). As such, if malware usually uses the Run key, then you should check the Run keys in both the HLKM\Software\Microsoft\Windows\CurrentVersion and the HLKM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion paths.
Something to be aware of is that none of the RegRipper plugins available in the current archive that check the Run keys in either the Software or NTUSER.DAT hives account for redirection. I have a number of plugins in my own repository that do take this into account, and have been responsible for some pretty cool/significant finds.
Now, most times, within the file system, all we usually see with respect to redirection is that when we install 32-bit applications on a 64-bit system, we'll see a C:\Program Files directory as well as a C:\Program Files (x86) directory. However, due to file system redirection, 32-bit malware that, for example, attempts to write a file to the C:\Windows\config\systemprofile \AppData\Local folder (on a Windows 7 or Win2008R2 system), on a 64-bit system will actually write that file to the to C:\Windows\SysWOW64\config\systemprofile\AppData\Local folder. Use of environment variables such as %Temp% will have a similar effect.
Again, I have yet to see any Registry redirection that applies to the System hive. I have seen 32-bit malware installed on 64-bit Windows systems as a service, and the services entries went right into the ControlSet00n\services\ subkeys.
Note: The current version of the appcompatcache.pl plugin includes some simple checks (via grep()) for potentially suspicious paths, such as those that contain the term "temp". Based on some recent findings, I'm going to go back to that and add a check for SysWOW64...and I will likely add that check to other plugins, as well.
So What?
So, why should anyone care about any of this at all? Well, let's say that you're doing some analysis of a system, and you think that there may be malware on the system, malware for which several AV vendor write-ups state that it uses the Run key for persistence. Okay, so we run RegRipper or open the hive in a viewer and navigate to that key...but we don't see a reference to any unusual files. At this point, what do we do? In some cases, many of us might check that item off of our checklist, and move on to the next step. However, did we really complete that check? After all, AV vendor write-ups are notorious for not providing complete information...I have yet to see a write-up that states, "...here is the PE header info for this malware, and we performed dynamic analysis by running the malware in a Windows XP SP3 (32-bit) VirtualBox VM..", and to be honest, I don't think that I've seen that because to the AV vendors, none of that is important. But to an incident responder or a digital forensic analyst, it can be very important.
A couple of months ago, I was looking at a Software hive from a system that had been compromised, and I found some interesting artifacts in the Microsoft\Tracing key. Now, this was a 64-bit Windows system I was analyzing, and I knew that at least one of the programs that had been installed on the system was 32-bit, so I decided to check the WOW6432Node\Microsoft\Tracing key, and not only did I find the subkeys that I thought would be there, but I also found references to other 32-bit programs, as well.
So, when performing analysis or asking questions in order to further your analysis, it is important to realize that not only is it very important to be aware of the version of Windows that you are analyzing, but it's also important to be aware of whether the version is 32- or 64-bit, as this can have a significant impact on where you look for artifacts, in both the file system as well as the Registry.
This also applies to when we're sharing information within the community; for example, after having read this blog post, it should be pretty clear that this write-up of ADrive on ForensicArtifacts.com involved a 32-bit app run on a 64-bit system. However, if you weren't aware of this, would you look for the \Wow6432Node\Microsoft\Tracing\ADrive Desktop_RASAPI32 key, not find "Wow6432Node" in the Software hive, and then just figure that the application had not been run?
Resources
Registry Redirection
File System Redirector
Wait...what?
Now, what does all this mean? Let's say you have a copy of a malware sample, and you submit it to VirusTotal, or you already know what the malware is identified and known as to some of the various AV vendors. When you read the AV vendor write-ups on the malware, you'll notice that they very rarely identify the analysis platform used; so, if the malware uses the Run key for persistence, you might open the Software hive in a viewer and navigate to the Run key, not find any unusual entries, and then simply assume that the malware either didn't execute, or failed to completely install and run.
You should be aware that 64-bit Windows system perform redirection when it comes to 32-bit applications. What this means is that if you check the PE header of the malware file and find that it was compiled for 32-bit platforms, and the system you're analyzing is a 64-bit platform, you're going to need to look in a few additional (maybe I should say "other", instead) areas for your artifacts.
Registry redirection primarily affects the Software and NTUSER.DAT hives; there's (apparently) no "WOW6432Node" subkey in the System hive (I haven't seen one yet). As such, if malware usually uses the Run key, then you should check the Run keys in both the HLKM\Software\Microsoft\Windows\CurrentVersion and the HLKM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion paths.
Something to be aware of is that none of the RegRipper plugins available in the current archive that check the Run keys in either the Software or NTUSER.DAT hives account for redirection. I have a number of plugins in my own repository that do take this into account, and have been responsible for some pretty cool/significant finds.
Now, most times, within the file system, all we usually see with respect to redirection is that when we install 32-bit applications on a 64-bit system, we'll see a C:\Program Files directory as well as a C:\Program Files (x86) directory. However, due to file system redirection, 32-bit malware that, for example, attempts to write a file to the C:\Windows\config\systemprofile \AppData\Local folder (on a Windows 7 or Win2008R2 system), on a 64-bit system will actually write that file to the to C:\Windows\SysWOW64\config\systemprofile\AppData\Local folder. Use of environment variables such as %Temp% will have a similar effect.
Again, I have yet to see any Registry redirection that applies to the System hive. I have seen 32-bit malware installed on 64-bit Windows systems as a service, and the services entries went right into the ControlSet00n\services\ subkeys.
Note: The current version of the appcompatcache.pl plugin includes some simple checks (via grep()) for potentially suspicious paths, such as those that contain the term "temp". Based on some recent findings, I'm going to go back to that and add a check for SysWOW64...and I will likely add that check to other plugins, as well.
So What?
So, why should anyone care about any of this at all? Well, let's say that you're doing some analysis of a system, and you think that there may be malware on the system, malware for which several AV vendor write-ups state that it uses the Run key for persistence. Okay, so we run RegRipper or open the hive in a viewer and navigate to that key...but we don't see a reference to any unusual files. At this point, what do we do? In some cases, many of us might check that item off of our checklist, and move on to the next step. However, did we really complete that check? After all, AV vendor write-ups are notorious for not providing complete information...I have yet to see a write-up that states, "...here is the PE header info for this malware, and we performed dynamic analysis by running the malware in a Windows XP SP3 (32-bit) VirtualBox VM..", and to be honest, I don't think that I've seen that because to the AV vendors, none of that is important. But to an incident responder or a digital forensic analyst, it can be very important.
A couple of months ago, I was looking at a Software hive from a system that had been compromised, and I found some interesting artifacts in the Microsoft\Tracing key. Now, this was a 64-bit Windows system I was analyzing, and I knew that at least one of the programs that had been installed on the system was 32-bit, so I decided to check the WOW6432Node\Microsoft\Tracing key, and not only did I find the subkeys that I thought would be there, but I also found references to other 32-bit programs, as well.
So, when performing analysis or asking questions in order to further your analysis, it is important to realize that not only is it very important to be aware of the version of Windows that you are analyzing, but it's also important to be aware of whether the version is 32- or 64-bit, as this can have a significant impact on where you look for artifacts, in both the file system as well as the Registry.
This also applies to when we're sharing information within the community; for example, after having read this blog post, it should be pretty clear that this write-up of ADrive on ForensicArtifacts.com involved a 32-bit app run on a 64-bit system. However, if you weren't aware of this, would you look for the \Wow6432Node\Microsoft\Tracing\ADrive Desktop_RASAPI32 key, not find "Wow6432Node" in the Software hive, and then just figure that the application had not been run?
Resources
Registry Redirection
File System Redirector
Monday, September 03, 2012
Links, Tools, Etc.
Windows 8 Forensics
There is some great information circulating about the Interwebs regarding Windows 8 forensics. There's this YouTube video titled A Forensic First Look, this blog post that addresses reset and refresh artifacts, the Windows 8 Forensics Guide (this PDF was mentioned previously on this blog), this blog post on the Windows 8 TypedURLsTime Registry key, and Kenneth Johnson's excellent PDF on Windows 8 File History...in addition to a number of other available resources. Various beta and pre-beta versions of Windows 8 have been out for some time, and with each release there seems to be something new...when I went from the first version available for developers to the Consumer Preview, one of the first things I noticed was that I was no longer able to disable the Metro interface.
So what does all this mean? Well, just like when Windows XP was released, there were changes that would affect how we within the digital analysis community would do our jobs, and the same thing has been true since then with every new OS release. While our overall analysis process wouldn't change, there are aspects of the new operating system and it's included technologies that require us to update the specifics of those processes.
Timeline Analysis
Over at the Sploited blog, there's an excellent post on how to incorporate Java information into your TLN-format timeline, in order to help determine the exploit used to compromise a system. In addition to the information available in the two previous posts (here, and here, respectively), this post includes code for parsing .idx files, and incorporating log entries into a TLN-format timeline.
Just to be clear, this is NOT a RegRipper plugin (there is often times confusion about this...), but is instead a file parser that you can use to incorporate data into your timeline, similar to parsing Prefetch file metadata. As such, it can very often add some much-needed detail and context to your analysis.
Posts such as this go hand-in-hand with the excellent work that Corey Harrell has done in determining exploit footprints on compromised systems.
PList Parser
If you do forensics on iDevices, or you get access to iDevice backups via iTunes on a system, you might want to take a look at Maria's PList Parser. Parsing these files can provide you with a great deal of insight into the user's behavior while using the device. Maria said that she used RegRipper as the inspiration for her tool, and it's great to see tools like this become available.
ScheduledTask File Parser
Jamie's released a .job file parser, written in Python. These files, on WinXP and 2003 systems, are in a binary format (in later versions of Windows, they're XML) and like other files (ie, Prefetch files) can contain some significant metadata. In the past, I've found analysis of these artifacts to particularly useful when responding to incidents involving certain threat actors that moved laterally within the compromised infrastructure...one way of doing so was to schedule tasks on remote systems.
Not only does Jamie provide an explanation of what a .job file "looks like", but she also provides references so that folks can look this information up themselves, and develop a deeper understanding of what the tool is doing, should they choose to do so. Also, don't forget the great work Jamie has done with her MBR parser, particularly if you're performing some sort of malware detection on an acquired image.
Registry Analysis
I ran across this write-up on Wiper recently via Twitter,
In the write-up, the authors state:
"...we came up with the idea to look into the hive slack space for deleted entries."
Hhhmm...okay. My understanding of "slack space", with respect to the file system, is that it's usually considered to be what's left over between the logical and physical space consumed by a file. Let's say that there's a file that's 892 bytes, and in order to save it to disk, the system will allocate 2 512 byte sectors, or 1024 bytes. As such, the slack space would be that 132 bytes that remains between the logical end of the file, and end of the second physical sector.
Now, this can be true for the hive files themselves, as some data may exist between the logical end of the hive, and the end of the last physical sector. This may also be true for value data, as well...if the 1024 bytes are allocated for a value, but only 892 bytes are actually written to the allocated space, there may be slack space available.
However, if you look at the graphic associated with the comment (excellent use of Yaru, guys!), the first 4 bytes (DWORD) of the selected data are a positive value, indicating that the key was deleted. As such, the key becomes part of the unallocated space of the hive file, just like the sectors of a deleted file become part of the unallocated space of a volume or disk. So, the value appears to have been part of unallocated space of the hive file, rather than slack space.
With respect to overall Registry analysis, perhaps "...we came up with the idea..." isn't the most systematic approach to that analysis. Admittedly, the authors found something very interesting, but I'd be interested to know if the authors found an enum\Root\Legacy_RAHDAUD64 key in that Registry hive they were looking at, or if they found a Windows Event Log record with source "Service Control Manager" and an ID of 7035 (indicating a service start message had been sent), and then opted to check for deleted keys in the hive after determining that there was no corresponding visible keys for a service of that name in the System hive.
Looking for Suspicious EXEs
Adam wrote an interesting blog post on finding suspicious PE files via clustering...in short, assuming PE files may have been subject to timestomping (ie, intentional modification of MFT $STANDARD_INFORMATION attribute time stamps), and attempting to detect these files by "clustering" the PE file compile times.
You can read more about methods for detecting malicious files by reading Joel Yonts' GIAC Gold Paper, Attributes of Malicious Files.
There is some great information circulating about the Interwebs regarding Windows 8 forensics. There's this YouTube video titled A Forensic First Look, this blog post that addresses reset and refresh artifacts, the Windows 8 Forensics Guide (this PDF was mentioned previously on this blog), this blog post on the Windows 8 TypedURLsTime Registry key, and Kenneth Johnson's excellent PDF on Windows 8 File History...in addition to a number of other available resources. Various beta and pre-beta versions of Windows 8 have been out for some time, and with each release there seems to be something new...when I went from the first version available for developers to the Consumer Preview, one of the first things I noticed was that I was no longer able to disable the Metro interface.
So what does all this mean? Well, just like when Windows XP was released, there were changes that would affect how we within the digital analysis community would do our jobs, and the same thing has been true since then with every new OS release. While our overall analysis process wouldn't change, there are aspects of the new operating system and it's included technologies that require us to update the specifics of those processes.
Timeline Analysis
Over at the Sploited blog, there's an excellent post on how to incorporate Java information into your TLN-format timeline, in order to help determine the exploit used to compromise a system. In addition to the information available in the two previous posts (here, and here, respectively), this post includes code for parsing .idx files, and incorporating log entries into a TLN-format timeline.
Just to be clear, this is NOT a RegRipper plugin (there is often times confusion about this...), but is instead a file parser that you can use to incorporate data into your timeline, similar to parsing Prefetch file metadata. As such, it can very often add some much-needed detail and context to your analysis.
Posts such as this go hand-in-hand with the excellent work that Corey Harrell has done in determining exploit footprints on compromised systems.
PList Parser
If you do forensics on iDevices, or you get access to iDevice backups via iTunes on a system, you might want to take a look at Maria's PList Parser. Parsing these files can provide you with a great deal of insight into the user's behavior while using the device. Maria said that she used RegRipper as the inspiration for her tool, and it's great to see tools like this become available.
ScheduledTask File Parser
Jamie's released a .job file parser, written in Python. These files, on WinXP and 2003 systems, are in a binary format (in later versions of Windows, they're XML) and like other files (ie, Prefetch files) can contain some significant metadata. In the past, I've found analysis of these artifacts to particularly useful when responding to incidents involving certain threat actors that moved laterally within the compromised infrastructure...one way of doing so was to schedule tasks on remote systems.
Not only does Jamie provide an explanation of what a .job file "looks like", but she also provides references so that folks can look this information up themselves, and develop a deeper understanding of what the tool is doing, should they choose to do so. Also, don't forget the great work Jamie has done with her MBR parser, particularly if you're performing some sort of malware detection on an acquired image.
Registry Analysis
I ran across this write-up on Wiper recently via Twitter,
In the write-up, the authors state:
"...we came up with the idea to look into the hive slack space for deleted entries."
Hhhmm...okay. My understanding of "slack space", with respect to the file system, is that it's usually considered to be what's left over between the logical and physical space consumed by a file. Let's say that there's a file that's 892 bytes, and in order to save it to disk, the system will allocate 2 512 byte sectors, or 1024 bytes. As such, the slack space would be that 132 bytes that remains between the logical end of the file, and end of the second physical sector.
Now, this can be true for the hive files themselves, as some data may exist between the logical end of the hive, and the end of the last physical sector. This may also be true for value data, as well...if the 1024 bytes are allocated for a value, but only 892 bytes are actually written to the allocated space, there may be slack space available.
However, if you look at the graphic associated with the comment (excellent use of Yaru, guys!), the first 4 bytes (DWORD) of the selected data are a positive value, indicating that the key was deleted. As such, the key becomes part of the unallocated space of the hive file, just like the sectors of a deleted file become part of the unallocated space of a volume or disk. So, the value appears to have been part of unallocated space of the hive file, rather than slack space.
With respect to overall Registry analysis, perhaps "...we came up with the idea..." isn't the most systematic approach to that analysis. Admittedly, the authors found something very interesting, but I'd be interested to know if the authors found an enum\Root\Legacy_RAHDAUD64 key in that Registry hive they were looking at, or if they found a Windows Event Log record with source "Service Control Manager" and an ID of 7035 (indicating a service start message had been sent), and then opted to check for deleted keys in the hive after determining that there was no corresponding visible keys for a service of that name in the System hive.
Looking for Suspicious EXEs
Adam wrote an interesting blog post on finding suspicious PE files via clustering...in short, assuming PE files may have been subject to timestomping (ie, intentional modification of MFT $STANDARD_INFORMATION attribute time stamps), and attempting to detect these files by "clustering" the PE file compile times.
You can read more about methods for detecting malicious files by reading Joel Yonts' GIAC Gold Paper, Attributes of Malicious Files.
Monday, August 20, 2012
SetRegTime
I like good stuff, interesting stuff. I particularly like stuff that gets me to thinking, and gets me to thinking specifically about validating my analysis process.
I ran across SetRegTime today, from Joakim Schicht. Basically, Joakim started from the perspective that, from his view and his reading on the Internet, modification of Registry key LastWrite times to arbitrary values was "not possible". So, he set out to turn this line of thinking around, achieved it, and released a proof-of-concept tool to demonstrate the capability.
In my courses, I have specifically stated that I was not aware of any open, public APIs (such as the GetFileTime()/SetFileTime() functions) that allow for arbitrary modification of Registry key LastWrite times. Now, thanks to Joakim, we all are.
I greatly applaud and appreciate Joakim's efforts in producing and releasing SetRegTime, as it:
1. Identifies the public API and increased the possibility (albeit not the likelihood) of this occurring.
2. Illustrates the need for an overall analysis process.
3. Illustrates the need for a greater understanding of the Registry as an investigative resource.
4. Illustrates more than ever the need for timeline analysis.
So, the big question for most analysts will likely be...okay, so what does this do to my examinations? I'm sure that the thought will be that it throws an additional level of uncertainty into the exams, but I would suggest that if you have an analysis process, then this won't be the case at all. With an analysis process, you will likely find indications of this sort of activity occurring, particularly if you are using timeline analysis.
In addition, when performing malware analysis, you would want to look for the use of the APIs that Joakim mentions (i.e., NtCreateKey, NtOpenKey, NtSetInformationKey, NtFlushKey), as well as the use of the Windows internal names for the Registry. Behavior analysis of the malware will likely illustrate this activity, as well.
So, if you're "poking around" in the Registry and find something interesting, and rely on that one artifact or finding as the foundation for your case, you're likely going to be building a house of cards. However, if you have an overall analysis process that incorporates multiple data sources and multiple artifacts to support your conclusions, then you're likely going to pick up on the use of this sort of software, and be able to address it accordingly.
I ran across SetRegTime today, from Joakim Schicht. Basically, Joakim started from the perspective that, from his view and his reading on the Internet, modification of Registry key LastWrite times to arbitrary values was "not possible". So, he set out to turn this line of thinking around, achieved it, and released a proof-of-concept tool to demonstrate the capability.
In my courses, I have specifically stated that I was not aware of any open, public APIs (such as the GetFileTime()/SetFileTime() functions) that allow for arbitrary modification of Registry key LastWrite times. Now, thanks to Joakim, we all are.
I greatly applaud and appreciate Joakim's efforts in producing and releasing SetRegTime, as it:
1. Identifies the public API and increased the possibility (albeit not the likelihood) of this occurring.
2. Illustrates the need for an overall analysis process.
3. Illustrates the need for a greater understanding of the Registry as an investigative resource.
4. Illustrates more than ever the need for timeline analysis.
So, the big question for most analysts will likely be...okay, so what does this do to my examinations? I'm sure that the thought will be that it throws an additional level of uncertainty into the exams, but I would suggest that if you have an analysis process, then this won't be the case at all. With an analysis process, you will likely find indications of this sort of activity occurring, particularly if you are using timeline analysis.
In addition, when performing malware analysis, you would want to look for the use of the APIs that Joakim mentions (i.e., NtCreateKey, NtOpenKey, NtSetInformationKey, NtFlushKey), as well as the use of the Windows internal names for the Registry. Behavior analysis of the malware will likely illustrate this activity, as well.
So, if you're "poking around" in the Registry and find something interesting, and rely on that one artifact or finding as the foundation for your case, you're likely going to be building a house of cards. However, if you have an overall analysis process that incorporates multiple data sources and multiple artifacts to support your conclusions, then you're likely going to pick up on the use of this sort of software, and be able to address it accordingly.
Wednesday, August 15, 2012
ShellBag Analysis
What are "shellbags"?
To get an understanding of what "shellbags" are, I'd suggest that you start by reading Chad Tilbury's excellent SANS Forensic blog post on the topic. I'm not going to try to steal Chad's thunder...he does a great job of explaining what these artifacts are, so there's really no sense in rehashing everything.
Discussion of this topic goes back well before Chad's post, with this DFRWS 2009 paper. Before that, John McCash talked about ShellBag Registry Forensics on the SANS Forensics blog. Even Microsoft mentions the keys in question in KB 813711.
Without going into a lot of detail, a user's shell window preferences are maintained in the Registry, and the hive and keys being used to record these preferences will depend upon the version of the Windows operating system. Microsoft wants the user to have a great experience while using the operating system and applications, right? If a user opens up a window on the Desktop and repositions and resizes that window, how annoying would it be to shut the system down, and have to come back the next day and have to do it all over again? Because this information is recorded in the Registry, it is available to analysts who can parse and interpret the data. As such, "ShellBags" is sort of a colloquial term used to refer to a specific area of Registry analysis.
Tools such as Registry Decoder, TZWorks sbag, and RegRipper are capable of decoding and presenting the information available in the ShellBags.
How can ShellBags help an investigation?
I think that one of the biggest issues with ShellBags analysis is that, much like other lines of analysis that involve the Windows Registry, they're poorly understood, and as such, underutilized. Artifacts like the ShellBags can be very beneficial to an examiner, depending upon the type of examination they're conducting. Much like the analysis of other Windows artifacts, ShellBags can demonstrate a user's access to resources, often well after that resource is no longer available. ShellBag analysis can demonstrate access to folders, files, external storage devices, and network resources. Under the appropriate conditions, the user's access to these resources will be recorded and persist well after the accessed resource has been deleted, or is no longer accessible via the system.
If an organization has an acceptable use policy, ShellBags data may demonstrate violations of that policy, by illustrating access to file paths with questionable names, such as what may be available via a thumb drive or DVD. Or, it may be a violation of acceptable use policies to access another employee's computer without their consent, such as:
...or to access other systems, such as:
Desktop\My Network Places\192.168.23.6\\\192.168.23.6\c$
Further, because of how .zip files are handled by default on Windows systems, ShellBag analysis can illustrate that a user not only had a zipped archive on their system, but that they opened it and viewed subfolders within the archive.
This is what it looks like when I accessed Zip file subfolders on my system:
Desktop\Users\AppData\Local\Temp\RR.zip\DVD\RegRipper\DVD
Access to devices will also be recorded in these Registry keys, including access to specific resources on those devices.
For example, from the ShellBags data available on my own system I was able to see where I'd accessed an Android system:
...as well as a digital camera...
Desktop\My Computer\Canon EOS DIGITAL REBEL XTi\CF\DCIM\334CANON
...and an iPod.
Desktop\My Computer\Harlan s iPod\Internal Storage\DCIM
Another aspect of ShellBags analysis that can be valuable to an examination is by the analyst developing an understanding the actual data structures, referred to as "shell item ID lists", used within the ShellBag. It turns out that these data structures are not only used in other values within the Registry, but they're also used in other artifacts, such as Windows shortcut/LNK files, as well as within Jump List files. Understanding and being able to recognize and parse these structures lets an analyst get the most out of the available data.
Locating Possible Data Exfil/Infil Paths via ShellBags
As information regarding access to removable storage devices and network resources can be recorded in the ShellBags, this data may be used to demonstrate infiltration/infection or data exfiltration paths.
For example, one means of getting data off of a system is via FTP. Many Windows users aren't aware that Windows has a command line FTP client, although some are; in my experience, it's more often intruders who are conversant in the use of the command line client. One way that analysts look for the use of the FTP client (i.e., ftp.exe) is via Prefetch files, as well as via the MUICache Registry key.
However, another way to access FTP on a Windows system is via the Windows Explorer shell itself. I've worked with a couple of organizations that used FTP for large file transfers and had us use this process rather than use the command line client. A couple of sites provide simple instructions regarding how to use FTP via Windows Explorer:
MS FTP FAQ
HostGator: Using FTP via Windows Explorer
Here's what a URI entry looks like when parsed (obfuscated, of course):
One of the data types recorded within the ShellBags keys is a "URI", and this data structure includes an embedded time stamp, as well as the protocol (ie, ftp, http, etc.) used in the communications. The embedded time stamp appears (via timeline analysis) to correlate with when the attempt was made to connect to the FTP site. If the connection is successful, you will likely find a corresponding entry for the site in the NTUSER.DAT hive, in the path:
HKCU/Software/Microsoft/FTP/Accounts/www.site.com
Much like access via the keyboard, remote access to the system that provides shell-based control, such as via RDP, will often facilitate the use of other graphical tools, including the use of the Windows Explorer shell for off-system communications. ShellBag analysis may lead to some very interesting findings, not only with respect to what a user may have done, but also other resources an intruder may have accessed.
Summary
Like other Windows artifacts, ShellBags persist well after the accessed resources are no longer available. Knowing how to parse and interpret this Registry data
Parsing ShellBags data can provide you with indications of access to external resources, potentially providing indications of one avenue of off-system communications. If the concern is data infiltration ("how did that get here?"), you may find indications of access to an external resource, followed by indications of access to Zip file subfolders. ShellBags can be used to demonstrate access to resources where no other indications are available (because they weren't recorded some where else, or because they were intentionally deleted), or they can be used in conjunction with other resources to build a stronger case. Incorporation of ShellBag data into timelines for analysis can also provide some very valuable insight that might not otherwise be available to the analyst.
Resources
ForensicsWiki Shell Item page
To get an understanding of what "shellbags" are, I'd suggest that you start by reading Chad Tilbury's excellent SANS Forensic blog post on the topic. I'm not going to try to steal Chad's thunder...he does a great job of explaining what these artifacts are, so there's really no sense in rehashing everything.
Discussion of this topic goes back well before Chad's post, with this DFRWS 2009 paper. Before that, John McCash talked about ShellBag Registry Forensics on the SANS Forensics blog. Even Microsoft mentions the keys in question in KB 813711.
Without going into a lot of detail, a user's shell window preferences are maintained in the Registry, and the hive and keys being used to record these preferences will depend upon the version of the Windows operating system. Microsoft wants the user to have a great experience while using the operating system and applications, right? If a user opens up a window on the Desktop and repositions and resizes that window, how annoying would it be to shut the system down, and have to come back the next day and have to do it all over again? Because this information is recorded in the Registry, it is available to analysts who can parse and interpret the data. As such, "ShellBags" is sort of a colloquial term used to refer to a specific area of Registry analysis.
Tools such as Registry Decoder, TZWorks sbag, and RegRipper are capable of decoding and presenting the information available in the ShellBags.
How can ShellBags help an investigation?
I think that one of the biggest issues with ShellBags analysis is that, much like other lines of analysis that involve the Windows Registry, they're poorly understood, and as such, underutilized. Artifacts like the ShellBags can be very beneficial to an examiner, depending upon the type of examination they're conducting. Much like the analysis of other Windows artifacts, ShellBags can demonstrate a user's access to resources, often well after that resource is no longer available. ShellBag analysis can demonstrate access to folders, files, external storage devices, and network resources. Under the appropriate conditions, the user's access to these resources will be recorded and persist well after the accessed resource has been deleted, or is no longer accessible via the system.
If an organization has an acceptable use policy, ShellBags data may demonstrate violations of that policy, by illustrating access to file paths with questionable names, such as what may be available via a thumb drive or DVD. Or, it may be a violation of acceptable use policies to access another employee's computer without their consent, such as:
Desktop\My Network Places\user-PC\\\user-PC\Users
...or to access other systems, such as:
Desktop\My Network Places\192.168.23.6\\\192.168.23.6\c$
Further, because of how .zip files are handled by default on Windows systems, ShellBag analysis can illustrate that a user not only had a zipped archive on their system, but that they opened it and viewed subfolders within the archive.
This is what it looks like when I accessed Zip file subfolders on my system:
Desktop\Users\AppData\Local\Temp\RR.zip\DVD\RegRipper\DVD
Access to devices will also be recorded in these Registry keys, including access to specific resources on those devices.
For example, from the ShellBags data available on my own system I was able to see where I'd accessed an Android system:
Desktop\My Computer\F:\Android\data
...as well as a digital camera...
Desktop\My Computer\Canon EOS DIGITAL REBEL XTi\CF\DCIM\334CANON
...and an iPod.
Desktop\My Computer\Harlan s iPod\Internal Storage\DCIM
Another aspect of ShellBags analysis that can be valuable to an examination is by the analyst developing an understanding the actual data structures, referred to as "shell item ID lists", used within the ShellBag. It turns out that these data structures are not only used in other values within the Registry, but they're also used in other artifacts, such as Windows shortcut/LNK files, as well as within Jump List files. Understanding and being able to recognize and parse these structures lets an analyst get the most out of the available data.
Locating Possible Data Exfil/Infil Paths via ShellBags
As information regarding access to removable storage devices and network resources can be recorded in the ShellBags, this data may be used to demonstrate infiltration/infection or data exfiltration paths.
For example, one means of getting data off of a system is via FTP. Many Windows users aren't aware that Windows has a command line FTP client, although some are; in my experience, it's more often intruders who are conversant in the use of the command line client. One way that analysts look for the use of the FTP client (i.e., ftp.exe) is via Prefetch files, as well as via the MUICache Registry key.
However, another way to access FTP on a Windows system is via the Windows Explorer shell itself. I've worked with a couple of organizations that used FTP for large file transfers and had us use this process rather than use the command line client. A couple of sites provide simple instructions regarding how to use FTP via Windows Explorer:
MS FTP FAQ
HostGator: Using FTP via Windows Explorer
Here's what a URI entry looks like when parsed (obfuscated, of course):
Desktop\Explorer\ftp://www.site.com
One of the data types recorded within the ShellBags keys is a "URI", and this data structure includes an embedded time stamp, as well as the protocol (ie, ftp, http, etc.) used in the communications. The embedded time stamp appears (via timeline analysis) to correlate with when the attempt was made to connect to the FTP site. If the connection is successful, you will likely find a corresponding entry for the site in the NTUSER.DAT hive, in the path:
HKCU/Software/Microsoft/FTP/Accounts/www.site.com
Much like access via the keyboard, remote access to the system that provides shell-based control, such as via RDP, will often facilitate the use of other graphical tools, including the use of the Windows Explorer shell for off-system communications. ShellBag analysis may lead to some very interesting findings, not only with respect to what a user may have done, but also other resources an intruder may have accessed.
Summary
Like other Windows artifacts, ShellBags persist well after the accessed resources are no longer available. Knowing how to parse and interpret this Registry data
Parsing ShellBags data can provide you with indications of access to external resources, potentially providing indications of one avenue of off-system communications. If the concern is data infiltration ("how did that get here?"), you may find indications of access to an external resource, followed by indications of access to Zip file subfolders. ShellBags can be used to demonstrate access to resources where no other indications are available (because they weren't recorded some where else, or because they were intentionally deleted), or they can be used in conjunction with other resources to build a stronger case. Incorporation of ShellBag data into timelines for analysis can also provide some very valuable insight that might not otherwise be available to the analyst.
Resources
ForensicsWiki Shell Item page
Saturday, August 11, 2012
RegRipper Updates
In an effort to consolidate some of the information regarding RegRipper in one consistent location, I started the RegRipper Google Code site. My hope is that this will provide a much more stable means for folks to find information regarding RegRipper.
Now, my setting up this site does not take anything at all away from the RegRipper Plugin Google Code site that Brett Shavers set up...in fact, these two sites will support each other. The RegRipper plugin site will continue to be the location to get the plugin distributions, as this is something that folks are likely to do much more often, once they have the RegRipper suite of tools. However, the point is to have just these two sites so that there is no confusion as to where you can go to get the latest and greatest information about RegRipper, or distribution of RegRipper plugins.
The RegRipper site will be one consolidated location where you can go to get information regarding RegRipper. For example, I've started adding pages to the wiki, such as this one describing the plugin architecture. The benefit of this is that the pages are right there...you don't have to search the blog, or via Google, to find what you're looking for. Also, this allows the information to be updated, but you won't have to search through my blog or some other resource for the information...it will be in one location.
Speaking of plugins, Hal Pomeranz sent me two plugins recently...I took a look at them and forwarded them on to Brett, and you should be seeing them shortly on the plugin site. Hats off to Hal for recognizing that something he saw could be put into a plugin, and for putting forth the time and effort to write the plugins, and share them with the rest of the community.
Also, I've uploaded two plugins to the RegRipper site. One is appcompatcache.pl, which basically was developed from the information available in this Mandiant blog post. Thanks to the great work, and the code that they provided, I was able to put together a RegRipper plugin to parse this same information.
Note: If you're going to use this plugin, and not use the EXE versions of the RegRipper tools (i.e., you're using the Perl scripts), be sure to update your copy of the Parse::Win32Registry module. The easiest way to do this, if you're using ActiveState Perl, is to use PPM:
C:\perl>ppm update parse-win32registry
Note: If you're going to use this plugin, and not use the EXE versions of the RegRipper tools (i.e., you're using the Perl scripts), be sure to update your copy of the Parse::Win32Registry module. The easiest way to do this, if you're using ActiveState Perl, is to use PPM:
C:\perl>ppm update parse-win32registry
The other plugin I uploaded is shellbags.pl, which is in an archive with a readme file...puh-lease read that file if you have any questions at all about the plugin. This plugin parses the Shell\BagMRU shell item information from the USRCLASS.DAT hives from Vista, Win2008R2, and Win7 systems. I had only a limited amount of testing data available (thank you to all of you who sent me samples) when developing this plugin, and most of it was from Win7 systems. I happened to find a couple of hives from Vista systems and one from a Win2008R2 system, so testing was extremely limited. As such, it might have some hiccups on various data types, particularly ones I have not yet seen in testing. If you run into any issues, contact me at the email address listed in the header of the plugin.
The output from this plugin is similar to what you see when you use TZWorks' sbag prototype utility. One notable exception is that when printing the Registry key LastWrite times in the far left-hand column (I call it "MRU time"), I apply that time only to the first value identified in the MRUListEx value immediately beneath that key. Many thanks to Dave and Jonathan for providing their excellent tool.
In developing the shellbags.pl plugin, I had access to a great deal of useful information to get me started. I've begun linking to most of that information on the ShellBags page in the RegRipper wiki, but I do want to thank Willi, Andrew, Joachim, and Kevin for their assistance in this endeavor. Without the foundation that they'd provided, developing this plugin would have been much more difficult. However, the effort put into developing the shellbags.pl plugin doesn't end here...the data structures used in the values beneath these keys are also used in other place throughout Windows systems, and not just in the Registry. However, this does mean that I'll be able to finally finish the comdlg32.pl plugin updates.
In developing both of these plugins, I found some fascinating information. After all, I was working at the binary level, dumping bits of the data to a hex editor-style format, and looking for patterns. For example, when looking at some of the output of the shellbags.pl plugin during development stages, I found that the data within URI types contains an embedded time stamp...including this in a timeline, along side information from the NTUSER.DAT hive from the same user profile proved to be extremely illuminating.
Okay, so why would you care about viewing/analyzing this "shell bags" information? As mentioned here (albeit four years ago...), this information can point you toward a user's access to external storage devices, including external drives, shares, and network resources. I've seen that it can also include devices such as iPods and digital cameras. Fifth Sentinel talks about these artifacts here, and Alissa Torres has talked a great deal about these artifacts at SANS events. If your case involves determining a user's access to resources, this information can be extremely valuable, not only in and of itself, but also when included in or acting as a pivot or reference point during timeline analysis. Combine this information with other data, including documents/files that the user accessed, removable devices connected to the system, Jump Lists, etc., and you can build a pretty interesting picture of user activity. Another thing I really like about this artifact, as well as what's provided via the appcompatcache.pl plugin is that the data persists well after the original resource is no longer available, and some of the data structures include embedded time stamps.
Okay, so why would you care about viewing/analyzing this "shell bags" information? As mentioned here (albeit four years ago...), this information can point you toward a user's access to external storage devices, including external drives, shares, and network resources. I've seen that it can also include devices such as iPods and digital cameras. Fifth Sentinel talks about these artifacts here, and Alissa Torres has talked a great deal about these artifacts at SANS events. If your case involves determining a user's access to resources, this information can be extremely valuable, not only in and of itself, but also when included in or acting as a pivot or reference point during timeline analysis. Combine this information with other data, including documents/files that the user accessed, removable devices connected to the system, Jump Lists, etc., and you can build a pretty interesting picture of user activity. Another thing I really like about this artifact, as well as what's provided via the appcompatcache.pl plugin is that the data persists well after the original resource is no longer available, and some of the data structures include embedded time stamps.
If you have any questions about the two plugins I uploaded, or about RegRipper in general, please feel free to contact me (keydet89 at yahoo dot com).
Subscribe to:
Posts (Atom)