How BGP hijacking enabled crypto theft and traffic interception

For two hours on the morning of 24 April 2018, anyone who typed myetherwallet.com into a browser and ignored a certificate warning was handing their private keys to a stranger. The site looked right. The DNS answer was wrong. And the reason the DNS answer was wrong had nothing to do with the wallet’s servers, its registrar, or its DNS provider’s security. Someone had lied to the internet’s routing table about who owned a slice of Amazon’s address space, and the lie held just long enough to drain about $150,000 in Ether.

That attack, and a near-identical one against the Korean DeFi platform KlaySwap four years later, are the cleanest worked examples of a problem that sits underneath every TLS handshake on the web. BGP decides where packets go. Almost nothing about BGP is authenticated. If you can convince enough routers that traffic for a victim’s IP belongs on your wire, you own that traffic for as long as the lie propagates, and the modern web’s defenses, certificates included, were quietly assuming that could never happen.

This post walks through the mechanism end to end. It covers how a route hijack actually redirects traffic, the 2018 Route 53 attack on MyEtherWallet in detail, the 2022 KlaySwap attack and the wrinkle that made it nastier, how a short-lived hijack converts into a valid HTTPS certificate, and the defenses that have shipped since: RPKI route origin validation on the routing side and multi-perspective issuance corroboration on the certificate side. For the broader history of route leaks and accidental hijacks, see BGP hijacks and route leaks; this piece stays on the targeted, for-profit variety.

The mechanism: announce a more-specific, win the route

BGP is the protocol autonomous systems use to tell each other which blocks of IP address space they can reach. An autonomous system, or AS, is a network under one administrative control, identified by a number: Amazon is AS16509, Cloudflare is AS13335. When an AS originates a prefix, say 205.251.192.0/24, it is asserting “send me packets for these 256 addresses and I will deliver them.” Its neighbors propagate that announcement to their neighbors, each one prepending its own AS number to the path, and within minutes the announcement is in routing tables across the planet.

There is no built-in check that the originating AS is allowed to announce that prefix. That is the whole problem. A router receiving two announcements for overlapping space picks a winner using a fixed decision process, and two rules in that process are what hijackers exploit. First, a router always prefers the most specific prefix that covers a destination. A /24 (256 addresses) beats a /16 (65,536 addresses) for any address inside it, because longest-prefix match is how forwarding works at the data plane and it carries straight into route selection. Second, among equally specific announcements the router prefers the shorter AS path. So an attacker who wants to steal traffic for a /16 that the victim legitimately announces does not have to out-compete it. They announce a /24 carved out of it. Every router that hears the /24 will prefer it for that slice, regardless of how short or trusted the victim’s path is.

*A more-specific announcement wins on longest-prefix match alone, so the attacker never has to beat the victim's path length, only carve a smaller block out of it.*

Three things follow from this, and they shape every targeted hijack. The attack is fast: propagation is a matter of minutes, and a hijack that lasts an hour is plenty. The attack is surgical: announcing a single /24 pulls in only the addresses the attacker wants, which keeps the blast radius small and the noise low. And the attack needs an origin AS, a network position from which to make the announcement and a transit provider willing to accept and forward it. In practice that origin is almost never the attacker’s own clean network. It is somebody else’s, borrowed or compromised. Both of the heist cases below originated from a third-party AS whose operator had no idea their network was being used.

What the attacker does with the captured traffic is a separate question. Redirect a DNS server’s IP and you can hand out forged DNS answers. Redirect a web server’s IP and you can serve a forged page. Redirect a CDN origin and you can tamper with a JavaScript file every visitor loads. The hijack is the delivery vehicle; the payload varies. The 2018 attack went after DNS. The 2022 attack went after a script. Both ended at the same place: a victim’s browser talking to the attacker over what looked like a clean HTTPS connection.

2018: the Route 53 hijack of MyEtherWallet

Amazon’s Route 53 is authoritative DNS. When a resolver needs the IP for a domain hosted on Route 53, it queries one of Amazon’s authoritative nameservers, and those nameservers live on a handful of well-known Amazon prefixes. On 24 April 2018, between roughly 11:05 and 13:03 UTC, five of those /24 blocks were announced by an AS that had no business announcing them: AS10297, eNet, a hosting company in Columbus, Ohio. The hijacked prefixes were 205.251.192.0/24, 205.251.193.0/24, 205.251.195.0/24, 205.251.197.0/24, and 205.251.199.0/24, roughly 1,300 of Amazon’s addresses. eNet peered with large carriers including Level 3, Hurricane Electric, Cogent, and NTT, so the bogus announcement got good reach.

For about two hours, a slice of the world’s DNS resolvers asking Route 53 for an answer were not reaching Amazon. They were reaching a server sitting in customer space at an Equinix data center in Chicago, configured to answer authoritative queries the way Amazon would, except for the records the attacker cared about. A query for myetherwallet.com came back pointing at an attacker-controlled web server hosted in Russia rather than the real one. The resolver cached the forged answer and handed it to users. From the user’s side, nothing in the address bar changed; they typed the right domain and their resolver gave them the wrong IP, because the machine that should have been authoritative had been quietly replaced at the routing layer.

*The hijack moved Route 53's IP space, so the forged nameserver answered as if it were Amazon. The user typed the correct domain and still landed on the phishing site.*

The one thing that did not work for the attacker was TLS. The phishing site presented a self-signed certificate, so every browser threw a full-page warning. The interception bought the attacker a forged DNS answer and a look-alike page, but not a trusted padlock, because a self-signed cert is not chained to any CA in the browser’s trust store. Users who stopped at the warning were fine. Users who clicked through were not, and enough of them clicked through to lose around 215 Ether. The destination wallet already held a far larger balance, on the order of millions of dollars, which suggests the operator was practiced rather than opportunistic.

The post-mortems converged on two points. The hijack was almost certainly not eNet acting maliciously; far more likely someone borrowed eNet’s routing to make the announcement, the way these things usually go. And the damage could have been contained by prefix filtering at the transit providers, the basic discipline of not accepting a customer’s announcement for address space that customer has no right to. Some networks in the path had MANRS-aligned filtering and did not propagate the bogus route. Enough did not.

If you want the DNS side of this in detail, DNS resolution end to end walks through why an authoritative answer is trusted on arrival, and why moving the authoritative server’s IP is enough to forge it. The routing trick is what made Route 53’s IP move; everything downstream was DNS behaving exactly as designed.

2022: KlaySwap, a stolen script, and a real certificate

The KlaySwap attack on 3 February 2022 used the same primitive and fixed the one thing that had failed in 2018. This time the attacker got a valid certificate.

KlaySwap is a DeFi platform on the Klaytn chain. Its frontend loaded a JavaScript SDK from KakaoTalk, the dominant Korean messaging service, specifically Kakao’s hosted file at developers.kakao.com/sdk/js/kakao.min.js. That single script dependency was the target. The attacker did not need to touch KlaySwap’s own servers. They needed to control the IP that served Kakao’s SDK, swap the file, and let every KlaySwap visitor’s browser fetch the poisoned version.

Starting around 10:04 KST, malicious announcements began originating from AS9457, an AS operated by the Korean provider Dreamline, again almost certainly manipulated rather than complicit. The attacker reached for the more-specific trick. To capture Kakao’s 211.249.216.0/21, they announced 211.249.221.0/24, a longer prefix carved from inside it, so routers preferred it on longest-prefix match. A second phase around 11:09 hit another Kakao block via 121.53.104.0/23. With the routing in place, queries for the SDK’s host landed on the attacker’s server, which served a modified kakao.min.js.

The poisoned script was selective. It carried a filter so it only activated its malicious branch for KlaySwap users, leaving every other site that loaded the same Kakao SDK untouched, which kept the attack quiet. When it saw a KlaySwap transaction, a deposit, a swap, a withdrawal, it rewrote the destination so the user’s assets went to an attacker-controlled contract instead. Roughly $1.9 million was announced as the loss, later compensated by the operator. The funds were swapped into stablecoins and moved out through cross-chain bridges and the FixedFloat exchange.

*The certificate was issued about an hour into the hijack. With a valid cert in hand, the poisoned script loaded over clean HTTPS and no browser complained.*

The certificate is the part worth slowing down on, because it is the difference between the 2018 warning page and a clean padlock. A domain-validated certificate proves one thing: that whoever asked for it could demonstrate control of the domain at issuance time. Control is usually proven by answering an HTTP challenge or hosting a token at a path the CA fetches. The CA connects to the domain, sees the expected response, and signs. But the CA reaches the domain over the same routing fabric as everyone else. If the attacker has hijacked the domain’s IP, the attacker is what the CA connects to. The attacker answers the challenge correctly, because as far as the network is concerned, the attacker is the domain right now.

That is exactly what happened. About an hour into the KlaySwap hijack, at 11:27 KST, the attacker obtained a free certificate from ZeroSSL for the Kakao host. The hijack made the attacker’s server the thing the CA reached during validation, the challenge passed, and the certificate signed. Now the poisoned script could be served over HTTPS with a certificate that chained cleanly to a trusted root. No warning. The Princeton analysis of the incident put the structural point plainly: the attack exploited the false trust that TLS places in the routing infrastructure. The padlock attests to a network-path check, and the network path was the thing under the attacker’s control.

A third incident that August closed the loop. The Celer Network bridge frontend was hijacked the same way, with a forged origin to make the route look like it came from Amazon and a certificate from a different free provider, GoGetSSL, obtained minutes after the route went live. Same recipe, different ingredients. By late 2022 the pattern was a known technique with three worked examples, and the people who run CAs had been thinking about it for years already.

How a short hijack becomes a trusted padlock

It is worth stating the full chain in one place, because the 2018 and 2022 cases are two snapshots of the same sequence, one stopped at the certificate step and one that cleared it.

The attacker picks a target IP: an authoritative nameserver, a web origin, a script host. They announce a more-specific prefix covering that IP from a borrowed or compromised AS, and within minutes a chunk of the internet routes the target’s traffic to them. While the hijack holds, they go to a CA and request a domain-validated certificate for the target’s hostname. The CA performs its domain-control check by connecting to the hostname, which now resolves and routes to the attacker, so the challenge succeeds and the certificate signs. The attacker installs that certificate on their interception server. Now any victim whose own path to the target is also hijacked gets a TLS connection that validates: correct hostname, valid chain, no warning. The attacker terminates the victim’s TLS, reads or rewrites the plaintext, and either serves a phishing page, forges a DNS answer, or swaps a script. When they are done they withdraw the announcement and the route heals, often within the hour.

*The whole attack hinges on steps two and three. If the CA validates from a vantage point the hijack does not reach, the chain breaks before a certificate is ever signed.*

Two properties make this hard to catch in the moment. It is local. A more-specific announcement does not have to reach the whole internet; it only has to reach the victim’s resolver path and the CA’s network path. Observers elsewhere see nothing wrong, and the victim sees a valid padlock. It is brief. The hijack needs to survive a DNS lookup and one CA validation request, both measured in seconds, plus the window in which victims transact. Pull the announcement and the evidence in the global routing tables largely evaporates, which is why these incidents are usually reconstructed after the fact from route-collector archives rather than caught live.

What this also means is that classic endpoint defenses do not help. The victim’s machine is not compromised. The DNS provider is not compromised. The CA is not compromised in any conventional sense; it followed its own rules and those rules trusted the network. HTTPS is doing precisely what it promises, authenticating that you are talking to the holder of a valid certificate for the hostname, and that promise is hollow when the certificate holder is whoever held the route at issuance time. Where your TLS connection actually terminates, and who controls that endpoint, is the question the TLS terminating proxy gets into; a route hijack is just a way to insert an unauthorized terminator.

Closing the routing side: RPKI and route origin validation

The clean fix is to authenticate route origins so a router can reject 205.251.192.0/24 from AS10297 as a forgery on its face. That is what the Resource Public Key Infrastructure does. RPKI lets the legitimate holder of an address block publish a signed Route Origin Authorization, a ROA, that says “this prefix, up to this maximum length, may be originated by this AS and no other.” Routers running Route Origin Validation check incoming announcements against the ROA database and mark anything contradicting a ROA as invalid, which most deploying networks then drop.

ROAs would have stopped the 2018 hijack at the door if Amazon had published them and eNet’s upstreams had validated. Amazon did publish ROAs for the affected Route 53 ranges in the months after the incident. By 2025 the picture had shifted considerably: more than half of IPv4 and IPv6 routes in the global table are covered by ROAs, around 54 percent, and because the tier-1 backbones that reject invalids carry so much traffic, an estimated 74 percent of traffic is heading toward ROA-covered destinations. Measurement work tracking validation adoption found roughly 63 percent of autonomous systems deriving some benefit from ROV, though the share fully filtering invalids was still in the low double digits.

RPKI has a sharp edge that the more-specific trick walks right up to. The maximum-length field in a ROA matters enormously. If a holder publishes a ROA for a /16 with max length /24, then any /24 carved from that block is still a permitted, valid announcement as long as the origin AS matches, and an attacker who can forge or borrow that origin slips through. The Celer Bridge hijack exploited exactly this kind of loose authorization: a ROA that permitted Amazon ASNs across a wide range of prefix lengths, combined with a forged origin AS, produced an announcement that passed validation. ROV is not a switch you flip; the ROAs underneath it have to be tight, with max-length set to the prefixes you actually announce, or the more-specific door stays open.

*A ROA with a generous maximum length still authorizes the more-specific announcements an attacker reaches for. Setting max-length to the prefixes you actually originate is what closes the gap.*

RPKI authenticates the origin AS but not the rest of the AS path, which is why path forgery, claiming a legitimate origin while inserting yourself as upstream, remains a gap that origin validation alone does not close. Work on path validation, ASPA and the broader BGPsec effort, aims at that, with slow real-world uptake. For the wider story of how route leaks and hijacks have played out across the internet’s history, and where path security sits, BGP hijacks and route leaks covers the ground; the takeaway for the heist cases is narrower. Tight ROAs plus widespread ROV would have blocked or contained all three.

Closing the certificate side: multi-perspective validation

The routing fix is necessary but slow, because it depends on every network in the path deploying it. The certificate side had a fix that a handful of CAs could deploy unilaterally and protect everyone, and that is the more interesting story.

The insight is that a more-specific hijack is local. It bends a subset of internet paths, not all of them. So if a CA validates domain control from one place, the attacker only has to corrupt that one path. But if the CA validates from several network locations spread across the internet and requires them to agree, the attacker has to hijack all of those paths at once, which is far harder for a localized announcement and far noisier when attempted. Let’s Encrypt deployed exactly this on 19 February 2020, built on research from Princeton, performing each domain-control check from its primary data center plus multiple remote perspectives and requiring a quorum to agree before signing. The early deployment forced an attacker to compromise the primary path plus a majority of the remote paths simultaneously, and it validated every certificate this way at a scale of over a billion within a few years.

The technique then moved from one CA’s good practice to an industry rule. The CA/Browser Forum passed Ballot SC-067, which writes multi-perspective issuance corroboration into the Baseline Requirements that every publicly trusted CA must follow. MPIC requires domain validation and CAA checks to be corroborated from independent network perspectives at least 500 kilometers apart, with a phased rollout through 2025: a soft requirement from 15 March 2025 and hard enforcement, where issuance fails if the remote checks do not corroborate, from 15 September 2025. As of 2026 this is baseline, not best-effort. A CA that signs a certificate today is supposed to have confirmed domain control from several vantage points that a single local hijack cannot all reach.

This is the cleaner of the two defenses, and not only because one party can deploy it. It attacks the precise step the heists depended on. The 2018 attack failed at the certificate because the operator never bothered with a CA-issued cert and ate the warning. The 2022 and Celer attacks succeeded because a single-perspective CA validated over a path the hijack controlled. Run that same validation from four other continents and at least one of them routes to the real server, the corroboration fails, and no certificate is issued. The hijack can still redirect traffic, but without a trusted certificate it is back to the 2018 warning page, which most users will not click through. Certificate Transparency adds the after-the-fact half of this: every issued certificate is logged publicly, so a domain owner monitoring the logs sees an unexpected certificate for their name appear and can react, a backstop covered in Certificate Transparency.

What the three heists actually proved

The cryptocurrency angle is almost incidental. Crypto made these attacks worth the effort, because the payoff is liquid, irreversible, and sitting behind a web frontend, and that economic profile is what turned a long-theorized weakness into a thing people actually did for money. But the weakness was general. Any service whose security rests on a TLS connection, which is to say all of them, was exposed to an attacker who could hold a route for an hour and talk a CA into a certificate. The wallets just made the bill legible: $150,000, then $1.9 million, then $235,000, three receipts for the same flaw.

The fix came in two pieces moving at different speeds. Origin validation hardens the routing layer but only as fast as networks deploy it and only as tightly as the ROAs underneath are written, which the more-specific trick keeps probing. Multi-perspective validation hardens the certificate layer and, because it became a mandatory Baseline Requirement in 2025, now applies to every publicly trusted certificate whether or not the domain owner did anything. The interception chain still has a first link an attacker can sometimes forge. It no longer has a reliable second one.

What lingers is the assumption that broke. TLS was built to answer “am I talking to the right server,” and it answers that by trusting that the network delivered me to the right place and that a CA confirmed the same. Both of those trusts route through BGP, and BGP was never built to be trusted. The heists did not break any cryptography. They went under it, to the layer where a router believes whoever spoke last, and for two hours in 2018 the thing that spoke last was a hosting company in Ohio that never meant to say a word.

---

Sources & further reading

• Internet Society (2018), Amazon’s Route 53 BGP Hijack — MANRS analysis of the MyEtherWallet hijack, AS10297, the prefix filtering that would have stopped it.
• ThousandEyes (2018), Anatomy of a BGP Hijack on Amazon’s Route 53 DNS Service — packet-level reconstruction of the 2018 redirection.
• The Register (2018), AWS DNS network hijack turns MyEtherWallet into ThievesEtherWallet — the hijacked /24 list, the Equinix Chicago server, the carriers eNet peered with.
• S2W (2022), Post-Mortem of KlaySwap Incident through BGP Hijacking — timestamps, prefixes, the ZeroSSL certificate, the poisoned kakao.min.js.
• MANRS (2022), KlaySwap: Another BGP Hijack Targeting Crypto Wallets — the more-specific announcement technique and the RPKI angle.
• Birge-Lee, Wang, Mittal, Rexford et al. (2022), Attackers exploit a fundamental flaw in the web’s security to steal $2 million in cryptocurrency — the PKI argument and the multi-vantage-point defense.
• Coinbase / Kacherginsky (2022), Celer Bridge incident analysis — the August 2022 forged-origin hijack, GoGetSSL certificate, RPKI recommendations.
• Kentik (2022), What can be learned from recent BGP hijacks targeting cryptocurrency services? — side-by-side of MyEtherWallet, KlaySwap, and Celer with RPKI status.
• Let’s Encrypt (2020), Multi-Perspective Validation Improves Domain Validation Security — the February 2020 deployment, quorum design, Princeton collaboration.
• CA/Browser Forum (2024), Ballot SC067v3: Require domain validation and CAA checks from multiple Network Perspectives — the MPIC Baseline Requirement and its phased dates.
• Birge-Lee, Sun, Edmundson, Rexford, Mittal (2021), Experiences Deploying Multi-Vantage-Point Domain Validation at Let’s Encrypt — USENIX Security paper on the operational deployment.
• Cloudflare (2025), Helping build a safer internet by measuring BGP RPKI Route Origin Validation — current RPKI ROV coverage and traffic-weighted deployment figures.