File Tags and Digital Forensics

                So I was bored one day and decided that with school and work, I just wasn’t busy enough and I needed a new project.  I wanted to do some research, preferably in the realm of digital forensics.  I started talking to my buddy Rob Marmo (@robmarmo) and the idea of looking how Windows utilizes the tag properties within certain files came up.  Eventually, after some thought and consideration we decided that it would make for an extremely fun project that would make for a great booster for our experience.  As it ends up it was a great learning experience in doing research and developing a way to utilize the information.

Background

                If you are not familiar, Windows introduced the ability to “tag” files in Windows Vista.  This feature allows the user to add a desired keyword to certain file types so they could easily be categorized and searched within the Search function they included within Vista as well.  Here is an example of how you can tag your files:

Your other option for tagging your file is via the file properties option for the file.  If the file format supports tagging you will see the option available within the “Details” tab, like so: 

These file tags are a great way to organize information in a user customized way.  To me, that is why file tags are quite interesting from a forensic point of view, as these tags are inputted manually via the user’s input.  So it’s quite possible to say that if a file is tagged with a certain keyword it may provide that file with an added value of interest to an investigation.

How It Works

                After a lot of looking and failed avenues, I was finally able to get a handle on how Windows implements the ability to File Tag.  First, you may have noticed that I said only certain file types can be tagged.  I don’t deliberately state the files that are tagged because it is a variable.  When you begin the tagging process, simply put, the tags are inserted into an XML that is then inserted into the file.  How this is handled varies on the file type.  This determination is handled by reading the registry.  If you look at HKEY_CLASSES_ROOT\SystemFileAssociations in the registry, you will find a list of various file types registered within the operating system.  Each file type has two keys of interest for our purposes the “FullDetails” and the “PreviewDetails”.  Within these keys are several values, and the one for file tags is “System.Keywords”.  This value says there is a way for Windows to store the tags within the file.  The actual injection of the XML is done via a property handler that is based on the file type, often done via a DLL. 

            There is another part the file tagging system, beyond simply adding the keywords to a file.  As you recall, I mention that this implementation was intended to allow for quick searching of files by these keywords via the Windows Search function.  This plays an interesting point with the file tagging system.  As you enter in these keywords this creates an interaction with the Windows Search Index.  I created a quick animation GIF to show how the Search Index works as I understand it:

As you can see, the search index works with a data store.  Those data stores work with the Search function and filters, as well as a notification system.  If certain parameters are met they are then gathered and sent to the System Index, which is actually a database locally stored on the system at: 

C:\ProgramData\Microsoft\Search\Data\Application\Windows\Windows.edb *

*It should be noted that this  location can be altered via the Index Options in the Advanced options.

This is a interesting database and seems to be proprietary to the Microsoft Operating System and is utilized by a few of their applications.  If you’re interested in taking a look at the database, I was able to by doing the following:

• Turn off Windows Search Service (This essentially unlocks the DB so you can use it)
• Navigate to the Index location
• Make a copy of the index EDB file
• You can turn back on Windows Search Service
• Download and install an EDB Viewer (I suggest EseDB Viewer from Woanware)
• Open your copied EDB file in the viewer

Viewing the Search Index provides an interesting look at all the information that your Windows systems can analyze in a short amount of time.  As best as I can tell the Search Index database is utilized by the tagging system for the preview generation.  While you’re inputting a tag, often time you will find that upon entry once you type in a letter you will be given option of tags.  These are tags that have previously been applied to files, and from what I can tell these are pulled from the Search Index database.  The “PreviewDetail” key discussed earlier is how the registry knows you can get these tags via preview and then the property handler works with the index. 

Interest in Recovery

                Again, each file type handles tag in a different way; it is dependent upon the property handler assigned to it.  How these handlers deal with the data and inject it into the files is different, and through my testing of various files types and how they dealt with the file tags I came across an interesting discovery.  Some of file types store tag data not only within the file XML but also in various parts throughout the file.  In testing I was able to see when tags were added or modified, and even if the file tags have been deleted (or not viewable by the OS as Windows will only read tags from the XML), they are still located within the file and viewable within the hex.  Now, this only occurs in certain file types with, dare I say, inefficient property handlers.  Looking at the new Office formats like .docx it handles XML with a higher proficiency it writes most all its properties to XML and then archives it and then is read via Word or whatever.  To me that makes for much more efficient way to deal with files.  However, when we look at something like a .jpeg, it writes the tags to the file in different locations based upon the interaction.  Forensically, this provides an investigator with an added way to look at a file.  My thought was if you have a file that has a MAC timestamp of all the same times exactly, but you see that within the file that it has indications that tags were added or modified it may indicate that the file timestamps may have been altered.

Future

                I am still in the research phase with this information, but this is everything I have gathered thus far.  I have developed a proof of concept application that is working and pulling files that have been tagged and readable by the OS.  It’s still in development, and I plan and getting it out to the community eventually once I have it optimized and have added all the features I wish to include.  Also, you may be wondering how I came to acquire this information, so I am planning on posting a research and implementation article as well that will describe the research I did in a fair amount of detail with pertinent examples and such.  It may also include how I learned to program the tool I am developing as well.  I think explaining the thought process behind research and development may be beneficial to the community and hopefully inspire others to do the same by providing some background and basic thought process.

Hope you enjoyed this, and if you have any thoughts on the implications of file tags and how they can be utilized in an investigation I would love to hear them.  Leave a comment or e-mail me at:  michael.ahrendt@gmail.com