BGP Hijack Explained: How One Wrong Announcement Reroutes the Internet

BGP hijack, in one answer

A BGP hijack is when one network tells the rest of the internet "send me traffic for these IP addresses" — and those addresses belong to somebody else. Because the internet's routing protocol, BGP (Border Gateway Protocol), was designed in an era when every operator knew every other operator, it has no built-in way to prove that an announcement is true. If nobody's filters catch the lie — or the typo — routers around the world can start delivering real traffic to the wrong network within minutes. Sometimes the traffic is then dropped, causing an outage. Sometimes it is watched, or answered by an impostor, before anyone notices.

Picture the internet as a delivery system where every depot puts up its own road signs. Each sign says "packages for these streets come through me", and every driver trusts the signs because that is the only system there is. A hijack is a depot putting up a sign for streets it does not serve. Drivers do not ring head office to check who really owns the street — they just follow the most specific sign they can see. If the sign points to an empty warehouse, the deliveries pile up and vanish. That, in one image, is almost every BGP incident ever recorded.

Why the internet believes the lie

BGP's job is reachability, not truth. When a router hears two announcements for the same prefix, it runs a best-path contest — local policy first, then things like the shortest AS-path — and picks one winner. Nowhere in that contest is there a step that asks "does this network actually own these addresses?" Ownership records do exist, in the regional address registries and in RPKI (covered below), but checking them is an add-on each operator must choose to build, not a step BGP performs itself.

The second reason hijacks work is subtler, and it is the one that matters most: the more-specific trick never has to win the contest at all. Suppose the real owner announces 208.65.152.0/22, a block of 1,024 addresses. A hijacker announces 208.65.153.0/24 — just the 256-address slice in the middle. Those are two different prefixes, so both are accepted and both sit in the routing table. The choice happens later, packet by packet, at forwarding time: when a packet's destination matches more than one route, the router must use the longest matching prefix — the most specific one. That rule is not a bug; it is how operators legitimately carve blocks up for traffic engineering. But it means a /24 lie beats a /22 truth everywhere both are heard, automatically, before any of BGP's path preferences are even consulted.

There are two other shapes. A same-prefix hijack announces exactly the owner's prefix from the wrong AS; now there is a best-path contest, and the hijack wins only where its path looks better — shorter, or preferred by local policy — so it usually captures some regions rather than the world. And a forged-path announcement dresses the lie up with a plausible-looking AS-path, sometimes even ending in the real owner's AS number, to slip past simple filters that only check the end of the path. All three shapes share the same root cause: an announcement is a claim, and claims were never signed.

The day Pakistan took YouTube offline — by accident

The most famous hijack was not an attack at all, and walking through it shows every moving part. On 24 February 2008, Pakistan's government ordered YouTube blocked inside Pakistan. Pakistan Telecom (AS17557) implemented the block the standard way: it announced a more-specific slice of YouTube's address space, 208.65.153.0/24 — carved out of the 208.65.152.0/22 block YouTube itself announced — and pointed that announcement at a null route, a blackhole, so its own customers' YouTube traffic would be discarded.

The mistake was scope. At about 18:48 UTC the blocking announcement was passed to Pakistan Telecom's upstream provider, PCCW (AS3491), which accepted it and readvertised it to the world. Because the /24 was more specific than YouTube's /22, routers everywhere did exactly what the longest-match rule tells them to do: for the addresses in that slice — which included the addresses YouTube's site actually answered on — the road now led to Pakistan, and into the blackhole. Within minutes YouTube was unreachable for much of the internet, and it stayed that way for roughly two hours, until the bad announcement was withdrawn and YouTube's own counter-announcements of the same /24 restored the real path.

Read the incident again and notice what is not in it: no hacking, no broken encryption, no failure inside YouTube. One operator made a routine local change, one upstream accepted an announcement it should have filtered — a customer has no business announcing YouTube's addresses — and a forwarding rule every router must follow did the rest. That is why the incident is still taught: the ingredients are present in every network, every day.

Hijack, leak, or attack? The three drawers

Operators sort these events into three drawers, because the fix differs. A hijack is a wrong-origin announcement: a network originates a prefix it does not own, deliberately or by misconfiguration — the Pakistan case started life as a deliberate local announcement that became a hijack the moment it escaped. A route leak (RFC 7908) is propagation beyond the intended scope: a network passes routes learned from one provider or peer on to another, accidentally offering itself as a transit path it was never meant to be. On 1 April 2020, for example, Rostelecom (AS12389) announced some 8,870 prefixes belonging to roughly 200 other networks — including major cloud and content providers — for about an hour; analysts widely treated it as an accident involving an internal traffic-optimisation system, and the damage came from how many large networks accepted and spread the announcements. The third drawer is the genuine attack: a hijack run on purpose to intercept or impersonate. In 2018, attackers hijacked prefixes used by Amazon's Route 53 DNS service and pointed people looking up a popular cryptocurrency wallet at a fake site — the routing lie lasted long enough to steal real money, without breaking any encryption.

Encryption deserves one honest paragraph, because it decides how bad a hijack is. TLS means an interceptor who merely forwards your traffic onward usually cannot read it. What a hijack still gives an attacker is availability (they can simply drop everything), metadata (who talks to whom, when, how much), and, in the DNS-style variant above, the chance to answer as an impostor before encryption even starts. "Our traffic is encrypted, so hijacks don't matter" is the first entry in the mistakes list below for a reason.

What actually stops it

RPKI: signed ownership, checked at the door. The Resource Public Key Infrastructure lets a prefix owner publish a signed statement — a ROA — naming the one AS allowed to originate that prefix, and the longest prefix length it may announce. Networks running route-origin validation mark announcements Valid, Invalid or NotFound, and drop the Invalid ones. A correct ROA would have made Pakistan Telecom's /24 announcement Invalid on sight. Our full RPKI guide, linked below, walks through ROAs and validation step by step — and its companion piece covers the maxLength loophole, the setting that can accidentally leave a ROA wide enough for a more-specific hijack to still validate.

Prefix filtering: the unglamorous control that would have prevented 2008. Providers can — and the good ones do — build a per-customer filter list from registry and RPKI data stating exactly which prefixes each customer is allowed to announce, and reject everything else. PCCW accepting a YouTube announcement from Pakistan Telecom is precisely the failure this control exists for. The MANRS initiative (Mutually Agreed Norms for Routing Security) exists to make filtering, validation and coordination the expected baseline rather than the exception.

Monitoring: assume it happens, hear about it first. Public route collectors watch the global table continuously, and services built on them will alert you when your prefix appears with a new origin AS or a new more-specific. That alert is the difference between a two-hour public outage and a ten-minute phone call to your upstream. If you own address space and nobody gets that alert, the standing assumption should be that a hijack will be discovered by your users.

One uncomfortable truth ties the three together: your protection depends heavily on other networks. You can publish perfect ROAs, but they only bite where other operators validate. You can filter perfectly and still receive the whole internet's mistakes. Routing security is a herd-immunity project — which is why each network that validates and filters makes the next hijack smaller for everyone.

If your prefix is hijacked: the first hour

1. Confirm it is routing, not your servers. Check your prefix in a looking glass or route-collector view from several regions: a new origin AS, or a new more-specific you never announced, is the signature. 2. Announce your way back. Announcing the same more-specifics yourself restores longest-match equality, so the contest returns to best-path — which the real owner, with the real connectivity, usually wins in most regions. This is what YouTube did in 2008. 3. Call, don't just email. Your upstream and the network propagating the bad announcement have network operations centres for exactly this; a hijack is one of the few incidents where a phone call to another operator is the fastest technical fix. 4. Keep the evidence. Save the collector snapshots with timestamps — they are how you prove scope and duration afterwards, to management and, in an attack, to law enforcement.

Four mistakes this article prevents

1. Believing encryption makes hijacks harmless. TLS protects content in transit; it does nothing for availability, metadata, or DNS-level impersonation. 2. Publishing a ROA with a loose maxLength "just in case". A maxLength far beyond what you actually announce signs permission for more-specifics you have never used — the exact shape a hijack takes. 3. Filtering only outbound, or only inbound. 2008 needed an outbound filter in Pakistan and an inbound customer filter at its upstream; either one alone would have contained it, and neither existed. 4. Having no routing monitor because "we're too small to hijack". Small prefixes are hijacked for spam runs precisely because nobody is watching them; an alert on a new origin AS costs nothing to set up.