Detecting BGP origin hijacks at internet scale
Border Gateway Protocol (BGP) is the protocol that lets networks exchange reachability information for blocks of IP addresses, known as IP prefixes. It was designed on the assumption that networks do not intentionally propagate falsified information — an assumption that does not hold on the modern internet.
Attackers who control BGP routers can perform origin hijacks by falsely announcing ownership of IP prefixes they do not own. This redirects traffic destined for the victim network to the attacker, allowing interception and monitoring. The effect is analogous to swapping freeway signs to reroute traffic onto incorrect exits.
Cloudflare has long monitored suspicious BGP anomalies internally. The company is now bringing this detection capability to Cloudflare Radar, making the results publicly available.
How origin hijacks work
Devices locate each other on the internet using IP addresses. Blocks of addresses are called prefixes, and multiple prefixes from the same organization are aggregated into an autonomous system (AS). Using BGP, ASes announce which routes can be imported or exported to other ASes and routers — this is the AS routing policy. Without this routing information, large-scale internet operation would be impractical and data packets would be lost or severely delayed.
During a BGP origin hijack, an attacker creates fake announcements for a targeted prefix, falsely identifying an AS under their control as the origin. In a typical example, an attacking AS announces a prefix that was previously originated by a legitimate AS; receiving parties accept the hijacked route and forward traffic toward the attacker instead. The legitimate and hijacked traffic flows in the opposite direction of the BGP announcements received.
If successful, this type of attack disseminates the falsified prefix origin announcement throughout the internet, redirecting network traffic intended for the victim network to the attacker's AS. In 2018, an attacker convinced parts of the internet to reroute AWS traffic to malicious servers, using DNS to redirect MyEtherWallet.com, a popular cryptocurrency wallet, to a compromised page.
Why RPKI alone is not enough
The core difficulty in preventing BGP origin hijacks is that BGP itself has no mechanism to validate announcement content. Any route can be originated and announced by any network, regardless of its rights to announce that route.
To address this, operators and researchers proposed the Resource Public Key Infrastructure (RPKI), which stores and validates prefix-to-origin mapping information. With RPKI, operators prove ownership of network resources and create Route Origin Authorisations (ROAs) — cryptographically signed objects that define which AS is authorized to originate a specific prefix. Other operators can then validate BGP announcements by checking the prefix origin against RPKI data; hijacking attempts with an incorrect origin AS produce invalid validation results and should be discarded. This process is called route origin validation (ROV).
Cloudflare committed to RPKI support early on and provides the Is BGP Safe Yet? test service so users can check whether their ISP filters RPKI-invalid announcements. Detailed RPKI status information for individual prefixes and ASes is available at https://rpki.cloudflare.com/.
However, RPKI's effectiveness depends on two factors: the ratio of prefix owners who register their prefixes, and the ratio of networks performing route origin validation. Neither is at a satisfactory level yet. As of July 27, 2023, only about 45% of routable IP prefixes are covered by some ROA. Even for covered prefixes, hijack attempts can still succeed due to low ROV deployment — a recent study found only 6.5% of internet users are protected by ROV.
Until RPKI registration and RPKI-invalid filtering reach high adoption rates, BGP origin hijacks will continue to pose a significant threat. This makes developing and deploying BGP monitoring and detection tools essential for the security and stability of internet routing infrastructure.
How the detection pipeline is built
Cloudflare’s system is split into three cooperating modules: prefix origin change detection, hijack detection, and alert storage and delivery. The first module generates the raw signals, the second analyzes them, and the third stores results and notifies operators.
Tracking origin changes
BGP routing information is exchanged through two stateless message types. Announcements carry an AS-level path toward one or more prefixes, where the last hop in the path is the origin AS. Withdrawals simply state that a prefix is no longer reachable. Because neither message type carries any previous state, detecting an origin change requires building state from historical updates.
Rather than managing that state in a database, the team built a fast Rust-based IP prefix trie. The trie stores the origin ASN and AS path for each prefix and updates that information as announcements and withdrawals arrive. When an update changes the origin ASN for a prefix, the system records the BGP message and emits an Origin Change Signal.
The origin-change module consumes both live-streaming BGP data and historical archives. Live feeds undergo light processing to convert BGP messages into an internal format. For historical data, a dedicated deployment of the BGPKIT broker and parser converts MRT files from RouteViews and RIPE RIS into BGP message streams. After collection and normalization, the module maintains the prefix tries for each peer and sends enriched downstream messages whenever an origin change is detected.
Scoring potential hijacks
Deciding whether an origin change is malicious is not a binary question. The system gathers evidence from two categories of data sources and runs it through a weighted scoring function.
Inter-AS relationship datasets come from CAIDA/UCSD’s AS2org and AS2rel, BGPKIT’s AS2rel, PeeringDB AS organization data, and Cloudflare’s own per-prefix AS relationship data. Prefix-origin binding data comes from live RPKI validated ROA payloads via the Cloudflare RPKI portal, daily IRR dumps curated by MANRS, and bogon lists for private and reserved prefixes defined in RFC 1918, RFC 5735, and RFC 6598.
For each event, the scoring function runs a sequence of checks covering RPKI, IRR, bogon prefixes and ASNs, AS relationships, and AS path:
The scoring logic follows several guiding principles. If the newly announced origin is RPKI or IRR invalid, the event is more likely a hijack — unless the old origin was also invalid, in which case it is less likely. Events involving private or reserved ASes and prefixes are discarded. If the new and old origins have a direct business relationship, the event is less likely to be a hijack. And if the new AS path still routes through the old origin, it is probably not a hijack.
Signals deemed legitimate are dropped. Signals with sufficiently high confidence scores are flagged as potential hijacks and passed downstream. Because the output is a score rather than a verdict, the framework allows for false positives and false negatives, and the weights and conditions can be tuned over time based on manual inspection and additional datasets.
Aggregating messages into events
Operating per-message keeps the system fast and resource-light, but a single hijack can generate a flood of individual signals. To avoid overwhelming operators with alerts, the system aggregates related messages into BGP hijack events.
An event groups messages from the same hijacker ASN that target prefixes from the same victim. The event start time is the first suspicious signal. The event ends when either of two conditions occurs: a BGP withdrawal for the hijacked prefix (regardless of sender), or a new announcement reverting the origin to the previous legitimate network. If all messages in an event have been withdrawn or reverted, and no new suspicious origin changes arrive from the hijacker ASN for six hours, the event is marked finished.
This aggregation covers both small-scale and large-scale attacks, and alerts are based on events rather than individual messages.
Storage, alerts, and portability
The storage and notification module handles all detected hijack events, exposing them through a user interface for search and historical review. It generates and delivers alerts to network operators and security analysts, and can power dashboards for high-level visualization of events.
The entire detection pipeline is implemented as a single Rust-based command-line binary that connects to a PostgreSQL database. The full system, including the database, runs on a laptop. Runtime cost is dominated by maintaining in-memory prefix tries for full-feed routers, at roughly 200 MB per peer. The beta deployment uses about 170 full-feed peers and runs on a single 32 GB node with 12 threads.
Where the Hijack Alerts Live
BGP origin hijack detection results are now available through both the Cloudflare Radar website and the Cloudflare Radar API.
On the Radar site, a new BGP hijacks table appears under the “Security & Attacks” section for both the global and ASN views. Each entry in the table lists the detected and expected origin ASes, the start time and duration of the event, the number of BGP messages and route collector peers that observed it, the announced prefixes, and evidence tags alongside a confidence score.
Each event includes automatically generated evidence tags that explain why the system considers the activity suspicious—or why it does not. Red tags push the confidence score upward, indicating a higher likelihood of a hijack. Green tags do the opposite. For example, a red “RPKI INVALID” tag signals that the announcement failed RPKI validation, which strongly suggests a hijack. In contrast, a green “SIBLING ORIGINS” tag indicates that the detected and expected origins belong to the same organization, reducing the probability that the event is malicious. The table is accessible in two ways: from the global view under Security & Attacks with no location filters, which shows the most recent 150 detected BGP hijack events worldwide, and on the Overview, Traffic, and Traffic & Attacks tabs when the view is filtered by a specific ASN.
Querying the API
The Cloudflare Radar API also exposes the hijack detection results programmatically under a CC BY-NC 4.0 license, with documentation available on the Cloudflare API portal. The following curl command retrieves the ten latest BGP hijack events relevant to AS64512:
curl -X GET "https://api.cloudflare.com/client/v4/radar/bgp/hijacks/events?invlovedAsn=64512&format=json&per_page=10" \
-H "Authorization: Bearer <API_TOKEN>"For higher assurance, the minConfidence parameter filters events by a confidence score on a 0–10 scale, where higher values indicate a greater likelihood of a hijack. Extending the previous example, this query adds a minimum confidence score of 8:
curl -X GET "https://api.cloudflare.com/client/v4/radar/bgp/hijacks/events?invlovedAsn=64512&format=json&per_page=10&minConfidence=8" \
-H "Authorization: Bearer <API_TOKEN>"The API also supports building custom alerters using a Cloudflare Workers + KV combination. A full tutorial on setting up alerts via webhook messages or email with Email Routing is available on the Cloudflare Radar documentation site.
Upcoming Routing Insights
Cloudflare plans to expand the routing security data available on Radar with a dedicated routing section. This will provide digestible BGP information for specific networks or regions, including distinct routable prefixes, RPKI valid/invalid/unknown routes, and the distribution of IPv4/IPv6 prefixes. The goal is to offer the community better tools and data for routing security, with the broader aim of building a more secure Internet. Additional insights on Internet disruptions, routing issues, traffic trends, attacks, and Internet quality are available on Cloudflare Radar. Follow the project on Twitter at @CloudflareRadar, on Mastodon at noc.social/@cloudflareradar, on Bluesky at radar.cloudflare.com, or reach out via email.
