Hubbry Logo
BGP hijackingBGP hijackingMain
Open search
BGP hijacking
Community hub
BGP hijacking
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
BGP hijacking
BGP hijacking
BGP hijacking
View on Wikipedia
from Wikipedia

BGP hijacking (sometimes referred to as prefix hijacking, route hijacking or IP hijacking) is the illegitimate takeover of groups of IP addresses by corrupting Internet routing tables maintained using the Border Gateway Protocol (BGP).[1][2][3][4][5]

Background

[edit]

The Internet is a global network that enables any connected host, identified by its unique IP address, to talk to any other, anywhere in the world. This is achieved by passing data from one router to another, repeatedly moving each packet closer to its destination, until it is delivered. To do this, each router must be regularly supplied with up-to-date routing tables. At the global level, individual IP addresses are grouped together into prefixes. These prefixes will be originated, or owned, by an autonomous system (AS), and the routing tables between ASes are maintained using the Border Gateway Protocol (BGP).

A group of networks that operates under a single external routing policy is known as an autonomous system. For example, Sprint, Verizon, and AT&T each are an AS. Each AS has its own unique AS identifier number. BGP is the standard routing protocol used to exchange information about IP routing between autonomous systems.

Each AS uses BGP to advertise prefixes that it can deliver traffic to. For example, if the network prefix 192.0.2.0/24 is inside AS 64496, then that AS will advertise to its provider(s) and/or peer(s) that it can deliver any traffic destined for 192.0.2.0/24.

Although security extensions are available for BGP, and third-party route DB resources exist for validating routes, by default the BGP protocol is designed to trust all route announcements sent by peers. Many ISPs do not rigorously enforce checks on BGP sessions.

Mechanism

[edit]

IP hijacking can occur deliberately or by accident in one of several ways:

  • An AS announces that it originates a prefix that it does not actually originate.
  • An AS announces a more specific prefix than what may be announced by the true originating AS.
  • An AS announces that it can route traffic to the hijacked AS through a shorter route than is already available, regardless of whether the route exists.

Common to these ways is their disruption of the normal network routing: packets end up being forwarded towards the wrong part of the network and then either enter an endless loop (and are discarded), or are found at the mercy of the offending AS.

Typically ISPs filter BGP traffic, allowing BGP advertisements from their downstream networks to contain only valid IP space. However, a history of hijacking incidents shows this is not always the case.

The Resource Public Key Infrastructure (RPKI) is designed to authenticate route origins via cryptographic certificate chains demonstrating address block range ownership but is not widely deployed yet. Once deployed, IP hijacking through errant issues at the origin (via accident or intent) should be detectable and filterable.

IP hijacking is sometimes used by malicious users to obtain IP addresses for use in spamming or a distributed denial-of-service (DDoS) attack.

When a router disseminates erroneous BGP routing information, whether intentionally or accidentally, it is defined by the Internet Engineering Task Force (IETF) in RFC 7908 as a "route leak." These leaks are characterized as "the dissemination of routing announcements beyond their intended scope. In other words, an announcement from one Autonomous System (AS) regarding a learned BGP route to another AS contravenes the intended policies of the recipient, the sender, and/or one of the ASes along the preceding AS path." Such leaks are made possible due to a long-standing "systemic vulnerability of the Border Gateway Protocol routing system."[6]

BGP hijacking and transit-AS problems

[edit]

Like the TCP reset attack, session hijacking involves intrusion into an ongoing BGP session, i.e., the attacker successfully masquerades as one of the peers in a BGP session, and requires the same information needed to accomplish the reset attack. The difference is that a session hijacking attack may be designed to achieve more than simply bringing down a session between BGP peers. For example, the objective may be to change routes used by the peer, in order to facilitate eavesdropping, black holing, or traffic analysis.

By default, BGP peers will attempt to add all routes received from another peer into the device's routing table and then proceed to advertise nearly all of these routes to other BGP peers. This can pose a problem as multi-homed organizations may inadvertently advertise prefixes learned from one Autonomous System (AS) to another, leading the end customer to become the new best path to the relevant prefixes.

For instance, a customer with a Cisco router peering with both AT&T and Verizon, and employing no filtering, may inadvertently establish a link between the two major carriers. This could result in the providers preferring to route some or all traffic through the customer (potentially on a T1 line) instead of utilizing high-speed dedicated links. This issue can also impact other entities peering with these two providers and lead those ASs to favor the misconfigured link.

In practice, this problem rarely occurs with large Internet Service Providers (ISPs) as they typically impose restrictions on what an end customer can advertise. However, any ISP that does not filter customer advertisements may inadvertently allow incorrect information to be propagated into the global routing table, potentially affecting even the large Tier-1 providers.

The concept of BGP hijacking involves identifying an Internet Service Provider (ISP) that does not filter advertisements, whether intentionally or unintentionally, or identifying an ISP with vulnerable internal or ISP-to-ISP BGP sessions susceptible to a man-in-the-middle attack. Once identified, an attacker can potentially advertise any prefix they choose, leading to the diversion of some or all traffic from its legitimate source to the attacker. This action can be carried out to overwhelm the infiltrated ISP or to execute a Denial of Service (DoS) or impersonation attack on the entity whose prefix is being advertised. It is not uncommon for attackers to cause significant disruptions, including complete loss of connectivity.

In an incident from early 2008, at least eight US universities experienced their traffic being rerouted to Indonesia for approximately 90 minutes one morning in an attack that was largely kept under wraps by those involved.[citation needed] Also, in February 2008, a large portion of YouTube's address space was redirected to Pakistan when the PTA decided to block access[7] to the site from inside the country, but accidentally black-holed the route in the global BGP table. While filtering and MD5/TTL protection is already available for most BGP implementations (thus preventing the source of most attacks), the problem stems from the concept that ISPs rarely ever filter advertisements from other ISPs, as there is no common or efficient way to determine the list of permissible prefixes each AS can originate. The penalty for allowing errant information to be advertised can range from simple filtering by other/larger ISPs to a complete shutdown of the BGP session by the neighboring ISP (causing the two ISPs to cease peering), and repeated problems often end in permanent termination of all peering agreements. It is also noteworthy that even causing a major provider to block or shutdown a smaller, problematic provider, the global BGP table will often reconfigure and reroute the traffic through other available routes until all peers take action, or until the errant ISP fixes the problem at the source.

One useful offshoot of this concept is called BGP anycasting and is frequently used by root DNS servers to allow multiple servers to use the same IP address, providing redundancy and a layer of protection against DoS attacks without publishing hundreds of server IP addresses. The difference in this situation is that each point advertising a prefix actually has access to the real data (DNS in this case) and responds correctly to end user requests.

Public incidents

[edit]
  • April 1997: The "AS 7007 incident"[8]
  • December 24, 2004: TTNet in Turkey hijacks the Internet[9]
  • May 7, 2005: Google's May 2005 Outage[10]
  • January 22, 2006: Con Edison Communications hijacks big chunk of the Internet[11]
  • February 24, 2008: Pakistan's attempt to block YouTube access within their country takes down YouTube entirely.[12]
  • November 11, 2008: The Brazilian ISP CTBC - Companhia de Telecomunicações do Brasil Central leaked their internal table into the global BGP table.[13] It lasted over 5 minutes. Although, it was detected by a RIPE route server and then it was not propagated, affecting practically only their own ISP customers and few others.
  • April 8, 2010: Chinese ISP hijacks the Internet[14]
  • July 2013: The Hacking Team aided Raggruppamento Operativo Speciale (ROS - Special Operations Group of the Italian National Military police) in regaining access to Remote Access Tool (RAT) clients after they abruptly lost access to one of their control servers when the Santrex IPv4 prefix 46.166.163.0/24 became permanently unreachable. ROS and the Hacking Team worked with the Italian network operator Aruba S.p.A. (AS31034) to get the prefix announced in BGP in order to regain access to the control server.[15]
  • February, 2014: Canadian ISP used to redirect data from ISPs.[16] - In 22 incidents between February and May a hacker redirected traffic for roughly 30 seconds each session. Bitcoin and other crypto-currency mining operations were targeted and currency was stolen.
  • January 2017: Iranian pornography censorship.[17]
  • April 2017: Russian telecommunication company Rostelecom (AS12389) originated 37 prefixes[18] for numerous other Autonomous Systems. The hijacked prefixes belonged to financial institutions (most notably MasterCard and Visa), other telecom companies, and a variety of other organizations.[19] Even though the possible hijacking lasted no more than 7 minutes it is still not clear if the traffic got intercepted or modified.
  • December 2017: Eighty high-traffic prefixes normally announced by Google, Apple, Facebook, Microsoft, Twitch, NTT Communications, Riot Games, and others, were announced by a Russian AS, DV-LINK-AS (AS39523).[20][21]
  • April 2018: Roughly 1300 IP addresses within Amazon Web Services space, dedicated to Amazon Route 53, were hijacked by eNet (or a customer thereof), an ISP in Columbus, Ohio. Several peering partners, such as Hurricane Electric, blindly propagated the announcements.[22]
  • July 2018: Iran Telecommunication Company (AS58224) originated 10 prefixes of Telegram Messenger.[23]
  • November 2018: US-based China Telecom site originated Google addresses.[24]
  • May 2019: Traffic to a public DNS run by Taiwan Network Information Center (TWNIC) was rerouted to an entity in Brazil (AS268869).[25]
  • June 2019: Large European mobile traffic was rerouted through China Telecom (AS4134)[26][27] "This route leak began when [Swiss] SafeHost (AS21217) announced more than forty-thousand IPv4 routes that had been learned from other peers and providers to its provider China Telecom (AS 4134). …In turn, China Telecom accepted these routes and propagated them…"[28]
  • February 2021: Initially reported that Cablevision Mexico (AS28548) leaked 282 prefixes creating conflicts for 763 ASNs in 80 countries, with the main impact in Mexico. Data from the Isolario MRT dump suggested that 7,200 IPv4 prefixes were announced and leaked to AS1874 impacting more than 1290 ASNs from over 100 countries.[29]
  • April 2021: Large BGP routing leak out of India: over 30,000 BGP prefixes hijacked via Vodafone Idea Ltd (AS55410) causing 13X spike in inbound traffic. Prefixes were from around the globe but mostly US including Google, Microsoft, Akamai, and Cloudflare.[30]
  • February 2022: Attackers hijacked BGP prefixes that belonged to a South Korean cryptocurrency platform, and then issued a certificate on the domain via ZeroSSL to serve a malicious JavaScript file, stealing $1.9 million worth of cryptocurrency.[31]
  • March 2022: RTComm hijacked a prefix used by Twitter.[32][33]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

BGP hijacking

View on Grokipedia
from Grokipedia
(BGP) hijacking, also termed route hijacking, constitutes the injection of false route advertisements by an autonomous (AS) into the Internet's interdomain fabric, diverting traffic intended for specific IP prefixes to unauthorized destinations. BGP, the prevailing protocol for exchanging information among ASes, relies on unverified announcements predicated on mutual trust rather than cryptographic safeguards, rendering it vulnerable to both inadvertent errors and deliberate exploitation. This mechanism enables an AS to prepend illegitimate origin AS numbers or fabricate AS paths, prompting upstream routers to propagate the deceptive routes based on BGP's path-vector selection criteria. Hijacking manifests in forms such as prefix hijacking, where an AS originates routes for unallocated prefixes, or subprefix hijacking, involving more specific announcements that outcompete legitimate ones due to BGP's longest-prefix-match forwarding. Motivations span accidental misconfigurations from faulty filters or peering disputes to intentional acts like traffic redirection for , amplification of denial-of-service floods, or circumvention of sanctions, with empirical observations indicating a rise in state-linked incidents leveraging BGP's global propagation delays for sustained redirection. Detection challenges persist owing to the protocol's tolerance for multiple paths and absence of origin validation, often requiring anomaly analysis of control-plane updates against empirical route histories. Mitigation strategies encompass (RPKI) to attest prefix ownership via digitally signed objects, enabling ASes to reject invalid origin advertisements, alongside BGPsec extensions for securing AS path integrity through cumulative signatures—yet deployment lags due to validation overhead, burdens, and incomplete inter-AS coordination. These vulnerabilities underscore BGP's foundational design trade-offs favoring over , perpetuating risks to resilience despite incremental hardening efforts.

Fundamentals of BGP and Hijacking

Definition and Scope

BGP hijacking refers to the deliberate or erroneous advertisement of false (BGP) routes by an autonomous system (AS), resulting in the unauthorized redirection of destined for specific IP prefixes away from legitimate paths. This vulnerability stems from BGP's design, which relies on trust among peering ASes without built-in or validation of route origins or paths, allowing malicious actors or misconfigurations to propagate deceptive announcements across the global . The scope of BGP hijacking primarily encompasses inter-domain disruptions, where an attacker AS announces prefixes it does not own, actions such as interception for , selective denial-of-service, or rerouting for or financial gain. Forged-origin hijacks, a common subtype, involve an unauthorized AS claiming direct control over a victim's prefix, often detectable via discrepancies in AS_PATH attributes but propagatable rapidly due to BGP's path-vector mechanics. While some incidents arise from like configuration typos or unintended prepending, the term typically denotes malicious intent, distinguishing it from benign route leaks defined in RFC 7908 as unintended propagation of internal or customer routes beyond their designated scope. In practice, hijacks can affect prefixes representing millions of IP addresses, with propagation times ranging from minutes to hours depending on BGP update damping and peering topology, potentially impacting global services like financial networks or content delivery. The phenomenon's breadth includes both state-sponsored operations and , but excludes intra-domain issues or protocol-independent attacks, focusing solely on BGP's exterior role connecting over 100,000 ASes worldwide as of 2024. Detection relies on tools monitoring control-plane anomalies, though incomplete adoption of defenses like (RPKI) leaves the protocol susceptible to such exploits.

Core BGP Protocol Mechanics

The (BGP), specified in RFC 4271, operates as an to exchange routing information between autonomous systems (ASes) on the , enabling policy-based path selection rather than shortest-path metrics used in interior protocols. BGP employs a path vector mechanism, where routers advertise reachable network prefixes (NLRI, or Network Layer Reachability Information) along with the sequence of ASes traversed to reach them, facilitating loop detection and administrative control over route preferences. Unlike distance-vector protocols, BGP does not inherently compute metrics but relies on configurable attributes to influence route dissemination and selection, supporting (CIDR) for efficient prefix aggregation. BGP sessions establish over TCP connections using port 179 for reliable, ordered delivery, with peers assuming roles of sender or receiver based on TCP three-way handshake completion. Upon TCP connection, peers exchange OPEN messages to negotiate parameters including BGP version (typically 4), local AS number, hold time (minimum 3 seconds, or 0 for indefinite), and a unique BGP identifier (an IPv4 address). Sessions progress through a finite state machine—Idle, Connect, Active, OpenSent, OpenConfirm, Established—with KEEPALIVE messages sent at intervals no less than one-third of the hold time to maintain connectivity, and NOTIFICATION messages to signal errors like version mismatch or connection closure. External BGP (eBGP) peers typically connect directly or via multi-hop configurations, while internal BGP (iBGP) operates within the same AS, often requiring full-mesh or route reflectors for scalability. Core message types include OPEN for initialization, UPDATE for dynamic route information, for liveness, and NOTIFICATION for termination. UPDATE messages, the primary vehicle for routing data, carry path attributes followed by NLRI for new advertisements or withdrawn routes for removals, allowing multiple prefixes sharing attributes in a single message to optimize exchange. Attributes are categorized as well-known (mandatory like NEXT_HOP or AS_PATH, or discretionary like LOCAL_PREF) or optional (transitive or non-transitive), with types encoded numerically—e.g., AS_PATH (type code 2) as a sequence of AS numbers prepended by the advertising router to record traversal history. Route advertisement involves injecting prefixes into the Adj-RIB-Out table after local policy application, then propagating via UPDATE to peers, with withdrawals triggering removal from forwarding tables upon validation. The BGP decision process selects best paths through sequential comparisons: highest LOCAL_PREF for outbound preference, shortest AS_PATH length to favor brevity, lowest origin type (IGP over EGP or incomplete), lowest MED for inbound ties, and eBGP over iBGP preference. Loop prevention relies fundamentally on AS_PATH inspection; if the local AS appears in the path, the route is discarded to avoid circular propagation. This design prioritizes policy flexibility over cryptographic validation, as attributes like NEXT_HOP (updated to the advertiser's IP for eBGP) propagate without inherent origin authentication.

Types and Mechanisms

Classification of Hijack Types

BGP hijacking events are classified based on the specific mechanism of the anomalous route announcement, distinguishing between misconfigurations that mimic hijacks and deliberate manipulations. A analysis by researchers at the Center for Applied Internet Data Analysis (CAIDA) categorizes reported hijacking incidents into four primary types using heuristics like AS hegemony scores and edit distances: typos, which involve inadvertent errors in entering prefixes or Autonomous System Numbers (ASNs), such as mistyping a prefix like 191.96.129.0/24 as 191.86.129.0/24 due to input mistakes; prepending mistakes, where errors occur in AS path prepending configurations, like incorrectly specifying a repetition count instead of repeating the ASN, leading to unintended route preferences; origin changes, characterized by the advertisement of unowned prefixes from a new origin AS, often malicious and detected via Multi-Origin AS (MOAS) conflicts, allowing traffic interception or blackholing; and forged AS paths, involving fabricated paths to bypass detection, identified by inconsistencies in global AS rankings or local path similarities. Malicious hijacks, distinct from accidental misconfigurations, are further subdivided by propagation dynamics and intent. Prefix hijacking (or origin hijacking) occurs when an unauthorized AS announces routes for a victim's IP prefix, either matching the exact length to compete via shorter paths or using more specific subnets (e.g., /24 over /23) to exploit BGP's longest-match preference, redirecting traffic for or denial-of-service. AS path hijacking, or path poisoning, manipulates the AS_PATH attribute by prepending fake ASes or inserting the attacker's AS into legitimate paths, making the route appear valid while steering traffic through the hijacker, often for man-in-the-middle attacks. These intentional types differ from route leaks, which involve unintended propagation of internal routes but share similar detection challenges due to BGP's lack of inherent validation. Classification schemes like those from CAIDA achieve high accuracy (e.g., 95.71% via models) by integrating BGP data from monitors such as BGPStream, emphasizing the need to differentiate hijacks from benign anomalies like link failures. In practice, hijacks are also grouped by outcome: blackholing (dropping traffic), (inspecting/relaying), or disruption, with malicious variants prioritizing stealth through path over crude origin shifts.

Execution and Propagation Dynamics

BGP hijacking execution begins when an autonomous system (AS) under attacker control configures its border routers to issue unauthorized BGP UPDATE messages announcing an IP prefix belonging to a victim AS. The attacker typically advertises the prefix as originating from its own AS number, often forging or manipulating the AS_PATH attribute to present a shorter path than legitimate routes, exploiting BGP's preference for brevity in path selection. To increase effectiveness, the hijacker may announce a more specific prefix (e.g., /24 instead of the legitimate /23), leveraging BGP's rule to override broader announcements. These false announcements propagate through eBGP sessions to directly connected peer ASes, which receive the UPDATE, apply local policies, and—if the route is deemed superior via the BGP best-path algorithm (prioritizing factors like LOCAL_PREF, AS_PATH length, origin type, and MED)—install it in their routing information base (RIB) and forward it onward. Propagation occurs hop-by-hop across the internet's AS graph, with iBGP used internally within each AS to distribute the route to all routers, potentially leading to global adoption if unfiltered. The dynamics of propagation are governed by BGP's asynchronous update process, influenced by timers such as the Minimum Route Advertisement Interval (MRAI, default 30 seconds) that throttle announcement bursts, and keepalive/hold timers (typically 60 seconds) that maintain session stability. Full convergence can take minutes to hours, depending on network topology, peering density, and the presence of route dampening or filtering policies that may suppress or delay invalid routes. In practice, hijacked routes often spread rapidly via high-tier transit providers, as seen in the 2008 Pakistan YouTube incident where a false prefix announcement propagated worldwide within minutes, diverting traffic until countermeasures like more-specific legitimate announcements were deployed. Without validation mechanisms like RPKI or IRR checks, the lack of inherent authentication in BGP allows unchecked dissemination, enabling partial hijacks (where traffic splits between legitimate and false paths) or complete takeovers.

Historical Incidents

Pre-2010 Events

On April 25, 1997, a router in autonomous system (AS) 7007, operated by MAI Network Services, experienced a that caused it to withdraw nearly all global BGP routes before readvertising them with AS 7007 prepended to the AS paths. This incident partitioned the , rendering approximately half of reachable destinations inaccessible for about 20 to 30 minutes as invalid routes propagated. The event exposed BGP's vulnerability to erroneous route announcements lacking inherent validation mechanisms. On December 24, 2004, TTNet (AS 9121), 's largest ISP, inadvertently re-originated over 106,000 prefixes—representing a significant portion of global routes—to its upstream provider Telecom Italia due to a peering configuration error. This leak directed much of the world's through Turkey for several hours, causing widespread congestion, , and service disruptions until the invalid announcements were withdrawn. The incident highlighted operational risks in BGP peering sessions without route filtering. On January 22, 2006, Con Edison Communications (AS 25706) erroneously announced routes for numerous prefixes owned by its customers and other entities, including Panix (AS 2033), leading to traffic interception and outages for affected networks. The hijack persisted until manual intervention restored legitimate paths, demonstrating BGP's susceptibility to unauthorized origin changes from misconfigured or compromised ASes. On February 24, 2008, (AS 17557) announced the prefix 208.65.153.0/24—allocated to AS 36561—to block domestic access per government order, but the more specific advertisement propagated globally, redirecting worldwide traffic to and rendering the site inaccessible for up to two hours. The event affected tens of millions of users and underscored how local intent can cascade into international disruptions via BGP's path-vector propagation without authentication. Resolution required withdrawal of the false route and reliance on backup addressing by . These pre-2010 incidents, primarily stemming from misconfigurations rather than malice, collectively illustrated BGP's trust-based design flaws, prompting early discussions on enhancements like route origin validation.

2010s Developments

In April 2010, announced bogus routes for approximately 50,000 IP prefixes, representing a significant portion of global tables, which rerouted up to 15% of worldwide through its networks for about 18 minutes. This incident, often classified as a hijack due to its scale and the announcement of non-originating prefixes, affected traffic destined for major U.S. entities including government (.gov) and military (.mil) domains such as the , , , and , potentially enabling interception or surveillance. Analysis indicated the event was not accidental, as selectively originated prefixes it did not own, demonstrating the protocol's vulnerability to state-level actors conducting large-scale traffic diversion. By 2013, BGP hijacks increasingly targeted financial and governmental infrastructure for man-in-the-middle attacks. In August, actors in originated false routes for prefixes owned by U.S. processors and Icelandic government networks, sustaining the hijack for six days and enabling potential on sensitive transactions. Concurrently, the Italian firm Hacking Team executed a BGP hijack on behalf of to reroute traffic for operations, highlighting how private entities could exploit BGP for authorized but protocol-violating interceptions. The mid-to-late 2010s saw a rise in BGP hijacks motivated by theft, exploiting the protocol's trust model to redirect wallet and exchange traffic. In 2014, adversaries hijacked routes between miners and pools to intercept unencrypted communications, altering mining rewards. By 2018, such attacks escalated; unknown perpetrators hijacked MyEtherWallet's domain resolution, stealing approximately $17 million in by redirecting users to sites. also engaged in prolonged misrouting of U.S. domestic traffic through its infrastructure from 2017 to 2018, spanning over two years and affecting providers like Verizon, raising concerns over persistent state-sponsored surveillance capabilities. These incidents underscored BGP's ongoing susceptibility, with documented hijacks numbering in the thousands annually by the decade's end, though distinguishing intentional hijacks from leaks remained challenging without enhanced monitoring. Responses included proposals for cryptographic route origin validation, but adoption lagged, leaving networks reliant on reactive detection.

2020s and Recent Cases

In April 2020, Russian telecommunications provider (AS12389) executed a large-scale BGP hijack by announcing more specific routes for over 8,000 prefixes belonging to major networks, including , , Amazon, Akamai, and , diverting traffic to its own infrastructure where much of it was blackholed. The incident began around 7:30 PM UTC on April 1 and persisted until routes were withdrawn the following day, causing widespread service disruptions and outages for affected content delivery networks. While some operators like Telia and NTT filtered the invalid announcements using RPKI validation, others such as Level 3 propagated them, amplifying the impact. Cryptocurrency platforms emerged as frequent targets in the early 2020s, exemplified by the August 17, 2022, attack on Celer Bridge, a cross-chain bridging service. Attackers employed forged BGP announcements and fake entries in the AltDB database—a free alternative to Internet Routing Registries—to impersonate ' address space, tricking a UK-based transit provider into redirecting traffic. By forging an Amazon ASN in the path to evade partial RPKI route origin validation, the hijack enabled interception of user transactions, resulting in the theft of approximately $235,000 from 32 victims over about three hours. This case highlighted vulnerabilities in reliance on unverified databases and incomplete RPKI adoption for . In 2024, BGP hijacks persisted, including a January 3 incident affecting Orange Spain, where "" exploited vulnerabilities in the database to hijack BGP routes, causing a nationwide . Later that year, in July, a commercial network hijacked IP addresses from a U.S. research and regional by announcing more specific routes, leading to traffic disruptions until partial mitigation via RPKI route origin authorizations (ROAs); full resolution was delayed by a cloud provider's lack of RPKI . of BGP from 2014 to 2023 identified ongoing "serial hijackers"—autonomous systems repeatedly seizing prefixes, with about 40% of previously flagged actors remaining active into 2022-2023, often evading detection due to sparse monitoring and reallocation of AS numbers. These patterns underscore the persistence of hijacking for , outages, and theft, despite incremental defenses like RPKI.

Underlying Vulnerabilities

Protocol Design Flaws

The Border Gateway Protocol (BGP), specified in RFC 4271, operates without inherent mechanisms to authenticate the origin of route advertisements or validate the authority of an autonomous system (AS) to announce specific network layer reachability information (NLRI). This trust-based model assumes cooperative behavior among peering ASes, enabling any participant to insert false routes that propagate transitively across the internet routing table without cryptographic or authoritative checks. As a result, malicious actors can perform prefix hijacks by advertising unauthorized IP prefixes, diverting traffic intended for legitimate destinations. BGP sessions rely on TCP for transport but lack protocol-level peer entity , making them susceptible to spoofing, , and insertion of fabricated UPDATE messages. While optional extensions like TCP MD5 signatures (per RFC 2385) can provide some session protection, they are not mandated by the core protocol and do not address data integrity or origin validation for routing attributes. Deprecated authentication fields from earlier BGP versions (e.g., BGP-1 through BGP-3) were removed in BGP-4 due to lack of adoption, leaving the protocol without built-in defenses against message modification or replay. A critical flaw lies in the absence of validation for path attributes, particularly the AS_PATH, which is intended to prevent loops but can be forged, prepended, or truncated to manipulate route selection. Without verifying the legitimacy of AS numbers in the path or the originating AS's right to advertise a prefix, BGP accepts and disseminates potentially bogus routes based solely on policy and shortest-path metrics. This enables path hijacks, where attackers insert themselves into legitimate routes by announcing altered AS sequences, often undetected until traffic anomalies occur. These vulnerabilities trace to BGP's design in the late for a smaller, research-oriented dominated by trusted entities like and academic networks, prioritizing over . The protocol's evolution, including the standardization of BGP-4, did not retroactively incorporate robust validation, as early options proved ineffective and unused. Consequently, route hijacking remains feasible, as demonstrated in analyses showing how unverified announcements can corrupt global routing tables.

Operational and Human Factors

Operational vulnerabilities in BGP arise primarily from the protocol's design reliance on unverified trust relationships between autonomous systems (ASes), where route announcements are accepted without cryptographic authentication or origin validation. Network operators often fail to deploy comprehensive inbound and outbound prefix filtering, allowing invalid or unexpected routes to propagate unchecked; for instance, the absence of proper filters contributed to the AS17557 incident, where misconfigured announcements disrupted traffic to major providers. Additionally, incomplete implementation of route origin authorization systems like RPKI leaves approximately 50% of advertised IP prefixes unprotected as of 2024, enabling hijackers to forge valid-looking announcements that evade basic operational checks. Human factors exacerbate these issues through configuration errors and insufficient oversight, with many BGP incidents classified as route leaks stemming from accidental misconfigurations rather than deliberate malice. A 2002 analysis of BGP updates identified misconfigurations as a leading cause of instability, including erroneous path announcements that increase global load and mimic hijacking effects. For example, the November 2015 route leak, affecting over 2,000 prefixes, resulted from in AS path handling, leading to widespread traffic redirection without intent to hijack. Such errors often occur due to fat-finger inputs or overlooked policy updates during network expansions, compounded by the protocol's complexity, which demands precise manual configurations across distributed teams. Adoption barriers for mitigations like RPKI further highlight human and organizational inertia, including reluctance to navigate certificate issuance errors or inter-AS dependencies that could disrupt legitimate routing. Studies of BGP events indicate that human-induced anomalies, such as similar prefix announcements between hijacker and victim, frequently signal unintentional errors rather than sophisticated attacks, underscoring the need for automated validation tools to reduce reliance on operator vigilance. Initiatives like MANRS promote operational norms such as global validation and anti-spoofing, yet slow uptake—driven by training gaps and fear of self-inflicted outages—persists, leaving networks exposed to both erroneous and malicious exploits.

Impacts and Ramifications

Immediate Network Effects

BGP hijacking triggers rapid propagation of unauthorized route announcements across the , leading routers to redirect traffic destined for hijacked IP prefixes to the attacker's autonomous system rather than the legitimate origin. This misdirection often manifests as immediate connectivity disruptions, where affected traffic is intercepted, rerouted through inefficient paths, or dropped entirely if the hijacker employs blackholing techniques. In scenarios where the hijacker forwards intercepted packets, users encounter elevated latency and performance degradation, as data traverses longer or congested alternative routes outside standard or peering arrangements. can occur due to route instability or deliberate non-forwarding, exacerbating issues like failed connections and increased retransmissions. A prominent example is the February 24, 2008, hijack of YouTube's 208.65.153.0/24 prefix by Pakistan Telecom (AS17557), which diverted global traffic to its network, resulting in widespread outages lasting approximately two hours as packets failed to reach YouTube's servers (AS36561). On April 1, 2020, Russian provider (AS12389) announced over 8,800 prefixes belonging to entities including Amazon, Akamai, and , causing traffic diversion, packet drops, and intermittent service interruptions for users reliant on those networks. More recently, on June 27, 2024, AS267613 hijacked Cloudflare's 1.1.1.1/32 prefix, blackholing traffic accepted by multiple upstream providers and triggering DNS resolution outages for 1.1.1.1 users beginning at approximately 18:51 UTC, with some networks enforcing route blackholing that amplified the impact.

Broader Security and Economic Consequences

BGP hijacking extends beyond localized traffic disruptions to enable pervasive security threats, including man-in-the-middle attacks that intercept sensitive data traversing unencrypted paths. Attackers can eavesdrop on communications, alter payloads, or impersonate legitimate endpoints, compromising data integrity and confidentiality across intercepted routes. State-sponsored actors have exploited these vulnerabilities for espionage, diverting traffic to surveillance points to access personal, corporate, or governmental information without detection. Such incidents undermine the foundational trust in internet routing, facilitating broader cyber operations like , , or the disruption of dependencies on stable BGP announcements. For instance, hijacks targeting DNS can misdirect queries globally, amplifying risks to authentication systems and enabling cascading failures in secure communications protocols. Economically, BGP hijacks precipitate direct financial losses through service outages and , with downtime for affected networks potentially costing enterprises millions in foregone revenue and remediation expenses. In targeted attacks on platforms, hijackers have redirected traffic to malicious endpoints, enabling thefts such as the February 2022 incident where KLAYswap lost $1.9 million in assets via illicit transactions facilitated by route manipulation. These events correlate with profit motives, including correlations between hijack timings and mining payouts observed in 2014 cases. Persistent vulnerabilities also impose indirect costs, as organizations invest in advanced monitoring, redundant routing, and validation protocols like RPKI to mitigate recurrence, straining operational budgets particularly for smaller autonomous systems lacking resources for comprehensive defenses. Hijacks exploiting economic incentives, such as rerouting to sites or amplifying denial-of-service attacks, further erode user confidence in digital transactions, contributing to sector-wide losses in and .

Geopolitical and Strategic Implications

BGP hijacking enables state actors to redirect through their controlled networks, facilitating and on adversaries' communications. In April 2010, announced false routes that rerouted approximately 15% of global , including data from U.S. government websites and systems, through Chinese infrastructure for up to 18 minutes, raising concerns over potential data interception despite official denials of malicious intent. Such incidents underscore the strategic value of BGP manipulation in allowing covert access to sensitive military, diplomatic, and economic data without direct confrontation. During geopolitical conflicts, BGP hijacks serve as tools for disruption and intelligence gathering. In the context of Russia's 2022 invasion of , reports indicated Russian entities rerouting Ukrainian internet traffic for potential sniffing and interference, alongside suspected hijacks targeting Ukrainian networks to degrade connectivity and enable man-in-the-middle attacks. This aligns with broader patterns where authoritarian regimes exploit BGP vulnerabilities to censor opposition, as seen in the 2008 Pakistan hijack that inadvertently disrupted global access, highlighting how domestic controls can spill over into international tensions. Strategically, these capabilities pose risks to by threatening and enabling asymmetric cyber operations. U.S. agencies have warned that state-sponsored hijacks can expose unencrypted traffic to theft, extortion, and , potentially compromising financial transactions or command-and-control systems during crises. The persistence of such vulnerabilities, exemplified by ongoing suspicions of Chinese traffic rerouting via global ASNs, erodes confidence in the interdependent architecture, prompting calls for enhanced to counter great-power competition without fragmenting the network. Failure to mitigate these risks could escalate , where BGP attacks precede or accompany kinetic actions, amplifying geopolitical instability.

Detection, Mitigation, and Responses

Monitoring and Detection Methods

BGP monitoring relies on global infrastructures that collect routing announcements from multiple vantage points to identify anomalies indicative of hijacking. Public BGP collectors, such as the Route Views project operated by the and RIPE NCC's Routing Information Service (RIS), aggregate UPDATE messages from diverse autonomous systems (ASes), enabling the detection of inconsistencies like unexpected prefix origins or multiple competing announcements for the same IP block. These systems provide real-time data streams, with tools like BGPStream facilitating analysis of historical and live feeds to spot deviations from expected routing tables. Detection methods primarily employ heuristic rules to flag hijacks, such as sub-prefix attacks where an illegitimate AS announces a more specific prefix than the legitimate one, or forged-origin hijacks where the AS_PATH attribute is manipulated to attribute a prefix to an unauthorized origin. For instance, s cross-reference announced origins against known prefix allocations from regional registries (RIRs) and detect events when a prefix suddenly appears under a new AS not matching its authoritative holder. (RPKI) enhances this by validating Route Origin Authorizations (ROAs); announcements failing ROA checks—due to mismatched AS origins—are invalidated, as implemented in Cloudflare's BGP hijack detection launched in July 2023, which integrates RPKI with control-plane monitoring to alert on invalid routes within minutes. Complementary data-plane techniques monitor end-to-end metrics like minimum round-trip times (minRTTs), identifying sustained delay spikes as evidence of traffic rerouting through distant or malicious paths, with experiments showing detection of Bitcoin-related hijacks via such . Advanced detection incorporates machine learning for unsupervised anomaly identification, such as AP2Vec, which embeds AS relationships into vector spaces to detect role shifts during hijacks, achieving high precision on labeled datasets from 2019-2021 events. Multi-dimensional approaches analyze features like announcement volume, AS path length, and withdrawal patterns, with one method detecting over 99% of 1,487 prefix hijacks validated against BGPStream data. Open-source tools like ARTEMIS, developed by RIPE NCC in 2018 and updated through 2019, provide real-time prefix hijack detection using route leak and sub-prefix heuristics, integrated with mitigation signaling for operators. Similarly, APNIC's BGPWatch platform, introduced in February 2024, employs knowledge-based algorithms to diagnose incidents, visualizing hijack propagation across the routing table and attributing events to specific ASes. Despite these methods, challenges persist, including false positives from legitimate route changes and vulnerabilities to monitor poisoning, where attackers flood collectors with benign data to mask hijacks, as demonstrated in analyses of systems like DFOH showing susceptibility to large-scale BGP data manipulation. Global monitoring remains incomplete, with undetected attacks exploiting uRPF filtering or selective announcements evading public collectors, underscoring the need for diverse, operator-deployed sensors.

Technological Defenses

(RPKI) provides a cryptographic framework to validate the authorization of autonomous systems (ASes) to originate specific IP prefixes, mitigating prefix hijacking by enabling route origin validation (ROV). Through Route Origin Authorizations (ROAs), resource holders digitally sign attestations of prefix ownership, which relying parties validate against BGP announcements to discard invalid routes. RPKI deployment has progressed significantly, with Route Origin Validation implemented by major networks; for instance, as of January 2024, Verizon (AS701) achieved full ROV across its infrastructure, contributing to a where invalid routes are increasingly filtered globally. By October 2025, RPKI's integration into routing processes has demonstrably reduced successful hijacks by embedding origin checks directly into BGP decision-making, though it does not address path manipulations like prepend attacks or leaks from authorized origins. BGPsec extends RPKI by securing the full AS path through cryptographic signatures appended by each forwarding AS, preventing path hijacking or forgery where an attacker inserts unauthorized segments. Standardized in RFC 8205, BGPsec requires routers to verify the integrity and authenticity of the entire update path, rejecting alterations. However, adoption remains limited due to operational complexities, including the need for public key distribution and performance overhead, with pilot implementations but no widespread deployment as of 2025. Autonomous System Provider Authorization (ASPA), an extension to RPKI, validates customer-provider relationships to defend against more sophisticated path violations, such as unauthorized transit or interception via invalid . ASPA objects specify authorized upstream providers, allowing routers to confirm path legitimacy beyond mere origin. Simulations indicate ASPA's effectiveness against path manipulation increases with adoption rates above 50%, complementing ROV but requiring similar cryptographic . Despite these advances, comprehensive protection demands layered implementation, as no single protocol fully secures BGP against all hijack variants without broad ecosystem participation.

Policy and Operational Best Practices

Operators should prioritize the deployment of (RPKI) to enable route origin validation (ROV), which cryptographically validates whether an Autonomous System (AS) is authorized to announce specific IP prefixes via Route Origin Authorizations (ROAs). ROAs must be created to match exact announced prefixes, with maxLength parameters set conservatively to cover only legitimate sub-allocations and avoid enabling more-specific hijacks. Routers configured for ROV should initially monitor invalid routes before progressing to tagging or dropping them, using multiple redundant validators for reliability. Participation in the Mutually Agreed Norms for Routing Security (MANRS) initiative commits operators to four core actions: filtering announcements to prevent propagation of incorrect routing information, coordinating globally to minimize disruption from errors or attacks, implementing anti-spoofing measures aligned with BCP 38 (RFC 2827), and maintaining accurate contact information in public registries for rapid incident response. MANRS encourages validation against Internet Routing Registries (IRRs) alongside RPKI, with operators publishing filtering policies and AS-set objects to peers. Operational hardening of BGP sessions includes mandatory authentication using TCP Authentication Option (TCP-AO) or with strong keys to prevent hijacking of peering relationships, combined with Generalized TTL Security Mechanism (GTSM) to verify peer proximity by enforcing expected TTL values (e.g., 255 for eBGP over directly connected links). Control-plane policing should rate-limit BGP traffic to mitigate denial-of-service attempts, while maximum prefix limits per neighbor (e.g., tearing down sessions exceeding thresholds like 80% of limit) protect router resources from table exhaustion. Route filtering policies require inbound and outbound prefix lists to accept only authorized prefixes (e.g., whitelisting customer allocations and rejecting unallocated or bogon space per IANA registries) and AS-path access lists to block invalid paths, such as those not originating from expected upstreams. Operators must enforce specificity limits (e.g., no IPv4 /25 or longer from peers unless explicitly allowed) and enable of neighbor state changes alongside route flap dampening to suppress unstable announcements without excessive penalties. Regular audits of configurations, including verification of ROAs via tools like regional RPKI dashboards, and on these practices reduce human-error-induced leaks or misconfigurations that enable hijacks.

References

  1. https://www.caida.org/catalog/papers/2019_bgp_hijacking_classification/bgp_hijacking_classification.pdf
  2. https://www.usenix.org/system/files/nsdi24-holterbach.pdf
  3. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-14.pdf
  4. https://www.usenix.org/system/files/login/articles/login_winter19_02_camp.pdf
  5. https://labs.ripe.net/author/vasileios_kotronis/artemis-neutralising-bgp-hijacking-within-a-minute/
  6. https://www.cloudflare.com/learning/security/glossary/bgp-hijacking/
  7. https://www.ietf.org/archive/id/draft-chen-grow-enhanced-as-loop-detection-07.html
  8. https://www.rfc-editor.org/rfc/rfc7908.html
  9. https://blog.cloudflare.com/bgp-hijack-detection/
  10. https://pmc.ncbi.nlm.nih.gov/articles/PMC11479385/
  11. https://datatracker.ietf.org/doc/html/rfc4271
  12. https://datatracker.ietf.org/doc/html/rfc4271#section-1
  13. https://datatracker.ietf.org/doc/html/rfc4271#section-1.2
  14. https://datatracker.ietf.org/doc/html/rfc4271#section-4
  15. https://datatracker.ietf.org/doc/html/rfc4271#section-4.2
  16. https://datatracker.ietf.org/doc/html/rfc4271#section-8
  17. https://datatracker.ietf.org/doc/html/rfc4271#section-6.1
  18. https://datatracker.ietf.org/doc/html/rfc4271#section-4.1
  19. https://datatracker.ietf.org/doc/html/rfc4271#section-4.3
  20. https://datatracker.ietf.org/doc/html/rfc4271#section-5
  21. https://datatracker.ietf.org/doc/html/rfc4271#section-3.1
  22. https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.1
  23. https://datatracker.ietf.org/doc/html/rfc4271#section-9.1.2.2
  24. https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.3
  25. https://www.catchpoint.com/bgp-monitoring/bgp-hijacking
  26. https://www.ripe.net/documents/3781/BGP_hijacking_brief_guide_on_protecting_BGP_from_bad_actors_b117eaf3-243d-4a95_xjDDZAc.pdf
  27. https://www.kentik.com/kentipedia/bgp-hijacking/
  28. https://www.noction.com/blog/bgp-hijacking
  29. https://www.cisco.com/c/en/us/products/cloud-systems-management/crosswork-network-automation/the-risks-of-traffic-hijacking.html
  30. https://www.kentik.com/blog/a-brief-history-of-the-internets-biggest-bgp-incidents/
  31. https://archive.nanog.org/mailinglist/mailarchives/old_archive/1997-04/msg00444.html
  32. https://www.merit.edu/wp-content/uploads/2024/10/Merit-Network_New-BGP-Analysis-Tools-and-a-Look-at-the-AS9121-Incident.pdf
  33. https://archive.nytimes.com/www.nytimes.com/external/idg/2009/01/15/15idg-Six-worst-Inter.html
  34. https://crypto.stanford.edu/portia/papers/bgp_karlin_06.pdf
  35. https://www.ripe.net/about-us/news/youtube-hijacking-a-ripe-ncc-ris-case-study/
  36. https://research.google/pubs/youtube-hijacking-february-24th-2008-analysis-of-bgp-routing-dynamics/
  37. https://citizenlab.ca/2012/12/characterizing-large-scale-routing-anomalies-a-case-study-of-the-china-telecom-incident/
  38. https://www.theregister.com/2010/11/17/bgp_hijacking_report/
  39. https://people.cs.umass.edu/~phillipa/papers/Hiran_Pam2013_full.pdf
  40. https://www.wired.com/2013/12/bgp-hijacking-belarus-iceland/
  41. https://arstechnica.com/information-technology/2015/07/hacking-team-orchestrated-brazen-bgp-hack-to-hijack-ips-it-didnt-own/
  42. https://www.theregister.com/2018/04/24/myetherwallet_dns_hijack/
  43. https://arstechnica.com/information-technology/2018/11/strange-snafu-misroutes-domestic-us-internet-traffic-through-china-telecom/
  44. https://www.thousandeyes.com/blog/rostelecom-route-hijack-highlights-bgp-security
  45. https://manrs.org/2020/04/not-just-another-bgp-hijack/
  46. https://www.securityweek.com/russian-telco-hijacked-internet-traffic-major-networks-accident-or-malicious-action/
  47. https://www.kentik.com/blog/bgp-hijacks-targeting-cryptocurrency-services/
  48. https://blog.apnic.net/2022/11/07/what-can-be-learned-from-bgp-hijacks-targeting-cryptocurrency-services/
  49. https://www.coinbase.com/blog/celer-bridge-incident-analysis
  50. https://tuxcare.com/blog/orange-spain-outage/
  51. https://internet2.edu/what-the-research-education-community-learned-from-three-impactful-routing-security-incidents-in-2024/
  52. https://blog.apnic.net/2024/10/25/serial-bgp-hijackers-a-reproducibility-study-and-assessment-of-current-dynamics/
  53. https://qrator.net/blog/details/q2-2024-ddos-bots-and-bgp-incidents-statistics-and
  54. https://datatracker.ietf.org/doc/html/rfc4272
  55. https://datatracker.ietf.org/doc/html/rfc4272#section-3
  56. https://datatracker.ietf.org/doc/html/rfc4272#section-3.1.5.4
  57. https://www.ietf.org/rfc/rfc4271.txt
  58. https://faculty.cc.gatech.edu/~ctestart8/publications/BGPhist.pdf
  59. https://datatracker.ietf.org/doc/html/rfc4272#section-3.1.5.3
  60. https://www.cs.princeton.edu/~jrex/papers/bgp-security08.pdf
  61. https://pulse.internetsociety.org/blog/why-is-routing-security-adoption-moving-so-slowly
  62. https://ratul.org/papers/sigcomm2002-misconfigs.pdf
  63. https://nsfocusglobal.com/bgp-hijackings-come-back/
  64. https://eprint.iacr.org/2016/1010.pdf
  65. https://www.loginradius.com/blog/identity/how-to-protect-business-bgp-hijacking
  66. https://blog.cloudflare.com/cloudflare-1111-incident-on-june-27-2024/
  67. https://www.thousandeyes.com/blog/4-real-bgp-troubleshooting-scenarios
  68. https://nrs.help/post/insight/impact-of-bgp-hijacking-on-global-internet-traffic/
  69. https://www.cisa.gov/news-events/news/most-important-part-internet-youve-probably-never-heard
  70. https://www.datacenters.com/news/bgp-hijacking-understanding-mitigation-and-best-practices
  71. https://www.bankinfosecurity.com/crypto-exchange-klayswap-loses-19m-after-bgp-hijack-a-18518
  72. https://www.secureworks.com/research/bgp-hijacking-for-cryptocurrency-profit
  73. https://www.cyberdefensemagazine.com/experts-detailed-how-china-telecom-used-bgp-hijacking-to-redirect-traffic-worldwide/
  74. https://slate.com/technology/2018/11/bgp-hijacking-russia-china-protocols-redirect-internet-traffic.html
  75. https://manrs.org/2022/03/did-ukraine-suffer-a-bgp-hijack-and-how-can-networks-protect-themselves/
  76. https://cyberdefensereview.army.mil/CDR-Content/Articles/Article-View/Article/2882277/unlearned-lessons-from-the-first-cybered-conflict-decade-bgp-hijacks-continue/
  77. https://bgpstream.caida.org/
  78. https://ieeexplore.ieee.org/document/9754706
  79. https://labs.ripe.net/author/vasileios_kotronis/artemis-an-open-source-tool-for-detecting-bgp-prefix-hijacking-in-real-time/
  80. https://blog.apnic.net/2024/02/07/bgpwatch-a-comprehensive-platform-for-detecting-and-diagnosing-hijacking-incidents/
  81. https://www.usenix.org/system/files/woot25-schulmann.pdf
  82. https://isbgpsafeyet.com/
  83. https://interlir.com/2025/10/13/how-rpki-prevents-bgp-hijacks-protects-your-network-traffic/
  84. https://www.ndss-symposium.org/wp-content/uploads/2025-675-paper.pdf
  85. https://www.anapaya.net/blog/why-rpki-wont-save-bgp
  86. https://www.arin.net/blog/2025/09/25/nro-rpki-best-practices/
  87. https://manrs.org/netops/guide/
  88. https://datatracker.ietf.org/doc/html/rfc7454
  89. https://www.nsa.gov/portals/75/documents/what-we-do/cybersecurity/professional-resources/ctr-guide-to-border-gateway-protocol-best-practices.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.