Field Notes · Incident Command September 2, 2026 · 6 min read

No malware, no exploit: the breach that starts at the helpdesk.

McKesson's Form 8-K describes an incident with no exploit and no malware. Per the reporting, the access chain was a phone call, a lookalike IT domain, and a handful of Okta accounts that opened Salesforce and Snowflake. If your identity evidence cannot reconstruct that chain, your materiality answer is a guess.

Update. Updated 2026-09-02. This note reacts to public reporting by BleepingComputer on 2026-08-28 and to McKesson's Form 8-K. I have not worked this incident.

How a vishing call becomes a breach

According to BleepingComputer, ShinyHunters phoned multiple McKesson employees while posing as IT and helpdesk staff behind a registered lookalike domain, and used those calls to take over multiple Okta single sign-on accounts.

Those accounts were enough to reach Salesforce and Snowflake, and the actor claims about 1 TB and roughly 284 million database records left over four days, from 2026-08-21 to 2026-08-25.

No exploit and no malware were reported, which means the entire intrusion lives in identity and SaaS logs, and those are the records a buyer has to be able to produce on demand.

The identity evidence to demand

Everything in this intrusion, as reported, is an identity event. A person answered a call. A person believed the caller was IT. An Okta account did something it had never done before. Salesforce and Snowflake served queries to a session that looked authenticated because it was. None of that produces an alert from an endpoint agent, because there is no endpoint story to tell.

So when a board or general counsel asks what happened, the answer has to be assembled from identity and SaaS records, and the first question I put to any team is whether those records exist at the depth needed. The list is short and none of it is optional.

Helpdesk ticket and call records for every password reset, MFA re-enrollment, or device registration in the window, with the verification step the agent performed written down.
Identity provider logs at the event level: sign-ins, factor enrollments, session creation, application assignments, and admin changes, tied to source IP and device.
SaaS-side history. For Salesforce that means login and API access history. For Snowflake it means query history and login history, so you can see which tables were read and how many rows came back.
Egress and volume. Something moved about 1 TB over four days, per the actor's claim. Your network or cloud telemetry either shows that or it does not.
Domain and mail telemetry showing when the lookalike domain first touched your environment.

If any one of those is missing, the timeline has a hole, and the hole is where the materiality argument goes to die.

The materiality clock started on 2026-08-25

McKesson's 8-K of 2026-08-28 says, quote, "the company has not determined that the incident is material or that the incident has had, or is reasonably likely to have, any material impact on the company." That is a lawful and reasonable statement three days after discovery. It is also a snapshot, and every fact that could move it was still in motion when it was filed.

Put the two calendars side by side. The actor claims exfiltration ran from 2026-08-21 to 2026-08-25. McKesson says it discovered the incident on 2026-08-25. If the claim is accurate, the company's clock started on the last day of the actor's clock, and the disclosure was written before anyone could have fully verified what left. The actor also claims roughly 284 million database records, which are raw rows and not unique people, and a demand of 55,236,150 dollars on a 72-hour deadline that, per the actor, went unanswered.

Here is what I tell counsel. A "not material" determination is only as durable as the evidence beneath it. It reverses when the row count becomes a person count, when the affected tables turn out to hold regulated data, when a customer notice obligation crystallizes, or when the actor publishes. Every one of those triggers depends on records you either have or do not. If your Snowflake query history was not retained, you cannot argue the rows were duplicates. If your Okta logs do not show session origin, you cannot bound the actor's access to the accounts you already know about.

The job for counsel in the first 72 hours is not to decide materiality. It is to make sure the evidence that will decide it is preserved before it ages out, and to know exactly which facts would flip the determination so that nobody is surprised when one of them lands.

What to check before the phone rings

This campaign, as reported, is part of a long-running series of intrusions against Salesforce and Snowflake environments. A separate 2026 case, Dropbox via a Lenovo single sign-on email-verification trust failure, shows the same shape: federated identity trusted a step it should not have. The pattern is stable, which means the preparation is knowable.

Four checks. Each takes about a day and none requires a product purchase.

Helpdesk reset verification. Pull the last 90 days of password and MFA resets and read the tickets. If the verification method is not written on the ticket, you cannot prove the requester was the employee. Fix the procedure before you fix the tooling.
Identity provider logging. Confirm your Okta or equivalent is exporting full system logs to storage you control, with retention measured in months. Confirm you can answer, for any account, which factors were enrolled and when.
SaaS query and login history. Run one test. Pick an account and ask your team to produce every Snowflake query and every Salesforce login it made last week. Time how long that takes. That is your incident response speed.
Egress baseline. You cannot see 1 TB leaving if you do not know what a normal week looks like. Establish the baseline for your data platforms now so that a four-day anomaly is visible on day one, not day four.

None of this is exotic. It is the difference between telling a regulator what happened and telling them what you think happened.

Questions people ask

What is a vishing helpdesk attack?

Vishing is voice phishing. In the McKesson case, as reported, ShinyHunters called multiple employees while impersonating IT or helpdesk staff from a lookalike domain, and used those calls to take over Okta single sign-on accounts. No software vulnerability was involved. The weakness was the verification step between a caller and a reset.

Did the McKesson breach use malware?

No malware and no exploit were reported. According to BleepingComputer, the actor gained access through phone-based social engineering and compromised Okta accounts, then used that access to reach Salesforce and Snowflake. The evidence of the intrusion lives in identity and SaaS logs rather than on endpoints.

How much data did ShinyHunters claim from McKesson?

The actor claimed roughly 284 million database records, which are raw rows rather than unique people, and about 1 TB exfiltrated over four days from 2026-08-21 to 2026-08-25. The demand was 55,236,150 dollars with a 72-hour deadline. McKesson did not respond, according to the actor.

If you cannot prove today whether every helpdesk password or MFA reset in the last 90 days went to a verified requester, an independent incident response and forensics engagement starts by pulling that evidence.