SANS Digital Forensics and Incident Response Blog

Digital Forensics: Dropbox

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: http://www.forensicfocus.com/dropbox-forensics

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.

Show Deleted Files

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.

Deleted File EntryMore Menu Options

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!)

Installation Directory

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: http://dereknewton.com/2011/04/dropbox-authentication-static-host-ids/

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?

filecache.db

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.

Cached Items.dropbox.cache folder

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...

entries.log file

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:

Network Connections

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!

17 Comments

Posted June 17, 2011 at 10:08 PM | Permalink | Reply

Sandra

Great Article

Posted June 18, 2011 at 4:35 AM | Permalink | Reply

Frank McClain

Thanks, Sandra! Glad you liked it.

Posted June 18, 2011 at 7:09 AM | Permalink | Reply

b

glad i read this. i had questions about its artifacts.

Posted June 18, 2011 at 2:11 PM | Permalink | Reply

Ken Pryor

Excellent post, Frank! I look forward to reading the full article. This type of research is really important and you definitely taught me a thing or twelve.
KP

Posted June 18, 2011 at 2:27 PM | Permalink | Reply

Adam

Hi,
Interesting article. Would it be possible to get a copy of the full thing?
Thanks,

Posted June 18, 2011 at 9:35 PM | Permalink | Reply

Keith Cottenden

Great article Frank, any chance of the full article?

Posted June 20, 2011 at 2:32 PM | Permalink | Reply

Almar

Nice article. Like to read the full article. When is it for download availble?

Posted June 20, 2011 at 2:32 PM | Permalink | Reply

Almar

Nice article. Like to read the full article. When is it for download available?

Posted June 20, 2011 at 7:58 PM | Permalink | Reply

James

Great article! I have been working with Dropbox as well, and I'm glad to see that research is being conducted. Is it possible to get a copy of the full article?
Thanks!

Posted June 20, 2011 at 9:22 PM | Permalink | Reply

Ronald

we need this kind of articles and people who do r

Posted June 21, 2011 at 10:25 AM | Permalink | Reply

Tobias

Great post, looking forward to the complete article.
Cheers, Tobias

Posted June 22, 2011 at 5:03 PM | Permalink | Reply

Johnathan B.

Dropbox Reader is a collection of free command-line Python scripts for reading evidence files associated with the Dropbox cloud storage software. These tools can run on Windows, Macintosh, and Linux systems. With Dropbox Reader, you can acquire information about the registered Dropbox account, shared directories, and synchronized files. Here's the link to the free download link:
http://www.cybermarshal.com/index.php/cyber-marshal-utilities/dropbox-reader

Posted June 23, 2011 at 9:21 PM | Permalink | Reply

Mark

Good Post tanks

Posted June 24, 2011 at 7:42 AM | Permalink | Reply

Martin M

We just released our paper on Cloud storage security which we will present at USENIX Security 2011 in August, with a detailed analysis of Dropbox in particular. You can find the paper at http://sba-research.org
Have fun, Martin

Posted June 24, 2011 at 1:27 PM | Permalink | Reply

Frank McClain

Martin,
I saw that paper this week, very well done! Lots of great research accomplished. I hope your USENIX presentation goes well.

Posted August 27, 2011 at 1:31 AM | Permalink | Reply

Subir Volumen Muscular

Great website. We just released our paper on Cloud storage security which we will present at USENIX Security 2011 in August, with a detailed analysis of Dropbox in particular. Good Work.