Quando si parla di data breach siamo abituati a cercare una porta d’ingresso, ma nel caso che ha coinvolto Revolut in queste ore, almeno sulla base delle informazioni emerse finora, cercare quella porta potrebbe però portarci nella direzione sbagliata, perché nessuno avrebbe avuto bisogno di forzarla: è infatti bastato un messaggio di posta elettronica (probabilmente certificata) da una casella istituzionale compromessa.

La società ha comunicato ad alcuni clienti di aver consegnato informazioni personali e finanziarie in risposta a quella che appariva come una legittima richiesta proveniente da un’autorità governativa.

Soltanto in seguito, dopo ulteriori verifiche, sarebbe emerso che dietro quella richiesta non si trovava chi Revolut pensava ci fosse.

Non ci sarebbe stata, quindi, una compromissione diretta dell’infrastruttura della fintech: i dati sarebbero stati estratti attraverso un processo previsto e apparentemente legittimo, inducendo chi li custodiva a consegnarli volontariamente.

La natura delle informazioni coinvolte rende l’episodio particolarmente delicato. Secondo quanto comunicato agli interessati, tra i dati potenzialmente divulgati figurano nome e cognome, data di nascita, professione, indirizzo postale, numero di telefono e indirizzo e-mail, oltre a copie di passaporti o patenti e alle immagini utilizzate durante la verifica dell’identità.

A queste informazioni si aggiungono dati finanziari quali IBAN, stato e data di apertura del conto, riferimenti dei wallet, prelievi e cronologie delle transazioni, comprese quelle relative a Bitcoin.

Revolut ha precisato che i dati biometrici derivati dalla verifica facciale non sarebbero stati divulgati e che password, numeri delle carte, chiavi private e fondi dei clienti non risultano coinvolti.

È una distinzione tecnicamente importante, ma non sufficiente a ridimensionare la portata dell’incidente: un insieme di dati capace di collegare identità anagrafica, documento, immagine del titolare, recapiti e attività finanziaria possiede infatti un valore considerevole anche senza consentire l’accesso diretto al conto.

L’e-mail falsa che è tecnicamente autentica

L’elemento più interessante dell’intera vicenda riguarda l’origine della richiesta. Non si sarebbe trattato del classico messaggio proveniente da un dominio costruito per assomigliare a quello di un’autorità, magari sostituendo una lettera o utilizzando un sottodominio sufficientemente credibile.

Secondo quanto riportato nelle comunicazioni relative all’incidente, il messaggio sarebbe invece partito da un account non autorizzato creato o comunque presente all’interno dell’infrastruttura di posta elettronica di una vera autorità governativa.

Questo particolare cambia radicalmente la natura del problema. Il dominio era autentico e, di conseguenza, potevano esserlo anche i meccanismi utilizzati normalmente per stabilire la provenienza di un messaggio.

Per il sistema ricevente quell’e-mail poteva quindi apparire esattamente per ciò che dichiarava di essere: un messaggio trasmesso attraverso l’infrastruttura autorizzata di un’organizzazione istituzionale.

È qui che il caso Revolut diventa più interessante di un normale episodio di phishing. Tecnologie come SPF, DKIM e DMARC sono progettate per contribuire a stabilire se un messaggio sia stato effettivamente autorizzato dal dominio dal quale dichiara di provenire.

Non possono però stabilire se la persona che in quel momento controlla una casella appartenente a quel dominio abbia realmente l’autorità per chiedere la copia del passaporto, l’indirizzo di casa o la cronologia finanziaria di un cliente.

Si tratta della differenza, spesso sottovalutata, tra autenticità tecnica e legittimità. Possiamo dimostrare con un elevato grado di affidabilità che una comunicazione proviene da una determinata infrastruttura senza poter dimostrare, attraverso gli stessi strumenti, che chi la sta utilizzando sia autorizzato a compiere quella specifica azione.

Il paradosso di un sistema che può funzionare correttamente e fallire lo stesso

Il caso permette di osservare un paradosso particolarmente interessante della sicurezza moderna.

Possiamo ipotizzare che diversi controlli abbiano funzionato esattamente come previsto: il dominio era quello corretto, l’autenticazione della posta risultava coerente, la richiesta aveva una forma credibile e il processo interno contemplava la possibilità di fornire informazioni alle autorità competenti.

Un operatore poteva quindi trovarsi di fronte a una procedura apparentemente normale e portarla a termine seguendo le regole previste dall’organizzazione. Il risultato finale, tuttavia, sarebbe stato comunque una divulgazione non autorizzata di informazioni.

Negli ultimi anni abbiamo investito enormemente nella capacità di stabilire se un’identità digitale sia autentica, ma un’identità autentica può essere utilizzata dalla persona sbagliata.

Una volta compromesso un elemento sufficientemente alto nella gerarchia della fiducia, molti dei controlli che si trovano più in basso rischiano di perdere efficacia.

Il concetto può essere spiegato con un’analogia molto semplice. Un aggressore può tentare di falsificare la divisa di un agente di polizia e sperare che la contraffazione sia abbastanza convincente, oppure può riuscire a entrare in una centrale e impossessarsi di una divisa autentica.

Nel secondo caso il problema non è più distinguere il vero dal falso, perché ciò che viene presentato alla vittima è effettivamente autentico.

È il soggetto che lo utilizza a non esserlo.

Perché il problema non può essere ridotto all’e-mail

Definire l’accaduto semplicemente come un sofisticato episodio di social engineering rischia però di nascondere la questione più importante, che riguarda la progettazione dei processi attraverso i quali vengono gestite le richieste di accesso a informazioni particolarmente sensibili.

Non tutte le richieste dovrebbero avere lo stesso peso. La divulgazione di un singolo indirizzo e-mail presenta un determinato livello di rischio; una richiesta che comprende contemporaneamente documento d’identità, fotografia utilizzata per la verifica, indirizzo di residenza, IBAN e cronologia finanziaria completa appartiene evidentemente a una categoria differente.

All’aumentare della sensibilità e della quantità dei dati richiesti dovrebbe quindi aumentare anche il livello di verifica necessario prima di autorizzarne la consegna.

In circostanze simili, l’autenticazione del canale attraverso il quale arriva la richiesta non dovrebbe rappresentare da sola una prova sufficiente.

Diventa necessario introdurre una seconda verifica indipendente, secondo il principio della conferma out-of-band. Se una richiesta arriva attraverso la posta elettronica, per esempio, la sua autenticità può essere verificata contattando l’ente attraverso un numero o un canale ufficiale ottenuto indipendentemente, anziché utilizzando i recapiti contenuti nella stessa comunicazione che si sta cercando di verificare.

La considerazione interessante è che una contromisura del genere non richiede necessariamente un prodotto di cyber security particolarmente sofisticato.

Di fronte a un attacco capace di superare diversi meccanismi tecnici di autenticazione, una delle difese più efficaci potrebbe essere un processo organizzativo molto più semplice: una seconda verifica effettuata attraverso un canale differente. In alcuni casi, persino una telefonata.

Il KYC e il valore di un’identità completa

La vicenda solleva anche una questione più ampia riguardo alla quantità di informazioni che banche, fintech ed exchange di criptovalute sono tenuti ad accumulare per rispettare gli obblighi di identificazione della clientela.

I processi KYC hanno progressivamente trasformato questi soggetti in depositari di una rappresentazione estremamente dettagliata dell’identità dei propri utenti, nella quale informazioni anagrafiche, documenti, fotografie, recapiti e dati finanziari vengono concentrati nello stesso ecosistema.

Una simile raccolta di informazioni ha un valore molto diverso rispetto alla compromissione di una semplice credenziale. Una password può essere modificata in pochi minuti; una data di nascita, un volto o buona parte delle informazioni contenute in un documento d’identità non possono essere sostituiti con la stessa facilità. Il rischio aumenta ulteriormente quando dati apparentemente indipendenti vengono combinati tra loro.

Conoscere il numero di telefono di una persona è utile per un criminale. Conoscere contemporaneamente il suo numero, l’indirizzo di residenza, il documento utilizzato per aprire il conto, la data di apertura, l’IBAN e alcuni dettagli delle sue operazioni finanziarie permette invece di costruire campagne di social engineering di qualità completamente diversa.

Un aggressore potrebbe presentarsi come operatore della banca, dipendente di un exchange, funzionario di un’autorità fiscale o appartenente alle forze dell’ordine citando informazioni che la vittima ritiene possano essere conosciute soltanto da un interlocutore legittimo.

Il phishing smette così di essere una comunicazione generica nella quale il criminale tenta di indovinare qualcosa sulla propria vittima e diventa una conversazione costruita utilizzando informazioni reali sulla sua identità e sulla sua vita finanziaria.

La particolare sensibilità delle transazioni in Bitcoin

La presenza, tra le informazioni interessate, della cronologia relativa alle transazioni in Bitcoin aggiunge un ulteriore elemento di attenzione.

Una blockchain pubblica permette per sua natura di osservare transazioni e movimenti, ma ciò non significa che ogni indirizzo possa essere immediatamente associato all’identità anagrafica del suo proprietario.

Quando informazioni provenienti da un intermediario finanziario permettono di collegare un’attività on-chain a un’identità verificata, quella separazione può ridursi considerevolmente.

Per soggetti che dispongono di patrimoni rilevanti, la questione può quindi superare rapidamente i confini tradizionali della cyber security.

La disponibilità congiunta di informazioni sul patrimonio, movimenti finanziari, identità, indirizzo di residenza e recapiti personali non costituisce soltanto una base efficace per future attività di phishing, ma può trasformarsi in un problema di sicurezza personale.

L’investigatore on-chain ZachXBT ha avanzato l’ipotesi che l’operazione possa aver interessato un numero limitato di utenti con patrimoni elevati.

Si tratta, tuttavia, di un elemento che deve essere trattato con cautela: Revolut non ha pubblicamente confermato né il numero complessivo delle persone coinvolte né l’esistenza di un criterio di selezione basato sulla loro disponibilità finanziaria. In assenza di ulteriori elementi, l’ipotesi rimane quindi tale.

Quello che ancora non sappiamo

Numerosi aspetti dell’incidente rimangono al momento poco chiari. Non è stata resa pubblica l’identità dell’autorità governativa la cui infrastruttura sarebbe stata utilizzata, non conosciamo le modalità attraverso le quali l’account non autorizzato sia stato creato o compromesso e non è noto il numero esatto dei clienti interessati.

Allo stesso modo, non sappiamo se le informazioni ottenute siano già state impiegate per successive attività fraudolente.

Secondo le informazioni disponibili, Revolut avrebbe scoperto il problema dopo aver verificato direttamente la richiesta con l’autorità interessata. La società avrebbe quindi bloccato internamente l’indirizzo coinvolto, avviato le notifiche alle autorità competenti e adottato misure precauzionali nei confronti degli account interessati.

È inoltre opportuno distinguere questo episodio dalle precedenti affermazioni circolate nel luglio 2026 su un forum cybercriminale, dove un soggetto sosteneva di essere in possesso di circa 75 milioni di record riconducibili a Revolut.

In quell’occasione, la società aveva dichiarato di non aver individuato elementi che indicassero una violazione dei propri sistemi e aveva affermato che gli identificativi presenti nei campioni pubblicati non corrispondevano ad account validi.

Le due vicende, sulla base delle informazioni attualmente disponibili, non devono quindi essere sovrapposte.

Zero Trust funziona anche in questo caso?

La lezione più interessante dell’incidente riguarda probabilmente il modo in cui interpretiamo il concetto stesso di fiducia.

Da anni l’industria della cyber security promuove il modello Zero Trust, basato sul principio secondo cui nessuna identità, dispositivo o richiesta dovrebbe essere considerata affidabile soltanto in virtù della sua provenienza.

Identità e autorizzazioni devono essere verificate continuamente e nel contesto della specifica operazione richiesta.

Eppure questo principio rischia di interrompersi proprio nei processi nei quali la fiducia istituzionale viene considerata implicitamente sufficiente.

Una richiesta proveniente dal dominio autentico di un’autorità governativa possiede inevitabilmente un peso differente rispetto a una normale comunicazione commerciale, ma è proprio questa caratteristica a renderla particolarmente interessante per un attaccante.

Il problema, naturalmente, non riguarda soltanto Revolut. Qualunque organizzazione custodisca informazioni sensibili dovrebbe chiedersi cosa accadrebbe se ricevesse una richiesta formalmente perfetta proveniente dall’infrastruttura autentica di una forza di polizia, di un’autorità fiscale, di un tribunale o di un regolatore.

La domanda non è soltanto se i sistemi tecnici riconoscerebbero correttamente il mittente, ma se esista un processo capace di verificare attraverso un secondo canale che quella specifica richiesta sia stata realmente autorizzata.

Per molto tempo abbiamo costruito una parte importante della sicurezza attorno alla capacità di riconoscere il falso: il dominio contraffatto, il certificato non valido, il mittente falsificato, il sito imitato.

È un modello ancora necessario, ma non più sufficiente. Gli attaccanti possono infatti spostarsi più in alto nella catena della fiducia e cercare di impossessarsi proprio degli elementi che utilizziamo per stabilire cosa sia autentico.

Il caso Revolut, più che raccontare l’ennesima fuga di dati, mostra quindi un problema destinato a diventare sempre più importante: cosa facciamo quando una richiesta illegittima arriva attraverso un’identità e un’infrastruttura perfettamente legittime?

In quella situazione la tecnologia può certificare correttamente la provenienza del messaggio e, allo stesso tempo, condurci alla conclusione sbagliata.

È forse questo l’aspetto più interessante dell’intera vicenda: quando viene compromessa la fonte della fiducia, non è più sufficiente verificare che qualcosa sia autentico. Bisogna verificare anche che sia vero.