BGP Hijacking Explained: Route Hijacks, Leaks & RPKI Defense

The internet has no central map. It is a mesh of about a hundred thousand independent networks, each one an Autonomous System, that tell each other which blocks of IP addresses they can reach. The protocol they use to trade that information is the Border Gateway Protocol, BGP, and it runs on a simple assumption: when a neighbor says it can reach a block of addresses, you believe it.

That assumption is the whole problem. BGP was built for a small club of operators who knew each other. It has no native way to verify that an announcement is true. Announce a prefix you do not own, and routers around the world may start sending you traffic that belongs to someone else. That is a BGP hijack, and it can move the traffic of an entire country or a major service in minutes.

How routing decisions actually get made

Every BGP router holds a table of prefixes, blocks of addresses written as 203.0.113.0/24, and for each prefix a list of paths to reach it. A path is a sequence of Autonomous System numbers, the AS-PATH, describing the networks the traffic would cross. When a router hears about the same prefix from several neighbors, it picks a single best path using a defined set of tie-breakers.

Two of those tie-breakers matter for hijacking. First, a router always prefers the most specific prefix that matches a destination. A route for 203.0.113.0/24 beats a route for 203.0.113.0/23, because the /24 covers a narrower, more exact range. Second, among prefixes of equal length, a shorter AS-PATH usually wins, because it looks like a closer, more direct route.

An attacker who understands those two rules has two levers. Announce a more-specific prefix than the victim, and you win outright everywhere the announcement spreads. Announce an equally specific prefix with a short path, and you win wherever your path looks shorter.

Prefix hijacks

The direct attack is a prefix hijack. A network originates an announcement for address space it has no right to. Because BGP does not check ownership, neighbors accept it and propagate it onward.

There are two common shapes:

• Exact-prefix hijack. The attacker announces the same prefix the victim announces. Traffic splits along the topology: networks that find the attacker's path more attractive send traffic to the attacker, the rest keep going to the victim.
• More-specific hijack. The attacker announces a smaller sub-block of the victim's space, for example a /24 carved out of the victim's /22. Longest-prefix match means the attacker wins broadly, often globally, because no legitimate route is more specific.

Once traffic arrives at the attacker, they choose what to do with it. Blackhole it and the victim goes dark, which is a denial of service. Forward it on toward the real destination after inspecting or altering it, and you have a man-in-the-middle position that most users would never notice. Terminate it on the attacker's own servers and you can impersonate the victim's services.

Route leaks

Not every routing incident is an attack. A route leak is the propagation of announcements beyond their intended scope, and it is usually a configuration mistake.

The internet's economics rely on networks keeping certain routes private. A network learns routes from its upstream providers, its customers, and its peers. The unwritten rule is that you only advertise your customers' routes to everyone, and you do not re-advertise a provider's or a peer's routes to another provider or peer. Break that rule, often through a missing filter or a typo in a routing policy, and traffic that should have taken a direct path suddenly detours through a network that was never sized to carry it.

The effect looks a lot like a hijack from the outside. Traffic redirects, latency spikes, and the leaking network can be overwhelmed, causing outages far from where the mistake was made. The difference is intent, and the defenses overlap heavily.

Hijacks versus leaks at a glance

Why the protocol cannot fix this on its own

BGP as specified in RFC 4271 carries no authentication of the routing information itself. A BGP session between two routers can be protected, so you know you are talking to the right neighbor, but that does nothing to verify that what the neighbor tells you is true. The neighbor may be honest and simply passing on a lie it heard from someone else.

That gap is why validation had to be bolted on around the protocol rather than inside it. The result is the Resource Public Key Infrastructure, RPKI, a cryptographic system that lets address holders make verifiable statements about who is allowed to originate their prefixes.

RPKI sorts every announcement a router hears into one of three states. Valid means a signed authorization exists and the announcement matches it, both the origin AS and the prefix length. Invalid means an authorization exists but the announcement contradicts it, a wrong origin or a prefix longer than the ROA allows, which is the signature of a hijack. NotFound means no authorization has been published for that space, which is still the common case because deployment is incomplete. A network doing origin validation typically accepts Valid and NotFound routes and drops Invalid ones. That single decision, drop what is provably wrong, is what turns RPKI from a database into a defense.

How to defend against BGP hijacking

No single network can secure global routing alone, but the controls below both harden your own network and raise the cost of hijacks that target you. Deployment discipline matters more than any one feature.

1. Publish RPKI Route Origin Authorizations (ROAs). As the address holder, create signed ROAs that state which Autonomous System is allowed to originate each of your prefixes, and at what maximum length. This is what lets other networks reject forgeries of your space.
2. Enforce Route Origin Validation (ROV). On your own routers, validate incoming announcements against RPKI data and drop the ones marked invalid. Publishing ROAs protects you from others; enforcing ROV protects your users from hijacks elsewhere.
3. Filter every prefix at every edge. Build explicit prefix lists for customers and reject anything they are not authorized to announce. Deny by default. Most large leaks would have been stopped by a filter that was never configured.
4. Set a sane maximum prefix length in your ROAs. If you only ever announce a /22, do not authorize longer prefixes. This blocks the more-specific hijack, which is the strongest form of the attack.
5. Adopt peer-locking and AS-PATH filtering. Encode the paths you expect from important peers, so an announcement that claims an impossible path gets rejected before it spreads.
6. Monitor the global view. Subscribe to routing-anomaly alerting so you learn within minutes when someone announces your space or an unexpected origin appears. The moat below tracks the actors and campaigns behind routing abuse, which helps you tell a fat-finger leak from a targeted hijack.

For the operators and campaigns tied to deliberate routing abuse and downstream interception, see our Threat Groups directory, which maps who runs these operations and how they chain routing manipulation into broader intrusions.

A worked example: how a more-specific hijack spreads

Follow the address space 198.51.100.0/22, held by a content provider whose legitimate origin is AS64500. The provider announces the whole /22 and nothing smaller. Traffic from around the world reaches AS64500 because that is the only route anyone has heard for the space.

Now an attacker operating AS64666 wants to intercept traffic to one server that lives inside 198.51.100.0/24, the first quarter of that block. Instead of announcing the same /22, the attacker announces 198.51.100.0/24, a more-specific route. The attacker hands that announcement to its own transit providers, who have no filter that would stop it, and they pass it on to their peers, who pass it to theirs.

Every router that receives both announcements now holds two entries: the legitimate /22 from AS64500 and the rogue /24 from AS64666. Longest-prefix match settles the contest with no tie-breaker needed. The /24 is more specific, so any packet whose destination falls inside 198.51.100.0/24 follows the /24 toward the attacker. The rest of the /22, the other three quarters, keeps flowing to AS64500 because no more-specific route exists for it. The victim sees a slice of its traffic vanish while everything else looks normal, which is exactly what makes the more-specific hijack hard to notice from the inside.

The attacker who wants to stay invisible does not blackhole the stolen slice. It configures its own router to forward those packets onward to AS64500 along a path that still functions, having first logged or altered them. From the end user's browser the service still loads. The only place the truth is visible is in the global routing table, where a /24 is suddenly originating from an Autonomous System that never announced it before.

How BGP security evolved

The trust-by-default design was reasonable when BGP was written. The networks running it in the late 1980s and early 1990s knew each other, and the operational problem of the day was keeping a small, fast-growing network reachable, not defending against a peer that lies. RFC 4271 codified the protocol without an authentication layer for the routing information because the threat model did not yet include a hostile Autonomous System announcing space it did not own.

The first widely deployed protection was not cryptographic. It was filtering: operators built prefix lists describing what each customer was allowed to announce and rejected anything else at the edge. Filtering works, and it remains the backbone of routing hygiene, but it does not scale cleanly to the peering mesh at the core of the internet, where a large network may hear hundreds of thousands of prefixes from a peer and cannot maintain a hand-written list for all of them.

RPKI, specified across RFC 6480 and its companions, added the cryptographic layer that filtering alone could not provide. It let an address holder publish a signed statement, a Route Origin Authorization, binding a prefix to the Autonomous System allowed to originate it. Origin validation checks announcements against those signed statements. RPKI closes the origin-forgery hole, which is the most common and most damaging class of hijack.

Origin validation still has a known limit: it validates the origin at the end of the AS-PATH, and it does not verify the rest of the path. An attacker can announce a prefix with a forged path that ends in the legitimate origin, making the announcement RPKI-valid while still steering traffic through the attacker. Path validation is the harder, less-deployed frontier, and it is why AS-PATH filtering and peer-locking still matter alongside RPKI. NIST SP 800-189 collects the current set of controls and the operational guidance for deploying them together.

Detection signals

Because a well-run hijack does not disturb the end user, detection lives in the routing layer and in a handful of secondary effects. Concrete signals to watch:

• A new origin for your prefix. The strongest indicator is your address space suddenly being announced by an Autonomous System that is not yours. Global BGP monitoring platforms and RPKI-invalid alerting surface this within minutes if you have subscribed to alerting for your own prefixes.
• A more-specific of your space appears. If you announce a /20 and a /24 carved out of it shows up in the global table from any origin, treat it as a hijack until proven otherwise. You know every prefix you legitimately announce, so anything more specific is a bright red flag.
• An unexpected AS-PATH to your prefix. Even when the origin is correct, a path that routes your traffic through an Autonomous System that has no business carrying it can indicate a path-manipulation attack or a leak. Compare observed paths against the paths you expect from your transit and peers.
• Latency and geolocation shifts. Traffic that suddenly detours adds round-trip time and often lands in an unexpected geography. A jump in latency to a service, or reachability tests that traceroute through a network you do not recognize, can be the downstream symptom of a hijack or leak upstream.
• RPKI-invalid counts rising at your validators. If you run origin validation, a spike in invalid announcements for your own space is a direct alarm, and the invalids name the rogue origin.
• Certificate and TLS anomalies. An interception hijack that terminates traffic may present a certificate that does not match, or trigger certificate-transparency monitoring if the attacker manages to obtain one for your domain while holding the traffic. Watch CT logs for certificates you did not request.

The practical posture is to monitor the global view of your own prefixes continuously, since you are the party best placed to know instantly that an announcement is wrong. The threat-intelligence question, whether a given anomaly is a fat-finger leak or a targeted operation, is where actor tracking helps you triage.

Common misconceptions

"Encryption protects me from hijacks." Transport encryption limits what an interceptor can read or forge, which is real and important. It does nothing to stop your traffic from being pulled off course, it does not prevent the outage when an attacker blackholes your prefix, and it does not help if the attacker obtains a valid certificate for your domain while holding the traffic. Route validation and encryption defend different layers.

"RPKI stops all hijacks." Origin validation stops origin forgery, which is the most common form. It does not validate the full AS-PATH, so a path-manipulation attack that appends the correct origin can still pass. RPKI is necessary and it is incomplete on its own.

"Only big networks can be hijacked." Any prefix can be hijacked. Smaller organizations are often easier targets precisely because they are less likely to publish ROAs or monitor the global table for their own space.

"A hijack always causes an outage." The most dangerous hijacks cause no outage at all. Interception forwards your traffic onward after inspecting it, so the service stays up while the attacker reads or alters what crosses.

"This is a rare, exotic problem." Routing incidents happen continuously, most of them accidental leaks rather than attacks. The mechanism that enables a leak is the same one an attacker exploits deliberately, which is why the defenses overlap.

Frequently asked questions

What is the difference between a BGP hijack and a route leak? A hijack is a deliberate false origin announcement: a network claims to originate address space it does not own. A leak is usually accidental: a network re-advertises routes beyond their intended scope, often through a missing filter. The traffic-redirection impact can look identical from the outside, but the intent and the announced origin differ. In a hijack the origin is forged or attacker-controlled; in a leak the origin is correct and the path is wrong.

Can RPKI alone stop BGP hijacking? It stops the most common class, origin forgery, by letting networks reject announcements from an origin the address holder never authorized. It does not validate the entire AS-PATH, so path-manipulation attacks that append the legitimate origin can still pass. RPKI is a large part of the answer and it needs AS-PATH filtering, peer-locking, and disciplined prefix filtering alongside it.

Why does announcing a more-specific prefix win? Routers always forward to the longest prefix that matches a destination, because a more-specific route describes a narrower, more exact range. A /24 beats a /23 covering the same space, so an attacker who announces a smaller sub-block of the victim's space wins traffic for that sub-block almost everywhere the announcement spreads, with no other tie-breaker involved.

How would I know my prefix is being hijacked? Subscribe to BGP monitoring and RPKI-invalid alerting for your own prefixes. The clearest signals are a new origin Autonomous System announcing your space, a more-specific of your space appearing from any origin, and an unexpected AS-PATH to your prefixes. Latency shifts and certificate-transparency anomalies are secondary indicators.

Does deploying RPKI on my network protect my users or other people's? Publishing ROAs protects your space from being forged by others, because it lets other networks reject hijacks of your prefixes. Enforcing origin validation on your own routers protects your users, because it makes your network drop invalid announcements for anyone's space before steering traffic toward a hijacker. You want both: publish ROAs and enforce validation.

Is a route leak dangerous if it was accidental? Yes. The redirection, congestion, and outages caused by a large leak are real regardless of intent. A network that is not sized to carry the leaked traffic can be overwhelmed, causing failures far from where the mistake was made. Filtering that would stop a deliberate hijack also stops most accidental leaks, which is one reason the two are defended together.

BGP hijacking persists because the protocol was built to trust and the internet was built on the protocol. There is no clever patch to install. The fix is a slow, collective deployment of validation and filtering across tens of thousands of networks. Publish your ROAs, enforce origin validation on what you accept, filter every edge, and watch the global routing table for your own prefixes. Each network that does this makes the next hijack a little harder to pull off and a lot easier to catch.

Related guides

• DNS Spoofing Explained
• Man-in-the-Middle Attacks Explained
• Certificate Transparency Explained
• Network Security Fundamentals