My Road to Digital Forensics Excellence

Archive for the ‘Forensics’ Category

Alternative to Typed URLs?

Posted by Paul Bobby on August 15, 2012

Wiping software had blown aware the TypedURLs kvp normally found at HKCU/Software/Microsoft/Internet Explorer. Whilst performing a keyword search I got a hit in the file appdata\local\temp\structuredquery.log. A Google search later and I found that this file records those entries you type in the URL bar in Internet Explorer that causes the ‘auto suggestion’ display of IE.

For example, if I’ve previously been to and various sub-sites of Google, if I just type google in the URL bar, Internet Explorer will search my history and favorites using a sql query like this:

SQL query built: SELECT TOP 6 “Microsoft.IE.TargetUrl”, “System.ItemPathDisplay”, “Microsoft.IE.Title”, “Microsoft.IE.SelectionCount” FROM SystemIndex..SCOPE()  WHERE  CONTAINS(“System.Search.Store”,'”iehistory*”‘,1033)  AND ((NOT CONTAINS(“System.ItemType”,'”Folder”‘) AND NOT CONTAINS(“System.ItemType”,'”Directory”‘))) AND (((CONTAINS(“Microsoft.IE.TargetUrlHostName”, ‘”go*”‘,1033) RANK BY COERCION(Absolute, 250)) ) OR ((CONTAINS(“Microsoft.IE.Title”, ‘”go*”‘,1033) RANK BY COERCION(Absolute, 150)) ) OR ((CONTAINS(“Microsoft.IE.TargetUrlPath”, ‘”go*”‘,1033) RANK BY COERCION(Absolute, 100)) )) ORDER BY “Microsoft.IE.SelectionCount” DESC , “Microsoft.IE.VisitCount” DESC , “System.Search.Rank” DESC

SQL query built: SELECT TOP 6 “Microsoft.IE.TargetUrl”, “System.ItemPathDisplay”, “Microsoft.IE.Title”, “Microsoft.IE.VisitCount”, “System.ItemUrl” FROM SystemIndex..SCOPE()  WHERE  SCOPE=’file:C:\Users\pbobby\Favorites\’  AND ((NOT CONTAINS(“System.ItemType”,'”Folder”‘) AND NOT CONTAINS(“System.ItemType”,'”Directory”‘))) AND (((CONTAINS(“Microsoft.IE.Title”, ‘”googl*”‘,1033) RANK BY COERCION(Absolute, 500)) ) OR ((CONTAINS(“System.ItemFolderNameDisplay”, ‘”googl*”‘,1033) RANK BY COERCION(Absolute, 400)) ) OR ((CONTAINS(“Microsoft.IE.TargetUrlHostName”, ‘”googl*”‘,1033) RANK BY COERCION(Absolute, 150)) ) OR ((CONTAINS(“Microsoft.IE.TargetUrlPath”, ‘”googl*”‘,1033) RANK BY COERCION(Absolute, 75)) )) ORDER BY “Microsoft.IE.SelectionCount” DESC , “System.Search.Rank” DESC , “Microsoft.IE.VisitCount” DESC

Some quick testing shows that this log file persists through deleting internet history from inside of Internet Explorer, and through the default configuration of CCleaner. BCWipe however did trash the file.

Still, this is yet another artifact that ‘remains behind’ and can shed light on the surfing habits of your subject. It also has the side benefit of answering the question “what are they browsing for” which is difficult to answer when just looking at internet history or a proxy log. These queries only get created when typing content in the URL bar.

Anyone had experience with this file?


Posted in Forensics | Leave a Comment »

Windows 7 CD/DVD Burning

Posted by Paul Bobby on June 4, 2012

Plenty has been said about the “did they burn data to CD/DVD” question for Windows XP – but a recent case required me to answer the same question but this time for Windows 7. So has anything changed? Is it easier, harder? Well let’s find out.

Windows 7 comes with built in support for burning CD’s and DVD’s. A tool called Windows DVD Maker is provided to end-users as part of the Windows 7 operating system. This guide highlights artifacts that indicate if/when a blank CD/DVD was inserted in to the drive, and also how to determine what was burned to that media.

The Event Log

Windows 7 records information in 40+ event logs, not just the original big three (System, Application and Security). Several tests of burning data to DVD show that with under my current environment’s build and GPO configuration, the only event that gets written to a log is:

Event ID 133. Source "cdrom"

And this gets written to the System Event Log only. While there is no supporting data for this event at or in the Microsoft Knowledge Base, testing has shown that this event occurs when the burn button is clicked in Windows Explorer. Simply adding non-blank discs does not trigger this event.


The description, "locked for exclusive access" shows that the ‘burn’ process has actually started.

The Registry

The following key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CD Burning\StagingInfo

contains a KvP that resembles this:



The value "StagingPath" is significant. It shows the folder on the volume that is used to ‘stage’ files prior to committing them to the disc.

Once we have a file on an NTFS volume to look at, we can resort to standard file system forensics to figure out what, if anything, existed in this folder. (Remember, even folders are files to NTFS)

The Forensics

Deleted Files

When parsing an NTFS volume using Encase, the tool automatically assigns all deleted files, with intact MFT records, to the appropriate parent folder.

In other words, when you navigate to this folder using Encase, you may see deleted files in that folder. If they are in the clear, then you got very lucky and found a burning session in progress. Any file present in this folder, clear or deleted, is/was staged there as part of a burning session.


Remember, every folder in NTFS is a file. What does the "file" for the "\burn" folder contain? It contains a binary record structure that the Windows OS uses to display the contents of that folder called an INDX record. Here’s a sample:


The OS maintains the contents of this file on a real-time basis: as files are added to the folder, the content of this INDX is updated. As files are removed, the contents of this INDX are updated. Even though the folder is currently empty, it looks like there is some ‘leftover’ data in this file. Encase can parse this out for you using an enscript under Examples->Index Buffer Reader. Here’s a partial screenshot of what the output can look like:


The output shows that a file was present in this folder (you have a filename) and corresponding timestamps for that file show you when this occurred. It also comes with size information and MFT record information.

MFT Records – $LogFile

What is the $Logfile? It contains information used by NTFS for faster recoverability. The log file is used by Windows Server 2003 to restore metadata consistency to NTFS after a system failure. The size of the log file depends on the size of the volume, but you can increase the size of the log file by using the Chkdsk command. Source Microsoft KB Article (The Logfile is of course used in more than just Server 2003).

This file contains several useful artifacts, but the one we want are the MFT records. Encase has an enscript to parse this file, it’s under Case Processor.


Once parsed, your case will contain a series of bookmarks (sometimes 100s of the things), one bookmark for each MFT record found in the $LogFile. What do we want to look for in these bookmarks?

MFT records contains lots of useful information, but the piece we are looking for is called the "Parent MFT Record #". This associates a file with a particular parent folder, and that is basically how things are kept organized. So let’s find the MFT record for the "\Burn" folder.


The MFT record # for the Burn folder is 75485. Note make sure you select the right folder. You want the MFT record for that second ‘burn’ folder, not the first.

So, make your own Condition under the Bookmarks view called "Comment contains" that finds any comment that contains the parent MFT record #, and ta-da, you now have a list of files that once existed in that folder. Why? Because every MFT record also stores the MFT number of its parent folder.

MFT Records – The Journal File

What is this journal file? The USN Journal (Update Sequence Number Journal) is a system management feature that records changes to all files, streams and directories on the volume, as well as their various attributes and security settings. The journal is made available for applications to track changes to the volume.[12] This journal can be enabled or disabled on non-system volumes[13] and is not enabled by default for a newly added drive. Source Wikipedia article on NTFS

This information is stored in a file called $USNJRNL, in the folder C:\$Extend. The files comes with two streams, and the one that contains the data we really want is:


Encase does not have a built-in enscript for parsing that file, but there are some scripts out there, along with standalone tools that can parse the Journal file. My favorite comes from TZWorks and is called Windows Journal Parser. Get it. Here is a sample output from this tool, already filtered to include files whose parent MFT ID matches that of the "\burn" folder:


The highlighted piece is the hex value for the parent MFT. Any entry that has this same parent MFT hex value once existed in this folder, therefore the data was burned, or staged for burning.

So that’s it? Any problems?

One thing I can think of, what if the user starts staging data in that folder but changes his mind and deletes it? Can I prove the actual burn took place? It looks like Event ID 133 occurs when the burn button is clicked, so if you can correlate this event to MFT records showing content in that folder, then it’s a solid conclusion to make. And I’m beginning to suspect that staging is not the write word to use. Continue reading.

If you look at the output of the USNJRNL parse, you’ll see that the file was copied and deleted all within the same second – I’d like to think that that indicates a successful burn. Some further testing is needed there – but it appears that staging doesn’t occur as I traditionally think of staging: as you select files and folders, place that data in the burn folder until you click Burn. That’s inefficient, instead it looks some sort of data structure is maintained in RAM to hold pointers to the data you wish to burn, and the actual commit to disk process involves taking each file, one at a time, and writing to the Burn folder, then to Disc, then deleting from the Burn folder.

I welcome any additional information you may have, especially if you have noticed different behavior or discrepancies in my write up.

Posted in Forensics | 1 Comment »

Manual review of data structures

Posted by Paul Bobby on June 8, 2011

#dfirsummit has been generous this year in that they’ve provided a free live stream of the 2 days of presentations. This quick post was prompted from listening to Lee “Gervais” Whitfield, and his discussion of where to look to disprove the ‘bios clock changed’ conspiracy when it comes to disputing the evidence on your hard drive.

He indicated several locations that exhibit temporal anomalies should the clock in fact get changed. For example, thumbs.db (thumbnail databases in folders with images) stores thumbnail data sequentially – changes in the timestamps of those thumbnails may indicate time change.

He was asked, what are the Top3 places to look for for evidence of clock changes, and as #1 he mentioned Event Logs. But I don’t think for the reason why it is #1. He mentioned one event for XP and a couple of events for Vista/7 that show the clock being changed that get recorded in the event log. This is good of course, but I believe the real deal with event logs is just as with thumbs.db. Data is written to the event log sequentially – it is not ordered chronologically.

Talking Windows OS and NTFS.

Again: event logs are written to the NTFS file system, and then individual events appended to the log. If the clock changes, new events are appended to the log with these new timestamps. This is where reliance on tools such as Encase/FTK to perl scripts, to Event Log explorers, even log2timeline, that may auto-sort events for us chronologically for presentation, or at the least, our first step is to sort output chronologically. If we manually inspect the contents of the event log file with a hex editor (i.e. a raw view), and do some decoding ourselves, we can see the jump in time/anomaly clearly.

Of course what is ‘clear’ is subjective – but this is a good example of where manual review of data structures may in fact save the day rather than relying on our tools. Manual review of data sources may only be appropriate for certain scenarios, and I’m not recommending it as a daily approach; but it is something to be mindful of when trying to prove a point.

Posted in Forensics, General Research | Leave a Comment »

Stability Index and Reliability

Posted by Paul Bobby on January 17, 2011

While conducting an investigation in to removable media, on a Windows Vista 64bit computer, several searches had led me to the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib09

A REG_MULTI_SZ value, called ‘Counter’, contains the following sample text:


Which lead me to the tool “Reliability and Performance Monitor”.


I have never looked at the “reliability monitor” before – but it contains something very interesting. A nice looking timeline of stuff.

Reliability Monitor

Here’s a sample from the “Software (Un)Installs” section:

Software (Un)Installs

Sweet! Another 4n6 timeline artifact that may be immune to file system cleaners and uninstallers. How about those external devices?

External Devices

Okay enough of that – what about deadbox analysis? On my test system, the files of interest are located in the path “C:\ProgramData\Microsoft\RAC\PublishedData”:

File Location

The ‘SWIT’ file contains the Software (Un)Install information, AFL is Application Failures, HFL is Hardware Failures, etc.

Let’s manually decode so that we can enscript them.

The following screenshot represents the record for Microsoft Silverlight, v4.0.51204.0, that indicates there was a successful Configuration Change made on January 8th, 2011 at 08:00:49 EST.

Record Breakdown

Here we go:

Bytes 0-15 represent a 128bit Windows SYSTEM timestamp. (See here)

typedef struct _SYSTEMTIME {
WORD wYear;
WORD wMonth;
WORD wDayOfWeek;
WORD wDay;
WORD wHour;
WORD wMinute;
WORD wSecond;
WORD wMilliseconds;

The cool thing here is that the time is available for analysis as opposed to just the date that is presented in the Perfmon MMC.

The next 128bytes contain a Unicode string representing the application. This byte stream is read until a NULL terminated string is found. In this case, “Microsoft Silverlight”. And to make sure you are paying attention, this field is reusable and can contain SLACK information! Woot.

The next 128bytes contain a Unicode string representing the version of the application. This byte stream is read until a NULL terminated string is found. In this case, “4.0.51204.0”. This field can also contain SLACK information.

The last 12 bytes contain the encoded events (I reversed these, couldn’t find a spec).

Four bytes at Offset 272 (the Purple bytes):

    0x00 = Install
    0x01 = Uninstall
    0x02 = Ignore field

Four bytes at Offset 276 (the green bytes):

    0x00 = Configuration change
    0x01 = Application install
    0x02 = System Update install

Four bytes at Offset 280 (the blue bytes):

    0x00 = Failure
    0x01 = Success

Writing a parsing tool for this is now cake.

Here’s an example from my own SWITable.DAT file that illustrates slack data (or what I’m calling slack data).
SWIT Slack

Posted in Forensics, Reverse Engineering | Tagged: | 1 Comment »