BGP hijacking as a DDoS vector:
route leaks, prefix hijacks, and traffic blackholes

Back to Blog

How BGP Hijacking Causes Denial of Service

The Border Gateway Protocol (BGP) is the routing protocol that holds the internet together. Every autonomous system (AS) on the internet uses BGP to announce its IP prefixes to its neighbors, who propagate those announcements to their neighbors, until the entire global routing table converges on a consistent view of how to reach every destination on the internet.

The problem is that BGP was designed in an era of implicit trust. When an AS announces a prefix, its neighbors generally accept the announcement at face value. There is no built-in mechanism to verify that the announcing AS actually owns or is authorized to announce that prefix. This trust model creates three distinct attack vectors that produce denial-of-service outcomes.

Prefix hijack: traffic redirected to a blackhole

In a prefix hijack, an attacker (or a misconfigured router) announces your IP prefix from their own AS. If their announcement is accepted by upstream providers and propagates through the global routing table, some portion of internet traffic destined for your network will be routed to the attacker's AS instead. From the perspective of your users, your services are unreachable. Their packets are being sent to a network that either drops them silently (a blackhole) or responds with unexpected content.

The attacker does not need to announce your exact prefix. They can announce a more-specific prefix, which BGP will always prefer due to longest-prefix match routing. If you announce 198.51.100.0/23, an attacker can announce 198.51.100.0/24 and 198.51.101.0/24 separately. Every router on the internet will prefer the /24 announcements over your /23, because more-specific prefixes always win in BGP path selection.

# Your legitimate announcement
AS 64500 announces: 198.51.100.0/23

# Attacker's more-specific hijack
AS 66666 announces: 198.51.100.0/24
AS 66666 announces: 198.51.101.0/24

# Result: all traffic follows the /24 routes to AS 66666
# Your /23 announcement is shadowed globally

Route leak: congestion and suboptimal paths

A route leak occurs when an AS announces routes it has learned from one provider to another provider (or peer) in violation of its routing policy. The leaked routes may cause traffic to take suboptimal paths through networks that lack the capacity to handle it, creating congestion-induced denial of service.

Unlike a prefix hijack, a route leak does not steal your prefix. Instead, it causes traffic destined for your network to take a longer, less optimal path that may traverse congested links, adding latency and packet loss. In severe cases, the leaked routes can attract so much traffic to an unprepared transit path that the intermediate network becomes congested, creating a cascading failure that affects not just your traffic but all traffic transiting that path.

More-specific announcement: partial traffic theft

Even without malicious intent, a more-specific prefix announcement from any AS will attract traffic away from your less-specific announcement. This is particularly dangerous when a downstream customer of yours accidentally announces one of your prefixes to their other upstream providers. The more-specific route propagates globally, and suddenly a portion of your traffic is flowing through a path you did not intend, potentially through links that cannot handle the volume.

The distinction between accidental and intentional BGP hijacking is important operationally but irrelevant to the victim. Whether your prefix was hijacked by a state-sponsored actor or by a junior network engineer who fat-fingered a route filter, the result is the same: your traffic is going to the wrong place and your services are unreachable.

Real-World BGP Hijacking Incidents

BGP hijacking is not a theoretical risk. It has caused major outages and traffic diversions repeatedly throughout the internet's history.

Pakistan Telecom and YouTube (2008)

In February 2008, Pakistan Telecom attempted to block YouTube within Pakistan by announcing a more-specific route for YouTube's IP prefix (208.65.153.0/24) to a null interface. The announcement should have stayed within Pakistan's borders, but a misconfiguration caused it to leak to Pakistan Telecom's upstream provider, PCCW. From there, it propagated globally. For approximately two hours, YouTube was unreachable for a significant portion of the world's internet users because their traffic was being routed to Pakistan Telecom's null interface instead of YouTube's actual servers.

Pakistan Telecom announced 208.65.153.0/24, which was more specific than YouTube's 208.65.152.0/22. Longest-prefix match ensured the hijacked route won everywhere it propagated. The fix required YouTube to announce its own /24 prefixes to compete with the hijack, and it required PCCW to filter Pakistan Telecom's announcement. The incident lasted approximately two hours and demonstrated how a single misconfigured router in one country can cause a global denial-of-service event.

Rostelecom incidents (2020)

In April 2020, Rostelecom (AS12389) announced more-specific prefixes belonging to major cloud and CDN providers, including Akamai, Cloudflare, Amazon, and several other companies. The announcements were accepted by multiple upstream providers and propagated to significant portions of the internet, redirecting traffic that should have gone directly to these providers through Rostelecom's network instead.

The incident lasted approximately one hour. While Rostelecom attributed it to an internal traffic engineering error that accidentally leaked to external peers, security researchers noted that the affected prefixes belonged specifically to companies that handle large volumes of sensitive internet traffic, raising questions about whether the incident was truly accidental.

China Telecom route leaks

China Telecom (AS4134) has been involved in multiple route leak incidents over the years, most notably in 2010 and 2019. In the 2010 incident, China Telecom briefly attracted approximately 15% of the internet's routes through its network by announcing more-specific prefixes for thousands of IP ranges belonging to networks worldwide. The 2019 incident involved more-specific announcements for European mobile operators' prefixes, redirecting traffic through China Telecom's network for several hours.

These incidents highlight a persistent challenge: even if each individual route leak is short-lived, the cumulative effect of repeated incidents from large transit providers erodes confidence in BGP routing and creates recurring denial-of-service conditions for the affected networks.

Accidental vs Intentional Hijacks

Understanding the distinction between accidental route leaks and intentional hijacks is important for developing appropriate detection and response strategies.

Accidental route leaks

The majority of BGP hijacking events are accidental. Common causes include:

• Missing or incorrect route filters: A network operator forgets to apply an outbound prefix filter to a BGP session, causing internally learned routes to leak to external peers.
• Route optimizer misconfiguration: Automated traffic engineering tools announce prefixes through unintended paths to optimize cost or latency, but the announcements escape their intended scope.
• Fat-finger errors: An engineer manually configuring a BGP session enters the wrong prefix, AS path, or community, causing an unintended announcement.
• Software bugs: Router software bugs have caused routers to announce prefixes from their full routing table, effectively hijacking thousands of prefixes simultaneously.

Accidental leaks typically have shorter durations because the operator notices the problem (often because they receive complaints) and corrects it. However, detection can still take minutes to hours, during which the affected traffic is misrouted.

Intentional hijacks

Intentional BGP hijacks are less common but more dangerous. They fall into several categories:

• Cryptocurrency theft: Hijacking the prefixes of cryptocurrency exchanges or DNS providers to redirect users to phishing sites or to intercept API traffic. The 2018 hijack of Amazon Route 53 DNS servers to steal cryptocurrency from MyEtherWallet users is a notable example.
• Traffic interception: Routing traffic through an attacker-controlled network for surveillance or data collection purposes. The hijacker announces the victim's prefix, receives their traffic, inspects or modifies it, and forwards it to the legitimate destination. This "man-in-the-middle" BGP attack is difficult to detect because the end user's traffic still reaches its destination, just with slightly higher latency.
• Denial of service: Intentionally hijacking a target's prefixes to cause service disruption. This is particularly effective against targets whose DDoS mitigation relies on BGP announcements (more on this below).
• Spam and abuse: Hijacking unused IP space to send spam, launch attacks, or host malicious content from IP addresses that cannot be traced back to the attacker.

RPKI and ROA: The Primary Defense

Resource Public Key Infrastructure (RPKI) is the primary defense mechanism against BGP prefix hijacking. RPKI allows IP address holders to cryptographically sign Route Origin Authorizations (ROAs) that specify which AS numbers are authorized to announce their prefixes.

How RPKI works

An ROA is a signed object that states: "Prefix X.X.X.X/Y is authorized to be originated by AS Z, with a maximum prefix length of /W." When a network operator creates an ROA and publishes it in the RPKI repository, any BGP router performing Route Origin Validation (ROV) can check incoming BGP announcements against the published ROAs.

# Example ROA
Prefix:      198.51.100.0/23
Max Length:  /24
Origin AS:   64500

# Validation outcomes for incoming BGP announcements:
198.51.100.0/23 from AS 64500  =>  VALID
198.51.100.0/24 from AS 64500  =>  VALID (within max length)
198.51.100.0/23 from AS 66666  =>  INVALID (wrong origin AS)
198.51.100.0/25 from AS 64500  =>  INVALID (exceeds max length)
198.51.100.0/23 with no ROA    =>  NOT FOUND (no ROA exists)

What RPKI protects against

• Origin AS spoofing: If an attacker announces your prefix from their AS, the announcement will be marked INVALID because the origin AS does not match your ROA.
• More-specific prefix hijacks: If your ROA specifies a maximum prefix length, announcements of more-specific prefixes beyond that length will be marked INVALID regardless of origin AS.
• Accidental origination: Misconfigured routers that accidentally announce your prefix from the wrong AS will be caught by ROV.

What RPKI does not protect against

• AS path manipulation: RPKI validates only the origin AS, not the full AS path. An attacker can prepend your legitimate origin AS to their hijack announcement, making it appear valid. This is called a "forged-origin" attack.
• Route leaks: If a legitimate AS with a valid ROA re-announces your prefix to peers it should not, RPKI will not flag it because the origin AS is correct. Route leaks violate routing policy, not origin authorization.
• Networks that do not enforce ROV: RPKI only works if BGP routers along the path actually perform ROV and reject INVALID routes. As of 2026, approximately 40% to 50% of the internet's transit capacity performs ROV, which means a hijack announcement can still propagate through non-validating networks.
• Sub-prefix hijacks within max-length: If your ROA allows /24 max-length and an attacker announces your /24 from your AS (by forging the origin), RPKI will mark it as valid.

RPKI is necessary but not sufficient. It stops the most common and most damaging class of hijacks (wrong-origin announcements), but it does not protect against route leaks or sophisticated forged-origin attacks. A layered defense that combines RPKI with active BGP monitoring is required for comprehensive protection.

BGP Monitoring Tools

Active monitoring of the global routing table is essential for detecting hijacks and route leaks that RPKI alone cannot prevent. Several public and commercial tools provide visibility into BGP routing from multiple vantage points around the internet.

RIPE RIS (Routing Information Service)

RIPE NCC operates the RIS project, which collects BGP routing data from over 600 peers at 27 route collectors worldwide. RIS provides real-time visibility into global BGP announcements and withdrawals through its RISwhois and RIS Live APIs. Network operators can set up alerts for changes to their prefixes using RIPE's BGP monitoring tools.

RouteViews

The University of Oregon's RouteViews project maintains a network of route collectors at major internet exchange points worldwide. RouteViews archives historical BGP data and provides real-time access to the global routing table from multiple vantage points. The data is freely available for research and operational monitoring.

BGPStream

BGPStream, developed by CAIDA (Center for Applied Internet Data Analysis), provides a unified interface for consuming real-time and historical BGP data from both RIPE RIS and RouteViews. Its companion tool, BGPAlerter, can be configured to send notifications when your prefixes are announced by unexpected ASes, when new more-specific prefixes appear, or when AS path changes suggest a hijack or leak.

# BGPAlerter configuration for prefix monitoring
prefixes:
  - prefix: "198.51.100.0/23"
    description: "Production network"
    asn: [64500]
    ignoreMorespecifics: false

# Alert channels
alerts:
  slack:
    webhook: "https://hooks.slack.com/services/XXX/YYY/ZZZ"
  email:
    smtp_host: "smtp.example.com"
    recipients: ["noc@example.com"]

Commercial BGP monitoring

Several commercial services provide enhanced BGP monitoring with features like anomaly scoring, historical analysis, and integration with incident response workflows. These include Kentik's BGP monitoring, ThousandEyes (now part of Cisco), and Qrator.Radar. The advantage of commercial tools is typically faster alerting, more sophisticated anomaly detection, and dedicated support for incident response.

Detecting If Your Prefixes Are Being Hijacked

Detecting a BGP hijack affecting your network requires combining multiple signals. No single indicator is definitive, but together they can confirm a hijack and help determine its scope and origin.

Routing table anomalies

Monitor for unexpected changes in how your prefixes appear in the global routing table:

• New origin AS: Your prefix is being announced from an AS that you did not authorize. This is the most obvious indicator of a hijack.
• Unexpected more-specific prefixes: Sub-prefixes of your allocation appear in the global table that you did not announce. This suggests a more-specific hijack.
• AS path changes: The AS paths seen at route collectors change unexpectedly, with new intermediate ASes appearing or the path length changing significantly.
• Multiple origins (MOAS): Your prefix is simultaneously announced from multiple origin ASes. While MOAS can be legitimate (anycast, CDNs), an unexpected MOAS condition often indicates a hijack.

Traffic anomalies

BGP hijacks produce observable effects on your traffic patterns:

• Sudden drop in inbound traffic: If a significant portion of your traffic is being redirected to a hijacker, you will see a corresponding drop in traffic volume. The drop may be partial (only traffic from certain geographic regions or transit paths is affected) or near-total (if the hijack propagated globally).
• Increased latency from specific regions: Route leaks that do not fully hijack your prefix but cause traffic to take suboptimal paths will manifest as latency increases from affected regions.
• Unreachability reports: Users in affected regions report that your services are unreachable or experiencing errors. The reports will be geographically correlated with the scope of the hijack propagation.

Verification steps

When you suspect a hijack, perform these verification steps:

1. Check looking glasses: Use route looking glass servers (e.g., lg.he.net, RIPE RIS looking glass) to view how your prefix is being seen from multiple vantage points. Identify which ASes see the legitimate route versus the hijacked route.
2. Query RPKI status: Verify that your ROAs are correctly published and check whether the hijacking announcement would be marked INVALID by ROV-enforcing networks.
3. Run traceroutes from external vantage points: Use RIPE Atlas or commercial traceroute services to trace the path to your prefix from multiple locations. Hijacked traffic will follow a different path than expected.
4. Contact your upstream providers: Alert your transit providers to the hijack and request that they filter the offending announcement. Most providers have procedures for handling hijack incidents.

BGP Security and DDoS Mitigation: The Critical Connection

Here is where BGP hijacking and DDoS defense intersect in a way that most organizations do not consider: your DDoS mitigation infrastructure relies on BGP to function. If your BGP announcements can be hijacked, your DDoS mitigation can be undermined.

Your mitigation BGP announcements are a target

When Flowtriq or any BGP-based DDoS mitigation system activates RTBH or FlowSpec rules, it does so by sending BGP announcements to your upstream routers. These announcements instruct the network to filter or blackhole attack traffic. If an attacker can hijack the prefixes involved in these announcements, they can effectively disable your mitigation.

Consider this scenario: you are under a volumetric DDoS attack and your mitigation system activates RTBH for the targeted /32 prefix. The RTBH announcement propagates to your upstream providers, and attack traffic is dropped at the edge. The attacker, seeing that the attack is being mitigated, then hijacks the /32 prefix from a different AS. Some transit providers now see two conflicting announcements for the same prefix: your RTBH community-tagged announcement and the attacker's hijack. The result is unpredictable: some providers may follow the hijack route, effectively routing the attack traffic back toward your network and bypassing the RTBH protection.

Cloud scrubbing depends on BGP integrity

Cloud-based DDoS scrubbing services work by announcing your prefixes from their scrubbing network via BGP, attracting your traffic to their scrubbing centers where it is cleaned and forwarded to your origin. If the scrubbing provider's BGP announcements are hijacked or if the BGP path between the scrubbing center and your origin is disrupted, the entire scrubbing pipeline fails.

FlowSpec rules require trusted BGP sessions

FlowSpec rules are distributed via BGP update messages. If an attacker can inject false FlowSpec rules into your BGP sessions (through session hijacking, BGP session reset attacks, or by compromising a router in the path), they can deploy filtering rules that block legitimate traffic. This turns your own mitigation infrastructure into a denial-of-service tool against you.

Your DDoS mitigation is only as reliable as the BGP infrastructure it depends on. Securing your BGP sessions and protecting your prefix announcements is not separate from DDoS defense; it is a prerequisite for DDoS defense.

Defending Your BGP Infrastructure

A comprehensive BGP security posture combines multiple layers of defense. No single measure is sufficient, but together they significantly reduce the risk and impact of BGP hijacking.

• Deploy RPKI ROAs for all your prefixes. This is the single most impactful step you can take. Create ROAs that specify your authorized origin AS and an appropriate max-length. Ensure ROAs are kept up to date as your prefix allocations change.
• Enable BGP session security. Use TCP-AO (RFC 5925) or MD5 authentication (RFC 2385) on all BGP sessions. Configure GTSM (Generalized TTL Security Mechanism, RFC 5082) to prevent remote TCP reset attacks on BGP sessions.
• Implement strict prefix filters. Configure outbound prefix filters on all eBGP sessions to ensure you only announce prefixes you are authorized to announce. Configure inbound filters to limit what you accept from peers and customers.
• Monitor your prefixes with BGP alerting tools. Use BGPAlerter, RIPE RIS, or a commercial monitoring service to detect unauthorized announcements of your prefixes in real time.
• Announce the most specific prefixes allowed. If you announce /23, also announce the component /24s. This prevents more-specific hijacks from stealing your traffic (the attacker cannot announce a /25 if your /24 is already the most specific announcement in the table and most providers filter /25 and longer).
• Register in IRR databases. Maintain accurate Internet Routing Registry (IRR) entries for your prefixes and AS. Many transit providers use IRR data to build prefix filters. Accurate IRR entries help ensure your legitimate announcements are accepted and unauthorized ones are filtered.
• Coordinate with upstream providers. Establish out-of-band communication channels with your transit providers' NOCs. In the event of a hijack, you need to be able to quickly contact them to request filtering of the offending announcement.

How Flowtriq Accounts for BGP Security

Flowtriq's BGP mitigation engine relies on correct BGP operation to deliver mitigation rules to your upstream routers. This means BGP security is a direct dependency of Flowtriq's mitigation effectiveness. Several design decisions in Flowtriq's architecture account for this reality.

First, Flowtriq's agent-based detection is independent of BGP. The detection layer runs directly on your servers, monitoring traffic at the kernel level. Even if your BGP sessions are compromised, detection continues to function. You will still know you are under attack, even if the mitigation path is disrupted.

Second, Flowtriq's 4-tier escalation provides fallback mitigation that does not depend on BGP. Tier 1 (host-level firewall rules) operates entirely locally and is unaffected by any BGP issue. If BGP-based mitigation (Tiers 2 and 3) is unavailable due to a BGP session issue or hijack, Tier 1 can still reduce the impact of attacks within the server's capacity.

Third, Flowtriq logs all BGP interactions in its audit trail. Every FlowSpec rule injected, every RTBH announcement sent, and every BGP session state change is recorded with timestamps. If a BGP issue causes mitigation to fail, the audit trail provides the forensic data needed to diagnose the problem and coordinate with upstream providers.

For operators who want to integrate BGP monitoring with their DDoS defense, Flowtriq's webhook alerting can be combined with BGPAlerter or RIPE RIS notifications to create a unified alerting pipeline that covers both DDoS attacks and BGP anomalies affecting your prefixes.

Getting Started

BGP security and DDoS defense are two sides of the same coin. Your mitigation is only as reliable as the BGP infrastructure it depends on, and your BGP infrastructure is only as secure as the monitoring and validation you put around it.

Start with the basics: deploy RPKI ROAs for all your prefixes, set up BGP monitoring alerts using BGPAlerter or RIPE RIS, and ensure your outbound prefix filters are correctly configured. These steps protect both your normal traffic routing and your ability to deploy BGP-based DDoS mitigation when you need it.

Flowtriq's agent-based detection provides the DDoS defense layer that integrates with your BGP infrastructure, adding per-second attack detection and automated FlowSpec and RTBH mitigation. Get started with a free 7-day trial to deploy agents on your network and validate the full detection-to-mitigation pipeline.

Back to Blog

Related Articles