Summary

  • The April 2018 attack assembled temporary power across five separate layers: a more-specific BGP route, selective route propagation, recursive DNS, a false authoritative answer and a phishing interaction behind an invalid TLS certificate.
  • The strategic lesson is not to find one sovereign control for “DNS security.” It is to give every layer an accountable owner, preserve its local veto and join its telemetry quickly enough to stop a cross-layer attack before the final action becomes irreversible.

The resolver was the hidden bridge

The user did not have to see a suspicious route. The user's Internet provider did not even have to accept one. A recursive resolver somewhere else could accept the route, reach an impostor authoritative server and cache the answer. The user would then receive a false address through a service that still appeared to be performing an ordinary lookup.

That indirection is the most important fact in the MyEtherWallet incident. It explains why a route announcement concerning Amazon address space could become a targeted phishing event for one Ethereum service. It also explains why the blast radius did not follow national borders, customer contracts or a single provider map.

On 24 April 2018, Cloudflare's BGP collectors observed more-specific /24 announcements inside four Amazon /23 ranges. The observations began at about 11:05 UTC and continued until roughly 12:55. The address space belonged to Amazon AS16509 and served Route 53 authoritative DNS. The observed origin was eNet AS10297, and one visible propagation path included Hurricane Electric AS6939.

Those facts describe routing state. They do not establish who operated the attacker, who controlled the announcing equipment or whether eNet itself intended the announcement. Cloudflare wrote that one of eNet's customers could have been responsible. Any account that collapses “origin AS” into “identified perpetrator” goes beyond the public evidence.

The route was useful to the attacker because it was more specific than Amazon's ordinary announcements. Longest-prefix matching meant that networks accepting the /24 routes could send traffic for the selected Route 53 addresses toward the new origin even if the less-specific legitimate route remained visible. There was no need to erase Amazon from the global table.

The recursive resolver turned that partial routing success into a service delivered to others. Cloudflare reported that its 1.1.1.1 resolver was affected at selected locations including Chicago, Sydney, Melbourne, Perth, Brisbane, Cebu, Bangkok, Auckland, Muscat, Djibouti and Manila, while other locations continued normally. A customer using an affected resolver could inherit the false answer even if the customer's own route to Amazon was untouched.

The attack therefore crossed an organisational boundary that many dependency maps omit. A recursive DNS service is not merely an application convenience. Its routing exposure, cache and validation policy can become part of every client's security state.

A selective authority, not a replacement Internet

The impostor servers did not convincingly reproduce Route 53 as a whole. Cloudflare observed that they answered for myetherwallet.com while other queries failed. That selectivity reduced noise and concentrated the value of a brief routing window on one target.

It also revealed the limit of the attacker's authority. The route produced reachability to a server. It did not grant control of Amazon's account systems, the Route 53 control plane, the domain registration or the MyEtherWallet codebase. The impostor still needed to answer the right name, direct the browser to a phishing host and elicit a wallet interaction.

The distinction is more than terminology. Incident reports that say “Amazon DNS was hacked” can lead buyers to demand controls from the wrong owner. There is no public evidence that an attacker authenticated to an AWS console or changed the hosted zone. The control-plane record could remain correct while packets intended for authoritative servers travelled elsewhere.

Nor did a false DNS answer finish the job. Cloudflare reported that the phishing site presented a self-signed certificate. The name on the certificate was relevant, but the issuer was not trusted. A standards-conforming browser could therefore stop the chain and warn the user.

The public accounts say that losses occurred where people crossed that warning and interacted with the impostor. MyEtherWallet later estimated that approximately USD 150,000 worth of Ether was taken. That figure should remain attributed to the affected service; the reviewed record does not provide an independent audit of every transaction or victim.

The attack succeeded only in the subset where several conditions overlapped: a route was announced, upstreams propagated it, a resolver's network selected it, the impostor supplied the targeted answer, a user reached that resolver and the final certificate warning was bypassed. Each condition narrowed the attack. Together they produced irreversible transfers.

Five decisions created one apparent fact

The first decision belonged to route propagation. An originating network or customer announced the more-specifics. Transit and peer networks then decided whether to export them. Cloudflare noted that some other eNet transits did not appear to carry the routes, possibly because of filtering or direct commercial knowledge of Amazon. The same announcement therefore acquired different operational force on different paths.

The second decision belonged to receiving networks. BGP did not deliver a legal finding about ownership. It delivered path information that local import policy could accept, reject or prefer. Longest-prefix selection then made the accepted route attractive.

The third decision belonged to recursive resolution. A resolver selected the authoritative endpoint its routing table could reach, accepted the response under the DNS security state available to it and exposed that answer to clients. Without authenticated DNS data, the resolver could not distinguish a response from the intended Route 53 server from a syntactically valid response delivered by the reached impostor.

The fourth decision belonged to TLS. The browser evaluated the presented certificate against its trust store and name rules. In the observed case, it produced a warning rather than silently treating the connection as authenticated.

The fifth decision belonged to the application interaction. The false page needed useful input or approval. Client-side wallet architecture did not make the web interface irrelevant; it made the user's interaction with that interface the point at which a temporary network illusion could become an on-chain consequence.

These decisions were dependent but not merged. A route was not a DNS record. A DNS record was not a certificate. A certificate was not transaction intent. A wallet transaction was not proof that the preceding infrastructure had been legitimate.

The incident appeared to the victim as one false fact: “this is MyEtherWallet.” Operationally, that fact was assembled by several systems that had answered narrower questions.

What RPKI would have changed

RFC 6811 defines route-origin validation as a classification of a BGP route against validated prefix-to-origin assertions. It does not make the result a universal command. A relying network chooses how to use Valid, Invalid and NotFound state.

The 2018 more-specifics were attractive because ordinary BGP selection rewarded specificity. RFC 6811 supplies a separate origin-validation decision: where a receiving network validates a correctly bounded ROA and rejects Invalid announcements, a different-origin more-specific like the one observed in April 2018 can be stopped before it influences a resolver.

That is a material control, not a complete historical eraser. ROV adoption remains a local network decision. It validates origin authorisation, not the full AS path. A determined attacker may attempt to forge an authorised origin in the path, and same-origin conflicts require other signals. The protection also depends on the prefix and maximum-length design of the ROA.

The right conclusion is bounded. RPKI can make this exact class of different-origin more-specific attack harder to propagate through participating networks. It cannot authenticate a DNS answer, enforce a browser certificate decision or prove that a wallet transfer expresses the user's intent.

DNSSEC answers another narrow question

RFC 4033 gives DNSSEC a precise purpose: data-origin authentication and integrity for DNS data. A validating resolver with a complete chain of trust can distinguish a signed answer from unauthenticated data delivered by an impostor. RFC 9364 now states that DNSSEC is the best current practice for adding origin authentication to DNS data.

That precision matters. DNSSEC would not prevent a BGP announcement. It would let a validating resolver reject a false answer that lacked the zone's valid signature. It protects the data, not the path used to fetch it.

AWS announced public hosted-zone DNSSEC signing and Route 53 Resolver validation in December 2020. That dated capability is relevant to current design. It does not prove what myetherwallet.com had configured in 2018, nor does it assign the whole incident to one platform feature that did not yet exist in the same form.

Deployment also creates its own custody surface. Zone-signing keys, delegation-signer records, rollover timing and resolver validation can fail. DNSSEC converts an unauthenticated ambiguity into a verifiable state, but it can also turn a broken chain into unreachability. Leadership must therefore ask who owns key operations, monitoring and rollback rather than treating an enabled checkbox as finished assurance.

The response checklist mixed different mechanisms

MyEtherWallet's June 2018 response announced a move to Cloudflare and described registrar lock, registry lock, HSTS, HSTS preloading, CAA, DNSSEC, CDN and denial-of-service protection. The list was broad because the service was responding to a frightening compound event.

The list should not be read as eight names for one defence. Registrar and registry locks constrain unauthorised domain-account or nameserver changes. The public evidence does not say such a change caused this incident. CAA tells certificate authorities which issuers are authorised for a domain; it does not invalidate a self-signed certificate in a browser that already rejects the issuer.

HSTS and especially browser preload address the last visible veto. A preloaded domain cannot rely on a user to interpret and resist a certificate warning; the browser refuses the unsafe path. DNSSEC addresses the authenticity of DNS data at validating resolvers. ROAs and ROV address origin claims in BGP. Monitoring joins the evidence so response begins before a wallet action.

Every control is valuable when assigned to its mechanism. The danger begins when a long post-incident list is reported upward as “DNS hardened” and no one can say which condition each control stops, who operates it or how its failure is detected.

Running code, not borrowed sovereignty

Heng Lu's Running-Code Primacy is useful here as a discipline. A registry record or platform account can describe an intended state, but operational force arises when independently operated systems accept and execute compatible inputs. The BGP route mattered because networks propagated and selected it. The DNS answer mattered because resolvers accepted and served it. The certificate warning mattered because browsers enforced it.

That account does not romanticise decentralisation. Local decisions can combine into a harmful common outcome. A resolver can inherit a bad path. A user can override a good warning. Distributed actors can all be rational inside their own narrow view and still assemble an attack.

The corrective principle is therefore not “trust no institution” or “centralise every veto.” It is to prevent one layer's evidence from silently becoming another layer's mandate. Route reachability must not be mistaken for name authenticity. Name authenticity must not be mistaken for website safety. Website identity must not be mistaken for transaction intent.

Heng Lu's distinction between technical capability and legal authority sharpens the language. AS10297's observed announcement produced a technical capability to attract traffic on selected paths. It did not create lawful authority over Amazon address space or MyEtherWallet. The Internet's running systems could still act on the capability before any institution resolved legitimacy.

For a leadership team, that gap is where accountability belongs. The question is not which organisation “owned the Internet” for two hours. The question is which local controls could have declined the capability, how quickly owners would see the divergence and which irreversible action remained at the end.

What the record does not settle

The reviewed evidence does not identify the perpetrator. It does not prove that eNet intentionally originated the routes rather than carrying a customer's announcement. It does not enumerate every affected recursive resolver, victim or wallet transaction.

It also does not support a claim of global DNS control. Cloudflare saw clear regional variation, and selective responses for one target indicate that the impostor service was deliberately narrow. Other Route 53 customers experienced failures at affected vantage points, not a faithful malicious reconstruction of every hosted zone.

The record should not be used to make users the sole cause. Crossing the certificate warning was the final avoidable act described by the sources, but the warning appeared only after several infrastructure owners had already accepted and transported hostile state. Blame that begins at the browser hides the upstream decisions that made the deception reachable.

Nor should the event be used to claim that one modern control makes recurrence impossible. RPKI, DNSSEC, HSTS and monitoring each remove or shorten a path. A determined adversary will search for the seams between them.

The durable lesson

The attack borrowed a name without acquiring it. For less than two hours, a route created enough reachability for a selective DNS service to lend an impostor page the appearance of myetherwallet.com. The browser still objected. The final theft required the warning to be crossed.

That chain is a better model for infrastructure security than the language of one hacked provider. Critical services rest on stacked, independently governed proofs. Their resilience depends on whether each proof remains narrow, whether each layer preserves a veto and whether evidence of divergence can travel faster than the attack.

The strongest architecture is not one in which a single institution declares truth. It is one in which a false route cannot authenticate a name, a false name cannot authenticate a certificate and an authenticated session cannot silently authorise an irreversible transfer.

Sources