A Few Worthwhile Updates

Okay, so I just need to post a couple (or maybe a few) quick updates. These are important, at least to me. :)

First up is ... wait for it ... wait for it ...

Forensic4cast Awards! There are some great folks in here, all very well-deserving. I'm not about to tell you who to vote for, as political discussions can be touchy. Oh wait, this isn't politics, so I guess I'll go ahead and get dirty. ;)

Not really, except to say, vote for log2timeline in the "Computer Forensic Software Tool of the Year" section. L2T's a great tool that I use on a regular basis, probably every case I work. Hands down, it's just awesome!

If for whatever reason (maybe you don't like perl) you can't bring yourself to vote for L2T, then there's another offering I can support. That's Registry Decoder, in the same category. RD is another great utility (in python, for you perl-haters) that can do for the Windows registry what L2T does for the file-system - parses the heck out of it! This bad boy is also proving extremely useful to me.

Yes, it's true, I'm in a quandary, a conflict, a conundrum. Now, where's my lucky coin?

Now that I'm all neurotic aboaut the choices to be made, I'll move on to the next part. Oh, but first ... GO VOTE!

My next topic is ForensicArtifacts. This is a community-driven site that has a very catchy name: ForensicArtifacts.com. What, you've never heard of it?! Well, shame on me if I haven't mentioned it before. ;-(

Taken from the About page, here's a description of the site:

"ForensicArtifacts.com was built to become a repository for useful information forensic examiners may need to reference during the course of their analysis. Requests for artifacts of system files, programs, and malware are very common to see on computer forensic mailing lists and forums. This site strives to take the place of those requests and become a one-stop shop when it comes to forensic artifacts.

This site was designed for the digital forensic community, but it also relies on the community to become stronger. Please consider submitting any artifacts you have documented that may be of use to other examiners. As an added incentive, Rob Lee and SANS have graciously offered up a SANS Lethal Forensicator Coin for anyone submitting six or more artifacts or IOCs in any given year. For more details on this, please read here."

This is important, because we need more community involvement. A site like this only benefits the community if the community uses it. And if you're using it, you should be contributing to it. I don't want to sound all legalistic, but you should contribute. This doesn't just mean to send in artifacts; you can post links, follow @4n6artifacts on twitter and retweet, and recently we've even talked about having a "suggestions box" so people can submit ideas for artifacts, and anyone who's interested (and has time) can do some research to share with the community.

When it boils down to the crux of the biscuit (just mixing up various metaphors), ForensicArtifacts needs you! Only you can provide artifacts. It's low pressure, no time-table, do it as you can, just write it up and submit in the easy-to-follow form. It doesn't get much better than that! Basically, if you've found something in your work or research, even if it's perhaps incomplete, submit it.

We need your artifacts. We need your IOCs. And by "we" I mean the community as a whole, not just this site. When we all share the fruits of our labors, we all benefit. Pitch in! Recycle your artifacts and IOCs; it's good for the environment, and you get to make a difference!

Thanks!

Forensic4cast 2012 - Kristinn Gudjonsson & log2timeline

Okay, folks, it's that time of year again. Yes, it's time for the Forensic4cast awards. Eric Huber beat me to it, which could cost me my fanboy status. However, I gave a link to the Awards, so maybe that'll help. :)

Anyway, here's the point: Nominate Kristinn Gudjonsson and log2timeline. For what, though? Well, I'm with Eric on this - Kristinn for Examiner of the Year, and l2t for Forensic Software of the Year. The software wasn't initially developed this year, we all know that, but it has been under constant development, and I think that counts. Anyway, he didn't get the recognition he deserves last year (IMO), so let's get all the l2t fans together and get him in there!

First thing is to nominate, then remember to vote! Be sure to nominate and vote for others as well. There are several categories, so have at 'em. Best Organization (CDFS), Best Blog [cough]this one[/cough], Best Article [cough]Dropbox Forensics[/cough], and so on. Jokes aside, I think the CDFS has a good chance to make a difference in our field, and its leaders have been working very hard to do just that. Be a part, get involved, and also - nominate and vote!

That's all for now.

Update - Just to add another worthwhile one into the mix, even though it is (gasp, aargh) in the same category... RegistryDecoder by Andrew Case and Lodovico Marziale at Digital Forensic Solutions. I've used RegDecoder, and I like it. Easy to use, very useful, does a great job automating registry parsing from an image, multiple extracted files, mounted image set, etc. It will even run against a live system, although I haven't used it that way. You can do keyword searches, build a timeline, and much more. So that should go for Forensic Software of the Year as well. I hate to have to suggest a competitor to l2t, but RD's very good as well. And, competition makes us all better, right?

PS: While you're at it, go vote for RegDecoder on Toolsmith, open until 31 Jan 2012!

#DFIRSummit - Afterthoughts, Part 2

Okay, so now we're on to the "real" content. First let me start off by addressing something I overlooked last night. Congratulations go to Eric Huber and his AFoD blog for winning the Forensic 4cast award for "Best Digital Forensic Blog." I know Eric did not anticipate winning, but he did, and deserves it! I must also say that I was sadly disappointed that log2timeline did not win the "Best Computer Forensic Software" category. I'm not the only one; there was a lot of discussion to that effect at the Summit. It seems that Guidance Software had an active internal campaign that paid off more than anything we did for Kristinn. General consensus from the Summit seems to be that l2t was the winner anyway. That's right!

I'm basically going to run through each presentation in order and give a couple tidbits. Any more than that and I'll be here all night! So without further ado...

Day 1

Andrew Hay - 5 Point Palm Exploding Heart Technique for Forensics
This was supposed to be Mike Cloppert's slot, but he was tied up (not literally).
The 5 Points:
Host/Platform forensics
Network forensics
Data Reduction
Corroboration
Orchestration
The overall idea is that you need to try to combine or integrate the various segments into one for more effective/comprehensive investigations, since host-based can no longer really be the primary focus.

Chris Pogue - Sniper Forensics 2.0
DF is constantly changing. We have to be agile & adapt
DF is the most challenging forensics discipline because of the changes
The software tools you use in an investigation don't matter - your brain is your best tool.
You have to have a plan - this is *key* (and your steps should be consistent)
CLI is your friend. Yay, Chris! :)

Sean Morrissey - iOS Forensics
I have used Lantern and tend to prefer it over Mobilyze. However, I really would have liked more info about "iOS Forensics" (ie, important artifacts and how to use them) than a presentation about Lantern.
Putting an iPhone in airplane mode does not disable WiFi. So if you are acquiring one, remove the SIM, put in AM, disable WiFi & bluetooth, and use a Faraday bag if need be.
To recover/carve deleted entries from SQLite db, look for "de-referenced" items.

NetWitness Lunch&Learn (I think the presenter was Michael Sconzo, from their CIRT)
It was technical, not a sales pitch, and very much about results of network investigation for malware, as opposed to what NetWitness can do.
The main idea was to know what "good" or "benign" http sessions look like so you can quickly recognize anomalies. I think he actually mentioned something about reading RFC 2616; I don't remember anything after that point... Just kidding; it was very informative.

Hal Pomeranz - EXT3 File Recovery via Indirect Blocks
What can I say - you give Hal a command line, a hex editer, a Linux file system, and he just starts dancing!
File-carving assumes 100% contiguous data...
Indirect block pointers are not nulled out when a file is deleted (unlike direct pointers).
When decoded, they will point to the next block #.
Hal has some tools to automate the process of recovery, rather than manually follow the indirect pointers; it basically runs on top of TSK and calls those utilities as it needs:
frib (file recovery indirect blocks) - this works if you know where the file started, and can progress forward from there.
fib (find indirect block) - finds indirect block (by signature, within the block grouping you're targeting), then counts back 12 blocks to what should be the start of the file.
He has a whitepaper and the tools on Mandiant's blog

RMO's were handed out by Rob Lee, to:
David Kovar - for AnalyzeMFT
Bamm Vischer - for sguil
Congratulations, guys!

Terry Maguire - IR Process & Smart Phones
As these phones become more common in the enterprise, we have to know how to handle them.
**Note: both android and iOS use a lot of SQLite db files.
-sqlite browser (sourceforge) is good, but no deleted entries will show
-epilog by CCL Forensics is designed to show deleted entries (not free, commercial product)
Android must be rooted to get access to any real information. This requires modifying the phone, if if you use something z4root that can be undone with the click of a button.
In order to get volatile data from iPhone, it will have to be jailbroken.
Blackberry cannot be imaged like other devices; removing & imaging chips might be possible. Blackberry file system can be mounted either through desktop manager or javaloader, but be careful; it's easy to destroy data! Blackberry Messenger SMS are not contained in IPD files; they can only be collected from mounted file system.
ABC Amber Blackberry Converter is now Backup Blackberry Explore by Elcomsoft.

Mike Cloppert - Distinguishing IR from Computer Network Defense
He's in Andrew Hay's original slot.
APT & such are much more advanced than the traditional IR models developed a decade ago:
Highly aware (situational awareness)
Adaptive
Lots of tools
There may be multiple adversaries/attack vectors simultaneously or near-simultaneously.
Campaigns (by adversaries) may span several years.
The conventional IR model is based on the presumption of a successful compromise. If it's an "imminent threat" the model doesn't fit. The model is reactive, not proactive. Needs to be more proactive.
Have a monthly overview of reporting to help determine where to focus preventive efforts.

Day 2

Kristinn Gudjonsson - log2timeline
version 0.60 - the "killer dwarf" release - now works on Windows; instructions on how to install in docs/install (Chris Pogue created/tested documentation).
Rewritten engine, work is done on back-end.
It is more object-oriented, and has preprocessing modules.
With the front-end not doing processing, you can easily build your own, for integration into your own processes, customize default action, etc.
It now has a Skype parser. It includes code from regripper and regtime to automatically pull in all the registry data. And (drumroll, please) David Kovar's AnalyzeMFT has been imported as well, to parse the MFT. Of course, that means it had to go from python to perl, but we won't get into that.

Mike Pilkington - Protecting Privileged Domain Accounts during Live Response!
Mission: remote access to WinXP (SP2) workstation (no patches) for analysis/triage
wmic
psexec
netuse
You don't want attackers who may be present to capture privileged credentials.
Do not use any type of interactive logon as this will cause a password hash to be stored locally. Running psexec creates a vulnerability for delegate-level access token theft. Don't set IR accounts as admin accounts; put them into different groupings and give those elevated privileges only as needed.

Panel: Professional Development in Digital Forensics and Incident Response
Lenny Zeltser, Richard Bejtlich, Ken Dunham, Joe Garcia, Bamm Visscher
Everyone had pre-formatted questions they spoke about, then it was open to questions from the audience. I will touch on one, for Richard: How do I build a computer incident response team? I thought the absolute key to it was his statement that you have to keep the groups tightly-knit and give the analysts what they need to do their jobs - training, equipment, etc. The best part was that he said you have to protect them fiercely. That's leadership! He had a blog post about this recently; it's obviously important to him.

Lee Whitfield - Digital Forensics and Flux Capacitors
Looking at reasons/ways people try to get out of trouble with their computers
Focus: Time/system clock alteration (as an excuse)
Top places to check at start of investigation
system event logs (except on XP, where it's not as important)
$UsrJrnl.$J
LNK files
Restore Points
Who is @gingerlover_17 Lee? ;)

Hal Pomeranz - EXT4: Bit by Bit
Changes in EXT4
48-bit address space
Uses extents instead of indirect block chains
64-bit nanoseconde resolution timestamps
File creation time timestamp (born, or b-time)
Backwards compatibility design goal
Inodes expanded to 256 (from 128)
Most of offsets listed in carrier's book still apply to ext4
Hal dove right in with his hex editor, heads exploded, Hal danced, twitter was on fire, etc. It was a very good presentation!

Panel: Forensics in the New Cloud Frontier
Andrew Hay, Cory Altheide, Joe Garcia, Robert Lee, Ed Skoudis
The questions were sprung on the panelists w/o preparation. Wow.
Here's my take: The cloud is here. It's not leaving. You need to know what kind of alerts your cloud provides (to indicate compromise/issue, like gmail's alerts to different locations accessing your account). Distributed processing is going to be key to future analysis (think multi-GB log files). Make sure your cloud provides you with auditing capabilities, as logs are going to be the target of your analysis. Look at the kind of data you've needed from recent incidents, and see if you can get that from your cloud.
Then it was opened up to the audience's questions, including:


#dfirsummit Q for panel: Would you get a 4Cast award for staying within a reasonable budget while proactively responding using sniper forensics, five point palm methodology and log2timeline to analyze a mobile device running ext4 whose clock was reset using false domain credentials through the cloud?

Does that question not totally sum it up?

Oh, there was one more panel, the vendor panel. I had to leave right before that, so that's where my summary falls short. However, I think the last question for the previous panel is the best place to end...

LM

Forensic4Cast Awards - Voting

I'm only going to say this once. At least right now, that is.

Everyone, go over to Forensic4Cast Awards and vote for log2timeline "Best Computer Forensic Software" category.

I don't care what/who else you vote for, but you must for log2timeline. Kristinn has done an incredible job with this software, is extremely helpful, and deserves all the accolades he can get. Read his blog, too.

L2T's up against some big players, and needs everyone's votes. IMHO, this is a greater contribution than EnCase or FTK3. Thank you.

Now you can call me a fanboy. :D

LM

PS: Thanks to Eric for posting that the voting was open. You can vote for his blog, too; he puts a lot of effort into it, and it's a good one.

PPS: In the "Best Civilian Forensic Team" category, I understand Digital Discovery pulled off the collection mentioned over the course of 1 1/2 days. Obviously Mandiant's the top of many a sane person's list but I hear the DDC crew rocks (no, I didn't nominate them).

PPPS: As per post above this one, the DDC crew no longer rocks the same as they used to... ;)

Using Log2Timeline with USB Device History

I just have to do a post about a benefit of using log2timeline, because this is entirely too cool.

On a recent investigation, one system had a Seagate FreeAgent Go (USB HD) attached at some point, and this showed up in USB history (from Woanware USB Device Forensics and RegRipper). However, I could not associate it with the user profile through MountPoints2 (MP2) because the USBSTOR didn't contain the Parent Prefix ID Prefix (PPID) for this device. The PPID is used in MountedDevices to identify the drive letter association and GUID; the GUID is then used in MP2 to identify the user (without the GUID you get nothing). Basically all I had was the Vendor, Product, and Version from USBSTOR, along with the connection date from DeviceClasses. As a side note, Enum\USB also did not provide the Volume ID (VID) or Product ID (PID).

At first I wasn't sure why the parsed MP2 didn't show the user association, so I went through the manual process (as detailed by SANS, Harlan Carvey, etc). This revealed what I've noted above regarding the PPID. Even though I did not necessarily need to, I also went through the setupapi.log just to confirm install date, and work the steps, as it were.

To quickly find the device in setupapi, I searched the file for "FreeAgent" using Notepad++. By clicking the "Find All in Current Document" button (as opposed to "Find Next"), I saw that there were hits in very different locations within the file. Looking more closely at these entries, I discovered that there had in fact been two Seagate FreeAgent Go drives attached to the system, more than a month apart. Well, well, well. The serial number for the second one (as logged in setupapi, which also showed the VID and PID) did show up in RegRipper's output for USBSTOR and DeviceClasses, but again that wasn't everything.

I must note at this point that until I started going through manually I hadn't spent a lot of time on RR's output, having focused on Woanware with its nicely organized text file and spreadsheet for ease of use as I had a lot of systems and not a lot of time. I had confirmed the first drive's existence, but hadn't looked to see if there were more like it. Good reminder to cross-check results, even though it may take significantly more time, depending on the amount of relevant data...

Anyway, all that said, here's the cool part with l2t. I loaded up my timeline (created by l2t's CSV output module) in Excel and went to the date/time of the initial setupapi.log entry. Sure enough, there were the install entries, just like expected. And immediately following the installation activity came the MountPoints2 key entry parsed from System Restore Point RPxxx, showing the user association. This was true for both drives in question. In addition, these historic MP2 entries showed the GUID, to help round out the analysis. Aaah, the sweet smell of forensication in the morning... ;-).

Call me a fanboy if you must, but I do like log2timeline. Thanks, Kristinn!

LM

Date-Range Specific Timelines

In the prior posts I built a timeline with the new mactime- and csv-format options in log2timeline, I used my bodyfile as input and exported to a nice csv that includes more l2t-related data (as opposed to standard mactime-generated csv). This is nice, but l2t generates one line per timestamp type and gives us a whole lot of rows. Turns out my main timeline was just too much data to be able to load in Excel or Access. Even with 64-bit Win7 and 16 GB of RAM on a Quad-Core processor. Apparently 1.2M rows is just insane. Meh.

I tried to get Kristinn to do things differently, but he just wouldn't see it "my" way. ;) However, in true form, he was extremely helpful. We walked through using grep against an l2t-generated csv to get out some specific sub-ranges that I needed to focus on, like:

head -1 csv.001 > dates.001
grep “^0[2-5]\/[0-3][0-9]\/2009,” csv.001 >> dates.001

This will split out all rows containing data originating (any timestamp type) from February through May of 2009.

Lo and behold! Kristinn also went and created a new module in the nightly build and asked me to help test it. It would automate the process, so you can feed in a date range (kind of like with mactime) and it will pull those dates out of an l2t-generated csv file. Way cool! And so the testing began.

Fortunately by that time I knew my test-set inside and out, so that was helpful in providing him statistics to help track down a few items. In the end, the process was ironed out and works very nicely. I'm not here to post all the specifics, as I know he plans to include it in the next release, and blog about it as well, so I'm leaving that to him. It's his baby, after all. I'm just trying to raise more awareness of this awesome utility, a cool developer, and get more traffic on his sites. Every time I've had a question or problem/concern, Kristinn has been extremely responsive and helpful. Twice now he's written new modules just because I asked if it could be done. Incredible!

I don't think he'll mind me saying that if you're using the nightly build, look for l2t_process; it even has its own man page.

Happy timelining!

LM

Timeline Registry Automation Script

I just couldn't keep from writing the script. Just couldn't. After going through the process yesterday, then posting about it, I just kept thinking about how I could streamline the process, so I took me a little bit of time and worked up the following. Ran through it a few times to make sure it worked and tweaked it a little.

Please keep in mind, I'm no scripting guru (aka, Hal Pomeranz et al) , so this may seem kludgy. But it does work. I could probably feed it a list of mount points and output files to fill in the variables and have it run through the whole of it, but that would probably take me more time to create and test (and fix) than it would for me to run this a handful of times.

So here it is, in all its (lack of) glory:



_________________________________________________________________

#!/bin/sh
#
# Script to automate regripper in linux for timeline creation.
# This is designed to be run from your regripper directory.
# This version of rip.pl is brought over from the Windows download to run in Linux based on http://grey-corner.blogspot.com/2010/04/running-regripper-on-linux.html
#
# This will will automatically run through the 4 hives in a given mount point and write specified output file.
# By default, the 'all' module is run, rather than specific to hive type.
#
# $Src is the path (mount point) to be recursed for file in question
# $Dst is the path & file for regripper output (path must already exist)
# Order of operation should be ./rip.sh src dst
Src=$1
Dst=$2
#
#
# Check that the user provided all arguments required by this script.
if [ -z $1 ]; then
echo -e "USAGE: rip.sh SOURCEDIR OUTPUTFILE";
exit;
fi
if [ -z $2 ]; then
echo "USAGE: rip.sh sourcedir TARGETFILE";
exit;
fi

echo

echo

#
# Begin the job, updating the user along the way.

echo "Parsing user hive ... Please be patient."

echo

find $1 -iname ntuser.dat | while read d; do ./rip.pl -f all -r "$d" >> $2; done

echo

echo "Thank you for being patient."

echo

echo

echo "Parsing system hive ... This will only take a minute."

echo

find $1 -iname system | while read d; do ./rip.pl -f all -r "$d" >> $2; done

echo

echo "See, I told you it wouldn't take long."

echo

echo

echo "Parsing security hive ... Just a second, it's almost done."

echo

find $1 -iname sam | while read d; do ./rip.pl -f all -r "$d" >> $2; done

echo

echo "There! I can't believe you're so impatient."

echo

echo "Last one - the software hive ... Hold your horses, okay?"

echo

find $1 -iname software | while read d; do ./rip.pl -f all -r "$d" >> $2; done

echo

echo "Okay, we're done now. Stop complaining; I worked as fast as I could."

echo
echo

echo "If you want to run another system, please start over"

echo

echo "Thanks for playing; have a nice day."
echo

# end of script
#

_________________________________________________________________


Here's hoping someone can use it.

Cheers!

LM

Timelines with Registry Data

I've posted before about log2timeline, and now I'm going to add to that a bit.

This is about incorporating regripper output into the timeline. SANS teaches about this in FOR508, and I'm going to "streamline" the process a bit. Without SANS (where I learned of the possibilities) and Harlan Carvey (the source of regripper), and coffee this would not be possible.

So here's the situation: I'm working an investigation with several systems, and starting by building timelines. Standard process - fls, l2t, mactime. But before working up the final bodyfiles and running mactime, I'm going to pull in registry data with regripper.

I'm working in my linux system, which is Ubuntu based. Using Lupin's great post here I've incorporated the latest version of regripper into my system.

At first I was going to bash it together with variables, but in the end it seemed like there would be four or five, and I thought that was too much typing across several images. It seemed more efficient to type my command line once, then repeat and modify the couple things I would need.

So my evidence items are numbered sequentially, like XYZ-001, XYZ-002, and so on. Their respective file systems are mounted accordingly on /mnt/001, /mnt/002, ... The drive containing the images is a Truecrypt volume, so it's mounted on /media/truecrypt1. I'm storing my output files in a separate directory for each evidence item, named for the number and custodian, like /media/truecrypt1/001_jones, /media/truecrypt1/002_smith, etc. The bodyfiles I've already created are named like 001.fls, 001.l2t so I can easily tell which is which. My regripper output will continue in that vein with 001.reg.

Now regripper documentation and SANS teach to use it by pathing out to each hive, then redirecting output somewhere. Something like:
# rip.pl -r /media/sda2/Windows/System32/config/SAM -f sam >> /media/sdb1/evidence/timelines/jones_regripper.txt
Something like that. But that's too much typing for me. And like I said, I thought about scripting it, but there's just too many variables for what needs to be done - source path, source file, module, destination path, destination file, ack pfft!

So to pull a page from my old ways with log2timeline (before timescanner), I did the following, from within my regripper directory:
# find /mnt/001/ -iname system | while read d; do ./rip.pl -f all -r "$d" >> /media/truecrypt1/001_jones/001.reg; done
Then all I have to do is replace "system" with "sam" "software" and "ntuser.dat" and that takes care of 001. For 002 I change the "1" to "2", change "jones" to "smith" and I'm good to go. Far quicker than typing all the paths each time, or plugging in several variables. If I wanted to get more creative I probably could script it to run through the various hives for each set of variables, and then just put in the set for the next custodian system. That might be okay, but I didn't feel like going that far today. Now that I think about it, I believe I will tomorrow, though.

This is no command line kung-fu, but I like it; it's better than a bunch of typing anyway. What it does is within the /mnt/001/ directory, it searches for files named "system" with no case-sensitivity. STDOUT is the normal output; this is piped to a while loop that runs rip.pl against the "system" file (-r). I had some errors trying to use the specific modules (-f) and being lazy (just like not wanting to type) I decided just to try "all." This worked just fine, no more errors. You'll see as it runs that regtime is called; I believe this is what creates the mactime-formatted output.

That takes care of my timeline pieces. Now to get a single bodyfile for each system... Within my output directory (/media/truecrypt1/001_jones):
# cat 001.* >> body.001
I'm now reversing the order, to keep my pieces separated. It helps me track the flow/progress as well, which I'll show next.

I'm trying to identify areas of activity (or inactivity) over several months so that I can focus in on details with a more limited timeframe. To do this I'll be running mactime and building a daily index. For 001, this looks like:

# mactime -d -z CST6CDT -m -y -b /media/truecrypt1/001_jones/body.001 2010-01-30..2010-05-24 -i day >> /media/truecrypt1/001_jones/index.001
This is just wrong. Shame on me. Here's how it needs to be:

# mactime -b /media/truecrypt1/001_jones/body.001 -i day /media/truecrypt1/001_jones/index.001 -d -m -y -z CST6CDT 2010-01-30..2010-05-24

This gives me a CSV file (-d) that gives a nice overview of total activity each day during my ~4 month period. Then hopefully I'll be able to focus in on a few specific days that look interesting (maybe a lot of activity, maybe very little). All these options are in the help info or man pages, but in brief -d gives a CSV output, -z allows you to set the timezone, -m and -y set the date format, -b specifies a bodyfile, then comes the date range I'm interested in, and last -i specifies to generate an index; it's either "day" or "month", and must be redirected to the output file. Again, all I have to do is change "1" to "2", "jones" to "smith" and move on to the next.

Now my output directory has the following files:
001.fls, 001.l2t, 001.reg, body.001, index.001
This makes it easier for me to keep track of the different sets of data, and their formats. The pieces that go into my main bodyfile start numerically, and the combined datafiles end numerically. I know everyone has a different way; just wanted to share my logic/excuse.

I hope that can help someone. I should (hopefully) have some sort of shell script together tomorrow that would loop through the different hives for each custodian. There would still be several parameters to input initially, but it might work out to be faster going through four hives than up arrow, back arrow, replace... Once I have it I'll post that as well.

LM

Note: Edited to correct mactime syntax to create index files.

Using Log2Timeline

Log2Timeline and forensic timeline creation


Creating timeline w/mmls, fls, log2timeline
This is really written with an image of a Windows system in mind. This was written as a guide for our lab (and me, to help remember), so keep in mind it's not necessarily intended to be a polished presentation. Some things were added/changed as my use of l2t progressed. The big difference between this and what has been published on the SANS blog and on Kristinn Gudjonsson's site is the use of 'find' and 'while' loops to recurse through directory structure instead of (for instance) going into each user profile for the ntuser.dat file.

These l2t cli bits of this are largely irrelevant now, with the introduction of the timescanner front-end (which does a great job of automating everything for you). However, there may (hopefully) be some other things of interest/use in different scenarios.

You do not have to extract the partition, but it's helpful to have a single image file for mounting purposes (I'm not sure about mounting a split image; at the least it will be easier to have a single/concatenated file)...

NOTE: Where something is enclosed such as [imagename] this includes full path to that file where needed; the "name" is a variable assigned by the analyst.

You need to gather partition info, which can be done with mmls or fdisk:

mmls [imagename] - this will show partition info (even from split image files), and you can identify whichever partition(s) you need (specifically you need the start point).
or
fdisk -ul [imagename]

To create the baseline bodyfile, use the following:
fls -m [original mountpoint, ie C:, /boot, etc] -r -f [file system type, type 'fls -f list' to find the values] -i raw -o [offset/start sector info from mmls] [path to imagefile] > [path to new bodyfile]
NOTE: The offset here is the straight info provided by mmls; it is not multiplied by 512 (sector info)

Variables here are:
C: - this is however you want it to show in the bodyfile for drive letter; keep in mind if you are working multiple partitions... (-m is what allows you to set this parameter)
ntfs - this will depend on the file system in question (-f denotes you will provide filesystem)
raw - this will depend on the image type (-i denotes you will provide image type)
offset info - as stated, this comes from mmls or fdisk (-o denotes you will provide offset)
recursive - this is denoted by (-r) which says you are recursing into all subdirectories

Bodyfiles are converted to timeline format w/mactime command (you don't do this now; it will happen at the end):
mactime -b [bodyfile] -d -m -y -z [timezone] 2000-01-31..2000-02-01 > [timelinefile]
Variables here are:
-m and -y: go together to establish date format - yyyy mm dd and day of week
-z: sets the timezone of the original system/image
-b: you will define the bodyfile to be used
-d: provides output in CSV format (this will add the timestamp to every line, even if it's the same second - you need this!)
dates: date range provided in yyyy-mm-dd..yyyy-mm-dd format - must use both, even for single day (in which case, the 2nd date MUST be one full day after) such as:2009-11-10..2009-11-11
NOTE: For original/main bodyfile, you won't use the date parameters; you want the entire system bodyfile intact (you will split out later if needed)
NOTE: There are some cases where you are having to process multiple bodyfiles into a single timelinefile, and want to use >> to append instead of overwrite. Be careful!

Creating log2timeline bodyfiles:
You can use the following to get lists of l2t variables/parameters:
log2timeline -f list

First you must mount the imageset loopback to be able to browse the filesystem for use w/l2t:
Multiply the Offset info (from mmls or fdisk) by the number of bytes per sector (also from mmls or fdisk), typically 512 (such as 63*512=32256)
mount -o ro,loop,offset=32256 -t auto [imagename] [mount point]
Variables here are:
offset: this will depend on the result of your partition math, as noted above

NOTE: I use mkdir to create my mountpoint, using things like "src" for source and "dst" for destination instead of relying on drive lettering (such as sdc1)

Now you can browse the mounted filesystem for your imageset, in order to create bodyfiles for l2t...

cd to any relevant profile, for ntuser.dat files
log2timeline -f userassist NTUser.dat > [UAbodyfile]
or from within Documents & Settings, do:
find . -iname ntuser.dat | while read d; do log2timeline -f userassist "$d" >> [UAbodyfile]; done ****This works better - more automated****

while within profile, run LNK files (if there are multiple users, do so within Documents & Settings):
find . -iname *.lnk | while read d; do log2timeline -f win_link "$d" >> [LNKbodyfile]; done

while within profile, run IE history (if there are multiple users, do so within Documents & Settings):
find . -iname index.dat | while read d; do log2timeline -f iehistory "$d" >> [IEbodyfile]; done

while within profile, run Firefox 3 history drill down into Application Data/Mozilla/Firefox/Profiles/xxxxxxxx.default and do:
log2timeline -f firefox3 places.sqlite > [FFbodyfile]
or from within Documents & Settings, do:
find . -iname places.sqlite | while read d; do log2timeline -f firefox3 "$d" >> [FFbodyfile]; done ****This works better - more automated****

cd to Recycler directory, and down into each S-1-5...
log2timeline -f recycler INFO2 > [RBbodyfile]
or from within RECYCLER directory, do:
find . -iname INFO2 | while read d; do log2timeline -f recycler "$d" >> [RBbodyfile]; done ****This works better - more automated****

cd to System Volume Information/_Restore/RP... for restore point info (you do not have to go into each subfolder)
log2timeline -f restore . >> [RPbodyfile]

cd to Windows/Prefetch directory for prefetch info
log2timeline -f prefetch . >> [PFbodyfile]

With all of your individual pieces, create a copy of your original system bodyfile, and add the l2t bodyfiles into it:
cp [bodyfile] [bodyfile2]
cat [XXbodyfile] >> [bodyfile2]
Repeat for each l2t bodyfile (denoted by the "XXbodyfile")

You now have a single bodyfile which contains all the l2t variables/optional bodyfile info. This is the point you will start splitting out timeline sections with date ranges:
mactime -b [bodyfile] -d -m -y -z [timezone] 2000-01-31..2000-02-01 > [timelinefile]

___________________

PS: I am very disappointed that Kristinn did not get the recognition he deserves through this year's Forensic4Cast awards. Log2Timeline is by far and away (in my book) the absolute best software contribution to digital forensics, and should have won that category hands down!