Registry Artifacts: Adobe Acrobat Reader

As you probably already know, the Windows Registry is a treasure trove of forensics artifacts that can come in quite handy during investigations and incident response.  Many applications leave quite the trail, and I’ve decided to start documenting these less common sections in the registry and sharing the information that I find on my blog.  We’ll start with Adobe Acrobat Reader:

In addition to recently accessed files showing up under the RecentDocs key, Acrobat Reader itself stores a list of the 5 most recently accessed PDF files in the user’s hive.  This information can be found in the subkeys under Software\Adobe\AVGeneral\cRecentFiles.  The subkeys found in this location are labeled cx (where x is replaced by the numbers 1 through 5), and under each of these subkeys you’ll find a value named tDIText which contains the full path and filename of the recently accessed pdf file.  Every time a new PDF file is opened in Reader, any existing values found in cx are copied to cx+1 and any values that were in c5 are lost (of course, keep in mind that you may be able to use VSS to recover old hives).  Unfortunately, Reader does not store date/time stamp values in these subkeys; however, you can get the date and time of the most recent file access (for the file information stored in c1) by reviewing the registry key’s last write time.  For all of the other files described in the other subkeys, given no other supporting data, you’ll only be able to state that the pdf file was accessed but will be unable to definitively state when.

If/when I discover any other interesting artifacts left by Adobe Acrobat Reader in the registry, I’ll make sure to update this post with my findings.  Feel free to leave me a comment as well if you have any additional Reader related artifacts that you review as part of your workflow…

Volume Shadow Copies

Harlan Carvey recently wrote a post on his blog called Accessing Volume Shadow Copies, which provided some excellent instruction on how you can go about accessing Volume Shadow Copies (VSCs) from an existing image without having to use expensive tools (in fact, his solution uses completely free tools).  In Windows 7 and Vista, VSS is turned on by default and thus additional artifacts are possibly just waiting to be discovered.  Accessing a system’s VSC(s) can be highly useful in an investigation and can possibly help you get your hands on older copies of registry hives (i.e. being able to get historical UserAssist data, etc) as well as other older file snapshots (pictures, etc), which can come in very handy.  So, needless to say, if you’re not presently looking for VSCs as part of your forensics workflow, you probably should be…

In the process of testing Harlan’s procedure, I started to wonder how Windows, by default, decides to generate these VSCs (and what is included).  I came up with some data and I thought that I’d go ahead and post my findings (feel free to comment if I’ve gotten anything wrong here):

  • Windows 7/Vista automatically (out of the box) create restore points at pseudo-random intervals:
    • A scheduled task (named SR in Win7) controls when a snapshot occurs.  By default, the task is set to run at 12:00AM every day and 30 minutes after every system startup, but will only execute when the system is plugged in and has been idle for 10 minutes.  If the system is not idle, the task will continue to wait for idle for 23 hours.
    • If a restore point/snapshot has not been successfully created in the last seven days, system protection will create one automatically.
    • And finally, a restore point may be created “automagically” as part of certain software installation/driver installation processes.
    • The bottom line: it is basically impossible to predict with any degree of certainty when a snapshot will occur.
  • All files/folders are covered in a volume snapshot, except for those defined under the HKLM\System\CurrentControlSet\Control\Backup Restore\FilesNotToSnapshot registry key.
  • If a file is modified several times between snapshots, only the version that was current when the restore point/VSC was made will be available to you for analysis.  Mind you, there may be multiple VSCs available, so that can be helpful with getting further historical revisions.

Additional resources:

Wikipedia – System Restore
Wikipedia – Shadow Copy

QCCIS – Reliably recovering evidential data from Volume Shadow Copies Whitepaper