You are here: 42 Resources Blog

42 LLC

SANS

The Answer

Forensics, Security, Law

Oct 07
2009

Shell BAG Format Analysis

Posted by Yogesh Khatri in WindowsShell BagsForensicsEnscriptartifacts

Yogesh Khatri
Windows uses the Shell BAG data to arrange folders and files in Explorer views, as well as to monitor recently used and frequently used applications in the Start-Menu among other things. Forensic experts use it to find traces of deleted file/folders with associated MAC times and file paths. It even tracks network paths and paths on external thumb drives that were once plugged into the machine.
 
When I started this research, I didn’t know of any product nor any freeware or documentation that explains the BAG format, so I decided to reverse engineer it myself. However since, I have learnt of a paper presented this year that talks about the BAG file and its usage to recreate user activity at the DFRWS conference. They have a tool called TraceHunter, available on request only, but no available documentation on the format. I haven’t seen the tool yet. Update: I have been informed by the folks at tracehunter that they will not be giving me a copy!
 
I have read on a blog that a once freeware tool to accomplish this was bought by Paraben and incorporated into their product ‘Registry Analyzer’ which is now called P2 Commander ($129). 
 
About the BAG format
It is prevalent in all windows versions since XP and is used in following registry keys:
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Bags
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\BagMRU
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\Bags
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\BagMRU
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\StreamMRU
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
Vista and Windows 7 have these additional locations (updated)
  • HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags
  • HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU
  • HKEY_CURRENT_USER\Software\Classes\Wow6432Node\Local Settings\Software\Microsoft\Windows\Shell\Bags
  • HKEY_CURRENT_USER\Software\Classes\Wow6432Node\Local Settings\Software\Microsoft\Windows\Shell\BagMRU

My Research
Very little has been known about the technical specifications of the Shell BAG format. I present my research and an Encase script to parse NTUSER.DAT hives and extract the data. The source code is a mess right now and many things are hard-coded, so I have not made it available yet.
 
I have been able to understand the basic format, although there seems to be quite a few variations of how it’s used in the different registry keys and at different levels, ie, it varies depending on whether the BAG artifact is from a file or folder, regular file or ZIP file, etc.. Sometimes GUIDs are used (instead of filenames) for well known items like Control Panel as well as application created shortcuts.
 
Structure Format 
 
struct BagFile {
USHORT BagSize; // Length of BAG structure
USHORT flags;
DWORD size;
USHORT ModifiedDOSDATE; //Modified Date GMT
USHORT ModifiedDOSTIME; //Modified Time GMT
USHORT FlagUnknown;
char  name[]; // (DOS short filename)
//extra byte here sometimes to align to even byte boundary
UnicodeBagData UnicodeData;
};
struct UnicodeBagData
{
USHORT LengthOfUnicodeStructure;
USHORT Short1; // 0x0003 for XP, 0x0008 for win7
USHORT Short2; // 0x0004
USHORT Short3; // 0xBEEF
USHORT CreatedDOSDATE; // Created Date GMT
USHORT CreatedDOSTIME; // Created Time GMT
USHORT AccessedDOSDATE; // Accessed Date GMT
USHORT AccessedDOSTIME; // Accessed Time GMT
DWORD Unknown; // usually xp = 0x14, win7 = 0x2A
 // Vista and Windows 7 Extra Fields (22 bytes total)
  DWORD  MftFileId;
  USHORT Unknown1;
  USHORT MftSequence;
  DWORD  Unknown2;
  DWORD  Unknown3;
  DWORD  Unknown4;
  USHORT Unknown5;
// END Vista extra fields
wchar name; // Unicode Filename
USHORT Unknown6;
};

Although this is the basic format, there are several variations depending on flag values.  The elements are likely contained in more structures nested within, hence the variations.

In the StreamMRU values, many such BAG structures are chunked together into one reg value, which represents the full file path.  For example, if a folder path is “C:\Program Files\Microsoft\Office”,  the registry value will have the following data 
[BagFile for C:] + [BagFile for Program Files] + [BagFile for Microsoft] + [BagFile for Office]

All will be appended into the same reg value.

Files vs. Folders
Since BAG data is mostly used by Explorer to remember view settings for each folder, we only find BAG entries for Folder data under ‘Software\Microsoft\Windows\Shell\BagMRU’. Each folder under that key has a NodeSlot value which represents the unique folder number for its settings which are stored at ‘Software\Microsoft\Windows\Shell\Bag’. 

The keys under this key store both file and folder metadata. Any time you move an icon in explorer, its new position in that folder is tracked here. For each NodeSlot value in BagMRU, there is a folder with that number as name. Not all views are tracked, so you will see some empty folders under this key and some with many values. One of these values will look like “ItemPos 1024x768(1)” or whatever your screen resolution is at the time of the event. There can be multiple of these items for multiple monitors, change in screen resolution, etc.. The ItemPosxxx key consists of many BAG structures appended together. Unlike StreamMRU, these don’t represent a file path, they are simply metadata for all the files/folders in that particular folder that it represents.
 
BAG Data Organization
The data is organised exactly as it appears in Windows Explorer, with the desktop being the root folder of everything.
 
 
The paths inside BAG files will have many redundant entries pointing to the same object in a different view depending on whether you browsed to the 'desktop' folder from C:\Documents and settings\... or directly accessed it from the Desktop, or from My Computer\Shared Documents\.. and so on.
 
Example: Redundant paths for an XP machine
Desktop\My Computer\C:\Documents and Settings\ProfileName\My Documents\..
Desktop\My Documents\..
Desktop\ProfileName's Documents\.. 
Desktop\ProfileName\My Documents\..
 
Script
This script (download link below) parses the data from an image or an NTUSER.DAT file. It tries to remove all redundant paths (removing duplicates), althought sometimes you would want that (dates/times on the duplicate entries may be different). 
 
Ideally, you want to run this against a full disk image (just because it tries to resolve ProfileName if not found in registry hive), but it will parse out individual NTUSER.DAT files also. It will process profile hives stored under System Volume Information (System Restore) also! It has been mostly tested on XP but has been tweaked to run on Vista and Windows 7. 
 
 
Update: There appear to have been quite a few additions to the format with Windows Vista and 7. Also a new location for these entries:
 C:\Users\ProfileName\AppData\Local\Microsoft\Windows\UsrClass.dat
The additional paths are noted in section above in "About the Bag format".

Oct 06
2009

Context Carver V1.0 - Physical Offset Reporting Bug

Posted by Nick Ringold in Untagged 

Nick Ringold
We have located a bug in the Context Carver this past week regarding the naming of the carved files output from unallocated space. These are files with a "P" in the file name, in the format Filename.[P#####].txt.

These numbers are meant to be the Physical Byte where the block of carved data starts on the disk, but we have found an error in the logic which generates the number.

Instead of generating the correct number, the math is taking the initial byte of the unallocated space and adding EnCase's logical offset within the "file". Because EnCase treats the entire unallocated space as a single file, these numbers will not match up due to the way the unallocated space is fragmented.

We are working to correct the bug and will release an update as soon as we are happy with the fix, but until then, you can use the following to determine the originating location of a carve block or you can download the attached spreadsheet.

X = Number following the "P" in the file name

[Graphic Coming Soon]

Y = "Physical Location" field within EnCase's table view from Cases --> Entries tab for the unallocated "file" the carve originated from

[Graphic Coming Soon]

X - Y = Z

Z = Logical Byte Within unallocated "file" as defined by EnCase. You can access this by selecting the unallocated "file" in the table pane, then right-clicking in the view / text pane and select Goto. Enter this number into the field.

[Graphic Coming Soon]

The carved blocks are still working as intended and carving data correctly based on the located keywords.

We apologize for anyone who has had issues due to this bug and we hope to have a corrected version of the script out soon.
Jul 07
2009

Using robocopy for network collections

Posted by Chris Pavan in robocopyForensicsediscoverycollectionacquisition

Chris Pavan

Too often we come across systems that the traditional tools just can’t handle. For example, if you have ever had to deal with a NetApp you know that you can’t just pull out the disks, image them, and then try to rebuild the RAID later. One option when you can’t remove drives is to try and get a shell on the appliance, but many times that is not an option either. When the only documented access to data is through a Microsoft network share, one of the best options is to use Microsoft’s robocopy utility. robocopy allows you to copy files across the network via mapped shares making it a great solution to this ever-growing problem of proprietary network storage systems. And it allows you to maintain time stamps and does its own limited data verification.

Download the Windows Server 2003 resource kit from the following location:

http://www.microsoft.com/Downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en

 When you install the resource kit, be sure to read the End User License Agreement (EULA) and ensure that your use will not violate the agreement.

 Because we are going to write out files directly to another disk and not into a forensic image file format you will need to ensure that you have properly prepared a target drive to store the files on. Prepare your target hard drive by wiping it with the hex pattern \x00 and verifying that the data has been successfully wiped. Once the process of wiping and verification has completed, format the drive with the NTFS file system.

 The next step is to turn off or disable all applications that might scan or affect the data that is being written to your target drive. In particular you will want to turn off active scanning of files by your anti-virus software and disable any power saving features, such as allowing the system to turn off hard disks or putting the computer to sleep. The ultimate goal here is to make sure that the process is not interrupted and that the data is transferred in as pristine a state as possible.

The easiest way to copy files from a network drive using robocopy is to first map the drive on the local system. Be sure to keep good notes on how you mapped the drive such as server name, share name, IP address, user name, etc. It is not necessary to record the password to the share, and if you do, it should be changed so it does not pose a security risk to your organization or client.

On your target drive, create a folder named after the server that you are copying the data from. Inside that folder create another folder with the share name. This structure allows you to copy files from multiple shares on the same server preserving relationships and structure.

For this scenario we have mapped the source \\co_fileserver\profiles to drive letter s:\. Our target drive was connected via USB and was automatically assigned drive letter t:\. On our target drive we created the folder structure t:\co_fileserver\profiles for us to point robocopy to.

The following command will copy everything from the source drive s:\ to the target drive path t:\co_fileserver\profiles:

robocopy s:\ t:\co_fileserver\profiles /E /COPY:DAT /R:3 /W:3 /V /TS /FP /NP /LOG+:t:\co_fileserver\profiles.log /TEE

Here is the breakdown of the options that were used

/E Copy everything including empty directories.

/COPY:DAT Copy the Data, Attributes, and Timestamps of the files and folders.

/R:3 If a file is locked retry copying a total of three times.

/W:3 Wait three seconds between each retry when retrying to copy a file.

/V Provide verbose logging.

/TS Include the timestamps of the files in the log.

/FP Provide the full path of the files in the log.

/NP Do not display progress. This will fill up your log if left out.

/LOG+:t:\co_fileserver\profiles.log Create a log of the activity in the path t:\co_fileserver\profiles.log. The + tells robocopy to append the log. If you leave this out robocopy will overwrite the log if it already exists. By leaving it in you don’t accidentally overwrite any of your previous work.

/TEE Output the progress to the screen as well as the log. This is a good option so you can see that the application is making progress.

You MUST review the log before leaving the site. If there was a file locked open by another user during the copy process, robocopy will fail to copy that file and will log the result. You will have to get the user to release control of the file and rerun robocopy again, this time specifying the file that you want to copy. An example of when you will most likely run into this is with PST files. If a user has Microsoft Outlook open the PST file will be locked because it is being edited. Have the user close the application and retry copying the file again using the same syntax as before, only this time add in the full path to the file. It may require some investigation to determine who has the file open if it is not within a specific users file share.

Search through the log for the following entry: ERROR: RETRY LIMIT EXCEEDED.

Just above this entry you will see what caused the failure. You may also want to search through the log for the word ERROR in general just to be sure there were no other issues.

2009/06/30 17:51:47 ERROR 33 (0x00000021) Copying File s:\suzie\Email\archive.pst

The process cannot access the file because another process has locked a portion of the file.

ERROR: RETRY LIMIT EXCEEDED

Rerun robocopy once you have taken steps to unlock the file, this time you only need to grab the file archive.pst. You can simply do this by putting the filename in after the destination, but this will cause robocopy to rescan the entire drive looking for files named archive.pst that haven’t been copied yet which, depending on the size of the drive you are scanning, could take a while..

robocopy s:\ t:\co_fileserver\profiles archive.pst /E /COPY:DAT /R:3 /W:3 /V /TS /FP /NP /LOG+:t:\co_fileserver\profiles.log /TEE

robocopy will not recopy a file that already exists, so you don’t have to worry about collisions. The recommended way is to be more specific and put in the full path information for source and destination.

robocopy s:\suzie\Email t:\co_fileserver\profiles\suzie\Email archive.pst /E /COPY:DAT /R:3 /W:3 /V /TS /FP /NP /LOG+:t:\co_fileserver\profiles.log /TEE

Once you have gone through your log and ensured that you have successfully copied all of the failed files then your collection is complete.

The final step

As soon as the copy is complete disconnect the target drive from the computer and reconnect it to your examination workstation via some means of write protection. Fire up EnCase, FTK or your preferred imaging application and preview the drive. Create a logical evidence file of the contents of the drive if possible. Both EnCase and FTK have given us issues when there are large numbers of files, so you may want to create multiple logical evidence files, one for each share. Additionally, you can also create a full disk image such as an EnCase evidence file (E01) for the entire drive and use that for preservation / analysis. This is one of the more critical steps in the process as this becomes the baseline of your collection. Provided you properly wiped the drive before hand, there should not be any data on the drive other than what was copied by robocopy.

Jun 18
2009

GMail Mailbox List Parser

Posted by Chris Pavan in gmailForensicsEnscriptartifacts

Chris Pavan
As a part of a case I was working on I needed to parse all of the GMail artifacts on several different hard drives. If you use GMail you are used to the preview you get when you view your Inbox. That preview (which is a JavaScript) is the only thing that actually gets left behind by Google, but it has some interesting artifacts in it.

Here is what you will typically find in a GMail mailbox listing:

• From - Who sent the message
• Subject - Subject of the message
• Preview - Snippet of the email message
• Attachments - Listing of the attachments with the message
• Short Date - Time if being viewed on the same day, month and day otherwise
• Long Date - Full date and time of when the message was sent
• Number of conversations - Count of messages that are a part of that thread

I wanted to search the entire drive for this artifact and parse the information so I asked Yogesh to create an EnScript for me. The script will only work properly in EnCase 6.12+. DOWNLOAD HERE

Make sure you have all of the items you want to search and parse blue checked (i.e. blue check everything to search the whole drive) and then run the script. Don't worry if the status bar hasn't moved, that is due to us not having time to code it. Once the script is done searching a dialog window will popup with the listing of the entries found. This view is similar to the table pane and if you blue check everything in this view, then right-click and choose Export, you can dump the list to a tab delimited file.

This is in Beta at the moment so if you find any bugs please let us know.

Jun 18
2009

Forensic Imaging of RAM on live Linux systems

Posted by Chris Pavan in RAMlinuximagingForensicsacquisition

Chris Pavan

During CEIC this year I had a couple people come up to me and ask how to create an image of RAM on a Linux computer. Recently there have been a lot of tools created that gets the job done in Windows, but there is nothing really out there for Linux.

 I created a knowledgebase article that goes into detail on how to handle imaging RAM on a Linux system. I also cover how to use netcat to send the image across the network to a remote computer. The article can be found HERE.

 The basic command you are going to run is:

dd if=/dev/mem bs=4096 conv=noerror,sync | tee >evidence.dd | md5sum >evidence.hash

By using tee the data is written out to a file as well as passed down the pipeline so it can be hashed. Once your image completes, run md5sum against the output file and compare that to the hash originally created. If they match you are good to go.

If you want to send the data across the network get netcat listening on your target computer:

nc -l -p 5000 >evidence.dd

On the source computer use the following command:

dd if=/dev/mem bs=4096 conv=noerror,sync | tee >(nc -w 5 target_ipaddress 5000) | md5sum

Make sure you record the MD5 hash value when the process completes and then hash the output on the target computer and compare the two.

 There are also some issues with block sizes that you may run across that I cover in the knowledgebase article.

Incidentally, you can do the same thing with disks, just change the device (e.g. /dev/sda) and now you are taking an image of the serial attached hard drive sda. I am working on another KB article that will cover imaging hard drives on live systems with dd.

  • «
  •  Start 
  •  Prev 
  •  1 
  •  2 
  •  Next 
  •  End 
  • »
42 LLC | 2596 Mission St, Suite 203, San Marino, CA 91108 | info@42llc.net | +1 626.698.1189