Revolut Data Breach via Fake Government Data Request: Defending Against Emergency Data Request (EDR) Fraud

Revolut, one of the world's largest fintech platforms, has disclosed a data breach with an uncomfortable root cause: no malware, no zero-day, no exploited vulnerability. The company voluntarily handed over customer data — including financial information and passport details — to a threat actor who was impersonating a government agency. The attacker convinced Revolut staff that they were a legitimate authority entitled to the data, and the company complied.

This is the latest high-profile example of a technique that has been steadily maturing into a reliable criminal business model: Emergency Data Request (EDR) fraud and government impersonation. Instead of breaking through your perimeter, attackers walk through your front door wearing a badge that doesn't exist. If your organization stores regulated PII — and in fintech, that means KYC documents, financial records, and identity documents like passports — your legal and compliance intake channels are now an attack surface.

Why defenders need to act now:

• The exposed data classes (passport scans, financial records) are exactly what is needed for full identity theft, SIM swapping, and downstream account takeover.
• EDR fraud scales. The same playbook used against Revolut has been used against ISPs, social platforms, and financial institutions globally, often using compromised government or law enforcement email accounts to add legitimacy.
• No patch will fix this. Detection and remediation here is about process hardening, verification workflows, and hunting for the artifacts these requests leave behind.

Technical Analysis

What Happened

Per the disclosure, Revolut shared data belonging to an undisclosed number of customers with a threat actor who successfully impersonated a government agency. The attacker did not compromise Revolut's infrastructure — they compromised the trust model of its legal/government request intake process. Key characteristics of this attack class:

1. Impersonation vector: Threat actors present as a government agency, law enforcement body, or regulator. In mature versions of this scheme, they send requests from compromised legitimate government email accounts (often obtained via credential phishing of real agencies), making trivial sender-domain checks useless.
2. Urgency engineering: Requests are framed as emergencies — imminent harm, kidnapping, terrorism, or financial crime investigations — to pressure staff into bypassing standard verification. The entire design of an "emergency request" is to defeat due diligence.
3. Target data: In Revolut's case, the payload was KYC-grade data: financial information and passport documents. This is crown-jewel PII that cannot be rotated like a password. Customers cannot change their passports easily or retroactively undo identity document exposure.

Attack Chain (Defender's View)

Exploitation Status

• No CVE is associated with this breach — this is a business-process and identity-verification failure, not a software vulnerability.
• Confirmed real-world compromise: Data was actually disclosed to the threat actor. This is not theoretical.
• Active, widespread technique: EDR fraud is an established and growing criminal methodology. Underground services openly sell access to compromised government email accounts specifically for submitting fraudulent data requests to tech companies and financial institutions. Any organization holding customer PII under legal-process obligations should treat this as an in-the-wild threat today.

Why This Is Harder Than It Looks

Fintechs and regulated entities are legally obligated to respond to genuine government and law enforcement data requests. Refusing a real request carries legal risk; complying with a fake one carries breach liability. That tension is precisely what attackers exploit. The control gap is almost never technical — it is the absence of a cryptographically or procedurally verifiable identity check on the requester before data release.

Detection & Response

Because the attack surface here is email, identity verification, and data export workflows, detection should focus on three observable layers: (1) inbound requests containing law-enforcement/emergency keywords from external or unverified senders, (2) anomalous or bulk access to customer PII stores, and (3) staging/archiving of customer data on endpoints prior to exfiltration.

Sigma Rules

---
title: Inbound Emergency Data Request or Law Enforcement Impersonation Email
id: 3f8c2a1e-7d94-4b56-9c01-2e7a5f8d3b44
status: experimental
description: Detects inbound emails containing language characteristic of fraudulent Emergency Data Requests (EDR) or government/law enforcement impersonation, a technique used in the Revolut breach to socially engineer disclosure of customer PII.
references:
  - https://www.bleepingcomputer.com/news/security/revolut-discloses-data-breach-exposing-financial-info-passports/
  - https://attack.mitre.org/techniques/T1656/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.initial_access
  - attack.t1656
  - attack.t1566
logsource:
  category: email
  product: o365
  service: exchange
detection:
  selection_keywords:
    Subject|contains:
      - 'emergency data request'
      - 'emergency disclosure request'
      - 'law enforcement request'
      - 'government request'
      - 'court order'
      - 'subpoena'
      - 'urgent legal request'
      - 'imminent harm'
      - 'preservation request'
  selection_external:
    SenderIsInternal: 'false'
  filter_verified_gateways:
    SenderDomain|endswith:
      - '.gov'
      - '.gov.uk'
      - '.europa.eu'
  condition: selection_keywords and selection_external and not filter_verified_gateways
falsepositives:
  - Legitimate law enforcement correspondence routed through non-standard addresses
  - Legal counsel forwarding genuine process
level: high
---
title: Bulk Export or Download of Customer PII From Cloud Storage
id: 9a1d4e72-3b68-4f25-a890-6c2e1d5f7a33
status: experimental
description: Detects mass download or export events against cloud storage or SaaS applications holding customer KYC/PII records, consistent with data collection activity following a fraudulent government data request such as the Revolut breach.
references:
  - https://www.bleepingcomputer.com/news/security/revolut-discloses-data-breach-exposing-financial-info-passports/
  - https://attack.mitre.org/techniques/T1530/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.collection
  - attack.exfiltration
  - attack.t1530
  - attack.t1567
logsource:
  category: cloud
  product: azure
  service: auditlogs
detection:
  selection:
    OperationName|contains:
      - 'FileDownloaded'
      - 'ExportReport'
      - 'DataExport'
      - 'DownloadFile'
  aggregation:
    CountEvents by UserId > 50
  timeframe: 10m
  condition: selection and aggregation
falsepositives:
  - Scheduled analytics or data pipeline jobs
  - Legitimate bulk operations by data engineering service accounts (allowlist by principal)
level: high

KQL — Microsoft Sentinel / Defender Hunting

// Hunt 1: Inbound emails matching Emergency Data Request (EDR) fraud patterns
// Requires Defender for Office 365 (EmailEvents) or ingested Exchange message trace
EmailEvents
| where TimeGenerated > ago(30d)
| where SenderFromDomain !endswith ".gov" and SenderFromDomain !endswith ".gov.uk"
| where Subject has_any (
    "emergency data request", "emergency disclosure", "law enforcement request",
    "government request", "court order", "subpoena", "preservation request",
    "urgent legal", "imminent harm", "child safety", "kidnapping")
| project TimeGenerated, SenderFromAddress, SenderFromDomain, Subject,
          RecipientEmailAddress, AttachmentCount, DeliveryAction, ThreatTypes
| order by TimeGenerated desc;

// Hunt 2: Anomalous bulk access/download of files from PII-bearing SharePoint/OneDrive/CloudApp locations
// Baseline deviation approach: flag users downloading far above their 30-day average
let PII_keywords = dynamic(["passport", "kyc", "customer_data", "identity", "financial"]);
CloudAppEvents
| where TimeGenerated > ago(7d)
| where ActionType in ("FileDownloaded", "FileSyncDownloadedFull", "ExportReport")
| extend FileNameLower = tolower(tostring(RawEventData.ObjectName))
| where FileNameLower has_any (PII_keywords)
| summarize DownloadCount = count(), DistinctFiles = dcount(tostring(RawEventData.ObjectName))
          by AccountUpn = tostring(RawEventData.UserId), bin(TimeGenerated, 1h)
| where DownloadCount > 25
| order by DownloadCount desc;

// Hunt 3: Endpoint staging — large archives created shortly before outbound transfer
DeviceFileEvents
| where TimeGenerated > ago(7d)
| where ActionType == "FileCreated"
| where FileName has_any (".zip", ".7z", ".rar", ".tar.gz")
| where FileName has_any ("export", "customer", "passport", "kyc", "request", "data")
| join kind=inner (
    DeviceNetworkEvents
    | where TimeGenerated > ago(7d)
    | where RemotePort in (443, 22, 21)
    | project DeviceId, RemoteUrl, RemoteIP, TimeGenerated
  ) on DeviceId
| project DeviceId, FileName, FolderPath, RemoteUrl, RemoteIP, FileCreatedTime = TimeGenerated1
| order by FileCreatedTime desc;

Velociraptor VQL — Endpoint Artifact Hunt

-- Hunt for staged customer-data archives on endpoints used by compliance/legal teams
-- Targets archives with PII-themed names created in the last 14 days in staging locations
SELECT FullPath, Size, Mtime, Btime
FROM glob(
    globs=[
      'C:/Users/*/Downloads/**/*{passport,kyc,customer,export,request,identity}*.{zip,7z,rar,csv,xlsx}',
      'C:/Users/*/Desktop/**/*{passport,kyc,customer,export,request,identity}*.{zip,7z,rar,csv,xlsx}',
      'C:/Temp/**/*{passport,kyc,customer,export,request,identity}*.{zip,7z,rar,csv,xlsx}',
      '/home/*/Downloads/**/*{passport,kyc,customer,export,request,identity}*.{zip,7z,rar,csv,xlsx}'
    ], accessor='ntfs')
WHERE Mtime > now() - 1209600
  AND Size > 1000000
ORDER BY Mtime DESC

Remediation / Audit Script

Use this PowerShell script against Exchange Online to surface inbound mail matching EDR-fraud language over the last 30 days, so your IR team can review every "government request" your organization has recently received and re-verify its provenance:

# Connect-ExchangeOnline must be run first with appropriate admin credentials
# Connect-ExchangeOnline -UserPrincipalName soc-admin@yourdomain.com

$keywords = @(
    'emergency data request','emergency disclosure','law enforcement request',
    'government request','court order','subpoena','preservation request',
    'imminent harm','urgent legal'
)

# Pull inbound messages from the last 30 days (paged for volume)
$trace = Get-MessageTraceV2 -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
         -ResultSize 5000

$suspect = $trace | Where-Object {
    $subject = $_.Subject
    $hit = $false
    foreach ($k in $keywords) { if ($subject -match [regex]::Escape($k)) { $hit = $true; break } }
    # Flag if sender is not from a verifiable government TLD
    $hit -and ($_.SenderAddress -notmatch '\.(gov|gov\.uk|europa\.eu)$')
}

$suspect | Select-Object Received, SenderAddress, RecipientAddress, Subject, Status |
    Export-Csv -Path ".\EDR_Fraud_Review_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

Write-Output "$($suspect.Count) messages require manual provenance re-verification."

Remediation

There is no patch for this breach class — remediation is procedural and architectural. Actions for your organization, in priority order:

1. Implement mandatory out-of-band verification for every government/law-enforcement data request. Never verify a request using contact details supplied in the request itself. Independently look up the agency's published contact channel and call it. Confirm the request, the requesting officer, and a case/warrant number with a human at the agency. No exceptions for "emergencies" — urgency is the attacker's primary weapon.
2. Do not rely on sender domain alone. Compromised legitimate government email accounts are a known commodity in criminal markets. A .gov sender proves the mailbox sent the email, not that the request is legitimate. Verification must be procedural (callback to published numbers) and, where available, cryptographic (signed requests, government verification portals such as Kodex or agency-specific legal request platforms).
3. Two-person authorization for PII release. Require dual sign-off — one legal/compliance approver and one security approver — before any customer data leaves your environment in response to a legal request. A single pressured employee must not be able to satisfy an EDR alone.
4. Gate and log all bulk access to KYC/PII data stores. Enforce just-in-time access for customer record exports, alert on any single principal exporting more than a defined threshold of records per day, and route all exports through DLP inspection for passport/financial document patterns.
5. Run the email hunt above against your last 90 days of mail. If you find prior "government requests" that were satisfied, re-verify each one out-of-band today. You may already have been breached without knowing it.
6. Tabletop this exact scenario. Put your legal intake, SOC, and executive team through an EDR-fraud exercise this quarter. Measure: does anyone release data before verification completes?
7. For affected Revolut customers and any organization facing KYC-data exposure: Enroll in credit monitoring, treat all inbound contact claiming to be Revolut as untrusted (breach-follow-on phishing is guaranteed), enable phishing-resistant MFA on financial accounts, and monitor for new-account fraud using exposed passport data.

Vendor/regulatory references:

• Incident reporting coverage: https://www.bleepingcomputer.com/news/security/revolut-discloses-data-breach-exposing-financial-info-passports/
• MITRE ATT&CK T1656 (Impersonation) and T1566 (Phishing) — map detections accordingly
• If you are EU/UK-regulated: confirm your GDPR/UK GDPR Article 33 breach-notification obligations were triggered within 72 hours of discovery, as Revolut's disclosure demonstrates is required

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub