How Hackers Hijacked Amazon Route 53 and Stole $152,000 in Ethereum: The MyEtherWallet BGP Attack

Not a Hack. Something More Dangerous.

On the morning of April 24, 2018, Amazon Web Services issued a statement that contained a sentence worth reading carefully:

“The incident did not involve any hack or compromise of systems at either AWS or Amazon Route 53.”

They were right. Nobody broke into AWS. No zero-day was exploited. No credential was stolen from Amazon. The attackers didn’t need any of that.

Instead, they exploited a 30-year-old architectural weakness in the protocol that routes internet traffic. They used it to redirect DNS queries away from Amazon’s legitimate servers to a server they controlled. That server returned fake answers for one specific domain — MyEtherWallet.com — and in two hours, they walked away with 215 Ether worth approximately $152,000.

This is the story of what happened, how it worked technically, and why RPKI is the only real fix.

The Target: Why Route 53?

MyEtherWallet (MEW) is an open-source Ethereum wallet — a web application that lets users store, send, and receive Ethereum. It was one of the most popular crypto interfaces at the time, handling transactions worth millions of dollars daily.

MEW used Amazon Route 53 as its DNS provider. Route 53 is AWS’s managed DNS service — when someone types myetherwallet.com into a browser, their DNS resolver queries Route 53’s authoritative servers, which return the IP address where the site is hosted.

The attackers’ insight was lateral: they didn’t need to compromise MyEtherWallet’s servers, or Route 53’s databases, or AWS’s infrastructure. They just needed to intercept the DNS query itself — answering before the legitimate Route 53 servers could. To do that, they needed to redirect traffic destined for Route 53’s IP addresses to a server they controlled.

For that, they turned to BGP.

The Attack: More-Specific Prefix, Longest Match

Amazon’s Route 53 DNS service operated from several IP blocks, including 205.251.192.0/23. Under normal operation, Amazon (AS16509) announced these prefixes to its upstream providers, and DNS resolvers worldwide sent their queries to those IP addresses.

At 11:05:41 UTC on April 24, 2018, a new BGP announcement appeared in the global routing table.

The announcement originated from eNET (AS10297), a small ISP based in Columbus, Ohio — also known as XLHost. The announcement: 205.251.193.0/24. A more specific prefix than Amazon’s /23, covering a subset of Route 53’s IP space.

eNET had no legitimate claim to 205.251.193.0/24. Amazon owned it. But BGP doesn’t verify ownership — it only propagates announcements. eNET’s announcement was most likely the result of a compromised router or a malicious insider with access to eNET’s BGP configuration.

The critical factor: eNET was connected to Equinix’s Internet Exchange Points in Chicago and Ashburn, VA — dense peering hubs where a single connection reaches thousands of networks. Through eNET, the malicious route reached Hurricane Electric (AS6939), one of the most widely peered transit providers on the internet with over 20,000 BGP sessions globally.

Hurricane Electric accepted the announcement and propagated it to its peers. The malicious /24 spread rapidly. While Amazon’s legitimate /23 continued to be announced, the more-specific /24 won via longest prefix match on every router that received both. Traffic destined for that slice of Route 53’s address space was diverted.

Dyn recorded approximately 15% of their BGP nodes receiving the malicious advertisement. NLNOG-RING observed 15 new BGP paths to the compromised prefix after the attack started — 12 of them coming through Hurricane Electric.

The Infrastructure: A Fake DNS Server in Chicago

The attackers had set up their operation before the BGP announcement was made. Sitting inside the XLHost data center — co-located at the Equinix Chicago IBX — was a server running a custom DNS resolver.

This server was not a general-purpose DNS forwarder. It was selective and surgical. For almost all DNS queries, it returned normal, legitimate answers — forwarding queries to real authoritative servers. This behavior served two purposes: it made the server look legitimate to monitoring tools, and it avoided disrupting other services that might trigger faster detection.

For queries about myetherwallet.com specifically, the server returned a different answer — the IP address of a phishing site hosted on infrastructure in Russia.

The phishing site was a pixel-perfect replica of MyEtherWallet’s interface. Users who landed on it saw exactly what they expected. The only giveaway: the site used a self-signed TLS certificate rather than a certificate issued by a trusted CA. Browsers displayed a security warning.

Many users clicked through it anyway.

What Happened to Victims

Users who visited MyEtherWallet during the attack window and bypassed the certificate warning were presented with the authentic-looking wallet interface. When they entered their private keys or unlocked their wallets, those credentials were captured by the phishing site.

One victim described the experience directly:

“As soon as I logged in, there was a countdown for about 10 seconds and a transfer was made sending the available money I had on the wallet to another wallet. I have no idea what happened. I barely download things and thought I was careful enough at least to avoid problems.”

The attackers’ server automatically initiated Ethereum transfers the moment wallet credentials were captured. Ethereum transactions are irreversible — once confirmed on the blockchain, there is no authority to override them. The stolen Ether was gone.

Over the approximately two-hour attack window, 215 ETH was stolen — worth approximately $152,000 at April 2018 prices.

The attackers’ wallets already contained millions of dollars worth of Ethereum before the attack began, suggesting they were well-resourced and this was not their only operation.

The Timeline

April 24, 2018 — 11:04 UTC: BGP feeders correctly receiving 205.251.192.0/23 from Amazon (AS16509).

11:05:41 UTC: First malicious /24 announcement appears, originating from eNET (AS10297).

11:05–11:10 UTC: Malicious route propagates via Hurricane Electric (AS6939) and TDS Telecom to many BGP peers globally. Traffic for affected Route 53 IPs begins diverting.

~11:00–13:00 UTC: Attack active. MyEtherWallet users querying Route 53 from affected networks receive attacker-controlled DNS responses pointing to phishing site.

~13:00 UTC: Amazon detects and resolves the issue, restoring legitimate routing. DNS caches for myetherwallet.com may have continued serving stale malicious records for some time afterward.

Total theft: 215 ETH / ~$152,000. Collateral impact: brief DNS disruption for other Route 53 customers including Instagram and CNN.

What Contained the Damage

The attack was limited, not because of any active defense by Amazon, but because of inconsistent propagation of the malicious route.

Three major transit providers — Level3 (AS3356), Cogent (AS174), and NTT (AS2914) — were MANRS (Mutually Agreed Norms for Routing Security) members with prefix filters in place. They rejected the malicious announcement from eNET. Traffic from their customers was not affected.

Hurricane Electric (AS6939) did not have adequate filtering and propagated the route to 12 paths worth of peers. This was the primary amplification vector.

The implication is stark: if a few more major transit providers had been running proper prefix filters, the attack’s reach would have been negligible. Conversely, if Level3, Cogent, and NTT had also accepted the route, the scale of theft would have been dramatically larger.

The Two-Layer Attack Chain

What makes this incident particularly instructive is how it chains two protocol weaknesses together:

Layer 1 — BGP has no origin validation. Any AS can announce any prefix, and without RPKI or strict prefix filters, other ASes will accept and propagate it. The attackers used this to redirect traffic destined for Amazon’s DNS servers.

Layer 2 — DNS has no response validation (at this domain). Without DNSSEC deployed on myetherwallet.com, there was no mechanism for resolvers to verify that the DNS response they received actually came from the legitimate authoritative server. The malicious DNS server’s answer for myetherwallet.com was indistinguishable from the real one.

Neither BGP weakness nor DNS weakness alone would have been sufficient. BGP hijacking without DNS control doesn’t let you steal wallet credentials. DNS cache poisoning without BGP reach doesn’t let you intercept traffic from millions of resolvers. Together, they created a complete man-in-the-middle attack.

RPKI breaks layer 1. If Amazon had published ROAs authorizing only AS16509 to announce its Route 53 prefixes, and if eNET’s peers had been enforcing ROV, the malicious /24 from AS10297 would have been classified RPKI-invalid and dropped immediately — before it ever reached Hurricane Electric.

DNSSEC breaks layer 2. If myetherwallet.com had been DNSSEC-signed, the malicious DNS responses from the attacker’s server would have failed cryptographic validation. Resolvers enforcing DNSSEC would have returned SERVFAIL rather than the attacker’s phishing IP.

Neither protection was in place. Both were available.

The Certificate Warning: The Last Line of Defense That Failed

The only technical signal that something was wrong was the browser’s TLS certificate warning. The phishing site had a self-signed certificate — not one issued by a trusted CA for myetherwallet.com. Every major browser displayed a warning before proceeding.

Users clicked through it.

This is the most uncomfortable lesson of the incident: at the final moment, when every technical defense had failed and only a human judgment call stood between victims and loss, users made the wrong call. The warning looked like an IT nuisance rather than an active attack signal.

Modern browser UX has improved significantly since 2018, making it harder to bypass certificate warnings. HSTS (HTTP Strict Transport Security) would have prevented bypass entirely — a browser with the myetherwallet.com HSTS header cached would have refused to connect to a site with an invalid certificate, full stop, with no option to click through.

What AWS, MyEtherWallet, and the Industry Did After

AWS: Added enhanced BGP monitoring for Route 53’s IP space. Amazon has since become one of the larger publishers of RPKI ROAs among cloud providers, covering its DNS and cloud infrastructure address space.

MyEtherWallet: Published extensive documentation explaining the attack. Added repeated warnings in their UI about self-signed certificate warnings and what they mean. The incident accelerated the crypto industry’s awareness of BGP-level attack surfaces.

Internet Society / MANRS: The attack occurred one day after MANRS announced its initiative for internet exchange points. It became an immediate case study for the program’s value, demonstrating exactly what happens when IXP participants don’t enforce routing security.

The broader industry: The incident, alongside others, accelerated enterprise adoption of RPKI. AWS, Google, Cloudflare, and major carriers have since published comprehensive ROA coverage. RPKI validation rates at major IXPs have climbed significantly since 2018.

Lessons for Network and Security Teams

Publish ROAs for every prefix you announce. Amazon’s Route 53 prefixes should have had ROAs on the day Route 53 launched. They did not. Every network operator with announced IP space should publish ROAs — it takes minutes and protects your users from exactly this class of attack.

Enforce ROV on your BGP sessions. Publishing ROAs protects your prefixes from being hijacked. Enforcing ROV protects your customers from routes hijacked by others. Both are necessary.

Deploy DNSSEC on high-value domains. A cryptocurrency wallet handling millions in daily transactions is exactly the kind of high-value domain that justifies the operational overhead of DNSSEC. The attack chain required both BGP and DNS weaknesses to succeed — either mitigation would have broken it.

Enable HSTS on web applications. HSTS with a long max-age and includeSubDomains prevents browsers from connecting to sites with invalid certificates, even if a user tries to click through a warning. It’s a defense-in-depth layer that costs nothing to deploy.

Treat infrastructure protocols as attack surfaces. BGP and DNS are not just network plumbing — they are attack surfaces. Security teams that focus exclusively on application-layer vulnerabilities miss the class of attacks that target the infrastructure layer beneath the application. The systems routing traffic to your application and resolving its name are part of your attack surface.

The Route 53/MyEtherWallet incident is a reminder that the internet’s foundational protocols were built for a cooperative environment, and we are operating them in an adversarial one. The mitigations exist. Deploying them is a choice.