Wednesday, 10 October 2012

SANS Forensic Artifact 1: Open/Save MRU

As most of you would have seen by now SANS posted a fantastic forensic poster for everybody to use which will "map a specific artifact to the analysis question that it will help to answer". Basically what that means is that SANS have 8 categories used to determine an analysis question. "Was the file opened?" for example an analyst could review the 'File Opening / Creation" category which will show artifacts that assist in determining whether files were opened.

We already know there are a number of tools available to us that can easily rip this information to us, such as RegRipper, and countless articles written about each of the artifacts listed. I find however that if you're purely reviewing the output of the tools to identify that a file was opened or that a file had executed in some way you may be missing the context in how that file was opened. Security analysts must ensure they have the technical understanding for each of the tools they run to ensure they can explain the prescence of an artifact, or lack thereof, listed within the output of their tools.

So I thought for my own benefit I'd create a series of blog posts going through each of the forensic artifacts and hopefully providing some examples with screenshots on how each artifact is created. Again there is no better way to understand these tools then running it across your own workstation where you understand exactly what you've done to complete that action. So with that being said lets take a look at the first artifact SANS lists within the File Download category: Open/Save MRU.

SANS lists the following information within the poster.

In simplest terms, this key tracks files that have been opened or saved within a Windows shell dialog box. This happens to be a big data set, not only including web browsers like Internet Explorer and Firefox, but also a majority of commonly used applications.
XP NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSaveMRU
Win7 NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePIDlMRU
• The “*” key – This subkey tracks the most recent files of any extension input in an OpenSave dialog

• .??? (Three letter extension) – This subkey stores file info from the OpenSave dialog by specific extension

So how can we test the information we've been presented with above. The best and simplest way is create a text file called SANS_ForensicArtifact1_MRU_1.txt  and SANS_ForensicArtifact1_MRU_2.txt and open one of them within notepad through the Windows shell dialog box and open another just by double clicking and letting the associated application open the file. We should note the differences in this key from before and after snapshots.

There were a number of ways to export the user hive from my current workstation I decided to leverage of one of my previous posts by using hobocopy to rip it from my live machine. You could use tools such as the built in regedit.exe,  simply run a reg save query from the command line or even use a tool such as ftkimager to get this information.

I ran the following first so that  I could have a comparison. Please note there are two separate commands in the dialog box below.

FOR /F "tokens=*" %%G IN ('dir /b ^"C:\Documents and Settings\*^"') DO .\tools\hob\hobocopy.exe "c:\Documents and Settings\%%G" .\hives\%%G NTUSER.DATregripper command:rip.exe -r ..\..\hives\username\NTUSER.DAT -f ntuser >> username.txt

I searched the output of regripper for OpenSaveMRU and currently it only listed documents that I'd open previously.

Important to note that  from the above example the first key is for objects opened that do not have an extension. The SANS reference below indicates the following "The values stored in the key itself are items that do not have file extensions associated with them. Since most files have extensions, what often ends up here is auto-complete information".

The '*' key indicates the last 10 files opened through the windows dialog box regardless of the extension it has. This can assist us with determining the opening order of each of those 10 files listed. Finally there is a key for each of the extensions opened and in this case we are only concerned with the txt so that we can use our example above. Lets open our file created above and I'll also open a secondary location with a file that has no extension in c:\blogmrulocation\test_noext

As you can see from the screenshot I've opened the file named SANS_ForensicArtifact1_MRU_1.txt. I also opened the file with no extension. For compasion I also double clicked on SANS_ForensicArtifact1_MRU_2.txt (i.e. did not open through windows dialog box) so that we have a  comparison to work with.

Lets run the script again to dump my hive and process it with regripper.

As we can see the only files listed are the ones that we opened through the windows dialog box and there is nothing currently listed for SANS_ForensicArtifact1_MRU_2.txt. As I ran the RegRipper plugin with the -f ntuser option selected it will parse my ntuser.dat file against a number of different plugins and enter the output in the same text file. I decided to search for the second file opened through double click to see where we had references for it.

Although the above keys have nothing to do with my current post (although we'll hit on them later) its important to note that our actions have modified another area within the system so now we not only understand how to review items opened within the windows dialog but we also have some clues how we can identify items not opened by the dialog.

None of this information above is rocket science by any means and as listed from the SANS reference below the information has already been provided by Chad Tilbury who has written an excellent article on these registry keys. What I do hope to provide to you from this is post is some practical examples and comparisons between what we saw before and what we saw after the files were open. The next time we run the tool rather than accepting the output for what it is we'll have a deeper understanding and hopefully revert back to our example to assist with better understanding and gathering context to an incident where we do not have the luxury of understanding how or why a file was opened and therefore need to piece our view of the world back together.


Friday, 5 October 2012

The Carbon Black Test Drive

 Many of the readers of this blog have most likely heard of Carbon Black by now. Carbon Black describes its product as "the world’s first ‘surveillance camera’ for computers". Carbon Black highlights five key elements that it can monitor which are

1. A record of execution
2. A record of files system modifications
3. A record of registry modifications
4. A record of new outbound network connections
5. A copy of every unique binary executed

We're all aware that antivirus and signature based detection methods are no longer keeping up with the huge amount of samples produced every day. Carbon Black recently posted an article called Second AV Study Reveals Small Window For Catching New Malware which caught my eye. The article highlights that using multiple AV products provides better ability to detect a malicious sample which makes sense to me. The article highlights that running multiple AV on a workstation is obviously a nightmare so instead they developed a plugin which uploads binaries to VirusTotal to leverage multiple AV.

Based on the above I thought that it might be time to download the trial and better understand what this tool could do. Although there are some amazing articles written on Carbon Black, see links below, nothing is better than getting hands on with the tool. Signing up for the trial was quick and easy and before I knew it I had downloaded the CB server and installed. Upon logon I was presented with the following screen.

My test lab is fairly unsophisticated in its approach but it should be enough to get a solid understanding of what CB can do. The next step for me was to create the client package so that I could install this on my Win XP test machine. As you can see from the screenshot its very simple, you hit the 'generate' button and before you know it you have your client. I installed this on my machine and within minutes I started to see results within my console.

Carbon Black offers a number of plugins and some of which I've mentioned above. In particular I was most interested in the 'droppercheck', 'virustotal' and the 'autoruns' plugin. See the below screenshot.

Droppercheck was as simple to turn on as selecting the checkbox however the other plugins had a number of options to configure. Within minutes I had all the plugins that I wanted activated successfully.



Once the client was installed I thought the best way to test it was to start hitting sites listed on malware domain list and see that what samples I could download to my test workstation. After spending a few minutes hitting random URLs I managed to get a malicious binary to download to my test workstation.

Now that I had my malicious executable I was keen to understand what the virus total plugin had detected.  First I checked the summary of the virus total plugin. I could see some detections already

 I clicked on the infected binaries link and was presented with the following screen

Clicking on any of the links I could see the virus total results. I also checked the status of my virus total account and whether it listed the files that had been uploaded under API submissions and sure enough I had some results there also.

So from a virus perspective its safe to say that Carbon Black is providing a significant benefit to organisations. AV is far from perfect and its struggling to keep up with samples so to have the benefit of running your files against virus total automatically and having access to all of the autorun type registry keys I see as a huge advantage. Too often these days I see a huge amount of faith put in a tool that should automatically detect malicious activity based on signatures or patterns. I like that Carbon Black provides me with a means to access the information that is important to me or my employer. This also made me wonder what other information I could source from the tool. I knew that i'd run some SysInternal tools and I wondered what information I could find in regards to this.

I decided to look up *sysinternals* within the registry modifications search and the first three entries showed the MUI Cache entries for each of these tools.

As the links have highlighted below Carbon Black offers much more than just searching for malicious executables or an indication of persistance. Information that we typically wouldn't have access to until a forensic investigation is now available to us in the form of a easy and fast search option to confirm the state of our environment across our entire fleet.

I would be keen to understand the amount of bandwidth and storage to maintain this solution over long term for a large global organisation. I would consider that in comparison to SIEM type tools or full packet capture the footprint would be relatively small. Do any of you have some success stories in large environments?

Well I hope you gained something from this post. As always I'd be keen to hear anything from my readers in regards to their successes or issues with this tool.

Some other articles written on carbon black