What happened
12 September 2026: Revolut goes public. Revolut disclosed that it had shared sensitive customer data with an unauthorised third party. The requests had come from the email domain of a legitimate government body. The company blocked the address and alerted the body, law enforcement and regulators. It also stated that its systems and customer funds were not affected. Around 680 customers are involved, mostly based in Switzerland and France. The attackers selected them through blockchain analysis, targeting accounts with significant crypto balances.
The exposed data includes identity documents and KYC verification selfies, account statements, IBANs and transaction histories (Bitcoin included), personal details and contact information. In short, the complete file needed to rebuild someone’s identity.
13 to 15 September: the claim and the escalation. A threat actor calling itself IAmNotAVillain claimed the attack and began leaking one customer dossier a day on Telegram. Speaking to International Cyber Digest, the actor said the operation had run for six months and had reached several Italian law enforcement departments. The first independent reconstructions emerged in the same days.
16 to 17 September: investigations and ransom. The Public Prosecutor’s Office in Reggio Calabria opened an investigation for unauthorised access to a computer system of public interest (Article 615-ter of the Italian Criminal Code). The Italian Postal and Communications Police, the National Cybersecurity Agency (ACN), the Bank of Italy and the Italian Data Protection Authority also stepped in. On 17 September the group publicly demanded a ransom of 3 million dollars in Monero.
How the campaign started
According to the investigative team at Duel, which has been in direct contact with the attacker, initial access came through an infostealer. The malware harvested the email credentials of a public employee. The attacker then added a recovery address under their own control and ran the mailbox for months, deleting sent messages and replies before the legitimate owner could notice. Once it became clear that forged court orders would not get through, the attacker targeted Revolut Bank UAB. This Lithuanian subsidiary is required to respond to European Investigation Orders.
Hudson Rock, a firm specialising in cybercrime intelligence and infostealer data tracking, found around 300 compromised credentials on the pec.interno.it domain. In its view, the attacker most likely bought logs already in circulation rather than infecting the victims directly.
The PEC inbox and how the deception worked
In Italy, PEC (Posta Elettronica Certificata) is the certified email system that gives a message the legal value of registered mail. It is the standard channel for official communications from public bodies. Italian media traced the inbox to an office of the Prefecture of Reggio Calabria, the local branch of the Ministry of the Interior.
The Prefecture has denied sending any requests. Revolut has not named the body, citing the ongoing investigation. The technical point is simple: the messages came from a genuine inbox. SPF, DKIM and DMARC all passed, and no filter had anything to flag. The method, as reconstructed by Duel, relied on volume.
Hundreds of crypto transaction IDs were sent in bulk, and the bank replied with the matching account holders: a textbook “spray and pray” approach.
The published exchanges even show that in March Revolut explained to the requesters how to fix the header of their request. In May it apologised for a late reply. In July it announced a separate email with the password to decrypt the documents. The warning signs were not new. CERT-AGID, the emergency response team of Italy’s Agency for Digital Italy, had already warned that PEC certifies delivery, not the safety of the content. It has handled more than 650 cases of abused inboxes since the start of 2026.
Confirmed facts and open claims
The data of around 680 customers has been confirmed. Two claims remain unverified: the six-month duration and the alleged 147 GB stolen from Italian law enforcement, supported only by a screenshot from the attacker. Two different timeframes are circulating. The five months refer to the period in which Revolut answered the requests. The six months refer to the whole campaign, as claimed by the attacker. Only the first figure rests on documentary evidence.
A plausible compromise scenario
To understand how an attack like this is possible, it helps to start from the scenario it belongs to, without claiming to reconstruct exactly what happened to that inbox. The scenario is BEC, Business Email Compromise. An attacker takes over a legitimate mailbox and uses it to exploit the trust that sender carries. A single valid credential is enough, and more and more often it comes from an infostealer: malware that strips a browser of passwords, tokens and session cookies in a matter of seconds.
Session cookie theft is the least understood part. When you log in, the website gives your browser an identifier, so you don’t have to repeat the login and second factor on every page. Whoever steals it appears as a session that is already valid, and in some cases can bypass MFA entirely.
Once inside, the goal is to stay. Recovery addresses are quietly added, mail rules erase the traces, and logins happen at times and from locations consistent enough not to trigger any alert. No control, however mature, guarantees immunity against someone with patience and valid credentials. The result is an inbox that is authentic in every respect: real sender, official domain, every technical check green. At that point the problem moves to the other side of the conversation.
On the receiving end
For whoever receives the requests, the weak point is not technology but process. In scenarios like this, the recurring gaps are well known:
- a formally valid channel is treated as sufficient proof of legitimacy;
- there is no out-of-band verification through contact details registered in advance;
- there is no anomaly threshold on volume, frequency or the profile of the people being requested;
- requests are handled by legal or support teams, with no escalation to security;
- there is no central register that would show when something does not add up.
Five months of requests, all pointing at customers with high crypto balances, is a pattern. It was visible only to someone in a position to see the whole picture.
GRC: what you build before, not during
Everything that could have made a difference had to be in place before the first request arrived.
A procedure, not a habit. Separate roles for whoever receives, verifies and authorises the release of data. Verification through official contacts registered in advance, never those given in the request itself. A log of every request, useful both for detection and as documentary evidence.
Secure channels agreed upfront. Sensitive data should not travel by email, not even certified email. It belongs on dedicated portals, or behind encryption based on certificates the parties have exchanged in advance. This ties the communication to a technical identity rather than to an address: whoever controls the inbox still lacks the key to read it.
Less data, better classified. Identity documents and transaction histories must be classified, encrypted and released under the principle of data minimisation, even to an authority. A full release “just to be safe” only multiplies the damage.
One standard across the group. The attacker chose a foreign subsidiary subject to different obligations. This shows that uneven controls across entities of the same group are a vulnerability in their own right. The same applies to suppliers and partners that handle the same data.
Regulation and testing. GDPR requires notification within 72 hours. DORA requires financial entities to manage ICT risk in a structured way. NIS2 extends similar obligations to many more sectors. Meeting these obligations depends on the maturity of the DFIR function. Yet procedures only count if they are tested, through simulated fraudulent requests and audits of the request log. The most common gap is the distance between what is written down and what happens when someone is in a hurry.
Five lessons
- 1. It can happen to anyone. What was abused here was a duty to cooperate with the authorities, not an infrastructure. Legal processes are part of the attack surface too.
- 2. One inbox, four victims. A single set of credentials led to access to confidential communications, the impersonation of an authority, data exfiltration from a third party, public extortion and reputational damage shared by the public body, the bank and its customers. The perimeter you need to defend is no longer just your own.
- 3. An authentic channel is not a legitimate request. A process that does not allow anyone to say “let’s verify before we reply” is not a secure process.
- 4. Infostealers are still underestimated. They make no noise. All they produce is valid access, which is exactly what perimeter controls are not designed to stop.
- 5. Zero risk does not exist, but the difference does. It comes from integrating three capabilities:
- Cyber Threat Intelligence: monitors compromised credentials, both your own and those of your third parties.
- Security Operations Center: detects anomalous logins, unexpected mail rules and unusual request patterns.
- Digital Forensics & Incident Response: reconstructs the scope and the exfiltrated data, keeping the response anchored to the facts rather than to the attacker’s claims.
The bottom line
None of these controls would have guaranteed immunity. Together, though, they would have drastically shortened the five months in which an attacker operated undisturbed. The message is uncomfortable, and useful: even organisations that comply with the rules can suffer reputational and financial damage. The question is not whether you will be hit, but how quickly you will notice, and what tools you will have to prove it.
How exposed is your organisation?
Knowing your procedures exist is not the same as knowing they work. NEVERHACK brings together Cyber Threat Intelligence, Security Operations Center and Digital Forensics & Incident Response to spot compromised credentials early, detect anomalous activity and respond on evidence, not on claims.
