HowTo: Determine User Access To Files

Sometimes during an examination, it is important for the analyst to determine files that the user may have accessed, or at least had knowledge of.  There are a number of artifacts that can be used to determine which files a user accessed.  As of Vista, the Windows operating systems, by default, do not update the last accessed times on files when normal system activity occurs, so some other method of determining the user (or process) that accessed files, and when, needs to be developed.  Fortunately, Windows systems maintain a good deal of information regarding files users have accessed, and some artifacts may be of value, particularly in the face of the use of anti- or counter-forensics techniques.

Files on the Desktop
By default, Windows does not normally place files on a user's desktop.  Most often, installation programs provide an option for putting a shortcut to the application on the desktop, but files themselves usually end up on the desktop as a result of direct and explicit actions taken by the user.  The presence of the files themselves on the desktop can be correlated with other artifacts in order to determine when the user may have accessed those files.

Recycle Bin
Clearly, if a user deleted files, they had knowledge of them, and accessed them to the point that they deleted those files.  However, keep in mind that this is not definitive...for example, if the user uses the Shift+Del key combination, or the NukeOnDelete value has been set, the files will bypass the Recycle Bin.  As such, an empty Recycle Bin should not lead to the assumption that the user took the explicit action to empty it.  It's trivial to check artifacts that can significantly impact your findings, so do so.

Tools: Various, including custom Perl script (recbin.pl)

LNK Files/Jump Lists
Most analysts are familiar with Windows shortcut/LNK files, particularly as a means of demonstrating user knowledge of and access to files.  LNK files within the user's Windows\Recent and Office\Recent folders are created automatically when the user double-clicks the files (and the application to view the file is launched), and will contain information about the location of the file, etc.

AutomaticDestinations Jump Lists are similarly created automatically by the operating system, as a result of user actions.  These files consist of a compound binary format, containing two types of streams...LNK streams, and a DestList stream, both of which are documented and easily parsed.  The DestList stream serves the purpose of an MRU list.

Browser History
Browser history, in general, illustrates access to pages found on the Internet, but can also provide information about other files that a user has accessed.  Browser history, particularly for IE, can contain file:/// entries, indicating access to local, rather than web-based, resources.

Tip
If you find that the LocalService, NetworkService, or Default User accounts have an IE browser history (i.e., the index.dat is populated...), this may be an indication of a process running with System level privileges that is accessing the Internet via the WinInet API.

When it comes to browser history, you will also want to look at file downloads.  Beginning with Windows XP SP2, files downloaded via IE or as OutLook attachments had a Zone Identifier NTFS alternate data stream attached to them by the operating system.  I have seen this, as well, on Windows 7 systems, but irrespective of the browser used.

To illustrate this, open a command prompt (should open to your user profile directory) and type the following command:

dir /s /r * | find "$data" /i | more

This can be very revealing.  Of course, it doesn't illustrate where the files are located, as you're applying a filter to the output of 'dir' and only showing specific lines, but it can provide a good indication of files that you've downloaded.  Also, I'd be very wary of any Zone Identifier ADSs that are more than 26 or 28 bytes in size.

Prefetch Files
It's common knowledge amongst analysts that application prefetch files provide information regarding when an application was run, and how many times that application was run.  These files also contain module paths, which are essentially embedded strings that point to various files, usually DLLs.  Many times, however, the module strings may point to other files.  For example, an application prefetch file for IE will include strings pointing to the index.dat files within the user profile (for the user who launched it).  The application prefetch file for sms.exe in Lance Mueller's first practical contains a path to "del10.bat", as well as a path to the sms.exe file itself, both of which are very telling.  I've seen application prefetch files for keystroke loggers that have contained the path to the file where the keystrokes are recorded, which just goes to show how useful these files can sometimes be, and that there's a great deal of information that can be pulled from these files.  Application prefetch files can be tied to applications launched by a particular user (i.e., correlate the last run time embedded within the file to program execution information for the user), which can then provide information regarding how the files were accessed.

Tools: Custom Perl script (pref.pl)

Registry
The Registry is well-known for being a veritable treasure trove of information, particularly when combined with other analysis techniques (timeline analysis, parsing VSCs, etc.).  While not everything can be found in the Registry (for example, Windows does not maintain records of files copied...), there is a great deal that can be found within the Registry.

RecentDocs
Most of us are familiar with the RecentDocs key within the user hive.  This is one of the classic MRU keys, as the key itself and all of it's subkeys contain values, and on Windows 7 systems, one of the values is named MRUListEx, and contains the MRU order of the other keys. The other values beneath each key are numbered, and the data is a binary format that contains the name of the file accessed, as well as the name of an associated shortcut/LNK file.

Each of the subkeys beneath this key are named for various file extensions, and as such, not only provide information about which files the user may accessed, but also which applications the user may have had installed.

A means for determining the possible use of counter-forensics techniques is to compare the list of value names against the contents of the MRUListEx value; numbers in this value that do not have corresponding value names may indicate attempts to delete individual values.

Tools: RegRipper recentdocs.pl plugin

ComDlg32
The user's ComDlg32 key contains information related to common dialogs used within Windows, and can provide specific indications regarding how the user interacted with the files in question.

Some of the subkeys beneath the ComDlg32 key are...

CIDSizeMRU
As described in a previous post, this key provides indications of program execution.

LastVisitedPidlMRU and LastVisitedPidlMRULegacy
These keys contain MRUListEx values, as well as numbered values.  The numbered values contain the name of the executable from which the common dialog was launched, followed by a shell item ID list of the path that was accessed.

OpenSavePidlMRU
This key is found on Vista+ systems, and corresponds to the OpenSaveMRU key found on XP systems.  The subkeys beneath this key correspond to the extensions of opened or saved files.  Each of the numbered values beneath the subkeys consist of shell item ID lists, and there's an MRUListEx value that provides the MRU functionality for each key.

On Windows XP, value data beneath the ComDlg32 subkeys consist of ASCII strings, whereas on Vista and Windows 7, the value data consists of shell items.  This means that in some cases, those data structures will contain time stamps.  However, to be of use during an examination, the analyst needs to understand how those time stamps are created, and maintained.

Tools: RegRipper comdlg32.pl plugin

MS Office File/Place MRU Values
Each of the applications within MS Office 2010 maintains an MRU list of not only files accessed, but places from which files have been accessed (in separate keys).  In addition to the paths to the files or folders, respectively, the value string data contain entries that look like, "[T01CD76253F25ECD0]", which is a string representation of a 64-bit FILETIME time stamp.  As such, these keys aren't MRU keys in the more traditional sense of having an MRUList or MRUListEx value.

Tools: RegRipper office2010.pl plugin

TrustRecords
A while back, Andrew Case pointed out this interesting artifact.  When an MS Office document is downloaded or accessed from the network, there's a yellow bar that appears at the top of the application window, just below the menu bar.  Most often, this bar contains a button, which the user must click in order to enable editing of the document.  Within the TrustRecords key, the value names are the paths and names of the files accessed, and the first 8 bytes of the binary data appears to correlate to the time when the user clicked the "Enable Editing" button.

Tools: RegRipper trustrecords.pl plugin

Application-specific MRUs
A number of file viewers (Adobe Reader, MS Paint, etc.) maintain their own MRU lists.  Most often when interacting with the application, if you click on File in the menu bar of the app, the drop-down menu will contain (usually toward the bottom) a list of recently accessed files.  Many times, that information can be found in the Registry.

Tools:  RegRipper applets.pl and adoberdr.pl plugins

On Windows 8, the Photos key in the user's USRCLASS.DAT hive is used to track photos opened via the Photos app on the Windows 8 desktop (many thanks to Jason Hale for sharing his research on this topic).

Tools: RegRipper photos.pl plugin

ShellBags
Ah, there they are again!  Shellbags...can shellbags artifacts be used to help determine files that a user may have accessed?  Yes, they can.  On Windows XP, correlating the shellbags artifacts includes mapping the NodeSlot value in the BagMRU key to the Bags keys, where in some cases you may find what amounts to a directory listing of files; this does not appear to be the case on Windows 7.  However, the shellbags artifacts can illustrate directories that the user accessed, both locally and on network resources, and can therefore provide some information regarding files that the user may have accessed.

In addition to folders on local and removable drives, shellbags artifacts can also illustrate access to mapped network drives, Internet resources (i.e., accessing FTP sites via Windows Explorer), as well as to zipped archives.  Most of us don't usually think twice when we click on a zipped archive and it opens up just like a regular folder, in an Explorer window...however, it is important to note that this does appear as a shellbag artifact.

Tools: RegRipper shellbags.pl plugin

TypedPaths
Similar to the shellbags artifacts, the TypedPaths key in the user's NTUSER.DAT hive maintains a list of folders that the user accessed; however, for this artifact, the paths were typed into the Windows Explorer Address Bar.

Users can also disable this feature, so if you find no values in the TypedPaths key, check for the AutoSuggest value.

Tools: RegRipper typedpaths.pl plugin

Searches
With Windows XP, user search terms were maintained in the ACMru key; on Windows 7, they're found in the WordWheelQuery key.  These values can provide information regarding what the user was looking for, and provide some indications of files they may have accessed (often determined through timeline analysis).

Tools: RegRipper acrmu.pl and wordwheelquery.pl plugins

A good deal of the information that provides indications of a user's access to files has time stamps associated with it, and as such, can be included in a timeline.  This timeline can provide context and granularity to your analysis, particularly when correlated with other artifacts.