The McKesson Breach Started With a Phone Call: 284 Million Records in Four Days

McKesson found out on August 25, 2026. By then it was over.

According to what ShinyHunters told BleepingComputer, the group had been pulling data out of McKesson's Salesforce and Snowflake environments since August 21. Roughly a terabyte. Around 284 million records, which the group itself concedes does not mean 284 million distinct patients. Then it sent McKesson a demand for $55,236,150 and a 72 hour clock. In an SEC filing on August 28, McKesson confirmed unauthorized access to third-party applications and confirmed that data was exfiltrated, tied to a subset of customers in its Oncology & Multispecialty and Medical-Surgical business units. It also said the investigation was in its early stages and that it had not concluded the incident was material. The 284 million figure remains the attacker's claim, not the company's.

I have run enough post-mortems to know which detail matters here, and it is not the record count. It is the entry point. ShinyHunters says it phoned McKesson employees, impersonated IT, and walked away with working Okta single sign-on sessions. That is the whole initial access story. There is no CVE in this incident. There is nothing to patch.

Four days, reconstructed

Here is the sequence as the public reporting supports it. Vishing calls hit multiple employees. Those calls produced credentials and an MFA approval, which produced valid Okta sessions. Those sessions produced access to Salesforce and Snowflake, both of which McKesson's people reach through SSO because that is the entire point of SSO. Then bulk extraction ran from August 21 through August 25. Detection landed on day four, on the last day, and by several accounts the thing that surfaced it was closer to the extortion contact than to a security control.

Every step in that chain is an authorized action performed by an authenticated identity. The vishing call is not a network event. The Okta login is a successful login. The Salesforce query is a query a licensed user is entitled to run. Snowflake sees a warehouse doing what warehouses do. If you drew this attack on a MITRE-style board you would end up with a diagram made almost entirely of legitimate behavior, and that is exactly why it took four days.

Worth being precise about what McKesson has and has not said, because the gap tells you something. The company confirmed unauthorized access to third-party applications. It confirmed exfiltration. It named the affected business units. It has not confirmed the record count, the ransom demand, or the vishing narrative, all of which come from the attacker via BleepingComputer. That is normal for day three of an investigation and it is also the reason the public conversation is running on ShinyHunters' framing. The group has an incentive to inflate. It also has a track record of claims that turned out to be broadly accurate, which is why the reporting from TechCrunch, Help Net Security and the HIPAA Journal all ran the number with the caveat attached rather than ignoring it.

This is the same operating model that produced the Anodot token theft earlier this year, where one stolen SaaS integration token cascaded into dozens of downstream victims. Different entry, identical shape: get a valid credential, ride a trusted integration, take the data out through a sanctioned channel.

The phone call is now the most productive exploit in the industry

CrowdStrike's 2026 Threat Hunting Report puts numbers on this. OverWatch measured a 2x increase in vishing intrusions in the first half of 2026 compared to the second half of 2025, on top of a 134% increase from 2024 to 2025. The same report describes SNARKY SPIDER going from account takeover to SaaS data theft in under five minutes.

Under five minutes. Think about what that does to your response plan. Whatever your on-call rotation looks like, whatever your SIEM correlation window is, whatever your help desk escalation SLA says, five minutes is shorter than all of it.

McKesson is not an outlier target either. Reporting on the broader ShinyHunters SSO campaign, including work from Obsidian Security and coverage in Cybersecurity Dive, tracks vishing against Okta, Google and Microsoft SSO accounts at roughly 100 organizations. Retail, airlines, telecom, and now healthcare distribution. EclecticIQ's profile of the group assesses that ShinyHunters is very likely sourcing its voice phishing capability from Scattered Spider and The Com, which means the calling is effectively a shared service and the extortion is the business layer on top.

The people making these calls are native English speakers who sound like your IT department because they have practiced sounding like your IT department. Security awareness training built around spotting a badly written email does not touch this.

They are tuning against your DLP on purpose

The detail from EclecticIQ's research that stuck with me: ShinyHunters has moved off the legitimate Salesforce Data Loader and onto custom Python scripts that pull data in chunked queries with variable chunk sizes, specifically to stay under detection thresholds.

Sit with what that means. Your volume-based controls have become a design input for the attacker. Someone read your detection logic, or inferred it accurately enough, and built an extraction tool whose defining feature is that it fits inside the gap between "normal query" and "alert." Variable chunk sizes are not an optimization for speed. They are an optimization for looking boring.

Any control that fires on "too much" can be defeated by a patient adversary doing slightly less than too much. Four days of steady, unremarkable-looking extraction beats one loud dump every time, and the group knows it.

What that leaves you is controls that fire on a single event rather than on a rate. Something that is wrong the first time it happens, at any volume, at any speed.

279 days, and why McKesson's four looks almost good

IBM's Cost of a Data Breach Report 2026, based on Ponemon interviews across 602 breached organizations, puts the healthcare mean time to identify and contain at 279 days, the longest of any sector for the thirteenth consecutive year, at an average cost of $6.64 million. Breaches involving stolen credentials came in worst overall at 292 days.

Against that baseline, four days is fast. It is also completely inadequate, because the attacker only needed four. That gap is the actual finding here. The industry has spent a decade optimizing dwell time against an intrusion model where the attacker lands, establishes persistence, moves laterally over weeks and eventually trips something. Identity-first SaaS extortion does not have that shape. There is no persistence phase worth mentioning. The session is the payload, and the session expires on its own.

I made this same argument after the Entra directory dumps, where an attacker enumerated 3.6 million records out of Microsoft 365 tenants without touching a single exploit. Reducing mean time to detect from 279 days to 40 is a real achievement that would not have changed the McKesson outcome by one record.

The one noisy moment in an otherwise silent chain

There is exactly one point in this attack where the adversary behaves differently from the employee whose account they took, and it is not the login and it is not the download.

It is the looking around.

A vished session arrives with zero context. The attacker does not know which Salesforce report holds the oncology roster, which Snowflake schema has the claims data, which shared drive the finance team actually uses. Your employee knows. Your employee goes to the same four objects every day and has for two years. The attacker has to enumerate: list the objects, scan the reports, browse the schemas, read the names, decide what is worth the bandwidth. That reconnaissance is unavoidable, it happens before the exfiltration, and it is the only phase where intent leaks.

This is where deception earns its keep, and it is why I keep arguing that decoys belong inside the data plane rather than around it. A Cloud Mine placed in a Salesforce org as a report with a name that ranks high in an outsider's mental priority list, or a Snowflake table that looks like a claims extract and contains nothing real, has one property that no threshold-based control has: a legitimate employee has no reason to ever open it. Not at low volume. Not at high volume. Not slowly. The signal is binary. First touch, alert, no tuning, no baseline, no false positive.

And it survives the chunked-query trick entirely, because a decoy does not care how much you took. It cares that you looked.

The objection I hear most often is that a sophisticated operator will recognize a decoy and skip it. Sometimes, sure. That objection misreads the economics though. The attacker in a vished session is working against a clock they cannot control, because the session dies when it dies and the account gets pulled the moment anyone at the victim notices. They are not doing careful attribution on every object name. They are triaging a list, fast, and anything that reads like a patient export or a credentials file gets opened precisely because it looks valuable. The same greed that makes bulk exfiltration profitable is what makes decoys work. And you do not need them to hit every decoy. You need one.

There is a second reason this fits the healthcare case specifically. Compromised credentials in the infostealer market are already circulating by the millions before anyone places a call, which means the vishing step is often just MFA cleanup on an account whose password the attacker already bought. Prevention controls that assume the password is still a secret are working from a premise that stopped being true a while ago. Detection that assumes the attacker is a stranger inside your data is still on solid ground.

What I would go do on Monday

Concrete, in the order I would do it.

Put honeytokens where an enumerating attacker looks first, not where your crown jewels are. Decoy Salesforce reports with names like "Patient_Master_Export_FY26." A Snowflake table in the same schema as the real claims data. Fake AWS keys in the runbook your help desk reads from during a password reset call, so that a vishing operator who talks their way into that runbook detonates the alert while still on the phone. That last one is my favorite because it turns the attacker's own social engineering step into the tripwire.

Fix the help desk workflow, separately and in parallel. Voice is not identity. If your reset procedure can be satisfied by someone who knows an employee's manager, start date and last four, it will be satisfied by someone who knows those things and is not the employee. This is the same category of gap as the conditional access exception that let the LSHIY campaign walk past MFA with legacy authentication: a policy that is correct on paper and has one human-shaped hole in it.

Then instrument the SaaS layer for enumeration specifically, not just for volume. Ask your Salesforce and Snowflake logs a different question than "who took a lot." Ask "who looked at something they have never looked at before." Most teams have the telemetry for this already and have never written the query, because the alert it produces is noisy without decoys to anchor it. With decoys, the noise problem disappears.

McKesson's investigation is early and the record count is still an attacker's claim, so treat the specific number lightly. Treat the method as settled, because it is: a phone call, a valid session, four quiet days, and a $55 million invoice. If your entire detection posture for that chain rests on spotting an anomalous volume, you are defending against the version of this attack that ShinyHunters stopped running a year ago. Book a demo and we will show you what it looks like when the first thing an attacker touches in your Salesforce org is a table you put there for exactly that purpose.