The Challenge
Revolut disclosed sensitive customer records to an unauthorized party through a social engineering attack. Criminals sent fraudulent information requests from an email address on a legitimate government agency domain, and Revolut's verification process failed to catch the deception.
The disclosed data included identity and contact information (dates of birth, postal addresses, email addresses, phone numbers), copies of government-issued IDs (passports and driver's licenses), verification selfies, account statements, and transaction histories. Within 48 hours of the public breach announcement, affected customers began receiving phishing texts that appeared in the same conversation thread as legitimate Revolut communications.
This immediate exploitation created a crisis: customers who'd just learned their data was compromised now faced active credential harvesting attempts using both the breach data and the confusion surrounding the incident.
The Environment and Constraints
Revolut operates in a messaging environment where SMS authentication and customer notifications are standard practice. Customers expect to receive account alerts, security notifications, and verification requests via text. This creates a trust baseline that attackers can exploit.
The phishing infrastructure appeared sophisticated. According to VirusTotal, the phishing domain was first scanned on September 14, the same day customers reported receiving the fraudulent texts. The messages inserted themselves into existing SMS threads with Revolut, bypassing one of the most common user defenses: checking whether a message comes from a known sender.
The fraudulent page didn't just ask for credentials. It requested camera access and mimicked Revolut's live-video "turn your head" identity verification flow before prompting for a password. This multi-step process lowered victim suspicion by replicating a familiar security check and potentially harvested biometric data (selfies or videos) that could be used for subsequent account recovery attempts or identity fraud.
Revolut needed to notify affected customers about the breach while simultaneously warning them about potential phishing attempts, but the attackers moved faster than the notification cycle could protect.
The Approach Taken
Revolut contacted affected customers directly about the breach. The company characterized the impact as affecting a "limited" or "very limited" number of customers, though it hasn't disclosed specific numbers.
The phishing page employed a fake liveness check followed by a password screen. This tactic lowers suspicion while collecting the credentials needed to attempt a real login or account-recovery flow. If the campaign was connected to the breach, the combination of disclosed identity documents, contact information, verification selfies from the breach, and freshly harvested login credentials from the phishing page could provide enough material for complete account takeover.
The company's public response focused on acknowledging the breach and its social engineering origin rather than a systems compromise. This distinction matters for incident classification and regulatory reporting, but it doesn't change the customer exposure.
Results and Metrics
The phishing campaign launched within two days of the public breach disclosure. The domain was actively scanned on September 14, and customers reported receiving texts that same day. The messages appeared in existing SMS threads with Revolut, significantly increasing their apparent legitimacy.
The fake liveness check represents an evolution in phishing sophistication. By requesting camera access and imitating a multi-factor verification step, the page collected not just passwords but potentially reusable biometric data. This creates a secondary risk: even if victims don't complete the full credential handover, the attackers may have captured facial images or videos that can be repurposed for other fraud attempts.
We don't yet know whether the phishing campaign was directly linked to the breach data or whether unrelated actors simply exploited news of the incident to target Revolut customers more broadly. Either scenario demonstrates how quickly the window closes between breach disclosure and active exploitation.
What They Would Do Differently
The root vulnerability was in the verification process for information requests. When criminals sent requests from an email address on a legitimate government agency domain, Revolut's controls failed to detect the social engineering attack. Strengthening this verification layer requires more than email domain validation.
Organizations handling similar requests should implement out-of-band verification for any bulk data disclosure, especially when the request arrives through digital channels. If a government agency emails a data request, call the agency directly using a number from official records (not from the email) to confirm the request's legitimacy and the requestor's identity.
The 48-hour gap between breach disclosure and active phishing suggests that faster customer notification might have reduced exposure. However, this creates a tension: organizations need time to investigate scope and prepare accurate communications, but every hour of delay gives attackers more time to weaponize the incident.
Post-breach, consider proactive account protections rather than relying solely on customer awareness. Temporarily requiring step-up authentication for sensitive actions, forcing password resets for affected accounts, or implementing additional transaction monitoring can reduce the window of vulnerability while customers process the notification and adjust their security posture.
Takeaways for Your Team
Your verification process for data disclosure requests must assume that attackers can compromise or spoof legitimate communication channels. Email domain validation isn't sufficient when government domains can be compromised or spoofed. Implement multi-channel verification for any request that would result in bulk customer data disclosure.
Train your incident response team to assume that breach disclosure will trigger immediate phishing campaigns. Your customer notification should include specific guidance on what communications customers should expect from you and what they shouldn't. Don't just warn about phishing in general; describe the specific tactics attackers are likely to use given the data that was exposed.
The fake liveness check demonstrates why security theater can backfire. If your verification flows include steps that look impressive but don't actually validate identity (or can be easily faked), you're training customers to accept superficial checks. Either implement genuine biometric verification with liveness detection that resists spoofing, or don't create the appearance of such verification.
Monitor for newly registered domains that mimic your brand immediately after any security incident becomes public. The VirusTotal scan timestamp shows the phishing infrastructure was stood up the same day customers received texts. Threat intelligence feeds and domain monitoring services can give you a few hours of warning to prepare customer communications or request takedowns.
Finally, recognize that the data types disclosed in this incident (identity documents, verification selfies, transaction histories, contact information) create compounding risks. Each element enables different fraud types, and the combination enables account takeover. Your breach notification and response must address not just the immediate credential risk but the longer-term identity fraud exposure.
