McKesson Data Breach 2026: Anatomy of a SaaS Exfiltration

McKesson has confirmed that an unauthorized party reached certain third-party applications and removed data. On the attacker's own account, that happened between August 21 and August 25, 2026, and moved roughly one terabyte out of applications connected to the largest healthcare distributor in the United States. Four days. No malware described. No perimeter breach described. No vulnerability described at any stage. On that same account, the attackers called employees, talked their way into valid credentials, and logged in.

Hold the numbers loosely and take the mechanism seriously, because the mechanism is the part that transfers to your environment. On that account, this was not a hacking story in the sense most security programs are built to defend against. It is an identity story and a SaaS-permissions story, and those are two things that almost no annual penetration test scope is written to cover. If your program tests the perimeter, patches on a tempo, and passes a SOC 2, you have covered a set of things this chain never had to touch.

The uncomfortable question for anyone running security at a healthcare organization is not "are we patched." It is "if one of our people gets talked out of a session tomorrow, what does that session reach, and how long does it take us to notice."

What Happened at McKesson

McKesson discovered the incident on August 25, 2026, and disclosed it in a Form 8-K filed with the SEC. That filing is the anchor for everything that is actually confirmed, and it is deliberately narrow.

McKesson confirmed that an unauthorized party gained access to "certain third-party applications" and that data was removed from those applications. The company stated that affected data was associated with a subset of customers in its Oncology & Multispecialty and Medical-Surgical business units. SecurityWeek's reporting and BleepingComputer's corroboration both track that framing closely. McKesson said its own core systems were not encrypted and that operations continued.

Everything else circulating is claim-side, and the list is longer than most coverage admits. ShinyHunters claims it exfiltrated 284 million records. It claims one terabyte of data. It claims the August 21 to August 25 window. It claims the entry route was vishing against Okta SSO accounts, and that the destinations were Salesforce and Snowflake. It claims it demanded $55,236,150 with a 72-hour countdown, and after that clock expired, publicly set a September 1 deadline before threatening to publish. McKesson has named none of those vendors, confirmed none of those numbers, and described no attack chain. No independent party has corroborated any of it. Nothing in this post asserts or implies a security defect, vulnerability or product failure in Okta, Salesforce or Snowflake. On the account as given, those platforms did what they were designed to do for a session that authenticated successfully.

That separation is not pedantry, and it cuts against the parts of the story we find most useful as much as the parts we discount. A record count in a leak-site post is a marketing number designed to maximize pressure on the victim, and it frequently counts database rows rather than distinct individuals. But the same caution applies to the terabyte, the four-day window, and the tidy Okta-to-Salesforce-to-Snowflake path: those came from the same interested party, and an attacker has every incentive to describe a chain that sounds sophisticated and inevitable. Treat all of it as unverified until a notification filing or an incident-response report says otherwise.

So why write about a chain nobody has confirmed? Because the pattern is independently attested even where this incident is not. Health-ISAC documented the same technique against the same sector before McKesson disclosed, which is what makes the mechanism worth your time regardless of which McKesson-specific numbers survive. Four days of sustained bulk export from connected SaaS platforms, using valid sessions, with nothing stopping it, is a scenario your environment either tolerates or does not. Which raises the obvious question: how do valid sessions get there in the first place.

The Attack Chain as Claimed: No Exploit Required

The entry route was the telephone.

The campaign class ShinyHunters has been running through 2026 starts with vishing, voice phishing, aimed at employees and, more productively, at IT help desks. The caller impersonates an internal user or an IT staffer. Domain impersonation supports the call: lookalike domains that mirror the target's SSO login page, staged and registered in advance so the URL passes a glance.

The part that defeats the control most organizations are counting on is the tooling. Modern phishing kits render authentication dialogs in real time, synchronized to the phone call. The caller keeps the target on the line while the kit relays credentials and multi-factor prompts to the real identity provider as they are entered. The target sees a login page that behaves exactly like their login page, because functionally it is their login page with an attacker in the middle. The MFA push arrives from their provider at the moment they expect it, and they approve it. The attacker walks away with a live authenticated session, not a password.

There is a second route, and it matters more than the first because it survives the control most people reach for. Rather than relaying an employee's authentication, the caller targets the help desk directly and asks for a password reset, an MFA factor reset, or a new device enrollment. Health-ISAC describes this as the primary initial-access technique in this campaign class, which is why its lead recommendation is out-of-band verification and a no-same-call policy for resets rather than a factor upgrade. Note what this route does: it does not defeat the authenticator, it replaces it. The attacker is not stealing a credential, the organization is issuing them one.

This is worth distinguishing from the credential-leak problem, because they are usually discussed as one thing and they are not. Previously leaked credentials replayed from infostealer dumps are largely a stale-password problem, and rotation plus MFA genuinely mitigates that half of it, though the same dumps increasingly carry live session cookies that rotation does not touch. A freshly socially-engineered live session is not a password problem at all. There is nothing to rotate, because the attacker holds the artifact that rotation produces.

From there, on the attacker's account, the chain is short. Multiple SSO accounts were compromised, giving the attacker authenticated presence inside the identity provider's trust boundary. From that position, the attacker moved laterally into connected SaaS applications. In this campaign class, the recurring destinations are Salesforce and Snowflake: a CRM holding customer and contact records, and a data warehouse holding whatever the analytics team needed it to hold. Then bulk export, sustained over four days. Then extortion, a deadline, and a threat to publish.

Note what is absent from the reported chain. No CVE. No payload. No lateral movement across your network, because the movement happened between cloud tenants that never touched your network. No privilege escalation in the traditional sense, because the identity already had the privileges required. Nothing was broken. The system was used as designed, from an identity it trusted.

Why This Is a Pattern, Not an Incident

This playbook predates McKesson, and its arrival in the sector was not unexpected.

Health-ISAC issued a sector advisory about ShinyHunters vishing campaigns and domain impersonation before the McKesson disclosure, describing this chain specifically: voice calls, lookalike domains, SSO compromise, SaaS data theft. The advisory named the technique, not a vulnerability, because there was no vulnerability to name.

The organizations reported as prior targets in the same campaign class are heavily healthcare and health-tech. Coverage of the Health-ISAC warning describes recent ShinyHunters campaigns as having targeted Medtronic, DentaQuest, iRhythm, One Medical, and AdaptHealth using similar tactics. Read that precisely: targeted with similar tactics, which is not the same as a confirmed breach at any of them, and we make no claim about outcomes at any named organization. What the list establishes is the shape of the target set. That is medtech, dental benefits administration, cardiac monitoring, primary care, and home medical equipment. The common thread is not a shared vendor or a shared stack. It is that all of them hold high-value regulated data behind SaaS applications fronted by SSO.

The strategic shift underneath this is worth naming. Huntress's profile of the group tracks its evolution from database theft and resale toward large-scale identity-driven extortion. The move away from ransomware is rational: encryption requires a payload, a payload requires execution on your endpoints, and that is the one thing your EDR is genuinely good at catching. Data extortion via valid SaaS sessions requires none of it. It is faster, quieter, and the tooling generalizes across every victim running the same three or four SaaS platforms, which is nearly everyone.

It is the same group reported to be behind the Oracle PeopleSoft zero-day campaign earlier in the year, which is instructive precisely because the entry route was the opposite. PeopleSoft was an unauthenticated CVE against an exposed administrative endpoint: a patching and exposure problem with a clear technical remedy. The McKesson chain, as described, needed only a valid login. Same actor, same extortion model, same data-theft objective, two entirely different front doors. A program that only hardened against the first one learned the wrong lesson.

Why Your Existing Controls Did Not Cover This

This is the section that determines whether the rest of the post is useful to you, so it is worth being specific rather than gesturing at "defense in depth." Five controls that most healthcare security programs are counting on, and what each one actually did during those four days.

Which leaves the honest question of what testing can and cannot do here.

The Part No Test Would Have Stopped, and the Part a Test Can Measure

No test makes a workforce unphishable.

A determined, well-resourced vishing campaign, run patiently against a help desk with hundreds of staff and a mandate to be helpful, will eventually succeed. That is not a training failure or a culture failure. It is arithmetic. Any vendor telling you their assessment would have prevented the McKesson breach is selling you something, and you should mark them down for it. CyberOrbit will not make that claim. No assessment makes a workforce immune to a convincing phone call, whoever runs it.

So set the prevention question aside, because it is not fully winnable, and ask the one that is.

The useful question is not "can someone steal a credential from us." Assume yes. Assume it will happen this year. The testable questions are the three that follow it: once one identity is compromised, how far does it reach, how much data can it pull, and how long before anything notices or stops it.

Those are architecture questions, not human questions. Blast radius is a configuration. Export limits are a setting. Detection on anomalous bulk read is a rule that either exists or does not. Every one is deterministic, testable, and fixable, and none depends on whether an employee has a bad Tuesday.

That scope has a name. In the industry it is called an assume-breach engagement: the tester starts with a valid identity you provide, and maps what that identity can do. It is a standard, well-understood engagement type, run by firms that specialise in identity and SaaS testing, and it is a different scope from the external assessment that tests your internet-facing attack surface. Many healthcare organizations have simply never bought it, because the annual pentest was scoped against the perimeter years ago and nobody has revisited the scope statement since.

What an Assume-Breach Test Surfaces, Whoever Runs It

Here is what a well-scoped engagement of this type writes down, whoever runs it. These are the five findings worth insisting on when you rewrite the scope statement.

If whoever runs your identity and SaaS testing cannot tell you which of those five are in scope, that is your answer about the scope. It is worth asking before renewal, not after. Use the questions below to evaluate any provider you engage for that work; it is a separate scope that sits alongside the external assessment, not inside it.

If you are rewriting the statement of work anyway, two things are worth doing in the same sitting. Our pentest cost calculator will tell you whether the budget line you have been renewing still matches the scope you now need, and the subdomain finder, run against your own domain, will show you what is exposed on the external side, which is the half of the estate the old scope statement was written for and probably still describes accurately.

Making the Case Internally

If you already agree, the remaining problem is getting it funded. Three arguments that work in healthcare specifically.

Breach notification exposure scales with blast radius. HIPAA notification obligations step up with the number of individuals affected, and the steps are concrete. Under 45 CFR 164.408, a breach affecting fewer than 500 individuals goes into a log reported to HHS annually; at 500 or more, you notify HHS without unreasonable delay and no later than 60 days. Separately, under 164.406, a breach involving more than 500 residents of a single state or jurisdiction requires notice to prominent media serving that state or jurisdiction. That threshold is not a fixed property of your organization. It is a function of how much data one compromised identity could reach, which is exactly what an assume-breach test measures and what segmentation and export limits reduce. Framed that way, this is not a security spending request. It is a quantified reduction in regulatory exposure, and finance understands that shape of argument.

The sector has been formally notified. Health-ISAC published an advisory on this specific chain, naming the technique and the actor, before McKesson disclosed. "We were not aware of this threat" is no longer an available position for a healthcare organization, whether the audience is a board, a regulator, or a plaintiff's counsel. Awareness is now assumed. What gets assessed is what you did after.

Timing. Board attention on a named breach has a half-life measured in weeks. While this one is still recent, the incident is concrete, the sector is named, and "could this happen to us" is already on the agenda. Scope the work while the example is still doing the persuading for you. This is also the natural moment to revisit testing cadence, because an identity and SaaS estate changes far faster than an annual snapshot can track, which is the argument underneath continuous threat exposure management as a program model.

The Bottom Line

Go back to the four days, and hold them as the attacker's account rather than an established one, because the argument does not need them to be exact.

The vishing call is the part everyone is discussing, and it is the part that is hardest to prevent. You can move to phishing-resistant MFA, you can harden help-desk verification, you can train continuously, and a sufficiently determined caller will still get through eventually. That is the honest position.

The dwell time is a different kind of problem. Days of unimpeded bulk export from connected SaaS applications, using a single set of valid sessions, is not bad luck. It is an architecture that permits it, and an architecture is something you designed, which means it is something you can test and change. One identity reaching both a CRM and a data warehouse is a configuration. An export with no volume ceiling is a setting. Bulk reads that alert nobody is a missing rule.

Whatever the final numbers turn out to be, this was not the story of a break-in. It was the story of what a valid login was allowed to do once it existed. Find out what yours is allowed to do before somebody else does.

This post is general information about security testing practice, not legal or compliance advice. Breach-notification obligations turn on facts specific to your organization; take them to your own counsel or privacy officer.

Frequently Asked Questions