The Rostelecom BGP Hijacks (2020)

On April 1, 2020, Rostelecom (AS12389) -- Russia's state-owned telecommunications provider -- began announcing more-specific BGP prefixes for over 200 networks including Google, Amazon, Cloudflare, Facebook, Akamai, and Apple. For approximately one hour, traffic destined for some of the world's largest internet services was rerouted through Russian infrastructure. This was not an isolated event -- Rostelecom had prior hijacking incidents in 2017 and 2019 -- and it reignited the debate about whether BGP hijacks by state-backed operators represent genuine misconfigurations or deliberate surveillance capability testing.

What Happened on April 1, 2020

At approximately 19:28 UTC on April 1, 2020, BGP route collectors observed AS12389 (Rostelecom) originating prefixes belonging to more than 200 autonomous systems. The hijacked prefixes were more-specific routes -- longer prefix lengths that override the legitimate, less-specific announcements from the actual owners under BGP's longest prefix match rule.

Among the affected networks:

• Google (AS15169) -- including prefixes covering Google Cloud and Google DNS infrastructure
• Amazon / AWS (AS16509) -- including Amazon CloudFront CDN ranges
• Cloudflare (AS13335) -- including ranges serving millions of websites
• Facebook / Meta (AS32934) -- social media and messaging infrastructure
• Akamai (AS20940) -- one of the world's largest CDN providers
• Apple (AS714) -- iCloud, App Store, and other Apple services
• Microsoft (AS8075) -- Azure and Office 365 infrastructure
• Netflix (AS2906) -- streaming infrastructure
• Over 200 additional CDN, cloud, and content providers

The hijack lasted roughly one hour before the illegitimate announcements were withdrawn. During this window, traffic from networks that accepted these routes was diverted through Rostelecom's infrastructure in Russia before potentially being forwarded to the legitimate destination -- or dropped entirely.

The Mechanics: More-Specific Prefix Hijacking

The technique Rostelecom used is the most effective form of BGP hijacking: announcing more-specific prefixes. Here is why it works.

BGP routers select routes using the longest prefix match rule. If a router's table contains both 8.8.0.0/16 (from Google) and 8.8.8.0/24 (from Rostelecom), any packet destined for an address in 8.8.8.0/24 will follow the /24 route -- because it is more specific. The legitimate /16 announcement, while still present, is simply not consulted for addresses that fall within the hijacked /24.

This makes more-specific hijacks particularly dangerous:

• They do not require the hijacker to be topologically closer to the victim
• They override the legitimate route everywhere the hijacked announcement propagates
• The legitimate origin AS often has no immediate visibility into the hijack -- its own announcement remains in the routing table, just overshadowed
• Mitigation requires either filtering the hijacked route at upstream providers or the hijacker withdrawing the announcement

In Rostelecom's case, the hijacked prefixes were typically /24s covering portions of larger blocks announced by the affected providers. Because most networks globally filter prefixes longer than /24 for IPv4, the /24 was the most specific route Rostelecom could announce and still have it propagate widely.

Scale and Scope of the Attack

What set the April 2020 incident apart from typical BGP hijacks was its sheer scale. Over 200 distinct autonomous systems were affected simultaneously. BGPStream, RIPE RIS, and multiple independent monitoring services detected the anomaly within minutes.

The affected networks read like a directory of the internet's critical infrastructure:

• Cloud providers: AWS, Google Cloud, Microsoft Azure, DigitalOcean, Linode, OVH
• CDNs: Akamai, Cloudflare, Fastly, StackPath, KeyCDN
• Content platforms: Facebook, Netflix, Twitch, Hulu, Riot Games
• DNS providers: Cloudflare DNS, Google Public DNS, Quad9
• Security firms: Symantec, Fortinet, Palo Alto Networks
• Payment processors and banks: Visa and financial infrastructure ranges

The breadth of affected prefixes suggested this was not a simple fat-finger misconfiguration of one or two routes. The hijacked prefixes spanned diverse address ranges belonging to unrelated organizations across multiple continents.

Rostelecom's History of BGP Incidents

The April 2020 hijack was not Rostelecom's first. The company, which is majority-owned by the Russian government and serves as the country's largest telecommunications provider, has a documented pattern of BGP anomalies:

2017: Financial Services Hijack

In April 2017, Rostelecom hijacked prefixes belonging to several major financial institutions, including Visa, Mastercard, and HSBC. Traffic destined for these networks was routed through Rostelecom's infrastructure for approximately seven minutes. The hijacked prefixes were again more-specific routes, and the incident affected payment processing networks during business hours. BGPMon and Oracle's Internet Intelligence team documented the event.

2019: Google Traffic Rerouted

In November 2019, Google (AS15169) traffic was rerouted through Rostelecom for roughly one hour. The incident primarily affected users in parts of Asia and Europe. Traffic to Google services -- including search, Gmail, and YouTube -- traversed Russian infrastructure before reaching its intended destination. Google confirmed the anomaly but did not attribute intent.

2020: The 200+ Network Incident

The April 2020 event was by far the largest. The number of affected networks jumped from a handful in prior incidents to over 200, suggesting either a more ambitious operation or a more catastrophic misconfiguration -- depending on which explanation one finds credible.

This pattern of repeated incidents involving a state-controlled provider, each growing in scope, is what makes the Rostelecom case particularly significant in the history of BGP security.

Accident or Intentional? The Debate

Rostelecom's official explanation was that the hijack resulted from an internal traffic optimization system that accidentally leaked routes to the global internet. According to the company, a system designed to manage internal traffic engineering announced the prefixes to external peers due to a software error.

This explanation has both supporters and skeptics in the network operations community.

The Case for Accidental Misconfiguration

• Internal route leaks happen. Large ISPs routinely maintain internal more-specific routes for traffic engineering purposes. If the boundary between internal and external BGP is misconfigured, these routes can leak to the global table. This is a well-documented class of BGP incident.
• The duration was short. One hour is consistent with an operator detecting and correcting a misconfiguration, rather than the sustained duration one might expect from a deliberate interception operation.
• No evidence of traffic manipulation. Public analysis did not reveal evidence that intercepted traffic was modified, decrypted, or selectively dropped -- though absence of evidence is not evidence of absence, especially since most traffic to the affected providers uses TLS encryption.

The Case for Intentional Activity

• Repeat offender. Three major hijack incidents in four years from the same state-owned provider stretches the "accident" explanation. Most network operators who experience one accidental leak implement safeguards to prevent recurrence.
• Target selection. The affected networks were overwhelmingly major cloud, CDN, and content providers -- precisely the targets a state intelligence apparatus would want to intercept or monitor. Random misconfigurations tend to affect geographically or topologically adjacent prefixes, not a curated list of high-value targets.
• State ownership. Rostelecom is majority-owned by the Russian government through Rosimushchestvo (Federal Agency for State Property Management). Russia's intelligence services have demonstrated sophisticated signals intelligence capabilities, and BGP interception is a known technique.
• Capability testing. Some researchers suggested the hijack was a rehearsal -- testing the ability to reroute traffic at scale and measuring how quickly it would be detected and mitigated. Even if no traffic was exploited during the incident, the data gathered about propagation speed, detection latency, and affected routes would be valuable for planning a future operation.

The truth may never be definitively established. What is clear is that the incident demonstrated the feasibility of large-scale traffic interception through BGP manipulation by a state-backed operator.

Technical Impact: What Happens to Hijacked Traffic

When a BGP hijack succeeds, the hijacker's network receives traffic that was meant for the legitimate destination. The hijacker then has several options:

• Blackhole. Simply drop the traffic. This creates an outage for the affected services. Users see connection timeouts and failures.
• Inspect and forward. Perform deep packet inspection on the traffic, then forward it to the legitimate destination via a path the hijacker knows. This is harder to detect because services still appear to work -- just with slightly higher latency. However, modern TLS encryption means the hijacker can see metadata (IP addresses, server names via SNI, traffic volumes, timing) but not the encrypted payload.
• Man-in-the-middle. For unencrypted traffic (HTTP without TLS, DNS without DoH/DoT, certain legacy protocols), the hijacker can read and modify data in transit. For encrypted traffic, the hijacker could attempt certificate-based attacks, though this requires a compromised or rogue certificate authority.

During the April 2020 Rostelecom incident, monitoring services observed that some hijacked traffic was being forwarded to the legitimate destination after passing through Rostelecom's network. This "pass-through" behavior is more consistent with an interception scenario than a simple blackhole, though it could also result from a misconfigured system that happened to have routes to the real destinations.

Detection and Response

The hijack was detected within minutes by multiple BGP monitoring services:

• BGPStream / CAIDA flagged the sudden appearance of hundreds of new more-specific prefixes from AS12389
• RIPE RIS route collectors recorded the illegitimate announcements across multiple vantage points
• Kentik, Qrator, and BGPMon issued alerts to affected customers
• Cloudflare and other affected operators observed the anomaly in their own BGP monitoring systems

However, detection is not the same as mitigation. Even after the hijack was identified, remediation required Rostelecom to withdraw the routes. Networks that had deployed RPKI Route Origin Validation were partially protected -- they could reject the hijacked announcements because the routes were RPKI-invalid (the ROA for those prefixes specified a different origin AS). But in April 2020, RPKI adoption was still limited, and many networks were not performing route origin validation.

The incident resolution timeline:

• T+0 minutes -- Rostelecom begins announcing hijacked prefixes
• T+2-5 minutes -- BGP monitoring services detect the anomaly
• T+5-15 minutes -- Alerts sent to affected network operators
• T+30-60 minutes -- Rostelecom withdraws the hijacked announcements
• T+60-90 minutes -- BGP convergence restores normal routing globally

Why RPKI Could Have Prevented This

RPKI is the primary defense against origin-based BGP hijacks. If every network along the path had enforced RPKI Route Origin Validation, the Rostelecom hijack would have been automatically rejected.

Here is why: each of the affected providers (Google, AWS, Cloudflare, etc.) had published Route Origin Authorizations (ROAs) specifying that only their AS was authorized to originate their prefixes, with a maximum prefix length. When Rostelecom announced those same prefixes with AS12389 as the origin, any router performing ROV would have marked those routes as RPKI Invalid and dropped them.

The problem in 2020 was twofold:

• Incomplete ROA coverage. Not all affected providers had published ROAs for all of their prefixes.
• Limited ROV enforcement. Even when ROAs existed, many transit networks and ISPs were not yet performing route origin validation. A route marked RPKI-invalid at one network could still propagate through another that did not check.

Since 2020, RPKI adoption has accelerated dramatically. Major transit providers including Lumen (AS3356), NTT (AS2914), and Arelion (AS1299) now perform ROV. Cloud and CDN providers have expanded their ROA coverage. But gaps remain, and RPKI only validates the origin AS -- it does not verify the full AS path, leaving room for more sophisticated path manipulation attacks.

The Broader Problem: State-Level BGP Threats

The Rostelecom incident is part of a broader pattern of state-affiliated BGP anomalies that have been documented over the past two decades:

• China Telecom (AS4134, AS4809) -- Multiple documented incidents of US government, military, and financial traffic being rerouted through China. A 2018 paper by researchers at the US Naval War College and Tel Aviv University documented systematic BGP hijacking by China Telecom over several years.
• Pakistan Telecom (2008) -- The accidental YouTube hijack demonstrated how a domestic censorship action could cascade globally through BGP.
• Turk Telekom (2014) -- Turkish ISP redirected DNS traffic to intercept users attempting to access blocked websites.

State-level BGP threats are uniquely dangerous because:

• State-owned telecoms are large transit providers with extensive peering, meaning their BGP announcements propagate widely and quickly
• They have the infrastructure and expertise to perform sophisticated traffic interception at scale
• Political and legal accountability is limited compared to private operators
• They may have access to compromised certificate authorities for TLS interception
• Attribution is difficult -- it is always plausible to claim misconfiguration

MANRS and Industry Response

The Rostelecom hijack gave renewed urgency to MANRS (Mutually Agreed Norms for Routing Security), an industry initiative coordinated by the Internet Society. MANRS participants commit to four actions:

1. Filtering -- Preventing propagation of incorrect routing information by validating BGP announcements against IRR (Internet Routing Registry) data and RPKI
2. Anti-spoofing -- Preventing traffic with spoofed source IP addresses from leaving the network
3. Coordination -- Maintaining up-to-date contact information and responding promptly to routing incidents
4. Global validation -- Publishing routing data (ROAs, IRR entries) so others can validate announcements

As of 2025, over 1,000 network operators have joined MANRS. However, participation is voluntary, and some of the world's largest networks -- including many state-owned telecoms -- have not committed to these norms.

Beyond MANRS, the incident accelerated several concrete changes across the industry:

• Major transit providers began enforcing RPKI ROV, rejecting RPKI-invalid routes rather than merely tagging them
• Cloud and CDN providers expanded ROA coverage to ensure all their prefixes had published authorizations
• BGP monitoring tools improved, with faster detection and automated alerting for anomalous route announcements
• ASPA (Autonomous System Provider Authorization) gained momentum as a complement to RPKI, enabling validation of the full AS path rather than just the origin

Lessons for Network Operators

The Rostelecom hijack underscores several practical lessons for anyone operating an autonomous system:

• Publish ROAs for all your prefixes. If you hold IP address space, create Route Origin Authorizations through your RIR (ARIN, RIPE, APNIC, etc.). Set the maxLength field to prevent more-specific hijacks.
• Enable RPKI ROV on your routers. If you are a transit or access provider, validate incoming BGP announcements against RPKI and reject (or deprioritize) routes that are RPKI-invalid.
• Deploy BGP monitoring. Use services like RIPE RIS, BGPStream, or commercial tools to monitor your prefixes in real-time. Detect hijacks within minutes, not hours.
• Implement prefix filtering. Apply strict ingress filters on customer BGP sessions. Only accept prefixes you expect from each customer, based on their IRR registrations and RPKI.
• Join MANRS. Commit to the community norms for routing security and hold your peers accountable.
• Use TLS everywhere. While BGP-level defenses are essential, end-to-end encryption (HTTPS, DoH) protects the payload even when traffic is rerouted. A BGP hijacker who intercepts TLS-encrypted traffic can see metadata but cannot read the content.

Investigate the Networks Involved

You can explore the routing data for all the key networks involved in the Rostelecom hijack using the looking glass. Check their current BGP announcements, AS paths, RPKI status, and peering relationships:

• AS12389 -- Rostelecom: see their current prefixes and neighbors
• AS15169 -- Google: check RPKI status on Google's routes
• AS16509 -- Amazon / AWS
• AS13335 -- Cloudflare
• AS20940 -- Akamai
• 8.8.8.8 -- Look up Google DNS and verify its route origin
• 1.1.1.1 -- Look up Cloudflare DNS and verify its RPKI validation