> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# Revolut Data Breach: 5 Months, 680 High-Profile Accounts, $3M Ransom
- URL: https://f4n6.co.uk/security-feed/revolut-data-breach-5-months-680-high-profile-accounts-3m-ransom/
- Published: 2026-09-17T20:10:51.000Z
- Updated: 2026-09-17T20:10:51.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

Revolut, a London-based fintech with more than 80 million customers, disclosed that it handed sensitive customer records to criminals who impersonated a government agency, submitting fraudulent "emergency data requests" from an email address on a legitimate government agency domain. The activity ran for approximately five months, reportedly affecting around 680 customers described as high-profile, with the attackers now demanding a $3M ransom (quoted as 10,000 Bitcoin) and posting samples of the stolen material to Telegram groups. Exposed data reportedly includes birth dates, postal and email addresses, phone numbers, copies of identity documents (passports, driving licences), and financial information. Revolut characterises this as an external impersonation scam rather than an intrusion into its systems, states that customer funds were not affected, and says it blocked the sending address and notified the relevant agency, law enforcement, data protection authorities and financial regulators. No verified CVSS/KEV data applies — this is a business-process compromise, not a vulnerability — and no named threat actor with a MITRE profile is identified, so attribution is unconfirmed.

## 2\. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item.

The incident is a third-party-originated social-engineering disclosure at a single fintech; the sources do not establish facts distinctive enough to trigger the listed articles for clients of this advisory. Clients who are Revolut customers with affected accounts, or who operate similar government-request handling processes, should assess their own position against DORA Art. 17 (ICT-related incident management process) and DORA Art. 18 (classification of ICT-related incidents and cyber threats) internally — but we do not assert those articles are engaged for the general client base on the facts provided.

## 3\. Technical analysis & attack chain

There is no technical intrusion to analyse. Revolut states its systems were not compromised; the attackers obtained data by abusing a trusted inbound channel. Confirmed and reported steps, numbered:

1. **Attacker obtained use of a legitimate government agency email account/domain.** The Record reports the fraudulent requests were submitted "from a legitimate government email account." It is not established from the sources whether the account was compromised, phished, or otherwise accessed — the mechanism is unconfirmed.
2. **Attacker submitted fraudulent "emergency data requests"** to Revolut from that address, impersonating the agency. Revolut has not identified the agency or disclosed the email domain.
3. **Revolut staff processed the requests as legitimate** and disclosed customer records — reportedly over a five-month period (single-sourced to the SecurityWeek headline reporting; verify before enforcement).
4. **Revolut detected the activity, blocked the sending address**, and notified the relevant government agency, enforcement agencies, data protection authorities and financial regulators. Revolut confirmed the incident on Saturday, September 12 (per Help Net Security).
5. **Extortion stage:** people claiming responsibility posted samples of the allegedly stolen data across several Telegram groups and demanded 10,000 Bitcoin (\~$3M per the headline reporting). Attribution to the actual perpetrators is unconfirmed — the Telegram posters' claim of responsibility is not verified.

**Data disclosed (per the customer notification described by Help Net Security and Malwarebytes):** birth dates, postal and email addresses, phone numbers, and copies of identity documents such as passports and driving licences. Malwarebytes indicates financial information was also disclosed; the primary item's headline references 680 high-profile accounts. Revolut has said only that a "limited" or "very limited" number of customers were affected and contacted them directly.

**What did NOT happen, per Revolut:** no intrusion into Revolut's systems, no effect on customer funds.

**Confidence caveats:** The five-month duration, the 680-account figure, and the $3M/10,000 BTC ransom demand are drawn from the SecurityWeek headline and DataBreaches.net reporting and are not corroborated by Revolut's own statements, which speak only of a "limited" number of affected customers. The Telegram sample postings are described but not independently verified in the sources. Treat these figures as single-sourced until Revolut or a regulator confirms.

## 4\. Mitigation & containment

This incident implicates **process controls around inbound data-disclosure requests**, not technical patching. For EMEA financial services clients, the relevant exposure is identical: a staffed channel that responds to "government" or "law enforcement" data requests.

### P1 — within 24h

- Inventory every channel by which your organisation accepts data-disclosure requests (legal, compliance, fraud, customer-ops inboxes) and confirm each has a documented verification procedure. If any channel accepts requests on domain-trust alone, suspend processing on it until a callback procedure exists.
- Require out-of-band verification for any emergency/urgent data request: callback to a independently-sourced number for the requesting agency, verification of the requester's identity and legal authority, and supervisory sign-off before disclosure. Domain trust is explicitly **not** verification — the attacker here used a legitimate government domain.
- Review the last five months of outbound data disclosures made in response to external agency requests. Look for repeated requesters, unusual urgency framing, requests outside normal legal process, or disclosures of identity documents.

### P2 — within 72h

- Brief front-line staff (compliance, legal, fraud, customer operations) on this incident pattern: impersonation via a legitimate government email domain, emergency framing, requests for identity documents and financial details.
- Add this scenario to social-engineering simulation and to incident-response playbooks as a distinct category (trusted-channel impersonation / fraudulent legal process), separate from phishing.
- Confirm your incident classification and reporting thresholds would capture a five-month delayed detection of this type — the detection gap here is the core failure.

### P3 — within 7 days

- If your organisation is a Revolut client with potentially affected accounts: check balances, cards, beneficiaries, recent transfers, statements and linked devices, and report unfamiliar activity through Revolut's in-app channels (per Malwarebytes guidance).
- Assess second-stage fraud exposure for any of your customers or staff whose identity documents may be in the disclosed set — the likely consumer impact is follow-on fraud and identity theft, not immediate unauthorised transfers.
- Review whether your own customer-notification content would clearly enumerate what was disclosed, as Revolut's notification reportedly did — affected parties need the specific data types to mount their own defence.

## 5\. Indicators of compromise

No indicators of compromise available in the source material.

### Behavioural indicators

| Behaviour                                                                                       | Where to observe                                                            | Confidence                                                                         |
| ----------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Fraudulent "emergency data requests" submitted from a legitimate government agency email domain | Inbound request mailboxes (legal/compliance/fraud), over a \~5-month window | High (multi-source: The Record, Malwarebytes, Help Net Security, DataBreaches.net) |
| Samples of stolen customer data posted to Telegram groups by people claiming responsibility     | Telegram monitoring / dark-web data-leak tracking                           | Medium (single-sourced to DataBreaches.net; verify before enforcement)             |
| Ransom demand of 10,000 Bitcoin (\~$3M) issued to Revolut                                       | Extortion communications; not directly observable by clients                | Medium (single-sourced; verify before enforcement)                                 |

## 6\. Detection

Insufficient indicators to author detection rules.

The sources contain no threat artefacts — no file hashes, strings, command lines, domains (Revolut has not disclosed the abused government domain), or log signatures. A rule keyed to "Revolut" or the agency name would detect reporting about the incident, not the threat. The defensive value here is procedural (see §4), not signature-based.

## 7\. Sources

- SecurityWeek — Revolut Data Breach: 5 Months, 680 High-Profile Accounts, $3M Ransom — https://www.securityweek.com/revolut-data-breach-5-months-680-high-profile-accounts-3m-ransom/ — 2026-09-17
- SecurityWeek — Personal, Financial Info Exposed in Revolut Data Breach — https://www.securityweek.com/personal-financial-info-exposed-in-revolut-data-breach/ — 2026-09
- Help Net Security — What we know about the Revolut data breach so far — https://www.helpnetsecurity.com/2026/09/14/revolut-data-breach-privacy/ — 2026-09-14
- DataBreaches.net — Hackers demand 10,000 Bitcoin from Revolut following data breach — https://databreaches.net/2026/09/15/hackers-demand-10000-bitcoin-from-revolut-following-data-breach/ — 2026-09-15
- The Record (Recorded Future) — Revolut handed customer data to fraudsters using government email account — https://therecord.media/revolut-scam-crypto-impersonation — 2026-09
- Malwarebytes Labs — Revolut gave customer IDs and financial data to a government impostor — https://www.malwarebytes.com/blog/news/2026/09/revolut-gave-customer-ids-and-financial-data-to-a-government-impostor — 2026-09

## 8\. Adverse Trace position

This is a high-impact business-process compromise with no technical vulnerability to patch, which is precisely why it matters: the attacker weaponised a legitimate government email domain and a trusted disclosure workflow, and the failure ran for roughly five months before detection. Severity for the affected individuals is high — identity documents, financial details and contact data on reportedly 680 high-profile people are now in criminal hands with an active extortion attempt attached — but the blast radius for the broader EMEA financial services client base is procedural, not technical. Attribution is unconfirmed: no actor is named, and the Telegram claim of responsibility is unverified; the 680-account figure, five-month duration and $3M demand are single-sourced pending confirmation from Revolut or regulators. Clients should treat this as a live test of their own inbound legal-process verification: any organisation that discloses customer data on the strength of a sender domain — government or otherwise — carries the same exposure today. We will monitor for confirmation of the affected-account count, identification of the abused agency domain, and any regulator or law-enforcement statement, and will update this advisory if verified indicators or attribution emerge.

---

[Read the original source →](https://www.securityweek.com/revolut-data-breach-5-months-680-high-profile-accounts-3m-ransom/?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*