🛡️ BGP Hijacking: How Route Leaks and Hijacks Actually Happen, and How They Get Caught

BGP was built on an assumption that made sense when the internet had a few dozen participants who largely knew and trusted each other: if a network says it can reach a prefix, believe it. That assumption never got a mandatory cryptographic upgrade as the internet scaled to tens of thousands of mutually-unfamiliar autonomous systems, which is the entire reason BGP hijacking is possible at all — nothing in the base protocol stops a network from announcing a prefix it has no legitimate claim to, and every other network on the internet has historically had no built-in way to tell the difference.

What a Hijack Actually Is, Precisely

A BGP hijack occurs when an AS announces a prefix it doesn't have legitimate authority to originate — the announcement itself is a completely valid BGP UPDATE message, indistinguishable in format from a legitimate one, which is exactly what makes hijacking hard to prevent at the protocol level. Once announced, any network that accepts and prefers this false announcement (based on normal best-path selection criteria like AS-path length, having no way to know the announcement is illegitimate) will send traffic destined for that prefix toward the hijacking network instead of — or in addition to — the rightful owner.

Hijack vs Route Leak: A Distinction Worth Being Precise About

These terms get used loosely, but they describe genuinely different failure modes. A hijack involves forging origination — announcing a prefix you don't own at all. A route leak involves incorrectly re-advertising a route you legitimately learned from one neighbor to another neighbor, in a way that violates the intended routing relationship (commonly, leaking routes learned from one transit provider to another transit provider, which shouldn't happen under normal customer/provider/peer relationship rules) — no forged origin, just a policy violation that can still cause real traffic misdirection at scale.

Why a Sub-Prefix Hijack Is Especially Effective

Because BGP routers always prefer the most specific matching prefix, an attacker who announces a smaller, more specific slice of a legitimate block (say, a /24 carved out of a legitimately-announced /16) will win the routing decision for that specific slice across virtually every network that receives the announcement, regardless of local preference or AS-path length differences with the legitimate broader announcement — prefix specificity is evaluated before the standard tie-breaking attributes even come into play. This is precisely why several well-known historical hijacking incidents involved narrow, surgical sub-prefix announcements rather than hijacking an entire large block outright — the more targeted the hijack, the more effective and often the longer it can persist before being noticed.

Detection: What an Anomaly Actually Looks Like

Automated BGP monitoring systems (covered in depth in our companion piece on BGP monitoring) generally watch for a specific set of anomaly signatures: a new, unexpected origin AS for a previously stable prefix; a sudden more-specific sub-prefix announcement from an AS with no prior history of announcing anything in that block; an unusually short or suspicious-looking AS-path appearing from a region or network with no plausible legitimate relationship to the prefix owner; or a prefix disappearing entirely (a possible route leak symptom) from expected paths. None of these signatures alone proves malicious intent — legitimate infrastructure changes can produce similar patterns — which is why context (does this new origin AS have a plausible business relationship with the legitimate owner) matters as much as the raw signature.

Case Study: A Regional ISP Misconfiguration Route Leak

A regional ISP, during a routine router configuration update, accidentally removed a route filter that should have restricted which prefixes it re-advertised to one of its transit providers — the result was a brief but significant route leak, where the ISP inadvertently offered itself as a transit path for a large number of prefixes it had no business carrying, causing some traffic destined for those prefixes to take a substantially longer, more congested path through the ISP's network before reaching its actual destination. The leak was caught within roughly twenty minutes by the affected networks' own BGP monitoring systems detecting AS-path anomalies, and resolved by reapplying the correct filter — a good illustration that most large-scale routing incidents in practice are misconfiguration, not malice, though the operational impact (degraded performance, in this case, rather than traffic interception) can still be significant.

Attack Scenario: Deliberate Traffic Interception

A more deliberate hijack scenario involves an attacker announcing a victim's prefix specifically to intercept traffic — commonly cryptocurrency-related infrastructure or DNS resolvers have been targeted historically, since intercepting traffic to these specific service types can enable follow-on attacks (transaction manipulation, DNS response forgery) beyond simple traffic disruption. These attacks are typically time-limited and narrowly scoped (targeting a specific small prefix rather than broad infrastructure) specifically to minimize the window of detection while maximizing the value of the intercepted traffic.

Mitigation: RPKI as the Primary Structural Defense

RPKI (Resource Public Key Infrastructure, RFC 6480) lets a legitimate prefix holder publish a cryptographically signed Route Origin Authorization (ROA) stating exactly which ASN is authorized to originate a given prefix. Routers configured to perform RPKI Route Origin Validation can then classify incoming announcements as Valid, Invalid, or NotFound based on whether they match a published ROA, and networks can configure policy to reject Invalid announcements outright — directly blocking many hijack attempts before they ever affect traffic, provided enough of the internet's networks actually perform this validation. Adoption has grown substantially in recent years but remains incomplete, meaning RPKI meaningfully reduces hijack risk without yet eliminating it entirely.

Mitigation and Detection Comparison

Response Playbook: If Your Prefix Gets Hijacked

1. Confirm the hijack independently — use multiple external vantage points (a BGP lookup tool, public looking glasses, or a monitoring platform) to verify the anomalous announcement is real and not a false alarm from a single source.
2. Identify the hijacking AS and contact information — most ASNs have a registered abuse or NOC contact through their RIR record.
3. Contact your own upstream providers to request they filter or reject the illegitimate announcement on their side, which can mitigate impact faster than waiting for the hijacking network to voluntarily stop.
4. Announce a more specific sub-prefix yourself if the hijack targets a broader block — since more-specific routes win, this can reclaim affected traffic even before the hijack is fully resolved upstream.
5. Escalate to your RIR and relevant community mailing lists (like NANOG) if the hijacking network is unresponsive, since public visibility often accelerates resolution.
6. Document the incident thoroughly for post-incident review and to support RPKI ROA creation if one didn't already exist for the affected prefix.

Real-World Industry Response Patterns

Common Mistakes in Hijack Prevention

Checklist for Reducing Hijack Risk

• Publish RPKI ROAs for every prefix you originate.
• Confirm your upstream providers perform RPKI Route Origin Validation, not just accept your ROA passively.
• Implement strict prefix filtering on all eBGP sessions, in both directions.
• Deploy continuous BGP monitoring for your own prefixes rather than relying on reactive detection.
• Maintain an up-to-date incident response playbook with current upstream and RIR contact information.

Summary

BGP hijacking is possible precisely because the protocol's foundational trust model was never designed to cryptographically verify who's authorized to announce what — a gap RPKI meaningfully closes but hasn't yet eliminated given incomplete global adoption. Understanding the distinction between a deliberate hijack and an accidental route leak, recognizing why sub-prefix hijacks are especially effective, and having a concrete response playbook ready before an incident happens are the practical, achievable pieces of preparedness available to any network operator today, regardless of size.