A bit about bytes…
December 18, 2013Posted by on
This is a continuation of my last post, Dropbox – NTFS Journal Artifacts. In this post, I will go over the second and third test done on the research project for my class. This will involve using the installed application to upload and sync data to a Dropbox account, then the use of the web interface to upload files, which will also be synced to the computer into the Dropbox directory.
For this step in the project, I merely copied files into the Dropbox directory used to sync with the account. In this case, it was the default directory. Here are the file stats for this step. Which I am showing, mostly to get an over view to the large amount of activity that is taking place behind the scenes, this would vary depending on the files to be synced.
- Uploaded 18 items
- 3 Folders
- 15 Files
- 3 – mp3
- 8 – jpg
- 1 – wmv
- 3 – ini
- 738 Transactions from copying the files to final sync
- Database Files accessed (390 times)
- sigstore.dbx (172)
- filecache.dbx (121)
- aggregation.dbx (37)
- config.dbx (40)
- photo.dbx (20)
Copy & Paste
The test files I used for this step were the Sample Music/Pictures/Video files and folders that come with a clean installation of Windows 7. I added the Sample folders to another folder called “Test 2 – Upload via app”, then copy and pasted the Test 2 folder to the Dropbox directory. Here is the result:
Again, I have this condensed to only the “File_Create” actions. There are important things to note here. The first one, as mentioned at the end of the first part of this series, we can see the files that are created in the Dropbox directory. This is great for investigators. Second, what we see here is that Dropbox did not begin syncing data until every file and folder completed copying into the directory. This can certainly use more testing, at the time of this project it was outside the scope. Initially what comes to mind is that if someone is stealing data via Dropbox, just seeing the files created in the sync folder, though can imply intent to steal does not prove any data was taken, unless we can look at the Filecache.dbx or we can see Dropbox activity immediately following the file creation(s).
I’ll show you what some of this activity looks like.
As you saw from the first image, after all the files were copied, then the Sync process started. Here is a snippet of the following few entries, I did not go further because it repeats this for about 70 more entries. Following access to the sigstore.dbx file, Dropbox then accesses its other database files multiple times, then goes right back to a long series of accesses to this sigstore.dbx.
There are multiple access to the “PENDING_bsiapi” temp file. Notice, this file has a similar name to the “PENDING_jqih7k” file from the earlier post. The file from the original post never changed while I was running tests. It is possible that these files are swapped out for new files periodically, possibly based on some event. This was not the case for only the PENDING* file, the same name change occurred with the UPDATED* file, as seen below. The name from the installation was “UPDATED_g4qacp”
Though there is a lot of Dropbox database access activity to see (below is another screenshot of more of the busy time), from the view point of the journal, there is no way to see what order the files were uploaded in. So without access to the filecache.dbx to verify, an investigator would not be able to confirm if all the files were uploaded (maybe! Keep reading). However, there is enough evidence here to say that file synchronization occurred between the computer and an active account relating to particular files. Depending on the type of case, that may be all that is needed.
Some interesting events occurred in the later part of the sync, “Stream_Change”. Though, of the four file types and the folders that were uploaded, only the .jpg files and the one .wmv file had this event. There was no such event for the .mp3 files, .ini files, nor the folders. It would be interesting to know what triggers the Stream_Change event.
Then finally, after the Stream_Change event to the Wildlife.wmv file, the synchronization completes.
Now for the Third step in the project. Using the Dropbox.com web interface to upload files to an account, then review what happens in the journal when the files are finally synced to a Windows 7 system. I found it interesting to see the differences in these two processes. So here are stats on this step of the project, then I’ll jump right in…
- Uploaded 12 Files
- 3 – mp3
- 8 – jpg
- 1 – wmv
- 186 Files Created
- 106 Files Deleted
- db(x) files accessed 349 times
- Over 900 transactions
Since in the journal, you can see each file that is created, you can see the temp files that are created during a web session. In this case, you can see access to “dropbox_com.htm” and “www.dropbox.xml”, as well as files related to a log in page. Through these actions, you can get an idea that an individual accessed their online Dropbox account at 22:06:06 UTC on October 13th. If they are still around, you could even search for the temp files to verify they are related to Dropbox.
In this image, I wanted to show more activity from this session. I have noted that the “gs.htm” file is the “Get Started” page accessed after I signed into Dropbox. You can see this from the webpage screen shot. Just adding some extra validity.
So, from this type of information alone, an investigator can gain knowledge of Dropbox access via a browser session. Just to mention, there is a lot more of this type of activity you can see in the actual journal, I’m just showing the good stuff.
After getting through the first parts of the website. I browsed to where I could begin to upload files to the account. Once there, the first action I took was to create a new folder in my account for the new set of files (They happened to also be a separate set of the Sample files from Windows 7). Once the folder was created via the website, you can see from the above image that Dropbox begins to communication with the computer, starting with the config database.
About a second later, you can see that the folder was created on the hard drive as well.
Since there is not a way, at this time, to upload folders via the Dropbox website (they must be created manually), I uploaded the files individually. First adding the MP3 files. Here is where the fun begins!
After the file completes the upload to the online account, there is a temp file (~8a62924b.tmp) that was created on the local machine. Followed by the renaming of the temp file to the name of the file that was uploaded, (Kalimba 3.mp3). There is this sequence of activity for each file that was synced in this manner. To note, there is again “Stream_Change” activity for the same files from the App Upload testing.
This is the pattern of activity I see for each Sync process.
- Web Sync will begin with accessing the databases on the hard drive, then create temp files to build the data, and finally rename the temp file to the actual file name.
- The App Upload will begin once all files & Folders are copied into the sync directory. Once sync begins, then the databases are accessed.
The NTFS journal is a great asset to forensic investigators. There is a plethora of data here to better understand.
It is great knowing there is this type of information available for Dropbox (probably other online storage services too). It can be a nice way to get around having to crack passwords. Obviously, this article strictly involves NTFS. There is likely a wealth of similar information for HFS+ as well, which David and Matt also have a journal parser available for.
I hope you enjoyed the write-up. Please leave me comments or email me. If you have some ideas you want to share or notice something I’ve overlooked, I’d be happy to hear from you!