> ## 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. # Hackers demand 10,000 Bitcoin from Revolut following data breach - URL: https://f4n6.co.uk/security-feed/hackers-demand-10-000-bitcoin-from-revolut-following-data-breach/ - Published: 2026-09-15T16:08:23.000Z - Updated: 2026-09-15T16:08:23.000Z - Author: Jeff Davies - Tags: #security-feed ## 1\. Executive summary On 2026-09-12 Revolut confirmed that it disclosed sensitive customer records to an unauthorised third party who submitted fraudulent information requests from an email address on a legitimate government agency's domain. Revolut characterises the event as an external impersonation scam rather than an intrusion — no compromise of its systems is claimed and customer funds were not affected. Exposed data for a "limited" number of the firm's 80m+ customers includes birth dates, postal and email addresses, phone numbers and copies of identity documents such as passports and driving licences. Individuals claiming responsibility have posted samples of the allegedly stolen material across several Telegram groups, and a demand of 10,000 Bitcoin has been reported. **No verified reference data resolved for this item**: no CVSS score, no CISA KEV exploitation state and no MITRE ATT&CK profile is available, so this advisory asserts no severity rating and no confirmed attribution. The bottom-line risk to EMEA financial services clients is second-stage identity fraud and social engineering against affected individuals, plus the process-control lesson that a legitimate government email domain is not authentication. ## 2\. Regulatory framing No specific DORA/NIS2 article is directly engaged by this item. The incident occurred at Revolut, not at the client, and the mechanism was a voluntary disclosure of data in response to a fraudulent request — not an ICT incident on a client's own systems. The generic facts present here ("an incident occurred", "a third party is involved") do not pass the engagement test on their own. Conditional note for scoping: if a client (a) uses Revolut as an ICT third-party provider for payment or account services **and** (b) confirms that its own customer or staff data was within the disclosed cohort, then the third-party risk management and contractual provisions in the regulatory reference would be engaged by that client's own exposure — not by this advisory. That determination requires the client's own data-scoping, which is not available from the sources. Clients should not treat this advisory as a notification obligation trigger. ## 3\. Technical analysis & attack chain ### Confirmed attack chain 1. **Impersonation of a government agency.** The attacker sent information requests to Revolut from an email address on the domain of a legitimate government agency. The sources do not state how the attacker obtained use of that address or domain — whether by compromising a mailbox, spoofing the domain, or another route. This step is unconfirmed in mechanism. 2. **Fraudulent data request accepted.** Revolut processed the requests and disclosed customer records to the third party. No exploitation of a software vulnerability, no malware and no unauthorised access to Revolut's systems is described. Revolut's own framing is "external impersonation scam, not an intrusion." 3. **Data disclosed.** Per the customer notification email reported by Help Net Security, the disclosed fields were: birth dates, postal addresses, email addresses, phone numbers, and copies of identity documents such as passports and driving licences. 4. **Detection and blocking.** Revolut states it detected the activity and immediately blocked the sending address. 5. **Notification.** Revolut says it alerted the relevant government agency, law enforcement, data protection authorities and financial regulators, and contacted affected customers directly. 6. **Post-incident exposure and extortion.** Individuals claiming responsibility posted samples of the allegedly stolen information across several Telegram groups. A demand of 10,000 Bitcoin is reported in the headline of the primary item; the body text of that item is truncated and does not detail the demand, its delivery method, or any deadline. ### Technical specifics relevant to defenders - **No CVE, no exploited component, no malware.** There is no vulnerability mechanism to analyse here. The "exploited component" was a business process: the intake and authorisation of third-party requests for customer data. - **Scale.** Revolut is described as a London-based banking and financial platform with more than 80 million customers globally. The affected population is described only as "limited" or "very limited"; no figure is given. - **Data classes at risk.** Identity documents (passport and driving licence images) plus date of birth and contact data are a strong identity-theft kit — sufficient for account-opening fraud, SIM-swap pretexting and document-replacement scams. - **Likely consumer impact.** The sources assess the primary risk as second-stage fraud attempts rather than immediate unauthorised transfers. Malwarebytes lists the expected follow-on contact channels: calls, emails, WhatsApp messages and SMS claiming the recipient must "secure" an account, reverse a transfer, or replace documents. - **Insurance/coverage angle.** One source (DataBreaches.net) frames the incident as a test case for how insurers define a "cyber attack" when no systems were breached — relevant to clients assessing their own cyber policy wording for social-engineering and voluntary-disclosure losses. ### Caveated / single-sourced claims - **The 10,000 Bitcoin demand is single-sourced and headline-only.** It appears in the title of the primary item; the article body is truncated and provides no detail on the demand, the channel used, or any deadline. Treat as unverified. - **"Customer IDs and financial data"** appears in the Malwarebytes headline, but the itemised data list in that article is truncated in the supplied material, and the Help Net Security list covers identity documents and contact data rather than financial account data. This is a source-level discrepancy, not a verified-data discrepancy; do not assume financial account data was disclosed on the strength of a headline alone. - **The Telegram samples are "allegedly stolen."** No source in this set verifies that the posted material corresponds to the disclosed records. - **Attribution is unconfirmed.** No actor is named in the sources and no MITRE ATT&CK profile exists in the verified reference data for any party. The individuals "claiming responsibility" in Telegram groups have not been corroborated by any second source. - **The government agency and its email domain have not been identified** by Revolut. Any client-side blocklist built on a guessed domain would be speculative. ## 4\. Mitigation & containment ### P1 — within 24 hours - If your organisation or staff hold Revolut accounts, determine whether any were in the affected cohort. Affected customers were contacted directly by Revolut; if no notification was received, treat the individual as out of scope but still exposed to the follow-on phishing campaign. - Treat any inbound contact referencing this breach as hostile by default. Do not use links, phone numbers or attachments supplied in the message. Revolut's own guidance is to end contact with suspected scammers and re-establish contact through official channels — for consumers, the Revolut in-app chat. - **Harden the government/law-enforcement data-request intake process.** This is the control that failed. Any request for customer data purporting to come from a government agency or law enforcement must be verified out-of-band, by callback to a previously known-good contact at that agency or to a published switchboard number — never by replying to, or trusting, the address in the request. - Require dual authorisation (two named approvers, one outside the requesting business unit) before any bulk disclosure of customer identity documents or personal data leaves the estate. - Alert on and review any outbound transfer of identity-document images (passport, driving licence) or bulk personal-data exports in the last 30 days. ### P2 — within 72 hours - Review third-party contracts covering customer-data processing for breach-notification and data-disclosure clauses, and confirm the notification timelines your providers are actually meeting. - Issue customer-facing comms warning about second-stage fraud: unexpected calls, emails, WhatsApp or SMS claiming an account needs to be "secured", a transfer reversed, or documents replaced. Direct customers to official channels only. - For affected individuals, recommend account and credit-file monitoring for unfamiliar account openings or credit applications, and a fraud alert or credit-monitoring service where available in the jurisdiction. - Review DLP rules to ensure identity-document images and bulk PII exports are covered, and that the alerts route to a monitored queue rather than a report. ### P3 — within 7 days - Tabletop the fraudulent-data-request scenario specifically: a request arriving from a genuine government domain, marked urgent, requesting customer records. Test the out-of-band verification path end to end. - Add the scenario to the incident response playbook with named approvers and a documented verification standard. - Reassess any cyber-insurance wording covering social engineering and voluntary disclosure, given the coverage debate flagged in the sources. ## 5\. Indicators of compromise No indicators of compromise available in the source material. The sources contain no hashes, domains, IP addresses, file paths, registry keys or malware artefacts — this was a social-engineering data disclosure, not a technical compromise. ### Behavioural indicators | Behaviour | Where to observe | Confidence | | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | Inbound request for customer data originating from a legitimate government-agency email domain, outside normal legal-process channels | Email gateway logs; legal/compliance request intake queue | Medium — described by multiple sources, but no domain or header detail published | | Requests framed as urgent/emergency, requesting customer identity documents or bulk personal data | Request intake queue; DLP alerts on outbound PII | Medium | | Bulk export or transfer of identity-document images (passport, driving licence) or customer PII | DLP; egress monitoring; database audit logs | Medium | | Posting of customer data samples in Telegram groups | External threat monitoring; brand/dark-web monitoring | Low — single-sourced, "allegedly stolen", unverified | | Second-stage contact with affected customers (calls, email, WhatsApp, SMS) claiming an account must be secured, a transfer reversed, or documents replaced | Customer report queue; contact-centre call logs; brand abuse monitoring | Medium — assessed as likely impact by sources, not yet observed in this item | ## 6\. Detection Insufficient indicators to author detection rules. The sources provide no file artefacts, command lines, mutexes, scheduled-task or service names, file paths, registry keys or ransom-note text. The only distinctive strings available are product names, a cryptocurrency figure and vendor headline phrases — none of which are artefacts of the threat itself, and a rule built on them would detect reporting about the incident rather than the activity. Detection effort for this item belongs in process controls (out-of-band verification of data requests, dual authorisation, DLP on identity-document egress), not in signature content. ## 7\. Sources - DataBreaches.net (Dev Kundaliya) — *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 — date not stated in supplied material - SecurityWeek — *Personal, Financial Info Exposed in Revolut Data Breach* — https://www.securityweek.com/personal-financial-info-exposed-in-revolut-data-breach/ — date not stated in supplied material - 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 - 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 (exact date not stated) - DataBreaches.net (Matthew Sellers) — *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 We assess this as a **data-disclosure and social-engineering incident, not a technical compromise**, and we deliberately do not assign a severity rating: no verified reference data resolved for this item, so there is no CVSS score, no CISA KEV exploitation state and no MITRE ATT&CK profile to anchor one, and we will not manufacture a number from a headline. The direct impact is confined to a "limited" cohort of Revolut's customers, but the exposed data classes — passport and driving-licence images plus date of birth and contact details — are a high-quality identity-fraud kit, and the realistic harm is second-stage fraud against those individuals rather than loss of funds. Attribution is unconfirmed: no actor is named, no MITRE profile exists, and the Telegram "claims of responsibility" and the 10,000 Bitcoin demand are single-sourced and unverified — treat both as claims, not facts. The transferable lesson for EMEA financial services clients is the control failure, not the victim: a legitimate government email domain was treated as sufficient authentication for the release of customer identity documents, and any client with a comparable request-intake path should assume it is equally exposed. Next, we will monitor for corroboration of the extortion demand and for any named actor or MITRE profile, watch for the follow-on phishing campaign targeting affected customers, and re-issue if verified reference data resolves a severity or exploitation state. --- [Read the original source →](https://databreaches.net/2026/09/15/hackers-demand-10000-bitcoin-from-revolut-following-data-breach/?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*