Update: Thanks to everyone for the feedback. I'm glad the info is useful and interesting - mission complete here. For everyone who asked about the full article, it's now available on Forensic Focus.
Dropbox is a web-based file synchronization and sharing service. While it can be a backup of sorts, it's really geared toward accessing files from multiple systems that are on the same account. I've used it myself, as it makes it easy to access files from multiple systems without having to resort to thumb drives and so on.
I'd wondered for some time about these types of cloud services from a forensic standpoint (security is a different issue, and that's not what I'm focused on here). Then I found that when a file is deleted from Dropbox - whether locally or online — it does not actually get deleted from the account. It disappears, but it's still recoverable, and we don't even need to carve for it! What?! Yeah, so I sketched out my research project (solely on Windows ®), and finished up a half-year later. This post is a brief summary of the full article.
File Deletion
As forensicators, we know that when files are deleted on a system they're not really gone. There are recycle bins, various tables that contain file data/metadata, and so on. There's always file carving. Dropbox changes this scenario just a little bit, even if files are wiped on the local system.
Within the web portal, you can access deleted files and folders for that directory by selecting the "Show deleted files" button at the top. The button is only available if such files exist. Free accounts have a 30-day time limit, paid accounts are unlimited.
Once a deleted file/folder is selected (note that size is shown as "deleted"), the "More" menu option can be accessed to permanently delete, undelete the data, or access previous versions (this last feature is also available for active files). See next two screenshots. As seen on the left, the deleted file (or folder) is a lighter shade, grayed out. However, it can still be accessed and even downloaded or opened in its native application.
So that's enough of the portal for now. Let's move on to the local system.
Installation and Local Files
Installing Dropbox makes all sorts of changes to the Registry, which are discussed in more detail in my full article. Naturally there are installation paths and uninstall entries. The interesting (low-hanging fruit) thing is the installation directory. It's not in Program Files, but instead is under the user profile. On Windows® XP, it is under ?Documents and Settings/username/Application Data/Dropbox,' and on Win7 it falls under ?Users/username/AppData/Roaming/Dropbox.'
There are a few directories within this, such as "bin," "shellext," and "installer." Older versions also had a "cache" folder but that has changed with newer versions and will be discussed shortly. The juicy stuff here are the multiple database files. These not only have the core configuration for the account, but also a listing of all files and folders managed by Dropbox. Kids, can you say, "forensic goodness?" (No, I'm not referring to baby goats!)
The "config.db" file contains the configuration for the account (well sure, the name says it all). This SQLite file contains the email address associated with the account, the "host_id" and local path information. Derek Newton has a great writeup about security considerations with the config file on his blog.
The veritable motherlode, in my opinion, is "filecache.db," with several tables, I think the "file_journal" one is the most interesting, as it contains a list of all the folders and files on the account. This is also a SQLite file, and past experience makes me think that even if you've deleted files, for at least a time (until the database needs the space), those records will still exist, although they may not be readily viewable. I know deleted text messages can be parsed from the "SMS.db" file on an iPhone, so why not here, too?
When a Dropbox account is created and the application installed/set up locally, the default location for user files is a "My Dropbox" folder inside the user's "My Documents" directory. This can be changed, as can the items to be synchronized. However, just going with the defaults, there's an item of interest, and that's the ".dropbox.cache" folder (inside "My Dropbox").
This directory is hidden, and appears to be the current version of what used to be the "cache" folder in the installation directory. So how is this useful? If there are multiple systems associated with the account (which is really kind of the point, I think) and a file is created or edited on one system, the other systems have a cached version of that file. Within ".dropbox.cache" there are subdirectories named by date, and those contain files from those. Each of these files shows as deleted (based on parenthetical addition to the name), but can still be opened in the native application. A couple screenshots follow to give a visual.
You'll notice that there are multiple versions of the same file, with a different ID appended to the name. These don't appear to be created automatically (based on time interval), but do show up each time the file is saved while open. Do you see that "entries.log" file at the bottom? That's also interesting. Each of the dated directories contains one of these, and it appears to be a list of every file in that folder, pipe-delimited format, in some encoded fashion. See below...
Network Activity
I mention network activity because obviously connectivity is a part of this service and just as obviously, artifacts will be created by the same. So what are they? Here's a quick snapshot:
I think it's important to note that none of these reference Dropbox so any search terms on that might not result in anything for the network. One connection is not encrypted, and I've blanked that IP just for paranoia purposes. I do not know if any of these connections change based on location.
Uninstall or Unlink System
There are three different ways to remove a computer from Dropbox. You can uninstall the application, unlink it through the local application, or unlink it through the web portal. As it turns out, uninstalling or unlinking locally do not actually remove the host from the account, only from synchronization. That has security implications as noted in Derek's blog. But the main forensic question is about what's left behind as artifacts.
When Dropbox is uninstalled, it removes the database files but keeps the rest of the installation directory intact. The user files are still present and accessible, but the top-level directory changes from "My Dropbox" to "Dropbox," and the icon is gone. If this directory is blown out, you might be left with little, other than evidence the service had been installed and used (registry, internet history). It should be noted that this does not actually remove the host from the account; it is still listed online.
If it's unlinked locally (through the application running in the systray), it's very similar to the uninstall. The user directory name changes to "Dropbox" but the icon remains. The application is still installed and will prompt to set up a local account if launched. The "config.db" remains behind, and can be used to maintain the prior settings (see also Derek's blog). This method also does not remove the host from the account, and it is still listed online.
If the unlinking occurs online, it is very similar to the local way. User directory is exactly the same as with the local unlinking. The application is still installed, and will launch the same way as above. However, all of the database file remain behind, intact and viewable. This method, however, will remove the host from the account; it is no longer listed online.
All three methods do leave the user file directory intact, including the cache folder. This would indicate to the examiner that at least one other system was at some point (based on the directory date-names) associated with the account. If the configuration database remains, then (even if the host is no longer linked), you at least have an associated email address to use in the investigation.
Wrap Up
This short overview is starting to get kind of long, so I'm going to wrap it up. I think the important thing to take away from this is that there are a lot of local artifacts from using Dropbox. In general, I'm quite sure that these types of cloud-based services will create such artifacts that are useful to the forensicator. There is a lot more research that can be done in this area, and I think it is incumbent upon us — as the cloud is used more and more — to identify those and share with the community.
I hope you enjoy this and find it useful. When my full article is posted (it's just too big for a blog post), I will endeavor to let everyone know. In the meantime, if you want a copy let me know.
Happy forensicating!
