Taking Over Millions of Accounts from Abandoned Startups

Taking Over Millions of Accounts from Abandoned Startups

Speakers: Dylan Ayrey

Conference: ShmooCon

YouTube: https://www.youtube.com/watch?v=yIutY_X2FcU

Overview

This talk, presented by Dylan Ayrey at ShmooCon, exposes a critical vulnerability in the widespread "Login with Google" OAuth implementation that allows attackers to take over millions of user accounts associated with defunct startups. Ayrey demonstrates how, by acquiring the expired domain of a failed company, an attacker can effectively impersonate former employees and gain unauthorized access to their accounts on various third-party services that relied on Google for authentication. The core issue stems from how service providers identify users through Google's OAuth claims, which prove insufficient when a domain changes ownership.

The talk highlights the immense scale of this problem, revealing that over 116,000 startup domains are currently vulnerable to this takeover. This translates to an estimated 10 million user accounts that could be compromised, potentially exposing highly sensitive personal and financial data stored in systems like HR platforms. Despite reporting the issue to Google, the company initially classified it as "working as intended" and a "Fraud and Abuse" concern rather than a technical OAuth vulnerability, offering no concrete fix details even after a bug bounty payout. Ayrey's research underscores a significant security blind spot in how online services handle account identity and domain lifecycle, leaving a vast number of users and their data at risk.

Background

▶ Watch: Speaker intro and talk's premise on abandoned startups (0:00)

The foundation of this vulnerability lies in the ubiquitous "Login with Google" button, a common implementation of the OAuth 2.0 protocol. OAuth allows users to grant third-party applications (known as relying parties or service providers) limited access to their information on an identity provider (like Google) without sharing their primary credentials. Dylan Ayrey simplifies the OAuth flow into three key steps:

1. A service (e.g., Slack, ChatGPT) asks Google: "Who is this user?"
2. Google asks the user: "Hey, [Service] wants to know who you are. Is that okay?"
3. If the user approves, Google tells the service: "This is [User's Name/ID]."

From Google's perspective, when a user logs in with their Google account, it provides the service provider with a set of claims – pieces of information about the user. By default, two claims are commonly used by service providers to identify users and link them to existing accounts:

• The hd claim: This string represents the domain associated with the user's Google Workspace account (e.g., example.com). It's often used by services to allow all users from a specific company domain to join a workspace or organization.
• The email claim: This is the user's specific email address (e.g., [email protected]). Service providers typically use this to match against an existing user record and log them into their personal account.

The critical flaw emerges when a startup goes out of business. As Ayrey points out, a staggering 81% of startups fail, and many eventually let their domain registrations expire. If an attacker then acquires this expired domain and sets up a new Google Workspace under that domain, they can effectively recreate the environment that previously authenticated the startup's employees. When a former employee, whose account on a third-party service is still linked to their old corporate Google login, attempts to log in using "Login with Google," the service provider receives the hd and email claims from the attacker's newly controlled Google Workspace. Since these claims – the domain and the email address – match the records of the legitimate former employee, the service provider mistakenly grants access to the attacker.

Ayrey investigates a potential countermeasure: the sub claim. Google's documentation describes sub as a "unique identifier for the user account." In theory, if service providers were to verify this sub claim in addition to email and hd, they could distinguish between the original Google account and a new Google account created under the same domain by an attacker. However, Ayrey's research, corroborated by real-world data from a friend's company, revealed a significant problem: the sub claim is not stable. For one service provider, 0.4% of legitimate user logins in a given week showed a changed sub claim, even though the user's email and domain remained the same. This instability, affecting hundreds of users weekly for a moderately sized service, makes the sub claim unreliable for account linking, as implementing it would lead to widespread user lockout. This leaves service providers with no robust, Google-provided identifier to prevent such domain-takeover attacks.

Key Findings

▶ Watch: Fictional startup 'CatChat' dramatically shuts down (4:00)

Dylan Ayrey's research uncovered several alarming findings regarding the widespread vulnerability of accounts linked to defunct startups:

• Massive Scale of Vulnerability: Ayrey identified an astonishing 116,000 failed startups whose domains are currently available for purchase. This data was gathered by cross-referencing Crunchbase's free dataset of millions of startups with domain availability checks. To visualize this scale, Ayrey attempted to print all 116,000 domains into a single book, but Amazon's publishing limits meant he could only fit 10,000 domains in the largest possible volume, requiring 11.5 such books to list all vulnerable domains.
• Estimated 10 Million Vulnerable Accounts: Based on conservative estimates of 10 employees per startup and 10 third-party accounts per employee linked via "Login with Google," Ayrey calculates that over 10 million accounts are susceptible to this takeover method. This number represents a massive attack surface for sophisticated and unsophisticated attackers alike.
• Successful Proof of Concept (PoC): Ayrey demonstrated the attack's viability by purchasing a random domain from his list of failed startups. He successfully registered a new Google Workspace with this acquired domain. Subsequently, when attempting to "create account" on various SaaS (Software as a Service) platforms using "Login with Google," he was instead dropped directly into existing accounts belonging to former employees of the defunct startup. This confirmed the technical feasibility and immediate impact of the attack.
• Exposure of Highly Sensitive Data: The most critical finding from the PoC was the potential access to extremely sensitive personal and financial data. Ayrey reported successfully logging into HR systems that allowed him to view former employees' W2s, Social Security numbers, and bank routing numbers. This elevates the vulnerability from mere account takeover to potential identity theft and financial fraud.
• Google's Response and Lack of Fix: Despite presenting Google with comprehensive evidence and a bug report, Google initially closed the issue, stating it was "working as intended" and categorizing it as a "Fraud and Abuse" problem rather than a technical OAuth vulnerability. Although Google later reopened the issue and paid out a bug bounty of $1327, they provided no details about a planned fix or timeline, nor committed to implementing the stable identifiers Ayrey proposed. As of the talk, the issue remains unpatched, well beyond the standard 90-day disclosure window.
• Password Reset Vulnerability: Ayrey also briefly touched upon a related vulnerability: for accounts that don't use Google OAuth but rely on email-based password resets, an attacker controlling the domain can also initiate password resets and gain access to those accounts. However, this method has a potential mitigation: service providers can implement multi-factor authentication (MFA) or additional verification steps (e.g., SMS codes, last four digits of a credit card) during the password reset process. This "speed bump" is generally not feasible for OAuth logins due to user experience considerations.
• Uniqueness to Google (Mostly): While social logins like "Login with Facebook" or "Login with GitHub" exist, Ayrey believes this specific vulnerability is largely unique to Google. This is because other identity providers typically retain control over usernames and do not allow re-registration of old user handles, preventing an attacker from fully impersonating a former user in the same way they can with an entire domain under Google Workspace. However, he speculates that other providers offering domain-based identity services, such as Microsoft, might have similar issues.

Technical Deep Dive

▶ Watch: Hacker demonstrates account takeover via abandoned domain (6:00)

The technical heart of this vulnerability lies in the interplay between domain lifecycle management, Google Workspace, and the design of OAuth 2.0 ID tokens as implemented by Google. When a user authenticates with "Login with Google," the relying party (e.g., a SaaS application) receives an ID token from Google. This token is a JSON Web Token (JWT) containing various claims about the authenticated user.

The claims most relevant to this attack are:

• email: The user's primary email address (e.g., [email protected]).
• email_verified: A boolean indicating if the email address has been verified by Google.
• hd: The hosted domain of the user's Google Workspace account (e.g., example.com). This claim is present only for users in Google Workspace domains.
• sub: A unique, stable identifier for the user's Google account.

Service providers typically use the email claim as the primary identifier to link a Google login to an existing user account in their own database. For corporate environments, the hd claim is often used to automatically associate users with a specific organization or workspace within the service.

The attack proceeds as follows:

1. Domain Expiration: A startup fails, and its domain (e.g., catchat.com) eventually expires due to non-renewal.
2. Domain Acquisition: An attacker, like "Tony the Hacker Man" in the dramatic reenactment, monitors expired domains or uses tools to find domains listed in databases like Crunchbase that are now available for purchase. The attacker then registers the expired domain.
3. Google Workspace Setup: The attacker attempts to set up a new Google Workspace account for the newly acquired domain. Google requires verification of domain ownership (e.g., via DNS TXT records), which the attacker can easily provide since they now own the domain. Once verified, the attacker creates a new Google Workspace.
4. Account Impersonation: The attacker can then create user accounts within this new Google Workspace that match the email addresses of former employees (e.g., [email protected]). If the attacker has access to a list of former employees (which can sometimes be gleaned from public sources or even from the compromised HR systems themselves), they can systematically recreate these identities.
5. OAuth Login: When the attacker, using their newly created Google Workspace account ([email protected]), attempts to log into a third-party service (e.g., Slack, ChatGPT, an HR portal) that a former, legitimate Alice used to access with her original Google Workspace account, the following happens:

• The service initiates the OAuth flow, redirecting to Google.
• Google authenticates the attacker's [email protected] account.
• Google issues an ID token to the service provider. This token contains email: [email protected] and hd: catchat.com.
• The service provider, seeing [email protected] and catchat.com, matches these claims to the existing user record for the original Alice.
• The service provider then grants access to the attacker, believing them to be the legitimate Alice.

The crucial design flaw is that the email and hd claims, which are the most commonly used for linking accounts, are tied to the domain and email address string, not to a persistent, unique identifier of the specific Google account instance that originally owned that email/domain.

The sub claim was Google's attempt at providing such a unique identifier. However, Ayrey's findings demonstrate its practical unreliability. Google's documentation states it's stable, but real-world usage shows it can change for a small but significant percentage of users (0.4% weekly). This instability means that if a service provider were to rely on sub in addition to email/hd for account linking, a legitimate user might suddenly be unable to log in to their account if Google internally changes their sub identifier, even if their email and domain remain constant. This "user lockout" scenario makes the sub claim impractical for service providers to use as a strong, immutable identifier without causing severe user experience issues.

Ayrey argues that Google needs to introduce two new, truly stable identifiers: one unique identifier for the Google Workspace/domain itself, and another unique identifier for the user account within that specific workspace. These would persist across domain ownership changes or internal Google account migrations, allowing service providers to unequivocally distinguish between an original legitimate login and an attacker's attempt using a re-registered domain. Without such stable identifiers, the current OAuth implementation remains fundamentally vulnerable to this domain-takeover attack.

Demo / Proof of Concept

▶ Watch: Understanding OAuth: The core mechanism explained (6:30)

Dylan Ayrey's talk included a compelling demonstration and proof of concept (PoC) to validate the theoretical attack described.

The PoC involved the following steps:

1. Domain Selection: Ayrey randomly selected a domain from his "book" containing 10,000 failed startup domains. He explicitly stated he knew nothing about the company beyond its Crunchbase listing, emphasizing the ease with which a target could be identified.
2. Domain Purchase: He purchased the expired domain via a domain registrar like Namecheap. This step is critical as it grants the attacker full control over the domain's DNS records.
3. Google Workspace Setup: Ayrey then attempted to set up a new Google Workspace (formerly G Suite) using the newly acquired domain. Google's system recognized that a Google Workspace had previously existed for that domain and prompted him to prove ownership. By modifying the DNS records (e.g., adding a TXT record) as instructed by Google, he successfully proved ownership and registered a new Google Workspace for the domain. It's important to note that this process does not grant access to the old Google Drive data or old emails associated with the original Workspace; it merely establishes a new, attacker-controlled Workspace under the same domain.
4. Account Creation/Impersonation: Within the new Google Workspace, Ayrey could create user accounts. While he didn't explicitly state if he created specific old employee accounts in the PoC, the general attack vector involves creating an email address that matches a known former employee (e.g., [email protected]).
5. Accessing Third-Party Services: Using this newly controlled Google account, Ayrey navigated to various SaaS (Software as a Service) platforms. Instead of clicking "create account," he selected the "Login with Google" option. Crucially, on these services, he was not prompted to create a new account but was instead logged directly into existing accounts of former employees. The services, relying on the email and hd claims, recognized the domain and email address as belonging to a legitimate user and granted access to the attacker.

The most alarming part of the demonstration involved accessing HR systems. Ayrey reported that some of these systems allowed him to log in and view highly sensitive information belonging to the original employees, including:

• W2 forms
• Social Security numbers
• Bank routing numbers

This level of access unequivocally demonstrates the severe real-world impact of the vulnerability, extending far beyond simple account takeover to potential identity theft and financial fraud.

Furthermore, Ayrey noted a secondary exploitation path: if an attacker gains access to a service that exposes a list of former employees (e.g., an HR system or internal directory), they could use this list to create all the corresponding email accounts within their newly controlled Google Workspace. This would then enable them to systematically log into a multitude of other services associated with those former employees, amplifying the attack's scope significantly.

Defensive Implications

▶ Watch: Default OAuth claims: HD and email vulnerability explained (7:45)

The findings from Dylan Ayrey's talk present significant defensive challenges for both service providers (relying parties) and Google (the identity provider), as well as implications for end-users.

For Service Providers (Relying Parties):

1. Re-evaluate OAuth User Identification: Service providers currently relying solely on the email and hd claims from Google for user identification are vulnerable. They cannot reliably distinguish between a legitimate user and an attacker who has acquired an expired domain and set up a new Google Workspace.
2. Unreliable sub Claim: The sub claim, which Google documents as a unique identifier, has been shown to be unstable in practice (changing for 0.4% of users weekly). This makes it impractical for service providers to use as a primary stable identifier without causing significant user lockout issues and poor user experience.
3. Lack of Immediate OAuth Mitigation: Unlike password reset flows, implementing a "speed bump" or additional verification steps during a "Login with Google" flow is generally not feasible. Product teams actively resist adding friction to the login process, making it difficult to introduce MFA or other challenges without Google's direct involvement.
4. Audit Account Linking Logic: Service providers should review their account linking logic to understand precisely what claims they use to identify users from social logins. They need to consider the scenario where a domain changes ownership and how their system would react.
5. Data Minimization and Retention Policies: Services, particularly those handling sensitive data like HR systems, should strictly adhere to data minimization principles. Retaining sensitive personal data (W2s, SSNs, bank details) for former employees long after their departure, especially if their login method is vulnerable, significantly increases risk. Robust data retention and deletion policies are crucial.

For Google (the Identity Provider):

1. Implement Stable Identifiers: The most crucial defensive implication for Google is the urgent need to introduce two new, truly stable identifiers:

• A unique, immutable identifier for the Google Workspace/domain itself, independent of who currently owns the domain.
• A unique, immutable identifier for the user account within that specific Google Workspace, which persists even if the domain changes hands or the user's email address is re-created under a new Workspace.

These identifiers would allow relying parties to definitively link a login to the original Google account and Workspace, preventing impersonation via domain re-registration.

1. Reclassify the Vulnerability: Google's classification of this issue as "Fraud and Abuse" rather than a fundamental OAuth technical vulnerability is problematic. A clear acknowledgment of the underlying technical flaw is necessary to drive a proper solution.
2. Provide Guidance to Developers: Once a fix is implemented, Google must provide clear documentation and guidance to service providers on how to correctly (and securely) use the new identifiers to prevent this class of attack.

For End-Users:

1. Awareness of Risk: Former employees of defunct startups should be aware that any accounts linked via their old corporate "Login with Google" are potentially vulnerable if their former company's domain has expired and been re-registered.
2. Update Login Methods: Users should consider updating their login methods for critical third-party services if they are still using an old corporate Google account. Where possible, they should switch to a personal email address or a direct username/password login, ideally secured with MFA.
3. Monitor for Suspicious Activity: Users should remain vigilant for any suspicious login attempts or activity on accounts that were previously linked to old corporate email addresses.

For Password Reset Flows:

While the primary attack focuses on OAuth logins, Ayrey noted that email-based password reset flows are also vulnerable if an attacker controls the domain. For this specific scenario, service providers can implement mitigations:

• Mandatory MFA for Password Resets: Require users to complete a second factor of authentication (e.g., SMS code, authenticator app, hardware token) before allowing a password reset via email.
• Knowledge-Based Authentication (KBA): Implement additional verification questions, such as "last four digits of your credit card" or "mother's maiden name" (though KBA can have its own security issues if answers are publicly available).

However, these "speed bumps" are generally not acceptable for the primary OAuth login flow due to user experience concerns, underscoring the unique challenge of addressing the core OAuth vulnerability.

Key Takeaways

• Millions of accounts are vulnerable: An estimated 10 million accounts associated with over 116,000 failed startups are susceptible to takeover due to expired domains and Google OAuth vulnerabilities.
• OAuth claims are insufficient: The commonly used email and hd (hosted domain) claims in Google's OAuth ID tokens cannot reliably distinguish between a legitimate user and an attacker who has re-registered an old company's domain.
• sub claim is unreliable: Google's sub claim, intended as a unique user identifier, is unstable in practice, changing for 0.4% of users weekly, making it impractical for service providers to use as a primary account identifier.
• Sensitive data at risk: Successful attacks can lead to access to highly sensitive personal and financial data, including W2s, Social Security numbers, and bank routing details from HR systems.
• Google acknowledges but hasn't fixed: Google has acknowledged the issue with a bug bounty payout but has not provided details on a fix or committed to implementing the necessary stable identifiers for workspaces and users.
• Limited immediate defenses for OAuth: Service providers face challenges in implementing "speed bumps" for OAuth logins without Google's intervention, though password reset flows can be hardened with multi-factor authentication.

About the Speaker(s)

Dylan Ayrey is a security researcher known for his significant contributions to the cybersecurity community. He is widely recognized as the author of TruffleHog, an open-source tool designed to find credentials and sensitive data in Git repositories. Beyond TruffleHog, Ayrey has engaged in extensive cloud security research, contributing to a deeper understanding of vulnerabilities and best practices in cloud environments. He also maintains a presence on TikTok, where he shares security-related content. This presentation marked his first time presenting at ShmooCon.