Caso Revolut: il riscatto chiesto a chi non è stato violato

Seimila XMR entro ventiquattro ore, un countdown pubblico, meno di settecento clienti coinvolti. I sistemi della fintech hanno retto e i conti correnti non sono stati toccati. Il riscatto è stato chiesto lo stesso. Il sequestro riguarda la fiducia, e funziona solo perché quei file sono usciti leggibili.

Punti chiave

• Revolut non ha subito intrusioni. I dati di circa 680 clienti europei sono usciti rispondendo a una richiesta di autorità arrivata da una PEC istituzionale compromessa del dominio pec.interno.it, riconducibile alla prefettura di Reggio Calabria, con data di invio 24 luglio 2026.
• Il gruppo iamnotavillain ha chiesto 6.000 XMR, circa 3 milioni di dollari, con un conto alla rovescia pubblico di 24 ore, senza contattare direttamente la banca.
• Sistemi integri, conti intatti, zero downtime. Il report IBM Cost of a Data Breach 2025 rileva che l'86% delle organizzazioni violate subisce interruzioni operative: qui quella voce resta a zero, e il conto arriva lo stesso.
• Il Rapporto Clusit 2026 misura una crescita del 37% degli incidenti al comparto Gov, Mil e Law Enforcement rispetto al 2024. In Italia quel comparto è il primo settore per numero di attacchi, con oltre il 28% del totale.
• NIS2 (D.Lgs. 138/2024) e DORA (Reg. UE 2022/2554) hanno spostato la responsabilità sugli organi di vertice: chi tratta il dato risponde di come lo ha protetto, anche quando l'incidente nasce a monte e fuori dal suo controllo.
• Un documento cifrato all'origine, illeggibile fuori dal perimetro di chi lo ha prodotto, non avrebbe impedito la compromissione della PEC. Avrebbe tolto oggetto al countdown.

Un countdown pubblico, e nessun sistema violato

«6.000 XMR / 3.000.000 di dollari, altrimenti tutti i dati saranno venduti». Il gruppo che si firma iamnotavillain ha pubblicato la scadenza sul proprio sito, e diffuso i documenti su Telegram, invece di trattare in privato come fa di norma chi estorce. Revolut ha dichiarato che nessuno l'ha contattata direttamente. Il countdown, intanto, restava online.

I sistemi hanno retto e l'operatività non si è fermata un minuto. Nessun conto cliente è stato toccato. I dati sono usciti lo stesso, per la porta principale. La società ha ricevuto una richiesta di dati da un indirizzo che apparteneva davvero al dominio di posta di un ente pubblico, con credenziali valide, e ha inoltrato le informazioni come il GDPR impone quando a chiedere è un'autorità con un atto vincolante. Ha fatto quello che doveva fare.

La richiesta legittima è diventata il vettore

Le piattaforme finanziarie e cloud gestiscono decine di emergency data request al giorno. È una procedura ordinaria, prevista, documentata. L'attacco non ha dovuto aggirarla: l'ha usata come canale di consegna.

Secondo i documenti diffusi dagli stessi attaccanti e le ricostruzioni della stampa nazionale, l'indirizzo sarebbe una casella PEC riconducibile a un ufficio della prefettura di Reggio Calabria, con data di invio 24 luglio 2026. Da quelle stesse fonti risulta un accesso ai sistemi istituzionali durato quasi sei mesi senza essere rilevato. Il dato non è confermato: in Parlamento, il 18 settembre, il Governo ha riconosciuto la compromissione della casella senza avallare quella durata. L'Agenzia per l'Italia digitale ha dichiarato di avere osservato un aumento delle compromissioni di caselle PEC, e il dato non resta isolato: il Rapporto Clusit 2026 misura una crescita del 37% degli attacchi al comparto Gov, Mil e Law Enforcement rispetto al 2024. Quando l'anello che cede è un'istituzione, l'esposizione si scarica su tutte le organizzazioni che con quell'istituzione hanno l'obbligo di parlare.

Una continuità operativa che non si misura in downtime

Il report IBM Cost of a Data Breach 2025 rileva che l'86% delle organizzazioni colpite da una violazione subisce interruzioni dell'operatività. Nel caso Revolut quella voce resta a zero. La discontinuità si legge altrove: nel tempo che i vertici sottraggono al business per gestire la crisi, nelle notifiche ai clienti, nel dialogo con polizia postale, autorità di protezione dei dati e regolatori, nella copertura stampa che accompagna ogni ora del conto alla rovescia.

Lo stesso report mette sotto «perdita di affari» i ricavi persi per fermo dei sistemi, i clienti che se ne vanno e il danno reputazionale, contabilizzati insieme perché di solito arrivano insieme. Qui arrivano separati. Fermo macchina nessuno, conto da pagare comunque.

Una sproporzione che dice tutto

I clienti coinvolti sono poco meno di settecento, in vari paesi europei. Revolut ha superato i cinque milioni di clienti nella sola Italia, dove a maggio 2026 Milano Finanza la collocava al quinto posto tra le banche del Paese per numero di correntisti. Fra i record usciti e il danno di immagine non esiste alcuna proporzione aritmetica.

La spiegazione sta nella natura di quei dati: passaporti, patenti, documenti di identità, foto di verifica, storico delle transazioni. Materiale che serve ad aprire conti a nome di altri e che, una volta fuori, nessuna revoca richiama indietro. A dare valore all'estorsione è la leggibilità di quei documenti. Il numero conta poco.

Il conto lo paga chi custodiva il dato in chiaro

NIS2, recepita in Italia con il D.Lgs. 138/2024, e il Regolamento DORA (UE) 2022/2554 hanno spostato la responsabilità sugli organi di vertice. Entrambi presuppongono la stessa catena: chi tratta il dato risponde di come lo ha protetto, anche quando l'incidente nasce a monte e fuori dal suo controllo. Revolut non ha subito un'intrusione, ha risposto a una richiesta formalmente legittima, e si ritrova il proprio nome in cima a ogni articolo sul caso. Lo stesso meccanismo è aperto per qualunque azienda scambi documenti con la Pubblica Amministrazione, con un fornitore o con uno studio legale: la sicurezza dell'interlocutore resta invisibile dall'esterno, e la buona fede smette di proteggere il file nel momento in cui parte.

L'articolo 32 del GDPR chiede misure adeguate al rischio. Per molte organizzazioni questo si è tradotto in controllo degli accessi e cifratura dei canali, con il contenuto che torna in chiaro appena il canale si apre. Un documento cifrato all'origine, illeggibile anche dopo essere uscito dal perimetro di chi lo ha prodotto, non avrebbe impedito la compromissione di quella casella PEC. Avrebbe tolto oggetto al countdown.

Per anni la domanda di chi progetta sicurezza è stata come impedire agli attaccanti di entrare. Il caso Revolut ne impone una diversa a chi siede nei board: cosa resta in mano a un estorsore quando i dati escono da una porta che l'azienda aveva l'obbligo di aprire. Finché la risposta sarà «file perfettamente leggibili», il ricatto pubblico continuerà a presentare il conto ad aziende che non hanno commesso alcun errore tecnico.

Aggiornamento al 25 settembre 2026

Il 18 settembre la sottosegretaria all'Interno Wanda Ferro ha confermato in aula alla Camera la compromissione della casella. ACN, tramite CSIRT Italia, ha verificato l'attacco analizzando un campione di email fraudolente fornito dalla stessa Revolut, e ha indicato in otto i clienti italiani coinvolti sui 680 totali. L'ultimatum è scaduto senza pagamento. Intorno al 23 settembre il gruppo ha aperto un data leak site sulla rete Tor e ha iniziato a chiedere il riscatto direttamente ai singoli clienti, di cui dichiara di conoscere nome, indirizzo e disponibilità in criptovalute. La prima estorsione è fallita e il materiale continua a produrre valore. È la definizione operativa di un dato rimasto leggibile.

Valerio Pastore

Founder & CTO, CyberGrant Inc.

Domande frequenti

Che cos'è una emergency data request e perché è un vettore di rischio?

Una emergency data request è la richiesta con cui un'autorità giudiziaria o di polizia chiede a un operatore i dati di un utente, spesso con procedura d'urgenza e tempi di risposta stretti. Piattaforme finanziarie e cloud ne gestiscono decine al giorno. Il rischio non sta nella procedura, che è legittima, ma nel fatto che l'autenticazione poggia sull'indirizzo del mittente: se quella casella viene compromessa, l'attaccante non deve violare nulla, gli basta chiedere. Nel caso Revolut la richiesta è arrivata da una PEC del dominio pec.interno.it, riconducibile alla prefettura di Reggio Calabria, con data 24 luglio 2026.

Come si protegge un documento che l'azienda ha l'obbligo di consegnare?

Cifrandolo alla creazione, non al momento dell'invio. La protezione file-centric lega la chiave al file e non al canale: il documento resta illeggibile anche dopo la consegna, e l'accesso passa da un permesso che il titolare può revocare, tracciare o far scadere. In pratica cambia la domanda: non «chi può ricevere questo file», ma «chi può aprirlo, quando, e per quanto ancora». Con FileGrant la revoca post-condivisione e l'audit trail restano attivi anche su copie già uscite dall'organizzazione.

La cifratura del canale basta a proteggere i dati scambiati con la PA?

No, e il caso Revolut lo mostra bene. TLS 1.3 e PEC proteggono la trasmissione e certificano invio e ricezione, non la legittimità sostanziale della richiesta né il contenuto una volta consegnato. Il file torna leggibile a destinazione nel momento in cui il canale viene decifrato. Da lì in poi la protezione non esiste più: nessuna revoca, nessun controllo su copie e inoltri. L'articolo 32 del GDPR chiede misure adeguate al rischio, e per dati di identità il rischio non finisce con la consegna.

Cosa chiedono NIS2 e DORA quando l'incidente nasce fuori dal perimetro?

Entrambi attribuiscono la responsabilità agli organi di vertice del soggetto che tratta il dato, non a chi ha causato la compromissione a monte. NIS2 è recepita in Italia con il D.Lgs. 4 settembre 2024 n. 138, in vigore dal 16 ottobre 2024, con le misure operative attese entro ottobre 2026. DORA è il Regolamento (UE) 2022/2554, applicabile dal 17 gennaio 2025 al settore finanziario. La conseguenza pratica è che la sicurezza dei fornitori e degli interlocutori istituzionali va trattata come rischio proprio, documentato e misurabile.

Come si verifica una richiesta di dati che arriva da una casella autentica?

Con una verifica out-of-band: si conferma la richiesta su un canale indipendente da quello su cui è arrivata, tipicamente un contatto ufficiale recuperato dall'albo dell'ente e non dalla mail stessa. Accanto a questo servono log di correlazione, perché una casella che invia richieste a un ritmo anomalo è un segnale, dual control sulle consegne massive di documenti di identità, e la regola che i dati sensibili non viaggino mai come allegato leggibile, nemmeno dentro un canale certificato.

Che differenza c'è fra DLP perimetrale e protezione file-centric?

Il DLP perimetrale ispeziona il traffico in uscita e blocca ciò che riconosce come anomalo. In uno scenario come quello di Revolut non ha niente da bloccare: la richiesta è legittima, l'utente è autorizzato, il canale è quello previsto. La protezione file-centric parte dall'assunto opposto: il file esce comunque, quindi deve uscire già inutilizzabile per chi non è autorizzato ad aprirlo. Cifratura alla nascita, classificazione automatica, RBAC, revoca e audit trail che seguono il documento anche fuori rete.

Come si integra la protezione file-centric con SharePoint, OneDrive e PEC?

Si affianca, non sostituisce. I contenuti restano dove sono e gli utenti continuano a lavorare con gli stessi strumenti: il livello di cifratura e di policy si applica al file, lasciando intatte librerie, permessi e abitudini. Sul canale email lo stesso principio vale per allegati e messaggi attraverso EmailGrant, modulo di FileGrant, che mantiene il controllo sul contenuto dopo l'invio. Il punto non è cambiare piattaforma, è togliere agli allegati la proprietà di essere leggibili da chiunque li intercetti.