Health Data Breach: 23andMe Lawsuit Lessons for Indian SMBs

The 23andMe health data breach of October 2023 is back in the headlines — this time with a lawsuit. California Attorney General Rob Bonta has filed a landmark legal action against 23andMe (acquired by Regeneron Pharmaceuticals after its March 2025 bankruptcy filing) for failing to protect the genetic and personal health data of millions of customers.

What happened and why does it matter to Indian businesses? In October 2023, attackers used automated credential stuffing to compromise 14,000 23andMe accounts, then exploited a social feature to scrape data from 6.9 million connected profiles. The stolen genetic and health data was packaged and listed for sale on dark web forums. For Indian SMBs, the case is a direct warning: the DPDP Act 2023 imposes strict obligations on health data, and CERT-In mandates breach reporting within 6 hours — a delay like 23andMe's is not legally survivable in India.

If you run an Indian business that touches health, wellness, insurance, or HR data, this case is your mirror — and the DPDP Act is your countdown clock.

What Happened in the 23andMe Health Data Breach

In October 2023, attackers launched a credential stuffing campaign against 23andMe — feeding billions of stolen email-password combinations, harvested from prior breaches on other platforms, into 23andMe's login page at machine speed. Approximately 14,000 accounts were directly compromised this way. Individually, that sounds manageable. What happened next was not.

23andMe's "DNA Relatives" feature — designed to help users discover genetic matches — had no meaningful rate limiting, no bulk-access detection, and no anomaly alerting. Once inside those 14,000 accounts, the attackers scraped every linked profile in their networks. Because users opt into sharing data with genetic relatives, one compromised account could expose hundreds. The cascade turned 14,000 breached logins into 6.9 million victims — nearly half the entire 23andMe user base — whose ethnicity estimates, family trees, health predisposition reports, and wellness data were harvested and packaged for sale on dark web forums, listed at negligible prices per profile.

What made the legal action inevitable was what came after. 23andMe took over five months to fully notify all affected individuals , initially attempted to blame customers for reusing passwords, and allegedly misled users about the scope of the compromise. The California AG's complaint details failures at every layer: inadequate technical controls, delayed incident response, and opaque communication. The company has since filed for bankruptcy and been acquired — but the liability followed it.

Why This Matters for Indian Businesses

If you think this is a distant American problem, consider how many Indian companies are sitting on equivalent data right now: health-tech platforms, diagnostic lab portals, telemedicine apps, insurance aggregators, corporate wellness tools, HR software with medical records — the list is long, and the data is just as sensitive.

India's DPDP Act 2023 explicitly categorises health data, genetic data, and biometric information as sensitive personal data subject to the highest protection standards. The Data Security Council of India (DSCI) has consistently warned that DPDP Act compliance India readiness among SMBs remains critically low — exactly the gap this lawsuit illuminates. For any organisation processing health data, the penalties for breach-notification failures can reach hundreds of crores per violation, and for an SMB, that is existential.

More critically, unlike the months 23andMe took to notify victims, CERT-In's 2022 directive mandates breach reporting within 6 hours of detection. Not days. Not a press release next quarter. Six hours — with documented evidence.

As someone who has reviewed hundreds of Indian SMB security postures, I see this exact pattern constantly: credential reuse vulnerabilities left unmonitored, authenticated API surfaces never audited, and zero incident response documentation. The 23andMe story is not unusual — it is the norm for companies that treat security as a compliance checkbox rather than an operational reality. The difference is that Indian SMBs will not have a Silicon Valley legal team to negotiate the aftermath.

DPDP Act compliance India starts with the same controls that could have stopped this breach: MFA, API rate limiting, and a 6-hour notification runbook. The data breach India 2025 landscape shows that attackers are already targeting domestic platforms with identical techniques. The health data breach India risk is no longer hypothetical.

Technical Breakdown

The 23andMe attack is a textbook case of attack amplification — a modest initial foothold transformed into a catastrophic breach through a feature-level security gap. Here is the full attack chain:

graph TD
    A[Credential Stuffing Attack] -->|14K logins cracked| B[Valid Authenticated Sessions]
    B -->|No anomaly detection| C[DNA Relatives Feature Abused]
    C -->|No rate limiting on API| D[6.9M Profiles Scraped]
    D -->|Data aggregated offline| E[Dark Web Marketplace Sale]
    E -->|5 month delay in disclosure| F[Regulatory Investigation]
    F -->|2025 filing| G[California AG Lawsuit]
    classDef default fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
    class A,B,C,D,E,F,G default

Credential stuffing is not a sophisticated zero-day exploit — it is brute automation. Tools like OpenBullet ingest leaked credential databases (from prior breaches at LinkedIn, Canva, Domino's India, and thousands of others) and replay them against a target at thousands of requests per minute. Hit rates of 1–3% are typical, and across millions of accounts, that is all an attacker needs.

The critical failure was feature-level access control. The DNA Relatives API had no per-session data volume limit, no alert for a single token accessing thousands of profiles in minutes, and no differential between a curious user browsing their relatives and an automated scraper harvesting at scale. The following pseudocode illustrates the kind of bulk access that almost certainly went undetected:

# Illustrative recreation of the scraping pattern (educational only)
# This shows WHY rate limiting and anomaly detection are non-negotiable

import requests, time

session = requests.Session()
# Attacker already holds valid session tokens from credential stuffing
session.cookies.update({"session_id": "<stolen_token>"})

def get_linked_profiles(profile_id: str) -> list:
    """Each call can expose hundreds of connected profiles."""
    r = session.get(f"https://api.example.com/relatives/{profile_id}")
    return r.json().get("relatives", [])  # Could return 200-500 profiles

# Without rate limiting, this runs undetected for hours
for seed_profile in compromised_profiles:          # 14,000 seed accounts
    linked = get_linked_profiles(seed_profile)     # Each yields ~500 victims
    for profile in linked:
        exfiltrate_to_c2(profile)                  # 6.9M total, quietly
    time.sleep(0.5)                                # Minimal delay = no alarm

The lesson is stark: perimeter and authentication security are necessary but not sufficient. Once an attacker holds a valid session — whether earned legitimately or stolen via credential stuffing — your internal API design, feature-level throttling, and real-time behavioral monitoring are the actual last line of defence. Most security audits never look there.

How to Protect Your Business

Quick Fix: Detect Credential Stuffing in Your Logs Right Now

# Spot credential stuffing in Nginx access logs
# Flags IPs with more than 20 POST /login attempts — adjust threshold as needed

grep "POST /login" /var/log/nginx/access.log \
  | awk '{print $1}' \
  | sort | uniq -c | sort -rn \
  | awk '$1 > 20 {print "[ALERT] Suspicious IP:", $2, "| Login attempts:", $1}'

# Also detect distributed attacks (many IPs, same user-agent)
grep "POST /login" /var/log/nginx/access.log \
  | awk -F'"' '{print $6}' \
  | sort | uniq -c | sort -rn | head -10

# Block credential stuffing with fail2ban
# Add to /etc/fail2ban/jail.local

[nginx-login-protect]
enabled  = true
port     = http,https
filter   = nginx-login-protect
logpath  = /var/log/nginx/access.log
maxretry = 10
findtime = 60
bantime  = 7200

# Create filter: /etc/fail2ban/filter.d/nginx-login-protect.conf
# [Definition]
# failregex = ^<HOST> .* "POST /login
# ignoreregex =

# Check passwords against 10B+ breached credentials at registration
# Uses HaveIBeenPwned k-Anonymity API — your actual password never leaves your server

import hashlib, requests

def is_password_pwned(password: str) -> tuple[bool, int]:
    """
    Returns (is_breached, count) using k-anonymity.
    Only the first 5 chars of the SHA-1 hash are sent — fully privacy-safe.
    """
    sha1 = hashlib.sha1(password.encode('utf-8')).hexdigest().upper()
    prefix, suffix = sha1[:5], sha1[5:]
    resp = requests.get(
        f"https://api.pwnedpasswords.com/range/{prefix}",
        headers={"Add-Padding": "true"},
        timeout=3
    )
    for line in resp.text.splitlines():
        hash_suffix, count = line.split(':')
        if hash_suffix == suffix:
            return True, int(count)
    return False, 0

# Use at signup and every password change
pwned, times = is_password_pwned(new_password)
if pwned:
    raise ValueError(
        f"This password has appeared {times:,} times in data breaches. "
        "Please choose a unique password."
    )

By the Numbers

pie showData
    title 23andMe Breach: How 14K Accounts Became 6.9M Victims (Illustrative)
    "Scraped via DNA Relatives (approx 99.8%)" : 99.8
    "Direct Credential Stuffing (approx 0.2%)" : 0.2

Note: The pie chart above is illustrative, based on the public figures of 14,000 direct accounts versus 6.9 million total victims. The "Secondary Scraping Chains" category from earlier versions of this analysis has been removed as it lacks a verifiable public source.

The distribution exposes the amplification problem at the core of this breach. Approximately 99.8% of victims never had their own account compromised — they were collateral damage from a social-sharing feature with no access controls. This is the feature-level security blind spot that nearly every standard security audit misses: companies test their login pages and forget entirely about what authenticated users can do once inside.

How Bachao.AI Detects This

Bachao.AI by Dhisattva AI Pvt Ltd maps directly to this attack class across four scan dimensions:

Run a free VAPT scan — takes 5 minutes, no signup required. Find your exposed API surfaces before a credential-stuffing attacker does. Questions? Reach us at ceo@bachao.ai. You can also explore more posts on proactive security on the Bachao.AI blog.

Originally reported by BleepingComputer.

Frequently Asked Questions

Written by Shouvik Mukherjee, Founder of Bachao.AI. Follow me on LinkedIn for daily cybersecurity insights for Indian businesses.