In recent years, hardware wallets have been regarded as one of the most secure ways to store private keys in the blockchain industry. Once generated, private keys are stored in the wallet’s secure element (SE), and are only used to sign incoming external data. This air-gapped hardware design, combined with software mechanisms that prohibit key export, builds a strong protective barrier.

However, this security architecture has its Achilles’ heel — hardware wallets rely heavily on external client software and communication channels. If these external components are compromised, an attacker can perform a man-in-the-middle (MITM) attack, replacing information without the user’s awareness, leading to asset loss.

What Is a Man-in-the-Middle Attack?

A man-in-the-middle attack occurs when an attacker secretly intercepts, alters, or forges messages between two parties who mistakenly believe they are communicating directly.

This type of attack is common in network eavesdropping, data forgery, identity theft, and address substitution. It is especially dangerous in the crypto space — an attacker only needs to substitute a receiving address to potentially cause irreversible loss of assets.

A real-world analogy: imagine you mail an important letter to a friend. A “malicious mailman” intercepts the letter, modifies its content, reseals it, and delivers it. Your friend receives it unaware that the message has been altered.

In this example, the mailman plays the role of the man-in-the-middle, manipulating the message during transmission.

In blockchain systems, since most public chains only require a recipient address for transfers (with no name verification), MITM attacks are easier to execute and typically result in more significant, unrecoverable losses.

Hardware Wallet Communication Flow: The Invisible Mailman

Mainstream hardware wallets typically use one of four communication methods:

• USB: The most common and stable, using data cables for bidirectional transfer
• Bluetooth: BLE, often used with mobile devices
• QR Code (airgap): A newer method involving mutual scanning for physical isolation
• NFC: Near-field communication, currently less common

Of these, USB and Bluetooth are the most prevalent. Regardless of the method, the flow is similar:

1. The “wallet client” (browser extension or mobile app) initiates a connection
2. It sends a request to the “hardware wallet” — e.g., to fetch an address or sign data
3. The request is delivered through a communication channel
4. The device processes and responds
5. The client receives and displays the result

Although the hardware wallet is a secure “vault,” the communication relies on a chain of intermediaries — the client software and transmission channel — like an unseen mailman. If the mailman is hijacked or turns rogue, the data could be tampered with along the way.

This is the hidden threat — the “Sword of Damocles” hanging over hardware wallets: the man-in-the-middle attack.

A Real-World Example: MITM via Malicious Script

Disclaimer

• All code and tests were conducted in September 2023, over 20 months prior to this article (June 2025).
• The demo uses publicly available software versions; version numbers are noted.
• The attack was disclosed and acknowledged by relevant teams.
• This article is for educational and security research purposes only.
• The author assumes no responsibility for consequences resulting from this information.

How Trezor Communicates

When Trezor connects to MetaMask via USB, it often communicates using Trezor Bridge:

• The bridge runs a local HTTP server on port 21325 after installation
• MetaMask loads the https://connect.trezor.io JS SDK
• The SDK sends protobuf-encoded data to the local bridge server
• The bridge then locates the Trezor device using libusb and transmits data

If the local Trezor Bridge is installed, all SDK traffic is routed through the local bridge, not WebUSB.

Bridge Implementation Details

Trezor Bridge v2.0.27 is written in Golang. It uses xgo for cross-platform builds (macOS, Windows, Linux). On macOS, it installs the binary to /Applications/Utilities/TREZOR Bridge/trezord and creates a LaunchAgent plist for auto-start, Link.

<key>KeepAlive</key>
<true/>
<key>ProgramArguments</key>
<array>
  <string>sh</string>
  <string>-c</string>
  <string>/Applications/Utilities/TREZOR\ Bridge/trezord -l $HOME/Library/Logs/trezord.log</string>
</array>

Attack Overview

When MetaMask connects to a Trezor device, it reads the ETH public key and derives multiple addresses atclient-side — without any hardware confirmation. This makes the system susceptible to MITM.

If Trezor Bridge is compromised by malware, the attacker can intercept and manipulate all data between the wallet and the device, making UI-displayed information inconsistent with the hardware’s real data.

Test Setup

• Software used: Trezor Suite v23.8.1, Trezor Bridge v2.0.27, MetaMask v11.0.0
• Two Trezor Model T devices were prepared: one for normal behavior, one for MITM testing
• First, both devices behaved normally and displayed correct addresses
• Then, a malicious script replaced the trezord process
• The first device still worked fine
• The second device’s address was tampered by the attacker

Youtube Video

Code Analysis

Logs were added to Trezor Bridge to monitor requests and responses:

1_RI1x-z_ULhghSN43aGjzOw.webp

if mode != core.CallModeWrite {
  hexbodyStr := hex.EncodeToString(binbody)
  
  a.logger.Log(fmt.Sprintf("hexbodyStr, %s", hexbodyStr))
  
  hexres := hex.EncodeToString(binres)

  a.logger.Log(fmt.Sprintf("hexres, %s", hexres))
  
  _, err = w.Write([]byte(hexres))
  if err != nil {
   a.respondError(w, err)
  }
 }

 
[28.178293 : 16:14:47] [server/api/api.go 220 server/api.(*api).call] hexbodyStr, 003700000000
[27.843938 : 16:14:47] [server/api/api.go 220 server/api.(*api).call] hexbodyStr, 000b0000001f08ac8080800808bc80808008088080808008080008002207426974636f696e
[27.843954 : 16:14:47] [server/api/api.go 228 server/api.(*api).call] hexres, 000c000000c70a4e080510f7c2896218002220520f8747876da744c2bf49fecc8562017c9be0ecf2f55eae8d9b98360dd72fc1322102bfb03b1c56e5a4bc3085acc16170c91fcb8903413291d6246ccbd0cfe769345b126f78707562364657475054416d5a386f636847554631716261436d4e6569685953636f53774d426177567232324b796666674c4a4635766d536d43364147537062325079565a59417a383337313147456d44486f42504d4b5775634d4a41376f47556831685a364874794646624d503918a3eeeb870d
[27.466270 : 16:14:46] [server/api/api.go 220 server/api.(*api).call] hexbodyStr, 000b0000001d08ac8080800808bc8080800808808080800808002207426974636f696e
[27.466317 : 16:14:46] [server/api/api.go 228 server/api.(*api).call] hexres, 000c000000c80a4f080410cec1b2da0a18002220f107c96b21b14c5a304af43e1187341dd153f4702d82a04fc712bd43b5d2d65332210201694395789981413027ef739b4360316a7d6878b18dcb9bc670a1a2bd8baad9126f7870756236456e76784c3665674737796d5a514b4d3141524e325670794c624e56624b68443168694d346555586333735967576574726e6461415a4b56626375466a523137755a68456a77447366516163387776576f4e78637738694144427466595663366d764b466e624157756318a3eeeb870d
[27.094882 : 16:14:46] [server/api/api.go 220 server/api.(*api).call] hexbodyStr, 001d0000002108ac80808008088180808008088080808008080008001207546573746e65742800
[27.094912 : 16:14:46] [server/api/api.go 228 server/api.(*api).call] hexres, 001e000000460a226d736a586538664d446e4c724a6877515675527332554462574c314d58324c6579581220258c7690ef920a9400c30705156b60dea068193e7d5e7d86f83e24682ca4b7b6
[24.027874 : 16:14:43] [server/api/api.go 220 server/api.(*api).call] hexbodyStr, 0000000000021800
[23.409576 : 16:14:42] [server/api/api.go 220 server/api.(*api).call] hexbodyStr, 003700000000

Returned identical serialized responses when replayed — no timestamps or unique parameters. Therefore, an attacker can hardcode responses and simulate fake hardware behavior.

In this demo, when the SDK requests an ETH public key, it receives a fake pre-encoded response from the attacker instead of the real one. The compiled malicious binary and helper daemon enable full address substitution.

Disclosure & Communication

The issue was reported to both MetaMask and Trezor teams:

• MetaMask report: HackerOne Report #2166893
• Trezor response email:

Core Issues & Recommendations

MetaMask Displays Full Address Without Hardware Confirmation

While hardware wallets are secure environments, MetaMask reads and displays full addresses without triggering a confirmation on the device.

Trezor’s SDK includes a showOnTrezor flag for displaying the address on-screen for confirmation. Most wallet apps support silent address reads but require confirmation when receiving funds.

However, MetaMask skips confirmation even on first use — opening a path for attack.

The Blind Signing Problem

This attack highlights a deeper issue: any non-deterministic data from hardware is theoretically unsafe.

Even with on-device confirmation, if the message is unreadable (as in blind signing), the user can’t verify it, exposing them to MITM attacks.

Example: The Safe multisig incident, where server-side JS replaced the signing payload. The Ledger blind signature mechanism failed to detect the change:

Incident Context

Multiple Vectors for Communication Hijacking

MITM is not limited to local malware. Some wallets use servers to encode transactions, adding attack vectors. Unsafe cables, USB hubs, or even peripherals can be leveraged as physical entry points.

From hardware to software, every communication layer is a potential vulnerability.

Raising Awareness Is Key

Even with end-to-end encryption, client-to-hardware wallet security isn’t guaranteed. Hackers will always weigh effort vs. reward — not just difficulty.

Many crypto teams deprioritize MITM protections. As shown in MetaMask’s bug bounty page, MITM is excluded.

Users must remain vigilant. Use isolated machines, avoid untrusted networks, and only download from trusted sources — even when using hardware wallets.

Final Thoughts

The myth of hardware wallet security doesn’t lie in the device alone — it depends on the security of the entire ecosystem.

When we ignore client integrity or overlook transmission safeguards, that invisible Sword of Damocles silently swings closer to our assets.

True security lies not just in hardware, but in every small detail you think doesn’t matter.