IR and forensic talk

I forgot to mention Aftertime in my last blog post, which is a new tool to create and analyse timelines.  Rob pointed this tool to me the other day, and I’ve done some limited testing on it.  It is very easy to create the timeline, just add the image file and let it crunch through it, all point-and-click and easy.  That is nice and I’m sure some will prefer that over the CLI method of log2timeline, where you need to use the command line and know the parameters of the tool, etc.  The tool also provides a nice GUI to display the timeline, using separate colors for each source, and to create reports.  Yet somehow I got the feeling it might be easy to overlook some of the important events, especially if they are only couple of them. This might be because I’m not used to examining timelines visually like this or because it might be hard to detect a single event that is surrounded with benign ones using a visual method like this. This is something I have to test further, since I think there are a lot of benefits of being able to visualize the timeline.

Harlan Carvey posted yesterday about some of these links that you see in this post.  One of which was the addition of regtime.pl into the timeline that includes every change made to the registry.  I haven’t added that functionality into log2timeline yet, that is to parse every single registry key into the timeline.  Today I’ve only included the UserAssist key, which adds more context to the registry entries than simply dump everything there.  In the near future you will see a lot more registry entries parsed using log2timeline, where I intend to parse only specific keys to add to the timeline, parsed and put into context.  I’ve been playing around few of these entries and I hope to add in version 0.51, at least part of my thoughts on the subject.

Although I agree with Harlan that adding every registry entry into the timeline can sometimes be an overkill and drown you with events and that in some cases it might loose some context (since you are not parsing the content of the keys).  However I have to admit that in some cases it really helps you find some registry entries that you might have otherwise missed.  I know that it has helped me greatly in at least few exams that I’ve done where I used tools like regtime.pl or reglookup-timeline to create the timeline.  In those cases I had a very specific timeframe which I was looking at, making the addition not so difficult to parse through, and found evidence or settings of software that I did not know at the time was installed (since timeline analysis is often the first step I do).  That led me quickly to what I was really looking for, thereby shortening the investigation time considerably.  I’m not saying that I wouldn’t have found what I was looking for using other methods, but adding the content of the entire registry into the timeline greatly reduced the investigation time so I think there is definitely value in it.  That being said, adding modules for log2timeline that actually parse the content of some specific keys and adding context to those last write times adds more value to the timeline than simply just the last write time and the name of the key, but it will never catch everything and every little piece of software you might have installed.  One thing that I liked about Aftertime though was that you could easily put everything into the timeline and then if you didn’t like seeing all the registry keys for example you could simply exclude them from the timeline and focus on something else, so if a particular source was somehow not useful at all, you could easily exclude it from the timeline (something that can be done using awk for instance in an ASCII file, but not something that everyone perhaps likes to do).

Timeline analysis has been getting a lot of press lately.  Harlan discussed some of the sources and usability of timeline analysis in a recent blog post. And then you’ve got few posts that describe how to create timelines, both from a live Windows machine, and from registry files. Rob Lee also posted a blog about creating timelines from shadow volume copies.

Then log2timeline has been getting some discussion as well. Paul Bobby actually pointed some bugs to me as well as posting two posts on his blog, one being a discussion of  the issues of mounting the image file using Encase and accessing log2timeline from a virtual machine. The other one about an Encase script to extract all the files that log2timeline is capable of parsing to a directory (at least most of them), to make it easy for log2timeline to parse it without the need to mount the image file.

Rob Lee also posted a blog post about super timeline creation, using among other tools, log2timeline.  I will post similar posts as Rob soon, just have to complete the new version of the tool first.  The plan is to complete it, which I hope will add some good improvements, before the SANS EU forensics summit. And speaking of the summit, the detailed agenda for the SANS EU forensics summit is up, make sure you don’t miss it.

I’ve just released a new version of log2timeline, version 0.42.  The new version includes two new input modules, one for extracting timestamps from PDF metadata and another one from McAfee anti-virus log files.  The new version also includes several bug fixes, the full changelog can be read here. The development focus will be to move the tool to version 0.50, which will introduce a new design of how timestamps and related information is handled within the framework, including a shift to TLN as the standard output format, more details can be found inside the roadmap.

log2timeline will also be included in the upcoming 2.0 release of the SIFT (SANS Investigative Forensic Toolkit) workstation, which will be available soon (and yes it is based on Ubuntu now). That way people can enjoy the tool without needing to go through the installation process with all the needed dependencies.

The agenda for the upcoming SANS EU forensics summit is up. I encourage everyone that has the change to attend this summit, there are some greate talks and of course a great change to meet some of the top experts in computer forensics in Europe.  And of course a change to meet with me and get me to implement some feature to log2timeline that you always wished was there, but for some odd reason you didn’t send me an e-mail to request it.

Just recently saw a post at Slashdot about Adobe implementing private browsing in their Flash Player.  That means that when the user starts private browsing mode in their web browsers LSO files will not be stored on disk.  This is implemented in the way that during the private browser session all Flash cookies are stored only in memory, and as soon as the browser is closed they are cleared.

Why do we care about this? Well with this change we will start to see that private browsing is becoming more private (or actually private), and it will make our lives as forensic investigators more difficult, since we cannot simply examine Flash cookies to determine the users browsing history (at least partially).

I just posted a blog post in the SANS forensics blog about the structure of LSO files and a quick view of how log2timeline parses it to extract timestamps. I’m not going to repeat that post on this site, so if you would like to know more about the binary format of LSO files, please read the blog post.

Recently there have been a lot of discussions about creating a standard for timeline analysis. Currently log2timeline relies upon the good old mactime format for it’s output (although it is possible to use several different output mechanism), a standard that was created for filesystem timelines.  Although it works great for its original purpose It might not be the most optimal output mechanism when incorporating timestamp information from other sources which is one of the reasons why this push for a new standard has been discussed. The structure of log2timeline will be changed soon to separate the internal structure away from the emphasis on mactime and move to a more neutral approach, and perhaps change the default output mechanism to something like TLN.

With the move to a more neutral approach more logic will be moved into the output modules, meaning that it will be easier to make the description text (which every output module includes) can be more descriptive and does not need to repeat information that might be contained within the output itself (such as TLN which includes a source field, why repeat the source in the description field?)

I just wanted to write a short post about the upcoming SANS European Digital Forensics and and Incident Response Summit that will take place in London on the 19th and 20th of April.  I encourage everyone that has the chance to attend since there are some very interesting talks, such as; Jesse Kornblum’s talk about fuzzy hashing, Keith Foggon’s discussions about trends and techniques and Lee Whitfield’s Windows Shadow Volumes presentation.

I will also be there, talking about log2timeline.  The title of my talk is Mastering the Super Timeline – log2timeline style.  After the talk I will participate in a tool talk panel, so there is your chance to pound me with some difficult questions…

The abstract of my talk is:

Traditional timeline analysis can be extremely useful yet it sometimes misses important events that are stored inside files on the suspect system (log files, OS artifacts).  By solely depending on traditional filesystem timeline the investigator misses context that is necessary to get a complete and accurate description of the events that took place.  To achieve this goal of enlightenment we need to dig deeper and incorporate information found inside artifacts or log files into our timeline analysis and create some sort of super timeline. These artifacts or log files could reside on the suspect system itself or in another device, such as a firewall or a proxy.  This talk will focus on the tool log2timeline, which is a framework built to parse different log files and artifacts to produce a super timeline in an easy automatic fashion, designed to assist investigators in their timeline analysis.

So the talk will contain some of the work in my upcoming Gold paper, titled “Mastering the Super Timeline With log2timeline” (did someone notice the similarities between the titles).  The paper should be published soon, at least before the summit.

I’ve just published version 0.41 of log2timeline, for a full list of the changes read the changelog.  This upgrade is a recommended upgrade since it contains several bug fixes as well as enhancements to the tool.  I’ve added new input modules for: Google’s Chrome History, Opera History, Firefox Bookmarks, and Windows Event Logs (EVTX). I’ve also added a new output module, CEF, for the Common Event Format as designed by ArcSight as well as improving few other input modules (more on that later).

In my last post I talked about Opera history files as well as the bookmark feature of older versions of Firefox.  Since I’ve added support for the bookmarks features in older versions of Firefox (the ones that still store their bookmark information in the bookmarks.html file) I decided to include those information in the newer versions of the browser as well.  As of version 3+ of Firefox it no longer stores bookmark information inside the bookmarks.html file.  Instead it stores them in the places.sqlite database, the same one that contains the browser history.  Therefore I upgraded the firefox3 input module to include information about bookmarks, which are stored inside the moz_bookmarks table as well as in inside the moz_places table.  The SQL command used to pull out information from the bookmarks is the following:

SELECT moz_bookmarks.type,moz_bookmarks.title,moz_bookmarks.dateAdded,
moz_bookmarks.lastModified,moz_places.url,moz_places.title,
moz_places.rev_host,moz_places.visit_count
FROM moz_places, moz_bookmarks
WHERE
 moz_bookmarks.fk = moz_places.id
 AND moz_bookmarks.type <> 3

There is one field in the moz_bookmarks table that is of special interest, that is the “type” field.  There are three different bookmark types:

• 1 = A bookmark (URL)
• 2 = A bookmark folder
• 3 = Separator

The above SQL command returns all values from the moz_bookmarks table (except separators) that have any corresponding fields inside the moz_places table.  This means that the SQL command in fact only returns bookmarked URL’s, not folders.  So another query is made to get the necessary information about bookmark folders:

SELECT moz_bookmarks.title,moz_bookmarks.dateAdded,moz_bookmarks.lastModified
FROM moz_bookmarks
WHERE
 moz_bookmarks.type = 2

This SQL command extracts all the dates associated with the bookmark folders.  But there are other tables within the places.sqlite database that might contain date objects, that is the table moz_items_annos.  This table contains additional information about bookmarks, that is annotations that are made to bookmarks.  The table stores the time when an annotation was added to a bookmark as well as when it was last modified.  The SQL command used to extract this information from the places.sqlite database is:

SELECT moz_items_annos.content, moz_items_annos.dateAdded
,moz_items_annos.lastModified,moz_bookmarks.title,
moz_places.url,moz_places.rev_host
FROM moz_items_annos,moz_bookmarks,moz_places
WHERE
 moz_items_annos.item_id = moz_bookmarks.id
 AND moz_bookmarks.fk = moz_places.id

An example output of the newly upgraded firefox3 input module is the following:

log2timeline -f firefox3 -z local places.sqlite  | grep Bookmark

...
0|[Firefox3] User: smith Bookmark Annotation: [milw0rm exploits and 0day
exploits database] to bookmark [milw0rm] (http://www.milw0rm.com/)|0|0|0|0|
0|1195573631|1195573631|1195573631|1195573631
...
0|[Firefox3] User: smith Bookmark Folder [Bookmarks Menu]|0|0|0|0|0|
1218738203|1218738203|1195573631|1195573631
...
0|[Firefox3] User: smith  Bookmark URL SANS London 2008 (http://www.sans.org/london08)
[london08] count 0|0|0|0|0|0|1218784170|1218784170|1218784170|1218784170

I’ve also upgraded the flash cookie or Local Shared Object (sol) input module considerably.  The older version was not built to support many of the common flash cookies out there so the new version should implement a parser for every known type of objects there are.  Although I’ve seen some flash cookies that the input module is not capable of parsing that have considerably different binary structure. These files might be an older version of the standard and the current version of the sol input module is unable to parse them (and so are every other SOL editors/parsers that I’ve seen).  I will not include any information about the structure of flash cookies in this post, it will be reserved for a later post.

I’ve also decided not to create all my blog posts on this site and then re-post some of them on the SANS forensics blog. Instead I will post some of the blog posts solely on the SANS blog while others will only be here.  On that spirit I wrote a post about Google’s Chrome browser which can be read here. My blog post about flash cookies will also be posted on the SANS forensics blog site.