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:

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.