BGP Security: Route Hijacking and How to Detect It

On February 24, 2008, Pakistan Telecom announced more-specific prefixes for YouTube's IP space to enforce a domestic censorship order. One upstream provider — PCCW Global — propagated the announcement globally. For two hours, YouTube traffic worldwide went to Pakistan, and nobody had to break a single system to do it.

That is BGP in one incident: a 35-year-old trust model operating exactly as designed, doing exactly the wrong thing.

BGP Trusts Every Announcement by Design

BGP-4 (RFC 4271, 1995) contains no mechanism to verify that an autonomous system actually owns the prefix it announces. When Pakistan Telecom's AS17557 said "I own 208.65.153.0/24," every router that received the announcement believed it. RFC 4272, the IETF's own vulnerability analysis of BGP, states directly: there are no mechanisms internal to BGP that protect against modified, forged, or replayed data.

The more-specific prefix rule makes this worse. A /25 announcement beats a /24 unconditionally — it will always be preferred by BGP's longest-prefix-match logic. An attacker announcing two /25s covering a victim's /24 captures all traffic destined for that prefix, even while the legitimate /24 route remains in the table. The victim's prefix doesn't disappear; it just loses to the more-specific announcement in every routing decision.

Tens of thousands of autonomous systems exchange routes through BGP with no bilateral trust verification at peering handshakes. This is not a misconfiguration. It's the architecture.

Three Hijack Techniques, One Root Cause

Origin hijack is the most visible attack type: an attacker announces a victim's prefix from the wrong AS. All traffic diverts to the attacker's network. It's relatively easy to detect because the origin AS in the announcement doesn't match the legitimate one.

Sub-prefix hijack is harder to catch. By announcing a more-specific prefix (a /25 against a victim's /24), the attacker attracts traffic without removing the legitimate route from the table. This matters because RPKI — the current primary defense — validates origin ASes against registered Route Origin Authorizations, but only for the exact prefixes in those ROAs. A sub-prefix that isn't covered by a ROA propagates without RPKI being able to validate or invalidate it.

AS path manipulation changes the topology of the path rather than the origin, enabling man-in-the-middle positioning without full traffic diversion. Route leaks — where a misconfigured AS re-advertises transit routes to peers — produce mechanically identical disruption to deliberate attacks. The 2010 China Telecom incident, where AS4134 originated 15% of global internet routes for 18 minutes (including US government and military prefixes), was a route leak. Intent doesn't change the impact.

The Incident Record Is Long and Ongoing

The incidents are not historical curiosities. They trace a pattern of capability being repeatedly exercised against production infrastructure.

The Pakistan/YouTube incident in 2008 stands as the textbook case, but China Telecom in 2010 affected a larger slice of global routing. In April 2018, eNET (AS10297) hijacked Amazon Route 53 DNS IP space for approximately two hours. Attackers redirected MyEtherWallet users to a Russian phishing server, exploiting the BGP-redirected DNS to serve a lookalike site. Victims who ignored the self-signed TLS certificate warning lost $150,000 in ETH. The attack required no vulnerability in AWS, no vulnerability in Ethereum — just the ability to announce an IP prefix and wait for traffic.

Rostelecom in 2020 briefly hijacked Akamai and Cloudflare CDN prefixes, creating an ISP-scale interception window. The KLAYswap cryptocurrency service was targeted via BGP attack in 2022. The pattern holds: BGP hijacking is a reliable technique for traffic interception at scale, available to any AS operator willing to misuse their routing authority.

RPKI Solves Origin, Not Path — and 33% of Routes Are Still Uncovered

RPKI is the most significant defense deployed against BGP hijacking. It works by cryptographically binding prefix ownership to AS numbers through Route Origin Authorizations signed by the Regional Internet Registries. Routers enforcing Route Origin Validation (ROV) drop routes with invalid origin ASes.

The deployment numbers as of mid-2026: 67.43% of announced prefixes have ROA coverage, and 70.3% of internet traffic traverses RPKI-valid paths. Zayo, one of the last major Tier-1 holdouts, began dropping RPKI-invalid routes in 2024. Progress is real.

What RPKI does not solve is also real. BGPsec — the path-validation extension that would authenticate the AS path, not just the origin — remains essentially undeployed due to performance overhead and operational complexity. ASPA (Autonomous System Provider Authorization), the more tractable replacement, covers only 2.54% of ASNs as of mid-2026. Only 12.3% of ASes are fully ROV-enforcing per RoVista; most filter partially. The 2024 research result is damning: all four tested tier-1 networks were vulnerable to stealthy sub-prefix hijacks that evaded public BGP monitors even with ROV enabled.

RPKI at current deployment covers the easy case — origin hijacks of ROA-covered prefixes propagated through ROV-enforcing providers. The hard cases remain open.

Detection Is the Defense That Works Today

While RPKI inches toward comprehensive coverage, real-time BGP monitoring catches what RPKI misses — sub-prefix attacks, AS path manipulation, and hijacks transiting non-ROV providers.

The public BGP collector infrastructure provides the raw material. RouteViews (University of Oregon) aggregates feeds from approximately 200 ASes with historical and live data. RIPE RIS operates 25+ collectors with a WebSocket-based live stream (RIS Live) delivering near-real-time BGP updates. BGPStream, from CAIDA, provides a prefix-filter API over these data sources.

ARTEMIS — originally developed by FORTH and CAIDA, now maintained by Code BGP — is the practical entry point for operator deployment. Self-hostable, open-source, configured with your ASN and prefixes, it detects origin hijacks within approximately one minute by watching for your prefixes announced from unauthorized origin ASes. The detection gap worth naming: BGP monitoring is control-plane only. Seeing that an announcement was made doesn't confirm traffic actually diverted — data-plane verification requires traceroute probing or a distributed probe network.

The anomaly signals to watch for: unexpected origin AS for a monitored prefix; unexpected sub-prefix announcement (a /25 appearing when you only announce /24s); AS path length changes that could indicate path manipulation; announcements from geographic regions where your upstreams don't peer. Any of these warrants immediate investigation, not just logging.

What Practitioners Can Do This Week

Three actions cover the majority of exposure and guarantee rapid detection if something happens anyway.

Publish ROAs in your RIR (ARIN, RIPE, APNIC, LACNIC, or AFRINIC) for every prefix you originate. Set maxLength to the most-specific prefix you actually announce — a maxLength equal to your prefix length prevents sub-prefix hijacking via RPKI for covered prefixes at ROV-enforcing providers. Register IRR objects in parallel (RIPE db, ARIN IRR, or RADB); many providers filter based on IRR independently of RPKI.

Configure prefix monitoring. BGPStream's API or a self-hosted ARTEMIS instance, configured with your ASN and full prefix list, will alert on any announcement from an unexpected origin. The setup time is hours, not days.

Verify your upstream providers enforce ROV at isbgpsafeyet.com. If your transit providers don't drop RPKI-invalid routes, your ROA investment protects you only at providers further downstream — significant coverage, but not complete. Minimizing your announced prefix surface also matters: aggregating routes where possible reduces the number of hijackable targets.

---

BGP hijacking doesn't require exploiting any software vulnerability. It exploits a 35-year-old design decision made when the internet's routing operators were a small community assumed to be trustworthy. RPKI is closing the gap, slowly. Until universal adoption with full path validation arrives — and ASPA at 2.54% of ASNs suggests that's not imminent — organizations that don't actively monitor their prefix announcements are learning about hijacks from their users, not their monitoring.