Wednesday, April 4, 2012

Case Experience #2.4 - Exposing Kilroy with Log2Timeline

Welcome back to the final (I think) installment in Kilroy's case study.  In this post I will be using RegRipper, VMWare and SANS SIFT workstation.

In a comment posted on Case Experience #2.3, ToneSurfer pointed out the step to tie drives between the System and NTUser.dat based on their GUIDs.  Below are the keys from the RR report that you could use in order to tie these together:

From System
mountdev v.20080324
Get MountedDevices key information from the System hive file.

LastWrite time = Sat Jan 21 17:14:52 2012Z

Drive Signature = 69 2a f1 28
Drive Signature = 04 f6 06 00

Device: _??_USBSTOR#Disk&Ven_&Prod_USB_Flash_Memory&Rev_PMAP#001D0F0CAAD3B8B17318047C&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

From NTUser.dat
LastWrite Time Sat Jan 21 17:15:16 2012 (UTC)

    {5163423f-1301-11e1-94d0-00266cdaca46}  Mon Jan  2 21:38:37 2012 (UTC)
    {38e479c9-3587-11e1-a72a-00266cdaca46}  Mon Jan  2 21:44:31 2012 (UTC)
    {38e47b09-3587-11e1-a72a-00266cdaca46}  Mon Jan  2 21:25:47 2012 (UTC)

What I want to do now, though, is to demonstrate how information, including what we have found in the registry, can be put into additional context using Log2Timeline.  Someone recently asked me what a supertimeline could do that other tools couldn't.  It's a valid question.  If you have never used a supertimeline, it can be difficult to see why the rabid converts (myself included!) love it so much.  My response was this:  "As far as timelines, it isn't so much that it does something that no other tool can... what's great is that it does all the legwork for you.  Because it looks not just at MAC dates (like you would see in FTK or EnCase), but also pulls dates and times out of log files, the registry, internet history, etc, and puts it all in one location, you don't have to go looking in four or five different places to get the context.  It's certainly not the end-all and be-all, but once I tried it... I admit, I never went back."  I still stand by that statement.  So, let's see if this tool would help in my continuing efforts to find out what Kilroy was up to...

Yet another disclaimer:  These steps to not reflect a full analysis.  There are many other ways to approach the problem.  Other tools can be used.  Even the tools I use can be implemented differently.  This is just one path of many!

Getting Started With SIFT

While it is possible to install log2timeline directly onto a windows system (I know because I did it... eventually), it can be a bit time consuming.  If you can use VMWare on your system, things become much easier by using the SIFT VMWare Appliance.  In addition to being able to run it within your Windows environment, the workstation is already setup with VMWare folder sharing and VMWare tools that will make life much easier.  I only mention this because when I first started using SIFT I made the mistake of downloading the ISO and creating a VMWare machine from scratch.  Learn from my mistake:  save yourself the effort and use the tool already put together for you!

Running a Timeline

I'm going to run through steps to create a timeline in SIFT.  Note that these steps do not encompass everything needed for a supertimeline, as I am not including the $MFT steps.  If and when you decide to create a supertimeline, the SIFT workstation comes pre-loaded with a Log2timeline cheat sheet that is invaluable.

Step 1:  I am running log2timeline on a drive attached directly to my machine.  Because of that, I will just need to share the drive in SIFT, without mounting.

 The OS is located on the partition mapped to the I: drive, so that is what I will be using in this example.

Step 2:  Now that the drive is shared, we can get down real work.  To run a timeline against my shared I: drive, I typed the following:

log2timeline -p -r -f win7 -z PST8PDT /home/sansforensics/Desktop/VMware-Shared-Drive/I -w kilroytimeline.csv
 This script is included in the Log2Timeline cheat sheet.  All I had to change was the input module (Win7), the timezone (PST8PDT), and the shared drive information.  Now it is just a matter of sitting back and letting log2timeline do its thing.

Click to view information
This image is a small excerpt of information from the resulting timeline.  Notice that there is information from both the NTUser.dat and System registry hives regarding attached drives, in addition to information about a file we noticed first in #2.2 in the Recent folder.  And this is only one small window of time on Kilroy's computer.  Supertimeline is an apt word indeed.

Parting Thoughts

Just briefly, I wanted to mention what an honor it is to have been chosen as one of the nominees for the Forensic4Cast awards.  Voting is now open, so please take time to vote for your favorites.  Both of the other blog options are fantastic, and there are many nominees in other categories that deserve recognition.

I'm unsure what my next blog posts will focus on.  I have been a bit more serious lately, so I may take a break with some levity, or maybe I've turned a new leaf of gravity... we'll see!  If you have any thoughts, let me know.


  1. Great post!

    From the post, you can clearly see that the device's serial number, found in the device descriptor (which means it requires a firmware update to modify).

    The Volume GUID, "{5163423f-1301-11e1-94d0-00266cdaca46}", is in UUID v1 format (per RFC 4122), and as such, the last segment is the node ID, or MAC address. The first three segments comprise a 60-bit time stamp, based on the epoch 15 Oct 1582.

    Lots of great intel, just from the bit that you've shown. Thanks for posting this, I'm sure that it's a huge help for many folks in the community.

  2. To the question about what a timeline provides that other tools don't...

    Well, first off, the answer is "a timeline". Seriously. Timelines are a valuable resource, and at this point, no commercial tool provides such a framework.

    Timelines provide context. Yes, you can get file modification times...but what is the context when you see that? What caused the modification, or what occurred *around* or *near* the event that may have influenced it? A great thing about the context is that it not only give the analyst information regarding what happened, it also provides an interesting framework for analyst can replicate the actions that occurred and see if ProcMon (or other monitoring tools) produce similar results, which in turn will validate the analyst's findings and conclusions.

    Timelines provide a greater relative level of confidence in the data that you're looking at. We know that some time values are highly (re: easily) mutable, meaning that they can be easily and arbitrarily changed. Time stamps in MFT $STANDARD_INFORMATION attributes, for example, are susceptible to modification with minimal privileges. So, if you have one data source...say, the default output from 'fls'...for your timeline, how much confidence do you have that the data you're looking at is correct? Now, add other data sources...Registry, Event Log, Prefetch, etc...and your relative level of confidence in your data will increase. If I have one event that suggests a file was modified, I might not trust it; however, if I have four or six *nearby* events that support the file modification, I'm more likely to trust what I'm seeing, as I'm more confident that the data is, in fact, correct.

    1. Thanks! This is a perfect response, and one I will probably borrow for future use. :)

  3. All I did was re-type stuff from my blog, and stuff I'd included in Chapter 7 of WFAT 3/e... ;-)

    1. Still working on memorizing important passages from the books... would probably be worthwhile, though. I would sound way smart if I could rattle that off. ^_^

    2. There's no need to memorize it. It does help if you can understand it and incorporate it into what you think and do. That's kind of how I did it. It's not something I memorized, it's something I know.

    3. Sorry, that's just my poor attempt at dry humor.
      Thanks for providing the information... I actually do plan to reread a bunch of your books. Hopefully more will sink in, even if no memorization is required!

  4. Hi GU,

    Just to be a PITA, I was wondering if you could also provide us with a couple of sample report conclusions (or even just brief outlines) based on the Kilroy evidence you've shown.

    Specifically, I would greatly appreciate:
    - One summary/outline for the "Executive" non technical people and
    - One summary/outline for the "Technical"

    Not having written a real-life report before, I am curious as to how you would tie it all together and present the information to the client.
    Even just an example of boilerplate text missing the details would be useful.



    PS The next post must feature MORE CARTOONS ! :)

    1. Ooops! I fogot to say "Thanks" for all the hard work you've put in to this series of posts.


    2. Cheeky... brilliant plan! I am actually writing an article about writing reports (a bit meta, amirite?), so following up with a post on reports would be perfect for really finalizing a case study.

      My cartoons aren't as fun as yours, but I'd be happy to give another one a whirl. I've had a few ideas running around in my brain... let's see if I can do them justice.

      Thanks for reading. I'm constantly impressed (and in awe!) of your blog. Really great stuff.

    3. Cheeky,

      Just FYI...I provided a sample report in the Files section of the Win4n6 Yahoo's called acme_report.pdf.

    4. Thanks Harlan,

      I'll join up and take a look-see.

  5. If you have a disk image with multiple partitions, say one for OS and one for data storage, do you need to run log2timeline on both the OS and data partition?

    1. Yes, I would recommend running log2timeline on both partitions, and then combine the outputs to get the whole picture.