Revolut breach exposes widespread security weakness -- trust

The Revolut breach highlights a vulnerability that experts say goes unnoticed in many enterprises: data release processes that conflate authentication and authorization, with users assuming requests from legitimate email domains are trustworthy.

In the attack on Revolut, a London-based financial technology company, threat actors used a stolen government email address to impersonate authorities and request customer information. Revolut told TechTarget that its employees complied with the attackers, believing they were corresponding with government officials. That cooperation led them to hand over the private data of nearly 700 individuals.

A threat actor claiming responsibility for the attack under the pseudonym IAmNotAVillain said in a public post that Revolut shared customers' names, home addresses, email addresses, ID documents, banking information and cryptocurrency transaction records. In messages exchanged with the Financial Times, the alleged attackers said they compromised an Italian government email system and communicated with Revolut for months. They also threatened to sell the data to other criminals if the company fails to pay a $3 million ransom.

"This one is hard because it passes every technical control you have, which leaves only governance. And because it comes from law enforcement, it arrives with an expectation of speed," said Ken Yao, head of partnerships at cybersecurity training platform vendor TryHackMe. "Anyone could get caught by this one."

The lesson for CISOs is that highly sensitive data flows should receive no less scrutiny than multimillion-dollar wire transfers, experts agreed. That means denying record requests by default -- even those subject to regulatory law -- unless and until they are verified through out-of-band channels and separately authorized by at least two qualified employees. Organizations must explicitly empower teams to slow their responses to legally authoritative requests, Yao added, without feeling they are putting their jobs at risk.

"Nobody releases six figures based solely on the fact that the email came from a real domain," said Denis Calderone, CTO at AI cybersecurity firm Suzu Labs. "But that appears to be essentially what happened here with data that, for affected customers, is more damaging than a wire fraud loss. You can reverse a wire transfer. You can't unleak a passport."

You can reverse a wire transfer. You can't unleak a passport.

As security controls go, out-of-band verification -- the process of authenticating a data request through a separate, trusted channel, such as a publicly listed agency phone number or authenticated portal -- is relatively simple, but not necessarily common in practice. Proof-based verification processes can also protect organizations against AI-based deepfake attacks, like the one that duped a senior finance professional into wiring $25 million to threat actors who impersonated his CFO and other colleagues during a Zoom call.

"Multifactor authentication is not just for logging into accounts anymore," said Bryson Byrd, cybersecurity advisor at Huntress. "Between deepfakes and compromised email accounts like the one used against Revolut, what we really need are multifactor authenticity checks built into the processes of organizations that handle sensitive data."

Arpit Mittal, a software engineer and technical lead who specializes in financial fraud prevention at PayPal, said handing over sensitive data based solely on an email thread is a "critical process failure."

"Treat incoming administrative or emergency data requests with the same risk-scoring discipline applied to financial transactions," Mittal advised. "Flag anomalies such as unusual urgency, sudden deviations from standard legal formatting or targeting of high-net-worth or crypto-associated profiles."

How CISOs can secure the 'loading dock'

Revolut said the threat actors did not compromise any of the company's internal systems. Rather, all the stolen data was leaked because employees voluntarily shared it.

That underscores another common security weakness, according to Eric Capuano, director of SOC operations at Black Hills Information Security. The typical organization lacks a mechanism for the security team to oversee the government and law enforcement request queue, he said, which is often just a shared inbox.

"Nobody gets an alert when the compliance team emails passport scans, verification selfies and a full transaction history to an outside address, because that is a Tuesday for that team," Capuano said. "Security spends its budget on the front door, and this stuff goes out the loading dock."

Security spends its budget on the front door, and this stuff goes out the loading dock.

Capuano urged every CISO whose organization handles customer data to do three things this week:

1. Identify security gaps and implement proof-based verification. Identify who in the organization can fulfill a government or law enforcement data request and have them walk security leaders through the process, Capuano said. If the only verification they require is that the email passed authentication and came from a familiar domain, create a new process that requires calling an out-of-band phone number -- from the relevant agency's public directory -- for independent confirmation. Add a mandatory second approver for anything involving identity documents or full account history.
2. Monitor official requests for private data. Set up a process to log all official data requests and ensure the SOC can readily access the logs.
3. Consider context. Before fulfilling requests for sensitive data, pull mail logs to review previous messages from the same domain, which could provide important context. "A mailbox that gets used once usually gets used more than once," Capuano said. In other words, approach a first-time or atypical request for sensitive data with even greater caution.

Organizations should also clearly define class-based data release policies and designate accountability for handling after-hours requests, TryHackMe's Yao added.

"Assume a request like this will reach you, and that it will look legitimate," he said. "Write down in advance which categories of data you will release [based] on an email alone, and name the person who owns that call at 2 a.m. on a Friday. Then run it as an exercise before it happens for real."

Alissa Irei is an Informa TechTarget news reporter covering cybersecurity.