BGP Hijacking: How Internet Routing Gets Manipulated and What's Being Done About It

The internet doesn’t have a central authority that decides how packets get from one place to another. What it has is BGP — the Border Gateway Protocol — a system by which roughly 75,000 independent networks (Autonomous Systems, or ASes) advertise their reachability to each other and collectively build a distributed routing table.

BGP was designed in 1989 for a network where the operators knew each other. The protocol’s trust model reflects that: when an AS announces that it’s the right path for a block of IP addresses, other ASes largely believe it. There’s no built-in cryptographic verification of route origin or path integrity. This is the root cause of BGP hijacking — a class of attack that has taken down YouTube, rerouted traffic through foreign state infrastructure, and enabled cryptocurrency theft at scale.

This article covers how BGP works, how hijacks operate mechanically, the major documented incidents, and the state of the defenses — RPKI, MANRS, and the emerging ASPA standard.

How BGP Works

Each Autonomous System has an ASN (Autonomous System Number) and a set of IP prefixes it’s responsible for. An AS tells its neighbors: “I can reach these prefixes” by sending BGP UPDATE messages. Neighbors incorporate that information, prepend their own ASN to the AS_PATH attribute, and propagate the announcement to their own neighbors. Through this process, routing information spreads across the internet.

When a router receives multiple routes to the same destination, BGP applies a selection process. Two rules dominate most hijack scenarios:

Most specific prefix wins: A route for 8.8.8.0/24 (256 addresses) overrides a route for 8.8.0.0/16 (65,536 addresses) because the /24 is a more specific match. Any router that receives both announcements will prefer the /24 — regardless of who’s announcing it.

Shortest AS path wins: If two announcements cover the same prefix length, the one with fewer ASNs in the path wins. An attacker can prepend fewer ASNs to make their route more attractive.

There’s no standard mechanism that asks “should this AS be announcing this prefix?” before accepting an update. That’s the gap.

Hijack Mechanics

Origin Hijack (Prefix Hijack)

The straightforward case: an attacker announces a prefix they don’t own.

If Google announces 8.8.0.0/16 and an attacker announces 8.8.8.0/24, the attacker’s announcement propagates globally. Any router that receives both will route traffic for 8.8.8.x to the attacker (more specific prefix wins). Traffic for the rest of the /16 still goes to Google.

The attacker can either black-hole the traffic (it arrives and goes nowhere — a denial of service) or forward it onward to the legitimate destination after inspection (a man-in-the-middle).

Sub-prefix Hijack

A refinement: rather than announcing the exact prefix, announce a more-specific sub-prefix. The legitimate owner’s announcement still reaches routers, but traffic for the hijacked sub-prefix gets intercepted. The legitimate owner’s traffic for other parts of their prefix space continues normally, which can delay detection — the service appears degraded rather than completely down.

Path Hijack (Route Leak)

More sophisticated: the attacker doesn’t claim to own the prefix but instead advertises a false AS path that makes their route look shorter or better-connected than the legitimate one. RPKI (which only validates origin ASNs) doesn’t catch this — the announcement’s origin is legitimate, but the path is fabricated.

A route leak is a related but distinct problem: an AS legitimately receives a route from a customer and incorrectly propagates it to peers or providers, making itself appear to be a transit path it isn’t. These are usually accidental but have the same effect as intentional hijacks.

Major Incidents

Pakistan Telecom / YouTube (2008)

Pakistan’s government ordered YouTube to be blocked nationally. Pakistan Telecom implemented this by announcing 208.65.153.0/24 — a sub-prefix of YouTube’s legitimate allocation — pointed at a null interface (black hole). The intention was to drop the traffic domestically.

The problem: Pakistan Telecom’s upstream provider, PCCW Global, failed to filter the announcement and propagated it globally. Because the /24 was more specific than YouTube’s /22, routers worldwide updated their tables. YouTube traffic globally followed the new route — straight into the black hole. The service was unreachable for approximately two hours until the announcement was manually withdrawn.

This incident is the cleanest illustration of the accidental hijack: no malicious intent, wrong configuration, upstream filtering failure, global impact.

Rostelecom (2020)

In April 2020, Rostelecom (Russia’s state telecom) originated routes for over 8,000 prefixes belonging to Akamai, Amazon, Cloudflare, Fastly, and others. The hijacked prefixes covered CDN infrastructure serving a substantial portion of global web traffic.

The incident lasted approximately 60 minutes before it was detected and withdrawn. Whether it was accidental misconfiguration or intentional traffic interception has never been definitively established — BGP doesn’t encode intent, and the distinction is invisible on the wire.

Amazon Route 53 / MyEtherWallet (2018)

This case demonstrates hijacking combined with a specific attack objective. Attackers announced a /24 covering IP addresses belonging to Amazon’s Route 53 DNS service. Traffic directed at Route 53’s authoritative servers was redirected to attacker-controlled infrastructure for approximately two hours.

During that window, DNS queries for myetherwallet.com from affected networks received responses pointing to a phishing server. Users who authenticated on the fake site had their private keys stolen. The attackers withdrew approximately $17 million in cryptocurrency.

The attack is notable because it combined a routing-layer attack with an application-layer objective — DNS poisoning enabled by BGP hijacking. HTTPS should have been a mitigation (the fake site would need a valid certificate for myetherwallet.com), but the attackers obtained a certificate from a CA that didn’t require proof of IP control, only domain control — and they had effectively hijacked the DNS resolution of the domain.

Detection

BGP hijacks are detectable, though the window between announcement and detection varies. Tools and services:

RIPE RIS (Routing Information Service) and Route Views collect BGP announcements from hundreds of collection points globally. These archives allow analysis of when announcements appeared, which ASes propagated them, and where they reached.

BGPmon (now integrated into Cisco) and ARTEMIS (open-source, from FORTH/ICS) provide real-time monitoring for prefixes you specify. You configure the prefixes and legitimate ASNs for your organization, and the tool alerts when unexpected origins appear.

Cloudflare Radar and RIPE Stat provide public tools for investigating historical BGP events and current routing state for any prefix.

For organizations announcing their own prefixes, the monitoring approach:

# Check current routing for your prefix using a route collector
# Using RIPE's looking glass service
curl "https://stat.ripe.net/data/bgp-state/data.json?resource=YOUR.PREFIX/24&rrcs=0,1,5" \
  | python3 -m json.tool | grep -A2 '"path"'

# Check RPKI validity of a prefix/ASN pair
curl "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS15169&prefix=8.8.8.0/24"

Alert on: your prefix announced from an ASN you don’t operate, a sub-prefix of your allocation appearing from an unexpected source, significant change in the AS path to your prefix from monitoring vantage points.

Defenses: RPKI, MANRS, and ASPA

RPKI (Resource Public Key Infrastructure)

RPKI provides origin validation via Route Origin Authorizations (ROAs). A ROA is a cryptographically signed record that states: “ASN X is authorized to announce prefix P with maximum length L.” ROAs are published by Regional Internet Registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC).

Routers configured to do RPKI validation classify received routes as:

Valid: The origin ASN matches a ROA for the prefix
Invalid: A ROA exists but the origin ASN doesn’t match, or the prefix is longer than the ROA’s maxLength
NotFound: No ROA exists for the prefix

An Invalid announcement is typically dropped. NotFound means no RPKI information exists — most routers still accept these (the alternative would be dropping most of the internet, since RPKI coverage is incomplete).

Deployment status: As of 2025, RPKI ROA coverage for the global routing table is approximately 50-55%, and valid-route dropping (Route Origin Validation, ROV) is deployed by a growing number of major networks. Cloudflare, Amazon, AT&T, Comcast, and many European ISPs now drop Invalid routes. The Pakistan Telecom 2008 incident wouldn’t propagate globally today from any network doing ROV — the /24 announcement without a matching ROA would be Invalid.

What RPKI doesn’t solve: Path attacks. A malicious AS that correctly announces a route it does own but advertises a fabricated AS_PATH that makes it appear closer to the destination passes RPKI validation. The origin is legitimate; the path is not.

MANRS (Mutually Agreed Norms for Routing Security)

MANRS is an operational framework rather than a technical standard — a commitment by network operators to implement specific routing hygiene practices:

Filtering: Implement prefix and AS_PATH filters on customer sessions — only accept announcements from customers for prefixes they legitimately own
Anti-spoofing: Implement BCP38/uRPF to prevent IP source address spoofing
Coordination: Maintain accurate routing registry data (in IRR databases) and contact information for rapid response
Global Validation: Implement RPKI ROV

Over 1,000 networks have joined MANRS as of 2025, including most major cloud providers and many ISPs. Networks that filter their customer announcements (item 1) directly prevent the route leak class of incident — if Pakistan Telecom’s upstream had filtered, the 2008 incident wouldn’t have propagated.

Checking whether a network participates: manrs.org/participants

ASPA (Autonomous System Provider Authorization)

ASPA is a newer RPKI extension (IETF draft, moving toward standardization) that addresses the path validation gap RPKI leaves open. An ASPA record states: “AS X uses AS Y as its upstream provider.” With a complete set of ASPA records, route processors can detect and reject routes with fabricated or impossible AS paths — specifically valley-free routing violations (a route that appears to travel down into a customer cone and back up through a different provider).

ASPA addresses the scenario that RPKI misses: an attacker who legitimately announces their own prefix but inserts a false path to appear as a preferred route. Deployment is in early stages as of 2026 but is the most technically promising solution to path-level attacks.

IRR (Internet Routing Registry) Filtering

IRR databases (RADB, RIPE DB, ARIN DB) predate RPKI and remain widely used for filtering. Operators register their routing policies and prefix allocations; peers and upstreams use those records to generate prefix filters.

IRR has weaker security properties than RPKI — records are not cryptographically signed and can be incorrect or outdated. But for networks that haven’t deployed RPKI yet, IRR-based filtering provides a meaningful baseline and is operationally mature.

What Network Operators Can Do Today

Publish ROAs for your prefixes. This is the highest-leverage action. ROA creation takes minutes through your RIR’s portal and enables networks doing ROV to reject hijacks of your prefix. If you announce 203.0.113.0/24 from AS64496, publish a ROA for that combination.

Enable ROV on your routers. Drop Invalid routes received from peers and upstreams. This protects your customers from being affected by hijacks elsewhere, and contributes to the ecosystem of networks doing validation.

Filter customer announcements. Only accept BGP announcements from customers for prefixes they own. Use IRR records or RPKI ROAs to build these filters. This is the control that would have stopped Pakistan Telecom’s announcement from propagating globally.

Monitor your prefix space. Set up alerts via ARTEMIS, BGPmon, or RIPE Stat for unexpected route origins. A hijack that’s detected in minutes has far less impact than one discovered hours later.

Join MANRS. The commitment formalizes operational practices that should be standard and provides the routing security community with accurate contact points for incident coordination.

The honest state of BGP security in 2026: RPKI has made meaningful progress against the simplest hijacks, and the percentage of the routing table covered by ROAs and subject to ROV continues to grow. The Pakistan Telecom class of incident — accidental, easily detectable, affecting a well-known service — is significantly harder to execute globally now than it was in 2008. Sophisticated path-level attacks and deliberate state-level interception remain largely unaddressed by deployed tooling. ASPA is the most credible technical path toward fixing path validation, but deployment is years away from providing meaningful coverage.

The routing system’s security model is gradually improving — but the pace is constrained by the coordination problem inherent in securing a decentralized system where every participant has to independently choose to implement controls.