A Decade of Nearly Identical Breaches: The Endpoint Nobody's Watching

TL;DR

• McKesson disclosed a cybersecurity incident on August 25, 2026, affecting its Oncology & Multispecialty and Medical-Surgical units. ShinyHunters claims 284 million records, a terabyte of data, vishing of employees, and compromised Okta SSO access to Salesforce and Snowflake, none of which McKesson has confirmed.

• The shape of the attack (a phone call or a stolen credential, not malware) has already hit Google, Qantas, Allianz Life, M&S, Co-op, Harrods, and LVMH in the past 18 months alone.

• Pull back further, and at least three separate threat actors (LAPSUS$ in 2022, the group behind Change Healthcare in 2024, and the Snowflake campaign the same year) ran the identical playbook against completely different industries.

• The entry point is consistently social engineering and a person's access, such as a help desk agent, a support rep, or a credential with no second factor, not an executive and not a system vulnerability.

• Mobile is where most of that access lives (MFA prompts, corporate email, SSO sessions), and it's still treated as a training problem instead of making it a monitored endpoint.

A Breach You've Seen Before, Just With a Different Name

On August 25, 2026, McKesson confirmed a cybersecurity incident affecting a subset of customers in its Oncology & Multispecialty and Medical-Surgical business units, involving unauthorized access to third-party applications. That's all McKesson has confirmed; the company hasn't quantified the scope beyond that. What ShinyHunters claims is a much bigger story: 284 million patient records and roughly a terabyte of data, taken between August 21 and 25 by voice-phishing (vishing) McKesson employees and using compromised Okta single sign-on accounts to reach the company's Salesforce and Snowflake environments, backed by a $55 million extortion demand (SecurityWeek; CyberInsider; Malwarebytes). McKesson's investigation is still open, and none of those specifics have been independently verified.

The record count matters less than the method. Strip away the claimed numbers and what's left is a shape security teams have seen before: a phone call or a stolen password that walked straight past every control built for a laptop, no zero-day or custom malware required. MGM Resorts learned this in 2023, when a help-desk social engineering call from Scattered Spider took down casino floors across Las Vegas, a pattern iVerify has covered in depth in its Scattered Spider threat profile. McKesson is simply the newest name in a list that's been growing for years, and every name on it traces back to the same two things: a person who can be talked into something, and the phone in their pocket, which gets less security scrutiny than almost anything else they touch at work.

Health-ISAC Confirms the Mechanism

Three days after McKesson's disclosure, Health-ISAC, the information-sharing organization for the healthcare and public health sector, issued an industry-wide threat bulletin confirming that ShinyHunters is running an active vishing campaign built specifically for healthcare targets. The bulletin never mentions McKesson by name, but the mechanism it describes matches the claims against McKesson almost exactly, and Health-ISAC is explicit about where these calls land. Attackers are "reaching employees directly on personal mobile devices via calls and voicemails," not enterprise-managed lines. That's independent confirmation, drawn from member incident reports rather than an attacker's own extortion demand.

Different Industries, Same Front Door

Whatever McKesson's investigation eventually confirms, the method behind it already has a paper trail that doesn't depend on it. In the sixteen months before McKesson's disclosure, a phone call or a social-engineered login reaching a connected SaaS platform produced confirmed breaches, not claims, at a technology company, an airline, an insurer, a retail group, and a luxury conglomerate.

Tech: Google confirmed a breach of one corporate Salesforce instance after the group it tracks as UNC6040 vished an employee into authorizing a fake connected app disguised as Salesforce's own Data Loader tool, the same "grant this app access" flow used to legitimately connect approved integrations.

Travel: Qantas confirmed 5.7 million customers affected after a threat actor targeted a call center and reached a third-party customer servicing platform.

Insurance: Allianz Life confirmed that 1,497,036 people were affected after a social-engineering attack against a third-party Salesforce CRM instance.

Retail: Marks & Spencer, Co-op, and Harrods were classified as a single combined cyber event with a financial impact estimated at £270–440 million. M&S itself attributed the attack to the DragonForce ransomware group "working with other loosely affiliated actors." 

Luxury goods: Louis Vuitton, Dior, and Tiffany & Co. each confirmed unauthorized access to a customer database through a third-party vendor platform.

Healthcare: Baxter International, the closest parallel to McKesson, disclosed unauthorized activity in "certain third-party applications" in August 2026. ShinyHunters claims 7.1 million Salesforce records; Baxter has confirmed neither the platform nor the number.

None of this is really an industry story. Casinos, airlines, insurers, retailers, and drug distributors have almost nothing in common operationally. What they share is where an employee's access lives.

Why Mobile Is the Entry Point

The average enterprise employee's phone carries authentication tokens, password manager access, MFA apps, corporate email, and live sessions into cloud systems like Salesforce and Snowflake. For most of the workforce, mobile is the primary identity surface: the thing that approves the login, receives the one-time code, and holds the session that everything else is built to trust, well ahead of the laptop it shadows. 

That shift mirrors a broader one already underway across the web: mobile devices now account for roughly half of all traffic worldwide, essentially at parity with desktop (Statcounter, August 2026).

An attacker who wants into a Salesforce instance can skip Salesforce entirely and spend a few minutes on the phone with an employee who has access to it instead, which is precisely what UNC6040 did to Google and what ShinyHunters claims to have done to McKesson.

That also explains why the entry point in incident after incident is a call or a text rather than a code exploit. A vished help desk agent or a smished support rep is a person, on a device built for convenience and constant availability, being talked past whatever access they're trusted with, rather than a security control failing to patch a vulnerability. The device is typically used exactly as designed, by someone it has no way of recognizing as an attacker: approving a connected app or reading back a verification code is normal phone behavior, right up until the person asking turns out to be a stranger.

Mobile is also where multi-factor authentication itself lives, which is what makes phone-based social engineering so effective against a control that's supposed to stop credential theft. SIM swapping, in particular, targets MFA directly: an attacker convinces or bribes a carrier into porting a victim's phone number to a device they control, and every SMS-based one-time code that number was supposed to protect now arrives in the attacker's pocket instead. None of the incidents cited above have been confirmed as SIM swap attacks specifically. Still, the technique falls into the same category as vishing and smishing: identity-layer fraud conducted through the phone, not the browser, and largely invisible to security tools built to watch laptops and email.

The 2026 Verizon Data Breach Investigations Report backs this up, and it also shows why the industry has been slow to catch on. The DBIR splits social engineering into two categories: phishing, an email lure someone reads on their own time, and pretexting, a live phone call or text where someone impersonates a trusted contact in real time. Voice phishing succeeds at a 40% higher rate than email, with a 2% median click rate versus 1.4% for email. Voice and text-based attacks now account for 41% of social engineering breaches overall (Verizon DBIR 2026, via Push Security's review).

What the report doesn't track is which device the target was using, partly because a large number of organizations still have no idea whether their vishing exposure sits on a managed laptop or an employee's personal phone.

Why the Same Move Keeps Working

Security budgets still flow overwhelmingly toward laptop and server EDR, for the understandable reason that this is historically where malware executed and ransomware detonated. Phishing training treats "phishing" as an email problem, built around habits like checking sender domains and hovering over links. None of that muscle memory transfers to a live phone call from someone who already knows an employee's name, their manager's name, and the exact software their help desk uses, which is the profile of vishing calls behind several of the confirmed incidents above.

MDM compliance gets mistaken for mobile security coverage, and that's the more persistent myth. MDM and legacy Mobile Threat Defense tools operate above the operating system: they talk to device management APIs, check configuration state, scan installed apps, and inspect network traffic. That's genuinely useful for compliance reporting and remote wipe, but it stops well short of visibility into what's actually happening on the device. Neither tool observes process-level behavior in real time, which means neither can tell the difference between a phone that's compliant on paper and the same phone mid-attack, where an employee has just approved a fraudulent MFA push or read a one-time code to someone posing as IT. The compliance check and the compromise can both be true on the same device at the same moment, and only one of them shows up in an MDM dashboard.

Training Has a Ceiling

Every incident in this piece started with someone doing their job: a help desk agent taking a call, a support rep verifying an identity, an employee approving what looked like a routine app request. None of them were careless in a way a training program could have flagged in advance. That's the uncomfortable part of vishing and smishing as techniques: they're built around exploiting normal, reasonable behavior, and a good enough pretext beats vigilance often enough that no security program gets the failure rate to zero. Attackers only need one success. Defenders need all of them to hold.

Training remains worth running, but it caps out well short of solving this, because the constant across every incident above is a person, and a person can be talked past their own judgment by someone who's done enough homework. Once that's true, the practical goal shifts: from making employees immune to a good pretext, which no organization has managed, toward shortening the distance between an attempt succeeding and a security team knowing about it. Speed becomes the control that matters once prevention has already failed. That's the actual premise behind detection and response as a category: acting on the attacks that get through before they turn into something the size of McKesson.

It's Not Just the C-Suite

It’s also time to reframe who's actually being targeted, because in nearly every confirmed incident above, the entry point was a help desk agent, a support rep, or a third-party contractor, not an executive. Attackers target standing access, not job titles, and most of the workforce has some form of it. iVerify has covered the help-desk and SIM-swap version of this pattern in detail in The Attack Surface in Your Pocket.

If resourcing is limited, prioritizing executives plus help desk, IT, and admin roles is a defensible place to start. But stopping there just rebuilds the same gap one tier down, at whichever role has access next. It also runs into a structural problem: many of the highest-risk roles in this list – contractors, support reps, and help desk staff – are exactly the roles most likely to be working from a personal device that no enterprise MDM policy ever touched in the first place.

What Actually Closes the Gap

Closing that gap isn't a matter of a stricter MDM policy either, because management tools sit above the layer where these attacks actually happen, the same as training does. MDM and legacy mobile threat defense can confirm a phone is encrypted, passcode-enforced, and running an approved OS version. Neither can confirm whether that same phone just approved a fraudulent MFA push, had its SIM silently ported to an attacker's device, or is mid-conversation with someone posing as IT support.

Closing that gap takes kernel-adjacent telemetry: continuous, device-level visibility into what's actually happening during an attack, not a point-in-time snapshot of policy compliance. Speed is the point in the sense described above: the value isn't in making the pretext fail, it's in how fast something on the device notices once the pretext has already worked. In practice, that looks like a small set of specific capabilities matched to the channels these incidents keep using. SmishGuard, iVerify's on-device detection for smishing and vishing, flags malicious links and suspicious message patterns before an employee acts. SIM swap detection alerts a security team the moment a number is ported to a new device, the exact mechanism that lets an attacker intercept SMS-based MFA codes without ever touching the victim's phone. And continuous device-level analysis can tell the difference between a phone that's merely policy-compliant and one that's actively being used as the entry point into a Salesforce or Snowflake environment, in near real time rather than at the next compliance check.

To be precise about scope, this argument stops at initial access: mobile EDR wouldn't have stopped a Salesforce or Snowflake data exfiltration once attackers were already inside those platforms. What it addresses is the step before that, present in nearly every breach above: a voice call, a text message, or a credential handed over with no working second factor, on a channel most enterprise security stacks were never built to watch.

How Many Breaches Will it Take?

Google, Qantas, Allianz Life, M&S, Co-op, Harrods, LVMH, and now McKesson and, days earlier, Baxter: different sectors, different years, in some cases entirely different attackers, all of them walking through the same door. At some point the volume itself becomes the argument: how many more names does this take before mobile identity gets treated as the Tier-1 endpoint it already is?

Summary Table: Confirmed vs. Claimed

The pattern across every incident above, condensed:

None of this requires a new threat actor to keep happening. It just requires enterprises to keep leaving the same door unwatched: a decade of unconnected groups have already found it independently. If you want a clearer picture of how exposed your mobile fleet is to this exact playbook, it's worth finding out before the next name on this list is yours. Book a demo with iVerify to see exactly where your fleet stands.