Timewarp

OK...so it's been a long time since my last post...sorry...got really busy with cases.

Anyway...one of my recent cases prompted me to write this blog posting (along with some much needed prodding from Harlan). In this case, I was asked to determine the authenticity of a series of documents. Specifically, could I tell if the documents had been altered in any way so as to obfuscate their original chronological data. To determine this, I was provided an EnCase image of a removable storage device that contained the documents. Nothing more.

So instead of simply loading the image into EnCase, checking out the MAC times, and calling it a day, I decided to do a proof of concept. I needed to find out what abnormal looked like so that I would know it when I saw it.

I created an Excel spreadsheet using Microsoft Excel 2008 version 12.1.9 (090515) on an Apple MacBook Pro running MAC OSX 10.5.7, Darwin kernel 9.7.0. The Excel file was named, "pogue-test.xls" and had a MAC time of 11:31AM. I copied this file over to a Windows test box running Microsfot XP Professional v5.1 SP3 at 11:33AM, and subsequently opened it at 11:39AM on 08/07/2009.

Next, a new column was created in the spreadsheet and it was saved. As expected the Access and Write times changed. The new times showed 11:43 AM 08/07/2009.

I then used Timestomp (an anti-forensics tool commonly used to modify timestamp information) to modify just the Last Written time - pushing it back one week to Friday 07/31/09 at 5:05:05AM. As expected, when the I used the "dir /T:W " command, the new date appears, NOT the original date.

I then used Harlan Carvey's "oledmp.pl" and "wmd.pl" to display the OLE times. The results displayed from the cmd line showed the time modification, but the Perl scripts did not. This is due to the fact that the Perl scripts pull the OLE times, which are different than the file times displayed by the operating system, which use metadata.

Timestomp was used again, to modify all of the timestamps (as can be seen with the –z flag) to “Thursday 7/30/09 6:06:06AM”. When the times were listed with "dir /T and each of the time variables (:C,:W,:A), they all reflected the NEW time.

Now that the file appears to have been modified as interpreted by the OS, I again used Harlan Carvey’s Perl scripts to extract the OLE data. The scripts displayed the REAL times and not the MODIFIED times.

A second exercise was performed using TrueCrypt v6.1a to create a 10MB volume. This volume was mounted as a physical drive on a system running Windows XP v5.1 SP3, and subsequently imaged with FTK Lite v2.6.1. The resulting raw image was copied to an Ubuntu Linux 9.04 host running kernel 2.6.28-14. The Sleuth Kit (TSK) V3.0.1 was used to create a body file from the image (using the “fls” utility). The bodyfiile was then parsed with “mactime”.

The times on “pogue-test.xls” reflect the date/time when the image was created and the spoofed modification time of “Thu Jul 30 2009 06:06:06”. The file was then extracted from the image using FTK Lite v2.6.1 and saved to the local system. Again, using Harlan Carvey’s Perl scripts “oledmp.pl” and “wmd.pl” the actual MAC times were extracted as display in the exact same manner as in the first test.

The conclusion derived from this proof of concept exercise was that the operating system and subsequently EnCase (if used) would display the spoofed file times. By using forensic specific utilities (like Harlan Carvey’s Perl scripts) that extract timestamp information from the OLE of the Excel document, I was able to display the actual times.

If the files provided to me had been modified in any way, there should have been a variance between the timestamp information displayed by the operating system (metadata) and EnCase and the Perl scripts that were used.

Then I thought, "What if the document creator modified his local system time with the date/time icon from the Windows control panel? What would that look like?" So, I conducted another proof of concept exercise.

I used the date/time utility from the control panel and set the year on my system to 2020 instead of 2009. I then opened up IE and typed in some URLs, opened a cmd prompt and ran some commands, and opened a couple of programs using their desktop icons. What I opened or typed in is irrelevant, the important thing is that my actions will be tracked by the UserAssit key and the TypedURLs key in my ntuser.dat file. The last write times for each of these actions should reflect the year 2020 and not 2009.

I extracted my ntuser.dat file using FTK imager lite v2.6.1 and parsed it using Harlan Carvey's RegRipper. Low and behold, I was correct. All of the dates recorded by the registry for my actions reflected the spoofed date. ALSO, when I changed the system date back to 2009, the timedate.cpl last write time also showed the spoofed year of 2020.

So, there are a few of good takeaways from this case and proof of concept.

1. Don't rely on a single tool to give you your answers. Don't be lame and simply load your image into EnCase can call it a day. That's weak, and it's not forensics...it's called being lazy.

2. If you don't know what "abnormal" is going to look like, figure it out. Conduct some proof of concept exercises so that you at least have some idea of what you are looking for.

3. Make sure you inform the customer of what you were able to do, and what you were not able to do. If you were not able to perform certain actions, tell them why, and request that data. In my case, I requested an image of the original system so that I could look for additional data points in the registry that would support chronological modifications.

Good stuff! Sorry again for the break in writing...I will try not to lapse like that again!