Chiavi AWS esposte e breach SickKids allargano il rischio aziendale

🛡️ Executive Summary

• Oltre 9.300 chiavi AWS pubblicamente esposte risultano ancora valide; 768 credenziali concedono il controllo completo di account aziendali.
• Chiavi root e identità IAM con AdministratorAccess permettono furto o cancellazione dei dati, creazione di amministratori, cryptomining e persistenza nel cloud.
• SickKids subisce un breach attraverso software di terze parti; sistemi clinici e dati dei pazienti non risultano coinvolti.

Due incidenti apparentemente distanti mostrano come il rischio aziendale si concentri sempre più sulle credenziali dimenticate e sulle infrastrutture affidate a soggetti esterni. Una ricerca durata quattro anni ha individuato migliaia di chiavi AWS ancora funzionanti dopo essere state pubblicate in repository, dataset, immagini Docker e log CI. In Canada, il SickKids di Toronto ha invece confermato l’accesso non autorizzato ai dati di dipendenti e candidati attraverso una vulnerabilità presente in un’applicazione di terze parti. Nel primo caso il perimetro cloud resta aperto dall’interno; nel secondo viene attraversato dal software di un fornitore.

Oltre 9.300 chiavi AWS esposte risultano ancora valide

Truffle Security ha raccolto 431.875 segreti AWS pubblicati tra agosto 2022 e agosto 2026 all’interno di repository di codice, cronologie Git, dataset, registry, immagini Docker e log delle pipeline di integrazione continua. Dopo la rimozione dei duplicati, il materiale corrispondeva a 64.024 chiavi uniche appartenenti a 50.654 account AWS.

La ricerca si è concentrata successivamente sulle credenziali complete che potevano essere verificate nuovamente senza accedere ai contenuti dei clienti: su 10.616 chiavi, l’88% continuava ad autenticarsi il 10 agosto 2026. Il risultato supera quindi le 9.300 credenziali ancora valide, nonostante la loro esposizione pubblica potesse risalire a diversi anni prima. La situazione conferma il rischio già evidente con NadMesh, botnet specializzata nel furto di chiavi AWS da servizi AI esposti: una credenziale statica conservata in una variabile, in un container o nel codice può sopravvivere al progetto che l’ha generata e diventare una porta permanente verso l’infrastruttura cloud.

Centinaia di credenziali concedono il controllo completo degli account

Tra le chiavi ancora attive, 817 risultano associate ad aziende. Il gruppo comprende 526 chiavi root, appartenenti cioè all’identità con il livello massimo di autorità su un account AWS, e 242 credenziali IAM collegate direttamente alla policy AdministratorAccess. Nel complesso, 768 chiavi appartenenti a queste due categorie possono concedere il controllo completo di un ambiente aziendale. Un aggressore potrebbe accedere ai bucket, copiare o cancellare dati, avviare e terminare istanze, modificare applicazioni, leggere database, creare nuovi amministratori e costruire percorsi di persistenza difficili da collegare alla credenziale originaria.

Potrebbe inoltre distribuire cryptominer o risorse costose facendo ricadere le spese sulla vittima. La ricerca tecnica di Truffle Security sulle chiavi AWS aziendali precisa che soltanto 262 dei 2.754 account leggibili disponevano di un budget alert, riducendo la probabilità che un consumo anomalo venisse intercettato rapidamente attraverso i costi. Il problema non riguarda quindi soltanto la segretezza della chiave, ma l’ampiezza dei privilegi che le è stata concessa.

Hugging Face concentra migliaia di esposizioni

La principale sorgente individuata è Hugging Face, dalla quale provengono 8.482 esposizioni di chiavi AWS uniche. Il dato non significa automaticamente che le credenziali appartengano alla piattaforma: modelli, dataset, applicazioni e repository caricati dagli utenti possono incorporare accidentalmente segreti appartenenti a organizzazioni differenti. Il 17,9% delle chiavi trovate su Hugging Face risultava però associato a identità root, rendendo il materiale particolarmente pericoloso.

Le piattaforme AI combinano codice, configurazioni, notebook, dataset, container e applicazioni dimostrative, aumentando il numero di percorsi attraverso i quali un segreto può finire in un artefatto pubblico. La stessa piattaforma è stata recentemente coinvolta in un’intrusione agentica con raccolta di credenziali cloud tra più cluster, sebbene non esista un collegamento diretto tra quell’incidente e le chiavi individuate da Truffle Security. I due casi mostrano però la medesima criticità: ambienti destinati allo sviluppo e alla condivisione possono custodire autorizzazioni capaci di aprire servizi di produzione.

Le chiavi dimenticate sopravvivono per anni

Per le 2.903 chiavi delle quali era disponibile la data di creazione, l’età mediana raggiungeva 1.831 giorni, equivalenti a circa cinque anni. La più vecchia era stata generata 17,4 anni prima, mentre soltanto 398 credenziali, pari al 13,7%, avevano una chiave più recente associata allo stesso utente. Questo suggerisce che buona parte dei segreti non fosse mai stata sottoposta a una rotazione ordinaria.

Una chiave può essere rimossa dal ramo principale di un repository e continuare a esistere nella cronologia Git, in un fork, in un’immagine container, nella cache di una pipeline o in un dataset derivato. Per questo motivo cancellare la stringa dal file corrente non costituisce una bonifica: qualsiasi credenziale pubblicata deve essere considerata compromessa, revocata e sostituita. Occorre inoltre controllare attraverso CloudTrail tutte le operazioni compiute dall’identità, verificare la creazione di utenti, ruoli, policy e access key secondarie e cercare modifiche a logging, bucket, snapshot e funzioni Lambda. La rivendicazione di milioni di record Azure ed Entra insieme al breach CEVA aveva già mostrato quanto le identità cloud possano conservare valore operativo anche quando non comprendono direttamente una password.

SickKids viene colpito attraverso un’applicazione esterna

Il secondo incidente riguarda il Hospital for Sick Children di Toronto, conosciuto come SickKids. L’organizzazione ha rilevato un accesso non autorizzato alle informazioni personali di alcuni dipendenti attuali ed ex dipendenti, collaboratori di Boomerang Health, personale della SickKids Foundation e candidati che avevano utilizzato il portale delle carriere. La compromissione è collegata a una vulnerabilità presente in un’applicazione di terze parti utilizzata anche da altre organizzazioni. Il fornitore, il prodotto e l’eventuale CVE non sono stati resi pubblici, impedendo per ora di stabilire se l’incidente faccia parte di una campagna più ampia contro clienti della stessa piattaforma. Nella comunicazione ufficiale sull’incidente, SickKids conferma che il sito esterno Careers è stato temporaneamente interessato ed è stato successivamente ripristinato. Sistemi clinici, informazioni dei pazienti e continuità delle cure non risultano coinvolti, distinzione essenziale per non trasformare una violazione dei dati HR in un attacco alle attività ospedaliere.

Il portale delle carriere custodisce identità professionali complete

SickKids non ha ancora indicato il numero delle persone interessate né le precise categorie di informazioni esposte. La revisione dei dati continua e gli individui confermati come vittime riceveranno una notifica diretta. Tutti i soggetti potenzialmente coinvolti sono stati comunque avvisati in via precauzionale e riceveranno 24 mesi di monitoraggio del credito e protezione dell’identità. I portali di recruiting costituiscono bersagli particolarmente ricchi perché possono raccogliere nomi completi, indirizzi, recapiti telefonici, email, curriculum, esperienze lavorative, qualifiche e documenti forniti durante la candidatura. Anche in assenza di dati clinici, queste informazioni permettono di costruire campagne di spear phishing credibili contro dipendenti e candidati, impersonare recruiter o responsabili HR e preparare tentativi di frode basati sulla storia professionale reale della vittima. L’impatto di un fornitore sanitario era già emerso con Unlimited Technology Systems e l’esposizione di 3,8 milioni di persone, dove una singola piattaforma utilizzata da più strutture aveva moltiplicato il numero dei soggetti downstream.

La sanità resta dipendente dalla sicurezza dei fornitori

SickKids era già stato colpito nel dicembre 2022 da un attacco ransomware che aveva provocato problemi ai sistemi interni, alle linee telefoniche e ai risultati di laboratorio e imaging. Nel 2023 era stato inoltre coinvolto nella compromissione di un’organizzazione esterna che condivideva dati sanitari pediatrici, conseguenza dello sfruttamento massivo della vulnerabilità MOVEit. Il nuovo caso è differente perché, secondo le informazioni disponibili, non coinvolge cartelle cliniche o pazienti, ma conferma la continuità del rischio derivante dalla supply chain. La sanità utilizza piattaforme esterne per assunzioni, fatturazione, gestione delle prestazioni, archiviazione, comunicazioni e analisi: ciascun fornitore riceve una porzione dei dati necessaria a svolgere il proprio servizio e diventa quindi un’estensione del perimetro. I data breach sanitari e le campagne attribuite a ShinyHunters mostrano inoltre come informazioni apparentemente amministrative possano alimentare frodi, estorsioni e successive operazioni di social engineering.

Privilegi minimi e controllo della supply chain riducono l’impatto

Le chiavi AWS e il breach SickKids convergono sul problema della fiducia persistente. Una credenziale dimenticata continua a funzionare perché nessuno ne ha ridotto i privilegi o imposto la scadenza; un’applicazione esterna continua a elaborare dati perché l’organizzazione deve affidarsi al fornitore per una funzione operativa. Nel cloud, la difesa richiede l’eliminazione delle access key dell’utente root, identità temporanee, ruoli con privilegi minimi, rotazione automatica, secret manager, scansione preventiva di repository e container e blocco delle credenziali prima che raggiungano sorgenti pubbliche. Nella supply chain servono inventario dei software, obblighi di notifica, verifica delle patch, segregazione dei dati e capacità di disattivare rapidamente l’integrazione compromessa. Il breach MCBS con esposizione di informazioni sanitarie conferma quanto sia difficile revocare dati personali già sottratti. Le chiavi cloud possono essere sostituite; curriculum, storie professionali e informazioni identificative, invece, possono restare utilizzabili dagli aggressori per anni.