As you may know, we have recently updated Elcomsoft Cloud Explorer, bumping the version number from 1.30 to 1.31. A very minor update? A bunch of unnamed bug fixes and performance improvements? Not really. Under the hood, the new release has major changes that will greatly affect usage experience. What exactly has changed and why, and what are the forensic implications of these changes? Bear with us to find out.

Elcomsoft Cloud Explorer 1.31 has one big change compared to the version it replaces. The new build comes with a brand new Google authentication engine. Unlike prior versions of Cloud Explorer that used to authenticate as a Web browser, the new authentication engine makes use of phone-based communication protocols. This much-needed change has multiple positive and not-so-positive implications.

Why the New Engine?

Why did we need to change the authentication engine in the first place? Wasn’t the old one perfectly working? It was until a few days ago. Since Web-based access to the data stored in the Google account is neither official nor documented, Google can (and does) make changes to the protocol as it pleases. Every little change that they make may (and will) break Elcomsoft Cloud Explorer, requiring another research and a rushed update.

In fact, this exact thing had happened just a few days ago. A small alteration of one of the protocols used by Google has instantly rendered Elcomsoft Cloud Explorer unusable.

By the time this happened, we’ve already developed a new, phone-based authentication engine. We scheduled it for a major update, and would introduce it with the next major release of ECX in a few weeks. The newly developed engine is more robust and significantly more future-proof compared to the browser-based implementation we used in previous builds.

Instead of ECX 1.40, we chose to introduce the new engine today. With this minor update, you receive the completely revamped authentication and downloading engine, the ability to store authentication credentials and automated token-based subsequent logins.

As good as it is, the new engine is still a major change. It will affect your usage experience, and it does have some new forensic implications compared to the old browser-based engine. From now on, the following applies.

1. We now make use of authentication tokens to cache authentication credentials. Instead of storing sensitive information (login, password and one-time 2FA codes), we create a small file containing an authentication token. The token can be used to authenticate into the same Google Account without having to re-enter the password or 2FA codes. The token does not contain the password, not even a hash, and cannot be used to recover the original account password.
2. If you select Dashboard data for extraction, you will receive an extra two-factor authentication code (if 2FA is enabled for a given account). You will have to enter that second code into Elcomsoft Cloud Explorer. This is in addition to the “normal” two-factor authentication process.
3. Google Dashboard data will not be accessible for token-based sign-ins when using cached credentials.

Forensic Implications

When using one of the previous versions of Elcomsoft Cloud Explorer, you could count on being mostly invisible to the owner of the account once you went past initial authentication steps. Since ECX has undergone some major changes, Google will treat it as a “new device”, and may notify the user with an email.

While the new build does not trigger any more notifications compared to previous releases, we still decided to outline the conditions in which the user may receive an alert.

Officially, Google sends an email notification if any of the following conditions is met:

• The user signs in for the first time on a new computer, phone or browser
• The browser’s incognito or private browsing mode is used
• The user clears the cookies on their computer
• The user connects through a VPN not previously used
• When another person is accessing the user’s account

In our internal test, we noticed some factors that may or may not trigger the notification. We found that a notification email may be sent if any of the following conditions is met:

• You sign in to the user’s Google Account using Elcomsoft Cloud Explorer using the login and password
• You log in from a distant region (e.g. logging in to a US or European account from Middle East, or vice versa)
• You sign in using a version of Elcomsoft Cloud Explorer with a revised “user-agent” field (as is the case in this release)

Let’s have a closer look at the last condition.

The new authentication mechanism used in Elcomsoft Cloud Explorer 1.31 makes use of the same authentication scheme as Android smartphones. Because of this, account owner will be alerted by email every time Elcomsoft Cloud Explorer signs in to their Google Account with login and password. Subsequent sessions authenticated with a token will not trigger this notification.

Technically speaking, Android devices use the following user-agent: “Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MPA44I; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/57.0.2987.132 Mobile Safari/537.36 MinuteMaid”.

Elcomsoft Cloud Explorer 1.30 and earlier were using a wide range of strings to form the correct user-agent for accessing the different types of data. Just to give you an idea, we used to use all of these:

1. For authenticating into Google Account and accessing Chrome data we used the following user-agent: “User-Agent: Chrome WIN 40.0.2183.0 (679d31a211c8844eda3ec6b51efadb54e8fe1d0b-refs/heads/master@{#298759})-devel”
2. Accessing Dashboard and Hangouts data required a different one: “User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36»
3. Accessing Wi-Fi access points and Calls utilized yet another user-agent: “User-Agent: GoogleAuth/1.4 (sailfish NOF26V) и  GoogleAuth/1.4 (hammerhead MPZ79M)”
4. Places and Routes for Locations was again using something else: “User-Agent: Dalvik/2.1.0 (Linux; U; Android 6.0; Nexus 5 Build/MPA44I”

Looks bizarre and prone to failures? It really was. A change implemented by Google to any one of the many protocols we used to access the data could break Elcomsoft Cloud Explorer. So we stopped using this, and unified all requests under a single new user-agent:

User-Agent: Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Of course, this is only part of what we did. The actual requests have been migrated to originate from the new “device” platform as opposed to be originated from the “Web browser” platform. As a result, we achieved significantly higher reliability. However, the new user-agent led to some new forensic implications.

As Elcomsoft Cloud Explorer 1.31 makes use of the new user-agent string, account owners will receive a notification email when you log in to their Google Account for the first time after updating Elcomsoft Cloud Explorer to the last build. We don’t know if this user-agent will persist in future releases; however, we will put the corresponding release note if we ever need to modify it in the future.

Conclusion

The new authentication engine is here to stay. Being significantly more robust, the new mechanism is more future-proof compared to the old browser-based engine. We can do more with it, too. In future versions of Elcomsoft Cloud Explorer you will see even more data, including new categories that may appear in Android O.