McKesson-Breach: So lief der Okta Vishing-Angriff ab

Ein Okta Vishing-Angriff — ein Telefonanruf, keine Schadsoftware — ist laut der Erpressergruppe ShinyHunters der Weg, auf dem sie in den US-amerikanischen Gesundheits- und Pharma-Distributionsriesen McKesson eingedrungen sein will. McKesson hat unbefugten Zugriff auf Drittanwendungen und einen Datenabfluss bestätigt, den eigentlichen Angriffsweg jedoch nicht bestätigt: Laut ShinyHunters‘ eigener Darstellung wurden Mitarbeitende angerufen, die Anrufer gaben sich als IT-Support aus und brachten sie dazu, Zugangsdaten preiszugeben oder betrügerische Single-Sign-On-Anfragen zu genehmigen — von dort aus sei die Gruppe eigenen Angaben zufolge direkt in McKessons Salesforce- und Snowflake-Umgebungen gelangt.

Was ist passiert

ShinyHunters gibt an, Vishing-Anrufe gegen mehrere McKesson-Mitarbeitende durchgeführt zu haben, um entweder direkt Zugangsdaten zu erlangen oder Mitarbeitende dazu zu bringen, betrügerische Okta-Single-Sign-On-Zugriffsanfragen zu genehmigen. Von dort aus habe die Gruppe eigenen Angaben zufolge McKessons Salesforce-Umgebung vollständig kompromittiert, einschließlich interner Support-Fälle, und über vier Tage hinweg — zwischen dem 21. und 25. August 2026 — rund 1 TB Daten aus der verbundenen Snowflake-Data-Warehouse-Umgebung exfiltriert; diesen genauen Ablauf hat McKesson nicht unabhängig bestätigt. Die Gruppe behauptet zudem, etwa 284 Millionen Datensätze erbeutet zu haben — vermutlich eher eine Zahl von Datenbankzeilen als eindeutigen Patienten — und beschreibt die Daten als Informationen zu verstorbenen und unheilbar kranken Patienten, Rezept- und Medikamentenversanddaten, Abrechnungsdaten, Mitarbeiterdaten, interne Salesforce-Kommunikation sowie Details zu Anbietern und Kliniken, die McKessons Dienste nutzen. Keine dieser Zahlen oder Datenkategorien ist über die Behauptungen von ShinyHunters und die Sekundärberichterstattung hinaus unabhängig bestätigt.

ShinyHunters behauptet, von McKesson 55.236.150 US-Dollar mit einer 72-Stunden-Frist zur Antwort gefordert zu haben; McKesson hat diese Summe, Verhandlungen oder eine Zahlung nicht bestätigt. McKessons eigene Offenlegung beschreibt den Vorfall als unbefugten Zugriff auf Drittanwendungen und Datenabfluss, betroffen sei ein Teil der Kunden in den Geschäftsbereichen Oncology & Multispecialty und Medical-Surgical. Der CTO von McKesson erklärte zudem, Kunden könnten zeitweise Serviceeinschränkungen erleben, die vermutlich mit dem Vorfall zusammenhängen — ein Handeln seitens der Kunden sei laut Unternehmen aber nicht erforderlich. Hinweise auf eine Ransomware-Verschlüsselung liegen in den ausgewerteten Quellen nicht vor, was zu einem reinen Datendiebstahl-Erpressungsfall passt und nicht zu einem klassischen Ransomware-Vorfall mit gesperrten Systemen.

Warum das wichtig ist

Dieser Okta Vishing-Angriff ist der zweite 2026er Fall, den DIESEC verfolgt hat, bei dem ein Angreifer Identitätskontrollen per Telefonanruf statt per Code aushebelt — nach der STAC4749-Kampagne vom 4. August, die über Microsoft-Teams-Impersonation innerhalb von 17 Stunden Chaos-Ransomware auslieferte. Beide Fälle nutzen dieselbe zugrunde liegende Annahme aus: dass eine Login-Genehmigungsanfrage oder ein Zugangs-Reset, der über einen vertraut wirkenden internen Kanal eintrifft, von jemandem, der wie ein Kollege oder der IT-Support klingt, unbedenklich ist. Für jede DACH-Mittelstandsorganisation, die Okta, Salesforce oder Snowflake einsetzt — eine zunehmend gängige Kombination —, ist der McKesson-Vorfall eine direkte Vorschau darauf, wie eine erfolgreiche Social-Engineering-Kampagne gegen den eigenen Helpdesk und SSO-Anbieter von Anfang bis Ende aussieht.

Was Sie jetzt tun sollten

1. Stellen Sie Okta (oder jeden anderen SSO-Anbieter) wo administrativ möglich von Push-Genehmigungs-MFA auf phishing-resistente, Number-Matching- oder FIDO2-Hardware-Key-Authentifizierung um.
2. Führen Sie eine verpflichtende Rückruf-Verifizierung über eine bekannte interne Telefonnummer ein, bevor auf eine vom „IT-Support“ initiierte Zugangsdaten-Zurücksetzung oder Zugriffsgenehmigung reagiert wird — vertrauen Sie niemals der vom Anrufer angegebenen Nummer oder Identität.
3. Richten Sie Anomalie-Alarmierung für neue Geräteregistrierungen oder Sitzungsfreigaben im zeitlichen Umfeld von Helpdesk-Kontakten ein, ebenso für ungewöhnliche Massen-Datenabzüge aus Salesforce oder Snowflake kurz nach Aufbau einer SSO-Sitzung.
4. Überprüfen Sie Ihren Incident-Response-Plan auf Vishing-spezifische Szenarien — die meisten Tabletop-Übungen gehen noch immer von einem technischen Exploit als initialem Zugriffsvektor aus, nicht von einem Telefonanruf.

DIESEC Einschätzung

Nach Darstellung von ShinyHunters hat jede technische Kontrolle in dieser Geschichte wie vorgesehen funktioniert — Okta authentifizierte die Sitzung, Salesforce und Snowflake gewährten einer authentifizierten Identität Zugriff. Das Versagen lag in den Verfahren zur menschlichen Verifizierung und in den Identitäts-Workflows, nicht in einer technischen Schwachstelle — und es ist genau die Art von Versagen, die kein Patch, kein CVE-Fix und kein Software-Update jemals schließen wird. Das knüpft auch an die Zahlen-oder-nicht-Entscheidung an, die DIESEC in unserem Beitrag vom 20. Mai zu Grafana und Instructure behandelt hat — das Erpressungs-Ökosystem rund um Marken wie ShinyHunters ist inzwischen eine Governance-Frage, auf die jede Organisation eine im Voraus abgestimmte Antwort braucht, bevor die 72-Stunden-Uhr zu laufen beginnt.

Nicht sicher, ob Ihre Helpdesk- und SSO-Genehmigungsprozesse einem gezielten Vishing-Versuch standhalten würden? Kontaktieren Sie DIESEC für eine schnelle Social-Engineering-Expositionsprüfung Ihrer Identitäts- und Zugriffsprozesse.

Quellen: McKesson SEC-8-K-Offenlegung | BleepingComputer | Cybernews
Veröffentlicht: 2026-09-02 | Kategorie: Tägliche News | ~4 Min. Lesezeit