The McKesson Breach Didn't Start in McKesson's Code

McKesson is a healthcare and pharmaceutical distribution company worth well over $300 billion. On August 31, 2026, it confirmed a cybersecurity incident discovered on August 25. The extortion group ShinyHunters claims to have taken roughly 284 million records from McKesson's Oncology & Multispecialty and Medical-Surgical business units, a mix of personally identifiable and protected health information.

That number is not confirmed. McKesson's own statement says the investigation is still in early stages, and it has not disclosed the volume or category of data taken. ShinyHunters has inflated numbers before, and 284 million records does not necessarily mean 284 million unique patients.

What McKesson has confirmed is narrower, and more useful to a security team than the headline figure: the access came through unauthorized entry into third-party applications connected to its environment, not through McKesson's own core systems.

That single sentence is the entire story. Not a hole in McKesson's own application. Not a flaw in code its engineers wrote. A third-party app that happened to hold a live connection to McKesson's data, reached through a login that was never supposed to leave the building.

The Attack Chain, Technically

According to ShinyHunters' own account to BleepingComputer, the entry point was a person, not a vulnerability. The group ran voice phishing calls against McKesson employees, then used compromised Okta single sign-on accounts to reach Salesforce and Snowflake, and pulled roughly 1 TB of data between August 21 and 25.

That is a three-stage chain, and it maps cleanly to a pattern that has been documented at scale since mid-2025 against exactly this kind of target. Google's Threat Intelligence group tracks the actor cluster behind it as UNC6040, widely reported under the ShinyHunters name, working in loose overlap with Scattered Spider's social engineering playbook.

This is not a novel technique invented for McKesson. It is a known, repeatable, well-documented methodology that has hit Google, Adidas, Cisco, Workday, Allianz Life, and hundreds of other organizations running the same identity stack.

Stage 1: Vishing the help desk, not the employee. The call rarely targets the person whose account gets compromised. It targets IT support or a help desk agent, impersonating an employee who is locked out or has a "connectivity issue."

The goal is to get a password reset, an MFA re-enrollment, or a temporary access grant issued to the attacker instead of the real employee. This sidesteps email security controls entirely, because there is no phishing link or malicious attachment for a mail filter to catch. It is a phone call exploiting a process, not a technical control.

Stage 2: SSO as the pivot point, not the target. Once the attacker holds valid credentials for the Okta tenant, Okta itself is rarely the objective. It is the trust broker that federates identity out to every SaaS platform the organization has connected.

A single authenticated Okta session inherits whatever access that identity has been granted downstream, and in a mature SaaS estate, that downstream list is long: CRM, data warehouse, ticketing, HR, file storage, and dozens of connected apps nobody remembers approving.

Stage 3: OAuth-connected apps as the exfiltration path. This is the step that gets missed in most breach retrospectives, and it is the technical detail that turns a stolen login into 1 TB of data. Salesforce, like most modern SaaS platforms, allows an authenticated user to authorize a "connected app," a third-party integration granted an OAuth token scoped to API access, often including bulk data export permissions like the Bulk API or Data Loader.

In documented UNC6040 campaigns, the attacker doesn't need to find a vulnerability in Salesforce. They walk into Setup, authorize their own malicious connected app using the compromised session, and that app now holds a durable OAuth token independent of the original login.

The token keeps working even if the stolen password is reset, because nobody revoked the grant. From there, a scripted Bulk API export of every object the identity can reach, contacts, cases, custom objects holding PHI, is a background job, not a break-in.

Snowflake fits the same pattern from a different angle: once an identity is federated through SSO, a query interface with broad read access to a data warehouse is a far faster exfiltration path than trying to pull records one screen at a time through a UI. A thousand gigabytes moves quickly through a warehouse query. It moves slowly, and loudly, through a web app.

None of these three stages requires the attacker to write an exploit. Every technical control involved, MFA, OAuth scoping, session policy, worked exactly as designed. The failure is upstream of all of them: a process trusted a phone call, and nothing downstream questioned what that trust then had permission to do.

Why Third-Party Apps Are the Easier Target

Security teams spend most of their engineering budget on the systems they own. That is a rational allocation on paper. It is also exactly why attackers have moved past it.

A company's own application gets code review, static analysis, and increasingly, regular penetration testing. A Salesforce connected app that a sales ops team authorized two years ago to sync leads into a marketing tool gets none of that.

Nobody on the security team wrote it, nobody scans its OAuth scope, and nobody is testing what a compromised SSO session can reach through it. The connected app itself might be perfectly well built. The problem is a governance gap: it was never in scope for anyone's testing, even though it holds a live, durable credential to production data that never appears on a login screen anyone monitors.

Attackers need one way in. Defenders need to secure everything, every domain, every OAuth grant, every connected app, every day, with no exceptions. Your company has to win every day. An attacker has to win once.

That asymmetry is the whole game, and third-party integrations are where it plays out most cleanly, because they sit in the blind spot between two teams: security owns the identity provider, and whichever business team requested the integration owns the connected app, and neither one is watching the seam between them.

This is the same structural gap our API penetration testing work keeps surfacing from a different angle: the vulnerabilities that get exploited are rarely in the parts everyone already tests. They are in the integrations, the connected apps, and the API scopes nobody remembered to scope.

An API security testing methodology built only around the application your engineers shipped will miss the OAuth token your CRM quietly holds. Healthcare raises the stakes because of what the data is, but the mechanism is identical in every industry that runs Salesforce, Snowflake, or any SSO-federated SaaS estate.

If your identity provider can reach it, it is inside your attack surface whether your security team has ever opened it or not.

What a Real Test Against This Chain Looks Like

Most organizations that get breached this way had a working MFA policy, a documented OAuth governance process on paper, and an annual pentest report that said "no critical findings."

All three can be true and the breach still happens, because none of them tested the specific chain that got exploited: a phished credential's actual downstream reach through connected apps.

A pentest that would have caught this pattern is not a code review and it is not a network scan. It is a targeted simulation of exactly the chain above, starting from an authenticated identity and mapping what it can reach, not starting from an assumption that MFA makes the identity trustworthy once it's authenticated.

That is the difference between a finding and a proof. A scanner can flag "connected app has broad API scope" as a medium-severity configuration issue and move on.

A real test authenticates as a compromised identity, walks the actual OAuth grant, and proves whether that scope reaches PHI, PII, or financial records, the same way an attacker would, with evidence attached rather than a severity label attached.

That distinction, a labeled risk versus a demonstrated breach path, is the entire difference between a compliance checkbox and a security program that would have caught this before ShinyHunters did.

What This Means for Your Third-Party Surface

A few practical takeaways from this specific attack chain, for any team that connects SSO to SaaS tools holding sensitive data.

• Inventory every OAuth-connected app, not just every vendor. A vendor risk questionnaire tells you a company passed a SOC 2 audit. It does not tell you what scope the connected app your team authorized two years ago actually holds today, or whether anyone has looked at it since. Pull the live connected-app list from Salesforce Setup, Google Workspace admin, and Microsoft 365 app governance, on a schedule, not once.

• Treat OAuth tokens as standing credentials, not session artifacts. A connected app's token survives a password reset. If your incident response plan for a compromised account stops at "reset the password," it has not actually revoked access. Token revocation has to be an explicit, tested step.

• Test the vendor-connected path, not just the vendor. A SOC 2 badge tells you a vendor passed an audit. It does not tell you what happens when someone with a stolen Okta session hits their API with your data behind it. That is a testing question, not a compliance checkbox, and it needs to be run against the actual authorization chain, not a synthetic environment.

• Treat vishing as a technical control gap, not just a training problem. Awareness training helps, but the durable fix is making a phished credential worth less: hardware-backed FIDO2 MFA that cannot be socially engineered around a help desk reset, session-bound tokens, and conditional access that flags an SSO login authorizing a new connected app for the first time as a reviewable event, not a silent success.

• Assume the record count will grow. McKesson said its investigation is in early stages. That phrase shows up in almost every breach disclosure and almost always precedes a larger number later. Build your incident response timeline assuming the first disclosure understates the scope, because it usually does.

If your organization handles PHI, the connection to compliance is direct. A HIPAA risk assessment is not the same exercise as a penetration test, and the McKesson case is a clean example of why: a risk assessment can note that a connected app holds ePHI on paper.

Only an actual test proves whether a compromised session can walk from your SSO into that app and out with the data, the same way ShinyHunters did here.

The Category Problem Behind This

McKesson is not an isolated incident. It is one data point in a pattern that changed shape faster than most security programs did.

Independent research cited by a16z shows the volume of disclosed vulnerabilities in 2026 running roughly 10x higher than any prior year combined, and the share of vulnerabilities being actively exploited before a patch even exists has climbed toward 90%, up from roughly half in prior years.

Attacks are happening at machine speed. Defense is still running at a human speed, and an annual pentest report, however thorough on the day it was written, is a snapshot of a surface that keeps moving after the report ships.

Security today is largely siloed: one tool for code, one for network, one for cloud, one for identity, one for pentesting, and none of them share what they learn with each other. That siloing is precisely what let a vished credential walk uncontested from an identity provider into a data warehouse.

A defender who can see the full chain, identity to SaaS to data, catches this pattern before it becomes a breach. A defender running five disconnected tools that each see one segment of that chain does not, no matter how good any single tool is in isolation.

The Fix

McKesson's own systems were not the weak point here. The weak point was a door the company did not build, connected through an identity trust chain that, by its own account, was not being watched closely enough. That is the part every security team can act on today, regardless of what the final record count turns out to be.

If ShinyHunters ran this exact chain against your Okta tenant tomorrow, would you find out from your security dashboard or from a ransom note?

CodeAnt AI tests that specific chain, compromised identity through OAuth-connected apps to the data behind them, and proves the answer with runtime evidence instead of a severity label. Start a free pentest and get the answer before an attacker hands it to you.