Crypto Security: What Other Overlooked "Trust Blind Spots" Exist?

Written by: imToken

A hardware wallet with an intact original chip, genuine firmware, and even the ability to pass the official Genuine Check — and yet the assets inside could still be stolen by hackers?

The recent Ledger security incident exposed exactly this seemingly impossible risk.

According to the investigation results later disclosed by the Ledger security team, the attacker implanted an additional malicious circuit inside the affected device, which was able to intercept the seed phrase displayed on the screen and send it to the attacker via mobile communication networks.

In other words, the original security chip was not compromised, but the seed phrase may have already fallen into the hacker's hands the first time it was displayed on the screen.

And this is not the only security incident worth paying attention to recently.

Since September, from Bitget suffering exploitation of a third-party security product vulnerability, to Trezor's email service provider Brevo being breached, to security issues emerging in parts of MetaMask's infrastructure, a series of incidents is reminding us that as crypto products become increasingly complex, security is no longer just about protecting private keys and avoiding smart contract vulnerabilities.

The risks hidden in device circulation, third-party services, internal permissions, and user communications can equally become the entry points attackers look for.

1. Ledger Sounds a New Alarm for "Supply Chain Security"

Let's first break down what happened to Ledger this time.

When buying a hardware wallet, people usually guard against two things: buying a counterfeit, or receiving a device that has been pre-initialized by someone else.

The most common scam in earlier years was for malicious intermediaries to pre-generate a seed phrase, print it on a scratch card, and stuff it back into the packaging, betting that novice users would not understand the rules and would deposit funds directly.

Although this scam is dangerous, the defense logic is clear — buy from legitimate channels, check the device status, watch the device generate a new seed phrase itself, and never use the ready-made seed phrase in the box.

But this attack on Ledger clearly escalated the methods. The hacker stuffed an additional electronic module with a microcontroller, eSIM, and cellular communication capabilities inside the casing. When users initialize the wallet for the first time, they inevitably have to read the seed phrase from the screen and write it down.

In other words, the implanted malicious circuit does not interfere with the seed phrase generation process at all; it simply monitors the seed phrase and transmits it away directly. This is why "the private key was not directly extracted from the security chip" does not mean the user's wallet recovery information is still safe.

What's worse, even if the device passes the official Genuine Check, it may not be able to identify this kind of additional hardware, because genuine verification mainly confirms the identity of the security chip and the trustworthiness of the firmware.

So this incident has indeed exposed a serious "supply chain risk" that is easily overlooked in daily life: the security of a hardware wallet depends not only on the chip and firmware, but also on the entire delivery process from the factory to the user's hands.

After all, a device may need to pass through regional distributors, third-party warehouses, logistics, and retailers, and any participant with the opportunity to physically touch the device could become a risk point requiring additional assessment.

2. From Trezor to Bitget: How Do Attackers Bypass Core Security Defenses?

Having understood Ledger's problem, if we look at the security incidents that recently hit Bitget and Trezor, we will find that the underlying logic is strikingly similar: the attackers likewise avoided the strongest frontal defenses and instead cut in from the peripheral "third-party services."

Let's look at Trezor first.

In early September, some Trezor users received an email with the subject "Critical Security Alert: STM32 Entropy Vulnerability," claiming that the hardware wallet had a serious security vulnerability and that immediate action was required.

This kind of email easily makes users nervous. After all, it involves hardware wallets and security vulnerabilities, and no one wants their assets to be lost as a result.

This was exactly the attacker exploiting Brevo, the third-party email marketing platform used by Trezor, to let malicious content reach users' inboxes through normal email-sending infrastructure.

According to Brevo's subsequent incident report, the attacker exploited permission boundary flaws in its single sign-on system to gain unauthorized access to other customer accounts, ultimately involving 138 customer accounts, some of which were used to send phishing emails or export contact data.

Trezor subsequently confirmed that 347,149 marketing email contact addresses were exported in the incident, and the attack emails attempted to induce users to download malicious applications and enter wallet backup information.

It should be noted that there is no evidence that Trezor's hardware wallets or private key protection systems were compromised in this incident; what the attacker first obtained was user information and the ability to abuse official communication channels.

But for ordinary users who received the emails, identifying the risk became even harder, because the emails may have come from a familiar official domain and could pass normal email authentication checks, while the content had already been replaced by the attacker with phishing information.

If users voluntarily enter their seed phrase as a result, what was originally just a third-party email service problem could further evolve into real asset losses.

Now let's look at Bitget.

On September 24, unauthorized asset outflows occurred in some of Bitget's hot wallets and warm wallets, ultimately confirmed to involve approximately $388 million.

According to the investigation results officially released by Bitget, the attacker exploited a vulnerability in a third-party security product to obtain high-privilege credentials inside the exchange, then intruded into wallet-related backend systems, forged withdrawal instructions, bypassed original risk control checks, and caused abnormal transfers to enter the normal execution process.

Bitget stated that no private key leakage was found in this incident, and the cold wallet was not affected. This sounds somewhat contradictory: if the private keys were not stolen, why could the money still be transferred away?

Actually, it is not hard to understand.

For custodial platforms like exchanges, when users initiate withdrawals, it is not the case that a person manually signs each transaction with the private key every time. Instead, it needs to go through a whole set of internal processes such as account verification, risk control review, transaction generation, and wallet signing.

This is like a bank vault. Even if the vault key is kept very strictly, if someone can impersonate an internal high-privilege identity and forge a transfer instruction that passes approval, the funds in the vault may still be transferred out incorrectly.

What Bitget exposed this time is exactly how risk further propagates to the asset execution system after upstream permissions and instruction verification fail. So "the private key was not leaked" and "funds will not be illegally transferred away" are actually two different things.

As for the infrastructure security incident disclosed by MetaMask at the end of September, it presented another dimension of operational risk.

At the time, MetaMask took preventive measures and proactively exited some affected staking validators. According to the official investigation update on October 1, no signs have been found that MetaMask wallets or customer funds were affected, and the related staking business does not manage withdrawal keys on behalf of customers.

However, this does not mean that infrastructure problems will not have other effects. Non-custodial solutions mainly address the issue of asset control, but they cannot automatically eliminate the operational risks of external infrastructure.

Putting these events together, the thread is actually very clear:

• What Ledger exposed is the risk of physical tampering in the hardware circulation process, which may ultimately lead to the theft of seed phrases;
• What Trezor / Brevo exposed is the risk of user information leakage and abuse of official communication channels, which does not mean the wallet itself was compromised;
• What Bitget exposed is the risk of vulnerabilities in third-party products propagating to internal high-privilege systems, which can directly affect fund execution;
• MetaMask reminds us that asset control and service operation risk are not the same concept.

Overall, today's crypto products are no longer isolated islands.

Wallets rely on external RPC nodes to read on-chain data and on aggregation interfaces to pull market quotes; exchanges cannot do without external security monitoring, KYC verification, and risk control components; extending further outward, there are also node operators, cloud providers, customer service ticketing, and email systems like Brevo.

These external services make products run more efficiently and improve user experience, but at the same time, every time a new external dependency is introduced, the product gains another layer of trust relationships that need to be managed:

What can third parties access, how much authority do they have, and if they are compromised, will the risk continue to propagate to other core systems?

3. How Should Products and Users Defend Themselves?

Facing increasingly complex third-party dependency risks and interlocking dependency relationships, it is obviously unrealistic to expect product teams to retreat to the primitive state of "not relying on any external services," nor does it conform to market rules.

What truly tests the strength of a security architecture is minimizing every possible risk exposure.

For example, why should a SaaS provider that only sends marketing emails retain the contact data of all users for a long time? Why should a third-party security monitoring tool be able to reach the core production environment without independent multi-authorization? Especially for sensitive actions involving fund transfers, internal systems must never adopt "default trust" and must implement strict permission isolation and independent cross-verification.

This is also what security architecture often calls "least privilege" and "separation of duties": the email platform should only have the permissions needed to send emails, security monitoring tools should not be able to execute fund transfers at will, and a large withdrawal should not be approved directly based solely on an instruction from some internal system.

The Ledger incident further reminds hardware wallet manufacturers that security management even needs to extend to the physical circulation of products.

From factory shipment, warehousing, logistics, to distributor delivery, how to establish a traceable management process, how to detect abnormal disassembly or replacement of devices, and how to locate affected batches and users after a problem occurs should not be regarded as mere channel management work.

Because for a hardware device that protects private keys, the delivery process itself is part of the security system.

Of course, for ordinary users, we can neither audit the wallet's software supply chain nor investigate every warehousing and logistics link of a hardware wallet one by one.

But this does not mean we can only passively bear the risk. At least there are several things worth forming habits around in daily use.

First, minimize unnecessary intermediate steps when purchasing a hardware wallet.

If conditions permit, prioritize ordering from the brand's official website and having it shipped directly from the original factory or official warehouse. This usually reduces the chance of the device being touched, disassembled, or swapped by third parties after leaving the factory's control.

From a risk management perspective, the more independent parties that touch the device, the more links require additional trust. In addition, after receiving the device, you should still check for packaging and appearance abnormalities, use official software to complete verification, and strictly follow the initialization process.

Second, it is necessary to rethink whether "official messages" are trustworthy.

The Trezor incident has already shown that even if an email is indeed sent through an official service platform, it does not mean the links and operational requirements in it are necessarily safe.

Especially when it involves sensitive operations such as wallet upgrades, account freezes, asset migration, and vulnerability fixes, it is best not to click links in the message directly. Instead, verify proactively through the official website address you have saved yourself or the official App you have already installed.

For non-custodial wallets like imToken, users likewise need to identify official channels. Downloads and installations should be based on token.im. When encountering abnormal information, prioritize verification through official entry points such as "Help & Feedback" in the App.

No matter whether the other party claims to be official customer service, a security team, or provides what looks like a very professional vulnerability explanation, you should never disclose your seed phrase or private key to them.

Finally, it is necessary to distinguish the actual impact of different security incidents on yourself.

An email address leak mainly means you may face more targeted phishing in the future; clicking a suspicious link requires further confirmation of whether malicious programs were downloaded or executed; if a seed phrase has already been entered, it should be handled immediately as a loss of wallet control.

If suspicious transactions or approvals have been signed, it is also necessary to combine the specific on-chain operations to determine whether there is an ongoing contract approval risk.

As for third-party service failures or infrastructure abnormalities, it is even more necessary to refer to the scope of impact disclosed officially to determine whether it involves your assets, service availability, or returns.

You should not assume that the private key has been compromised just because you hear about a "wallet security incident," and you should certainly not rashly move assets to unfamiliar addresses because of so-called urgent security notifications.

After all, in many cases what attackers really expect is not to break through the strongest technical defense line, but to make users voluntarily complete the final step in panic (Further reading: "AI "Challenges" Cryptography? Web3 Must Prepare in Advance, But Must Never Migrate Rashly").

Final Thoughts

In the past, the phrase most often emphasized in the crypto industry was "Not your keys, not your coins."

This statement is still important, because private key control determines whether users can truly control their assets independently.

But as wallets, exchanges, and on-chain financial products gradually mature, we also need to realize that private key protection is only one part of the entire security system.

A genuine hardware wallet may still be physically tampered with during delivery; a notification that truly comes from an official email system may still be exploited by attackers; and a third-party tool originally used to strengthen security may even become the entry point to the core fund system.

These cases do not mean we should lose trust in all wallets and external services. On the contrary, they remind the entire industry that security needs to be extended from inside a single product to the entire process of supply chain, permission management, user communication, and emergency response.

After all, a truly mature crypto security system must not only ensure that private keys are not easily leaked, but also ensure as much as possible that even if some external link goes wrong, the entire mechanism can still stop the risk dead in its tracks and prevent it from crossing the final line of defense protecting user assets.