Trezor sale a 81.000 vittime: Mathspace supera il milione e IDScan rischia il maxi-breach

🛡️ Executive Summary

• Trezor porta a circa 81.000 i clienti coinvolti nel breach ShipMonk: 67.000 record USA dovevano essere stati cancellati anni prima.
• Mathspace conferma 1.079.819 persone colpite dopo il mancato aggiornamento di Metabase, mentre Novocure espone record di oltre 1.400 pazienti.
• IDScan affronta numerose cause sul presunto leak di 153 milioni di patenti, ma origine e dimensione della violazione non sono ancora confermate.

Una nuova sequenza di violazioni mostra quanto il rischio cyber dipenda ormai dalla conservazione dei dati e dalle infrastrutture di terze parti almeno quanto dall’attacco iniziale. Trezor ha portato a circa 81.000 il numero dei clienti coinvolti nel breach del provider logistico ShipMonk, scoprendo che informazioni che avrebbero dovuto essere eliminate erano rimaste nei sistemi per anni. Mathspace conferma invece 1.079.819 persone coinvolte dopo lo sfruttamento della vulnerabilità zero-day di Metabase. Sul fronte sanitario Novocure comunica accessi a record riferiti a oltre 1.400 pazienti, mentre negli Stati Uniti IDScan affronta una serie crescente di cause legate al presunto furto di oltre 153 milioni di documenti di identità, incidente sul quale l’FBI sta ancora indagando.

Trezor arriva a 81.000 clienti perché ShipMonk non aveva cancellato i vecchi ordini

Il caso più significativo non è quello numericamente più grande, ma quello che mostra con maggiore chiarezza il problema della data retention lungo la supply chain. Trezor aveva comunicato il 13 agosto che la compromissione di ShipMonk, società incaricata della logistica e delle spedizioni, aveva esposto i dati di circa 13.689 clienti. L’aggiornamento del 4 settembre aggiunge però altri 67.000 clienti statunitensi che avevano effettuato ordini tra novembre 2019 e agosto 2021, portando il totale a circa 81.000 persone. Per questi utenti risultano esposti nome, indirizzo email, numero telefonico, indirizzo di spedizione e numero d’ordine. Il passaggio più grave emerge dalla stessa comunicazione aggiornata di Trezor: il produttore sostiene di avere richiesto ripetutamente a ShipMonk la cancellazione dei dati e di avere ricevuto rassicurazioni scritte che tale eliminazione fosse avvenuta. Trezor applica infatti una policy di conservazione di 90 giorni ai dati degli ordini e afferma di avere imposto lo stesso requisito ai propri fulfillment partner. Il breach dimostra invece che almeno una parte delle informazioni era ancora presente dopo cinque-sette anni. È precisamente il rischio emerso anche nel caso SafePal, dove quasi 40.000 clienti avevano visto esposti indirizzi e dettagli degli ordini: per chi acquista un hardware wallet, conoscere identità, telefono e indirizzo fisico è un’informazione molto più pericolosa di una normale lista marketing, perché consente phishing costruito sul possesso di criptovalute e può aumentare persino il rischio di aggressioni fisiche. Trezor precisa che wallet, firmware, seed phrase e sistemi aziendali non sono stati compromessi. La distinzione è fondamentale ma non riduce il rischio successivo. Nel 2024 un precedente incidente contro il portale di supporto Trezor aveva esposto informazioni di circa 66.000 utenti, successivamente riutilizzate in campagne progettate per sottrarre le recovery seed. Lo stesso schema era riemerso nel 2025 con il phishing mirato contro gli utenti Trezor e nel 2026 con OKOBot, malware costruito per rubare seed phrase da Trezor e Ledger. Un dataset che associa una persona all’acquisto di un hardware wallet consente quindi di passare dal phishing indiscriminato alla selezione preventiva di vittime che probabilmente possiedono asset crypto.

Mathspace supera un milione di vittime dopo avere ignorato la patch Metabase

Il breach di Mathspace presenta una dinamica tecnica ancora più netta. La piattaforma educativa ha confermato che 1.079.819 studenti, genitori, tutori, insegnanti e dipendenti di Australia e Nuova Zelanda sono stati coinvolti dopo l’accesso non autorizzato al sistema interno di reporting. Gli aggressori hanno sfruttato una vulnerabilità nella versione self-hosted di Metabase, ottenendo privilegi amministrativi senza un login legittimo. La ricostruzione pubblicata direttamente da Mathspace stabilisce una timeline particolarmente problematica: Metabase aveva pubblicato la patch critica il 6 agosto, gli accessi malevoli iniziano dal 10 agosto, i dati vengono scaricati il 27 agosto e Mathspace aggiorna la propria installazione soltanto il 29 agosto, dopo avere ricevuto un successivo avviso. L’azienda riconosce espressamente che il proprio processo di vulnerability notification non aveva identificato ed escalato correttamente l’advisory iniziale. I dati sottratti comprendono ID interno, username, nome, cognome, email, paese, fuso orario, tipologia di utente, stato di verifica dell’email e informazioni temporali come ultima attività, ultimo login e data di creazione dell’account. Non risultano esposti password, token SSO, credenziali API, risultati scolastici o attività didattiche. Il dataset resta però particolarmente sensibile perché riguarda in larga parte studenti e minori e consente di costruire impersonificazioni credibili di scuole, docenti e piattaforme educative. Il precedente di Gruppo Spaggiari, con documentazione scolastica e potenziali dati sanitari sottratti a un servizio utilizzato dagli istituti, mostra come il settore education concentri informazioni capaci di restare utili agli aggressori ben oltre la chiusura dell’incidente.

Leggi anche: ShinyHunters contro Oracle PeopleSoft: oltre 450.000 studenti coinvolti nel breach dell’Università di Nottingham

Metabase collega Mathspace e Trezor attraverso la stessa campagna di compromissione

Mathspace e Trezor sono aziende completamente differenti, ma i rispettivi incidenti sembrano convergere sulla campagna di compromissione delle installazioni Metabase emersa durante agosto. Metabase ha ricostruito una vulnerabilità zero-day che permetteva di manipolare il percorso di reset della password, effettuare SQL injection, inserire direttamente una sessione amministrativa nel database e utilizzare quella sessione per creare API key ed effettuare download massivi. Nella propria analisi tecnica dell’incidente di agosto, Metabase afferma che tutte le installazioni dalla versione 0.58 in avanti erano vulnerabili e che meno del 3% dei clienti cloud era stato effettivamente compromesso prima della correzione, insieme ad alcune installazioni self-hosted pubblicamente raggiungibili. Nel caso Trezor, il sistema compromesso apparteneva però a ShipMonk, non a Trezor stessa. Le notifiche ricevute dai clienti indicano Metabase come punto di ingresso, mentre BleepingComputer ha collegato le richieste di estorsione rivolte a ShipMonk a ShinyHunters. L’attribuzione della compromissione Trezor al gruppo non è stata confermata ufficialmente dal produttore e va quindi mantenuta separata dal fatto tecnico. Il precedente di ShinyHunters contro PeopleSoft e le infrastrutture enterprise offre comunque il contesto più pertinente: il gruppo ha già costruito campagne nelle quali una singola tecnologia enterprise compromessa produce una cascata di vittime appartenenti a organizzazioni differenti. Qui la differenza è che la cascata non passa da un fornitore software installato direttamente dalla vittima finale, ma da un provider logistico che conserva dati per conto del cliente.

IDScan rischia un breach da 153 milioni di patenti ma il caso non è ancora provato

Completamente differente è la situazione di IDScan.net. Numerose cause sono state depositate presso il tribunale federale dell’Eastern District of Louisiana dopo la comparsa sul servizio criminale Nexus di un database che sarebbe composto da oltre 153 milioni di scansioni di patenti statunitensi e canadesi, insieme a circa 10 milioni di altre carte d’identità, tre milioni di documenti di viaggio e centinaia di migliaia di tessere sanitarie. I procedimenti contro IDScan sono reali: diversi docket federali risultano aperti dal 2 e 4 settembre, tra cui Greenbaum v. IDscan.net, ma le accuse contenute nelle cause non equivalgono alla conferma del breach. L’origine dell’archivio è stata collegata a IDScan da un’indagine giornalistica basata su campioni verificati e sulle correlazioni tra le date delle scansioni e attività effettuate presso aziende che utilizzano i servizi della società. L’FBI di New Orleans ha confermato di avere aperto un’indagine, ma IDScan non ha ancora pubblicato una ricostruzione tecnica e non risultano confermati né il vettore iniziale né il numero reale delle persone coinvolte. È quindi scorretto scrivere che “IDScan ha perso 153 milioni di patenti” come fatto accertato. Se però l’attribuzione venisse confermata, il caso avrebbe un impatto eccezionale perché una scansione di documento rappresenta un identificativo permanente, riutilizzabile per procedure KYC, impersonificazione e social engineering anche anni dopo. È lo stesso principio che rende pericolosi i dataset descritti nelle campagne italiane in cui documenti, codici fiscali e dati completi vengono raccolti per costruire identità digitali credibili.

Novocure espone dati di pazienti oncologici ma il perimetro è più ristretto

Il caso Novocure ha dimensioni molto inferiori ma coinvolge informazioni sanitarie e richiede quindi una valutazione diversa dal semplice conteggio delle vittime. Nel Form 8-K depositato presso la SEC, l’azienda specializzata in terapie oncologiche afferma di avere scoperto a metà agosto un accesso non autorizzato ad alcuni sistemi informatici. L’indagine ha individuato più di 1.400 record statunitensi contenenti ID paziente interni, senza nomi o altri identificativi diretti; meno di 50 pazienti negli Stati Uniti occidentali risultano invece coinvolti con ulteriori informazioni identificative. Sono stati raggiunti anche dati generali di contatto relativi a operatori sanitari e dipendenti. Novocure precisa che nessun dispositivo medicale è stato compromesso e che l’incidente non ha interrotto la capacità operativa. Il confronto più pertinente è con la recente esposizione di 9,5 milioni di pazienti attraverso Aesto Health e con la sanzione francese per oltre 700.000 persone coinvolte in un breach ospedaliero. In entrambi i casi il punto centrale non è soltanto impedire la compromissione della rete, ma sapere quali copie di dati sanitari esistono, dove sono conservate e chi può raggiungerle. Nel caso Novocure il fatto che oltre 1.400 record contengano soltanto identificativi interni riduce il rischio diretto rispetto all’esposizione di nomi, diagnosi, Social Security Number o informazioni assicurative, ma non elimina la necessità di verificare se quegli ID possano essere correlati con altri dataset.

Continua con:

• Sanità sotto attacco: Aesto espone 9,5 milioni di pazienti
• SafePal espone quasi 40.000 clienti e riapre il rischio fisico per chi possiede hardware wallet

Il dato che non viene cancellato diventa una vulnerabilità permanente

I cinque incidenti mostrano problemi differenti ma convergono su una regola comune. Mathspace aveva una patch disponibile e non l’ha applicata prima dell’esfiltrazione. ShipMonk avrebbe dovuto cancellare i dati Trezor e invece li conservava ancora anni dopo. IDScan, se l’attribuzione verrà confermata, mostrerebbe i rischi estremi della concentrazione di documenti utilizzati per verificare l’identità di milioni di persone. Novocure dimostra invece quanto sia necessario distinguere tra semplici identificativi interni e informazioni sanitarie direttamente riconducibili al paziente. La vulnerabilità quindi non coincide sempre con una CVE. Può essere un processo di patching che non escalata un advisory critico, un contratto di cancellazione non rispettato, un provider terzo che accumula vecchi record o un’architettura che concentra documenti permanenti in un unico sistema. Il caso Trezor rende il problema particolarmente evidente: una politica di conservazione di 90 giorni avrebbe limitato drasticamente il breach, ma una copia che secondo il titolare non avrebbe dovuto più esistere ha esteso l’incidente a ulteriori 67.000 persone. Una volta esfiltrato, quel dato non può più essere richiamato, revocato o cancellato dal criminale. Per questo data minimization, verifica della cancellazione presso i fornitori e patch management devono essere trattati come controlli di sicurezza, non come semplici attività amministrative.