The cybersecurity incident disclosed by McKesson is particularly significant because it combines three of the most important trends currently shaping enterprise attacks: social engineering against employee identities, compromise of cloud and SaaS applications, and large-scale data theft without any requirement for traditional ransomware encryption. McKesson confirmed that it discovered unauthorized access on August 25, 2026, involving third-party applications and the exfiltration of data. At the same time, the ShinyHunters extortion group has claimed responsibility and says it obtained access through voice-phishing attacks targeting multiple employees, ultimately compromising Okta single sign-on accounts and gaining access to Salesforce and Snowflake environments.

The distinction between what McKesson has confirmed and what ShinyHunters claims is critical. McKesson has confirmed unauthorized access to third-party applications and data theft, but it has not publicly identified the applications involved, the initial access mechanism, the data categories stolen or the number of people affected. ShinyHunters, meanwhile, claims it exfiltrated approximately one terabyte of information over four days and obtained roughly 284 million patient-related data records. That figure should not be interpreted as 284 million affected patients. The attackers themselves clarified that it represents approximately 284 million database rows or records, and they reportedly do not yet know how many unique individuals those records represent.

That difference matters because raw database record counts can be enormously misleading. One person may appear across dozens or hundreds of rows associated with prescriptions, appointments, insurance records, medication shipments, invoices or clinical interactions. The number of records therefore cannot be translated directly into the number of individuals affected. A proper forensic investigation needs to deduplicate those records, identify unique individuals and determine which data fields were actually accessed before any reliable breach population can be established.

If the attackers’ account of the intrusion is accurate, the incident provides a textbook example of how identity compromise has replaced conventional network intrusion as one of the most effective routes into enterprise environments. ShinyHunters claims it used vishing, or voice phishing, to target multiple McKesson employees and then compromise their Okta single sign-on accounts. Instead of exploiting a sophisticated zero-day vulnerability in a server, the attackers allegedly convinced legitimate employees to help them cross the authentication boundary.

This attack model is increasingly attractive because enterprise cloud environments are built around identity. Once an attacker possesses a valid Okta session or employee authentication context, the perimeter becomes substantially less relevant. The attacker no longer needs to scan for exposed internal servers or establish traditional malware-based persistence immediately. They can interact directly with approved SaaS applications using credentials and sessions that appear legitimate.

That is why identity should now be viewed as part of the primary security perimeter. A successful login is no longer sufficient evidence that the activity following the login is trustworthy. Security systems need to evaluate the context of authentication, including device state, location, behavioral patterns, requested applications and unusual data-access activity.

The reported use of a domain resembling `mckesson.claims` is particularly instructive. ShinyHunters has been associated with campaigns that register domains using a company’s name or abbreviation followed by the `.claims` top-level domain and then use those domains to impersonate internal help desks or security teams. The technique is effective because victims may see a familiar company name embedded in the address and assume the site is legitimate.

This demonstrates how modern social engineering increasingly exploits organizational context rather than generic phishing templates. Attackers research the target, imitate support teams, reference internal processes and often interact with employees over the telephone in real time. A voice call can also bypass some of the psychological skepticism employees apply to email because the interaction feels more immediate and personal.

Traditional security awareness programs that repeatedly tell users not to click suspicious links are therefore increasingly inadequate. Employees need to understand that attackers may call them directly, know their company name, understand their identity provider and guide them through a convincing fake support procedure.

Organizations should establish strong help-desk verification procedures so employees can independently confirm whether a security or IT call is legitimate. Internal support teams should have clearly documented channels, and employees should be encouraged to terminate suspicious calls and contact support through independently known numbers or internal portals.

Phishing-resistant authentication becomes especially important against this attack model. Ordinary MFA based on push notifications, one-time passwords or SMS codes can still be defeated through real-time social engineering. Attackers can convince users to approve prompts or relay verification codes while the attacker is logging in simultaneously.

Passkeys and hardware-backed FIDO2 security keys are much more resistant because authentication is cryptographically bound to the legitimate domain. A user can be socially engineered into visiting a fake website, but the authenticator will not normally produce a valid response for the attacker’s domain.

That does not eliminate all identity risk, but it significantly raises the difficulty of the attack. Organizations operating high-value healthcare, financial or administrative systems should therefore move privileged and sensitive identities toward phishing-resistant authentication wherever practical.

The Okta aspect of the alleged attack also reinforces the importance of protecting the identity provider itself. An enterprise SSO platform is one of the highest-value systems in the organization because it provides access to many downstream applications. Compromise of one identity can therefore produce access to Salesforce, Snowflake, collaboration platforms and other SaaS systems without separate passwords.

Identity providers should receive security controls similar to domain controllers: strong authentication, restricted administrative access, comprehensive logging, device trust and continuous monitoring for unusual session activity.

Session theft and token abuse deserve particular attention. Resetting a user’s password may not terminate an attacker who already possesses a valid session token. Incident response therefore needs to include global session revocation, refresh-token invalidation, review of newly registered authentication factors and investigation of OAuth applications or other persistent authorization mechanisms.

The alleged movement from Okta into Salesforce and Snowflake is also a powerful example of how attackers exploit trusted SaaS relationships. Neither Salesforce nor Snowflake necessarily needs to contain a vulnerability. If the attacker authenticates using a legitimate enterprise identity with appropriate permissions, the platforms may simply perform exactly what they were configured to allow.

This changes the defensive question from “Was the software exploited?” to “Was a legitimate identity used in an illegitimate way?”

Salesforce environments frequently contain customer support cases, healthcare partner information, communications, contact details and workflow records. ShinyHunters claims it fully compromised McKesson’s Salesforce environment, including support cases, although McKesson has not independently confirmed this.

Support platforms can be extremely valuable to attackers because support records often contain far more context than administrators realize. Tickets may contain customer information, screenshots, troubleshooting data, internal contacts, system identifiers or sensitive documents attached during support interactions.

Large SaaS environments should therefore implement granular authorization rather than giving broad export or search capability to ordinary users. An employee who needs access to a subset of support cases should not necessarily be able to retrieve the complete organization-wide dataset.

Bulk export functionality should also be monitored closely. SaaS platforms make exporting data intentionally easy because legitimate businesses need analytics, backups and integration. The same functionality becomes extremely useful to attackers once they possess a valid account.

Security teams should alert when users suddenly retrieve data volumes far above their historical patterns, particularly when the activity originates from a new device, unfamiliar IP address or unusual time.

Snowflake represents an even more significant potential data source because cloud data warehouses frequently aggregate information from many operational systems. ShinyHunters claims the much larger patient-related dataset came from Snowflake. McKesson has not confirmed that claim, but the scenario illustrates why data warehouses have become high-value targets.

A data warehouse can concentrate records that were originally distributed across dozens of systems. From an attacker’s perspective, this is extremely efficient. Instead of compromising each clinical, logistics or billing application independently, the attacker may find a centralized analytical platform containing enormous volumes of replicated information.

This concentration creates what might be called analytical convenience for the business and criminal convenience for the attacker.

Data warehouses should therefore receive exceptionally strong identity and access controls. Analysts should have access only to datasets required for their role, privileged export rights should be restricted and service accounts should be scoped narrowly.

Queries involving unusually large result sets should generate alerts. An employee who normally analyzes a few million rows may legitimately perform large queries, so raw size alone is not sufficient. Security monitoring should combine query volume with identity, source location, time, historical behavior and data sensitivity.

Data classification is critical here. Security teams should know which Snowflake tables contain protected health information, personally identifiable information, employee information or other regulated data. Without classification, an organization may detect an unusual query without understanding that it touched highly sensitive information.

The attackers claim the stolen information includes names, physical addresses, dates of birth, Social Security numbers, patient IDs, telephone numbers, email addresses, Medicaid identifiers, medical record numbers, medication and allergy information, illnesses, disabilities, appointment information and physician information. They also claim the dataset contains records concerning deceased and terminally ill patients, prescriptions, medication shipments, invoices, employee information, internal communications and healthcare organizations using McKesson services.

Those claims are highly consequential but remain unverified. McKesson has not yet publicly disclosed which categories of information were stolen. Until the forensic investigation establishes the actual scope, responsible commentary should treat those fields as attacker claims rather than confirmed breach data.

If even a substantial portion of those categories is confirmed, however, the privacy consequences would be severe. Medical information is fundamentally different from ordinary credentials because it is persistent. A password can be changed. A credit card can be replaced. A medical diagnosis, disability, allergy or historical prescription cannot be rotated after a breach.

This permanence makes healthcare information especially valuable for targeted fraud, identity theft, extortion and highly personalized phishing.

Social Security numbers combined with dates of birth and addresses can support identity fraud. Medicaid numbers and medical record numbers may enable healthcare-related impersonation. Prescription and medication information can provide attackers with intimate context useful for social engineering.

A criminal calling a patient and correctly identifying their physician, medication or recent treatment may sound extraordinarily convincing. The victim may naturally assume only a legitimate healthcare provider could know those details.

That assumption is becoming increasingly unsafe after repeated healthcare breaches.

The alleged inclusion of terminally ill and deceased patients also raises unusually sensitive privacy concerns. Criminals do not necessarily stop targeting an identity because the individual has died. Information associated with deceased individuals can be used for fraud precisely because account monitoring may be weaker.

Family members can also become targets if attackers possess information about a patient’s illness, healthcare provider or treatment. Social engineering could exploit emotional urgency by impersonating medical facilities, insurers or pharmacies.

Healthcare organizations therefore need to prepare affected individuals not only for generic phishing but for highly contextual impersonation attempts.

The incident also demonstrates why customer and patient communication after a breach needs to be carefully designed. Attackers may exploit the public announcement by sending fake McKesson breach notices claiming that recipients need to verify their identity, enroll in protection services or confirm insurance information.

Customers should independently navigate to official resources rather than using unexpected links contained in emails or text messages.

Organizations should also avoid using communication patterns that resemble phishing themselves. A legitimate breach notification asking recipients to click an unfamiliar tracking link and enter sensitive information is a gift to attackers trying to imitate it.

The reported one-terabyte exfiltration over approximately four days raises important questions about network and SaaS telemetry. Moving that volume of data should generate substantial activity somewhere, although cloud-to-cloud extraction may not traverse the organization’s conventional network perimeter in the way traditional data theft would.

This is exactly why relying solely on firewall-based DLP is no longer sufficient.

When data moves directly from Snowflake or Salesforce to an attacker using legitimate SaaS APIs, the organization’s on-premises firewall may see little or none of the underlying transfer.

Cloud security monitoring needs direct visibility into SaaS audit logs, API calls, query activity and export operations.

Organizations should establish baseline behavior for data warehouse users and service accounts. A sudden increase in queries, exports, API calls or downloaded records can provide evidence of compromise even when authentication technically succeeds.

Rate limiting and adaptive access controls can also help. A compromised account attempting to retrieve enormous quantities of sensitive data should encounter additional friction rather than being allowed to extract everything simply because the account possesses broad read access.

This is where least privilege becomes crucial.

Employees rarely need permanent access to every patient record. Access should be constrained by role, geography, business unit, customer relationship or dataset depending on operational requirements.

Privileges should also expire when no longer needed. Temporary projects often result in users receiving additional access that remains years after the project ends.

Attackers benefit enormously from this privilege accumulation.

Regular entitlement reviews should therefore identify accounts with excessive access, unused roles and unnecessary data warehouse permissions.

Service accounts require similar scrutiny. Machine identities often possess broad permissions because applications need uninterrupted integration. These identities may also use long-lived secrets that are difficult to rotate.

Cloud environments should prefer short-lived workload identities over static credentials wherever supported.

Secrets should not be stored in scripts, configuration files or shared collaboration platforms.

If an identity-related compromise is suspected, administrators should review not just human accounts but OAuth tokens, API keys, service principals and integration accounts potentially accessible from the compromised environment.

The McKesson incident also provides another example of why SaaS logs need sufficient retention. If the attackers’ claim that data was extracted from August 21 through August 25 is correct, investigators need detailed historical records of authentication, queries and exports covering that entire period and potentially much earlier.

Initial compromise may have occurred before exfiltration began.

Short retention periods can make forensic reconstruction extremely difficult. SaaS platforms often provide limited default audit retention unless customers configure or purchase longer-term logging.

High-value organizations should export these logs into independent SIEM or security data platforms so historical analysis remains possible.

The investigation should attempt to determine the earliest abnormal identity event rather than focusing solely on the August 25 discovery date.

Investigators should examine suspicious help-desk interactions, Okta authentication, MFA changes, device registrations, session creation, Salesforce activity, Snowflake query history and data export behavior.

The timeline needs to identify when attackers first obtained credentials and whether access persisted continuously or through multiple compromised employee accounts.

The claim that multiple employee Okta accounts were compromised is particularly concerning because it may indicate a coordinated social-engineering campaign rather than a single unlucky employee.

Multiple compromised accounts create resilience for attackers. Disabling one user may not end the intrusion if other identities remain under attacker control.

Security teams should therefore search for patterns across users rather than treating each suspicious authentication as an isolated incident.

The use of similar phishing domains, source IP addresses, user agents or authentication changes may reveal additional compromised accounts.

This is also where identity threat detection and response becomes important.

Traditional SIEM rules often alert on impossible travel or excessive failed logins. Social engineering attacks using valid sessions may not produce those classic indicators.

Defenders need behavioral analytics capable of identifying changes in the way authenticated users interact with applications after login.

For example, an employee who normally uses Salesforce interactively through a browser may suddenly begin making large API-based exports from an unfamiliar environment.

That change is more meaningful than the fact that the login succeeded.

Endpoint investigation remains relevant as well. If employees entered credentials into attacker-controlled pages, their systems may not necessarily contain malware. However, investigators should still determine whether information-stealing malware, malicious browser extensions or other endpoint compromise contributed to the incident.

A user may be both phished and infected.

If browser session cookies or tokens were stolen directly from the endpoint, password resets alone may not fully remediate the problem.

Managed browser controls can help reduce some of this risk. Enterprises increasingly access SaaS systems through browsers, making browser extensions, session storage and local token protection part of the identity security model.

Unauthorized browser extensions should be restricted, and sensitive applications should require managed devices where practical.

The reported ransom demand is also noteworthy. ShinyHunters claims it demanded $55,236,150 and provided McKesson with 72 hours to respond. McKesson has not confirmed the ransom demand, and the attackers claim the company did not negotiate.

This illustrates the economics of modern data extortion.

There is no need to encrypt the victim’s infrastructure if the attacker believes stolen information creates enough pressure on its own.

Large healthcare datasets can provide extraordinary leverage because organizations face privacy obligations, reputational harm, potential lawsuits and concern for affected patients.

Backups therefore offer little protection against this kind of extortion.

An organization can restore every server perfectly and still face the same problem if the attacker retains a copy of the data.

Cyber resilience must therefore address data exfiltration as seriously as ransomware encryption.

This means monitoring bulk transfers, controlling SaaS exports, restricting API permissions, classifying sensitive information and maintaining rapid identity containment.

The healthcare sector is especially exposed because data needs to move between many organizations. Pharmaceutical distributors, hospitals, pharmacies, insurers, clinics, logistics providers and health technology platforms all exchange information.

Every integration creates another trust relationship and another potential identity pathway.

McKesson’s position within pharmaceutical distribution makes the incident particularly significant because it interacts with a huge ecosystem of providers and pharmacies. Compromise of information associated with customers and healthcare partners could potentially create secondary social-engineering opportunities even if those organizations were not technically breached themselves.

Attackers could impersonate McKesson in communications with clinics, pharmacies or suppliers using information stolen from support records.

Business partners should therefore be alert to unusual requests involving credentials, payments, account changes or technical support.

Organizations should verify sensitive requests through established channels rather than trusting email simply because it contains accurate account or relationship information.

The incident also demonstrates the problem with relying on known personal information for identity verification.

If attackers obtain dates of birth, addresses, patient IDs or other personal attributes, those details can no longer be considered secrets.

Customer service and healthcare verification processes should increasingly avoid knowledge-based authentication for high-risk actions.

Possession-based and cryptographic verification provide substantially stronger assurance.

Another lesson concerns cloud concentration risk. Salesforce and Snowflake are extremely powerful platforms because organizations can centralize workflows and data. But centralization increases the value of each privileged identity.

A single compromised SaaS account may expose information that previously required access to multiple separate systems.

Security teams should therefore classify major SaaS platforms as critical infrastructure within the enterprise, not merely business applications operated by someone else.

Cloud providers secure the platform infrastructure, but customers remain responsible for how their identities and data permissions are configured.

The absence of a software vulnerability does not mean the cloud service cannot be breached from the customer’s perspective.

If attackers authenticate successfully with stolen credentials, the cloud platform may function perfectly while the customer experiences a catastrophic data breach.

This is one of the central misunderstandings around SaaS security.

Cloud security is not simply patch management performed by the vendor. It is identity, authorization, data governance and monitoring performed jointly by vendor and customer.

The alleged McKesson attack makes that distinction extremely clear.

The incident should also prompt organizations to examine help-desk workflows.

Attackers increasingly impersonate employees to request password resets, MFA changes or account recovery.

Support personnel need strong methods for verifying callers that do not rely solely on information attackers can discover publicly.

High-risk identity changes should trigger separate verification or managerial approval.

Help desks should also be able to flag suspicious calls immediately so security teams can investigate similar attempts against other employees.

A single reported vishing call may be evidence of a campaign targeting dozens of people.

Rapid internal communication can therefore prevent attackers from repeating the same technique successfully.

Employees should know where to report suspicious calls and should not fear disciplinary consequences for reporting that they may have been deceived.

Speed matters more than embarrassment.

If a user tells security immediately that they entered credentials into a suspicious site, the organization may revoke sessions before attackers have time to extract large datasets.

If the user stays silent for several hours because they are worried about being blamed, the attacker receives a very useful head start.

Security culture therefore directly influences technical incident response.

The potential intermittent service degradation mentioned by McKesson is another important aspect. The company says customers may experience intermittent service issues related to the incident, although it stated it was not proactively disconnecting systems within its environment.

This suggests the incident has at least some operational consequences even though McKesson has not currently determined that it is materially affecting the company financially.

Cyber incidents can produce degradation for several reasons. Security teams may restrict functionality, authentication systems may be adjusted, cloud integrations may be temporarily constrained or investigation activity may affect service performance.

Organizations should design business-continuity plans around the possibility that SaaS applications or integrations become unavailable during incident response.

The absence of full shutdown does not mean operations remain completely unaffected.

For a healthcare distribution organization, continuity is particularly important because delays can influence pharmacy and provider operations downstream.

Again, there is no public evidence that patient care has been disrupted, so such consequences should not be assumed.

The broader architectural lesson is that one compromised employee identity should not provide broad access to high-value enterprise datasets.

Strong authentication should prevent many account compromises.

Least privilege should limit what compromised identities can reach.

Behavioral monitoring should identify abnormal data access.

Rate limits and step-up authentication should make bulk extraction harder.

Centralized SaaS logging should allow rapid investigation.

And automated response should revoke suspicious sessions before attackers have several uninterrupted days to exfiltrate information.

Those controls form layers.

Any one of them may fail.

The objective is to prevent failure of one employee authentication event from becoming theft of an entire enterprise data warehouse.

The attackers’ claim that roughly one terabyte of information was transferred over four days, if confirmed, would suggest a significant window existed between initial compromise and containment.

That timeline should encourage organizations to measure Mean Time to Detect identity misuse, not just malware.

Traditional endpoint security may proudly report that no virus was found while a legitimate employee identity exports millions of records from cloud applications.

That is not a successful security outcome.

Security operations need telemetry that follows identities across systems.

A suspicious Okta login should be correlated with Salesforce activity, Snowflake queries and unusual data transfers.

When those events are examined separately, each may appear plausible.

Together, they may clearly describe an attack.

This is why integrated identity, endpoint and cloud detection is becoming essential.

The McKesson incident also arrives amid a wider series of ShinyHunters attacks against healthcare and health technology organizations. Health-ISAC has already warned members about increasing social-engineering campaigns targeting corporate identities and cloud applications.

That trend suggests defenders should pay attention to attacker technique rather than only to individual victims.

Blocking one malicious domain is useful, but attackers can register another domain immediately.

Training employees to recognize company-name-plus-`.claims` domains helps temporarily, but attackers can switch top-level domains.

The durable control is strong verification of help-desk interactions combined with phishing-resistant authentication and behavioral detection after login.

Threat intelligence should therefore focus on patterns of behavior rather than static indicators alone.

Static indicators expire.

Technique lasts longer.

Another useful lesson is that extortion-group claims need independent verification.

ShinyHunters has provided detailed allegations about McKesson’s Salesforce and Snowflake data, but BleepingComputer explicitly notes that it has not independently verified these claims and McKesson has not publicly confirmed them.

Attackers have incentives to exaggerate data volume, sensitivity and victim count because larger numbers create greater pressure.

Security commentary should therefore remain precise.

“Attackers claim 284 million patient-related records” is accurate.

“284 million patients were breached” is not.

Likewise, “the attackers claim Social Security numbers and medical information were stolen” should remain distinguished from “McKesson confirmed those fields were stolen.”

Forensic accuracy matters, particularly in healthcare where incorrect reporting can create unnecessary fear among patients.

The eventual notification process will need to identify exactly which individuals were affected and which categories of information were involved.

Until that occurs, patients and partners should remain alert without assuming every McKesson-associated record has been compromised.

For potentially affected individuals, phishing is the immediate practical risk.

Messages referencing prescriptions, medication deliveries, appointments, Medicaid information or healthcare providers could become significantly more convincing if the attackers’ claims about the data are correct.

People should be cautious of unexpected communications asking for payment details, Social Security numbers, passwords or authentication codes.

Legitimate organizations should not unexpectedly ask patients to reveal sensitive credentials merely because a cybersecurity incident occurred.

If Social Security numbers are eventually confirmed as exposed, affected individuals may also need to monitor credit activity and identity fraud according to McKesson’s eventual notification guidance.

The most important lesson for enterprises, however, is not specific to McKesson.

Modern attackers increasingly bypass the infrastructure layer entirely.

They target people.

They compromise identities.

They authenticate normally.

Then they use the same SaaS platforms employees use every day to extract information.

Nothing has to explode.

No ransomware note has to appear.

No antivirus alert has to trigger.

From the cloud application's perspective, a user may simply be downloading data they are authorized to read.

That makes identity-centric attacks one of the hardest categories to detect.

The solution is not to distrust every employee action, but to continuously evaluate whether the behavior makes sense for that identity, device and role.

Authentication should begin the security decision, not end it.

The McKesson incident ultimately demonstrates why Zero Trust needs to extend beyond network access.

A valid Okta session should not automatically provide unlimited trust in Salesforce.

A valid Salesforce account should not automatically permit unrestricted bulk exports.

A valid Snowflake identity should not automatically retrieve hundreds of millions of rows without additional scrutiny.

Every layer should independently apply least privilege and behavioral context.

That is what limits blast radius when the identity layer fails.

The broader takeaway from the reported McKesson breach is therefore not merely that a healthcare giant may have lost a vast amount of patient-related data.

The more important lesson is how little conventional hacking may have been required if the attackers’ account proves accurate.

A telephone conversation, a convincing fake identity page and several compromised employee accounts may have been enough to reach some of the most valuable data platforms in the organization.

That should concern every enterprise that has invested heavily in cloud migration but still treats social engineering as primarily an employee-awareness problem.

Identity compromise is now infrastructure compromise.

Once employees’ authentication sessions become keys to Salesforce, Snowflake, Microsoft 365, AWS and dozens of other SaaS services, protecting those sessions becomes just as important as protecting servers.

The McKesson incident should therefore be studied not simply as another healthcare data breach but as an example of the new enterprise attack chain:

social engineering leads to identity compromise, identity compromise leads to trusted SaaS access, trusted SaaS access leads to bulk data extraction, and bulk data extraction becomes extortion.

No malware is required at several of those stages.

That is precisely why the attack is so effective.

And it is why modern cybersecurity needs to become much better at answering a deceptively simple question after every successful login:

Does this authenticated user actually behave like the person we intended to authenticate?

Healthcare and pharmaceutical distribution giant McKesson has disclosed a cybersecurity incident involving unauthorized access to third-party applications and data theft, with the ShinyHunters extortion group claiming it stole 284 million patient data records. [...]

Source: McKesson discloses breach after ShinyHunters claims patient data theft via Bleeping Computer — published 28 Aug 2026.