What happens when attackers borrow a trusted channel

Two incidents, one shared weakness

On September 12, Revolut confirmed that it had disclosed customer data in response to fraudulent requests submitted from an email address on a genuine government agency domain.

According to the notification Revolut sent affected customers, the information included names, dates of birth, occupations, addresses, phone numbers and copies of identity documents. Revolut said its systems and customer funds were unaffected.

Parties claiming responsibility have since begun publishing customer identity documents and are demanding 10,000 BTC. Revolut has not confirmed that demand.

Two days earlier, Trezor and BitBox newsletter subscribers received phishing emails sent from the vendors' own addresses after a compromise at Brevo, the email provider both companies use.

The message claimed there was a critical entropy flaw in the wallets and directed recipients to an app that asked for their wallet backup. Trezor took the phishing domain down within 20 minutes and said around 2,500 people had clicked the link by then.

The flaw described in the email was real, but it affected another company's product. Coinkite had disclosed it roughly six weeks earlier. The attackers reused the vulnerability and changed the brand name.

There is no reporting connecting the Revolut and Brevo incidents. But they expose the same weakness: the attacker did not need to fake the channel. They gained access to one that recipients already trusted.

The sender passed the check

Revolut said the fraudulent communication "carried valid domain authentication credentials" and was fulfilled under the reasonable belief that it came from a genuine government agency.

Brevo made a similar point. The phishing emails went through legitimate infrastructure, which meant they passed the normal email authentication checks and looked genuine.

Neither incident depended on spoofing the sender.

That distinction matters.

The email came from the right place and looked legitimate. But that only established where the message came from, not whether the request inside it was genuine or should have been acted on.

In both incidents, the first check passed. The problem came after it.

For Revolut, the question was whether the request justified releasing customer information. For Trezor and BitBox customers, it was whether a genuine vendor email justified handing over a wallet backup.

The sending channel could not answer either question.

The Revolut debate is focusing on the wrong control

Much of the discussion around the Revolut incident has focused on the amount of sensitive customer information financial institutions collect.

That debate is worth having, and Range's position is that it is not what failed here.

Regulated institutions carry obligations to disclose information to regulators, law enforcement and other competent authorities, and those obligations are independent of how they perform KYC.

A company can use a third-party identity provider, rebuild onboarding around reusable credentials or zero-knowledge proofs, and minimize what sits in its identity stack. It still holds transaction histories and account records, and it still receives requests that require disclosing some of them.

The harder question is how an institution decides that a request is legitimate, what it is allowed or required to disclose and who needs to approve the release before any data leaves.

That is an operational control problem. The amount of data a company holds determines how much can be exposed, but it does not determine whether the disclosure itself was authorized.

Protecting customer data starts with controlling how sensitive requests are handled: who verifies them, who approves them and what gets recorded before anything is shared.

Now replace the data request with a payment

The same failure mode shows up in finance. Substitute a payment instruction for a data request and the failure is identical.

A payment instruction arrives from an address the company has dealt with for two years. It sits in the usual email thread. The invoice is real. The sender's name is familiar.

It survives review because of how it arrived. Everything about the request looks normal because the channel looks normal. Nothing about the instruction itself was checked, because what was checked was the channel, and the channel is the first thing an attacker takes.

Finance, compliance and risk teams make these judgment calls every day. The sender is recognized. The context makes sense. The request fits an existing pattern.

With a fiat payment, there may still be time to call the bank and attempt a recall.

Onchain, the consequence of getting it wrong is different in kind. With a stablecoin transfer, settlement is in seconds. Once value has moved to the destination address, there is no bank on the other side waiting to reverse it.

Any control capable of stopping the payment therefore has to run before release. And it has to evaluate the payment itself, rather than relying on the message that requested it.

Where the control has to sit

The communication layer cannot carry this control, because it is what the attacker already holds.

The same counterparty usually lives across three systems and often in one person's inbox, which is how an arriving message becomes the record of how to pay them. Three controls are available to companies today:

• Verify payout details independently. Confirm them against an existing counterparty record or through a channel your company initiated. Do not treat the message providing new payment details as proof that those details are correct.
• Screen the destination before value moves. The receiving address is part of the payment itself. It can be evaluated independently of the email, chat or ticket that supplied it.
• Reconcile payments against approved instructions. A payment without a corresponding approval should become an exception in the process rather than something somebody has to notice manually.

Those controls matter whether or not a company ever uses Range.

Range is the platform for companies operating across stablecoins and fiat. We start from the requirements a regulated company is held to, what the regulator expects, what auditors need to see, what gets reported and when, and translate those into operational controls applied to each transaction.

Range orchestrates the risk and compliance providers a customer already uses rather than replacing them, so existing screening and identity vendors keep their place and gain treasury context. Monitoring, reconciliation and reporting then run off the same record.

Neither September incident was a treasury failure, and Range does not control what arrives in a corporate inbox.

What Range covers is the point where value moves: whether that payment matches an existing approval, whether the destination satisfies policy and whether the company can show what was checked before value moved.

If payment approvals still depend heavily on the channel an instruction arrived through, get in touch.