A Very Large Order of Patient Data
# A Very Large Order of Patient Data
284 million records isn't just a number. It's a map. When McKesson confirmed those records were exposed, they weren't talking about a leak so much as a mass migration. Healthcare ranks third out of twelve most targeted sectors this week, but this is the failure that actually matters.
I suspect the entry happened through a compromised third-party credential or an unpatched edge appliance. Those are the usual culprits for a company this size. I'll be sure if a specific CVE linked to their perimeter turns up, but right now it's just probability based on current trends. Why is there always a rush to blame a "sophisticated actor"? Sophistication is usually just a cloak victims use to explain why basic monitoring failed.
The real question is how they stayed inside long enough to move nearly 300 million records out the door. That means staged exfiltration.
Most people think of a breach as a digital smash and grab. They imagine an attacker finds a database, hits download, and disappears. It doesn't work like that with 284 million records. If you try to push a multi-terabyte blob of data out of a corporate network at once, you trip every egress filter and anomaly detector in the place. Instead, attackers use staging. They find the data, compress it into smaller encrypted chunks, and move those pieces to an internal staging server. This is often a compromised print server or some forgotten backup node, and from there, they trickle the data out. They use low and slow techniques, mimicking legitimate HTTPS traffic or using cloud storage APIs that the company already trusts.
They aren't stealing a mountain; they're moving it one pebble at a time.
This smells like that 2015 Anthem breach. The attackers back then hung around in the network for months (just slowly siphoning off almost 80 million records), and both cases show some real patience on the part of the adversary. The volume is where things differ. To move 284 million records, you need a level of persistence that implies either a ghost for an attacker or a deaf security operations center.
McKesson's public statements read like a corporate script, and they talk about their "commitment to privacy," "comprehensive investigations," and hiring outside forensics firms. Notice what they don't say? They avoid the dwell time; we aren't told how many days or months those records sat staged before someone finally tripped an alarm.
Getting hit happens. A medical logistics supply chain is complex, which means you have a massive attack surface. But missing the exit of 284 million records isn't just bad luck. It's a choice in where to put your money. Their monitoring was likely tuned for availability (keeping the lights on) instead of integrity (watching what leaves the building).
The cost will be astronomical, though not mostly from fines. The real hit is the second order effect on the medical supply chain. McKesson acts as the plumbing for hospitals and pharmacies; when a central node like this gets compromised, every downstream partner has to treat any message from them with suspicion. Is it an email or a phishing attempt using the stolen data? That's what thousands of pharmacists and clinic administrators will be wondering for the next six months. It'll lead to massive verification fatigue.
The insurers will also be sweating. A breach of this magnitude usually triggers complex indemnity clauses that can tie up legal departments for years.
I bet we'll hear it was a known ransomware gang or some state actor within a few weeks. I don't buy that timeline. Fast attribution is usually just a guess in a fancy suit. To get from "suspected" to "probable," you'd need to see the specific command-and-control infrastructure used for staging (not just the ransom note they left behind).
Who actually owns the security in a managed service? That's the real question, and it's an uncomfortable one if one of the world's largest medical supply chain entities can't tell when 300 million records leave the building. We talk about shared responsibility models, but when data walks out the door unnoticed, that responsibility isn't being shared. It's just gone.
I'm waiting for the forensic report to see if there were any canary tokens (those fake records meant to alert security teams if they're moved or touched). If McKesson had them and they didn't go off, then we aren't looking at a tool failure. We're looking at a total collapse of the response process.
Until then, 284 million people just had their medical history turned into a commodity.
◼
Sources
The reporting this analysis was built from. Follow the originals before acting on anything here.
- PaperCut Replaces Emergency Patches With Fixes for Two Actively Exploited Flaws The Hacker News
- Attackers Chain JFrog Artifactory Flaws to Gain Admin Control and Plant Backdoors The Hacker News
- IDScan Confirms Massive Data Breach Affecting 150 Million – DTH - Daily Tech News Show Google News Security
- IDScan confirms breach after 153 million driver’s licenses leak on dark web - Help Net Security Google News Security
- GitLab Vulnerability Exploited One Day After Disclosure SecurityWeek
- PaperCut Flaws Exploited in AI-Powered Attacks SecurityWeek
- Data Breach Hits Medical Supply Chain Giant McKesson, Exposing 284 Million Patient Records - CPO Magazine Google News Security
- 4.1M Impacted by AdaptHealth Data Breach - Security Magazine Google News Security