BGP hijacking

Mechanism

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."

BGP hijacking and transit-AS problems

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. Also, in February 2008, a large portion of YouTube's address space was redirected to Pakistan when the PTA decided to block access 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

• April 1997: The "AS 7007 incident"
• December 24, 2004: TTNet in Turkey hijacks the Internet
• May 7, 2005: Google's May 2005 Outage
• January 22, 2006: Con Edison Communications hijacks big chunk of the Internet
• February 24, 2008: Pakistan's attempt to block YouTube access within their country takes down YouTube entirely.
• November 11, 2008: The Brazilian ISP CTBC - Companhia de Telecomunicações do Brasil Central leaked their internal table into the global BGP table. 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
• 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.
• February, 2014: Canadian ISP used to redirect data from ISPs. - 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.
• April 2017: Russian telecommunication company Rostelecom (AS12389) originated 37 prefixes 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. 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).
• 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.
• July 2018: Iran Telecommunication Company (AS58224) originated 10 prefixes of Telegram Messenger.
• November 2018: US-based China Telecom site originated Google addresses.
• May 2019: Traffic to a public DNS run by Taiwan Network Information Center (TWNIC) was rerouted to an entity in Brazil (AS268869).
• June 2019: Large European mobile traffic was rerouted through China Telecom (AS4134) "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…"
• 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.
• 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.
• 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.
• March 2022: RTComm hijacked a prefix used by Twitter.
• On June 27, 2024, a Brazilian ISP (AS267613, Eletronet) mistakenly advertised a /32 host route for 1.1.1.1, Cloudflare's public DNS resolver address, while another autonomous system leaked a /24. Several tier-1 networks accepted the more-specific /32 announcement, causing Cloudflare's DNS resolver to become unreachable or severely degraded for users across more than 300 networks in 70 countries.

Background

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

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."

BGP hijacking and transit-AS problems

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. Also, in February 2008, a large portion of YouTube's address space was redirected to Pakistan when the PTA decided to block access 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

• April 1997: The "AS 7007 incident"
• December 24, 2004: TTNet in Turkey hijacks the Internet
• May 7, 2005: Google's May 2005 Outage
• January 22, 2006: Con Edison Communications hijacks big chunk of the Internet
• February 24, 2008: Pakistan's attempt to block YouTube access within their country takes down YouTube entirely.
• November 11, 2008: The Brazilian ISP CTBC - Companhia de Telecomunicações do Brasil Central leaked their internal table into the global BGP table. 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
• 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.
• February, 2014: Canadian ISP used to redirect data from ISPs. - 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.
• April 2017: Russian telecommunication company Rostelecom (AS12389) originated 37 prefixes 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. 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).
• 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.
• July 2018: Iran Telecommunication Company (AS58224) originated 10 prefixes of Telegram Messenger.
• November 2018: US-based China Telecom site originated Google addresses.
• May 2019: Traffic to a public DNS run by Taiwan Network Information Center (TWNIC) was rerouted to an entity in Brazil (AS268869).
• June 2019: Large European mobile traffic was rerouted through China Telecom (AS4134) "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…"
• 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.
• 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.
• 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.
• March 2022: RTComm hijacked a prefix used by Twitter.
• In February 2025, researchers discovered a stealthy BGP hijacking incident targeting a sub-prefix (203.127.225.0/24) belonging to SingNet (Singapore). The prefix was fraudulently announced by Innove Communications, a Philippine network with no established relationship to SingNet, causing traffic from major transit providers including SEACOM to be silently diverted to the illegitimate origin. Whether the cause was misconfiguration or deliberate hijacking remained under investigation at the time of publication.