Subtitle: Determining which application a file "belongs" to
Many times when I am browsing through online lists and forums, I see questions geared along this avenue; an analyst finds a file with a specific extension, and wants to know which application uses it or may have been used to modify that file. Most times, this is just a small part of a much larger question, and initial attempts to answer the question via Google searches may have led to additional confusion (specified application does not appear to be installed on the system, etc.). However, there are things that an analyst can do to answer that question using the data currently available, within the collected image.
File Extension Analysis
So you have a file that you're interested in, along with a path, name, and extension, and you want to know which application may have been used to create or modify that document. One way we can go about this is to use Registry analysis. Within the acquired image, locate the Software hive (usually in the path "\Windows\system32\config"), and within that hive, look to the Classes key. Many of the first subkeys that you'll see beneath this key are file extensions, such as ".3g2". The "(Default)" value of this key is "QuickTime.3g2", which indicates that this system will attempt to open a file with this extension using the QuickTime application. Additionally, the "OpenWithList" subkey includes a subkey named "QuickTimePlayer.exe". Locating the key "Classes\QuickTime.3g2", I saw that that key had a "shell\open\command" subkey with a "(Default)" value that pointed to QuickTimePlayer.exe (along with the complete path to that file).
As another example, beneath the "Classes\.aa" key, the "OpenWithList" subkey contains a subkey named "iTunes.exe", which indicates that the iTunes application will be used to open a file that ends in the ".aa" extension. Some extensions may have multiple subkeys beneath the "OpenWithList" key, which serves as an indicator to the type of file with which the extension is associated.
Other keys beneath the "Classes" key may have different information that may indicate how the file had been accessed or used on the system. On a system I was looking at, I found the ".rnk" extension, and the key only had a "(Default)" value with "rnkfile". I then located the "Classes\rnkfile" key, which had a "shell" subkey, with additional subkeys that referred to different commands. When I went to the command line on that system and typed "assoc rnkfile", the response was "rnkfile=Dial-Up Shortcut".
As this technique is based on Registry analysis, analysts need to keep in mind that it may often be unique to the system being analyzed, and findings on one system may not necessarily map directly to or represent those on another system. Also, these artifacts are based on file associations, which many times will be set when an application is installed, during the installation process. As such, when the application is uninstalled, those associations may be removed.
As this technique involves Registry analysis, there are other areas you can check, as well. For example, each user hive (XP) has a "Software\Classes" key within the NTUSER.DAT hive that may contain file associations specific to the user. On Vista and above systems, this information will be located in the root of the USRCLASS.DAT hive. You can also look to the RecentDocs key within the NTUSER.DAT hive to see which files the user has accessed, by extension. Also, if you suspect that someone may have purposely deleted any of the keys or values of interest, be sure to use regslack to check the unallocated space within the hive files for those artifacts.
If you have a file name (as opposed to just an extension) you might open up the user's hives in something like MiTeC's Windows Registry Recovery tool or the Registry Decoder from DFS, and search for the file name...you may find a reference in the application MRU listing.
Jump Lists
Jump Lists are artifacts that are new to Windows 7, and appear to contain most frequently used or most recently used (MFU/MRU) information with respect to applications and files. The *.automaticDestinations-ms Jump List files are created by the operating system, with only interact from the user being to open the file. However, testing indicates so far that Jump Lists created as a result of an application being used will persist after the application itself has been removed or uninstalled from a system. Therefore, an analyst with a specific file extension of interest should be sure to check the available Jump Lists (assuming that the image is from a Windows 7 system, of course) for indications of the extension or the complete file name. From there, the analyst can then map the AppID (first part of the Jump List name, before the '.') to the application, using the list on the ForensicsWiki, or on ForensicArtifacts.com.
Timeline Analysis
When presenting on timeline analysis, one of the benefits of this analysis technique that I try to get across is that it can provide context to what we're looking at; for example, creating a timeline from multiple data sources (including data from the user profile) may provide clear indications as to how a file with a specific extension was created or modified. Timelines very often include (if available) file system metadata, Prefetch file metadata, as well as time stamped data from a user's NTUSER.DAT, including (but not limited to) UserAssist data, RecentDocs data, etc. Through a timeline, you may find that a user opened an application, and shortly thereafter a Prefetch file was created or modified for that application, and then the file in question was created or modified. At this point, you'd not only know when the file was created, but using with application, and by which user.
VSCs
Volume Shadow Copies (VSCs) may provide some considerable information that may not be available via other sources. If an artifact does not persist when an application has been uninstalled from a system (such as may be the case with file extension associations), there may be historic remnants available in the VSCs (Vista, Windows 7).
Resources
Jump List Analysis (part 1, part 2, part 3)
No comments:
Post a Comment