Criminals sent Revolut a request for customer information from a real government agency’s email address. The message passed every technical check, because the address was genuine. Revolut treated it as an official request and handed over the files.
About 680 customers were affected. Their passports, driving licences, verification selfies, account statements and full transaction histories went to the attacker. The people behind it now demand 10,000 Bitcoin, worth more than $782 million. Until it is paid, they are publishing customer dossiers on Telegram.
What is a fraudulent emergency data request? An emergency data request lets law enforcement obtain user data quickly, without a warrant, when someone is in immediate danger. Criminals abuse it by sending requests from stolen or compromised government email accounts. The receiving company sees a valid official address and complies.
The Ransom Covers More Than the Revolut Files
These 680 accounts of customers are just part of what has been taken for ransom. The ransomware claims that the customers’ records are only a byproduct of an extended campaign targeting Italian law enforcement.
This ransomware claims that its access into Italian law enforcement agencies lasted six months, during which the data had been requested from Revolut through the system itself. An additional 147GB of information was also obtained from Italian law enforcement agencies, according to the same ransomware account, including internal information, calendars and personal files.
The Revolut database is also considered larger than the one mentioned above. This database contains data from more than 30 countries, most of the records belong to Switzerland and France.
None of the Larger Claims Are Confirmed
Everything is the result of one individual, the extortioner of the bank using the name IAmNotAVillain who provided this information to a cyber news site.
No comment has been received from any Italian organizations regarding their involvement with the compromise of police systems. Revolut claims that there has been no breach of its system or money and has made no comment about the ransom demanded. There is no verification of the 147GB of data, six months or country list.
The verified aspect of this issue is more specific. The bank has released the full identity details of around 680 customers due to a legitimate request coming from a government email address.
What Revolut Handed Over
It was not simply an address list. The details leaked encompass full names, dates of birth, occupations, mailing addresses, email addresses, phone numbers, and copies of identity proofs.
The list contains verification selfies, statement accounts, IBANs, withdrawals and transaction logs, including Bitcoin transactions as well.
This means that everything required to build an identity has been exposed. It can be used for account takeovers and impersonations, and even physically targeting the person due to their crypto currency wealth. Ireland’s national broadcasting company stated that out of 680 victims, 12 were Irish citizens.
The Email Passed Every Check It Was Supposed To
Revolut explained an advanced external impersonation fraud scheme. It involved an unauthorized third party sending false requests using a genuine government department domain name.
It is worth noting the technical nature of the case. The message had valid domain authentication and therefore was processed with the assumption that the message was sent by a valid agency. There would be no chance for any spoofing filter to spot anything wrong.
The identity of the affected agency is currently not known. According to Italian news, the domain address was interno.it and the investigation is being conducted by the Postal Police. Official representatives deny the information.
When the Compromised Mailbox Is the Attack
A law enforcement request for user data without a warrant, justified by immediate risk to life.
Know Your Customer. The identity file a regulated financial firm must collect and keep, including documents and selfies.
Email standards that prove a message really came from a domain. They verify the sender, not the sender’s authority.
The check that a message was sent by a server allowed to use that domain. A compromised mailbox passes it.
Confirming a request through a separate channel, such as calling a published agency number.
The legal rights customers hold over their own records, which regulators enforce after an incident.
Authentication Is Not Authorization
All controls in this story have functioned properly, yet a violation happened nonetheless.
SPF, DKIM and DMARC are meant to provide an answer to one precise question: was this e-mail truly sent by the particular domain? They have nothing to say regarding the fact that the person at the other end of the keyboard might require a copy of the client’s passport. The mailbox of a hacked account carries all credentials of its domain.
The problem lies precisely in the following decision. The request to provide the most confidential data owned by the bank was granted based on the e-mail header only. Neither has the verification of the requesting officer been carried out through any independent channel, nor has any legal document been authenticated.
Where the Proof Should Live
We covered a breach with no exploit in it at all in Manchester Airports Breach Needed No Exploit at All. The same shape repeats here. Attackers work through legitimate channels, because those channels are trusted by default and rarely produce enforcement evidence.
A position worth defending is entitlement and proof. Entitlement means a request is considered legitimate and granted only after the requester is verified off-band, through a publicly listed number or agency contact page. Not from the email that made the request itself. Proof means the company can tell a regulator what record went out, on whose say-so, and what verification was done.
Regulators are investigating already. The United Kingdom’s Information Commissioner’s Office is investigating this breach. In early September the US Office of the Comptroller of the Currency conditionally approved a Revolut national bank license. This charter still needs deposit insurance and Fed signoff.
Detection mindset would ask if this was a suspicious message. And it wasn’t. An enforcement mindset would ask if the requester had any entitlement to the data, leaving a record of the decision. And this record is the only means by which any incident can be sized independently, outside the extortionist’s word alone.
Conclusion: The Email Was Authentic. The Authority Was Not.
The Revolut incident demonstrates a trust failure that conventional email authentication was never designed to prevent. The fraudulent requests arrived through a legitimate government agency domain, so the sender passed the technical checks normally used to distinguish genuine mail from spoofing. The failure occurred after authentication, when a trusted origin was treated as sufficient proof that the requester was entitled to receive highly sensitive customer records.
That distinction matters. SPF, DKIM, and DMARC can establish that a message was sent through infrastructure authorized for a domain. They cannot establish that the person controlling the mailbox is an authorized officer, that the legal request is valid, or that the requested scope is justified. When passports, verification selfies, financial statements, transaction histories, and other KYC records are involved, domain authentication should be the beginning of verification, not the final approval.
The incident therefore belongs as much to access governance as to email security. A sensitive disclosure should require independent proof of authority and leave evidence showing who approved it, what verification was performed, what data was released, and why.
Why This Threat Matters
- A legitimate sender can still make an illegitimate request. Compromised trusted infrastructure can pass normal email authentication.
- The target is the business process itself. No malware or exploit is required when an attacker can persuade an organization to release the information directly.
- KYC records create lasting exposure. Identity documents, selfies, contact information, and financial histories cannot be treated like passwords that can simply be reset.
- Urgency weakens verification. Emergency data procedures are designed for speed, which makes independent validation especially important.
- Detection cannot replace authorization. A message may contain no technical indicator of compromise while the resulting business decision is still unauthorized.
Where Defensive Control Must Operate
The decisive control is independent authorization before disclosure. Sensitive government requests should be verified through a known agency contact, published telephone number, authenticated portal, or another channel separate from the request itself.
Xcitium Cyber Awareness Education can reinforce this distinction for employees handling privileged requests, while Phishing Simulation can test whether staff pause, escalate, and independently verify trusted-looking but high-risk communications before acting.
Verify the Authority, Not Just the Sender
Organizations handling financial, identity, health, or other regulated data should treat authenticated email as evidence of origin, not evidence of entitlement. High-risk disclosures need a second trust decision: independently verify the requester, validate the legal authority and requested scope, require documented approval, and preserve that evidence so the organization can later demonstrate exactly why the data was released.
