McKesson Breach: How a Vishing Call Turned Into an Okta and Salesforce Incident

The McKesson breach became public on August 28, 2026, three days after McKesson discovered the incident affecting its information systems. McKesson disclosed it via an SEC filing and confirmed an investigation is underway, but has not named the compromised applications, entry method, or exposed data categories.

ShinyHunters, the extortion group that claims responsibility for the incident, filled in gaps McKesson left open. It told BleepingComputer it vished multiple employees, hijacked their Okta single sign-on accounts, and used those sessions to reach McKesson’s Salesforce and Snowflake environments, claiming roughly 1 TB of data was stolen, including 284 million patient-related records.

Security teams should treat the confirmed facts and the attacker’s claims separately. McKesson has verified the intrusion and data theft, but not how attackers got in or what they took. That gap holds the real lessons for enterprise identity and SaaS security.

What McKesson has confirmed, and what it hasn’t

McKesson’s own statement stays narrow. Here’s what the company has confirmed:

• It discovered the incident on August 25, 2026.
• It immediately activated incident response protocols and engaged outside cybersecurity experts.
• It describes the incident as unauthorized access to third-party applications that led to data exfiltration.
• It currently tells customers no action is required on their part and says it isn’t proactively disconnecting systems.

What the company has not confirmed carries equal weight for defenders:

• It hasn’t named the compromised third-party applications.
• It hasn’t described the intrusion vector.
• It hasn’t specified which data categories left the environment.

Every technical detail beyond “unauthorized access and exfiltration” currently comes from the threat actor, not McKesson.

ShinyHunters’ account of the McKesson breach

ShinyHunters told BleepingComputer it ran voice-phishing calls against multiple McKesson employees, reportedly using a lookalike domain resembling mckesson[.]claims to support the pretext. The group’s claimed attack chain runs like this:

• It vished multiple McKesson employees to gain trust and extract credentials or session approvals.
• The calls allegedly compromised several employees’ Okta single sign-on accounts.
• It pivoted from Okta into McKesson’s Salesforce environment, including support cases.
• It also reached McKesson’s Snowflake data platform.
• It exfiltrated close to 1 TB of data between August 21 and August 25, 2026.
• It claims roughly 284 million records, though it has clarified this counts raw data rows, not unique patients.

The group claims the stolen data includes:

• Patient identifiers and Social Security numbers
• Medical record numbers and Medicaid numbers
• Medication and allergy details
• Appointment records and physician information
• Internal Salesforce communications
• Records tied to deceased and terminally ill patients

It also says it contacted McKesson after the theft and demanded $55,236,150, giving the company a 72-hour window to respond. BleepingComputer has not independently verified the stolen-data claims, and McKesson has not confirmed them either.

Featured resource

The Cybersecurity Blueprint

Build a strong cybersecurity strategy with key statistics, attack trends, and practical implementation steps for businesses.

DOWNLOAD

Why the Okta-to-SaaS pattern keeps working

Vishing-driven Okta compromise followed by Salesforce or Snowflake access is now a recurring ShinyHunters signature, not an isolated technique. Recent healthcare-related targets linked in reporting to ShinyHunters data-theft activity include Medtronic, DentaQuest, iRhythm, OneMedical, and AdaptHealth.

The claimed intrusion relied on social engineering rather than a publicly disclosed software exploit.

• A convincing phone call gets an employee to approve an SSO session or reset a credential.
• The attacker inherits whatever access that identity already has, often across multiple connected SaaS platforms.
• Once inside a legitimate SSO session, attackers don’t need malware to move. They can browse Salesforce objects, query Snowflake tables, and export data using the same interfaces employees use every day.

That combination makes detection dependent on spotting anomalous behavior inside trusted sessions, not on catching malicious files.

Reported attack chain: confirmed vs. claimed

Where Hexnode fits into McKesson breach response

The platform doesn’t detect this specific incident or confirm ShinyHunters’ claims, but its documented capabilities map onto the exposure this kind of attack creates.

Hexnode UEM addresses the access side:

• It integrates with identity providers through device compliance–driven Conditional Access, including Okta Device Trust.
• Organizations can require a managed, compliant device before an Okta-authenticated session reaches applications protected by Okta SSO.
• This reduces the chance that a vished credential alone is enough to reach sensitive systems, since access also depends on device posture.

Hexnode IdP addresses the identity layer directly:

• It functions as a native Identity Provider, handling SSO, MFA, and login authentication within the Hexnode UEM ecosystem.
  Access decisions factor in real-time device compliance, so a valid login alone doesn’t guarantee access.
• Continuous session verification lets teams revoke access mid-session if a device’s risk posture changes, rather than relying on a one-time login check.

Hexnode XDR addresses the investigation side, for Windows endpoints specifically:

• Teams can use the query-based Investigate tab to search historical process and event telemetry.
• Analysts can trace which endpoints a suspicious session or process touched and establish the blast radius of a detection.
• If an investigation surfaces a compromised endpoint, teams can isolate it, kill malicious processes, or quarantine files directly from the console.

Neither capability replaces identity-provider investigation, Salesforce and Snowflake audit logs, or the forensic work McKesson’s external experts are running. Hexnode’s role sits at the endpoint and access layer, narrowing what a compromised identity can reach and helping teams investigate the devices involved once an incident is underway.

FAQs

Conclusion

The McKesson breach shows how a vishing claim can raise serious concerns about access to core SaaS platforms holding sensitive healthcare data. Until McKesson confirms more details, security teams should focus on what they control right now: verifying helpdesk identity procedures, auditing recent Okta sessions and resets, and confirming that SaaS access requires more than a valid token.