On September 12, 2026, Revolut confirmed that it disclosed sensitive customer data — KYC identity documents, verification selfies, and Bitcoin transaction histories — to an unauthorized third party. The mechanism was not a software vulnerability, a zero-day, or a misconfigured cloud bucket. The attacker sent fraudulent information requests from an email address operating inside an actual government agency's infrastructure, complete with valid domain credentials. The messages authenticated cleanly and passed Revolut's checks for legitimate legal process.
This incident should be a forcing function for every organization that processes government or law enforcement data requests — banks, fintechs, telcos, social platforms, and hosting providers. The trust model most teams use for inbound legal process — "does this email come from a genuine government domain?" — is now demonstrably insufficient. Threat actors have spent the last several years compromising government email infrastructure precisely because it inherits the implicit trust of every platform that receives requests from it. The Revolut disclosure is the predictable outcome.
If your organization has a legal request intake mailbox, you are a target for this technique. This post breaks down the attack chain, where the verification model failed, and the specific detections and process controls you should deploy now.
Technical Analysis
What Was Exposed
- KYC documents: government-issued identity documents submitted during customer onboarding (passports, national ID cards, driver's licenses)
- Verification selfies: biometric-adjacent imagery used for liveness and identity matching
- Bitcoin transaction histories: on-chain activity records linked to verified identities
This combination is exceptionally dangerous in the hands of criminals. A valid passport scan plus a matching selfie defeats the remote onboarding controls of most financial institutions, enabling identity theft at scale, account takeover at other platforms, and deanonymization of cryptocurrency holdings — which exposes victims to targeted extortion and physical coercion.
Attack Chain (Defender's Perspective)
Based on the confirmed details, the attack chain is:
- Government email access: The attacker obtained the ability to send email from an address inside a real government agency. The summary states the fraudulent requests carried valid domain credentials — meaning SPF, DKIM, and DMARC checks would pass. This is consistent with either a compromised mailbox/account inside the agency or abuse of a legitimately provisioned but attacker-controlled account. Either way, the email was cryptographically indistinguishable from genuine government correspondence.
- Crafted legal process: The attacker sent fraudulent information requests that mimicked legitimate government data demands — the kind of lawful-process requests fintechs receive daily. Because the sender domain was authentic, the requests passed Revolut's verification checks.
- Data disclosure: Revolut's trust and safety / legal compliance team processed the requests and released KYC documents, selfies, and transaction histories to the requester.
- Discovery and confirmation: The unauthorized disclosure was identified and publicly confirmed on September 12, 2026.
Why Domain Authentication Failed as a Control
SPF, DKIM, and DMARC answer one question only: was this message sent by infrastructure authorized for this domain? They answer nothing about whether the human or process behind the mailbox is authorized to make legal process requests, whether the request itself is genuine, or whether the account has been compromised. When an attacker operates from inside a genuine government email tenant, all three controls validate the message.
This is the same trust-abuse pattern seen in business email compromise and in the abuse of Emergency Data Requests (EDRs) that has plagued major platforms for years: attackers compromise police and government email accounts and submit forged court orders or emergency disclosure demands to extract user data. The defensive lesson is identical — the communication channel's authenticity must never substitute for out-of-band verification of the request itself.
Exploitation Status
No CVE is associated with this incident; it is a process and trust-model failure, not a software vulnerability. The underlying technique — compromised government email used to extract user data from platforms — is actively exploited in the wild and has been for multiple years. This is confirmed real-world abuse, not a theoretical risk.
Detection & Response
Detection for this threat lives in two places: your email/security telemetry (anomalous legal-process request characteristics) and your data handling telemetry (bulk access to and staging of identity documents for disclosure). The rules below target the observable behaviors of this attack pattern.
---
title: Bulk Archive Creation of KYC or Identity Documents
id: 3f9c1d72-6a4e-4b58-9c21-8d7e2f4a6b10
status: experimental
description: Detects compression utilities being used to archive files with names or paths associated with KYC records, identity documents, or verification selfies — consistent with staging customer identity data for unauthorized disclosure in response to a fraudulent legal request.
references:
- https://securityaffairs.com/198922/data-breach/revolut-exposed-kyc-data-after-fraudulent-government-email-passed-security-checks.html
- https://attack.mitre.org/techniques/T1560/001/
author: Security Arsenal
date: 2026/09/15
tags:
- attack.collection
- attack.t1560.001
- attack.exfiltration
logsource:
category: process_creation
product: windows
detection:
selection_tool:
Image|endswith:
- '\7z.exe'
- '\7za.exe'
- '\rar.exe'
- '\winzip.exe'
- '\tar.exe'
selection_keywords:
CommandLine|contains:
- 'kyc'
- 'passport'
- 'id_document'
- 'identity_verification'
- 'selfie'
- 'onboarding_docs'
condition: all of selection_*
falsepositives:
- Legitimate archival of identity records by compliance or backup tooling — whitelist known service accounts and scheduled tasks
level: high
---
title: Mass File Access to Identity Document Stores by Non-Standard Account
id: 8c2e5a19-4d7f-4e31-b648-2a9d6f0e5c47
status: experimental
description: Detects a large volume of file reads on directories storing KYC or identity documents by accounts outside an approved compliance-service allowlist. A fraudulent legal request being fulfilled manually produces exactly this burst pattern. Tune the threshold to baseline compliance-team activity.
references:
- https://securityaffairs.com/198922/data-breach/revolut-exposed-kyc-data-after-fraudulent-government-email-passed-security-checks.html
- https://attack.mitre.org/techniques/T1213/
author: Security Arsenal
date: 2026/09/15
tags:
- attack.collection
- attack.t1005
logsource:
category: file_event
product: windows
detection:
selection_paths:
TargetFilename|contains:
- '\kyc\'
- '\identity_documents\'
- '\customer_onboarding\'
- '\verification_selfies\'
filter_approved_accounts:
User|contains:
- 'svc_kyc_backup'
- 'svc_dlp_scanner'
condition: selection_paths and not 1 of filter_*
falsepositives:
- Compliance analysts fulfilling verified legal requests — correlate against your legal request ticketing system before escalating
level: medium
// Hunt: anomalous legal-process / government-domain request characteristics
// Assumes email gateway (Proofpoint, Mimecast, Defender for Office, SEG) logs ingested via CEF into CommonSecurityLog.
// Flags government-TLD senders where reply-to differs from sender domain, first-time senders to the legal intake
// mailbox, or government domains failing DMARC alignment — all consistent with fraudulent legal process abuse.
let Lookback = 30d;
let LegalIntake = dynamic(["legal-requests@yourcompany.com", "subpoenas@yourcompany.com", "lawenforcement@yourcompany.com"]);
let KnownGovSenders = CommonSecurityLog
| where TimeGenerated > ago(180d) and TimeGenerated < ago(Lookback)
| where DeviceVendor =~ "Proofpoint" or DeviceVendor =~ "Mimecast" or AdditionalExtensions has "mail-from"
| extend SenderDomain = tostring(split(extract(@"mail-from=([^;]+)", 1, AdditionalExtensions), "@")[1])
| where SenderDomain endswith ".gov" or SenderDomain contains ".gov."
| distinct SenderDomain;
CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| extend MailFrom = extract(@"mail-from=([^;]+)", 1, AdditionalExtensions),
ReplyTo = extract(@"reply-to=([^;]+)", 1, AdditionalExtensions),
Recipient = extract(@"rcpt-to=([^;]+)", 1, AdditionalExtensions),
DmarcResult = extract(@"dmarc=([a-zA-Z]+)", 1, AdditionalExtensions)
| where Recipient in~ (LegalIntake)
| extend SenderDomain = tostring(split(MailFrom, "@")[1]),
ReplyDomain = tostring(split(ReplyTo, "@")[1])
| where SenderDomain endswith ".gov" or SenderDomain contains ".gov." or SenderDomain endswith ".police" or SenderDomain contains ".police."
| extend Anomalies = strcat(
iff(SenderDomain != ReplyDomain and isnotempty(ReplyTo), "REPLY_TO_MISMATCH; ", ""),
iff(SenderDomain !in (KnownGovSenders), "FIRST_TIME_SENDER_DOMAIN; ", ""),
iff(DmarcResult == "fail", "DMARC_FAIL; ", ""))
| where isnotempty(Anomalies)
| project TimeGenerated, MailFrom, ReplyTo, Recipient, SourceIP, SenderDomain, Anomalies, AdditionalExtensions
| order by TimeGenerated desc
-- Hunt for staging of identity/KYC documents into archives or unusual directories,
-- and archive files with KYC-related naming, across Windows endpoints.
-- Deploy as a multi-host hunt scoped to compliance-team workstations and document-processing servers.
SELECT FullPath, Size, Mtime AS Modified, Ctime AS Created
FROM glob(globs=[
"C:/Users/*/Documents/**/*.zip",
"C:/Users/*/Desktop/**/*.7z",
"C:/Temp/**/*.zip",
"C:/Temp/**/*.rar",
"D:/KYC/**/*.zip",
"D:/LegalRequests/**/*.zip"
])
WHERE FullPath =~ '(?i)(kyc|passport|id_document|identity|selfie|onboarding|verification)'
OR FullPath =~ '(?i)(legal_request|subpoena|disclosure|edr_response)'
ORDER BY Modified DESC
# Verify email authentication enforcement and surface risky mail-flow configuration
# for the mailboxes that receive legal/government data requests.
# Run in Exchange Online PowerShell (Connect-ExchangeOnline first).
# 1) Confirm DMARC/SPF/DKIM reject enforcement is enabled on inbound policy
Get-HostedContentFilterPolicy | Select-Object Name, EnableSpoofIntelligence, SpoofIntelligenceAction
Get-AntiPhishPolicy | Select-Object Name, EnableMailboxIntelligence, EnableOrganizationDomainsProtection, `
HonorDmarcPolicy, DmarcRejectAction, DmarcQuarantineAction
# 2) Audit transport rules that auto-forward or redirect legal-intake mail externally
Get-TransportRule | Where-Object {
$_.RedirectMessageTo -ne $null -or
$_.BlindCopyTo -ne $null -or
$_.CopyTo -ne $null
} | Select-Object Name, State, RedirectMessageTo, BlindCopyTo, CopyTo
# 3) Find inbox rules on the legal intake mailbox forwarding outside the org
$intake = "legal-requests@yourcompany.com"
Get-InboxRule -Mailbox $intake | Where-Object {
$_.ForwardTo -ne $null -or $_.ForwardAsAttachmentTo -ne $null -or $_.RedirectTo -ne $null
} | Select-Object Name, ForwardTo, ForwardAsAttachmentTo, RedirectTo
# 4) Review external forwarding at the org level (should be Off / disabled)
Get-HostedOutboundSpamFilterPolicy | Select-Object Name, AutoForwardingMode
# 5) Pull recent sign-in activity for accounts that process legal requests (requires Graph)
# Look for impossible travel, unfamiliar countries, and legacy auth on those accounts.
Connect-MgGraph -Scopes "AuditLog.Read.All"
$processors = @("analyst1@yourcompany.com", "analyst2@yourcompany.com")
foreach ($u in $processors) {
Get-MgAuditLogSignIn -Filter "userPrincipalName eq '$u'" -Top 50 |
Select-Object CreatedDateTime, AppDisplayName, IpAddress, `
@{N='Location';E={$_.Location.CountryOrRegion}}, `
@{N='Status';E={$_.Status.ErrorCode}}, ClientAppUsed
}
Remediation
There is no patch for a trust-model failure. Remediation is process, architecture, and verification discipline. Prioritize the following:
-
Mandate out-of-band verification for every data request, no exceptions. Contact the requesting agency through an independently sourced channel — a phone number or contact point retrieved from the agency's official website or an established liaison directory, never from contact details in the request itself. Confirm the request reference number, the requesting officer, and the legal authority cited. Document the verification in your ticketing system before any data moves.
-
Use cryptographic request validation where available. Many jurisdictions and major platforms now support signed requests, mutual TLS portals, or dedicated law-enforcement request portals (e.g., agency-verified submission systems). Treat any request arriving by bare email as unverified by default, regardless of how clean its SPF/DKIM/DMARC results are.
-
Enforce dual authorization for data disclosure. No single analyst should be able to both approve and fulfill a legal data request. Require a second approver, ideally with a manager or counsel sign-off for requests involving identity documents or financial transaction histories. This single control would likely have stopped the Revolut disclosure.
-
Apply data minimization to responses. Disclose only what the verified legal authority compels. KYC documents, selfies, and full cryptocurrency transaction histories should be high-friction disclosure categories requiring senior legal review — not something an intake analyst can export in response to an email.
-
Harden the accounts that process legal requests. Phishing-resistant MFA (FIDO2/passkeys), conditional access blocking legacy authentication, impossible-travel alerting, and privileged access workstation requirements for anyone touching customer identity data. The attacker's advantage came from trust placed in an email identity; don't replicate that weakness internally.
-
Alert on the fulfillment pattern, not just the request. Deploy the detections above: bulk reads on identity document stores, archive creation with KYC-related filenames, and outbound transfers sized like document bundles. Correlate every alert against your legal request ticketing queue — any disclosure activity with no matching verified ticket is a critical incident.
-
Rehearse the scenario. Add fraudulent legal process to your tabletop exercise rotation. Your legal, compliance, and security teams should have a shared runbook for the moment someone questions whether a government request is real — including who has authority to halt a disclosure in progress.
-
If you are a Revolut customer potentially affected: monitor for identity misuse, place fraud alerts with credit bureaus in your jurisdiction, treat any unsolicited contact referencing your identity documents as hostile, and be alert to targeted phishing leveraging your real personal details. Given the exposure of Bitcoin transaction histories, be especially wary of extortion-style contact referencing your crypto activity.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.