Hello Reader,

This summer, we encountered a fascinating incident that highlights a surprising gap in how some third-party services handle authentication. Brian Krebs later covered the underlying issue in his post “Crooks Bypassed Google’s Email Verification to Create Workspace Accounts, Access 3rd-Party Services,” but our investigation was already finished by then. Let’s dive in.

The Scenario

Imagine your company has a third-party service provider where employees can create their own accounts. This service also supports authentication through multiple identity providers—like Google, Apple, or Facebook—to make logging in easier.

However, there’s a catch: in some cases, the third-party service will treat an identity-provider-based login as if it were the same account an employee created manually—even if they never actually linked their account to that identity provider.

How this Exploit Worked

1. Manual Account Creation
   A user signs up for a third-party website using their company email address and even enables multi-factor authentication (MFA).

2. Multiple Identity Providers
   The third-party site allows users to log in via providers like Google. Ideally, this is meant for convenience instead of creating an account manually.

3. Domain Hijack
   A threat actor finds a loophole that lets them register the same email address on Google Workspace—even though the domain actually belongs to someone else. (See Krebs’s article for how they bypass Google’s verification.)

4. Unintended Access
   Once the attacker has set up that Google Workspace email, they sign in to the third-party service using Google. Because the service trusts Google’s authentication, it grants the attacker access to the real user’s account—MFA included.

Why This Shouldn’t Work

• Identity Provider Verification
  Google (or any identity provider) should confirm domain ownership before allowing someone to create email accounts for that domain. Attackers found a way around this requirement.

• Third-Party Account Linking
  The third-party service should recognize that the user’s existing account isn’t linked to Google. However, many services fail to confirm whether an account was created manually vs. through an identity provider, resulting in the user’s legitimate account being “taken over.”

Our Investigation

In the logs, we noticed a user’s account authenticating via Google—odd, since that user’s company uses Microsoft 365. After reaching out to Google, we learned that the domain had recently been set up on Google Workspace, which led to a small set of logs confirming a brand-new account. Initially, we thought the third-party website might have suffered a larger breach. Then Brian Krebs’s coverage explained exactly how attackers managed to bypass Google’s email verification, confirming our findings.

Things to look for

• If you’re investigating an incident and see a user “miraculously” authenticating—especially if it’s not a straightforward case of stolen tokens—check the identity providers the third-party service supports.

This case was a stark reminder that even well-known platforms can be manipulated if there’s a loophole in domain or email verification procedures.