Thursday, July 29, 2010

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.

No comments:

Post a Comment