Il 28 agosto 2026 McKesson, uno dei maggiori distributori farmaceutici e fornitori di servizi sanitari degli Stati Uniti, ha comunicato con un modulo 8-K alla SEC di aver rilevato il 25 agosto un incidente di sicurezza che ha coinvolto applicazioni di terze parti e l'esfiltrazione di dati. Il gruppo di estorsione ShinyHunters ha rivendicato l'attacco.

La cifra che sta circolando — 284 milioni di pazienti — merita una precisazione immediata, perché è il primo elemento di valore di questa vicenda. Non è il numero delle persone coinvolte. È stato lo stesso gruppo criminale, parlando con BleepingComputer, a correggere le prime ricostruzioni: si tratta di circa 284 milioni di record, cioè di righe di dati, e gli attaccanti hanno dichiarato di non aver ancora analizzato il materiale e di non sapere quante persone distinte vi siano dentro. In un archivio sanitario ogni paziente genera decine di righe fra prescrizioni, spedizioni, appuntamenti e fatture: il numero di individui è quasi certamente di un ordine di grandezza inferiore. Vale la pena tenerlo a mente ogni volta che un titolo trasforma un conteggio di righe in un conteggio di persone.

I fatti verificati

  • Cronologia: secondo ShinyHunters l'esfiltrazione è avvenuta fra il 21 e il 25 agosto 2026, per un totale di circa 1 TB di dati. McKesson dichiara di aver scoperto l'incidente il 25 agosto e che l'indagine è in fase iniziale.
  • Vettore d'ingresso: attacchi di vishing (phishing telefonico) contro più dipendenti. Il gruppo sostiene di aver compromesso in questo modo gli account Okta di single sign-on di diversi dipendenti.
  • Dove sono finiti: da Okta agli ambienti Salesforce e Snowflake dell'azienda. Il gruppo dichiara di aver compromesso interamente l'ambiente Salesforce, comprese le richieste di assistenza, e di aver sottratto da Snowflake una raccolta molto più ampia di dati relativi ai pazienti.
  • Il dominio usato: mckesson[.]claims. Il dato è rilevante perché si inserisce in uno schema documentato: il team di ricerca di ReliaQuest ha segnalato una campagna diffusa di ShinyHunters basata su domini che seguono il modello nomeazienda[.]claims, registrati per impersonare l'help desk e i team IT delle organizzazioni bersaglio.
  • Dati rivendicati: nomi, indirizzi, date di nascita, codici di previdenza sociale, identificativi paziente, telefoni, email, numeri Medicaid, numeri di cartella clinica, informazioni su farmaci e allergie, patologie, disabilità, appuntamenti e medici curanti. Il gruppo sostiene che vi siano anche dati di pazienti deceduti e terminali, comunicazioni interne e informazioni sui dipendenti.
  • Richiesta di riscatto: 55.236.150 dollari con 72 ore di tempo. Secondo gli attaccanti McKesson non ha risposto.
  • Contesto: Health-ISAC aveva già diramato un avviso alle organizzazioni sanitarie sull'aumento degli attacchi di ShinyHunters basati su ingegneria sociale per compromettere account aziendali e accedere a piattaforme cloud e SaaS. Fra i bersagli recenti nel settore sanitario figurano Medtronic, DentaQuest, iRhythm, OneMedical e AdaptHealth.
  • Cautela necessaria: le rivendicazioni sui contenuti dell'archivio provengono dagli attaccanti e non sono state verificate in modo indipendente. McKesson non ha reso pubblico quali applicazioni siano state compromesse né quali dati siano stati sottratti, e nel deposito alla SEC afferma di non aver determinato che l'incidente sia rilevante ai fini finanziari.

L'anatomia dell'attacco, e perché funziona ancora

Tolto il rumore delle cifre, questo attacco ha una struttura molto semplice: una telefonata, un'identità, un data lake.

La telefonata sfrutta un punto debole che nessun controllo tecnico copre: l'help desk. Un dipendente riceve una chiamata da qualcuno che si presenta come supporto IT, viene indirizzato su un dominio che sembra quello aziendale, inserisce le credenziali e approva la richiesta di autenticazione a più fattori che arriva sul telefono. Non c'è nessun malware, nessun exploit, nessuna anomalia sui sistemi da rilevare.

L'identità è il moltiplicatore. Il single sign-on è stato adottato ovunque perché risolve problemi reali di gestione e di sicurezza, ma ha un costo strutturale: concentra in un unico punto l'accesso a decine di applicazioni. Un account Okta compromesso non è un account, è un mazzo di chiavi.

Il data lake è il bersaglio. Salesforce e Snowflake non sono nati come archivi da proteggere alla stregua di un database clinico: sono nati come strumenti per rendere i dati accessibili. Snowflake in particolare è progettato per interrogare volumi enormi rapidamente e per esportare risultati con la stessa facilità. Un accesso legittimo con credenziali valide che esporta un terabyte in quattro giorni assomiglia, dai log, a un analista che lavora molto.

Il punto di rottura di questa catena è uno solo, ed è identificabile con precisione: l'autenticazione a più fattori non resistente al phishing. Codici via SMS, codici a sei cifre da app, notifiche push da approvare — tutti meccanismi che un attaccante al telefono può farsi consegnare o far approvare in tempo reale. Con FIDO2 e passkey legate al dominio, la stessa telefonata non produce nulla: la chiave crittografica non funziona su mckesson[.]claims, e nessuna dose di persuasione può cambiarlo.

Cosa significa per le aziende italiane

Va detto con onestà: McKesson opera principalmente negli Stati Uniti e la sua base di pazienti è americana. Per un'azienda italiana l'esposizione diretta è bassa. Il valore di questa notizia non sta nell'incidente, sta nel metodo, ed è integralmente trasferibile.

Il modello nomeazienda[.]claims è la parte più immediatamente utile. Le estensioni di dominio generiche di nuova generazione costano pochi euro, si registrano in minuti e non fanno parte del perimetro che la maggior parte delle organizzazioni sorveglia. Molte aziende monitorano le varianti tipografiche del proprio dominio .it o .com; quasi nessuna guarda cosa succede su .claims, .support, .help, .zone o .services. È una lacuna a costo di chiusura molto basso: i registri di Certificate Transparency sono pubblici e interrogabili gratuitamente, e un controllo automatico che segnali ogni nuovo certificato emesso per un dominio contenente il nome dell'azienda è realizzabile in poche ore di lavoro.

Il secondo elemento trasferibile riguarda le procedure dell'help desk, ed è la parte che in Italia risulta tipicamente più scoperta. Nelle organizzazioni di medie dimensioni il reset di una password o la ri-registrazione di un secondo fattore avviene ancora spesso su richiesta telefonica, con una verifica basata su informazioni che chiunque può trovare (nome, matricola, ufficio, nome del responsabile). Questa procedura, dove esiste in questa forma, è il punto d'ingresso.

Sul piano normativo, per un'organizzazione italiana un incidente di questo tipo attiva più fronti contemporaneamente. I dati sanitari sono categorie particolari ai sensi dell'articolo 9 del GDPR: la valutazione del rischio per gli interessati parte da un livello elevato per definizione, e la comunicazione agli interessati prevista dall'articolo 34 diventa difficile da evitare. La notifica al Garante va effettuata entro 72 ore dalla conoscenza del fatto, con la possibilità di una notifica in fasi quando l'indagine è ancora in corso — situazione in cui McKesson si trova oggi e in cui si trova, realisticamente, chiunque nelle prime settimane.

C'è poi la questione della catena di fornitura, che qui è centrale: l'attacco ha colpito applicazioni di terze parti, non i sistemi dell'azienda. Per il titolare del trattamento questo non sposta la responsabilità. L'articolo 28 del GDPR richiede che il titolare si avvalga solo di responsabili che presentino garanzie sufficienti, e in caso di violazione il titolare deve poter dimostrare di aver verificato quelle garanzie, non di averle date per acquisite perché il fornitore è grande e noto. Per le strutture sanitarie italiane, che rientrano fra i settori altamente critici dell'allegato I della direttiva NIS2, si aggiunge l'obbligo di gestire i rischi derivanti dai fornitori come parte integrante delle misure di sicurezza previste dall'articolo 21, e la notifica di preallarme ad ACN entro 24 ore per gli incidenti significativi.

Cosa fare subito

  • Passate a un secondo fattore resistente al phishing almeno per gli account con accesso ad archivi di dati: chiavi FIDO2 o passkey legate al dominio. È l'unico controllo che neutralizza alla radice l'attacco descritto. Se la migrazione completa non è realistica nel breve periodo, iniziate dagli amministratori dell'identity provider e da chi accede a Salesforce, Snowflake, ServiceNow e strumenti equivalenti.
  • Riscrivete la procedura di reset dell'help desk: nessun reset di password o di secondo fattore su richiesta telefonica senza una verifica fuori banda (richiamata sul numero presente in anagrafica aziendale, conferma dal responsabile diretto, o verifica in videochiamata con documento). Mettetelo per iscritto e verificate che il personale esterno di primo livello lo applichi.
  • Monitorate le registrazioni di domini simili al vostro sulle nuove estensioni generiche, in particolare .claims, .support, .help, .services e .zone. Un controllo periodico sui registri di Certificate Transparency è gratuito e intercetta il dominio nel momento in cui viene emesso il certificato, cioè tipicamente prima della campagna.
  • Applicate politiche di rete sui SaaS che contengono i dati. Snowflake supporta le network policy per limitare l'accesso a indirizzi noti; Salesforce consente restrizioni IP a livello di profilo e limiti sulle applicazioni collegate. Un accesso da un indirizzo mai visto a un ambiente che contiene dati clinici dovrebbe essere impossibile, non semplicemente registrato.
  • Costruite allarmi sul volume esportato, non solo sugli accessi anomali. La domanda a cui i vostri log devono saper rispondere è: "quanto ha scaricato ieri questo utente rispetto alla sua media dei trenta giorni precedenti?". Un terabyte in quattro giorni è visibile solo se qualcuno ha definito in anticipo cosa sia normale.
  • Inventariate le applicazioni di terze parti collegate all'identity provider e revocate quelle non più usate. Le integrazioni OAuth dimenticate sopravvivono ai progetti che le hanno create e mantengono i permessi concessi anni prima.
  • Preparate la notifica prima di averne bisogno. Chi deve decidere, in quali ore, con quali informazioni minime, e chi firma. Le 72 ore del GDPR e le 24 ore del preallarme NIS2 si consumano quasi interamente nel capire chi deve fare cosa.