Daily Blog #59: Understanding the artifacts ShellBags

Hello Reader,
           Another day, another blog. They say if you've done something for two weeks it becomes a habit. Well it's been two months and I will tell you that I know each evening that I should be writing tomorrows blog, but life (and good tv shows/movies) often gets in the way. So I just got back from lunch and its time to push through the remaining usage artifacts so we can talk about the combined analysis of them. I think after I'm done with all of these posts I will feel some feeling of relief but also another separate list of which artifacts I need to go into more technical detail on in the future. Blog posts sometimes just write other blog posts, but mainly your comments are what help drive the direction of my writing. Also please note that if you have not added me to your Google+ circles and made your comment limited, I can't see it.

Let's talk about Shell Bags! Shell bags is one of my favorite Windows artifacts as it reveals so much as to what the custodian was interested in data wise. For a technical primer on shell bags, go here:
http://computer-forensics.sans.org/blog/2011/07/05/shellbags
and
http://windowsir.blogspot.com/2012/08/shellbag-analysis.html

As has been stated shellbags record a users preference for each folder viewed within the gui explorer. That is important as the only ways to get around a shellbag in viewing folders that I know of is to:

• Load a command prompt
• Utilize a third party file system navigation tool
• Browse for files inside of an application that does not use the win32 browser call

Otherwise, if a folder is accessed and viewed within the GUI a shellbag entry is going to be made to record their preferences. As a by product of storing those preferences (item list type, window size, sorting) it also stores the MAC times of the directory, the full path, the last time of update to the registry key and in Windows 7 the MFT record number. 

For the most in depth treatise on the shell item format and how its changed between Windows versions read this: https://googledrive.com/host/0B3fBvzttpiiSajVqblZQT3FYZzg/Windows%20Shell%20Item%20format.pdf

This is important. Why you ask? While full paths are great for static drive letters, without volume serial numbers (as we find in LNK files) we have no way to uniquely match them to removable devices without doing some deep timeline analysis showing what was attached at what times. With the addition of the MFT record number (consisting of the entry number and sequence number) which will allows us to identify uniquely the directories and files being recorded in the shellbags to the directory/file located on external media.

Now I just assumed something of you reader, I assumed you understand the power of shellbags in getting more information about what was contained on removable devices. The shellbag entries are stored on a per user basis and are not limited in scope to just the local disks. Whatever removable or network based storage the user views through the GUI explorer gets recorded. As far as I know, and please leave a comment and correct me if i'm wrong, the shellbags are the only artifact that will reveal the existence of directories accessed without the need of a file being accessed within them. LNK files do get created pointing to directories at times, but not the breadth and depth that the shellbag entries show you. 

So, shellbags are awesome. You should be checking them. 

This is my favorite tool to check them with:

https://www.tzworks.net/prototype_page.php?proto_id=14

Don't exclude them in your analysis just because its not a built in feature of your tool.

Tomorrow we move onward towards more artifacts and greater understanding!

Daily Blog #58: Understanding the artifacts Jump Lists

Hello Reader,
         Another Sunday Funday is behind us and from it I've identified another blog series that need to be written. We are trucking along through the artifacts needed to better understand usage. We've covered LNK files, the USN Journal, USB Stor and User Assist. Today we are going to jump into Jump Lists which first made their appearance in Windows 7.

If you've never heard of Jump Lists before go here, http://www.forensicswiki.org/wiki/Jump_Lists, this blog post assumes you are familiar with them and seeks to help you better understand them. For instance I won't be explaining the difference between automatic/custom jump lists or where to find them and their structures.

If you want to read the most thorough write up of Jump Lists I've seen to date go here: http://articles.forensicfocus.com/2012/10/30/forensic-analysis-of-windows-7-jump-lists/.

An easy way to think about jump lists, though not technically accurate, is a chained series of LNK files stored on a per application basis. The biggest fundamental issue regarding Jump Lists versus the LNK files that analysts know and love is that LNK files where created, stored and maintained for the explorer shell (with the one exception I know of being Microsoft Office). Through program shourtcuts, recent documents, office application documents, etc... there is a shared set of LNK files maintained. Jump lists does not entirely replace this functionality but rather extends it allowing tracking of recently used documents from the registry to individual jump lists on a per application basis through automatic destination files.

In short, if you are analyzing a Windows 7 system and you are not parsing/analyzing the jump lists then you are missing evidence. Many up to date forensic suites are not parsing jump list data structures yet and instead will carve LNK files from custom destination lists. Get a tool that handles them correctly:

TZWorks: http://tzworks.net/prototype_page.php?proto_id=20
Woanware: http://www.woanware.co.uk/?p=265

This is good news for us as that means what documents are being accessed through an application are no longer just maintained in the registry through MRU's and we get much more data to analyze on a per file basis. Some applications, notably Microsoft Office, emulated this functionality through LNK files in prior versions of Windows but Jump Lists extends this through auto destinations. MRU keys only keep the date of the last file accessed for that MRU key and the order of last access, while automatic Jump Lists records the same type of data a LNK files does but extends it.

One of the difficulties investigators have had with jump lists was matching the appid that makes up the jump lists name back to which application it was tracking. Luckily for us Hexacorn seems to have solved this issue and made a perl script for use (Yay Perl!):
http://www.hexacorn.com/blog/2013/04/30/jumplists-file-names-and-appid-calculator/ which will allow you to generate the app-id for any given string.

So in short, and I probably will want to revisit this blog post, Jump Lists extend the analysis you did prior with LNK files and is stored on a per user basis for recent document access like LNK files, but is stored on a per application basis. One of things mentioned between all of the major sources is that jump lists are not deleted when a program is uninstalled and they would not be deleted by any system cleaner that is not 'Windows 7 aware'. So if you are not currently taking them into account in your investigations you should change that today.

Daily Blog #52: Understanding the artifacts LNK Files

Hello Reader,
               Time to continue the series of understanding the artifacts building up to a deeper understanding of proving usage. Today we are going to go into a well known artifact LNK files and them move through Jump lists, MRU keys and the other artifacts we use to establish use and explain how to stitch them together. Along the way we will detail the nuances that can change your opinion or possibly lead to misinterpretation.

LNK files are one the simplest artifacts and many, many, many people have written about them. Here are some of my favorite LNK write ups if you are reading this and are not familiar with them:

http://www.forensicswiki.org/wiki/LNK
http://www.forensicfocus.com/link-file-evidentiary-value
http://windowsir.blogspot.com/2013/06/there-are-four-lights-lnk-parsing-tools.html

The funny thing about artifacts as simple as LNK files is that they reveal as much information to the examiner as they care to know. When I do interviews for a position at G-C I ask a series of questions relating to artifacts and what they mean to the examiner. This isn't a trick question, which I explain to the interviewee, but rather a gauge to determine how far down the rabbit hole the examiner has gone. As an example for LNK files I would ask the following to an interviewee:

'What can you determine from a LNK file'

I can determine the rough expertise of an examiner by how many of the following points they answer with. I then take this in combination with other artifact questions/scenarios and the level of depth they answer to determine their level of forensic experience rather than focus on their resume.

Beginner Answer:
A LNK file reveals what files and/or programs a user accessed.

Intermediate Answer:
A LNK files reveals what files and/or programs a user accessed and the network path and MAC address of the where the access took place.

Experienced Answer:
A LNK file reveals what files and/or programs a user accessed and the network path and MAC address of where the access took place. In addition it contains the timestamps captured from the file and/or program being accessed that represents the file at the time the access took place.

Senior Answer:
A LNK file reveals what files and/or programs a user accessed and the full path\network path and MAC address of where the access took place. In addition it contains the timestamps captured from the file and/or program being accessed that represents the file at the time the access took place. It also contains the volume serial number of the device which you can use to match the LNK back to the volume the file came from if not a network data source. In addition LNK files contain shell items allowing the examiner to determine the type of folder being accessed (volume/network/file/uri).

Expert Answer:
A LNK file contains two sets of timestamps relevant to the examiner. The first set of MAC times belong to the LNK file itself, it reveals by creation date when the file was first accessed as recorded by this LNK file. The modification time records the last time the LNK file was updated and should reflect the last successful access. The second set of dates is maintained within the LNK file and represents the MAC times of the file being accessed based on the last successful access to the file from the LNK file. In order to determine prior states of the file you can examine the restore points (XP), shadow copies (win 7) and carved LNK files to find all the other versions of this LNK file that also reference this file and volume serial number/shell item uniquely. Each updated set of internal MAC times represents another successful access of the file through the LNK File and should be counted towards usage.

Now if you noticed I didn't say the Expert Answer had to go into depth on the technical structure as to what all can be contained within a LNK file, that isn't as important to me as the ability to properly interpret what the data means in the context of analysis. I assume that anyone who can give me an expert answer already has the technical knowledge of the file format to give additional facts when needed, but I find that people who give just technical information are missing the larger picture of what they data means in their analysis and what they can prove with it.

So with that said, tomorrow we will continue on with usage artifacts. Do you think I missed something or do you have an even better answer? Leave it in the comments, I'm always interested in additional views on analyzing familiar artifacts! 

Daily Blog #51: Understanding the artifacts USNJrnl

Hello Reader,
        I'm going to change tracks this week and focus on a deeper understanding of the USNJrnl and its associated artifacts to prove usage from our challenge two weeks ago. To prepare for this series I want to take a bit to explain what each of the artifacts we rely on for proof of usage were created for. When we are complete I hope you will look at your cases in a different way.

Today we are going to talk about the USNJrnl. The USN Jrnl or Update Sequence Number Journal aka the Change Journal was first introduced in Windows 2000 but didn't get enabled by default until Windows Vista (that I know of, please leave a comment if you have evidence of other default states/os's). I have seen it enabled for EFS encrypted drives on XP but I can't say if that's a default setting.The concept of the change journal was simple, many programs need to know when files are changed so they can be backed up, compressed, scanned, replicated, etc...

Prior to the change journal a developer would have to register hooks or shims into the operating system for all reads and writes to be able to be notified that a file is being created/modified/deleted and to process it. The Change Journal gave the developer a central api to monitor that covered all subscribing functions and prevented  a lot of unnecessary overhead. You can read more about the basics of the Change Journal here on wikipedia. The original announcement of it was made in September 1999 and can be found here its interesting that it took as long as it did for it to be enabled by default. You can see that it was being marketed to developers as a way to centrally monitor file system changes and improve performance.


The current change journal development documents are here and if you relying on change journal evidence in your cases you should be familiar with the use case scenario because things are not as black and white as they appear. What do I mean by that? In our testing we've found that a file left open overnight and accessed at different times will create multiple USN open/close/delete events. You cannot rely on the file open and file close times of a file to determine total time of access, it may only be showing you the times of activity against a file that was open the entire time. In addition we've found file close/file delete being used to close a file handle but not to delete the file itself.

I'm going to into more detail of how individual Change Journal operations work and get logged as we move forward so I don't want to get ahead of myself. So in summary remember that the Change Journal keeps track of file system changes for the benefit of those subscribing services. If you are unsure of a pattern of records your seeing the best thing you can do is build a virtual machine and try to recreate those actions to validate your assumptions. The Change Journal is not as simple as we all though it to be! Tomorrow I'm going to continue talking about Usage artifacts and then go into depth on the Change Journal and the rest of them. 

Daily Blog #46: Understanding the Artifacts USBStor

Hello Reader,
               No time to finish my Gmail code review so I'm going to continue the understanding the artifacts posts to keep things going. I got some good responses yesterday from the prolific Joachim Metz regarding what he's seen in User Assist keys which I updated the post to include. The more we share our knowledge with each other the better picture we have of whats true and whats possible, so if you see something you feel is missing please let me know and I'll incorporate it!

USBStor

Most of us doing forensics are familiar with the USBStor key, we look to it to identify USB devices plugged into a system and identify the make, model (unless its generic) and serial number (as windows reports it)  of the device. USBstor also has at least two sister keys IDE (for physical disks) and SBP2stor (for firewire) all of which serve the same purpose. This is one of the first registry artifacts many examiners are made away of as what USB external storage devices have been attached is so important to most investigations. Many times I'm asked as I've stated in the prior post, 'Is the computer logging this to track us? Did the NSA request this feature?'. The answer is, as far as I know, no.

Instead the USBStor and its sister keys are all related to a convenience mechanism to the user that is greatly appreciated. It associates a known device to its loaded driver! Without these keys every time you inserted an external device (USB, eSATA, Firewire in this example), the system would have to look up the driver to load it, check to see if it has the driver and load it. Instead thanks to the caching of known device to driver pairs the device quickly comes up each subsequent plugin.

You might ask, well why does it not stop keeping knowledge of devices after so many days. The answer that its more inefficient to check and expire registry keys and then just recreate them again in the future if the device is plugged in rather than just store it since hard drive space is no longer a premium.

This understanding can help you to explain odd scenarios. For instance lets say a generic USB device was plugged in (many white labeled devices do not identify a specific manufacturer) and from its name you cannot determine what kind of device it was, storage or connectivity of some kind (CDROM, Phone, MP3 player that does not expose its file system). You can look at the driver loaded to determine what functionality Windows made available to the custodian and how the custodian could have made use of it on this system.

It's this kind of deeper understanding that will lead to better explanations, testimony and fact finding. I hope you look to understand deeper and let me know if you think there is functionality that i'm missing in the comments below!

Daily Blog #45: Understanding the artifacts: User Assist

Hello Reader,
              Turns out Gmail is very complicated so I need more time to parse through the javascript and css to find the right code that is rendering the array of emails to view-able text. If you've already done this feel free to leave me a note in the comments below or via email dcowen@g-cpartners.com. So to buy myself some time I am going to fill in with a blog series I plan to interject through the year called 'Understanding the artifacts'.

If you remember from the the milestone series I talked about the importance of understanding now only what an artifact means but why its created, in these posts I will go into detail on what I understand the original intent of these data structures are. If you understand why a developer create an artifact that you rely on you can better predict not only what data should be stored in it but what other artifacts may exist.

This post will focus on the 'User Assist' artifact. There are alot of good posts that explain how to interpret the User Assist registry keys, such as http://windowsir.blogspot.com/2007/09/more-on-userassist-keys.html. http://www.4n6k.com/2013/05/userassist-forensics-timelines.html,  http://sploited.blogspot.com/2012/12/sans-forensshic-artifact-6-userassist.html,  http://forensicsfromthesausagefactory.blogspot.com/2010/05/prefetch-and-user-assist.html and http://forensicartifacts.com/2010/07/userassist/ are just a few examples of the dearth of information available on what it contains, how to parse it and how to interpret it. What most posts fail to address is why is it there at all?

Most times when someone first gets introduced to digital forensics their first thought is 'my computer is spying on me!'. This may seem to be true but the facts are much more simple, the developers who created the operating system and applications you rely on want to give you the best experience possible. In trying to create a good experience they want to make it easy for you to access the documents and programs you use the most.

The User Assist key was created to fulfill one purpose, to populate the start menu list of recently executed programs so you can quickly load them again. This is why it tracks the last time of execution, the full path to the executable and the amount of times the program has been executed. All so when you click on the start button a dynamically sorted list can show the approximately 15 (excluding the possibility the user pinned an application) programs that the user executes most frequently.

In order to be more efficient the developer decided not to limit the amount of entries that could be stored in the User Assist key as you don't want false statistics if a program drops off for a couple months and then gets frequent usage again. For instance the user went on vacation and started playing games daily and not executed Microsoft Word when the user goes back to work the start menu would only display games and not his work tools if the developer limited the number of entries rather than just storing all of them and shorting by number of executions and time of last execution.

This is also why there are two sets of registry keys for User Assist one for program execution and the other for shortcut execution as they are displayed at different points to the user.

Joachim Metz points out there can be more than two though:

" There can be more than 2. I've seen at least 3 different UserAssist subkeys on XP and Vista, and about 8 different ones on Win 8."

Each separate subkey should be divided by purpose, it will be interesting to see for Windows 8 what they are.

So what can we learn from this?

1. We can debunk the idea that something is 'spying' on the user
2. We can explain to clear terms why an artifact is created to a judge and jury
3. We can explain that these artifacts exist by default and have to exist unless disabled and the functionality disabling it removes
4. We can predict what data should be contained within it

I'll see if I can get my code review done this evening and continue the Web 2.0 forensics series tomorrow.