Anthem — 78.8M health-insurance records

What happened

On 4 February 2015 Anthem Inc., then the second-largest health insurer in the United States, disclosed that attackers had broken into its IT systems and exfiltrated personal data on approximately 78.8 million current and former members and employees. The breach was, and remains, the largest reported theft of healthcare data in US history.

The data taken did not include medical records, diagnostic information, or treatment histories — the database targeted was an administrative data warehouse, not a clinical system. What it held was arguably more durable in its harm: names, dates of birth, Social Security numbers, member identification numbers, street addresses, email addresses, phone numbers, and employment information including employer details and income. Social Security numbers do not change. A dataset of 78.8 million SSN-linked records provides the foundation for identity fraud, targeted phishing, and foreign intelligence targeting that persists for the lifetime of the affected individuals.

The breach was discovered on 29 January 2015 by a database administrator who noticed that a fellow IT worker’s name was being used to run queries against the data warehouse — queries that the employee had not initiated. Anthem engaged the FBI and external forensic investigators. The FBI’s investigation, combined with subsequent DOJ prosecutorial work, ultimately led to a 2019 indictment of two Chinese nationals: Fujie Wang and an unnamed co-conspirator, described as members of a sophisticated China-based hacking group that had conducted similar intrusions against three other unnamed US companies in the same period.

The pattern of targeting — health insurers, a federal government personnel database, a consumer credit bureau — was consistent with state-directed intelligence collection: building a comprehensive database of American citizens that could be used to identify intelligence officers, verify cover identities, track targets, and support operations against US personnel abroad.

How it worked

The initial access vector was a spear-phishing campaign. Investigators assessed that attackers sent carefully crafted phishing emails to employees at an Anthem subsidiary, with at least one employee clicking a malicious link or attachment that installed malware providing remote access to the attacker. The phishing occurred as early as February 2014 — more than a year before the breach was discovered — suggesting the attackers used an extended initial-access phase to establish a reliable foothold before moving toward the target data.

From the initial compromised endpoint, the attackers conducted credential harvesting — using tools that captured login credentials from memory and from stored authentication material on the compromised machines. With legitimate administrative credentials in hand, they began lateral movement through Anthem’s internal network, escalating from the subsidiary foothold toward Anthem’s core enterprise systems.

The destination was the Anthem Data Warehouse — a centralised repository that aggregated member records across all of Anthem’s insurance brands. The warehouse was a high-value target precisely because it centralised records that would otherwise have required separate intrusions into each subsidiary’s systems. Investigators found evidence that the attackers ran database queries using stolen credentials to extract records in batches, then staged the data for exfiltration. The exfiltration used encrypted channels that blended with normal network traffic, contributing to the extended dwell time before detection.

No evidence emerged that the attackers attempted to monetise the stolen data through conventional identity-fraud channels. The profile of the breach — the choice of target, the patience of the operation, the type of data selected — was consistent with the assessments of US intelligence and law-enforcement agencies that the operation was directed by a foreign state for intelligence purposes.

Timeline

• February 2014 — Earliest evidence of attacker activity in Anthem’s environment; spear-phishing of a subsidiary employee provides initial foothold.
• April–December 2014 — Attackers conduct lateral movement, credential harvesting, and reconnaissance across Anthem’s network. Data warehouse identified as primary target.
• December 2014 – January 2015 — Active exfiltration of records from the Anthem Data Warehouse.
• 29 January 2015 — Anthem database administrator notices that a colleague’s credentials are being used to run unusual database queries that the employee did not initiate. Incident response activated; FBI notified.
• 4 February 2015 — Anthem publicly discloses the breach. Initial estimate of affected records is in the tens of millions; subsequently confirmed at 78.8 million.
• February–April 2015 — Anthem sends breach notification letters to affected current and former members. Offers two years of credit-monitoring services.
• 2015–2016 — HHS Office for Civil Rights launches HIPAA investigation. Multiple state attorneys general open their own investigations. Class actions filed.
• June 2017 — $115 million class-action settlement receives preliminary court approval — at the time the largest data-breach class-action settlement in US history.
• October 2018 — HHS OCR and Anthem agree to a $16 million resolution agreement and corrective action plan — the largest HIPAA settlement in history at that time.
• May 2019 — DOJ unseals indictment of Fujie Wang and co-conspirator for the Anthem breach and related intrusions.

What defenders should learn

The Anthem breach is the clearest large-scale demonstration of a principle that security teams know but organisations often fail to act on: the data that is most harmful when stolen is not always in the clinical or operational system. Anthem’s medical records — diagnoses, treatments, prescriptions — were not taken. The administrative data warehouse, which held the identity and employment data needed to operate an insurance business, was the target. Defenders who prioritise their clinical systems as the crown jewels and treat administrative data as lower-sensitivity are making a categorisation error with lasting consequences for the people whose data they hold.

The credential-harvesting and lateral-movement pattern that moved the attackers from a phished subsidiary endpoint to the central data warehouse is a playbook that has not changed. The countermeasures are similarly well-established but often imperfectly implemented: network segmentation that limits what a compromised endpoint can reach, multi-factor authentication that makes stolen passwords alone insufficient, privileged access management that limits who can query a data warehouse and when, and database activity monitoring that flags anomalous query volumes or patterns — precisely the control that ultimately detected this breach. The detection came from monitoring, not from a perimeter control. Building detection capability for what happens inside the network, after initial access, is where the investment should sit.

The eleven-month dwell time between initial phishing and discovery underscores the inadequacy of perimeter-focused security postures against patient, well-resourced adversaries. The attackers had nearly a year to understand Anthem’s internal architecture, harvest credentials, and locate the target database before beginning exfiltration. A threat-hunting programme — proactive search for indicators of compromise across the environment, rather than reactive response to alerts — gives defenders a chance to detect the reconnaissance and lateral-movement phases before exfiltration begins.

The HIPAA enforcement context is also noteworthy. The $16 million settlement was large in healthcare terms, but the corrective action plan that accompanied it required Anthem to undertake a systematic programme of security improvements including a comprehensive risk analysis, risk management plan, information system activity review, and enhanced identity and access management. The breach enforcement created a documented, auditable security improvement obligation. Organisations in regulated sectors should treat their regulatory frameworks not as compliance checklists but as minimum specifications for the security programme their regulators will hold them to when something goes wrong.