> ## 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 phishing texts appear days after data breach
- URL: https://f4n6.co.uk/security-feed/revolut-phishing-texts-appear-days-after-data-breach/
- Published: 2026-09-17T20:10:03.000Z
- Updated: 2026-09-17T20:10:03.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

Revolut has confirmed it disclosed sensitive customer records — identity and contact details, copies of passports and driving licences, verification selfies, and account statements/transaction histories — to an unauthorised party that submitted fraudulent emergency data requests from an email address on a legitimate government agency domain. Revolut characterises this as an external impersonation scam, not an intrusion into its systems, and states customer funds were not affected. Beginning Monday 14 September, two days after public acknowledgement of the breach, affected customers have received phishing SMS messages that appear in the same conversation thread as legitimate Revolut texts; at least one observed phishing page requests device camera access and imitates Revolut's live-video "turn your head" liveness check before prompting for a password. It is not yet confirmed whether the phishing campaign is operated by the same actors as the breach or by opportunists exploiting news coverage. No named threat actor has been identified in the available reporting; attribution is unconfirmed. The bottom-line risk for EMEA financial services clients is two-fold: direct exposure where staff or customers hold Revolut accounts, and a demonstrated, replicable social-engineering playbook — impersonating a trusted government domain to extract KYC-grade identity documents from a financial institution's data-disclosure process.

## 2\. Regulatory framing

| Article                                                                         | Trigger (the fact in this item)                                                                                                                                                                                           | Practical impact                                                                                                                                                                                           |
| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| DORA Art. 19: reporting of major ICT-related incidents to competent authorities | Revolut states it notified law enforcement, data protection authorities and financial regulators upon detection of the disclosure — a financial entity's own reporting path for a major incident is the live example here | Clients receiving fraudulent data requests should treat them as potential reportable incidents and pre-map the decision path to competent authorities, rather than handling them as routine correspondence |
| DORA Art. 28: ICT third-party risk — general principles                         | The compromise vector was a trusted external channel (a government agency domain) being abused to extract data — trust in external counterparties was the control that failed                                             | Verify data-disclosure requests through independent, out-of-band channels before releasing customer records; do not treat a request's origin domain as sufficient authentication                           |
| NIS2 Art. 21(2)(d): supply chain security measures                              | The same fact — a legitimate external domain was abused to obtain customer data — engages supply-chain security measures for in-scope entities that handle government or partner data requests                            | Include request-verification procedures for external data demands in supply-chain security measures, not only technical supplier controls                                                                  |

No specific UK NIS 2018 obligation is directly engaged by this item on the facts available.

## 3\. Technical analysis & attack chain

### Confirmed attack chain (breach)

1. An unauthorised party registered or otherwise used an email address on a legitimate government agency domain. The specific agency and domain have not been identified publicly.
2. The party submitted fraudulent emergency data requests to Revolut impersonating the government agency.
3. Revolut's disclosure process accepted the requests on the strength of the sending domain and released customer records. No compromise of Revolut's systems, malware, or credential theft was involved — the failure was procedural trust in the request channel.
4. Upon detection, Revolut blocked the sending address and notified the relevant government agency, law enforcement, data protection authorities, and financial regulators.
5. Revolut notified affected customers directly by email, specifying which data categories were disclosed. The company describes the number of affected customers as "limited" or "very limited"; no figure has been published.

### Data disclosed (per Revolut's customer notification, corroborated across sources)

- Identity and contact information: dates of birth, postal addresses, email addresses, phone numbers
- Copies of identity documents: passports and driving licences
- Verification selfies
- Account statements and transaction histories

### Observed follow-on activity

- People claiming responsibility for the incident have posted samples of the allegedly stolen information across several Telegram groups and demanded 10,000 Bitcoin from Revolut (single-sourced: DataBreaches.net citing Dev Kundaliya; verify before treating the extortion demand as established fact). Note this is an extortion demand, not ransomware — no malware or encryption is involved.
- From Monday 14 September, affected customers began receiving phishing SMS messages. In at least one case the message appeared in the same SMS conversation thread as genuine Revolut messages, lending it apparent legitimacy. This thread-placement effect is consistent with sender-ID spoofing of Revolut's SMS sender, though the mechanism is not confirmed in the sources.
- Per VirusTotal, the phishing domain was first scanned on 14 September — the same day the first phishing text was reported.
- In a separate observed example, opening the phishing link led to a web page requesting access to the device's camera. On granting permission, the page imitates Revolut's live-video "turn your head" liveness check, then prompts the victim to enter a password. This achieves two things: it makes the page appear authentic, and it may yield a selfie or video usable for further identity fraud, plus credentials sufficient to attempt a real login or account-recovery flow.

**Unconfirmed / single-sourced:** The link between the phishing campaign and the breach is not established — the sources explicitly state it is unknown whether the phishing uses breached data or whether unrelated scammers are exploiting news of the incident. The extortion demand and Telegram postings rest on a single DataBreaches.net report. The specific government agency, its domain, and the number of affected customers are all undisclosed. No named actor has a MITRE profile in the verified reference data (none was resolved for this item); attribution is unconfirmed.

## 4\. Mitigation & containment

This incident implicates process controls, not technical containment of an intrusion. Priorities below are framed for financial-institutions clients, both to protect their own customers and to close the same procedural gap in their own disclosure processes.

### P1 — within 24 hours

- Alert fraud and customer-contact teams to the Revolut phishing pattern: SMS appearing in the same thread as legitimate bank messages, links to pages requesting camera permission, a fake liveness check ("turn your head"), then a password prompt. Instruct staff and customers never to grant camera permission or enter credentials from a link in an unsolicited message.
- If your institution receives or processes emergency/government data requests: immediately require out-of-band verification (a callback to a independently-sourced official number, or verification through an established legal process channel) before any customer data is released. A request arriving from a legitimate government domain must not be treated as authenticated by domain alone — that is precisely the control that failed here.
- Review whether any data-disclosure requests received in the past 30 days were actioned on domain trust alone; retrospectively verify them.

### P2 — within 72 hours

- Block known-bad patterns at the web gateway: pages that request `getUserMedia` camera permissions immediately on load, on domains registered recently and unrelated to your brand. (No specific phishing domain is published in the sources; VirusTotal holds the scan record dated 14 September — pivot there once domains are shared through your intel feeds.)
- Brief customer-facing teams on the second-stage fraud pattern: exposed KYC documents (passports, licences, selfies) plus account statements enable convincing impersonation of the bank itself. Any customer contact referencing "securing" an account, reversing a transfer, or replacing documents should be treated as suspect and routed to verified in-app channels.
- For clients with Revolut accounts (corporate cards, treasury, staff): check balances, cards, beneficiaries, recent transfers, statements, and linked devices; report unfamiliar activity through Revolut's secure in-app chat.

### P3 — within 7 days

- Update fraud-detection rules to flag account-recovery and password-reset flows that follow a liveness-check-style video submission from a new device, where the customer's KYC documents were recently involved in a third-party disclosure.
- Add "fraudulent government data request" to your incident-response playbooks and tabletop scenarios, with a defined escalation path to legal, data protection, and financial regulators — mirroring the notification set Revolut engaged (law enforcement, data protection authorities, financial regulators).
- Review whether your customer-notification emails (in the event of a breach) inadvertently train customers to expect account-related contact — and pair any such notification with explicit anti-phishing guidance.

## 5\. Indicators of compromise

No indicators of compromise available in the source material. The phishing domain referenced in the Malwarebytes report is not named, and no hashes, IPs, or sender addresses are published.

### Behavioural indicators

| Behaviour                                                                             | Where to observe                                             | Confidence                                                                               |
| ------------------------------------------------------------------------------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------- |
| Phishing SMS appearing in the same conversation thread as legitimate Revolut messages | Customer-reported SMS threads; mobile device logs            | Medium — corroborated by Malwarebytes reporting; mechanism (sender spoofing) unconfirmed |
| Phishing page requests device camera access on load                                   | Web gateway/proxy logs; on-device browser permission prompts | Medium — single customer report via Malwarebytes                                         |
| Fake "turn your head" liveness check followed by password prompt                      | Endpoint web filtering; customer reports                     | Medium — single customer report via Malwarebytes                                         |
| Samples of allegedly stolen Revolut data posted in Telegram groups                    | Threat-intel monitoring of Telegram                          | Low — single-sourced (DataBreaches.net); verify before enforcement                       |

## 6\. Detection

Insufficient indicators to author detection rules.

The sources contain no named domains, hashes, sender addresses, or distinctive strings from the phishing kit. A YARA or Sigma rule built from vendor headline phrases or the product name would detect reporting about this threat, not the threat itself. Revisit once the phishing domain (VirusTotal first-seen 14 September) or kit artefacts circulate through intel channels.

## 7\. Sources

- Malwarebytes — Revolut phishing texts appear days after data breach — https://www.malwarebytes.com/blog/threat-intel/2026/09/revolut-phishing-texts-appear-days-after-data-breach — 2026-09-17
- 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
- SecurityWeek — Personal, Financial Info Exposed in Revolut Data Breach — https://www.securityweek.com/personal-financial-info-exposed-in-revolt-data-breach/ — 2026-09
- The Record (Recorded Future) — Revolut handed customer data to fraudsters using government email account — https://therecord.media/revolut-scam-crypto-impersonation — 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-revolt-following-data-breach/ — 2026-09-15
- DataBreaches.net — Revolut's paperwork breach shows why insurers are rethinking what counts as a 'cyber attack' — https://databreaches.net/2026/09/15/revoluts-paperwork-breach-shows-why-insurers-are-rethinking-what-counts-as-a-cyber-attack/ — 2026-09-15

## 8\. Adverse Trace position

This is a process-failure breach with a live, active follow-on phishing campaign — not a technical intrusion, and there is no CVE, patch, or malware signature to act on. Severity for EMEA financial services clients is moderate but actionable: the disclosed data set (passport/licence copies, verification selfies, full transaction histories) is precisely the material needed to defeat liveness checks and impersonate both the customer and the bank, and the observed phishing kit already weaponises a fake liveness flow. The extortion demand and the breach-to-phishing link are single-sourced or unconfirmed respectively; we are not treating them as established. The transferable lesson is the vector: a legitimate government domain was sufficient authentication for a financial institution to hand over KYC-grade records. Clients should verify that their own emergency-disclosure and legal-request handling requires out-of-band confirmation, and should brief fraud teams on the camera-permission-plus-liveness phishing pattern now. We will monitor for the phishing domain's publication, confirmation or refutation of the breach-to-phishing link, and any identification of the responsible actors, and will update this advisory if the campaign is confirmed to be using breached data.

---

[Read the original source →](https://www.malwarebytes.com/blog/threat-intel/2026/09/revolut-phishing-texts-appear-days-after-data-breach?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*