Verify, Then Trust

This afternoon two emails from Trezor Security landed in my inbox, forty minutes apart, from two different addresses at the same domain. Subject line on both: “Critical Security Alert: STM32 Entropy Vulnerability.” The first arrived at 1:52 and I did not notice it until the second one showed up at 2:33.

They said a hardware flaw in the chips meant some recovery phrases were generated with as little as 40 bits of entropy, that roughly one in four devices was affected, and that I should check whether mine was one of them.

It was phishing. Trezor has since said publicly that the compromise was at their third party email provider. They spotted it and disclosed quickly, which is more than a lot of companies manage.

By late afternoon at least two more had gone out, so if you get one of these, assume the campaign is still running.

I want to talk about why the advice most of us give did not work here.

The sender check passed

The standard guidance is to look at who sent it. Check the domain. Watch for lookalikes, the extra letter, the wrong TLD.

That advice failed completely. The email came from Trezor’s real mailing domain. It carried a valid DKIM signature made with Trezor’s own signing key, the one published in Trezor’s own DNS. It passed DMARC against a policy that tells receiving servers to reject anything that fails. Forward and reverse DNS both agreed the sending host was who it claimed to be.

Nothing was spoofed. It really did come from inside Trezor’s mail pipeline, because whoever did this got into the account that holds the key.

That is the part worth sitting with. Email authentication answers one question: did this message leave a channel the domain authorized? It does not answer whether the content is honest. When a company hands its sending authority to a third party service, and someone gets into that service, every check still comes back green.

The ask is the tell

Here is what the email actually wanted. It linked to an “entropy check tool” that opens in your browser. The tool was described as validating BIP-39 checksums for 12, 18, or 24 words, validating SLIP-39 shares, and exporting an extended public key.

Read that again. To check your seed, it needs your seed.

The message even included the line “NEVER enter your recovery phrase on a website” directly above the button that asks you to do exactly that. That is not sloppiness. It is there to make you feel careful while you comply.

So the rule that survives:

Nothing legitimate ever asks you to type your recovery phrase into a browser. Not the manufacturer, not support, not a security alert, not a recovery tool, not a checker. There is no exception and there is no emergency that creates one. Your hardware wallet exists precisely so the phrase never touches an internet connected device.

Judge the ask, not the address.

Two hosts, two very different levers

There are two machines in this story and it is worth keeping them apart, because it decides who can stop what.

The links in the email do not point straight at anything. They point at a tracking address on Trezor’s own domain, which then forwards you onward. That address belongs to Trezor. They can delete it themselves, in seconds, without anyone’s permission.

Where it forwards to, I do not know, and I am not going to find out by clicking. That page is on infrastructure somebody else controls, and getting it removed runs on a registrar’s clock and a hosting provider’s clock, not on the clock of the person staring at the email right now.

I watched the first lever get pulled this afternoon. At 2:47 the sending host on Trezor’s domain still resolved to an address at their bulk email provider. By 3:16 that record was gone. Something was removed in that half hour, and I cannot tell you who did it or why, only that it was there and then it was not.

It changed nothing. Two more of these arrived at 3:08 and 3:10, from the same provider account, still carrying a valid signature. Deleting a name from DNS hides it from lookups. It does not revoke the ability to send, and it does not invalidate a signature.

The lever that would actually work is the signing key itself, published as a single DNS record on Trezor’s domain. Remove or rotate it and every message after that fails its signature check, fails the domain’s own reject policy, and gets refused at the receiving server before anyone reads it. As I write this, that record is still published.

That gap, between the company knowing and the mail actually stopping, is where the losses happen. It is also why a warning from a friend beats a press release.

They did not just get the ability to send. They got the list.

This is the part I would sit with longest, and it is the reason not to file this away as one bad afternoon.

When the breach is at the company that sends the mail, two things walk out the door. The ability to send as that company, which is the part everybody noticed today. And the customer list, which is the part that matters next month.

Whoever has that list now knows who owns one of these devices and where to reach them. The next email does not have to come from the vendor’s domain at all. It can come from anywhere, addressed to exactly the right people, about exactly the right product, and it will look legitimate again because it will be written for an audience the sender actually knows.

The scary part: they did not make the story up

Go back and read what the email claimed. A flaw in the STM32 chips. Seeds generated with as little as 40 bits of entropy. Crackable by brute force.

Now here is what actually happened to a different company six weeks ago.

On 30 July an attacker drained 1,196 Bitcoin addresses in 41 minutes, taking roughly 1,082 BTC. Galaxy Research mapped the sweep to a firmware flaw in Coldcard, the Bitcoin-only hardware wallet from Coinkite. A firmware integration error dating to 2021 had routed seed generation to a deterministic software pseudorandom generator instead of the STM32 hardware random number generator. Coinkite’s own estimate of the damage: effective entropy of roughly 40 bits on the Mk3, against the 128 bits a 12-word seed is supposed to carry. Galaxy has since traced further waves, and the last one moved coins two days ago.

Read those two paragraphs again. The phishing email did not invent a scary sounding vulnerability. It took a real one, with real numbers, and pointed it at a different manufacturer.

That is why it works. Anyone who followed the news in August has “hardware wallet, STM32, 40 bits, seeds are crackable” already sitting in their head as a true thing. The email is not asking you to believe something new. It is asking you to believe the thing you already believe, about your device this time.

And the sales pitch writes itself: everyone else is vulnerable too, come check whether yours is strong. There have been dozens of these since August. People have fallen for them.

So the useful response is not to memorize the details of this particular email. Those details expire. The useful response is to get better at the shape.

What I actually did

I did not click anything. I ran the links through a checker that resolves and reports on a URL without ever contacting it, and I read the raw email headers as text.

That took about twenty minutes and most of it was reading. The links were live. The signature was real. The body was asking for a seed. That combination is enough to act on without visiting anything.

Then I warned the people I know who hold one of these devices, before I understood every detail, because a warning that arrives late is worth much less than one that arrives incomplete.

I still do not know where the link goes

Here is where I have to leave it, and I think the gap is the whole point.

I am not going to click it. So I cannot tell you whether the page at the end is still up, or what it looks like, or what it asks for. What I can tell you is that the link in front of me shows a domain that genuinely belongs to Trezor, and it forwards somewhere I have no way to confirm.

Everything visible checks out. The sender is real. The domain is real. The signature is real. And none of that tells me anything about the destination.

That is not a gap in my tooling. That is the situation. The things we were taught to inspect are exactly the things that were bypassed here, and they were bypassed using the company’s own infrastructure against the company’s own customers.