680 Passports, One Real Government Mailbox: The Revolut Disclosure That Passed Every Check

On September 12, 2026, Revolut confirmed that it had sent customer passports, verification selfies, bank statements and transaction histories to someone who was not the government agency they claimed to be. Nobody broke into Revolut. Nobody phished a Revolut employee's password. The requests arrived from a real mailbox on a real government domain, and the people whose job is to answer those requests answered them.

Revolut hasn't published a number. It told TechCrunch that a "limited" number of customers were affected. The Financial Times put the figure at 680, and a source close to the bank confirmed that count to City AM. Out of more than 80 million customers, 680 sounds small. Then you look at who they were.

Who got picked, and why that matters

The attackers didn't want a random slice of the customer base. The Record reported that the targets skewed toward wealthy customers, many working in crypto. Crypto entrepreneur Marc Zeller posted that he woke up on a Saturday to find "all my data leaked by Revolut." Former Mt. Gox CEO Mark Karpelès says he was affected too. Crypto investigator ZachXBT shared Revolut's notification email on his Telegram channel and said the operation looked aimed at high-net-worth users.

That tells you something about how the requests were written. These weren't bulk "send us everything" demands. Someone arrived with a target list and asked for specific people, which is exactly what a real investigator does. A narrow, named request looks more legitimate than a broad one, not less.

According to customer notices reported by TechCrunch, The Record and Malwarebytes, the disclosed data included:

• Dates of birth, home and email addresses, phone numbers
• Copies of passports and driver's licenses
• The selfies customers took during identity verification
• Account statements, IBANs, withdrawal records and transaction histories, including Bitcoin activity

Revolut says passwords and funds weren't touched. That's true, and it also misses the point. A passport scan, a matching selfie and a list of which wallets someone withdraws to is a complete kit for SIM swaps, account recovery fraud at other exchanges, and the kind of physical-world targeting crypto holders already worry about. You can rotate a password. You can't rotate your face.

The extortion layer

A Telegram account claiming responsibility posted what it said was stolen data, then got suspended. The Record said not all of it could be verified, though one customer whose data appeared didn't dispute it was genuine. Images from that account suggested the emails came from an Italian government domain. Several Italian authorities didn't respond to The Record's questions, and Revolut still hasn't named the agency.

Reports citing the FT say a group calling itself "Revolut Smilik" demanded 10,000 Bitcoin, then dropped the ask to $3 million with a 24-hour deadline to sell the 680 files. A separate actor using the handle "IAmNotAVillain" claimed the operation ran for six months through compromised Italian law enforcement systems. Treat that last claim as unverified. If it's even partly true, though, this wasn't one lucky email. It was a pipeline.

The UK Information Commissioner's Office told City AM it had received a report and was assessing it. The Financial Conduct Authority said it was aware and engaging with the company.

This playbook is older than most compliance teams

I've worked incidents where the root cause turned out to be "we did what the letter told us to do." They're the hardest post-mortems to write, because nobody made a mistake you can point at.

Fraudulent emergency data requests aren't new. In 2021 and 2022, people linked to Lapsus$ used hacked law enforcement accounts to send forged requests to Apple, Meta and Discord, and got user data back. In November 2024 the FBI published a public service announcement warning about an increase in criminal forum posts selling access to compromised government and police email accounts, specifically so buyers could send fake emergency requests. Those mailboxes usually get compromised the same way everyone else's do: infostealer logs, reused passwords, a session cookie lifted from a laptop. We wrote about how automated that harvesting has become in our breakdown of the Zerofot credential scanner. A police officer's webmail password sits in the same stealer dumps as a gamer's Steam login. It just sells for more.

So the attack chain is short:

1. Buy or steal access to a government mailbox.
2. Write a request that looks like the dozens of real ones the target's legal team handles every week.
3. Name specific high-value customers.
4. Wait for the reply.

No exploit. No malware on the victim's network. No login to the victim's systems at all.

Every check passed. Here's each one.

The easiest reaction is "Revolut should have verified the sender." I think they probably did, by the standard most companies use. Walk through what a typical legal-requests desk checks and you'll see why it didn't matter.

Was the sending domain legitimate? Yes. That was the whole trick. Revolut's own statement said the fraudster "utilised a legitimate government agency domain email." Not a lookalike domain. The real one.

Did SPF, DKIM and DMARC pass? Almost certainly. The message came from the agency's actual mail infrastructure. Email authentication proves which server sent a message. It says nothing about who was typing. This is the line I keep coming back to: domain verification authenticates the mailbox, not the person.

Did the request look right? Presumably. If the IAmNotAVillain claim holds, the attackers had real law enforcement templates, real case formatting, and maybe real officer names. Legal teams pattern-match on format because that's all they have.

Was the scope reasonable? Yes, and this is the uncomfortable one. Asking about a few named individuals is the most normal request a financial institution gets. The trained red flag is a request that's too broad. This one was narrow on purpose.

Was it urgent? Emergency requests are urgent by definition. The whole point of the emergency process is that you skip the court order because someone might get hurt. That shortcut is what attackers are buying.

Each control did its job. The design flaw is that the chain of trust ends at a mailbox, and mailboxes are credentials. When the mailbox is compromised, every check downstream inherits the lie. It's the same shape as the McKesson vishing breach, where valid Okta sessions made every later action look authorized. The identity was real. The person behind it wasn't.

The compliance desk is a privileged account

Here's the part I'd push every security team to take away from this. Your law enforcement response team can export passports, selfies and full financial histories for any customer, on request, to an outside party, with no MFA on the requesting side. By any sane definition that's one of the most privileged data paths in the company. Almost nobody models it that way.

Security teams put PAM around database admins and require approval workflows for production access. Then the legal operations inbox, staffed by people trained in regulation rather than adversaries, runs a manual export process that ends with a PDF attached to an email. No anomaly detection on the export. No second channel. Nothing in the SIEM, because from the logging system's point of view an authorized employee ran an authorized report.

If you run an IR tabletop this quarter, try this one: "A request from a real police mailbox asks for KYC files on five named customers. The mailbox is compromised. Which of our controls fires?" I've asked versions of that question in rooms, and the usual honest answer is "none, until the customer calls."

What would actually have caught it

There's no single fix, but there are layers that break the chain at different points.

Verify out of band, every time, on a number you already had. Not the phone number in the email signature. A callback to the agency's switchboard from a directory you maintain, asking for the named officer and the case reference. It's slow and annoying. It's also the only check here that doesn't route through the compromised mailbox. For emergency requests, a quick callback beats a leaked passport archive.

Move requests off email. Several large platforms now take law enforcement requests only through an authenticated portal with registered officers. That doesn't solve compromised officer accounts, but it adds a second credential the attacker has to steal, and it gives you login telemetry to look at.

Rate and pattern checks on the disclosure side. Six months of requests, if that claim is right, is a pattern. One agency suddenly asking for crypto-heavy, high-balance customers across several requests is a signal your fraud team would catch instantly if the same pattern showed up in transactions. Point that same analytics at the disclosure log.

Put a tripwire inside what you send. This is where deception earns its place, and it's the layer I'd add first because it's cheap. Every disclosure package can carry a honeytoken: a tracked document or a unique link in the cover sheet that calls home when opened. A real agency opens it from its own network, on a predictable schedule. A fraudster opens it from a residential VPN, a hosting provider, or never opens the cover sheet at all and just forwards the attachments to a Telegram channel. When the first beacon comes from an IP that has nothing to do with Italian law enforcement, you know on day one instead of when the extortion post lands. You'd also know which request, which case reference and which mailbox, so you can stop answering it.

To be honest about the limits: a careful attacker can strip beacons or open files in a sandbox with no network. We covered a phishing kit that does exactly that to canary tokens in our BigBear 2.0 teardown. But that kit was built because canaries work often enough to be worth defeating. Most extortion crews moving 680 files through Telegram aren't running a clean-room workflow. And a beacon that never fires is also data: a real agency that never opens its own case file is odd enough to prompt a callback.

Seed decoy identities in the KYC store. A few synthetic customer profiles, flagged internally as decoys, that no genuine request should ever name. If a disclosure request, an internal lookup or a bulk export ever touches one, that's a zero-false-positive alert. It won't catch a perfectly targeted request for real people. It will catch the attacker who got a target list from a scraped or leaked dataset where you planted those profiles, and it'll catch the insider browsing KYC files they shouldn't.

None of this needs a new platform. It needs someone to decide that the disclosure workflow is part of the attack surface, and then instrument it like one. That's the same approach we take for credentials and sessions across the rest of the environment, which you can read about on our solutions page.

The question to ask your own team

Revolut will get most of the blame here, and some of it is fair. Six months, if true, is a long time for a pattern to run unnoticed. But the uncomfortable truth is that most banks, fintechs, telcos and SaaS companies run the same process: trust the domain, check the format, send the file. The attackers didn't beat Revolut's security. They went around it, through a door that was built to open quickly for the right people.

So here's the question. If a real government mailbox asked your company for five customers' identity documents tomorrow, what would tell you the person behind it wasn't who the domain said? If the answer is "the domain," you have the same exposure Revolut had. If you want to see what a tripwire on that path looks like in practice, book a Mine2 demo and we'll walk through planting one on your own disclosure workflow.