BGP Hijacking Techniques and Defenses
The Border Gateway Protocol was designed in an era when every network operator on the internet knew every other operator by name. There was no authentication, no cryptographic verification, and no mechanism to check whether a route announcement was legitimate. Thirty-five years later, BGP still runs on this trust model — and attackers exploit it. A BGP hijack occurs when a network announces IP prefixes it has no authority to announce, diverting traffic away from its rightful destination. The consequences range from brief service disruptions to large-scale data theft and surveillance. This article examines the specific techniques attackers use, the real-world incidents that demonstrate their impact, and the layered defenses the internet community has built to fight back.
Prefix Hijacking: Claiming Someone Else's Address Space
The most straightforward form of BGP hijack is an origin hijack, also called a prefix hijack. The attacker's router announces a prefix that belongs to another autonomous system, claiming to be the origin. For example, if Google (AS15169) legitimately originates 8.8.8.0/24, an attacker operating AS99999 could announce the same prefix with AS99999 as the origin.
When neighboring networks receive this announcement, they have two routes for the same prefix: one from Google (via its normal AS path) and one from the attacker. Which route "wins" depends on the BGP decision process at each receiving router — factors like AS path length, local preference, and multi-exit discriminator come into play. If the attacker is topologically closer to some networks (shorter AS path), those networks will route traffic to the attacker instead of Google.
The fundamental vulnerability is that BGP has no built-in way to verify origin claims. A router receiving a route announcement from a neighbor has no reason to doubt it — the neighbor vouches for it by forwarding it. This chain-of-trust model breaks when any single network in the chain is malicious or misconfigured.
Sub-Prefix Hijacking: The More-Specific Attack
Sub-prefix hijacking is more potent than a same-prefix origin hijack because it exploits BGP's longest prefix match rule. When a router has two routes — one for 8.8.8.0/24 and another for 8.8.8.0/25 — it always prefers the more specific /25 route, regardless of AS path length or any other attribute. The longer prefix is an unconditional winner in the forwarding table.
An attacker exploiting this technique takes the victim's prefix and announces a more specific subset. If Google announces 8.8.8.0/24, the attacker announces 8.8.8.0/25 and 8.8.8.128/25. Every router on the internet that receives both announcements will prefer the attacker's more-specific routes. The attack is nearly global in scope — only networks that filter the hijacked routes (via RPKI or manual filtering) are protected.
Most networks filter prefixes more specific than /24 for IPv4 and /48 for IPv6, which sets a natural boundary. If the victim already announces a /24, the attacker cannot go more specific because the /25 would be filtered by most transit providers. This is why RPKI ROAs specify a maxLength field — by setting a ROA with maxLength of /24, the prefix holder signals that no announcements more specific than /24 should be accepted. Any /25 from any origin would be RPKI-invalid.
AS Path Manipulation
While origin hijacks involve claiming ownership of a prefix, AS path manipulation attacks tamper with the AS path attribute itself. These attacks are subtler and harder to detect because the origin AS may remain correct while the path is forged.
AS Path Shortening
An attacker removes AS numbers from the path to make its route appear shorter and therefore more attractive. If the legitimate path to 8.8.8.0/24 is 2914 15169 (two hops), the attacker might announce it as 15169 (one hop) — forging a direct adjacency with Google that doesn't actually exist. Networks comparing paths will prefer the attacker's apparently shorter route.
AS Path Poisoning
Conversely, an attacker can add specific AS numbers to the path to prevent certain networks from accepting the route. Recall that BGP's loop-prevention mechanism causes a router to reject any route containing its own ASN. An attacker who wants to hijack traffic but avoid detection by a particular monitoring network can prepend that network's ASN into the fake path. The monitoring network will reject the route (thinking it's a loop), while everyone else accepts it. This technique has been observed in targeted hijacks where the attacker wants to avoid alerting the victim or specific route-monitoring infrastructure.
Forged Origin
The attacker announces the victim's prefix with the victim's ASN as the origin but places itself in the path. The route looks like: [attacker's AS] [victim's AS]. Since the origin AS is correct, simple origin-based validation (including basic RPKI ROV) will not flag this as invalid. The attack succeeds because the attacker's route may have a shorter overall path through certain parts of the internet. This type of manipulation is the primary motivation for path-level validation proposals like BGPsec and ASPA.
Interception Attacks: Hijack Without Disruption
The most sophisticated form of BGP hijack is an interception attack, sometimes called a man-in-the-middle BGP hijack. Unlike a simple prefix hijack that creates a "black hole" (traffic goes to the attacker and stops), an interception attack reroutes traffic through the attacker's network and then forwards it to the legitimate destination. The victim service continues to function, and end users experience little or no disruption — making the attack extremely difficult to detect.
The attacker accomplishes this by carefully engineering their BGP announcements. They announce the victim's prefix (or a more-specific sub-prefix) to attract traffic. But they ensure that their own path to the victim remains intact by using selective announcement — they only advertise the hijacked route to networks from which they want to capture traffic, while keeping their own upstream path to the victim clean. Alternatively, they use a separate, unhijacked path (perhaps via a different transit provider or a tunnel) to forward intercepted traffic to its real destination.
Interception attacks have been documented in the wild. The 2018 MyEtherWallet hijack was an interception-style attack: traffic to Amazon's Route 53 DNS was rerouted through a server that answered DNS queries with fake responses, redirecting cryptocurrency wallet users to a phishing site while the rest of the infrastructure appeared to function normally. The 2020 Rostelecom incident showed similar interception patterns, with traffic for major CDN and cloud providers briefly passing through Rostelecom's network before being forwarded to the correct destination.
Real-World Incident Patterns
Studying past incidents reveals recurring patterns in how BGP hijacks occur, propagate, and are resolved.
Accidental Hijacks: Fat Fingers and Misconfigurations
The majority of BGP hijacks are accidental. An operator misconfigures a router and announces prefixes they don't own, or fails to apply filters that prevent internal routes from leaking to the public internet. The 2008 Pakistan/YouTube incident is the textbook example: Pakistan Telecom was ordered to block YouTube domestically and did so by creating a BGP route for YouTube's prefix pointing to a null route. But the route leaked to their upstream provider, PCCW, which propagated it globally. Within minutes, YouTube was unreachable for much of the world.
Accidental hijacks are also closely related to BGP route leaks, where a network inappropriately forwards routes it received from one peer to another peer or provider. In 2019, a small Pennsylvania ISP leaked routes for many of the internet's largest prefixes through its upstream, Verizon, which did not have adequate filtering. The result was that traffic for Cloudflare, Amazon, and other major networks was funneled through a network far too small to carry it, causing widespread outages.
State-Sponsored Hijacks
Multiple incidents have been attributed to nation-state actors. China Telecom has been observed on several occasions originating routes for US government and military prefixes, causing traffic to traverse Chinese networks. In these cases, the routes were announced for short periods — sometimes just minutes — consistent with intelligence collection rather than disruption. Rostelecom's 2020 hijack of routes belonging to Google, Amazon, Cloudflare, and Akamai similarly appeared to be an interception-style rerouting rather than a simple blackhole.
Criminal Hijacks for Financial Gain
BGP hijacking has been used to steal cryptocurrency multiple times. The technique involves hijacking the prefixes of DNS servers or specific services to redirect users to phishing sites or intercept API calls. The 2018 MyEtherWallet attack combined a BGP hijack of Amazon's DNS infrastructure with forged DNS responses, redirecting users to a server that harvested private keys. The attackers stole approximately $17 million in cryptocurrency within two hours.
Defense Layer 1: RPKI and Route Origin Validation
RPKI (Resource Public Key Infrastructure) is the most widely deployed defense against BGP hijacking. It addresses origin hijacks by allowing IP address holders to create Route Origin Authorizations (ROAs) — cryptographically signed statements that specify which AS is authorized to originate a given prefix.
When a network performs Route Origin Validation (ROV), it checks every received BGP route against the published ROAs. The result is one of three states:
- Valid — the origin AS and prefix match a published ROA
- Invalid — a ROA exists but the route does not match (wrong origin AS, or prefix is more specific than the ROA's maxLength allows)
- Not Found — no ROA exists for this prefix
Networks that enforce RPKI (performing ROV and rejecting invalid routes) are protected against origin hijacks for any prefix that has a valid ROA. Major networks including Cloudflare, Google, NTT, and Arelion now reject RPKI-invalid routes. As of 2026, over 50% of globally announced prefixes have ROAs, and the adoption rate continues to climb.
However, RPKI has a critical limitation: it only validates the origin AS. An attacker who places the correct origin AS at the end of a forged path — the forged-origin attack described above — will pass RPKI validation. RPKI also cannot prevent route leaks, where a route is re-announced with the correct origin but through an unauthorized path.
Defense Layer 2: ASPA (Autonomous System Provider Authorization)
ASPA is a newer mechanism that extends RPKI to address path-level attacks and route leaks. With ASPA, each AS publishes a signed list of its authorized upstream providers. A validating network can then check each hop in the AS path: if AS X claims that AS Y is its upstream, but AS X has not listed AS Y as an authorized provider, the route is suspicious.
ASPA is particularly effective against route leaks. In a typical route leak, a customer AS receives a route from one provider and accidentally re-announces it to another provider. With ASPA, the receiving provider can check whether the leaking AS has authorized the provider it is announcing through — and reject the route if it has not.
ASPA is in the standardization process through the IETF and has begun seeing early deployment. It is designed to be incrementally deployable — even partial adoption provides meaningful protection, because any network that publishes an ASPA record and any network that validates ASPA can benefit immediately.
Defense Layer 3: BGPsec
BGPsec is the most comprehensive path-validation solution. It requires each AS in the path to cryptographically sign its hop, creating a verifiable chain of signatures from origin to receiver. A validating router can confirm not just that the origin AS is authorized (like RPKI), but that every AS in the path actually forwarded the route and consented to being in the path.
In theory, BGPsec eliminates both origin hijacks and path manipulation attacks entirely. In practice, deployment has been minimal due to significant operational challenges:
- Performance — every BGP update requires cryptographic signing and verification. With hundreds of thousands of routes and constant updates, this imposes substantial CPU overhead on routers.
- Incremental deployment — BGPsec only works when every AS in the path supports it. An unsigned gap anywhere in the path breaks the chain. This creates a chicken-and-egg problem where early adopters see little benefit.
- Incompatibility with AS path prepending — BGPsec does not accommodate prepending, which many networks rely on for traffic engineering.
As a result, the industry has largely moved toward the lighter-weight combination of RPKI ROV plus ASPA, which provides meaningful security without requiring universal deployment or per-update cryptographic operations.
Defense Layer 4: IRR Filtering
The Internet Routing Registry (IRR) predates RPKI and provides a database of routing policy information. Networks register their prefixes and AS numbers in the IRR (such as RADB, RIPE IRR, ARIN IRR, etc.), and other networks use this data to build prefix-list filters on their BGP sessions.
IRR-based filtering works like this: when a transit provider peers with a customer, it generates a prefix filter based on the customer's IRR records. Only prefixes registered to the customer in the IRR are accepted. If the customer tries to announce someone else's prefix — whether maliciously or accidentally — the filter drops it.
IRR filtering has significant limitations:
- No cryptographic verification — IRR records are not signed. Anyone can register objects, and stale or fraudulent registrations are common.
- Inconsistent maintenance — Many organizations do not keep their IRR records up to date, leading to either overly permissive filters (allowing too much) or overly restrictive ones (breaking legitimate routes).
- Multiple, uncoordinated databases — There is no single authoritative IRR. Records are spread across RADB, RIPE, ARIN, APNIC, and others, with varying quality.
Despite these weaknesses, IRR filtering remains widely deployed and provides a useful first line of defense, particularly against accidental hijacks. Many transit providers combine IRR filtering with RPKI validation for defense in depth: IRR filters catch misconfigured announcements from direct customers, while RPKI catches invalid origins regardless of where they enter the routing system.
Detection Methods
Even with preventive defenses, detection remains critical. A hijack that bypasses RPKI (because the prefix has no ROA, or the attack uses a forged-origin technique) must be caught through monitoring.
RIPE RIS and RouteViews
The RIPE Routing Information Service (RIS) operates a global network of route collectors — BGP routers that peer with hundreds of networks and record every route announcement and withdrawal they see. The data is available in real time through the RIS Live WebSocket feed and in archived form through RIS dumps. Similarly, the University of Oregon's RouteViews project collects BGP data from vantage points around the world.
These datasets enable detection of anomalies: new origins appearing for established prefixes, sudden path changes, unexpected more-specific announcements, and MOAS (Multiple Origin AS) events where the same prefix is seen from two different origin ASes — a hallmark of a hijack in progress.
BGPStream and Alerting
CAIDA's BGPStream framework provides a unified interface to RIS and RouteViews data, enabling real-time analysis. Services like Cloudflare Radar, RIPE Stat, BGPmon, and ThousandEyes build on these data sources to provide alerting: network operators can register their prefixes and receive immediate notification when an anomalous route is detected.
Effective alerting systems monitor for:
- Origin changes — a new ASN appearing as the origin for a prefix you own
- Sub-prefix announcements — more-specific prefixes appearing that cover your address space
- Path anomalies — unusual AS paths that suggest manipulation or route leaks
- RPKI status changes — routes transitioning from valid to invalid or not-found
- Reachability shifts — sudden changes in which networks can reach your prefix
BGP Looking Glasses
A BGP looking glass like god.ad provides on-demand visibility into the routing table. Operators can look up their prefixes and immediately see the origin AS, AS paths, and RPKI status from multiple vantage points. During a suspected hijack, a looking glass is often the first tool operators reach for — it answers the question "what does the internet see for my prefix right now?"
Try it yourself: look up any prefix and check whether the origin AS and paths match what you expect:
- 8.8.8.0/24 — should be originated by AS15169 (Google)
- 1.1.1.0/24 — should be originated by AS13335 (Cloudflare)
- AS32934 — check all of Meta's announced prefixes
Putting It Together: Defense in Depth
No single defense mechanism stops all BGP hijacking techniques. Effective protection requires layering multiple defenses:
For network operators, the practical steps are:
- Create ROAs for all your prefixes — Register with your RIR's RPKI system and create ROAs specifying the authorized origin AS and maximum prefix length for every prefix you announce.
- Enforce RPKI ROV on all BGP sessions — Configure your routers to reject RPKI-invalid routes. This protects your users from being affected by hijacks targeting other networks.
- Maintain accurate IRR records — Keep your route and aut-num objects current in the relevant IRR databases. Require the same from your customers.
- Apply strict prefix filters on customer BGP sessions — Only accept prefixes that a customer is authorized to announce. Generate these filters from IRR and RPKI data.
- Deploy ASPA — As your RIR supports it, publish ASPA records listing your authorized upstream providers.
- Monitor your prefixes — Subscribe to alerting services that watch for anomalous origin changes, sub-prefix announcements, and path shifts. Periodically verify your routes in a looking glass.
- Announce covering prefixes — Ensure you announce the most specific globally routable prefix (typically /24 for IPv4) so that an attacker cannot announce a more-specific sub-prefix.
The Evolving Threat Landscape
BGP hijacking is not a static threat. As defenses improve, attack techniques adapt. RPKI adoption has made simple origin hijacks riskier for attackers — a hijacked prefix with a valid ROA will be flagged as invalid and dropped by an increasing fraction of the internet. This has pushed attackers toward more sophisticated techniques: forged-origin attacks that pass ROV, interception attacks that are harder to detect, and targeted hijacks that use AS path poisoning to avoid specific monitors.
The internet routing community's response is a layered strategy: RPKI for origin validation (deployed today), ASPA for path validation (deploying now), monitoring for detection (mature and widely available), and continued research into full path security. Each new layer reduces the attack surface, making hijacks progressively harder, more detectable, and shorter-lived.
The tools to verify route security are available to everyone. Check the RPKI status and origin of any prefix, examine AS paths, and investigate anomalies using the looking glass: