Published Date : September 3, 2020 , atropos4n6
Artifacts, Cloud Forensics, Google Chrome, Google Drive, Mozilla Firefox, Windows 10
As promised, this is the second post about Google Drive. This time I will write down some of the artifacts that remain after using either Mozilla Firefox or Google Chrome to access and use Google Drive. Once again, those results came up after a research I 've made last year (2019) regarding cloud forensics (as part of my MSc Thesis). However, I did not have a blog back then, so now that I have, it feels like the best time to share. I want to thank Phill Moore for his great post on "HOW and WHY" you should try DFIR blogging, which gave me the motivation to begin my blogging journey (You can read the post here: https://thinkdfir.com/2018/07/28/should-i-start-a-blog-yes-the-answer-is-yes/ ). Well, as I did in the previous post, I will start with writing down the setup, scenario and tools I used and then we will see our findings.
Setup
My goal was to keep everything as clean as possible. The setup methodology I used was:
- I installed Windows 10 Pro 16299 on a brand new VM (Base-VM, using VMware Workstation 14).
- Created a couple of full-clones of the Base-VM.
- Installed Mozilla Firefox (version 65.0.2 (64-Bit)) on one clone and Google Chrome (version 72.0.3626.121 (Official Build) (64-bit)) on the other clone.
- Then I made an bunch of full-clones of the initial full-clones.
- I performed a series of actions.
- I acquired the virtual machine’s hard drive.
- I examined the images.
Next I shortly describe the scenario of the research.
Scenario
The scenario was pretty basic. I performed each and every of the following actions (wherever applicable):
- Download a file from user's cloud.
- Create a file at the user's cloud.
- Edit a file at the user's cloud.
- Delete a file from the user's cloud.
The scope of this research was to locate those artifacts that could prove that the above actions were made from the user. Of course, in both cases there will be similarities as browsers share almost the same kind of the artifacts (e.g. URLs). Nonetheless, lets see how that went.
Findings – Mozilla Firefox
As I expected, Mozilla Firefox's findings regarding Google Drive's usage, were less than Google Chrome's counterpart. It make sense as Google products are supposed to operate more smoothly together, right?
Downloading a file
Anyways, the first place to look for Mozilla Firefox's artifacts should be places.sqlite (located at C:\Users\<username\ AppData\Roaming\Mozilla\ Firefox\Profiles\XXXXXXXX.default\places.sqlite) and/or downloads.sqlite (depending on the version of Mozilla). I used Axiom (personal favorite tool) to find the files that the user(me) downloaded. Search for this information if you interesting in attributing the downloading files from Google Drive user's cloud:
| Field | Value |
|---|---|
| URL | URL must begin with "https://doc-0g-2s-docs.googleusercontent.com/docs/ securesc/...." and also must include "?e=download" (During my research I downloaded a document file and a presentation file and both had that URL. Not sure if it holds true for spreadsheets as well. Also, be advised that the above string will come up if you download a document/presentation file but not a Google Document. If a Google document is downloaded then the string "export?format=docx" will come up instead.) |
| Title | The filename of the downloaded file e.g. test.txt |
| Is Typed | No |
| Transition Type | TRANSITION_DOWNLOAD |
Editing a file
If we look at the same place (places.sqlite), we can also find artifacts with reference to editing a file. I accessed and edited both a document and a spreadsheet file, and this is the information you need to search for, if you are looking for something similar:
| Field | Value |
|---|---|
| URL | Editing a document: URL began with "https://docs.google.com/document/XXXFILE-IDXXXX/edit" Editing a spreadsheet: URL began with "https://docs.google.com/spreadsheets /XXXFILE-IDXXXX/edit" |
| Title | The filename of the file that is being edited e.g. test-Google (During my research I found that even if you choose to edit a file that is not a Google Document file, it will be automatically be converted to one) |
| Is Typed | No |
Creating a file
Once again the answer lies in places.sqlite. Lets see what we have here:
| Field | Value |
|---|---|
| URL | Creating a presentation: URL began with "https://docs.google.com/presentation/XXXFILE-IDXXXX/create" |
| Title | The filename of the file that is being edited e.g. test-Google |
Lastly, I did not find any artifacts that could safely attributed to the deletion of files from users' cloud. And now lets jump to Google Chrome's artifacts.
Findings – Google Chrome
Similarities with Mozilla Firefox
Google Chrome's main database is History. sqlite. Apart from that, as far as editing a file through the web browser, I found identical results (URLs) with Mozilla Firefox above. This also holds true, for the artifacts referring to both creating and downloading a file through these browsers.
Deleting a file
The most important finding during this research, was residing in Google Chrome's cache. It was a goldmine of information. AXIOM managed to parse those cache files and revealed the treasure for me.
So, If you are trying to determine that a Google Drive file was deleted through Google Chrome then extract any .json file that resides in Chrome's cache. More particularly search for these details:
| Field | Value |
|---|---|
| URL | Search for URLs that begin with "https://client6.google.com/appsactivity/ v1.1internal/activities?source=drive.google.com" |
| File Type | json |
Inside the .json file there was wealth of information. Here's a short view of its content:
As you can see, not only did we find the username that deleted the file, but also we can find both the filename and deletion timestamp of the file itself. Applying the same methodology, I was able to retrieve another super important artifact. We can precisely determine if a particular file was shared with other users, being at the same time able to find their email addresses. To find this, search inside Chrome's cache for .json files that contain:
| Field | Value |
|---|---|
| URL | Search for URLs that begin with "https://client6.google.com/drive/ v2internal/files/XXSPECIFIC-FILE-IDXXX?permissions?" |
| File Type | json |
Permissions of the file look like this:
So cache is the best place to look for evidence of user's activities and files' permissions. Interesting enough, right?
Summary
As you may have already understand, the majority of the findings depend on which URL the user visited. To that extent, all browsers will leave the same artifacts (not just the above). Of course, they will leave them in different files and directories but you get the point.
Anyways, the extra value of this research was clearly cache files. Especially those "rich" cache files that are generated from Google Chrome. If you do cloud forensics, never underestimate the cache files. Those little diamonds can give you the evidence you really need the most.
We will continue our "days of the future past" posts, but not for long I promise. Up coming next will be Dropbox examination. Yeah!!
2 Replies to “Artifacts of Google Drive Usage on Windows 10 (Part 2)”
Hello! Many thanks for your these posts, really interesting. I have tried to see the deleted files in cache memory but I see nothing. Are you aware of any change?
Thanks and best regards
Thank you for your feedback. Unfortunately, I have not researched how these artifacts changed over the years, so I cannot tell for sure whether something has changed or not. What I would suggest however is using Nirsoft tools like ChromeCacheView against your browser’s cache memory. Then look for entries that include the google drive’s domain and evaluate any .js or other files you may find. This might help you locate any related artifacts.
Good luck!