Skip to content

DEF CON 34 talks are here: 354 talks, summarized and searchable.

Browse DEF CON 34

Taking Over Millions of Accounts from Abandoned Startups

Dylan Ayrey

AppSecTalks23 minIntermediateOpen on YouTube ↗

Where

Talks
ShmooCon 2025

Duration

23 min

Shows how re-registering lapsed startup domains lets attackers reach old Google sign-in accounts at other services.

Summary

The talk opens with a skit about a fictional startup that shuts down while its domain lapses. The speaker then explains how "Sign in with Google" works: the service asks Google who a user is, Google confirms the email address, and the service logs that person in. Most sites only check the account's domain and email, so whoever buys an expired domain can recreate the same addresses and get into old accounts.

Using a public startup dataset, the speaker counted about 116,000 failed companies whose domains were available to buy. Registering one of them and creating a Google Workspace on it gave access to former employee accounts at several SaaS providers. One HR system exposed sensitive payroll and banking data. Some providers also leaked old user lists, which made the problem worse. The speaker estimates roughly ten million accounts could be affected. The Google subject identifier would be a stronger check, but it changes for some real users, so providers could not rely on it. Google first closed the report as working as intended, then reopened it with a small bounty and no concrete fix, past the usual 90-day disclosure window.

The speaker separates this from password reset flows, which providers can harden by adding a second verification step. Social login has no easy provider-side fix, since adding friction to login is unlikely to be accepted. The practical takeaway is to check whether sign-in relies only on email and domain, and to treat expired domains as an account takeover risk.

Related talks

Talks·21 min

  • ShmooCon
  • AppSec
  • Date: Jan 2025
  • Location: DC

Falcon Darkstar Momot

Shows how Postgres roles, stored procedures and in-database JWT checks can limit what SQL injection is able to reach.

appsecvulnerabilitiesidentity+3