Forensic implications of MS Word ASD files

Microsoft Word .ASD (auto-save/auto-recovery) files.

Reference, MS KB Article ID: 107686, previously Q107686: http://support.microsoft.com/kb/107686

I had a case a while back in which Auto-Save/Auto-Recovery (ASD) files from MS Word were brought up. The other side made some allegations as to the purpose and function of ASD files that I did not believe to be true. In order to confirm this I read through the MS documentation, and did some testing, as follows...

Per the KB Article, the default is to create an .asd file every 10 minutes, in the default path: Documents & Settings\\Application Data\Microsoft\Word (note: this path can be changed manually)

The stated purpose, per the KB, is for recovery after a crash (system or application) where the document is not able to be saved properly the user; it is not a substitute for saving files, nor is it the same as the auto-save feature.

A quote from the KB: "AutoRecover files are not designed to be saved when a logoff is scheduled or an orderly shutdown occurs."

Per the KB, when Word starts, it looks in the default path for the presence of any .asd files; if found, it will display to the user, and prompts the user to "recover." Apparently when it opens the .asd file, it changes the extension to .wbk (depending on version of Word - Word 7.x uses .bak instead of .wbk, for instance). If the file is saved, or closed w/o saving, Word deletes the AutoRecovery version.

Through testing, my results (all work done in EnCase):
**Note: In between each "Open" or "Load" Word and/or EnCase are closed and reopened fresh.

Open existing DOC.doc, wait 10 minutes (minimum) and close w/o making changes or saving the document.
Load local HD, search for ASD, WBK - no results.

Open existing DOC, alter text with '.'
Wait 10 minutes minimum, then load local HD, search for ASD - it is present, with the file still open.
Save and close file.
Reload local HD, search ASD - no results.

Reopen existing DOC, make no changes.
Wait 10 minutes minimum, then load local HD, search for ASD - not present, w/o changes.
Remove previously added '.'
Wait 10 minutes minimum, then load local HD, search ASD - it is present, w/change, prior to saving.
Close DOC w/o saving change.
Load local HD, search ASD - it is present, as a deleted file.
Size is the same as the live file, and content (in hex or raw text view) shows the same as the real file.

Reload local HD (10 minutes later, minimum), search ASD - still present, as deleted file.
Reopen existing DOC, remove the previously added '.' Note: Word did not prompt for Recovery of a file.
Save corrected DOC.

Load local HD, search ASD - no results; it is now gone, since the file was saved (even though file wasn't opened from the auto-recovery feature).

Conclusions:

ASD file is ONLY created once the open file is modified (content changed), 10 minutes later.
It does take 10 minutes, even w/changes, for the ASD to come into existence.
If the file is closed w/o saving changes, the ASD goes into a deleted state, but still exists.
The ASD file matches the "real" file for size and content. Not sure about embedded metadata (I didn't test that)
If there is an ASD (even deleted), once the "real" file is opened and saved, the ASD automatically goes away.
Presuming that the MS KB is accurate, if a true, live ASD exists, it will go away (to a truly deleted state) once the file is recovered and closed/saved;
it may even go away if the file is not allowed to recover (haven't tested these, but it seems to be what the KB is saying).

Ultimately I was correct and was able to support this by my research and testing.

I guess I would say that the forensic implications are that Microsoft's documentation is not 100% complete/accurate, and one should not make assumptions about the state of ASD files simply based on "common knowledge." You may find such files on a system, and they don't *have* to be in the default directory.

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!

Computer Forensic Blog Intro

Computer forensics blog, 'forensicaliente' ~

So, the name is completely geeky, but hey, that should be worn like a badge of honor. Or perhaps a SANS Lethal Forensicator ROM (Round Metal Object, aka, 'coin')... :) No, I'm not sayin' for me, I'm just sayin'.

In looking for something in IT jobs that really truly interested me, I came across computer forensics (digital forensics, whatever you want to call it), and managed by the grace of God to get into the field. I have been working here for several years now and absolutely love it. I think it's the coolest thing since sliced bread, pockets on shirts, and so on. Or with slang/euphemisms being what they are, sometimes 'cool' = 'hot' and thus 'forensicaliente...'

As I work through problems, come up with questions to test and try, I have developed a fairly sizable Evernote library (or maybe not so sizable, who knows?). I finally decided to put things into a blog in the hopes that they may help others. That's one of the things I think is so neat about CF, that so many practitioners share so generously, and I'd like to contribute to the community as well.

While I won't likely be as prolific as some of the great forensic bloggers, I will try to start out with a number of posts from my library of notes, and add to it as I go along. I hope these are of use and benefit to others.


PS: And yes, the site is largely unformatted; I'll be working on that too.