Skip to content
Back to Blog
·15 min read·news

Health Data Breach: 23andMe Lawsuit Lessons for Indian SMBs

California sues 23andMe over a health data breach exposing 6.9M records. India's DPDP Act and CERT-In's 6-hour rule demand immediate action from Indian SMBs.

BR

Bachao.AI Research Team

Cybersecurity Research

Source: BleepingComputer

Get Your Free VAPT Scan

Business impact of this development

Emerging threats move fast. Indian SMBs are primary targets because they're under-defended. Here's what you need to know and do now.

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.

6.9MUsers whose genetic and health data was exposed
14,000Accounts directly breached via credential stuffing
5+ MonthsTime taken before full notification to all victims
Dark webGenetic profiles packaged and listed for sale at negligible prices
2025Year 23andMe declared bankruptcy and was acquired by Regeneron Pharmaceuticals
2025Year California AG filed the landmark lawsuit

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.

⚠️
WARNING
Indian companies processing health, genetic, or biometric data face DPDP Act penalties reaching hundreds of crores per violation — and CERT-In mandates breach notification within 6 hours of detection. A months-long delay like 23andMe's is not legally survivable in India.

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:

python
# 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.

Know your vulnerabilities before attackers do

Run a free VAPT scan — takes 5 minutes, no signup required.

Book Your Free Scan

How to Protect Your Business

Protection LayerSpecific ActionDifficulty
MFA EnforcementEnable TOTP/SMS MFA on all user accounts; block login without second factorEasy
Breached Password DetectionIntegrate HaveIBeenPwned API at registration and password-change to reject known-leaked passwordsEasy
Login Rate LimitingDeploy fail2ban or WAF rules to flag >10 failed logins per IP per minuteEasy
API Rate LimitingSet per-user, per-endpoint limits (e.g. max 50 profile lookups per hour)Medium
Behavioral Anomaly DetectionAlert when a single session exceeds normal data volume thresholdsMedium
Data MinimisationMask sensitive fields in API responses; return only what the feature genuinely needsMedium
CERT-In RunbookDocument your 6-hour notification workflow now; designate a nodal officerEasy
Dark Web MonitoringContinuously scan for your domain's credentials on paste sites and forumsHard

Quick Fix: Detect Credential Stuffing in Your Logs Right Now

bash
# 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
bash
# 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 =
python
# 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."
    )
💡
TIP
Run the Nginx log scan above on your production server right now — before reading further. If you see any IP with hundreds of hits on your login endpoint, you may already be under a credential stuffing attack. Rotate your session secrets and enable MFA immediately.
🛡️
SECURITY
Under CERT-In's 2022 directive, all Indian organisations must report cybersecurity incidents — including data breaches — within 6 hours of detection to cert-in.org.in. Designate a nodal officer, pre-fill your organisation's profile on the CERT-In portal, and document your escalation chain before you need it. Companies that scramble to figure this out mid-breach consistently make costly mistakes.

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.

🎯Key Takeaway
Key insight: The 23andMe breach was not a failure of authentication alone — it was a failure of internal API design and behavioral monitoring. Attackers who are already "inside" as valid sessions can cause catastrophic damage if your feature-level access controls, rate limits, and anomaly detection are absent. Most Indian SMB security audits stop at the login page. The real risk begins after it.

How Bachao.AI Detects This

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

🎯Key Takeaway
How Bachao.AI's platform maps to this exact attack class:

VAPT Scan — Our vulnerability assessment probes your authenticated API endpoints for rate-limiting gaps, BOLA/IDOR vulnerabilities, bulk data export weaknesses, and feature-level access control failures — exactly the audit 23andMe needed but never ran. Run a free VAPT scan in under 5 minutes.

Dark Web Monitoring — We continuously monitor dark web forums, Telegram groups, credential marketplaces, and paste sites for your domain's email-password pairs. If your users' credentials surface in a breach database before attackers weaponise them, we alert you first — giving you the window to force password resets and block the attack before it begins.

DPDP Compliance Assessment — We map your data flows, identify sensitive personal data categories (health, genetic, financial, biometric), audit your retention and access policies, and build your CERT-In incident response runbook — so your team knows exactly what to do in the critical first 6 hours of a breach, not just in theory.

API Security Scanning — Our REST and GraphQL scanner goes beyond standard VAPT to test authenticated API surfaces for session abuse, bulk scraping vectors, mass assignment, and data over-exposure — the exact vulnerabilities that turned 14,000 compromised 23andMe accounts into 6.9 million victims.

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

Frequently Asked Questions

What was the 23andMe data breach and how did it happen?
The 23andMe breach occurred in October 2023 when attackers used credential stuffing — automatically testing billions of stolen email-password pairs from other breaches — to access approximately 14,000 user accounts. They then exploited the platform's DNA Relatives feature, which lacked rate limiting and anomaly detection, to scrape data from 6.9 million connected profiles. The stolen genetic and health data was packaged and listed on dark web forums at negligible prices per profile.
What does the 23andMe lawsuit mean for Indian health-tech companies and SMBs?
It signals that regulators worldwide are holding companies directly liable for inadequate technical controls around sensitive health and genetic data — not just for the breach itself, but for delayed notification and opaque communication. Indian companies face parallel obligations under the DPDP Act 2023, which mandates heightened protection for health data. CERT-In's 6-hour breach notification rule means a months-long delay like 23andMe's would trigger immediate regulatory action in India.
What is credential stuffing and how can I protect my Indian business from it?
Credential stuffing is an automated attack where stolen username-password pairs from previous breaches on other platforms are tested at scale against your login page. Protect your business by enforcing multi-factor authentication (MFA) for all users, integrating the HaveIBeenPwned API to reject known-breached passwords at registration, deploying fail2ban or WAF rules to rate-limit login attempts, and monitoring your Nginx or Apache logs for high-frequency POST requests to your authentication endpoint.
Does India's DPDP Act 2023 cover genetic and health data?
Yes. The Digital Personal Data Protection Act 2023 classifies health data, genetic data, and biometric data as sensitive personal data requiring the highest level of protection. Organisations processing this data must implement appropriate technical and organisational security controls, appoint a Data Protection Officer if required, and report breaches to the Data Protection Board of India. CERT-In additionally mandates notification of cybersecurity incidents within 6 hours of detection.
What should an Indian company do in the first 6 hours of a data breach?
Immediately contain the breach by revoking compromised sessions and blocking malicious IPs. Assess the scope — what data was accessed, for how long, from where. Notify CERT-In via their incident reporting portal (cert-in.org.in) within the mandatory 6-hour window and preserve all logs for forensic analysis. Engage your incident response team and prepare user notifications. Having a pre-documented runbook with your nodal officer's contact and CERT-In credentials ready is the difference between a controlled response and a panicked one.
What specific security controls would have prevented the 23andMe breach?
Three controls would have dramatically limited the damage. First, mandatory MFA on all accounts to block credential stuffing from producing valid sessions. Second, per-user API rate limiting on the DNA Relatives endpoint to detect and block bulk scraping — for example, capping profile lookups at 50 per hour per session. Third, behavioral anomaly detection to automatically alert when a single authenticated session accesses thousands of profiles within minutes. None of these are costly or complex — they are standard controls that a thorough API security audit would flag as absent.

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

BR

Bachao.AI Research Team

Cybersecurity Research

AI-powered security research and threat intelligence from the Bachao.AI team. Covering the latest vulnerabilities, CVEs, and cybersecurity developments affecting Indian businesses.

Get cybersecurity insights for Indian SMBs

Weekly vulnerability alerts, DPDP compliance tips, and security guides. No spam — unsubscribe anytime.

We respect your privacy. Your email is never shared.

Find the gaps attackers use for initial access — before they do

Free automated scan — risk score in under 2 hours. No credit card required.

Get Your Free VAPT Scan
Find your vulnerabilitiesStart free scan →