---
title: "Inside the Revolut Breach: The Fake Request That Passed Every Email Check."
description: "See how attackers turned a real government inbox into a path to Revolut customer data, and where the disclosure process should have stopped them."
category: "Attack breakdowns"
date: 2026-09-22
canonical: https://www.brside.com/blog/inside-revolut-breach-fake-request-email-checks
source: "Brightside AI"
image: https://www.brside.com/assets/inside-revolut-breach-fake-request-email-checks.D588W21a.jpg
---

# Inside the Revolut Breach: The Fake Request That Passed Every Email Check.

The attackers behind the Revolut data breach did not have to penetrate the bank’s network. They asked for customer records from a real government mailbox, and a process built to answer legitimate authorities released them. The request looked official, made sense as a cross-border demand and travelled through infrastructure that ordinary email checks would recognise as genuine. None of that revealed who was at the keyboard.

[TechCrunch reported](https://techcrunch.com/2026/09/12/revolut-confirms-customer-data-breach-through-fake-government-requests/) that Revolut confirmed the disclosure after receiving fraudulent requests from a legitimate government agency email domain. That distinction matters. The confirmed incident is narrower than the attacker’s wider claims, but it also points directly to the missed control: the requester was not independently verified before the data left Revolut.

## What happened in the Revolut breach?

[SecurityWeek reported](https://www.securityweek.com/revolut-data-breach-5-months-680-high-profile-accounts-3m-ransom/) that roughly 680 customers across 33 countries were affected during about five months of fraudulent requests, with high-profile or high-value accounts among the targets. That is a small share of Revolut’s customer base. It is also a concentrated set of people whose exposed records ran far beyond basic account details.

[TechCrunch reported](https://techcrunch.com/2026/09/12/revolut-confirms-customer-data-breach-through-fake-government-requests/) that the disclosed data included names, dates of birth, postal and email addresses, phone numbers, passports or driving licences, verification selfies, account statements and transaction histories. A dataset like that is closer to a complete identity and financial dossier than a conventional leak of email addresses and passwords. For a victim selected because of wealth, prominence or access, it can expose relationships, routines, holdings and the documents used to prove identity.

Revolut said its systems and customer funds were unaffected. The attackers did not use this route to enter customer accounts or move money during the incident; they turned an authorised disclosure workflow into the extraction mechanism instead. That leaves a different investigative trail, but it does not make the disclosed files less sensitive.

A conventional intrusion review starts with applications, infrastructure and customer accounts. Here, the critical trail runs through the intake mailbox, legal review, requester validation, approval records and the exact files returned. A clean network perimeter cannot clear the process that moved the data. Nor does a relatively small victim count capture the impact when each record contains several durable proofs of identity and a detailed financial history.

## How the attackers turned a stolen mailbox into a data request

The public evidence supports a six-stage chain, although not every stage carries the same level of certainty. Revolut confirmed the disclosure. Later reporting and threat-intelligence assessments supply other parts, while the threat actor’s broader claims remain unverified.

### 1. Credentials were captured outside Revolut

SecurityWeek’s account says threat-intelligence firm Hudson Rock assessed that infostealer malware had captured credentials for an Italian government mailbox. The attacker likely obtained them from existing stealer logs rather than compromising Revolut or mounting a new intrusion against that official.

Infostealers collect saved passwords, browser cookies and active sessions from infected devices. The resulting logs can be searched and sold according to the institution or service a buyer wants to access. A government credential may therefore change hands long after the original infection and give a criminal a ready-made identity inside an organisation they never targeted directly.

### 2. The real mailbox became an operating position

Later reporting linked the requests to a compromised account on `pec.interno.it`, a certified-mail domain used by Italy’s Ministry of the Interior. This was an [email account takeover](/blog/email-account-takeover) rather than a lookalike address pretending to be one.

Reporting described persistence and concealment inside the mailbox, including the addition of a recovery address, deletion of fraudulent outgoing messages and collection of replies before the legitimate user saw them. Those details have not been confirmed publicly by Revolut, but they explain how the same access could support repeated requests over months. The attacker was managing a trusted channel while trying to keep its legitimate owner unaware.

### 3. The target and jurisdiction made the request plausible

The fraudulent requests went to Revolut Bank UAB, the Lithuanian-licensed entity serving much of Revolut’s European business. A request from an authority in one European country to a regulated entity in another is not inherently unusual. Cross-border cooperation gives such a request a credible institutional shape.

Reviewers assess more than a sender address. They also ask whether the named authority could have a reason to seek the records, whether it is contacting the correct legal entity and whether the cited process resembles a real one. The attacker appears to have understood enough of that environment to place the request inside a familiar category rather than inventing an obviously impossible demand.

### 4. Genuine infrastructure carried a fraudulent instruction

The request then arrived from a legitimate government email domain. A spoofed address only imitates a trusted sender. A compromised mailbox lets an attacker use the trusted sender’s actual infrastructure.

The message carried several reinforcing signals: an authentic domain, the identity of a public authority, a plausible cross-border reason for contact and the urgency associated with legal or investigative work. None proved that the authorised official had written the request. Together they made the demand look routine enough to enter the disclosure process.

### 5. Customer data was released before independent verification

Revolut eventually verified the request through another channel and discovered the fraud, but the verification came after customer records had been disclosed. The sequence converted a suspicious request into a confirmed incident.

An independently sourced callback, a known agency portal or another out-of-band route would have asked a different question from email authentication: does the originating authority confirm this specific request and the person making it? That check had to happen before disclosure, while the bank still controlled the data.

### 6. The disclosed records became leverage

Reporting later described customer dossiers being published on Telegram and an extortion demand that changed sharply over several days. Publication and extortion came after the extraction. The attackers first exploited the request workflow, then used possession and publication of the records as leverage.

The threat actor also claimed a much larger theft from Italian law-enforcement systems. The wider claim has not been independently established and should not be folded into the confirmed Revolut breach. What Revolut confirmed is narrower: an unauthorised party used fraudulent requests from a legitimate government domain to obtain customer information.

## Why every email check passed

SPF, DKIM and DMARC are valuable because they answer questions about infrastructure. SPF checks whether a server is authorised to send for a domain. DKIM uses a cryptographic signature to show that an authorised system signed the message and that covered content was not altered after signing. DMARC tells a receiving domain what to do when authentication and domain alignment fail.

In this case, the infrastructure was the convincing part. A criminal operating a genuine government account could send a message that passed technical authentication while making a false claim of human and legal authority. The checks could not tell Revolut whether the person using the mailbox was its legitimate owner, still had authority to act or had attached a request connected to a real investigation.

That is where delivery evidence ends and the compliance decision begins. A reviewer still has to establish who is asking, whether the agency confirms the request, whether the requester has the cited legal power and whether the records sought are necessary for the stated purpose. In a busy queue, those questions can blur together. An authentic domain lends credibility to the signature, the signature to the claimed role, and the role to the supposed authority.

The controls worked as designed. The workflow asked them to prove more than they could. Another rule for inspecting the From address would not have fixed that problem because the domain was genuine; the falsehood concerned who controlled the account and whether they had the authority they claimed.

## The stop that came too late: verify the requester outside email

The decisive control is simple to describe: verify the requester through a channel that does not depend on the message under review, and do it before releasing any records. Making that happen quickly and consistently under pressure is the harder part.

The [FBI’s 2024 guidance](https://www.ic3.gov/CSA/2024/241104.pdf) on fraudulent emergency data requests tells organisations to examine signatures, logos and cited legal codes, and to contact the sender and originating authority when validation is needed. The Revolut case shows why the second part carries more weight when a mailbox is compromised. Message inspection can find a poor forgery. It cannot reliably expose a capable attacker working inside the authentic account.

The contact route has to be independent. Calling a number in the request, replying to the same mailbox or following a link supplied by the sender keeps the verification inside channels the attacker may control. The reviewer needs a pre-established agency contact, a number from a trusted directory, a known request portal or another verified route, then must confirm the request reference, named official, legal authority, affected subjects and scope of data sought.

Identity is only one gate. The UK [Information Commissioner’s Office](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/sharing-personal-data-with-law-enforcement-authorities/) says organisations sharing personal data with law enforcement need a lawful basis, must consider necessity and proportionality and should disclose only the minimum personal data needed for the stated purpose. A real official can still submit an invalid, overbroad or misdirected request. Teams therefore need to validate the requester, the legal basis and the requested data separately.

Urgency increases the difficulty without removing the requirement. The [European Commission](https://commission.europa.eu/law/cross-border-cases/judicial-cooperation/types-judicial-cooperation/e-evidence-cross-border-access-electronic-evidence_en) says a European Production Order can require a service provider in another EU member state to respond within 10 days, or within eight hours in an emergency. Teams need pre-approved contacts, clear escalation routes and a second reviewer before that clock starts, not a verification process improvised during a live request. The same principle appears in broader guidance on how to [verify the action independently](/blog/how-to-prevent-business-email-compromise).

The FBI’s guidance supports the callback control, but a written rule does not show whether staff will follow it when a convincing caller invokes urgency and rank. [Brightside’s vishing simulator](/blog/vishing-simulator-updates), available with Brightside Pro or the Voice add-on, lets admins configure a live AI call that appeals to authority and applies pressure, then review the exercise’s failed rate and failed-rate trend. That exercise does not authenticate government requests or replace a callback procedure. It gives employees a chance to practise the moment when they must stop, switch to the independent channel and escalate. The operational control still belongs in the disclosure workflow.

## Five months of requests changes the monitoring question

A credible request may defeat an individual reviewer. A months-long campaign, however, creates patterns that centralised monitoring should have a chance to expose.

A central request log should make it possible to review repeated demands from the same authority, unusual concentrations of high-value customers, requests spanning many countries, expanding data scope and sudden changes in volume. It should also connect verification results and approvals to each disclosure. Public reporting does not establish which monitoring controls Revolut had or which specific alert was absent.

Useful monitoring depends on structured fields rather than a folder of message threads. Teams need to compare the claimed agency, requesting official, legal route, urgency, customer type, requested data, callback result and approvers. A threshold does not have to declare a request fraudulent. It can require another review when several unusual attributes appear together or when one sender repeatedly seeks unusually sensitive records.

Each function sees a different part of the risk: Legal may assess authority, Privacy may test necessity and proportionality, Compliance may process the response, and Security may know that credentials for a public body are circulating or that a sender account behaves unusually. Kept apart, those views allow a five-month sequence to look like a series of valid one-off cases instead of a pattern that warrants investigation.

## Why leaked KYC records create a second attack surface

Revolut’s statement that customer funds were unaffected describes the immediate event, not the useful life of the exposed records. Passports, driving licences, selfies and contact details can support identity impersonation and account-recovery fraud. Statements and transaction histories give a later approach the private detail it needs to feel credible.

Combined, the fields are more useful than any one of them alone. Identity documents help an attacker answer biographical checks. A verification selfie can strengthen an impersonation package. Contact details reveal where to place the approach, while transaction records supply names, dates and amounts that a victim may recognise. Some fields can be changed after a breach. A date of birth, document image already in circulation or historical payment record can remain useful for years.

An attacker contacting the victim, or someone who serves them, can refer to a real payment, merchant, balance pattern or personal detail. The approach may then ask the target to “secure” an account, approve a transfer, replace payment details or disclose another authentication factor. If the records reveal addresses, routines or substantial holdings, high-profile customers may also face physical targeting.

The downstream attacker also benefits from uncertainty about the original incident. A message that refers to a real breach and offers to “help” can reach a victim when they already expect contact from the bank. Customer communication therefore needs a clear description of what Revolut will and will not ask people to do, plus a trusted route for checking any follow-up approach.

[Business email compromise](/blog/what-is-business-email-compromise) is one likely pattern for this follow-on stage. Using the leaked context, criminals can impersonate a bank employee, adviser, supplier or executive and make an ordinary fraud request unusually convincing.

Teams can prepare for that risk with [role-based training against targeted phishing](/blog/train-employees-against-ai-phishing-attacks) rather than a generic annual example. Brightside’s vendor-impersonation and business-email-compromise simulations track opens, clicks, credential submissions and reporting. Those measurements help teams rehearse the follow-on attacks that leaked KYC and transaction context can make more persuasive. They do not detect a compromised government mailbox or authenticate a legal demand. The results show how employees respond when a trusted identity asks them to act.

## What security and compliance teams should change now

The aim is to stop a fraudulent request before disclosure while preserving a fast route for genuine authorities.

1. **Inventory every intake route.** Document the mailboxes, portals, forms and regional teams that can receive government or legal demands. A verification standard cannot work if requests enter through channels the central process does not cover.

2. **Verify the requester independently.** Contact the originating authority through a number, directory, portal or relationship established separately from the incoming message. Confirm the named official and the specific request. Do this before records are assembled or released.

3. **Validate authority and legal basis as separate checks.** A genuine sender does not automatically have jurisdiction or a lawful basis for every demand. Review the cited power, the affected legal entity, the deadline and any emergency claim on their own merits.

4. **Release only what is necessary.** Match each disclosed field to the stated purpose. An overbroad response magnifies the harm if the request is fraudulent, misdirected or later mishandled.

5. **Require a second approval for sensitive releases.** Passports, selfies, statements and transaction histories deserve stronger review than low-sensitivity subscriber details. A second approver should confirm that requester verification, legal review and data minimisation are complete.

6. **Log requests and monitor the pattern.** Store sender, authority, jurisdiction, customer profile, requested fields, verification method, approvers and outcome in one searchable record. Review concentrations and changes over time instead of assessing every request as an isolated event.

7. **Rehearse the escalation path.** Put reviewers through realistic authority and urgency scenarios, including phone follow-ups. Test whether they can pause, find the independent contact, reach the right internal owner and hold the disclosure until verification is complete.

The playbook should also define stop conditions. If the agency cannot be reached, the reference cannot be confirmed, the legal entity is wrong or the requested scope exceeds the stated purpose, disclosure pauses and the designated owner handles the escalation. That decision should be recorded with the evidence considered, including how the independent contact was sourced.

The steps separate identity, agency confirmation, legal basis, data necessity and secondary approval into distinct checks. No mailbox, however authentic, should satisfy all of them on its own.

## FAQ

### What happened in the Revolut data breach?

Attackers used a legitimate government agency email domain to submit fraudulent requests for Revolut customer records. Revolut disclosed information before an independent check established that the requests were false. [SecurityWeek reported](https://www.securityweek.com/revolut-data-breach-5-months-680-high-profile-accounts-3m-ransom/) that roughly 680 customers across 33 countries were affected during about five months.

### Was Revolut hacked?

Revolut said its systems and customer funds were unaffected, so this was not reported as an intrusion into the bank’s technical environment. The attackers instead compromised a government mailbox and abused Revolut’s process for responding to official data requests. The disclosure workflow, rather than Revolut’s network perimeter, was the route to the data.

### What data was exposed in the Revolut breach?

The exposed data included identity and contact information, passports or driving licences, verification selfies, account statements and transaction histories, according to TechCrunch. The exact records varied by customer. Revolut said the incident did not affect customer funds.

### How did the fake government request work?

The attacker used a real government mailbox, so the message could pass ordinary sender-authentication checks and appear to come from a legitimate authority. The request also had a plausible cross-border context. Customer data was released before the bank verified the requester through a separate channel. Revolut later performed that check and identified the fraud.

Email authentication can establish that approved infrastructure handled a message. It cannot establish who controls the mailbox, whether that person is authorised or whether the demand is lawful and proportionate. Collapse those questions into one, and a genuine domain can carry a fraudulent instruction all the way to disclosure. Independent verification has to happen while the organisation still controls the data.