Written by: imToken
A hardware wallet with intact original chips, genuine firmware, and even the ability to successfully pass the official Genuine Check—could the assets inside still be stolen by hackers?
The recent Ledger security incident precisely exposed this seemingly impossible risk.
According to the investigation results subsequently disclosed by the Ledger security team, the attacker implanted an additional malicious circuit inside the affected device, which was able to intercept the mnemonic 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 mnemonic phrase may have already fallen into the hacker's hands the first time it was displayed on the screen.
Moreover, this is not the only security incident worth paying attention to recently.
Since September, from Bitget encountering the exploitation of a third-party security product vulnerability, to Trezor's email service provider Brevo being breached, to security issues appearing in some of MetaMask's infrastructure, a series of incidents are 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 likewise become entry points that attackers seek.
I. The New "Supply Chain Security" Alarm Sounded by Ledger
Let's first break down what happened to Ledger this time.
When buying a hardware wallet, people are usually on guard against two things: buying a fake, or receiving a device that has been pre-initialized by someone else.
The most common trick in the early years was for malicious intermediaries to first generate a mnemonic 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 directly deposit funds into it.
Although this scam is dangerous, the defense logic is very clear—use legitimate channels, check the device status, watch the device generate a new mnemonic phrase itself, and never use a ready-made mnemonic phrase from the box.
But this attack against Ledger has 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 will ultimately need to read the mnemonic phrase from the screen and write it down.
In other words, the implanted malicious circuit does not interfere with the mnemonic generation process at all; it merely monitors the mnemonic phrase and directly transmits it away. This is also why "the private key was not directly extracted from the security chip" does not mean that the user's wallet recovery information is still safe.
What is more troublesome is that even if the device passes the official Genuine Check, it may not be able to identify this additional hardware, because the 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 original factory to the user's hands.
After all, a device may need to go through multiple links such as regional distributors, third-party warehouses, logistics, and retailers. Any participant with the opportunity to physically access the device may become a risk point requiring additional assessment.
II. From Trezor to Bitget: How Do Attackers Bypass Core Security Defenses?
Having understood Ledger's problem, if we then look at the security incidents that Bitget and Trezor encountered one after another recently, we will find that the underlying logic is strikingly similar: the attackers likewise avoided the strongest frontal defense line and instead cut in from the peripheral "third-party services."
First, look at Trezor.
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.
Such emails easily make users nervous. After all, when it involves hardware wallets and security vulnerabilities, no one wants their assets to suffer losses because of it.
This is exactly what happened: the attacker exploited 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 in this incident that Trezor's hardware wallets or private key protection systems were compromised. 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 more difficult, because the emails may have come from a familiar official domain and could also pass normal email authentication checks, while the content had already been replaced by the attacker with phishing information.
If users voluntarily enter their mnemonic phrase because of this, what was originally only a third-party email service problem could further evolve into real asset losses.
Now let's look at Bitget.
On September 24, unauthorized asset transfers occurred in some of Bitget's hot wallets and warm wallets, ultimately verified to involve approximately US$388 million.
According to the investigation results officially announced 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 cold wallets were not affected. This sounds somewhat contradictory: since 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, after a user initiates a withdrawal, it is not the case that a person manually signs each transaction with a 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 mistakenly transferred out.
What Bitget exposed this time is exactly how risk further propagates to the asset execution system after upstream permissions and instruction verification fail. Therefore, "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 that 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 relevant staking business does not manage withdrawal keys on behalf of customers.
However, this does not mean that infrastructure problems will not have other impacts. 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 mnemonic 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 being transmitted to internal high-privilege systems, which can directly affect the execution of funds;
- MetaMask, in turn, 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 tickets, and email systems like Brevo.
These external services make products run more efficiently and also improve the 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 be transmitted to other core systems?
III. How should products and users defend themselves?
Faced with increasingly complex third-party dependency risks and interlocking dependency relationships, expecting product teams to retreat to the primitive state of "not relying on any external services" is obviously unrealistic and does not conform to market rules.
What truly tests the skill of a security architecture is minimizing every possible risk exposure.
For example, why should a SaaS provider that only handles marketing emails retain the contact data of all users over the long term? Why can third-party security monitoring tools 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 is often called "least privilege" and "separation of duties" in security architecture: an email-sending platform should only have the permissions required 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 transmitted from some internal system.
The Ledger incident further reminds hardware wallet manufacturers that security management even needs to extend to the physical circulation process of the product.
From factory shipment, warehousing, logistics, to dealer 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 software supply chain of a wallet 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 developing into habits in daily use.
First, minimize unnecessary intermediaries in the hardware wallet purchase process.
If conditions permit, prioritize ordering from the brand's official website and having it shipped directly from the original factory or official warehouse, which usually reduces the chance of the device being contacted, disassembled, or swapped by third parties after leaving the original factory's control.
From a risk management perspective, the more independent parties that come into contact with 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 re-understand whether "official messages" are trustworthy.
The Trezor incident has already shown that even if an email is indeed sent through the service platform officially used, it does not mean that the links and operation 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, but to proactively verify through the official website address you have saved or the official App you have already installed.
For non-custodial wallets such as imToken, users likewise need to identify official channels, use token.im as the basis for downloading and installation, and when encountering abnormal information, prioritize verification through official entrances such as "Help & Feedback" in the App.
No matter whether the other party claims to be official customer service, a security team, or provides a seemingly very professional vulnerability explanation, you should never disclose your mnemonic 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 that you may face more targeted phishing in the future; clicking a suspicious link requires further confirmation of whether malicious programs were downloaded or run; if a mnemonic phrase has already been entered, it should be handled immediately as a leak of wallet control.
If suspicious transactions or authorizations have been signed, it is also necessary to combine the specific on-chain operations to determine whether there is a continuing contract authorization risk.
As for third-party service failures or infrastructure abnormalities, it is more necessary to refer to the scope of impact disclosed officially to determine whether it involves your assets, service availability, or returns.
You cannot default to the conclusion that the private key has been compromised just because you hear about a "wallet security incident," and you should certainly not rashly transfer 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 for Rainy Days, But Must Never Rush to Migrate").
Final Thoughts
In the past, the phrase most often emphasized in the Crypto industry was "Not your keys, not your coins."
This phrase 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 part of the entire security system.
A genuine hardware wallet may still be physically tampered with during delivery; a notification genuinely sent from an official email system may also be exploited by attackers; and a set of third-party tools originally used to strengthen security may even become an entrance to the core fund system.
These cases do not mean that 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 within 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 a certain external link goes wrong, the entire mechanism can still firmly stop the risk midway and prevent it from crossing the final red line protecting user assets.
