Executive Summary
Between 2012 and 2026, a single personal email address accumulated exposure across 38 confirmed data breaches and 2 paste records — a span that covers four distinct phases of the modern threat landscape: the era of weak password hashing (2012–2015), the rise of large-scale credential aggregation (2016–2019), the industrialization of infostealer malware (2020–2023), and the current ransomware data-extortion era (2024–present).
This report treats that exposure history as a live threat intelligence dataset. Rather than cataloguing breaches in isolation, it maps the cumulative attack surface they create — including a key structural finding about authentication architecture: accounts created in the pre-SSO era (pre-2012) may exist as dormant native password accounts alongside more recent Google SSO logins, creating a hidden attack surface the account holder may not be aware of.
Breach Timeline: Four Eras of Exposure
The 38 breaches in this profile do not represent isolated incidents — they map to four distinct phases in the evolution of the threat landscape, each with different attacker capabilities and different risks to the exposed individual.
Analyst note: The 2012 LinkedIn breach went undiscovered until 2016, meaning 164 million cracked SHA-1 credentials circulated for four years before any user notification. Early breach data ages poorly for defenders but never expires for attackers — once cracked, a password hash is permanently a plaintext credential.
Credential Stuffing: The Full Attack Chain
Credential stuffing is the primary active threat arising from this exposure profile. It exploits the gap between how frequently users change passwords and how long cracked credentials remain in circulation. The following chain traces how a 2012 LinkedIn breach becomes a 2026 account takeover attempt — a 14-year attack lifecycle.
The Password Reuse Multiplier
Credential stuffing success scales directly with password reuse. A single compromised credential reused across five platforms creates five simultaneous attack vectors from one breach event. The Synthient dataset (2025, 2 billion records) and Telegram combolists (361 million records sourced partly from infostealer malware) represent the current state of the art — these lists are actively tested against targets continuously.
Source: Compiled from historical breach databases, traded on dark web forums.
Credential age: Reflects passwords at time of breach — may be years old.
Defense: Changing passwords after a breach notification removes the risk. Regular rotation limits exposure window.
Examples in this profile: Collection #1, Cit0day, Pemiblanc, Exploit.In
Source: Malware (Lumma, RedLine, Raccoon) deployed via malvertising, trojanized downloads, phishing attachments.
Credential age: Current — harvested from active browser sessions. Session cookies captured alongside passwords.
Defense: Password changes alone are insufficient if session cookie was captured. Requires full session invalidation + malware remediation.
Examples in this profile: Telegram Combolists 2024 (partially infostealer-sourced)
Threat Actor Profiles
Two categories of threat actor are directly implicated in the highest-severity breaches in this profile: the Everest ransomware group (Under Armour, January 2026) and the infostealer-as-a-service operators whose malware output fed the Telegram combolist distribution network.
MITRE ATT&CK Technique Mapping
MITRE ATT&CK is a publicly maintained knowledge base of adversary tactics and techniques based on real-world observations. In SOC environments, ATT&CK technique IDs provide standardized vocabulary for classifying threat activity across teams and tooling — SIEMs, EDR platforms, and threat intelligence feeds all use ATT&CK as a common language. Each technique below is directly observed in or enabled by the breach exposure documented in this report.
| Technique ID | Tactic | Technique Name | Observed in this profile |
|---|---|---|---|
| T1589.001 | Reconnaissance | Gather Victim Identity Info: Credentials | Email + credentials harvested across 38 sources, compiled into active stuffing lists |
| T1078 | Initial Access | Valid Accounts | Stolen credentials used to authenticate as legitimate user — core mechanism of credential stuffing |
| T1078.004 | Persistence | Valid Accounts: Cloud Accounts | Where Google SSO is active: one token compromise = access to all linked platforms. Where pre-SSO native accounts persist alongside SSO accounts, both attack surfaces exist simultaneously |
| T1555.003 | Collection | Credentials from Web Browsers | Infostealer malware targeting browser-stored credentials — source of Telegram combolist infostealer component |
| T1486 | Impact | Data Encrypted for Impact | Everest ransomware group's Under Armour attack — encryption after exfiltration as double-extortion leverage |
| T1530 | Collection | Data from Cloud Storage | Post-compromise Dropbox access enabled via Google SSO token without separate authentication |
| T1114.003 | Collection | Email Collection: Email Forwarding Rule | Post-Gmail-compromise path: attacker sets forwarding rules to persist access and intercept password resets to all linked accounts |
SOC relevance — T1078.004 (Cloud Accounts): This technique is a tier-one detection priority in Azure SOC environments. Compromised Entra ID (Azure AD) accounts exhibit the same cascading access pattern as the Google SSO structure in this profile — one identity provider controlling access to dozens of SaaS applications simultaneously. Detection focuses on anomalous sign-in patterns: impossible travel, unfamiliar device fingerprints, token replay from unexpected geographic locations.
Cloud Identity Risk: SSO, the Pre-SSO Era, and the Duplicate Account Problem
A key structural finding in this analysis concerns authentication architecture — and it is more complex than it first appears. While LinkedIn, Dropbox, and Canva currently support Google SSO login, the accounts in this profile were likely created before "Sign in with Google" was widely available. Google OAuth for third-party sites launched around 2009–2012 and was not broadly adopted until 2013–2015. LinkedIn was founded in 2003; Dropbox in 2008. Accounts created in that early period would have required native email and password registration.
Analyst note — SSO adoption timeline: "Sign in with Google" did not exist in the early 2000s. Any account created on a platform before approximately 2012 was registered with a native email and password, not OAuth. This means the breach exposure from LinkedIn (2012) and Dropbox (2012) may reflect real native password accounts — not accounts protected by Google SSO — for users who created those accounts in the early days of those platforms.
The Duplicate Account Problem
A common and underappreciated risk arises when users later adopt SSO on platforms where they already had native accounts. The typical sequence: a user creates an account with email + password in 2008. Years later, they click "Sign in with Google" on the same site. If the platform fails to recognize and merge the Google identity with the existing email account — which happens frequently — it silently creates a second account. The user is now logged into the new SSO account while the original native password account continues to exist, unmonitored, in the background.
User creates account in 2008 with email + password. Later switches to "Sign in with Google" and assumes this replaced or secured the original account.
User believes there is one account, protected by Google SSO and Google's 2FA.
User stops maintaining the original password — stops rotating it, forgets what it was, loses the ability to recover it if needed.
Two accounts exist: the original native account (email + old password, possibly from a breached era) and the new SSO account. Platform may not have merged them.
The original account sits dormant — with whatever password was set at creation, potentially one that appears in breach lists, with no active monitoring or rotation.
Password reset emails for the dormant account may not arrive due to spam filtering, delivery failures, or platform changes — creating an unrecoverable account that still holds personal data and represents an active credential-stuffing target.
The Unrecoverable Account: A Compounded Risk
A further complication emerges when attempting to investigate or close these dormant accounts: standard recovery mechanisms fail. The "Forgot password" flow sends a reset email that never arrives — caught by spam filters, routed to a defunct address variant, or simply undeliverable due to platform mail infrastructure issues. The account cannot be accessed, cannot be secured, and cannot be deleted through normal channels.
From a security standpoint, this is a Catch-22: the account exists and is targetable, but the legitimate owner has no path to secure or remove it through standard means. The only recourse is direct contact with the platform's support or privacy team — bypassing the automated recovery flow entirely — which is the approach taken with ParkMobile and Houzz in this analysis.
Critical finding: For accounts created before 2012 on platforms now supporting Google SSO, both a dormant native password account and a current SSO account may coexist without the user's awareness. The dormant account carries the credential risk from the original breach era; the SSO account carries the Google identity risk. Both attack surfaces must be addressed — and the dormant account may only be closeable via direct support or privacy deletion request, not through standard recovery flows.
The SSO and Azure Entra ID Parallel
Where SSO is confirmed and fully adopted, the risk architecture is directly analogous to Azure Entra ID in enterprise environments. A single identity provider controlling authentication for multiple downstream applications means one compromised token cascades through every integrated platform simultaneously. In Azure SOC contexts this is a tier-one detection priority — anomalous Entra ID sign-in patterns (impossible travel, unfamiliar device, token replay) trigger immediate investigation precisely because the blast radius of a single compromised identity is so large. The consumer equivalent deserves the same priority treatment.
Root of trust: Google account controls OAuth authentication for linked platforms.
Blast radius: One stolen session token = simultaneous access to all SSO-linked platforms.
Email-as-master-key: Gmail also functions as the password reset address for every email-linked account — SSO or not. Compromising Gmail gives reset authority over all downstream accounts.
Detection gap: No centralized audit log across platforms for consumer SSO sessions.
Root of trust: Entra ID controls authentication for all integrated SaaS applications — SharePoint, Teams, Salesforce, ServiceNow, and more.
Blast radius: One compromised Entra ID account cascades through every integrated application via OAuth token delegation — functionally identical risk profile at enterprise scale.
Detection advantage: Entra ID Sign-in Logs + Microsoft Defender for Identity provide centralized visibility. Anomalous sign-ins trigger automated risk scoring and conditional access policies.
SOC priority: Entra ID compromise is the single highest-leverage attack path in most Azure environments — tier-one detection, tier-one response.
Prioritized Remediation
Remediation is ordered by attack path proximity — actions that close the highest-impact vectors first. Each action is mapped to the MITRE ATT&CK technique it mitigates.
| Priority | Action | ATT&CK Mitigation | Effort |
|---|---|---|---|
| P1 — Critical | Harden Google account — upgrade 2FA to authenticator app, audit sessions and third-party app permissions, confirm unique high-entropy password in manager | T1078.004, T1078 | Hours |
| P2 — Critical | Password manager security audit — run Watchtower/Breach Report, rotate any reused or flagged credential. Priority: financial, email, professional accounts | T1078 | Hours |
| P3 — High | Dropbox file audit — review stored files for sensitive documents, remove active shared links, check for legacy native password in Account Settings → Security | T1530 | Hours |
| P4 — High | Dormant account deletion — ParkMobile (support portal submitted), Houzz ([email protected] submitted), EatStreet (deleted). Reduces active attack surface | T1078 — attack surface reduction | Days |
| P5 — High | Enable continuous breach monitoring — HaveIBeenPwned email alerts + password manager breach monitoring. Converts reactive posture to proactive detection | T1589.001 — early warning | Minutes |
| P6 — Maintain | Credit freeze — maintain existing — PII exposure across Neiman Marcus, Evite, EatStreet, French Citizens dataset (name, DOB, address, partial card). Freeze is stronger protection than fraud alert | Identity fraud mitigation | Done |
Check Your Exposure
Two tools below. The first checks whether a specific password has appeared in any known data breach — using the HaveIBeenPwned Pwned Passwords API with k-Anonymity: only the first 5 characters of a SHA-1 hash are ever transmitted, never the password itself. The second links directly to HaveIBeenPwned's email breach search. Neither tool stores, logs, or transmits any personal data.
Conclusions: What Thirteen Years of Breach Accumulation Teaches
Thirteen years of breach accumulation across a single email address illustrates a fundamental asymmetry in digital security: defenders must secure every account continuously, while attackers need to exploit only one credential successfully. The 38 breaches in this profile are not independent incidents — they are 38 contributions to a compounding attack surface that grows more dangerous as aggregators combine them into increasingly comprehensive stuffing lists.
A key structural finding — refined during the investigation — concerns the assumed SSO architecture. Because LinkedIn, Dropbox, and Canva accounts were likely created before Google SSO was widely available (pre-2012), native email and password accounts almost certainly predate any SSO adoption. When users later adopt SSO on platforms where native accounts exist, platforms frequently create a second account rather than merging identities — leaving a dormant native password account in the background, unmonitored, carrying credentials from the original breach era. This duplicate account problem is invisible to the user but fully visible to credential-stuffing tools. In enterprise Azure environments, the equivalent risk is unmanaged legacy authentication protocols that persist alongside modern Entra ID SSO — the same ghost-account problem at organizational scale.
The emergence of the Synthient dataset (2025, 2 billion records) and the Telegram infostealer combolists (2024, 361 million records with browser-harvested credentials) signals a qualitative shift: credential stuffing is no longer limited to reusing historical breach data. Infostealer-sourced credentials are current, bypass password change history, and require behavioral detection — anomalous login patterns, impossible travel, unfamiliar device fingerprints — as a primary defense layer. This is precisely the detection logic that defines modern SOC operations in Azure environments.
Final assessment: The most underappreciated risk in this profile is not the 38 breaches themselves but what they revealed about account architecture: dormant native password accounts from the pre-SSO era likely coexist alongside current Google SSO logins on platforms including LinkedIn and Dropbox. These accounts are unmonitored, carry credentials from breach-era passwords, cannot be recovered through standard reset flows, and are only closeable via direct privacy deletion requests. The attack surface is larger — and harder to close — than a simple breach count suggests.
All findings in this report are based on publicly available breach data from HaveIBeenPwned.com, vendor security notifications, and open-source threat intelligence. MITRE ATT&CK techniques referenced are from ATT&CK v14. This analysis represents the author's independent research and does not reflect the views of any employer or client organization.