BGP Hijacking: When the Internet’s Routing Gets Poisoned
The internet does not have a central authority that controls where traffic goes. Routing decisions are made by approximately 75,000 autonomous systems (AS) that announce their routes to each other using the Border Gateway Protocol (BGP). BGP has no authentication. Any autonomous system can announce any route, and other systems will believe it.
This means that a single malicious or misconfigured router can redirect internet traffic for entire countries, cloud providers, banks, or government agencies — and the rest of the internet will comply, forwarding traffic to the attacker without question.
This is BGP hijacking. It is the most powerful man-in-the-middle attack that exists, and it operates at the very foundation of internet routing.
How BGP works (and why it breaks)
BGP is the routing protocol of the internet. Every ISP, cloud provider, and large organization operates an autonomous system (AS) that participates in BGP. These systems announce to their neighbors: “I can reach these IP address ranges.” Neighbors propagate these announcements, and the global routing table converges so that every packet finds its way to the correct destination.
BGP was designed in 1989 for a network of a few hundred trusted operators. There was no authentication because everyone knew everyone. Thirty-seven years later, there are 75,000 autonomous systems operated by entities ranging from Fortune 500 companies to regional ISPs in every country on earth. The trust model hasn’t changed.
The hijacking mechanism
- The attacker announces a more specific route. BGP prefers more specific routes. If the legitimate AS announces 192.168.0.0/16, the attacker announces 192.168.0.0/17 and 192.168.128.0/17. These more specific routes are preferred by every router on the internet.
- Traffic is redirected. Routers worldwide update their routing tables to forward traffic through the attacker’s network.
- The attacker inspects, modifies, or drops traffic. They can passively intercept data, actively modify it, or simply black-hole it (denial of service).
- Optional: forward to real destination. Sophisticated attackers forward the traffic to the real destination after inspection, making the hijack transparent to the victim. The connection works. The data flows. But it took a detour through the attacker’s network.
Real-world BGP hijacking incidents
Pakistan Telecom vs. YouTube (2008)
Pakistan Telecom attempted to block YouTube domestically by announcing a false route for YouTube’s IP addresses. The announcement leaked beyond Pakistan’s borders and propagated globally. YouTube was unreachable worldwide for approximately two hours. This was an accidental global hijack caused by a domestic censorship attempt.
China Telecom route leaks (2010, 2019)
China Telecom repeatedly announced routes for IP prefixes belonging to US military, government, and corporate networks. Traffic destined for these networks was routed through China before reaching its destination. Whether this was intentional intelligence collection or accidental misconfiguration remains debated. The effect was the same: sensitive traffic transited through a foreign nation’s infrastructure.
MyEtherWallet cryptocurrency theft (2018)
Attackers hijacked BGP routes for Amazon’s Route 53 DNS service, redirecting DNS queries for MyEtherWallet.com to a malicious server. Users who visited the site had their cryptocurrency wallets drained. The attack combined BGP hijacking with DNS spoofing — two infrastructure-layer attacks that were invisible to application-layer security tools.
Rostelecom hijacking (2020)
Russia’s state-owned Rostelecom hijacked BGP routes for more than 200 CDNs and cloud providers, including Akamai, Cloudflare, AWS, and Google. Traffic for these providers was briefly routed through Russian infrastructure. The incident affected major websites and services worldwide.
BGP hijacking is unique among MITM attacks because it requires no proximity to the victim. The attacker can be on another continent. The attack operates at the routing infrastructure level, below every application-layer defense. And when it happens, the entire internet cooperates in redirecting the traffic.
Why BGP hijacking is a nation-state weapon
BGP hijacking requires control of an autonomous system, which limits the attack to ISPs, cloud providers, and nation-state actors. But that is a lower bar than it appears:
- AS numbers can be purchased from regional internet registries for a few hundred dollars
- Small ISPs can be compromised to announce malicious routes
- Nation-states control national ISPs directly or through regulation, giving them BGP announcement capability over the entire country’s routing infrastructure
- BGP hijacks can be brief — lasting only minutes — making them difficult to detect and attribute after the fact
For intelligence agencies, BGP hijacking is an ideal surveillance tool: intercept specific traffic, inspect it, forward it, and restore normal routing. The entire operation can complete in minutes. The victim never knows.
Why RPKI adoption is too slow
Resource Public Key Infrastructure (RPKI) is the protocol designed to secure BGP. It allows autonomous systems to cryptographically sign their route announcements, enabling other routers to verify that a route is legitimate before accepting it.
RPKI is the right solution. But adoption is glacial:
- As of 2026, approximately 45% of routes have RPKI Route Origin Authorizations (ROAs). This means 55% of routes are still unprotected.
- ROA validation is optional. Even when ROAs exist, most networks don’t reject invalid routes — they just flag them. The hijacked route still propagates.
- RPKI doesn’t prevent path manipulation. Even with RPKI, an attacker on the routing path can intercept traffic as it passes through their AS. RPKI only validates the origin, not the entire path.
- Incentive misalignment: Network operators bear the cost of RPKI deployment but benefit only when other operators also deploy it. Classic collective action problem.
How ZK Proven detects BGP hijacking
ZK Proven operates at the application layer, making it independent of BGP routing decisions. Even when traffic is rerouted through a malicious network, ZK Proven’s proof streams detect the anomaly.
Network topology proof
BGP hijacking changes the routing path. Traffic that normally traverses 4 autonomous systems now traverses 6 or 7. The hop count increases. The latency increases. The latency distribution changes because the traffic is now passing through different geographic regions with different propagation delays.
ZK Proven’s topology proof monitors these characteristics continuously. A sudden change in hop count, latency, or routing topology triggers score degradation. If the change is consistent with a hijack pattern (increased path length + latency increase + geographic routing anomaly), the score collapses.
Timing analysis
When traffic is rerouted through an additional autonomous system, the round-trip time changes. If your traffic to a US-based server suddenly takes a detour through Asia, the latency increases by 100-200ms — the speed-of-light propagation delay for the additional distance. ZK Proven’s temporal coherence proof detects this latency shift.
Canary signal verification
ZK Proven’s canary signals are designed to detect infrastructure manipulation. The canary challenge-response is bound to the expected network path characteristics. When the path changes due to a BGP hijack, the canary response arrives with different timing characteristics, triggering a score adjustment.
RPKI prevents BGP hijacking at the routing layer (when deployed). ZK Proven detects BGP hijacking at the application layer (always deployed). Together, they provide defense in depth. But only ZK Proven works today, on every connection, regardless of RPKI deployment status.
The compound threat: BGP + DNS
The most dangerous BGP attacks combine routing hijacking with DNS manipulation. The attacker hijacks BGP routes for DNS servers, poisons the DNS responses, and redirects users to malicious destinations. This is what happened in the MyEtherWallet attack.
ZK Proven catches this compound attack through multiple proof streams simultaneously:
- Topology proof catches the routing change
- Temporal coherence catches the latency shift
- Canary signal catches the DNS manipulation
- Ephemeral key proof ensures the session cannot be replayed even if intercepted
No single-layer defense catches both BGP and DNS attacks. ZK Proven’s multi-layer proof architecture catches them together.
The internet’s routing is built on trust
BGP is a trust-based protocol in a trustless world. RPKI will eventually fix this, but “eventually” means years or decades of continued vulnerability. In the meantime, every internet connection is routed through infrastructure that can be hijacked by any autonomous system operator on earth.
ZK Proven doesn’t fix BGP. It makes BGP hijacking detectable at the application layer. Your data may be rerouted, but ZK Proven ensures it is never exposed — because the connection is terminated before sensitive data flows over the hijacked path.
Detect routing anomalies before data is exposed
ZK Proven’s topology proof catches BGP hijacking at the application layer, regardless of RPKI deployment.
Explore ZK Proven →