The MyEtherWallet BGP Hijack (2018)

On April 24, 2018, attackers executed one of the most sophisticated BGP hijacks ever observed. By exploiting the trust-based nature of BGP, they redirected traffic destined for Amazon's DNS infrastructure, answered DNS queries for the cryptocurrency wallet service MyEtherWallet.com with the IP of a phishing server in Russia, and stole approximately $152,000 in Ethereum. The attack chained together three distinct exploits — a BGP hijack, a DNS hijack, and a phishing site — into a single coordinated operation that lasted roughly two hours.

The Attack Chain

To understand this incident, you need to see how three layers of internet infrastructure were exploited in sequence. The attackers did not compromise Amazon's servers or MyEtherWallet's code. Instead, they manipulated the routing layer to redirect DNS traffic, then served fraudulent DNS responses to send users to a phishing clone.

Step 1: The BGP Hijack

The attackers originated a BGP hijack from eNet (AS10297), an ISP based in Columbus, Ohio with infrastructure in a Chicago-area data center. At approximately 11:24 UTC on April 24, 2018, a BGP announcement appeared for the prefix 205.251.192.0/24. This prefix is part of Amazon Web Services' IP address space and specifically belongs to Amazon Route 53 — AWS's managed DNS service.

Under normal conditions, the /24 prefix 205.251.192.0/24 is announced by Amazon (AS16509) as part of a larger block. The attackers announced the exact /24 — a more-specific prefix — from AS10297. Because BGP uses longest-prefix-match routing, any network that received both announcements would prefer the attacker's /24 over Amazon's less-specific covering route. This is the fundamental mechanism behind most BGP hijacks: more specific always wins.

The hijacked route propagated through several upstream providers, including Hurricane Electric (AS6939), which has one of the most extensive peering fabrics in the world. From there, the false route spread to a significant fraction of the internet's routing table. Not all networks were affected — those with direct peering to Amazon or those that filtered the announcement were immune — but enough networks accepted the route to make the attack effective.

Step 2: The DNS Hijack

The BGP hijack alone did not directly target MyEtherWallet. What it targeted was Amazon Route 53 — one of the largest authoritative DNS services on the internet. Route 53 serves DNS for hundreds of thousands of domains, including myetherwallet.com.

Once traffic to 205.251.192.0/24 was flowing to the attacker's infrastructure instead of Amazon's, the attackers ran a rogue DNS server on those IP addresses. When recursive resolvers queried for myetherwallet.com, the rogue server responded with the IP address of a phishing server located in Russia, rather than MyEtherWallet's real server. This is what makes the attack so insidious: the attackers did not need to compromise MyEtherWallet's DNS registrar, hack Amazon's infrastructure, or exploit any software vulnerability. They simply convinced the internet to send Route 53 traffic to them, and then answered DNS queries with lies.

It is important to understand why this worked. DNS operates on the assumption that the server at the IP address it reaches is legitimate. When a recursive resolver sent a DNS query to what it believed was an Amazon Route 53 nameserver at 205.251.192.x, it had no way to know the packets had been BGP-hijacked to a completely different machine. The resolver accepted the fraudulent answer because the IP address matched what the .com TLD servers had indicated as authoritative for myetherwallet.com.

Not every DNS query for myetherwallet.com was intercepted. Many recursive resolvers had cached the legitimate answer from before the hijack, and the hijacked route did not propagate to every network on the internet. But enough resolvers were affected to direct a meaningful number of users to the phishing site.

Step 3: The Phishing Site and Cryptocurrency Theft

Users whose DNS was poisoned by the rogue server were directed to a clone of MyEtherWallet hosted on a server in Russia. The phishing site looked identical to the real MyEtherWallet interface — but there was one critical giveaway: the phishing site used a self-signed TLS certificate rather than a certificate issued by a trusted Certificate Authority.

Modern browsers display a prominent warning when encountering a self-signed certificate. Users would have seen a full-page warning stating that the connection was not secure, with language like "Your connection is not private" or "This certificate is not trusted." To reach the phishing site, users had to actively click through this warning and accept the untrusted certificate.

Despite the warning, enough users clicked through. The phishing site captured private keys and seed phrases entered by users who believed they were accessing their legitimate wallets. The attackers used these credentials to drain approximately $152,000 worth of Ethereum from victims' wallets. The stolen ETH was sent to an address that was quickly identified by the cryptocurrency community, but the decentralized and pseudonymous nature of Ethereum meant the funds could not be recovered.

Why This Attack Worked

Several factors converged to make this attack possible:

BGP's Trust Model

The Border Gateway Protocol was designed in an era when the internet was a small network of cooperating academic and government institutions. BGP has no built-in mechanism to verify that a network is authorized to announce a given prefix. Any autonomous system that can establish a BGP session with an upstream provider can announce any prefix it wants. The upstream may or may not filter the announcement. In this case, eNet's upstream providers accepted the hijacked route and propagated it to the global routing table.

The More-Specific Prefix Advantage

Amazon announces Route 53 address space in aggregate blocks. The attackers announced a /24, which is the most specific prefix that most networks will accept in the global routing table (prefixes longer than /24 are typically filtered). By matching this threshold exactly, the attackers ensured their announcement would be accepted and preferred over Amazon's less-specific covering route by every router that received both.

DNS Has No Route Verification

When a recursive resolver contacts an authoritative nameserver, it validates the response based on the question/answer matching and basic protocol checks — not on whether the server it reached is actually operated by the rightful owner of the zone. DNSSEC was designed to address this by adding cryptographic signatures to DNS responses, but myetherwallet.com did not have DNSSEC deployed at the time. Even if it had, many recursive resolvers do not validate DNSSEC signatures, so it would have provided only partial protection.

Users Ignored TLS Warnings

The last line of defense was TLS certificate validation. The attackers could not obtain a valid TLS certificate for myetherwallet.com from any trusted CA (Certificate Authorities verify domain control before issuance). They served a self-signed certificate instead, which triggered browser warnings. But users conditioned to click through warnings — or who did not understand the significance — proceeded to the phishing site. This highlights how critical it is that users treat TLS warnings as genuine red flags, not routine nuisances.

The Technical Details

The Hijacked Prefix

The prefix 205.251.192.0/24 is part of the 205.251.192.0/21 block allocated to Amazon for Route 53. You can look up the current routing for this prefix to see it properly originated by Amazon:

• 205.251.192.0 — Route 53 nameserver prefix (currently Amazon)
• AS16509 — Amazon's autonomous system

During the attack, BGP monitoring systems observed the same /24 being originated by AS10297 (eNet), creating a classic origin conflict. The AS path for the hijacked route was short — just eNet and its immediate upstreams — making it competitive with Amazon's legitimate route in terms of path length.

The Timeline

The attack was compact and deliberate:

• ~11:24 UTC — The hijacked BGP announcement for 205.251.192.0/24 appears from AS10297
• 11:24 – ~13:24 UTC — Affected recursive resolvers receive poisoned DNS responses for myetherwallet.com, directing users to the phishing server in Russia
• ~13:24 UTC — The hijacked route is withdrawn; BGP returns to normal
• Post-withdrawal — Poisoned DNS cache entries continue directing some users to the phishing site until their TTL expires

The total active hijack period was approximately two hours, but the DNS cache poisoning effect lingered. Any resolver that cached the fraudulent DNS response during the hijack window would continue sending users to the phishing site until the cache entry expired — potentially minutes to hours later, depending on the TTL value the attackers set in their fraudulent DNS responses.

The eNet Connection

The role of eNet (AS10297) in the attack remains a subject of investigation. Equinix, which had acquired eNet's parent company, stated that the compromise appeared to involve a customer of eNet rather than eNet's own infrastructure. This is plausible: in many colocation and ISP environments, a customer with access to a BGP session (or who compromises one) can inject arbitrary route announcements. This is why prefix filtering — where an ISP only accepts route announcements from a customer for prefixes the customer is authorized to announce — is a critical security practice that was not adequately enforced in this case.

Defenses That Could Have Prevented the Attack

Each layer of the attack chain had a corresponding defense that was either not deployed or not effective enough:

RPKI and Route Origin Validation

RPKI (Resource Public Key Infrastructure) allows IP address holders to cryptographically assert which autonomous systems are authorized to originate their prefixes. If Amazon had published a Route Origin Authorization (ROA) for 205.251.192.0/24 specifying AS16509 as the only authorized origin, and if eNet's upstream providers performed Route Origin Validation (ROV), the hijacked announcement from AS10297 would have been flagged as RPKI invalid and dropped.

In April 2018, RPKI deployment was still in its early stages. Amazon had not yet published ROAs for all of its prefixes, and most networks were not performing ROV. Since then, RPKI adoption has accelerated dramatically. Today, Amazon's Route 53 prefixes are covered by ROAs, and major transit providers like Lumen (AS3356), NTT (AS2914), and Arelion (AS1299) reject RPKI-invalid routes.

Prefix Filtering (BCP 38/84)

ISPs are supposed to filter the BGP announcements they accept from their customers, only allowing prefixes the customer is authorized to announce. If eNet (or its upstream) had enforced strict prefix filtering on the session that originated the hijack, the false announcement would never have entered the global routing table. Best Current Practice documents BCP 38 and BCP 84 describe these filtering requirements, but enforcement remains inconsistent across the industry.

DNSSEC

If myetherwallet.com had deployed DNSSEC, the fraudulent DNS responses from the attacker's rogue server would have lacked valid cryptographic signatures. DNSSEC-validating resolvers would have rejected the unsigned or incorrectly signed responses and returned an error instead of the phishing IP. However, DNSSEC deployment remains limited — many domains do not sign their zones, and many resolvers do not validate — so this defense was not in place.

HSTS and Certificate Transparency

HTTP Strict Transport Security (HSTS) preloading would have made it impossible for users to click through the TLS warning in Chrome and Firefox. If myetherwallet.com had been on the HSTS preload list, browsers would have hard-failed on the self-signed certificate with no override option. Certificate Transparency logs also help detect misissued certificates, but they would not have caught a self-signed certificate since those are not submitted to CT logs.

Aftermath and Industry Impact

The MyEtherWallet hijack was a watershed moment for internet routing security. It was the first widely publicized BGP hijack used for cryptocurrency theft and demonstrated that BGP vulnerabilities could be weaponized for direct financial gain, not just surveillance or denial of service.

Several consequences followed:

• Accelerated RPKI adoption — Amazon and other major cloud providers fast-tracked ROA publication for their IP space. The incident became a canonical example cited in RPKI deployment advocacy.
• Increased BGP monitoring — Organizations invested in route monitoring services that alert on anomalous origin changes. BGP monitoring tools like RIPE RIS, BGPStream, and commercial platforms saw increased usage.
• Cryptocurrency security awareness — The incident highlighted that cryptocurrency theft does not require blockchain vulnerabilities. Attacking the infrastructure layers beneath the application — DNS, BGP, TLS — can be equally effective.
• ISP filtering pressure — The Mutually Agreed Norms for Routing Security (MANRS) initiative, which advocates for prefix filtering and RPKI deployment, gained new members and visibility after the incident.

Lessons for Today

Six years after this attack, the internet is better defended but not immune. RPKI coverage has grown substantially — over 40% of global prefixes now have valid ROAs — but gaps remain. BGP hijacks still occur, though they are more likely to be detected quickly thanks to improved monitoring.

The MyEtherWallet incident teaches several durable lessons:

• Defense in depth matters. No single layer of security is sufficient. BGP security (RPKI), DNS security (DNSSEC), transport security (TLS/HSTS), and user awareness all play a role. The attack succeeded because none of these defenses were fully in place.
• BGP is a supply-chain vulnerability. Even if your application and servers are perfectly secure, an attacker can redirect your users at the routing layer. Cloud providers, DNS operators, and website owners should all ensure their IP prefixes are covered by RPKI ROAs.
• Certificate warnings exist for a reason. The self-signed certificate warning was the last chance to stop the attack. Users who heeded the warning were not affected. Understanding how TLS works and why certificate validation matters is essential for anyone transacting online.
• Short-lived hijacks are hard to stop. The attack lasted only two hours — fast enough that manual intervention was impractical. Automated defenses like RPKI ROV are the only realistic way to stop hijacks in real time.

Explore the Infrastructure Involved

You can use the looking glass to examine the networks and IP space involved in this incident as they appear today:

• 205.251.192.0 — The hijacked Route 53 prefix
• AS16509 — Amazon Web Services
• AS10297 — eNet (the AS used for the hijack)
• AS6939 — Hurricane Electric (propagated the hijacked route)
• myetherwallet.com — Resolve and see current routing

To learn more about the technologies involved, see our articles on BGP hijacking, RPKI, DNS, and how BGP works.