ShinyHunters contre McKesson : 284 millions d'enregistrements patients volés en quatre jours de vishing

Rapport CTI technique du 30 août 2026

Résumé exécutif

McKesson Corporation, géant américain de la distribution pharmaceutique, a confirmé le 25 août 2026 une intrusion après que le groupe d'extorsion ShinyHunters a revendiqué le vol d'environ 284 millions d'enregistrements liés à des patients. Les données annoncées comme volées incluent noms complets, adresses, dates de naissance, numéros de téléphone, numéros de sécurité sociale, identifiants patients, numéros de dossier médical, numéros Medicaid, diagnostics, allergies, traitements et informations de handicap. Il faut lire ce chiffre de 284 millions comme un décompte brut de lignes de données, un même individu générant potentiellement plusieurs enregistrements à travers ses rendez-vous, prescriptions et facturations, et non comme un nombre de victimes uniques ; McKesson elle-même indique que son enquête reste à un stade précoce.

Le vecteur d'entrée n'est ni une CVE ni un exploit technique : c'est du vishing pur, avec usurpation du helpdesk informatique pour obtenir la réinitialisation d'accès Okta d'employés McKesson, puis pivot vers les environnements Salesforce et Snowflake de l'entreprise pour l'exfiltration. L'ensemble du cycle, de l'ingénierie sociale initiale à la fin de l'exfiltration, tient en moins d'une semaine. ShinyHunters a ensuite contacté McKesson pour exiger une rançon de 55 236 150 dollars sous 72 heures, un montant que l'entreprise n'a à ce stade pas payé selon les informations disponibles. CyberAfrik avait déjà documenté fin juillet une campagne d'abus OAuth/Salesforce menée par ce même écosystème. L'incident McKesson en est indépendant : la cible, le volume de données et le vecteur d'accès initial diffèrent nettement de ce premier dossier.

Chronologie

Date	Événement
Fin juillet 2026	Contexte : ShinyHunters, fédéré au sein de l'alliance Scattered Lapsus$ Hunters, poursuit une campagne active de vishing ciblant les intégrations SaaS des grandes entreprises
21 août 2026	Début estimé de l'exfiltration de données depuis les environnements Salesforce et Snowflake de McKesson
21-25 août 2026	Environ 1 téraoctet de données extrait progressivement des instances compromises
25 août 2026	McKesson détecte l'incident de sécurité ; ShinyHunters contacte l'entreprise et formule une demande de rançon de 55 236 150 dollars avec un délai de 72 heures
25-28 août 2026	ShinyHunters revendique publiquement le vol de 284 millions d'enregistrements ; McKesson confirme l'incident et ouvre une enquête
29 août 2026	Couverture presse généralisée (BleepingComputer, CyberInsider, DataBreaches.Net) ; McKesson indique que l'enquête reste à un stade précoce

Fiche vulnérabilité (format fiche CTI)

Ce sujet n'est pas rattaché à une CVE isolée mais à une campagne d'acteur exploitant une faiblesse structurelle : la dépendance des procédures de réinitialisation d'accès à la crédulité humaine plutôt qu'à un facteur de vérification résistant au phishing.

Acteur | ShinyHunters, opérant au sein de l'alliance Scattered Lapsus$ Hunters (également suivie sous les identifiants UNC6040 et UNC6395)
Scattered Lapsus$ Hunters, surnommée « Trinity of Chaos » par plusieurs chercheurs, réunit des membres historiques de ShinyHunters, Scattered Spider et Lapsus$. La répartition opérationnelle observée dans plusieurs incidents documentés depuis 2025 fait de ShinyHunters le pôle extorsion et négociation, pendant que des opérateurs proches de Scattered Spider assurent l'ingénierie sociale téléphonique se faisant passer pour le support IT interne. Conditions d'exploitation : la technique ne requiert aucune vulnérabilité logicielle, seulement un annuaire d'employés (souvent constitué par reconnaissance LinkedIn), un numéro de téléphone d'entreprise usurpable et un opérateur capable de mener une conversation crédible en anglais professionnel. PoC disponible : sans objet, il s'agit d'ingénierie sociale documentée par de multiples enquêtes (Obsidian Security, LevelBlue, Resecurity, Push Security) plutôt que d'un exploit technique publiable. Mitigation : authentification résistante au phishing (clé matérielle FIDO2/WebAuthn) pour toute réinitialisation d'accès à privilèges, procédure de vérification d'identité hors bande pour le helpdesk, et surveillance des connexions OAuth tierces sur les instances Salesforce et Snowflake.

Technique d'accès observée | Sans objet (CVSS non applicable) | Okta SSO, applications tierces Salesforce, entrepôt de données Snowflake
Les opérateurs appellent des employés en se faisant passer pour le support informatique ou un prestataire, souvent depuis des domaines d'apparence légitime contenant le nom ou une abréviation de l'entreprise ciblée suivie de « .claims » ou d'un équivalent. L'appel commence sur un ton calme avec un faux incident technique, puis pousse la victime à réinitialiser son second facteur, installer un outil de prise en main à distance, ou valider une autorisation d'application OAuth via une page ressemblant au flux d'installation légitime de Salesforce. Une fois la session SSO Okta compromise, les opérateurs accèdent directement aux instances Salesforce et Snowflake liées, sans avoir besoin d'exploiter de faille applicative supplémentaire. Conditions d'exploitation : absence de MFA résistant au phishing sur le compte ciblé, ou volonté de la victime de coopérer sous la pression sociale de l'appel. PoC disponible : non applicable, TTP documentée par observation d'incidents réels plutôt que publiée sous forme d'outil. Mitigation : passkeys ou clés de sécurité matérielles pour Okta, désactivation des flux d'auto-installation d'applications OAuth tierces sans validation administrateur, alerte sur toute réinitialisation de MFA suivie d'une connexion depuis une localisation ou un appareil inhabituel.

Diagramme de la chaîne d'attaque

Le diagramme place l'acteur ShinyHunters/Scattered Lapsus$ Hunters au centre et détaille les nœuds traversés (usurpation helpdesk, compromission Okta, environnements Salesforce et Snowflake, canal d'extorsion). Sources : Bleeping Computer, CyberInsider, Cybernews, rapports Obsidian Security et LevelBlue sur l'alliance Scattered Lapsus$ Hunters.

Analyse technique

Étape 1 : reconnaissance et préparation de l'usurpation

Avant tout appel, les opérateurs constituent un annuaire d'employés ciblables, généralement par scraping LinkedIn et énumération d'annuaires d'entreprise. Ils enregistrent des noms de domaine ressemblant à celui de la cible pour héberger de fausses pages de support ou de connexion, une pratique déjà documentée sur des campagnes précédentes de ce même écosystème.

Étape 2 : vishing et usurpation du helpdesk

L'appel se présente comme une intervention de routine du support informatique. L'opérateur instaure la confiance par un ton professionnel avant d'orienter la victime vers une action concrète : réinitialisation de mot de passe, ajout d'un nouveau facteur MFA contrôlé par l'attaquant, ou installation d'un outil d'accès à distance. Dans les variantes les plus abouties de cette TTP observées ailleurs dans l'écosystème Scattered Lapsus$ Hunters, la victime est redirigée vers un site d'hameçonnage adversary-in-the-middle qui capture simultanément identifiants et code MFA.

Étape 3 : prise de contrôle de la session SSO Okta

Une fois la réinitialisation ou la capture de session effectuée, les attaquants disposent d'un accès Okta légitime au nom de l'employé compromis. Cet accès unique donne, par construction du SSO d'entreprise, une porte d'entrée directe vers l'ensemble des applications fédérées sans nécessiter d'authentification supplémentaire propre à chacune.

Étape 4 : pivot vers Salesforce et Snowflake, exfiltration

Depuis la session Okta compromise, les opérateurs accèdent aux instances Salesforce et Snowflake de McKesson et lancent l'extraction de données à grande échelle. Le volume rapporté, environ un téraoctet extrait entre le 21 et le 25 août, est cohérent avec une exfiltration via des requêtes API massives ou des exports de rapports Salesforce automatisés plutôt qu'une copie manuelle fichier par fichier.

Étape 5 : contact d'extorsion et publicité de la revendication

Le 25 août, une fois l'exfiltration terminée, ShinyHunters contacte directement McKesson pour exiger 55 236 150 dollars sous 72 heures. La revendication publique du vol de 284 millions d'enregistrements suit rapidement, une tactique de pression désormais habituelle chez ce groupe : publiciser l'ampleur du vol avant même l'expiration du délai de rançon pour maximiser la pression médiatique et réputationnelle sur la victime.

Indicateurs de compromission

Type	Valeur
Vecteur d'accès initial	Vishing avec usurpation du support IT interne, ciblant les comptes SSO Okta
Infrastructure de leurre	Domaines contenant le nom ou une abréviation de l'entreprise ciblée suivis de « .claims » ou de variantes similaires (motif observé sur des campagnes connexes de l'alliance, non confirmé nommément pour l'incident McKesson dans les sources publiques disponibles)
Systèmes ciblés en aval	Instances Salesforce et Snowflake liées au SSO Okta compromis
Volume d'exfiltration rapporté	Environ 1 téraoctet entre le 21 et le 25 août 2026
Montant de rançon exigé	55 236 150 dollars US, délai de 72 heures
Acteur revendiquant	ShinyHunters (alliance Scattered Lapsus$ Hunters / UNC6040 / UNC6395)

Aucun hash de fichier, adresse IP ou domaine d'infrastructure C2 spécifique à l'incident McKesson n'a été publié dans les sources consultées à la date de rédaction ; les indicateurs ci-dessus reflètent le mode opératoire documenté plutôt qu'une liste d'IOC exhaustive propre à cette intrusion.

MITRE ATT&CK

Aucune cartographie officielle vendeur n'a été publiée spécifiquement pour l'incident McKesson au moment de la rédaction. Le tableau suivant reprend la cartographie établie par plusieurs chercheurs (Picus Security, Push Security, Splunk Research) pour le mode opératoire général de Scattered Lapsus$ Hunters, appliquée par CyberAfrik à la séquence connue de cet incident ; ce n'est pas une attribution technique confirmée par McKesson ou par un vendeur de sécurité sur ce cas précis.

Tactique	Technique	ID	Justification
Reconnaissance	Gather Victim Identity Information	T1589.002	Constitution d'un annuaire d'employés ciblables par scraping LinkedIn, documentée sur l'écosystème Scattered Lapsus$ Hunters
Initial Access	Phishing: Spearphishing Voice	T1566.004	Vishing avec usurpation du helpdesk informatique pour obtenir une réinitialisation d'accès
Initial Access	Valid Accounts	T1078	Utilisation de la session SSO Okta légitimement réinitialisée pour accéder aux applications fédérées
Persistence	Account Manipulation	T1098	Modification du second facteur MFA au profit d'un dispositif contrôlé par l'attaquant
Collection	Data from Cloud Storage	T1530	Extraction massive de données depuis les environnements Salesforce et Snowflake
Exfiltration	Exfiltration Over Web Service	T1567.002	Volume d'environ un téraoctet extrait sur quatre jours, cohérent avec une exfiltration via API cloud
Impact	Financial Theft	T1657	Demande de rançon de 55,2 millions de dollars sous 72 heures accompagnée d'une menace de publication

Remédiation : checklist opérationnelle

Déployer une authentification résistante au phishing (FIDO2/WebAuthn matériel) pour tout compte à privilèges administratifs ou disposant d'accès SSO fédéré, en priorité sur les comptes IT et helpdesk eux-mêmes.
Mettre en place une procédure de vérification d'identité hors bande pour toute demande de réinitialisation de MFA ou de mot de passe reçue par téléphone, incluant un rappel systématique sur un numéro interne connu plutôt qu'une confiance dans l'appelant entrant.
Restreindre l'installation d'applications OAuth tierces sur Salesforce aux seules applications validées par une liste blanche administrateur, en désactivant les flux d'auto-installation par lien.
Mettre en place une alerte automatique sur toute séquence réinitialisation MFA suivie d'une connexion depuis un appareil ou une localisation inhabituels dans les 30 minutes.
Auditer les journaux d'accès Snowflake et Salesforce pour détecter des volumes d'export ou de requêtes API anormaux par rapport à la ligne de base historique de chaque compte de service.
Former spécifiquement les équipes de support IT et helpdesk à reconnaître les scripts de vishing de type usurpation de collègue, plutôt que de limiter la sensibilisation aux utilisateurs finaux.
Segmenter les accès Snowflake par principe de moindre privilège pour qu'une session SSO compromise ne donne pas un accès en lecture à l'intégralité de l'entrepôt de données.
Préparer un plan de communication de crise pour la notification des personnes concernées, la loi applicable dans le secteur de la santé américain imposant des délais stricts de notification en cas de compromission de données médicales et de numéros de sécurité sociale.