L’incident en bref
Les 28 et 29 août 2026, BleepingComputer et CyberNews ont rapporté que le groupe ShinyHunters revendique une intrusion chez McKesson Corporation, premier distributeur pharmaceutique des États-Unis. Selon le groupe, l’opération s’est déroulée du 21 au 25 août et visait les environnements Snowflake et Salesforce de McKesson, pour un butin d’environ 1 To contenant 284 millions d’enregistrements. McKesson a découvert l’incident le 25 août et l’a confirmé le jour même en déposant un formulaire 8-K auprès de la SEC, le gendarme boursier américain.
McKesson n’a confirmé ni le chiffre de 284 millions, ni les types de données, ni le vecteur d’attaque. Tant que l’entreprise n’a pas terminé son enquête forensique ni envoyé de notifications officielles, chaque chiffre attribué à ShinyHunters doit être considéré comme une revendication et non comme un fait établi. Ce qui est établi : McKesson a subi un incident de cybersécurité assez grave pour déclencher un 8-K, et un groupe d’extorsion très médiatisé le revendique en exigeant 55,2 M$.
Comment les attaquants ont-ils pu accéder à Snowflake et Salesforce en même temps ?
ShinyHunters a pour mode opératoire documenté l’utilisation d’identifiants collectés en masse pour compromettre des tenants SaaS à grande échelle. En 2024, le groupe a mené une campagne contre des clients de Snowflake – dont AT&T, Ticketmaster et Advance Auto Parts – en exploitant des comptes sur lesquels l’authentification multifacteur (MFA) n’était pas imposée. Les identifiants avaient été dérobés des mois plus tôt par des infostealers installés sur des postes de développeurs, des systèmes CI/CD et des machines de prestataires.
Le mécanisme est simple : un utilisateur installe un infostealer (souvent via du phishing ou un outil piégé), le logiciel malveillant récupère les mots de passe enregistrés dans le navigateur et les fichiers de jetons, puis ces identifiants sont revendus ou conservés pour plus tard. Si la plateforme SaaS n’exige pas la MFA à chaque session, ou si l’attaquant récupère directement un jeton de session valide, il peut s’authentifier sans déclencher de détection liée au mot de passe. Les comptes Snowflake, les Connected Apps Salesforce et les comptes de service utilisés pour l’ETL ou les pipelines de données sont des cibles privilégiées : ils disposent souvent d’un accès en lecture massif aux données critiques et échappent fréquemment aux politiques MFA conçues pour la connexion des utilisateurs finaux.
Si l’enquête confirme une entrée par identifiants, le schéma serait identique à celui de 2024 : aucune faille dans les produits Snowflake ou Salesforce eux-mêmes, mais une lacune dans les contrôles d’accès que le client applique sur ces plateformes.
Ce que McKesson a confirmé, et ce qu’il n’a pas confirmé
Le formulaire 8-K établit que McKesson estime qu’un incident de cybersécurité est survenu le 25 août 2026 ou avant. Les règles de la SEC imposent à une société cotée de déposer un 8-K dans les quatre jours ouvrés suivant le moment où elle juge qu’un incident est « significatif ou raisonnablement susceptible de l’être ». Le dépôt ne décrit ni le périmètre, ni le vecteur, ni les données touchées ; ces éléments apparaissent généralement dans les rapports 10-Q ou 10-K suivants, dans des 8-K complémentaires ou via les notifications réglementaires obligatoires.
McKesson n’a pas confirmé la responsabilité de ShinyHunters, ni l’implication de Snowflake ou de Salesforce, ni l’accès à des données de patients, ni le chiffre de 284 millions. L’enquête était toujours en cours au moment de la publication. Dans ses activités de distribution pharmaceutique et de services technologiques, McKesson est à la fois « covered entity » et « business associate » au sens de HIPAA ; si des données de santé protégées (PHI) ont été consultées, il est soumis à des obligations de notification, qu’il commente ou non publiquement la revendication de ShinyHunters.
Ce que cela implique pour les équipes logicielles en santé
Que les chiffres de ShinyHunters se vérifient ou non, le schéma de l’attaque présumée est riche d’enseignements pour toute équipe qui conçoit ou exploite des logiciels de santé stockant des données de patients dans des plateformes d’analytique ou de CRM cloud.
Les délais de notification HIPAA sont fixes. Si l’enquête confirme un accès non autorisé à des PHI, le délai de 60 jours pour informer les personnes concernées a commencé à courir à la date de découverte (25 août). Pour les violations touchant 500 personnes ou plus dans un État américain, McKesson doit également prévenir l’Office for Civil Rights (OCR) du ministère américain de la Santé (HHS) et informer les grands médias de cet État dans les mêmes 60 jours. Les équipes dont les systèmes reposent sur l’infrastructure de données de McKesson – systèmes officinaux, entrepôts de données de santé, analytique de la chaîne d’approvisionnement – doivent relire dès maintenant leurs Business Associate Agreements (BAA) pour savoir où commencent leurs propres obligations.
Les contrôles d’accès massif dans Snowflake ne sont pas facultatifs. Snowflake permet de configurer au niveau du compte l’obligation de MFA, des politiques réseau et des politiques d’accès par ligne. Beaucoup d’organisations activent la MFA pour les outils BI des utilisateurs, mais laissent les comptes de service et les connexions ETL sur de simples clés d’API. Une seule clé d’API ou un seul jeton de session compromis peut offrir à un attaquant un niveau d’accès équivalent à ACCOUNTADMIN, qu’un DBA met des mois à construire. Si votre compte Snowflake contient des données de santé – données de facturation, résultats d’analyses, historiques de prescription –, les comptes de service doivent être renouvelés fréquemment, la MFA ou l’authentification par certificat imposée pour tous les types de connexion, et les politiques réseau limitées aux plages IP connues.
Les Connected Apps Salesforce sont un point d’exfiltration classique. Une Connected App disposant d’un accès Bulk API (« Chatter API » ou périmètre API standard) peut exporter de gros volumes d’enregistrements avec un seul jeton OAuth. Vérifiez quelles Connected Apps de votre org Salesforce ont un accès API complet ou aucune restriction IP. L’expiration des jetons et la révocation des refresh tokens doivent être automatisées, pas manuelles.
L’ordre de grandeur de 284 millions montre la vitesse des exports massifs. Selon ShinyHunters, toute l’opération s’est déroulée du 21 au 25 août, soit cinq jours. Pour 284 millions d’enregistrements, cela suppose un rythme moyen de plusieurs dizaines de millions de lignes par jour. La commande COPY INTO de Snowflake et la Bulk API de Salesforce sont précisément conçues pour ce débit. Les outils SIEM et DLP qui alertent sur des volumes d’export anormaux sont le principal moyen de détection ; ils doivent être réglés spécifiquement sur l’activité des API d’export massif, et pas seulement sur le volume des requêtes interactives.
Checklist de durcissement immédiat pour les données de santé en SaaS cloud
- Snowflake : imposer la MFA à tous les utilisateurs et comptes de service. Lancez
SHOW USERSet vérifiezHAS_MFA. Les comptes de service authentifiés par paire de clés ou OAuth doivent utiliser des jetons à courte durée de vie (15 minutes) et des politiques réseau limitées aux plages IP connues. - Snowflake : auditer les chaînes de privilèges ACCOUNTADMIN et SYSADMIN. Lancez
SHOW GRANTS ON ROLE ACCOUNTADMINet identifiez chaque utilisateur capable d’obtenir ce rôle. Révoquez les droits antérieurs à la dernière revue des accès. - Snowflake : examiner QUERY_HISTORY pour la période du 21 au 25 août. Recherchez les commandes COPY INTO vers des stages externes, les SELECT * massifs à fort volume de lignes et les connexions depuis des plages IP hors de votre politique réseau. C’est votre indicateur de compromission si vous utilisez les mêmes plateformes que McKesson.
- Salesforce : auditer les Connected Apps disposant d’un périmètre API. Dans Setup → Connected Apps → Manage, passez en revue les applications ayant un accès API complet ou Chatter API, ainsi que les assouplissements IP et la durée de vie des jetons.
- Salesforce : renouveler les identifiants d’intégration. Toute intégration Salesforce (ETL, BI, portails externes) authentifiée par identifiant et mot de passe doit migrer vers des flux OAuth via Connected App, avec des jetons courts et des restrictions IP.
- Revoir les contrats : BAA et clauses de sous-traitance. Si vous consommez l’infrastructure de données de McKesson en aval, ressortez votre BAA – et, pour les données européennes, votre contrat de sous-traitance au sens de l’article 28 du RGPD : quels délais de notification sont prévus, et le prestataire doit-il vous prévenir dans un délai précis si vos données sont concernées ?
- Alertes SIEM sur les API d’export massif. Si votre SIEM n’alerte pas sur un usage anormal des API d’export (COPY INTO Snowflake, volume de requêtes Bulk API Salesforce), ajoutez ces détections avant la fin de votre prochain sprint.
Questions fréquentes
McKesson a-t-il confirmé le vol de 284 millions d’enregistrements ?
Non. McKesson a confirmé un incident via un formulaire 8-K de la SEC déposé le 25 août 2026, mais n’a confirmé ni l’ampleur, ni le vecteur, ni les types de données revendiqués par ShinyHunters. Le chiffre de 284 millions provient de la publication du groupe lui-même et doit être considéré comme non vérifié jusqu’à la fin de l’enquête de McKesson et l’envoi des notifications officielles.
Quels types de données ShinyHunters affirme-t-il avoir volés chez McKesson ?
ShinyHunters affirme que les données dérobées comprennent des numéros de sécurité sociale américains, des diagnostics, des ordonnances et des numéros de dossier médical. Si cela se confirme, ces catégories constitueraient des données de santé protégées (PHI) au sens de HIPAA, déclenchant une notification obligatoire aux personnes concernées, au HHS et potentiellement aux autorités des États. McKesson n’a pas confirmé ces types de données.
Quelles obligations de notification HIPAA McKesson doit-il respecter après une violation de cette ampleur ?
Selon la HIPAA Breach Notification Rule, les covered entities doivent informer les personnes concernées dans les 60 jours suivant la découverte d’une violation. Lorsque 500 personnes ou plus sont touchées dans un État, les grands médias de cet État doivent aussi être prévenus. Toute violation touchant 500 personnes ou plus doit être déclarée à l’Office for Civil Rights (OCR) du HHS dans les 60 jours. McKesson ayant découvert l’incident le 25 août 2026, l’échéance tombait le 24 octobre 2026. À titre de comparaison, le RGPD impose une notification à la CNIL sous 72 heures.
Comment des attaquants ont-ils pu compromettre à la fois Snowflake et Salesforce chez McKesson ?
ShinyHunters a toujours exploité des identifiants volés en masse – collectés par des infostealers sur des postes de développeurs, dans des environnements CI et dans des bases d’identifiants – pour compromettre des tenants SaaS sans MFA imposée. Lors de la campagne Snowflake de 2024, le groupe a utilisé des identifiants volés des mois plus tôt pour accéder à des dizaines de grands comptes sans déclencher la détection d’anomalies, car les connexions semblaient provenir de plages IP connues. Les comptes Salesforce à authentification simple, notamment les comptes de service utilisés pour l’ETL ou les intégrations, sont tout aussi vulnérables. Un seul compte cloud privilégié compromis peut ouvrir en quelques heures les API d’export massif des deux plateformes.
Sources
BleepingComputer — McKesson discloses breach after ShinyHunters claims patient data theft (August 28–29, 2026)
CyberNews — McKesson breached: ShinyHunters claims 284M records (August 28–29, 2026)
SEC EDGAR — McKesson Corporation (CIK 0000927653) Form 8-K filings