Immagine illustrativa generata con AI
La campagna di phishing contro Trezor ha sfruttato un’infrastruttura email affidabile dopo la violazione di Brevo
Attacco phishing a 347.000 utenti Trezor via Brevo: falsa vulnerabilità STM32 per rubare seed, sfruttando errore SAML SSO tra organizzazioni.
Testo generato da intelligenza artificiale, pubblicato senza revisione umana. Trasparenza IA
Un convincente avviso di sicurezza ha raggiunto circa 347.000 indirizzi
Una campagna di phishing segnalata il 10 settembre 2026 ha preso di mira i clienti di Trezor attraverso l’infrastruttura per le newsletter gestita dal provider email di terze parti Brevo. I messaggi fraudolenti sembravano provenire da [email protected], lasciando ai destinatari pochi dei consueti motivi per dubitare dell’identità del mittente.
L’email aveva come oggetto Critical Security Alert: STM32 Entropy Vulnerability. Sosteneva che una vulnerabilità nei microcontroller STM32 utilizzati dagli hardware wallet Trezor potesse esporre i seed dei wallet ad attacchi di forza bruta.
L’avviso era falso. Trezor ha dichiarato che i messaggi erano stati inviati senza autorizzazione e non rappresentavano una reale comunicazione dell’azienda relativa a una vulnerabilità. Non ci sono prove che gli aggressori abbiano compromesso i dispositivi Trezor, le relative protezioni crittografiche o l’hardware STM32.
Secondo la ricostruzione dell’incidente pubblicata da SecurityWeek, sono stati presi di mira circa 347.000 indirizzi email di Trezor memorizzati nell’account Brevo. Circa 2.500 destinatari hanno fatto clic sul link incorporato prima che il sito di phishing venisse disattivato, circa 20 minuti dopo il rilevamento.
Non è noto quanti siano i destinatari che hanno inserito informazioni sensibili. Trezor non ha comunicato perdite di criptovalute confermate né indicato quante persone abbiano inserito i dati di recupero nella pagina di phishing.
La combinazione di un dominio mittente affidabile, di una presunta emergenza legata alla sicurezza dell’hardware e di un sito progettato per sembrare un servizio legittimo di criptovalute ha reso la campagna insolitamente convincente. Non si è trattato semplicemente di spam inviato in massa con un nome visualizzato falsificato: l’attacco ha sfruttato l’accesso a un canale di comunicazione consolidato.
La falsa vulnerabilità STM32 era progettata per sottrarre i backup dei wallet
Il messaggio di phishing cercava di alimentare il timore legato alla generazione dell’entropia, un concetto tecnico che influisce direttamente sulla sicurezza delle chiavi crittografiche. Sostenendo che i componenti STM32 generassero seed vulnerabili, gli aggressori hanno fornito ai destinatari un motivo plausibile per agire immediatamente.
Il sito malevolo chiedeva quindi le informazioni di backup del wallet. Non sono stati resi pubblici dettagli tecnici sulla sua implementazione, sull’infrastruttura di hosting, sul codice per la gestione dei dati o sugli esatti campi richiesti.
L’obiettivo previsto è tuttavia chiaro: ottenere un seed di recupero avrebbe consentito a un aggressore di ricostruire il wallet della vittima e trasferirne gli asset. Transazioni di questo tipo possono essere irreversibili, anche se la vittima scopre rapidamente la frode.
Un provider legittimo di wallet non dovrebbe mai chiedere all’utente di inserire una frase di recupero, una chiave privata, un PIN o un codice di autenticazione in un sito raggiunto tramite un’email non richiesta. La sicurezza di un hardware wallet non può proteggere i fondi quando il relativo segreto di recupero viene fornito volontariamente a un aggressore.
Trezor ha avvertito i destinatari di non seguire il link e ha disattivato il dominio malevolo. Ha inoltre avviato un’indagine sia sulla compromissione del provider sia sul meccanismo che ha consentito agli aggressori di inviare messaggi usando un’identità email dall’aspetto legittimo.
Per la vulnerabilità di Brevo non è stato assegnato né divulgato alcun identificativo CVE. Non sono note neppure le versioni del software Brevo interessate, ammesso che il servizio in hosting preveda una gestione delle versioni applicabile al caso.
Un errore nell’autorizzazione SAML ha consentito l’accesso tra organizzazioni diverse
Brevo ha attribuito la compromissione sottostante a un errore di implementazione nel proprio sistema di Single Sign-On basato su Security Assertion Markup Language. SAML SSO consente a un servizio di affidarsi a un provider di identità esterno per autenticare gli utenti, ma deve anche limitare ciò a cui ciascuna identità autenticata può accedere.
L’aggressore ha prima creato un account Brevo e abilitato SSO per quell’account. Gli utenti legittimi di Brevo sono stati quindi invitati nella configurazione SSO controllata dall’aggressore.
Usando il proprio provider di identità, l’aggressore si è autenticato come quegli utenti invitati. L’errore critico si è verificato dopo l’autenticazione: Brevo non ha limitato correttamente l’accesso all’organizzazione per la quale era stata abilitata quella configurazione SSO.
L’aggressore ha potuto invece raggiungere tutte le organizzazioni Brevo disponibili per gli utenti impersonati. In pratica, una relazione di fiducia creata per un tenant è diventata una porta d’accesso ad ambienti appartenenti ad altri clienti e privi di collegamenti tra loro.
La distinzione è importante. L’autenticazione ha stabilito chi fosse l’utente secondo la piattaforma, mentre un’autorizzazione difettosa ha determinato in quali organizzazioni potesse entrare quell’identità. È stato quest’ultimo controllo a non riuscire a preservare i confini tra tenant.
Brevo ha dichiarato che l’accesso non autorizzato ha interessato complessivamente 138 account cliente. Sei sono stati utilizzati per inviare messaggi di phishing, mentre le informazioni di contatto sono state esportate da 43 account. Un avviso precedente indicava 120 account cliente interessati, ma la successiva analisi tecnica post-incidente ha portato il dato a 138.
Brevo ha riferito di aver rimosso l’aggressore, chiuso il percorso di accesso non autorizzato e implementato una correzione permanente per il problema di definizione dell’ambito dell’autorizzazione SAML. L’azienda ha inoltre dichiarato di voler collaborare con le autorità giudiziarie.
CoinTracking e BitBox sono rimaste coinvolte nello stesso incidente del provider
Trezor non è stata l’unica azienda di criptovalute i cui iscritti hanno ricevuto email malevole. Anche CoinTracking e BitBox hanno confermato campagne rivolte al pubblico delle loro newsletter, secondo le notizie sulle aziende di criptovalute interessate.
CoinTracking ha identificato Brevo come proprio provider e ha segnalato un messaggio intitolato Data Breach Notice: Please refresh API Keys as soon as possible. L’esca cercava di indirizzare i destinatari verso un link malevolo con il pretesto di mettere in sicurezza le loro credenziali API.
Chiavi API compromesse avrebbero potuto esporre i dati del portafoglio o consentire operazioni non autorizzate, a seconda dei permessi assegnati a ciascuna chiave. Non sono note né le perdite confermate né il numero di destinatari di CoinTracking interessati.
BitBox ha avvisato gli iscritti alla newsletter, ha contattato il proprio provider, ha segnalato i domini di phishing e ha dichiarato che la maggior parte dei link associati sembrava essere stata rimossa. Non ha comunicato quanti destinatari siano stati presi di mira né ha identificato pubblicamente Brevo nella dichiarazione citata.
L’impatto su più aziende mostra perché le piattaforme di marketing siano obiettivi preziosi. Un singolo errore di autorizzazione può esporre le mailing list di numerosi clienti e, allo stesso tempo, fornire accesso ai sistemi di distribuzione di cui i destinatari si fidano già.
I controlli di autenticazione delle email potrebbero non bloccare messaggi di questo tipo quando l’aggressore opera attraverso un’infrastruttura autorizzata. Dal punto di vista del server ricevente, il messaggio può apparire molto più legittimo rispetto a una normale falsificazione del dominio.
Le precedenti esposizioni di dati aumentano il rischio di attacchi mirati
La campagna condotta attraverso Brevo segue una violazione distinta legata a Trezor e riguardante ShipMonk, il provider dell’azienda per le spedizioni e la logistica. Trezor ha divulgato l’incidente ad agosto.
Una prima stima indicava circa 14.000 clienti interessati. Un aggiornamento del 4 settembre ha aggiunto 67.000 clienti negli Stati Uniti, portando il totale comunicato a 81.000.
I dati esposti comprendevano nomi e cognomi, indirizzi email e di spedizione, numeri di telefono e informazioni sugli ordini. Sono stati interessati clienti in Brasile, Colombia, Italia, Portogallo, Svezia e Regno Unito i cui ordini erano stati effettuati tra il 10 maggio e l’8 agosto 2026.
Secondo le notifiche relative alla violazione, gli aggressori hanno sfruttato una vulnerabilità zero-day critica di SQL injection nella piattaforma di analisi Metabase presente nell’ambiente di ShipMonk. La falla avrebbe consentito di ottenere l’accesso amministrativo e sottrarre dati. Non sono stati forniti identificativi CVE né le versioni di Metabase interessate.
Secondo il resoconto di BleepingComputer sugli incidenti, ShipMonk ha inoltre ricevuto email estorsive dal gruppo ShinyHunters. Gli altri articoli citati non hanno verificato in modo indipendente questa attribuzione.
In seguito, alcuni clienti Trezor hanno ricevuto per posta codici QR malevoli. Gli indirizzi fisici e i dati degli ordini possono aiutare i criminali a distinguere i reali proprietari di criptovalute dalle persone che si sono limitate a iscriversi a una newsletter.
Non è la prima esposizione di dati di Trezor causata da terze parti. Nel gennaio 2024, gli aggressori hanno compromesso il portale esterno per la gestione dei ticket di supporto dell’azienda, esponendo nomi, nomi utente e indirizzi email appartenenti a circa 66.000 utenti.
Le informazioni provenienti da violazioni diverse possono essere combinate. Un aggressore che disponga del nome di una persona, della cronologia degli acquisti legati a un wallet, del numero di telefono, dell’indirizzo e dell’email può costruire truffe di impersonificazione, estorsione o recupero dell’account molto più credibili.
Le conseguenze possono inoltre estendersi oltre le frodi online. Individuare i proprietari di criptovalute e i luoghi in cui vivono crea un rischio di furti con scasso, coercizione e cosiddetti attacchi wrench.
Cosa devono fare ora destinatari e organizzazioni
Chiunque abbia ricevuto l’email dedicata a STM32 dovrebbe considerarla malevola, indipendentemente dal fatto che sembrasse provenire dal dominio Trezor. Il link incorporato non deve essere aperto né visitato nuovamente.
Gli utenti che hanno inserito una frase di recupero devono presumere che il segreto del wallet sia compromesso. Trasferire gli asset su un wallet appena creato con un nuovo seed di recupero è più sicuro che limitarsi a cambiare il PIN, perché il vecchio seed rimane sufficiente per ricostruire il wallet.
I destinatari dovrebbero inoltre:
- Controllare la cronologia dei wallet e degli exchange per individuare transazioni non autorizzate.
- Sostituire le password e le chiavi API inserite dopo aver seguito link sospetti.
- Revocare i permessi API non necessari e le sessioni attive.
- Abilitare l’autenticazione multifattore, preferibilmente robusta, ovunque sia supportata.
- Accedere ai servizi di wallet ed exchange tramite applicazioni conosciute oppure digitando manualmente gli indirizzi ufficiali.
- Diffidare di successive telefonate, lettere, codici QR o servizi di “recupero” che facciano riferimento all’incidente.
Le organizzazioni che utilizzano Brevo o piattaforme di marketing simili dovrebbero verificare le relazioni di fiducia SAML e assicurarsi che l’autorizzazione venga applicata separatamente a ogni tenant e organizzazione. Dovrebbero invalidare sessioni e token, esaminare le attività amministrative e stabilire se le liste di contatti siano state consultate o esportate.
Il monitoraggio dovrebbe inoltre includere le campagne inviate attraverso domini legittimi, non soltanto gli evidenti tentativi di spoofing. In questo incidente, l’autenticità del canale di distribuzione faceva parte dell’attacco. L’inganno riguardava proprio l’avviso di sicurezza.
Fonti
Questo articolo è una rielaborazione originale basata sulle fonti seguenti.
