Man-in-the-Middle Attack (MITM)

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

A man-in-the-middle (MITM) attack is a form of interception where an adversary secretly positions themselves between two parties who believe they are communicating directly. The attacker can read, modify, or completely replace messages passing through them. NIST defines it as "an attack in which an attacker is positioned between two communicating parties in order to intercept and/or alter data traveling between them."

In traditional networking, MITM attacks target login credentials, banking sessions, and email. In cryptocurrency, the stakes are higher and the attacks more targeted: a single intercepted transaction can result in irreversible loss of funds. Because blockchain transactions cannot be reversed once confirmed, MITM attacks that successfully redirect payments are especially devastating.

The attack does not require breaking any cryptographic algorithm. Instead, it exploits the gap between what users see and what actually happens on the network: a copied address that gets silently swapped, a DNS lookup that returns a malicious IP, or a P2P connection that routes through an adversary's infrastructure.

How It Works

A MITM attack follows a general pattern regardless of the specific vector:

1. The attacker gains a position on the communication path between two parties
2. Traffic flows through the attacker instead of directly between the legitimate endpoints
3. The attacker inspects, records, or modifies the data in transit
4. Both parties believe they are communicating normally because the attacker forwards (potentially altered) messages in both directions

What makes MITM attacks dangerous is their invisibility. Unlike a denial-of-service attack that disrupts communication entirely, a well-executed MITM preserves the appearance of normal operation while silently manipulating the content.

Clipboard Hijacking

The most common crypto-specific MITM vector is clipboard hijacking. Malware running on the victim's device monitors the system clipboard for strings matching cryptocurrency address patterns. When a user copies a wallet address, the malware replaces it with an attacker-controlled address in milliseconds.

Kaspersky Lab discovered CryptoShuffler in October 2017, a trojan that stole approximately 23 BTC (around $140,000 at the time) by monitoring clipboard contents and swapping Bitcoin, Ethereum, Zcash, Monero, and Dogecoin addresses. The malware operated silently in the background, and victims only discovered the theft after funds arrived at an unknown address.

More sophisticated variants like Laplas Clipper (discovered in 2023) pre-generate addresses that visually resemble the victim's intended recipient, exploiting the fact that users typically verify only the first and last few characters of an address.

DNS Hijacking

DNS hijacking redirects domain name lookups so that a legitimate URL resolves to an attacker-controlled server. In the crypto context, attackers compromise DNS registrars or DNS infrastructure to serve pixel-perfect clones of wallet interfaces, exchange login pages, or DeFi front-ends.

In August 2022, attackers compromised the DNS registrar for Curve Finance and redirected users to a cloned site that requested malicious token approvals. Approximately $575,000 was stolen before the attack was detected. Similar attacks hit Cream Finance and PancakeSwap in March 2021 through compromised GoDaddy DNS credentials, with fake sites prompting users to enter seed phrases.

BGP Hijacking

BGP hijacking exploits the trust-based nature of internet backbone routing. Attackers broadcast malicious BGP (Border Gateway Protocol) route announcements, causing internet routers to send traffic through attacker-controlled infrastructure instead of its intended path.

The most significant crypto BGP attack occurred in April 2018 against MyEtherWallet. Attackers hijacked BGP routes for Amazon's Route 53 DNS service, redirecting MyEtherWallet.com queries to a Russian-hosted phishing site for approximately two hours. The attack resulted in 215 ETH stolen (approximately $152,000). Victims had to click through browser HTTPS certificate warnings because the fake site used an untrusted TLS certificate.

Earlier, between February and May 2014, attackers from a Canadian ISP used BGP hijacking to redirect mining pool traffic from BTCGuild, Middlecoin, and other pools, stealing approximately $83,000 in cryptocurrency over four months by rerouting miners' hashpower to attacker-controlled pool servers.

Node API Interception

Web wallets and decentralized applications that communicate with blockchain nodes via HTTP/JSON-RPC can be vulnerable if the connection is unencrypted or the node endpoint is compromised. An attacker on the network path can intercept API calls, return falsified blockchain data, or manipulate transaction parameters before they reach the node.

This vector is related to eclipse attacks, where a node's view of the network is completely controlled by an adversary. While an eclipse attack isolates the node at the peer-to-peer level, API interception targets the communication between the user and the node they rely on for broadcasting transactions and querying balances.

Defenses Against MITM Attacks

BIP-324 Encrypted P2P Transport

BIP-324 defines an encrypted transport protocol for Bitcoin peer-to-peer connections, replacing the original plaintext v1 protocol. Authored by Dhruv Mehta, Tim Ruffing, Jonas Schnelli, and Pieter Wuille, it was enabled by default in Bitcoin Core 27.0 (April 2024).

The protocol uses ChaCha20-Poly1305 authenticated encryption with keys established via Elliptic Curve Diffie-Hellman (ECDH) on secp256k1. A novel ElligatorSwift encoding converts the handshake's elliptic curve points into pseudorandom 64-byte strings, making the handshake indistinguishable from random data and preventing protocol fingerprinting.

BIP-324 provides opportunistic (unauthenticated) encryption: it prevents passive eavesdroppers (ISPs, nation-states) from identifying or tampering with Bitcoin P2P traffic, and forces adversaries from passive surveillance to active, detectable MITM attacks. Authentication can be layered on top separately.

TLS/HTTPS for Web Wallets

TLS (Transport Layer Security) encryption protects web-based wallets and exchanges by encrypting all data between the user's browser and the server. TLS 1.3 provides the strongest protections, and all legitimate wallet services should enforce HTTPS connections.

However, TLS alone does not prevent all MITM attacks. The MyEtherWallet incident demonstrated that attackers who hijack DNS can present a different certificate. Browsers flagged the untrusted certificate, but some users clicked through the warning. This is why defense in depth matters: no single layer is sufficient.

Hardware Wallet Address Verification

Hardware wallets provide a trusted display controlled by a Secure Element chip isolated from the potentially compromised host computer. Users verify the recipient address on the device's screen before signing, defeating clipboard hijacking and screen-manipulation malware.

Researchers demonstrated the EthClipper attack in 2021, which pre-mines addresses visually similar to the victim's intended recipient. Since users often verify only a few characters, the attack achieved concerning match rates. The defense: always verify the complete address on the hardware wallet screen, not just the first and last few characters.

Certificate Pinning

Certificate pinning hardcodes a specific TLS certificate or public key into a mobile application. During the TLS handshake, the app validates that the server's certificate matches the pinned value and refuses the connection if it does not match, even if the certificate is otherwise valid. This defeats MITM attacks that rely on rogue certificates, compromised Certificate Authorities, or DNS hijacking.

Lightning Onion Routing

The Lightning Network uses source-based onion routing (defined in BOLT #4, based on the Sphinx construction) to prevent intermediaries from learning payment endpoints. The sender wraps the entire route in layered encryption: each forwarding node can only decrypt its own layer, revealing only the next hop. Intermediate nodes cannot determine the sender, the receiver, or their position in the route.

This design prevents routing nodes from acting as effective MITM attackers because they lack the context needed to selectively intercept or censor specific payments. Combined with HTLCs that cryptographically bind payment preimages to each hop, the protocol ensures that intermediaries cannot redirect or steal funds in transit.

MITM in the Context of Bitcoin and Layer 2

Bitcoin's cryptographic foundations provide strong protection against certain MITM scenarios. Every transaction requires a valid digital signature from the private key controlling the funds. An attacker who intercepts a transaction in transit cannot modify the recipient or amount without invalidating the signature. The MITM threat in Bitcoin is not about altering signed transactions but about manipulating what gets signed in the first place.

Layer 2 protocols like Spark inherit Bitcoin's signature-based security while adding their own protections. Spark uses FROST threshold signatures for cooperative operations, meaning multiple parties must independently validate and co-sign state transitions. A single compromised communication channel cannot unilaterally redirect funds because the protocol requires agreement from multiple independent signers.

Using Tor for Bitcoin and Lightning connections adds another defense layer by routing traffic through multiple encrypted relays, making it significantly harder for network-level attackers to identify and intercept specific connections. For users in adversarial network environments, combining Tor with BIP-324 provides defense in depth against both traffic analysis and active interception.

Practical Prevention Checklist

Protecting against MITM attacks requires layered defenses across different parts of the transaction flow:

• Verify addresses on a hardware wallet screen before signing any transaction, checking the full address rather than just the first and last few characters
• Use a dedicated device for high-value transactions, reducing exposure to clipboard malware and browser-based attacks
• Never ignore browser HTTPS certificate warnings, especially when accessing wallet interfaces or exchange sites
• Run a full Bitcoin node to independently verify blockchain data rather than trusting a third-party API endpoint
• Enable BIP-324 encrypted connections (default in Bitcoin Core 27.0+) to protect P2P traffic from passive eavesdroppers
• Use wallet software that implements certificate pinning to prevent DNS and BGP hijacking from redirecting connections to attacker-controlled servers
• Avoid public Wi-Fi networks for cryptocurrency transactions, as they are trivially easy to MITM

Risks and Considerations

Evolving Attack Sophistication

MITM attacks continue to grow more sophisticated. Early clipboard hijackers simply swapped addresses at random; modern variants like Laplas Clipper generate visually similar addresses that pass cursory inspection. DNS and BGP attacks have moved from opportunistic to targeted, with attackers obtaining valid TLS certificates (as in the 2022 KLAYswap attack, where attackers obtained a legitimate certificate via ZeroSSL for the hijacked domain) to avoid browser warnings entirely.

Defense Gaps

No single defense eliminates MITM risk. BIP-324 encrypts P2P traffic but provides opportunistic rather than authenticated encryption: it raises the cost of MITM from passive to active but does not prevent a sufficiently positioned attacker from performing an active interception. TLS protects the transport layer but relies on certificate authorities and DNS infrastructure, both of which have been compromised in documented attacks. Hardware wallets protect signing but require users to actually verify addresses on the device screen.

Supply Chain and Side-Channel Risks

MITM attacks can target the supply chain itself: compromised wallet software, tampered hardware devices, or malicious browser extensions can intercept transactions before any network-level protection applies. These side-channel and supply chain attacks bypass transport encryption entirely because the attacker operates within the trusted endpoint. For a deeper analysis of these vectors, see the research on wallet security attack surfaces and hardware wallet attack vectors.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.