BGP Hijack Monitor
Understand BGP hijacks and route leaks. Check ASN update activity for anomalies and explore historical incident data.
Advertisement · Anuncio
What is a BGP Hijack?
A BGP hijack occurs when a malicious or misconfigured router announces prefixes (IP address ranges) that belong to another autonomous system. Because BGP lacks built-in authentication, other routers may accept these false announcements and route traffic to the wrong destination — potentially allowing interception, redirection, or black-holing of internet traffic.
Route Leaks vs. Hijacks
A route leak is an accidental propagation of routing announcements beyond their intended scope — for example, a customer re-advertising transit routes to other providers. A hijack is typically intentional. Both can cause widespread disruptions, as seen in high-profile incidents affecting major internet services.
RPKI: The Modern Defense
Resource Public Key Infrastructure (RPKI) is a security framework that cryptographically validates that an ASN is authorized to announce specific IP prefixes via Route Origin Authorizations (ROAs). When RPKI validation (ROV — Route Origin Validation) is deployed, routers can automatically reject invalid BGP announcements, significantly reducing hijack risk.
- Origin hijack: An AS announces a prefix it doesn't own with a shorter or equal prefix length.
- Subprefix hijack: More specific prefix announced, attracting traffic due to longest-prefix-match routing.
- Route leak: Routes redistributed to unintended peers, causing traffic redirection.
- AS path manipulation: Inserting fake ASNs in the AS_PATH to bypass loop prevention or influence routing decisions.
BGP Security: Understanding Hijacks, Route Leaks, and RPKI
BGP (Border Gateway Protocol) was designed for trust between networks, not security. Since BGP has no built-in authentication for route origins, malicious or misconfigured routers can announce prefixes they don't control. Notable historical incidents include the 2010 China Telecom hijack of 15% of global internet traffic, the 2008 Pakistan Telecom YouTube blackout, and the 2018 MyEtherwallet BGP hijack that redirected cryptocurrency traffic.
Modern mitigation strategies include RPKI (Resource Public Key Infrastructure), which assigns cryptographic certificates to IP address blocks and ASNs through Regional Internet Registries (RIRs). Route Origin Authorizations (ROAs) specify which ASNs are authorized to originate which prefixes. When deployed with Route Origin Validation (ROV), BGP routers can automatically reject "Invalid" route origins — those that conflict with existing ROA records.
Additional defenses include IRR (Internet Routing Registry) filtering, MANRS (Mutually Agreed Norms for Routing Security) adoption, BGPsec (which signs the full AS_PATH), and monitoring tools like BGPmon, RIPE Stat, and BGPstream that provide real-time alerts for routing anomalies. The AS_PATH length, update frequency, and prefix specificity are key indicators of potentially suspicious routing behavior.
Check ROA for a prefix
curl "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS13335&prefix=104.16.0.0/12" curl "https://rpki-validator.ripe.net/api/v1/validity/AS13335/104.16.0.0/12"
Monitor BGP updates (requires bgpdump)
bgpdump -m updates.gz | grep "^BGP4MP|" | awk '{print $7}' | sort | uniq -c | sort -rn | head -20Expert guide · BGP Hijack Monitor
What it does
The BGP Hijack Monitor has two parts. For any ASN you enter, it pulls seven days of BGP update activity from RIPEstat, which aggregates what the RIPE NCC Routing Information Service collectors saw, and reports total announcements plus withdrawals, the daily average and a churn-based risk level. The incidents table and the hijack versus leak explainer are clearly labeled sample data meant to illustrate event types; they are not a live feed of detected hijacks.
Why it matters
- Early warning from churn: A sudden jump in announcements and withdrawals for your ASN often precedes customer complaints, whether the cause is a flapping uplink, a misbehaving optimizer or someone else announcing your space.
- Financial and credential theft: Hijacks have been used to redirect DNS and web traffic, as in the 2018 attack on Amazon Route 53 space that sent cryptocurrency users to a fake wallet site.
- Outages caused by others: Route leaks from third parties, like the 2019 incident where an optimizer's more-specific routes leaked through a large US carrier, can blackhole your traffic with no change on your side.
- Baseline for investigations: Knowing your normal daily update volume lets you tell an attack from routine noise when an alert finally fires.
- Board-level risk: Regulators and customers increasingly ask whether you publish ROAs and monitor routing, especially for financial services and DNS operators.
How to read the results
- Total Updates: Announcements plus withdrawals involving the ASN's prefixes, summed over the last seven days as seen by RIS collectors.
- Avg / Day: Total updates divided by the number of days returned; compare it with your own history rather than with other networks.
- Risk Level: High above 1,000 updates per day, Medium above 200, Low otherwise. It measures instability, not proof of a hijack: a large transit network is legitimately noisy and a quiet ASN can still be hijacked.
- Daily breakdown: The most recent days of activity, useful for pinpointing when churn started and correlating it with maintenance windows.
- Sample incidents table: Illustrative hijack and leak rows with hijacker, victim, prefix, confidence and status; use them to learn the vocabulary, not as evidence about the ASNs listed.
Technical background
BGP has no built-in way to verify that a network is entitled to announce a prefix, so routers believe what neighbors tell them unless filters say otherwise. A prefix hijack happens when an AS originates space it does not hold. If it announces the exact same prefix, only part of the Internet prefers the bogus route, depending on path length and local policy. If it announces a more-specific, longest-prefix matching sends nearly everyone to the hijacker. The canonical example is February 2008: Pakistan Telecom (AS17557) originated 208.65.153.0/24, a more-specific of YouTube's 208.65.152.0/22, meant to block the site domestically. Its upstream PCCW (AS3491) propagated it, and YouTube was unreachable worldwide for roughly two hours until the route was withdrawn.
Hijacks can be targeted and short. In April 2018 AS10297 announced more-specifics of Amazon Route 53 address space for about two hours. Resolvers that followed those routes received forged DNS answers for myetherwallet.com pointing to a phishing server, and attackers stole roughly USD 150,000 in ether from users who clicked through a certificate warning. Path manipulation is subtler: a forged-origin hijack puts the legitimate origin ASN at the end of a fake path, so origin validation alone does not catch it.
Route leaks are a different failure, defined in RFC 7908 as propagation of an announcement beyond its intended scope, typically a customer re-advertising routes learned from one provider or peer to another provider. RFC 7908 lists six types; the most damaging, type 1, is the hairpin through a multihomed customer. In June 2019 more-specific routes generated by a BGP optimizer at a small US network leaked through a customer link to Verizon, which accepted and propagated them, pulling traffic for major content networks through a path that could not carry it. RFC 9234 adds BGP roles and the Only-To-Customer attribute so that routers can detect and stop many leaks automatically.
Defense is layered. RPKI Route Origin Validation (RFC 6811) drops routes whose origin contradicts a published ROA and stops most origin hijacks, provided ROAs avoid loose maxLength values (RFC 9319). ASPA, still an IETF draft, lets an AS publish its authorized providers so routers can detect forged paths and many leaks. IRR-based prefix filters on customer sessions catch accidents early. Monitoring closes the loop: RIS and similar collector projects publish every update they receive, and watching your own prefixes and update volume reveals unexpected origins, new more-specifics or abnormal churn within minutes.
This page's risk level is deliberately simple: it flags volume, not intent. Treat a High reading as a prompt to inspect which prefixes changed and who originated them, then confirm with an RPKI check and a prefix-level view.
Common errors and how to fix them
- Problem Reading a High risk level as proof that the ASN is being hijacked.
- Fix Check which prefixes generated the updates and who originated them with a prefix lookup and routing history; high churn is usually flapping links, traffic engineering or a large customer base, not an attack.
- Problem Publishing ROAs with maxLength /24 on a /20 'just in case', which lets an attacker announce any /24 with your ASN as forged origin.
- Fix Set maxLength equal to the prefix length you actually announce, and create separate ROAs for each more-specific you really originate, as RFC 9319 recommends.
- Problem Announcing only a large aggregate, so a hijacker's more-specific wins everywhere.
- Fix For critical services such as DNS, consider originating the /24 (IPv4) or /48 (IPv6) that contains them, covered by an exact ROA, so a hijacker cannot outbid you on prefix length.
- Problem Accepting any prefix from customers on BGP sessions.
- Fix Build per-customer prefix filters from IRR route objects and RPKI ROAs, with tools like bgpq4, and regenerate them automatically; reject RPKI-invalid routes on all eBGP sessions.
- Problem No one watches routing until customers complain.
- Fix Monitor your own prefixes for new origins, new more-specifics and visibility drops using public collector data, and alert the NOC on changes rather than on volume alone.
Do it from the command line
macOS
# Seven days of update activity for an ASN from RIPEstat
curl -s "https://stat.ripe.net/data/bgp-update-activity/data.json?resource=AS13335&starttime=2026-10-01&endtime=2026-10-08" | python3 -m json.tool | head -40
# Current origin(s) of a prefix
curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=1.1.1.0/24" | python3 -m json.tool | grep -A3 '"asns"'Windows
# Does the observed origin match the ROA?
(Invoke-RestMethod "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS13335&prefix=1.1.1.0/24").data.status
# Who originated the prefix over the last weeks
(Invoke-RestMethod "https://stat.ripe.net/data/routing-history/data.json?resource=1.1.1.0/24").data.by_origin | Select-Object originLinux
# Download a 5-minute RIS update dump and search for a prefix (needs bgpdump)
curl -sO https://data.ris.ripe.net/rrc00/2026.10/updates.20261010.1200.gz
bgpdump -m updates.20261010.1200.gz | grep '|208.65.152.0/22|'
# Validate origin from your own validator
routinator validate --asn AS13335 --prefix 1.1.1.0/24Frequently asked questions
What is the difference between a BGP hijack and a route leak?
A hijack is an announcement of address space by a network that is not authorized to originate it, either by mistake or on purpose. A route leak, defined in RFC 7908, involves legitimate routes that are propagated where they should not go, such as a customer passing routes from one provider to another. Both divert traffic, but they need different defenses: ROV for hijacks, roles and ASPA for leaks.
Would RPKI have prevented the YouTube and Route 53 incidents?
Largely yes, if the victims had published ROAs and enough networks had enforced Route Origin Validation. Both attacks used more-specific prefixes with the wrong origin ASN, which ROV marks invalid. A careful attacker could still forge the legitimate origin at the end of the path; that variant is what ASPA and path validation are designed to catch, and why ROV is necessary but not sufficient.
How can I tell if my prefix is being hijacked right now?
Look at the current origin ASNs and more-specific routes for your prefixes as seen by public collectors, and compare them with what you announce. An unknown origin, a more-specific you did not create, or a sudden drop in the number of peers seeing your route are the key signals. Confirm with traceroutes from external vantage points and contact the offending network's upstreams.
What should I do during an active hijack?
Announce more-specifics of the affected space if your ROAs allow it, to win back traffic by longest match. At the same time, contact the hijacking network's NOC and its upstream providers, ideally through PeeringDB contacts or operator mailing lists, and ask them to filter the route. Make sure your ROAs are correct so validating networks drop the bad announcement automatically.
Why is the incidents table labeled sample data?
Detecting hijacks reliably requires continuous processing of the full update stream from many collectors plus knowledge of each network's legitimate origins and relationships. The table illustrates the fields such a detector would report. The live part of this page is the per-ASN update activity, which measures routing churn from RIPEstat and helps you spot anomalies worth investigating.