Chapter 2. Index.dat

Transcription

1 Chapter 2 Index.dat

2 Internet History Practical Exercise Anatomy of a MSIE / History.IE5\Index.dat File 1. Use WinHEX to open up the file named: \Student Files\02_Internet_History\Index.dat. 2. Let s examine this file structure First, let s determine the location of the HASH section of the file. The HASH section is not generally of forensic use but we will find it so that we can locate another jump code. Determine the DWORD value file offsets This value is a jump code that points to the HASH section. What is the 32-bit value? Next, jump 16,384 bytes from the beginning of the file.

3 2.3. Next, determine the multiplier for 128-byte blocks that is used to determine the location of the first record entry beyond the HASH section. Get the value of the DWORD following HASH. 32 The calculation is 32 X 128 = Start the jump from the H in HASH After jumping 4096 bytes we land on the first record. What type of record did we land on? (Note the 4-byte record header.) in ASCII URL

4 2.6. The record size is determined by the value of the DWORD following the 4-byte record header multiplied by 128. What is the value of this DWORD for this record?2 What is the size of this record? 2x128= Confirm the record size is 256 bytes and located at file offsets thru using WinHex to highlight data area. Note that another URL record begins after this data block.

5 3. Now let s look at a different record further down in the file. Jump to file offset Note that this is another URL record What is the record size? Determine the value of the DWORD following the record identifier. 4 So then, what is the size of this record size? 4x128= Let s visually confirm the record size by highlighting 512 bytes starting at the beginning of the record. (29696 thru 30207)

6 3.4. Now let s examine this particular record. Note that there are two 64-bit date and time values in this record, one is the QWORD following the multiplier mentioned in the previous step and the second is the second QWORD following the multiplier. We will focus on the second 64-bit date code that is located at record offsets 17-24, however, it just so happens that in this type of index.dat file the two dates are the same. (This is not true for index.dat files located in other areas.) This second date denotes the LAST ACCESS DATE AND TIME (last visit to the address listed in the record). What is the 64-bit date code found at record offsets 17-24? 5/13/ :44:07 Note that WinHex reports the time in GMT Now let s determine the beginning of the URL string for this record. Place the cursor on the first byte of the record (55h in this case) and move ahead 53 bytes With the cursor now on the 53 rd byte note the value of the DWORD at record offsets 53-56? 104 This DWORD value determines the jump size from the beginning of the record to the beginning of the URL string.

7 3.7. So, jump 104 bytes from the beginning of the record and find the following nullterminated string. Note that records found in this type of index.dat file begin with Visited: 3.8. Now let s determine the end of the data block assigned to the URL string. Locate the DWORD located at record offsets This DWORD value determines the jump size from the beginning of the record to the end of the data block that contains the null-terminated URL string. It might be that the data block is larger than the null-terminated string Now jump 236 bytes from the beginning of the record to the end of this data block.

8 3.10. Next, determine the start of the page title, if present. From the beginning of the record, jump the previous value and then skip [jump over] the next 20 bytes (20 is a static number and note the following Unicode value. Note if there is no page title, no Unicode is present.

9 Internet History Practical Exercise Anatomy of a MSIE Content.IE5\Index.dat File 1. Use WinHEX to open up the file named: \Student Files\02_Internet_History\TIF_Cache_Index.dat. 2. Let s examine this file structure First, let s determine the location of the HASH section of the file. The HASH section is not generally of forensic use but we will find it so that we can locate another jump code. Determine the DWORD value file offsets This value is a jump code that points to the HASH section. What is the 32-bit value? Make the jump bytes from beginning of the file Next, determine a multiplier for 128-byte blocks that is used to determine the location of the first record entry beyond the HASH section. Determine the value of the DWORD following HASH. 32 The calculation is 32 X 128 = 4096.

10 2.3. Start the jump from the H in HASH After jumping 4096 bytes we land on the first record. What type of record did we land on? (Note the 4-byte record header.) in ASCII LEAK A LEAK record is an incomplete record; no forensic value, no date and times The record size is determined by the value of the DWORD following the 4-byte record header multiplied by 128. What is the value of this DWORD for this record? 4 What is the size of this record? 4x128=512

11 2.6. Confirm the record size is 512 bytes and located at file offsets thru using WinHex to highlight data area. 3. Next, let s examine a different record, a URL record that begins at file offset (Use WinHex to jump bytes from the beginning of the file.) 3.1. Note the ASCII character string URL<space> at record offsets 1-4. (Don t confuse these offsets with file offsets.) (Note that URL Recovery Tool in Datalifter_V2 carves only URL records but the URL Tool in Bonus Tools also carves REDR. Re-direct records might reveal exculpatory information. Neither tool carves LEAK records these are incomplete records that do not contain dates and times.) 3.2. What is the value of the DWORD at record offsets 5-8 used to determine the multiplier of 128-bytes chucks assigned to this record entry? What is the record size? 3x128=384

12 3.4. Confirm the record size is 384 bytes and located at file offsets thru using WinHex to highlight data area Now let s determine the Last Access Date and time that this particular record was accessed. Again, note that there are two 64-bit date values in this record. In this index.dat file the last access date and time is the seconds date code. Recall that WinHex reports the time in GMT and that no time zone bias is calculated. What is the 64-bit date code found at record offsets 17-24? 9/26/ :43:07

13 3.6. Now let s determine the file size of the referenced file at the time of the last visit. Determine the value of the QWORD at record offsets Now let s determines the jump value from the beginning of the record to the beginning of the null-terminated URL string. What is the value of the DWORD at record offsets 53-56? 104 In this case the file name is IUIDENT.CAB and was 7,893 bytes in size when last accessed Server response code.

14 3.9. Determine the hit rate count from the DWORD record offsets (a static position). What is the hit rate for this record? 4 Note, this count appears to be relative to the current cache contents and resets when the browser is requested to empty the temporary Internet files Determine the active user name (profile) when the cache entry was created. Search the record entry for the hex values 7E 55 3A or the ASCII string ~U: What is the user name for this record entry? dispatch2

15 Internet History Practical Exercise Decoding Internet History Index.dat File Using DataLifter 1. Start DataLifter s Internet History module. 2. (#1) Click on the Browse Folder button. (#2) Navigate to the \Student Files\ 02_Internet_History\Index. dat file. (#3) Click on the Open button. 3. Once the path has been selected click on the Finish button to let DataLifter carve the data.

16 4. Once the results are returned click on File then Export to save out a tab-delimited text file. 5. Enter a filename for the file to be saved, such as history-1.txt and select the folder in which to save it, such as, c:\temp.

17 Internet History Practical Exercise Decoding Internet Cache Index.dat File Using DataLifter 1. Start DataLifter s Internet History module. 2. (#1) Click on the Browse Folder button. (#2) Navigate to the \Student Files\ 02_Internet_History\TI F_Cache_Index.dat file. (#3) Click on the Open button. 3. Once the path has been selected click on the Finish button to let DataLifter carve the data.

18 Internet History Practical Exercise Anatomy of a MSIE History.IE5\date-ranged\Index.dat File 1. Start WinHEX & open \Student Files\02_Internet_History\History_DateRange_Index.dat. 2. Let s examine this file structure First, let s determine the location of the HASH section of the file. The HASH section is not generally of forensic use but we will find it so that we can locate another jump code. Determine the DWORD value file offsets This value is a jump code that points to the HASH section. What is the 32-bit value? Next, jump 16,384 bytes from the beginning of the file.

19 2.3. Next, determine the multiplier for 128-byte blocks that is used to determine the location of the first record entry beyond the HASH section. Determine the value of the DWORD following HASH. 32 The calculation is 32 X 128 = Next, jump 4096 starting the jump from the H in HASH What is the file offset for the first record entry? What type of record did we land on? (Note the 4-byte record header.) in ASCII URL

20 2.7. The record size is determined by the value of the DWORD following the record header multiplied by 128. What is the value of this DWORD for this record? 2 What is the size of this record? 2x128= Confirm the record size is 256 bytes and located at file offsets thru using WinHex to highlight data area. Note that another URL record begins after this data block.

21 2.9. Note the date-ranged folder name is embedded at the beginning of the URL string. This can differentiate between history root folder record and a date-ranged record. 3. Search the data for the character string password (without the quotes). Use the F3 key to advance through subsequent hits. Note that some Websites pass the login information in plain text.

22 4. Search the data for the character string q= (without the quotes). Use the F3 key to advance through subsequent hits. You can see some search strings

23 Internet History Practical Exercise Carving Browsing History Artifacts from Unallocated Space Using DataLifter Bonus Tools 1. Delete all files in C:\Temp 2. Start the CleanUSB program from the Desktop to zero-out the logical volume on thumb drive. (Note that CleanUSB only reads removable media.) Confirm the check mark in the accept agreement box and then click on the Next button. 3. Next, choose the correct path for your thumb drive and then click on the Next button. 4. Next, choose Delete all files in device and then clean it. Then click on the Next button.

24 5. Next, type OK in the confirmation box and then click on the Clean Now button. 6. Next, wait for the process to compete. 7. Copy the three sample index.dat files from \Student Files\02_Internet_History to the thumb drive. 8. Then delete all of the index.dat files on the thumb drive.

25 9. Start FTK Imager and select to Create Disk Image. 10. Select the source as a Logical Drive. 11. Select the appropriate location for the thumb drive. Then click on finish to acquire the thumb drive.

26 12. Click on the Add button so you can choose the type of image to create. 13. Select the Raw(dd) as the image type. Click on Next to continue. 14. We will leave these dialog boxes blank for the purposes of this exercise. Click on Next to continue.

27 15. Enter c:\temp as the destination folder and enter URL_Unall as the file name. Accept the default fragment size. Do not activate compression. Click Finish. 16. After confirming the parameters are set as shown here click on the Start button. 17. A progress bar will keep you notified as the image is being acquired. 18. The Status box indicates when finished.

28 19. Start DataLifter Bonus Tools and run the URL Recovery Module. Suggestion: Click on (to activate) the URL Recovery workspace tab. 20. Click on the Browse Folder button and then navigate to the file URL_Unall.001 in the c:\temp folder. 21. After confirming the parameters are correct click on the Finish button.

29 22. If the URL Recovery workspace tab was not the active, as suggested above, this message will be displayed. 23. The results shown above provide the following information about browser history records (history and cache) found in the source file. Type: The type of hit found by Bonus Tools. URL indicates a valid Microsoft Internet Browser Index.dat record. If another browser hit, such as Netscape, is found, the code ORPH (orphaned) will be displayed in this field. This field could also contain the code REDR; which indicates a redirected visit. In other words, the user visits a URL that in turns points them to a different URL. URL/REDR: The complete URL that was listed in the Index.dat record. Record entries beginning with "Visited:" followed by a profile name that was active during the visit indicate a root history.ie5 as the origin. (Note, Visited is the default setting but this can be changed with a registry edit.) Record entries beginning with a date ranged value such as followed by a profile name that was active during the visit indicate a date-ranged subfolder of the root history.ie5 as the origin. Record entries beginning with followed by the address indicate a temporary Internet folder [cache] as the origin.

30 FQDN: Fully qualified domain name. This is the domain name for the URL. If the hit is a record for a visit to a web site then this field does not contain the header "Visited" and the profile name, if the record is from a history index.dat file. If the record is from a cache index.dat file then this field does not contain the name of the cache file that is referenced in the URL field. Hit Rate: Depending upon the version of the browser that is being used, the hit rate may or may not be reported. The hit rate is the number of times this site (if history record) has been visited or the number of times the file (if cache record) has been accessed. Last Visited: The last date and time the URL (if history record) was visited or file (if cache record) was accessed. User Name: Only applicable if the origin was a cache URL record entry. Other record types history (root & date-ranged) and cache REDR do not include the user name field so DataLifter displays Unknown. File Name: If the record [hit] is from a cache index.dat file then this field contains the name of the file that was accessed by the browser. Normally, this is a file that would have, at one time, been contained in one of the cache folders. If the record is from a history index.dat file then most likely this field will contain "unknown" due to a history entry not pointing to a specific file. File Size: If the record [hit] is from a cache index.dat file then this field contains the size of the file mentioned in the 'File Name' field. If the record is from a history index.dat file then most likely this field will contain "0". Parent Name: The name of the file that the URL tool obtained this information from. Parent Path: The path for the file mentioned in the "Parent Name" field. 24. You have the capability to filter the records based upon field type and condition.