This article was originally published on the APNIC blog.
Border Gateway Protocol (BGP) hijacking has long been one of the protocol’s most persistent security threats. RPKI and ROV were standardized to provide origin authentication and mitigate the threat, but Route Origin Validation (ROV) deployment is likely to remain partial for the next decade. Partial deployment not only leaves obvious gaps in protection but also creates a subtle threat, which we refer to as ROV-related stealthy BGP hijacking (or simply stealthy hijacking).
(Free access, no subscription required)
In a stealthy hijack, the affected Autonomous System (AS) never sees the malicious origin on the control plane because ROV-enabled neighbors drop the invalid announcement. Yet, traffic can still be silently diverted to an attacker via legacy (non-ROV) ASes along the data plane path. This makes the attack effectively evade detection that relies on control-plane visibility. In other words, BGP hijacking becomes stealthier — the victim’s routing tables and RPKI checks look perfectly normal, even as its traffic is being diverted.
Below, we present a real-world case that illustrates how a stealthy hijack occurs.
Figure 1 — Hijacking incident on 203.127.225.0/24 (last seen on 24 April 2025). This incident was most likely the result of a benign misconfiguration.
In a stealthy hijack, the affected Autonomous System (AS) never sees the malicious origin on the control plane because ROV-enabled neighbors drop the invalid announcement. Yet, traffic can still be silently diverted to an attacker via legacy (non-ROV) ASes along the data plane path. This makes the attack effectively evade detection that relies on control-plane visibility. In other words, BGP hijacking becomes stealthier — the victim’s routing tables and RPKI checks look perfectly normal, even as its traffic is being diverted.
Below, we present a real-world case that illustrates how a stealthy hijack occurs.
Figure 1 — Hijacking incident on 203.127.225.0/24 (last seen on 24 April 2025). This incident was most likely the result of a benign misconfiguration.
In this case, AS17894, the supposed hijacker, mis-announced a /24 prefix, which is part of a /16 that is legitimately owned and originated by AS3758. Technically, this is a classic sub-prefix hijack.
What makes this case subtle is how ROV comes into play. In Figure 1, only AS37100 applies ROV filtering. Because AS37100 dropped the invalid /24 route, it kept only the valid /16 route in its routing table. As a result, AS37100 and its customers had no visibility of the invalid route on the control plane. In other words, AS37100 and its customers had no reason to suspect anything wrong. Yet their traffic to the /24 was still diverted to AS17894 via legacy AS6762, which does not perform ROV and accepted the invalid /24 route. Unless notified or actively probing the /24 for some reason, they would remain unaware of the ongoing hijack.
Evidence from AS37100’s looking glass confirms the incident. We manually inspected AS37100’s control-plane view and data-plane reachability using its public looking glass ‘g-01-ams.nl‘. All observations were captured on 10 February 2025.
As shown in Figure 2, running show ip bgp for the /16 returned two valid routes, both originated by the legitimate owner AS3758:
Figure 2 — AS37100’s routes to 203.127.0.0/16.
For the /24 sub-prefix, however, show ip bgp returned nothing (see Figure 3), meaning that the hijack was effectively invisible to AS37100 at the control plane:
Figure 3 — AS37100’s routes to 203.127.225.0/24.
The data plane told a different story. As shown in Figure 4, a traceroute from AS37100 to 203.127.225.1 was diverted and ended up in AS17894, confirming that the /24 traffic was indeed being hijacked (Figure 4).
Figure 4 — Traceroute from AS37100 to 203.127.225.1.
The key takeaway from this incident is that if any intermediate AS on your path has a different view of origins than you do, traffic diversion could still happen, even if your own routing table looks good. And most importantly, partial ROV deployment is making such inconsistencies more common, making BGP hijacking potentially harder to detect.
Beyond this case, we conducted a large-scale empirical and analytical study of stealthy BGP hijacking risk across today’s Internet. The full results are presented in our upcoming paper at NDSS 2026. We have also launched a website that publishes daily reports of stealthy hijacks we capture in the wild.
Based on what we learned, here are some operational insights and recommendations for network operators:
First, keep pushing RPKI and ROV deployment forward. One key finding from our study is that the risk of stealthy hijacking follows a rise-then-decline curve as ROV deployment increases. The good news is that current data suggests we may now be entering the declining phase, so further adoption can reduce the risk.
Second, pay attention to what you drop. Invalid routes that you filter out may still carry valuable information. Monitoring and correlating them can help flag possible traffic diversion events. A more proactive (though aggressive) mitigation strategy could be for ROV-enabled ASes to not only drop invalid routes but also re-run route selection and prefer routes that avoid ASes seen in the dropped announcements (a similar policy is described in a Cisco patent).
Finally, collaborate and share visibility. Community resources, such as RouteViews, RIPE RIS, and RIPE Atlas, are powerful tools for improving collective visibility into routing events. ROV-enabled ASes could further help by sharing ‘dropped route’ digests (for example, via mailing lists), giving others early warning of stealthy hijacks. We encourage operators to join the discussions, share operational experiences, and help shape practical defences. As an initial step, we have opened an Internet Draft to formally document this threat and invite feedback.
Stealthy BGP hijacking is a subtle but real risk in today’s partially secured Internet. The good news is that with wider RPKI adoption, better monitoring, and further collaboration, we can make it far harder for such attacks to succeed, and easier to detect when they do.
Yihao presented this topic during Technical Session 2 at APNIC 60. Watch the recording, including the audience discussion, now.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.
