Friday, August 08, 2008

File Associations

Now and again, I'll see posts in the lists asking questions about files based on the names and/or the extensions of the files. If the name is unique, sometimes an analyst can find out quite a bit about the file by doing a Google search. This should not be considered the be-all and end-all, however...too many folks have tottered down the wrong path based on what they've found in this manner.

[digression=momentary]I can't tell you how many times I've walked into an engagement where the other party's entire "analysis" consisted solely of performing a Google search![/digression]

So let's say that you find several files on a Windows system with a particular extension that you, as an examiner, don't recognize. Sure, many of us recognize ".doc" and ".txt", and right off-hand, we know what programs these files are associated with. In some cases, these programs (most often MSWord and Notepad, respectively) are used to create files with these extensions, and we know from experience that when we receive one of these files and double-click it, the operating system will automatically open the file using a specific application. How does Windows know how to do this?

This information is maintained in...wait for it...wait for it....that's right, the Registry!! Through normal usage on a system, a user might interact with these areas of the Registry through a context menu (specifically, "Open With..."), and an uber-user might actually use ftype and assoc at the command line. However, if you're only got an image of a system, how would you very quickly attempt to determine which application was associated with a particular file extension?

So, let's say that we want to determine the file association for the ".doc" extension. We can start on a live system by typing the following command:

C:\>assoc .doc

Okay, that's pretty straightforward. The same command works for PDFs, etc. In order to find out what application specifically is used to open the file when the user double-clicks it, we can use this command:

C:\>ftype AcroExch.Document
AcroExch.Document="C:\Program Files\Adobe\Reader 8.0\Reader\AcroRd32.exe" "%1"

Pretty neat, eh? Okay, great. So how do we find this in an image of a system? You can start by going to the following key:


Beneath this key, there are a LOT of subkeys, and most of the first ones that you will see are the file extensions. Scroll down to ".doc", and you'll see that the value named "(Default)" within the key contains the name that was saw above when we ran the "assoc" command. In some cases, the extensions won't have a great deal of information (subkeys and values) but in others (as with ".doc"), you'll see a number of entries. Now, using "Word.Document.8", keep scrolling down beneath the Classes key, all the way down until you find that name. Once you find the Registry key with that name, you then want to find the "shell\open\command" subkey, and within that subkey, the "(Default)" value. So, at this point, the full Registry path that we should be at is:


The "(Default)" value within this subkey will give you the path to and command line for the application used to open the files with the extension we started with.

Pretty cool stuff, eh?

Oh, and don't forget to check the NTUSER.DAT files, as well, for the same paths.

Addendum: I created a Software hive plugin for RegRipper, but it can take a while to run, so I'd recommend running it with rip.exe instead. Want to know the default web browser on the system? Check the entries for HTTP and HTTPS. Also, I created a RegRipper plugin for the FileExts key in the NTUSER.DAT file.


Anonymous said...

Very cool indeed!

Anonymous said...


I have been using the assoc and ftype commands for years, but generally for litigation support. However, we recently have been using them in incident response. The surprise for us was how quickly the two commands can demonstrate bad stuff going on. We dump the out puts to text files. Unusual file types stick out, as to the programs responsible for them.

Thanks again.