Revolut Tricked by Stolen Govt Email

How the Attack Worked

Attackers gained access to a stolen or compromised government email account and used it to impersonate law enforcement or government authorities. They contacted Revolut employees requesting customer records, including identity documents, banking information, and transaction history. Because the email came from a legitimate-looking government domain, employees believed the request was authentic and responded by sending the requested data. According to Revolut, the threat actors did not need to compromise any internal systems since employees voluntarily shared the information.

Why It Succeeded

The attack worked because staff conflated authentication with authorization. A familiar or official-looking email domain was treated as sufficient proof that a request was legitimate, without any separate verification step. This is a common weakness in organizations where official request handling flows through a shared inbox with little oversight from the security team. Attackers reportedly communicated with the company over an extended period, requesting large volumes of sensitive data without triggering additional scrutiny.

What to Watch For

• Requests claiming to be from law enforcement or government agencies that ask for broad datasets such as ID documents combined with full transaction history.
• Urgency framed around "official" or legal matters, designed to discourage employees from slowing down to verify.
• Requests handled entirely through email with no independent confirmation, especially when the request comes through a general or shared inbox.
• Sensitive data release processes that rely solely on the sender's domain as proof of legitimacy.

How to Build Resistance

Organizations handling customer identity and account data can reduce exposure to this type of social engineering by treating sensitive data releases with the same scrutiny as high-value financial transactions. Recommended steps include:

• Require out-of-band verification for any government or law enforcement request, using a publicly listed agency phone number or an authenticated portal rather than replying to the original email thread.
• Add a mandatory second approver for any release involving identity documents or full account history.
• Give the security operations center visibility into the official request queue, and log all such requests so they can be reviewed and monitored.
• Train compliance, legal, customer support, and fraud teams to recognize that a legitimate-looking domain is not, by itself, sufficient authorization to release sensitive data.

This case illustrates that even organizations without a technical breach can suffer significant data exposure when trust in a familiar communication channel replaces independent verification.

How did attackers get Revolut employees to share customer data?

Attackers used a stolen or compromised government email account to impersonate authorities, and employees complied because they believed they were corresponding with real government officials.

Did the attackers breach Revolut's internal systems?

No, Revolut said the threat actors did not compromise any internal systems. All the data was leaked because employees voluntarily shared it after being deceived.

What should organizations do to prevent similar incidents?

Experts recommend out-of-band verification using a trusted phone number or authenticated portal, plus requiring a second approver before releasing identity documents or full account history.

Why is this attack considered dangerous despite low technical complexity?

It succeeded by exploiting trust in a legitimate-looking government email domain rather than any technical vulnerability, showing that authentication alone should not be mistaken for authorization.