Hello my dear DFIR community. First of all, I would like to thank Ryan Benson (creator of the super useful tool unfUrl, I am sure you all know who he is but in case you don’t, check out his blog here: https://dfir.blog/) for his kind words on this blog. It means a lot to me. Also, I want to give a big shout out to those who use the “contact us” page to share with me their ideas and provide feedback. It feels so good to be a part of this supporting and motivating community. You are all so cool!
This blog, is a side project that I have so much fun working on. However, work is getting crazier and crazier these days (I suspect that you know what I mean?!) and I cannot tell for how long will I have the ability to keep up publishing a post per week. I have many research topics in mind (some thanks to you) and I promise you the best of them are yet to come. Some of them require more research than a week, while others require hardware which I am currently lacking. I will try my best to keep up the pace, but in case I do not, I want you to know that I am working in the background. Enough chit-chat, let’s get to work.
In my last post, we saw how tricky Google Chrome’s “Login” feature can be. It can lead us to false assumptions while trying to answer the question “Has the user logged into this account, or not?”. “Login Data” database is an ambiguous witness, who we must choose carefully when to trust. Today, we shall speak for a more co-operative witness, named “Web Data” database. But before getting into it, let’s see how we ended up there.
This week (as promised), we will investigate what happens when a user tries to log in to the Google Chrome browser (Sync with her Google Account). Therefore, in this research we will solely focus on answering the question “Has the user logged into this Google account, or not?”
When you launch Google Chrome, you will notice a profile icon next to the address bar (See below Image 1). By clicking on the profile icon and the “Turn on sync…” option, you can log in to the Chrome browser and allow synchronization to take place between the data related to your Google account (that is stored in the cloud) and the data related to the local installation of Google Chrome. There is another way to log in to the Chrome browser, but we will skip it for now.
As always, we will first take a look at our setup, then our scenario and last but not least, our findings.
All of my tests were run on a VM with Window 10. As far as the software I used, it is listed here:
- VM OS: Microsoft Windows 10 Enterprise Evaluation 10.0.17763 N/A Build 17763.
- VM Software: I used Virtual Box 6.1.14.
- I powered up the VM and then installed Google Chrome (Version 85.0.4183.121 (Official Build) (64-bit)).
- After installing Google Chrome, I performed a serious of actions (Described in the Scenario section).
- I then used DB Browser for SQLite (version 3.12.0) to view the contents of Chrome’s “Login Data” & “Web Data” databases and Notepad++ v7.8.9 for the rest of the files.
During this research, I tried:
- To log in successfully into my Google account using the Chrome browser’s “Turn on Sync” function.
- To log in successfully into my Google account via visiting the Google Account authentication webpage.
- To log in to multiple Google accounts (3) and use them alternatively for browsing.
- To log in unsuccessfully into Google accounts.
- To sign out from one or more Google accounts.
- A variation of the above.
Let’s see what did we find.
I started this research by trying to unsuccessfully log in to a Google Account via visiting Google Authentication webpage (https://accounts.google.com). Unlike my previous research, in the latest update of Google Chrome it seems that the “Login” Message-Box (see previous post) is no longer triggered when you put invalid credentials, no mater how hard you try (more good news for us). So when I tried again and successfully logon to the account, our favorite Message-Box appeared. I chose “Never” should Chrome remember the creds. After that, I immediately closed Google Chrome and anticipated that when I re-launch it, I would have to re-authenticate myself. Well, guess what? When I launched Chrome again, I was connected to Chrome browser with my Google Account (wait what?). Apparently, this is the second way to log in to the Chrome browser. I dived into “Login Data” database to check what was happening and validated that in the “logins” table, the follow entry was created:
So everything seemed to be where it supposed to be. This meant that there is another artifact somewhere, that can help us determine that a user has logged into their Google Account. This also means, that if a forensicator examines “Login Data” database only, then he might lose some important artifacts related to a potential logged in user’s account. The artifact that holds information related to the account that has logged in the Google Account-Chrome browser, is named “Web Data” database. Among the tables inside “Web Data” database, there is one of particular interest; the “token_service” table. This is the entry that was created after my Google Account-Chrome browser logon:
As you may see, the service column is populated by the user’s Account ID and the encrypted_token field with the user’s authentication token. Excellent! When you try to determine that a user has logged in to a Google Account, make sure you also check “Web Data” database as well. Ok, nothing really new so far but is this all there is there? What about the date and time that the user logged in to the Chrome browser and as consequence to the Google Account (or vice versa)? By merely looking at this table or database, we cannot answer that question. But we are able to answer this question if we dig around the “Default” directory of Google Chrome (C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default) and locate our next artifact, a file named “Preferences“. Before talking about this next artifact, I need to outline the following key-points to remember (those all came up after experimenting with the above-mentioned scenario steps):
- If someone’s logs in successfully to her Google Account via the Google Authentication webpage, then Chrome automatically logs her in the Chrome browser as well (no matter what she chose in the Message-Box). When this happens, by default “sync” option is off for the logged in user. The same holds true, if the user first logs in to the Chrome browser (“Sync now” option). She gets automatically logged in her Google account as well. The only difference here, is that the user gets to choose whether or not she wants synchronization to take place (see below Images 4 and 5):
She can choose to sync everything or be more selective with what to sync, or even opt out sync at all. However synchronization is out of scope for this research, so we will stop here with that.
- When the user signs out from her Google Account (either signing out from Chrome browser or while being in the google.com and by clicking on her icon and then choose “Sign out” option) the Google account’s corresponding entry inside the token_service table, gets deleted. So if you find no entries in the token_service table, it is an indication that the user might has signed out from her Google Account (or Accounts).
Now let’s take a closer look at the “Preferences” file.
When the user logs in with her account, a file named “Preferences” under the “Default” directory, gets populated with her account’s details (the file is already there but holds more generic information before logging with a Google Account). This file is a JSON format file that stores a bunch of information about the Chrome usage and more particularly about the logged in user. Let’s see what forensic value can be extracted from this file. Take a look at its content:
As you can see, someone can easily correlate the Google Account’s ID from the table “token_service” in the “Web Data” database with the keys “account id/gaia” and their corresponding values. This way you can concentrate almost all the necessary information about the logged in Google Account. However we have not figured out yet how we can answer the questions “When did the user last logged in to the Chrome browser and as consequence to the Google Account (or vice versa)?” and “When was the last time the logged in user used Chrome browser?”. If we dig deeper in the “Preferences” file, we will find many timestamps. Only one of them can help us answer the first of the questions. Also, forensically speaking, there is another one, which we can use to answer the second question. These are the keys you should look for:
| Key | Value |
|---|---|
| last_signin | This timestamp (is in epoch time) stores the last date and time that a user logged in the Chrome Browser. Super useful artifact. |
| last_synced_time | This timestamp (is in Chrome time) gets updated every time that a user launches the Chrome Browser. |
In order to further investigate the above timestamps, I logged in with 3 different Google Accounts (used the “Add a different account” option) at the same time and checked how this “Preferences” file got affected. Bare in mind, that no matter how many accounts you are logged in with, only one can be logged in to the Chrome browser. But you can have a user logged in Chrome browser and another one using the Google services (see image 8 below). Well, as far as the results are concerned:
The good news:
- For every Google Account that I logged in, all the above-mentioned info (Image 6) was logged in the “Preferences” file. Also, in the “token_service” table a new entry was created for each of the accounts.
- For every Google Account that I logged in, a separate “last_signin” was logged in the “Preferences” file. Each one corresponding to the timestamp that I logged in to each account. So we can determine exactly when each user logged in.
The bad news:
- The bad news are that the “last_synced_time” exists only once in the “Preferences” file, no matter how many accounts you are logged in with. This timestamp as we now know, gets updated the last date and time (up to the minute) that a user launches the Chrome Browser. This timestamp is also assigned to the logged in user in the Chrome browser. So we cannot safely determine when each user last used Google Chrome. We can only determine when Chrome was last launched.
To sum up this post, using the above-mentioned artifacts we are able to safely determine if and when a user has logged in to her Google Account. We can also determine when did that user last used (or more correctly launched Google Chrome). On the other hand, we cannot safely determine (in case of multiple logged in users) when each one of the logged in users last launched Google Chrome.
Till the next time, cheers and thank you all for your support!