BGP Hijacking Explained: How Whole Countries Lose the Internet

BGP in one paragraph

The internet is not a single network; it is roughly 75,000 networks that have agreed to forward each other's traffic. Each network has a unique autonomous system number (ASN) and runs BGP — the Border Gateway Protocol — with its neighbours to advertise which IP prefixes it can reach. Every BGP message says: “I, ASX, can reach 192.0.2.0/24, and the AS-path to get there is X → Y → Z.” Routers prefer shorter, more-specific, and locally preferred paths. There is no built-in authentication — every neighbour's claim is accepted unless an operator has explicitly filtered it.

Almost every BGP incident in the past two decades is a variation on the same theme: someone announced something they should not have, or accepted something they should not have, and the rest of the internet quietly believed it for as long as the announcement persisted.

The three flavours of getting it wrong

1. Origin hijack

The simplest case: an AS announces a prefix it does not own, claiming itself as the origin. Traffic destined for that prefix gets pulled towards the hijacker. The MyEtherWallet incident in April 2018 was a textbook origin hijack of 205.251.192.0/24 (Amazon's Route 53), redirecting DNS lookups for a single high-value domain to a phishing site for two hours.

2. Sub-prefix hijack

Routers prefer more-specific announcements over less-specific covering ones. If Google announces 8.8.8.0/24 globally and an attacker announces 8.8.8.0/25 from a small network, anyone who accepts that announcement sends the first half of Google's prefix to the attacker. This is what Pakistan Telecom accidentally did to YouTube's /22 in February 2008 with a /24 it intended to keep domestic.

3. Route leak

A leak does not change the origin AS — it changes the path. ASX learns a route from a peer it should keep to itself, then re-announces it to its own transit. Now ASX ends up in the middle of paths it has no business being in, and traffic detours through a small network that probably cannot handle the volume. The November 2018 MainOne → China Telecom incident pulled 74 Google prefixes through Lagos and Beijing for over an hour.

The widget below lets you flip between the “before” and “after” AS-paths for each of those incidents. The hostile hop is highlighted in red; everything else is the same chain of carriers that move your packets every day.

What we have built to make this harder

Prefix filtering and IRR

The oldest defense: an upstream carrier maintains a list of which prefixes a customer is allowed to announce, and drops everything else. The list typically comes from an Internet Routing Registry like RIPE-RR, RADb, or APNIC-RR. It works, but it depends on the upstream having accurate filters — and many small carriers historically do not.

RPKI and Route Origin Authorisations

The Resource Public Key Infrastructure is a cryptographically signed mapping from IP prefix to authorised origin AS. The prefix holder publishes a Route Origin Authorisation (ROA) at their RIR. Carriers configure their routers to do Route Origin Validation (ROV) and drop announcements that are RPKI-invalid. By 2024 ROV is enabled on every major Tier-1 backbone and a clear majority of mid-tier networks; most origin hijacks now stop at the first transit hop.

Mutually Agreed Norms for Routing Security (MANRS)

MANRS is a soft-power initiative that gets operators to commit publicly to filtering, anti-spoofing on customer edges, global validation, and contact information in PeeringDB. It is the closest thing the routing community has to a code of practice; a meaningful number of incidents are now caught because a MANRS participant filtered an announcement an non-participant accepted.

BGPsec and ASPA — the still-deploying future

RPKI authenticates the origin; it does not say anything about the rest of the AS-path. BGPsec adds signatures over the whole path so that route leaks become detectable. ASPA (AS Provider Authorisation) is a lighter alternative: each AS publishes which providers it pays for transit, and routers reject announcements that violate the customer-cone shape implied by those relationships. Deployment is still early, but both should make leak scenarios like MainOne's much harder.

What end-users can do

Honestly: not much directly. BGP lives well above the layer where applications get to make choices. But the things you can do are worth doing:

• Pin certificates and use SRI. A BGP hijack of a CDN that loads JavaScript is only useful if the attacker can also pass HTTPS. Strict transport security plus subresource integrity raise the bar from “own a network for an hour” to “own a private key too”.
• Run validating DNS. Most hijack attacks against end users target DNS, not HTTPS. DNSSEC + DNS-over-HTTPS make that significantly less productive. (We have a separate DNSSEC primer.)
• Watch the routing reports. Cloudflare Radar, BGPStream, and the various academic monitors publish near-real-time incident feeds. If a high-profile site you use suddenly shows up there, treat it like an outage and don't enter credentials until it's clear.