mitec registry analyser - santa clara...

MiTeC Windows Registry Analyser. Interpretation of Output

MiTeC Registry Analyser

**The following information is an interpretation of analysis work done by Allan S Hay and all output

from Windows Registry Analyser should be verified by carrying out your own tests.**

Windows Registry Analyzer is tool for reading, viewing and forensic analyzing of Windows registry hive files (e.g. NTUSER.DAT etc.). It's compatible with all registry versions on Win-dows 32bit platforms. It has an incredibly powerful search facility which populates its hits in a navigable output. WRA should be viewed as strong corroborative evidence of a users activi-ties. The program was initially authored by Michal Mutl at MiTeC as a stand alone Registry Viewer. My thanks to Michal who has taken on board my requests and produced a fantastic tool to assist those involved in the Forensic Computing community. The enhancements to his product came about as a result of my involvement in a P2P based case involving CP. Due to the nature of the enquiry I began to see far too many references to CP in the Registry, and well the rest is history. I do not want to delve into the Registry in great detail. What I am going to concentrate is simply what we are looking at in Registry Viewer, how it got their, and how you can replicate this on a local system to validate your findings. This program will analyse NTUSER.DAT files from a Windows Registry. It will also handle all other Registries, though in a Windows 9X System.DAT and USER.DAT the functionality is lost as several components highlighted later on are not available for interpretation. Furthermore, the program has been enhanced to accept NTUSER files which are from System Volume Information (System Restore). Before I go into Windows Registry Analyser I am going to cover how we can examine any multitude of NTUSER files, by extracting the information from the mounted volume. Apologies for anybody not used to EnCase.

SYSTEM RESTORE POINTS

The following is a hypothetical scenario in the day of the user 9AM Browse Internet for images 11AM Play a PC Game 1PM Access CD with CP Images 3PM Install new game onto PC and commence playing PC 5PM Browse Internet for images 7PM Install software for Digital Camera 9PM Browse Internet 11PM Commence use of History Erasing Software and shutdown PC


Nothing out of the ordinary for a sad person, but this is where I made the discovery. The cleaning is only done on the active accessible files. You can guess the files that the majority of cleaning software deletes. I’ve tried several different products, Evidence Eliminator, EastTec Eraser, and Windows Washer. All products only clean active and accessible files.

The wonder of XP is that it automatically creating Restore Points when software is installed, hardware is installed, System Checkpoint invoked by the PC, or the user selects a Create Restore Point. The re-store is a snapshot of the system and therefore when created becomes a protected system file. It is another NTUSER file (shrouded) in the System Volume Information. It can be accessed manually, but only by quite a convoluted process. So when the user asked the history erasing software to clean the machine, it did what it was asked to do, but it couldn’t access the Restore Points. When the Digital Camera software was installed at 7PM all the activities of the user found in the registry were all bun-dled into a Restore Point. The software cleaned all the entries in the HKCU profile, but it could not access the Restore Point. In EnCase, navigate to C/System Volume Information. Within this folder resides the Restore Points available for interpretation. Each of these Restore Points contains files which are snapshots of the various parts of the system. Of note the main file of interest is the NTUSER.DAT file. You will see RP1-RP-200 etc, drop the folder so you can see Snapshot. Highlight Snapshot and you will see several Regis-try Entries. You are interested in the _Registry_User_NTUSER ( SID Number) . The file should look similar to: _REGISTRY_USER_NTUSER_S-1-5-21-436374069-1957994488-1343024091-1003 The NTUSER.DAT file should be checked in the text panel in EnCase to ensure you have the correct account. At this point you can either Right Click select View File Structure, or copy to a folder for Windows Registry Analyser and treat as a normal NTUSER.DAT file. In my trials I have found that not all Restore Points will open so don’t be disappointed

WRA INTERFACE


USER ASSIST KEYS

Open WRA and select an NTUSER.DAT file by navigating to it. The screen should populate as was seen earlier. On the TOOLS tab select from the Drop Down List; Spy and Analyse / User Assist. WRA should quickly populate a panel with the RAW and Decoded data from the User Assist keys. Where dates are given after decoded entries, these are the times that the files were Accessed. You will note that some entries in the User Assist keys have a strange date of 1601. Work is being undertaken to rectify the problem.

The User Assist Keys are essentially keeping track of recently accessed EXE and LNK files which are being populated in the panel below.

The Keys values are kept in 2 Sub keys in the path Software /Microsoft/ Windows/ CurrentVersion/ Explorer/UserAssist/ %N%/Count. The values are encoded with ROT 13 which essentially rotates the 13th Charac-ter, so A becomes N and so forth. The first Count Key in User Assist always contains URL records. I am not able to determine why only some of the URL records are be-ing displayed in here. The second Count Key contains references to LNK files along with EXE files. I have tested accessing a LNK via my desktop to an EXE in the path C/Program Files and the entry appears in the User Assist for an LNK access and EXE access. Where you have a time for the LNK and the EXE within seconds, it’s a good pointer that the user accessed an Executable via the Shortcut.

UserAssist File: C:\WINDOWS\ERDNT\29-11-2004\Users\00000001\NTUSER.DAT Found Username: ASH Created: 29/11/2004 23:03:19

Raw HRZR_EHACNGU:P:\Cebtenz Svyrf\NpprffQngn\NpprffQngn Ertvfgel Ivr-jre\ErtvfgelIvrjre.rkr

1D 00 00 00 07 00 00 00 D0 B8 59 84 65 D6 C4 01

Decoded UEME_RUNPATH:C:\Program Files\AccessData\AccessData Registry Viewer\RegistryViewer.exe

29/11/2004 22:48:17

The NTUSER Path and File being examined

Report Time

Computer User

EncodedROT13 DecodedROT13 Access Date and Time


STREAMS MRU.

These keys contain some interesting facets of information. I have carried out extensive re-search into why a key is entered into the Streams. Several scenarios exist where entries can populate the keys. Suffice to say these entries do occur, under the following circumstances. When a user inserts a CD into a CD tray and accesses a folder thereon, and entry is made in the Streams. When a user opens a folder on a USB Thumb or Pen Drive the values are re-corded in the Streams. When a user accesses a folder via a network, the entries can be popu-lated in the Streams. The largest Streams entry I saw in doing tests ran into the 200’s What is actually captured in the Streams are the date the folder was accessed, the directory in which the folder was resident, the Creation Date and Time of the folder, the sub folders ( if accessed) their Creation Dates and Times, Modified Times and a snapshot of the Last Ac-cessed Date. To get a better understanding of how we derive the data output in WRA it is best to start at a basic level so you can understand why the results are populating in the panel. Below I will show several screen captures of WRA highlighting the data in a Stream. There are two keys, Streams and Streams MRU. Each references each other to derive data. Navigate to this path Software / Microsoft / Windows / Current Version / Explorer.


Below is the breakdown of a Stream Entry

The following images show using Craig Wilson’s Decode, how the dates are arrived at. For some reason Microsoft bundles the Last Accessed Date next to the Creation Time of the file. WRA tabulates the en-tries to read in a logical format. The figure below depicts where the Last Modified Date is derived.


The figure below depicts the Creation Date of the file and the erroneous recurring 23:55 time.

The figure below depicts the Last Accessed Date and the Creation Time. All the images depicted should now tally correctly with the output in the lower pane, highlighted with a red line.


The last image shows the date the volume was accessed. The Stream MRU entry gets cross referenced to the Stream. In this case we were looking at Value (2). By right clicking on Key 2 in the Streams and selecting Properties, the value of the Time Accessed is displayed. The figure below depicts where the Last Modified Date is derived.


SHELLBAGS

Windows by default will keep 400 Folder sizes, though a user can configure for more entries. When a user opens a folder for example in a Windows XP OS, Start / My Music, resizes the folder win-dow, and closes the folder, opens the same folder again, and Windows remembers the folder dimen-sions. Some of these folder sizes are recorded in the Bags. You can find the entries on a mounted NTUSER registry @ Software/Microsoft/Windows/Shell (or) ShellNoRoam/Bags My preliminary findings are that the values associated with the keys contain files or folders that have been, or are resident on a drive. It does not merely pertain to local drives but also that of attached drives (USB, Pen) and Networked Drives. Windows does not always capture the data in these bags, and I am as yet unable to determine why only several bags contain information. What Windows will actually capture( ShellNoRoam/Bags) is the folder or file attributes within that folder, along with the Created Date and Time of a file embedded within the folder. Even if the folder and contents were overwritten/erased the bags contain the name of the path of the Accessed Folder, File Name, Creation Date and Time, and a snapshot of its Last Accessed Date. My footnote on Page 14 highlights the differences in the Bags. Bag Entries have the following structure 1. Most Entries start with a solitary integer. 2. Carry 3 bytes 3. Followed by 4 bytes which is the Last Modified date. 4. Carry 3 bytes, then the next 4 bytes are the start of the Short DOS name. 5. Carry 8 bytes 6. The next 4 bytes, which are the Creation Date of the File and erroneous time (23:55). 7. Followed by 4 bytes, which is the Last Accessed Date (snapshot) and Creation Time of File 8. Carry 6 bytes 9. Followed by Long File Name 10.Carry 20 bytes, end of entry. Open an NTUSER file with WRA and via the Tools / Spy Analyse. The next image shows a full ShellNo-Roam Bag with all its attributes.


To see where the data is derived from I will take you through the process of how WRA interprets the findings. Each ShellNoRoam Bag which has an entry will be identified by the ITEMPOS key being pre-sent as a value in the key. In the image below I have requested a search across the whole NTUSER file for the term ITEMPOS. The results have been displayed in the lower panel and I have selected entry 109.


By double clicking on the entry at 109 the Data View window is expanded to show the full entry for the ShellBag. Below is an image with the breakdown of a ShellBag. Using Decode you can verify the con-tents if you wish.

Short DOS Name

Last Accessed Date and Creation Time

Long File Name

Modified Date

Creation Date

I will now endeavour to explain how the path is shown in the output of WRA, because it is not embed-ded in the actual ShellBag. Each entry in the ShellBags conforms to a Directory which in turn addresses a node. I highlighted ShellBag 109 and I will now return to its entry. Software\Microsoft\Windows\ShellNoRoam\Bags\109\Shell\ItemPos800x600(1) Directory of C:\Documents and Settings\Administrator\My Documents\My Pictures We are now going to do an exercise similar to dot to dot. We return to the ShellBags to determine where the Volume Directory is.We navigate to the Root of Bags MRU and drop each key till you find the

entry for Volume ‘C’ in this case. The entry is at ShellNoRoam/BagsMRU/1. Note that in the next image in the Data View window the Value Name is 2.


By navigating to entry 2, which in the tree is one below, we can see an entry at Value 1, for Documents and Settings. Therefore the path so far is C/Documents and Settings. Note the value name is 1.


By navigating to Subkey 1, which in the tree is 2 below the key, we can see an entry for Administrator. Note the Value Name 5. We now have the path C:/Documents and Settings/Administrator.

By navigating to the Subkey 5, which below Key 1, there is an entry for My Documents. Note the Value Name 2. We now have the path C:/Documents and Settings/Administrator/My Documents.


By navigating to SubKey 2, we can see an entry at 0 for My Pictures. Note the Value Name 0. We now have the path C:/Documents and Settings/Administrator/My Documents/My Pictures.

By navigating to the SubKey 0 in the Key of 2, we select the Node Slot by double clicking on it. The DataView brings up a HEX value of 0000006D. Select the Radio Button ‘ Decimal’.


The Decimal interpretation is 109. If you navigate to Bags 109 you will see it is the entry we began with.

Below is an interpretation of the results as output via WRA . Software\Microsoft\Windows\Shell\Bags\1\Desktop\ItemPos1024x768(1) : Since the desktop is a folder, this is a snapshot of what the user had on their desktop. You may see several entries, this is due to differing screen resolutions. Software\Microsoft\Windows\ShellNoRoam\BagMRU\ : These are singular entries of folders accessed. Software\Microsoft\Windows\ShellNoRoam\Bags\***\Shell\ItemPos1024x768(1) : Where *** is an Integer, this relates to the whole contents of a folder when it was accessed. Software\Microsoft\Windows\Shell\BagMRU\ : These entries occur when the folder is via a network access. If you have any problems with interpretation of any of the results output by WRA you can contact me via email, or leave a private message on either the Digital Detective BB, or Guidance Software BB. Allan S Hay December 2004 [email protected]