# Exploiting Internet's Shadow Areas for Stealth Interception BGP Hijack at Internet Exchange Points

Hugo Rimlinger, Olivier Fourmaux, Timur Friedman, Ronaldo A. Ferreira, Kevin Vermeulen

► To cite this version:

Hugo Rimlinger, Olivier Fourmaux, Timur Friedman, Ronaldo A. Ferreira, Kevin Vermeulen. Exploiting Internet's Shadow Areas for Stealth Interception BGP Hijack at Internet Exchange Points. TMA PhD School, Jun 2025, Copenhagen, Denmark. . [hal-05220992](https://hal.science/hal-05220992v1)

HAL Id: hal-05220992

https://hal.science/hal-05220992v1

Submitted on 24 Aug 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Exploiting Internet's Shadow Areas for
Stealth Interception BGP Hijack at Internet
Exchange Points.

Hugo Rimlinger¹³ Olivier Fourmaux¹ Timur Friedman¹³
Ronaldo A. Ferreira⁴ Kevin Vermeulen²

¹LIP6, Sorbone Université

²Ecole Polytechnique

³LINCS

⁴UFMS, Brazil

## Introduction

Despite its central role in the propagation of Internet routes and despite efforts to make it more secure, BGP remains vulnerable to certain attacks called **BGP hijacks**.

* **A lack of authentication mechanism:** Despite a steady increase of authentication mechanisms adoption (like RPKI or BGPsec), BGP remains vulnerable to more sophisticated attacks.

* **A dependence on detection systems:** These detections systems are able to catch an attacker by analysing public BGP data from monitors (control-plane) [4] or performing measurements like ping or traceroutes (data-plane) [5].

The main question we ought to answer with this work is the following: can we characterize and detect shadow areas, regions of the network that are invisible to existing detection systems?

## Shadow Areas Characterization

We define a shadow area as a part of the network where a BGP hijack can be conducted while remaining undetected by state-of-the art detection systems. These systems fall into two categories:

1. Data-plane detection.

* Uses ping and traceroutes measurements to detect hijacks (ex: iSPY [5]).

* The first criteria for a shadow area is: **the hijack should only target ASes that do not answer traceroute.**

* Notice that this approach falls short in case of Man-in-the-Middle (or interception) attack [1].

2. Control-plane detection.

* Analyses publicly available BGP feeds from organizations like RIPE RIS and Route Views for hijacks detection (ex: ARTEMIS [4]).

* These methods rely on the principle that the bogus route is perceived by one of the BGP monitors. Therefore, **the attacker's route should not reach a BGP monitor.**

## Defining a surface of attack

Current methodologies [1, 3] perform **upstream** attacks where the bogus route is announced to a **provider**. These attacks **require precise knowledge about the attacker network** to define how and where the attack propagates.

We propose a new model of **downstream attacks** for hijacking prefixes with a better control on the propagation of the attacker's route:

1. The route is announced to one of the peers of the attacker.

2. Due to the "valley-free" the route is only propagated to the peer customer cone.

3. In this context, we know where the route will be propagated.

Downstream attacks are not considered because the surface of attack is narrow. An attacker can overcome this issue by **leveraging the property of the IXPs**:

* IXPs are large switch fabrics connecting hundreds of ASes.

* It is the perfect place to create peering links with other ASes.

In this settings, **we can multiply the number of shadow areas** (peer without reachability nor BGP monitors) and thus our surface of attack.

<figure><img src="image_2.png" /><figcaption>Figure 1. Illustration of our threat model. A pointed arrow symbolizes a customer to provider link (C>P). No arrow symbolize a peering links. AS 5 and its customer cone (AS 6, AS 7 and AS 8) do not have a BGP monitor. The attacker (A) propagates a malicious route to AS 5 for the victim's (V) prefix, from an IXP. Because of the "valley-free" rule, AS 5 propagates the route to its clients and not to AS 4, the provider.</figcaption></figure>

## Preliminary results

### Traceroute reachability

Among a total of 118k registered ASes, 61k (52%) of them answered at least to one traceroute probe.

### BGP monitoring

There are 1,533 BGP monitors in 599 ASes for RIPE RIS and 1,754 BGP monitors and 423 ASes from Routeviews, for a total of 2,711 BGP monitors and 865 ASes.

### IXPs

We retrieve a set of 1,109 IXPs for a total of 22,573 ASes participants.

### AS's customer cone

We acquire each AS's customer cone using CAIDA's AS relationship dataset.

**Control-plane criteria:** We retrieve 21k (96%) ASes peering at an IXP without a BGP monitor. Over these ASes, 16k of them do not have a monitor in their customer cone. Adding the ASes in their customer cone, **we obtain a dataset of 86k ASes (73%) peering at an IXP without a BGP monitor** in them or in their customer cone.

**Reachability criteria:** Adding the data plane criterion, **we find only 1,328 ASes, 2,723 when adding their customers** (also all unresponsive), that peer at an IXP, do not answer to ping and traceroute and do not possess a BGP monitor.

There are two takeaways from these preliminary results:

1. Most ASes peering at an IXP do not have a BGP collector peer in them or in their customer cone

2. Adding data plane condition significantly reduces the surface of attack, so one must be able to forward back to the victim to remain unnoticed.

## Challenges

**Why these results need to be refined.** The results are likely to be overestimated, for the following reasons. First, when announcing a prefix to an AS at an IXP, all of its client ASes might not adopt the route. On the other hand, these results might also be underestimated, as our condition for an announcement to be visible is conservative: Not all the announcements made on the Internet are visible to all collector peers.

**Better understanding the IXP ecosystem.** To refine our estimation, we need to better understand how the prefixes are propagated at an IXP. Most IXPs now propose a service called the route server (RS), which allows IXP participants to reduce their number of BGP sessions. The RS performs its own BGP route selection and only forwards the best route it chose. This problem is known as BGP path hiding at IXPs [2], and solutions have been designed to mitigate this problem, but nobody has ever studied how they were implemented.

## References

[1] Henry Birge-Lee, Liang Wang, Jennifer Rexford, and Prateek Mittal. Sico: Surgical interception attacks by manipulating bgp communities. In *Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security*, pages 431–448, 2019.

[2] Elisa Jasinska, Nick Hilliard, Robert Raszuk, and Niels Bakker. Rfc 7947: Internet exchange bgp route server, 2016.

[3] Alexandros Milolidakis, Tobias Bühler, Kunyu Wang, Marco Chiesa, Laurent Vanbever, and Stefano Vissicchio. On the effectiveness of bgp hijackers that evade public route collectors. In *IEEE Access*, 2023.

[4] Pavlos Sermpezis, Vasileios Kotronis, Petros Gigis, Xenofontas Dimitropoulos, Danilo Cicalese, Alistair King, and Alberto Dainotti. Artemis: Neutralizing bgp hijacking within a minute. In *IEEE/ACM transactions on networking*, 2018.

[5] Zheng Zhang, Ying Zhang, Y. Charlie Hu, Z. Morley Mao, and Randy Bush. iSPY: Detecting IP prefix hijacking on my own. In *SIGCOMM*, 2008.