What Is BGP Hijacking? How Route Hijacks Work, Famous Incidents, and How Networks Prevent Them

BGP hijacking is the illegitimate takeover of traffic destined for IP address space, carried out by announcing routes for prefixes the announcer is not authorized to originate. Also called prefix hijacking, route hijacking, or IP hijacking, it corrupts the Internet’s routing tables themselves: networks around the world are told that the wrong party can deliver traffic for an address block, and they believe it.

This makes hijacking fundamentally different from IP spoofing, which forges the source address inside individual packets but redirects nothing — a distinction we mapped in our guide to IP spoofing. A hijack operates one layer up, on the routing system, and its effect runs in the opposite direction: traffic that should reach the legitimate holder is pulled toward the hijacker instead. Services go unreachable, or worse, reachable through an attacker positioned to observe and manipulate what passes through.

For any business operating public IPv4 space, hijacking carries an uncomfortable lesson about where protection actually comes from. A registry record does not stop a hijack. What determines whether a hijack succeeds for weeks or fails within minutes is the quality of the records and monitoring around the prefix — the ROAs, the route objects, the filters, and whether anyone is watching. This article explains how hijacks work, what history’s most famous incidents show, how to detect and prevent them, and what to do in the hours after discovering your prefix is being announced by someone else.

What Is BGP Hijacking?

BGP hijacking occurs when an autonomous system announces IP prefixes it is not authorized to originate, causing other networks to route traffic for those prefixes toward the wrong destination. The hijacker does not touch the victim’s network, servers, or registry records. The attack lives entirely inside the routing system: a false claim of reachability, propagated network by network, until a portion of the Internet — sometimes effectively all of it — delivers the victim’s traffic to the wrong place.

The consequences depend on what the hijacker does with the captured traffic. Dropped traffic produces an outage. Answered traffic enables impersonation and phishing. Forwarded traffic — passed along to the real destination after inspection — creates a man-in-the-middle position that can be nearly invisible to the victim, because services keep working while an unauthorized party sits on the path.

Terminology note: prefix hijacking, route hijacking, and IP hijacking all describe the same phenomenon. “BGP hijacking” has become the umbrella term because BGP, the Border Gateway Protocol, is the mechanism being abused.

Why Is BGP Hijacking Possible?

Hijacking is possible because BGP was designed on an assumption of honesty: by default, routers accept the route announcements their neighbors send them without verifying that the announcer has any right to the prefixes it claims.

As we explain in our guide to how BGP works, the Internet’s routing system is a chain of trust: each network announces the prefixes it can reach, neighbors accept and propagate those announcements, and traffic follows the resulting paths. Nothing in the base protocol checks an announcement against any registry, authorization record, or proof of holding. Whoever configures a BGP-speaking router at a sufficiently connected network can, absent filtering, inject claims about any address space on Earth.

Layers of verification have been retrofitted around the protocol — RPKI origin validation, IRR-based filtering, provider-level checks — and they work where deployed. But deployment is uneven, which produces the defining property of the modern hijacking landscape: a prefix’s protection is not a property of the prefix. It is a property of the records published for it and the filtering practiced by the networks around it. Two identical /24s can have completely different exposure depending on whether their ROAs exist, their route objects are accurate, and their upstreams filter. Registration alone confers none of this.

How Do BGP Hijacks Work?

Hijacks use one of two announcement strategies: competing for an exact prefix, or announcing a more-specific prefix that wins automatically. Described at the conceptual level:

1. Exact-prefix hijack

The hijacker announces the same prefix the legitimate holder announces — say, the identical /24. The Internet now holds two competing claims, and each network independently chooses between them using its normal path-selection rules, in which shorter AS paths are generally preferred. The result is a split: networks topologically closer to the hijacker send traffic there, while the rest continue reaching the legitimate holder. The victim experiences the most confusing symptom in networking — partial unreachability, where the service works from some places and vanishes from others.

2. More-specific prefix hijack

The hijacker announces a longer, more specific prefix inside the victim’s block — for example, a /24 carved out of the victim’s announced /22. This variant is far more dangerous because of a fundamental forwarding rule: routers always follow the most specific matching route. The more-specific announcement does not compete with the legitimate one; it overrides it, everywhere it propagates. Traffic for the hijacked portion drains toward the attacker from effectively the entire Internet, regardless of AS-path lengths.

This asymmetry also explains a defensive tactic that appears later in this article: the same longest-match rule that makes more-specific hijacks devastating lets a victim counter-announce even more specific routes to pull traffic back.

A third pattern worth naming: hijacks of unannounced space. If a prefix’s holder is not announcing it at all — dormant space, reserved space, a block between deployments — a hijacker’s announcement faces no competition whatsoever. Nothing contests the claim, and no outage alerts anyone, because there was no service to disrupt. The hijack can persist quietly for as long as nobody looks.

Accidental vs Malicious Hijacks — and Route Leaks

Not every hijack is an attack: a large share of routing incidents are configuration mistakes — but the traffic impact is real either way, and the defenses are the same.

Accidental hijacks typically come from typographical errors (announcing a prefix one digit away from the intended one), stale configurations left over from previous arrangements, or filtering mistakes at providers. The most famous incident in hijacking history — the YouTube case below — began as a local action that escaped by accident.

A related but distinct event is the route leak: a network propagates legitimate announcements beyond their intended scope — for example, a customer network re-advertising routes learned from one provider to another, accidentally offering itself as transit for traffic that was never meant to flow through it. In a leak, the origin of the route is still legitimate; the propagation path is wrong. In a hijack, the origination itself is unauthorized. The distinction matters for diagnosis and for defenses: origin validation (RPKI) addresses hijacked origination but not leaks, which need path-aware filtering and provider discipline.

From the victim’s chair, intent changes little in the first hour. Traffic is going to the wrong place; the response playbook is the same. Intent matters afterward — for how quickly the offending network cooperates, and for what consequences follow.

Famous BGP Hijacking Incidents

Two documented incidents, a decade apart, illustrate both hijack mechanisms and both ends of the intent spectrum.

2008: Pakistan Telecom and YouTube

In February 2008, Pakistan Telecom announced a more-specific prefix covering part of YouTube’s address space. The announcement was intended to implement a domestic block of YouTube by routing its traffic into a dead end inside Pakistan — but the announcement leaked to an international upstream provider, which propagated it globally. Because it was more specific than YouTube’s own announcement, routers worldwide preferred it, and YouTube became unreachable for a large portion of the Internet for roughly two hours. The incident became the textbook demonstration of the more-specific mechanism, of how a local routing decision can escape globally, and of the counter-announcement defense: YouTube’s operator responded in part by announcing even more specific prefixes to reclaim traffic while upstream providers filtered the leak.

2018: Amazon Route 53 and MyEtherWallet

In April 2018, attackers hijacked prefixes belonging to Amazon’s Route 53 DNS service by announcing more-specific routes for them. With DNS resolution traffic captured, the attackers answered queries for the cryptocurrency wallet site MyEtherWallet with the address of an impersonation server, harvesting credentials and stealing cryptocurrency from users who logged in — reportedly over a hundred thousand dollars’ worth during the roughly two-hour window. The incident demonstrated the modern threat model: hijacking not as an outage tool but as an interception platform, aimed at infrastructure (DNS) whose capture cascades into every service depending on it, with direct financial theft as the objective.

The pattern across both: the hijacks worked immediately and globally because nothing in the default routing system contested them — and both were resolved through the same channels defenders still rely on: detection, upstream escalation, filtering, and counter-announcement.

What Attackers Gain from a Hijack

A successful hijack gives the attacker the victim’s inbound traffic, which can be weaponized four ways:

• Denial of service. Captured traffic is simply dropped. The victim’s services go dark for whatever portion of the Internet the hijack reaches — an outage produced without sending a single packet at the victim, unlike the flood-based attacks covered in our DDoS mitigation guide.
• Interception and man-in-the-middle positioning. Traffic is inspected — or inspected and forwarded onward so services keep functioning while the attacker reads the path. Widespread TLS limits what can be read from encrypted sessions, but metadata, unencrypted protocols, and the opportunity to attack the encryption endpoint (as in the DNS-redirection pattern above) remain valuable.
• Impersonation and phishing. The attacker answers the captured traffic, serving fake versions of the victim’s services to harvest credentials — the MyEtherWallet playbook.
• Reputation laundering. Hijacked space — especially dormant space with a clean history — is used to emit spam and abuse traffic. The abuse is attributed to the hijacked prefixes, and the reputation damage lands on the legitimate holder, with the deliverability and acceptance consequences described in our guide to IP address reputation. The hijacker discards the space once it is burned; the holder keeps the blocklist entries.

Who Gets Targeted: Why Unmonitored Space Is Preferred

High-value services attract targeted hijacks, but the broadest category of victim is different: address space that nobody is watching.

From a hijacker’s perspective, the ideal prefix has three properties: no ROA (so origin validation cannot reject the false announcement), inaccurate or absent route objects (so automated filters have nothing to check against), and no active monitoring (so detection depends on someone eventually noticing). Space that is registered but unannounced adds a fourth: no competing legitimate route at all. This is why dormant blocks — space held for future growth, blocks between deployments, acquisitions not yet integrated, investment holdings — are disproportionately hijacked for spam emission. The holder learns about it, if ever, when the block they planned to deploy turns out to arrive pre-blacklisted.

The operational conclusion: idle IPv4 space still requires active governance. A block does not need to be in production to need ROAs, accurate records, and monitoring — it needs them precisely because nothing else will raise the alarm. For businesses that buy IPv4 addresses ahead of need, record hygiene and monitoring for the dormant period belong in the acquisition plan, not the eventual deployment plan.

Risk also concentrates in transition windows. When a prefix changes hands or changes announcing networks, records are in flux, multiple parties hold partial authority, and a false announcement blends into expected change. That elevated window has its own dedicated playbook in our guide to preventing IPv4 hijacking during a transfer — the special case of the general threat described here.

How to Detect a BGP Hijack

Hijacks are detected by watching the global routing system for announcements about your prefixes that deviate from what you authorized. Because your own network often continues working normally during a hijack — the false routes exist in other networks’ tables — detection requires external vantage points, not internal monitoring. The signals:

• An unexpected origin ASN. Route-monitoring services observe BGP data from collectors around the world and alert when your prefix appears originated by an ASN other than the ones you registered. This is the primary alarm, and services in this category — commercial monitoring platforms and open tools that consume public BGP feeds — can raise it within minutes of a hijack propagating.
• An unexpected more-specific. A new, longer prefix inside your block appearing in global tables, announced by anyone — including seemingly plausible parties — warrants immediate verification, given the override behavior described earlier.
• Geographically patterned reachability complaints. “Your service is down” reports clustering by region or by user network, while your own checks show everything healthy, is the classic symptom of an exact-prefix hijack splitting the Internet’s view of you.
• Reputation and abuse anomalies. Blocklist appearances or abuse complaints for space you are not actively using is a strong signal that someone else is using it.

The common thread: every signal requires that someone — or some service — is actually looking. Monitoring is not an enhancement to hijack defense; for the detection half of the problem, it is the defense.

How to Prevent BGP Hijacking

Prevention means publishing the records that let other networks reject false announcements about your space, and choosing upstreams that enforce them. No single measure is sufficient; together they raise the failure rate of hijack attempts from “rarely” to “usually”:

1. Publish ROAs for your prefixes. A Route Origin Authorization is a cryptographically signed statement in the RPKI system declaring which ASN is authorized to originate your prefix (and to what maximum specificity). Networks performing origin validation — a group now including many of the largest carriers — reject announcements conflicting with a valid ROA. A ROA is the closest thing to a global “reject forgeries of my space” instruction the routing system offers, and covering your space with accurate ROAs is the single highest-leverage preventive step.
2. Keep IRR route objects accurate. Many providers build filters automatically from Internet Routing Registry data. Accurate route objects mean automated filters admit your legitimate announcements and have grounds to question others; stale objects mean the filtering layer works from fiction.
3. Choose upstreams that filter and validate. Your prefixes’ protection is partly outsourced to every network that handles announcements about them. Providers that enforce RPKI validation, filter customer announcements against authorization data, and participate in routing-security norms (such as the MANRS initiative) materially shrink the population of networks a hijack can propagate through. This is a procurement criterion, not just an engineering one.
4. Monitor, per the previous section. Prevention reduces hijack success; monitoring bounds hijack duration. Both numbers matter.
5. Harden the transition windows. Apply the transfer-specific sequence — records updated in the right order, authorizations aligned before announcements move — whenever prefixes change hands or announcing networks.

An honest caveat the marketing around routing security often omits: RPKI origin validation verifies the origin of an announcement, not its path. A sophisticated attacker who forges an announcement claiming the legitimate origin ASN at the end of a fabricated path can evade origin validation; countermeasures for path forgery are an active area of standards work and are not yet widely deployed. ROAs defeat the common hijack, which is the right bar to clear — they do not make hijacking impossible, and no honest provider will tell you otherwise. We will treat RPKI and ROA mechanics in depth in a dedicated guide.

What to Do If Your Prefix Is Hijacked

The response playbook has six steps, and its effectiveness is decided mostly by how much of it was prepared in advance:

1. Confirm from external vantage points. Verify the rogue announcement in public routing data — the origin ASN, the exact prefix, the propagation footprint. This takes minutes and prevents chasing a false alarm or misdiagnosing a leak as a hijack.
2. Engage your upstream providers immediately. They can filter the false announcement at their edges and escalate to their peers and to the hijacker’s upstreams — the networks actually positioned to strangle the announcement’s propagation. This is where pre-verified emergency contacts pay for themselves.
3. Counter-announce more-specifics where possible. If the hijack is an exact-prefix or a more-specific that leaves room below it, announcing your own more specific routes exploits longest-match forwarding to pull traffic back — the YouTube defense. Its availability depends on your block size, your ROAs’ maximum-length settings (a counter-announcement rejected by origin validation helps nobody), and your ability to change announcements quickly.
4. Verify and correct your records. Confirm your ROAs and route objects are valid and current, so validating networks reject the hijack and accept your legitimate and counter-announcements. If records were stale, correcting them mid-incident is slow — another argument for doing it beforehand.
5. Notify affected parties as needed. If interception is plausible, treat it as a security incident for your services and customers, not merely a network event.
6. Document everything. Timelines, routing data, provider communications. The record supports abuse reports against the hijacking network, reputation disputes for anything emitted from your space during the hijack, and your own post-incident review.

Note what every step depends on: authority and speed. Who is entitled to demand filtering from your upstreams? Who can change your announcements and records, and how fast? For space announced under arrangements where those answers are unclear — an unresponsive provider chain, a lease with undefined routing authority — the playbook exists on paper and fails on the clock.

Spoofing vs Route Leak vs Hijack: Three Forgeries Compared

Aspect	IP spoofing	Route leak	BGP hijack
What is false	The source field in packets	The propagation scope of a legitimate route	The origination of the route itself
Layer	Data plane	Control plane	Control plane
Effect on the victim’s inbound traffic	None — nothing is redirected	Misrouted through an unintended path, often degraded	Redirected to the hijacker — dropped, answered, or intercepted
Usual intent	Malicious (floods, reflection)	Usually accidental	Either — mistakes and attacks both occur
Primary defense	Source validation at edges (BCP 38, uRPF)	Path-aware filtering, provider discipline	ROAs + origin validation, IRR hygiene, monitoring

Practical Checklist for Prefix Holders

1. Publish accurate ROAs for every prefix you hold — including dormant space — with maximum-length settings that permit your legitimate announcements and planned counter-announcements, and nothing broader.
2. Keep IRR route objects current for every prefix and origin ASN combination in use.
3. Enroll all your space in route monitoring with alerting — again including space not currently announced.
4. Verify your upstream providers enforce RPKI validation and filter customer announcements; make it a selection criterion.
5. Maintain verified emergency contacts and escalation paths at every upstream, tested at least annually.
6. Document who holds authority to change your announcements and records, and confirm the change process meets incident speed.
7. For leased space, confirm in writing how monitoring, ROA cooperation, and emergency routing changes are handled across the lease relationship.
8. Apply the transfer-window playbook whenever prefixes change hands or announcing networks.
9. Keep incident documentation habits ready: routing snapshots, timelines, communications.

Practical Note from i.lease

Hijacking incidents sort prefix holders into two groups, and the sorting happens before the incident begins. The first group has ROAs published, route objects accurate, monitoring alerting within minutes, upstream contacts verified, and clear authority to change announcements. For them, a hijack is an operational event: detected quickly, filtered quickly, over in an hour, documented. The second group discovers during the incident that the ROA was never created, the route object names an ASN from two providers ago, nobody was watching the dormant half of the block, and the question “who can authorize an emergency announcement change” starts an email thread instead of an action. For them, the same hijack runs for days and leaves reputation damage that outlasts it by months.

Nothing separates the two groups except governance — and governance is what to evaluate when structuring how you hold address space. For leased prefixes, every item in the first group’s posture crosses the lease relationship: ROA publication requires the registered holder’s cooperation, monitoring must be someone’s named responsibility, and emergency changes need an authority chain that answers at incident speed. A structured arrangement — the standard a managed IPv4 leasing platform should meet — defines all of this in writing before the first announcement. An informal one leaves the lessee holding the response playbook without the authority to execute any step of it. That difference is invisible in the monthly price and decisive in the incident.

Final Thoughts

BGP hijacking is what the Internet’s trust-based routing design costs when the trust is abused: false origination claims, propagated by default, redirecting traffic through exact-prefix competition or more-specific override. The famous incidents mark the threat’s range — an accidental more-specific that erased YouTube globally for two hours, and a deliberate interception of DNS infrastructure that converted captured routes into stolen cryptocurrency. Between those poles sits the quiet majority of hijacks: unmonitored, unannounced space borrowed for spam, discovered only in the reputation damage left behind.

The defense, correspondingly, is not a product but a posture: ROAs that let the world’s validators reject forgeries of your space, route objects that give automated filters the truth to enforce, upstreams chosen for their filtering discipline, monitoring that bounds any hijack’s lifetime in minutes, and a response chain with the authority to act at incident speed. None of it comes from registration; all of it comes from governance — which is the general lesson hijacking teaches about public address space. A prefix is protected exactly as well as the records published for it, the networks around it, and the attention paid to it. That holds whether the space is owned or leased, announced or dormant — and it is decided, like most things in routing security, long before anything goes wrong.

Frequently Asked Questions

What is BGP hijacking in simple terms?

BGP hijacking is when a network falsely tells the rest of the Internet that it can deliver traffic for IP addresses it has no right to, causing other networks to send the real holder’s traffic to the wrong place — where it can be dropped, answered by impostors, or inspected.

Is BGP hijacking illegal?

Deliberate hijacking to intercept traffic, steal credentials, or disrupt services violates computer misuse and fraud laws in most jurisdictions. Accidental hijacks from configuration errors are not crimes, though the operational and contractual consequences for the responsible network can still be significant.

How common is BGP hijacking?

Routing incidents — hijacks and leaks together — occur continuously; monitoring organizations observe suspicious origination events on a daily basis worldwide. Most are small, short-lived, or accidental, but deliberate hijacks of valuable prefixes and quiet hijacks of unmonitored space are a persistent background threat rather than a rarity.

What is the difference between BGP hijacking and IP spoofing?

Spoofing forges the source address inside individual packets and redirects nothing — the victim’s inbound traffic is untouched. Hijacking forges routing announcements and redirects the victim’s inbound traffic itself, which is what makes interception possible and makes hijacking the more severe threat.

What is the difference between a hijack and a route leak?

In a hijack, the origination of the route is unauthorized. In a route leak, a legitimately originated route is propagated beyond its intended scope, misdirecting traffic through an unintended path. Origin validation addresses hijacked origination; leaks require path-aware filtering and provider discipline.

Can RPKI stop all BGP hijacks?

No. RPKI origin validation rejects announcements whose origin ASN conflicts with a published ROA, which defeats the common forms of hijacking. It does not verify the path of an announcement, so an attacker forging the legitimate origin at the end of a fabricated path can evade it. ROAs are the highest-leverage defense available, not an absolute one.

How do I know if my prefix is being hijacked?

Through external monitoring: services that watch global BGP data and alert on unexpected origin ASNs or unexpected more-specific announcements for your space. Internal checks often show nothing wrong, because the false routes live in other networks’ tables — which is also why regionally clustered “your service is down” reports are a classic symptom.

Can a hijack steal data from HTTPS websites?

TLS encryption prevents captured traffic from being read directly, which substantially limits interception. However, hijacks can still capture metadata and unencrypted protocols, and can attack the surrounding infrastructure — as in the 2018 incident, where hijacked DNS traffic let attackers direct users to an impostor site. Hijacking plus a supporting attack can defeat protections that hijacking alone cannot.

Can leased IP prefixes be hijacked?

Yes — the routing system does not distinguish leased from owned space. The practical difference is that the defenses cross the lease relationship: ROA publication needs the registered holder’s cooperation, and emergency routing changes need a defined authority chain. How the lease handles monitoring, records, and incident response should be confirmed in writing before leasing.

How long do BGP hijacks last?

Anywhere from minutes to weeks. Duration is determined almost entirely by detection and response: monitored prefixes with responsive upstreams see hijacks filtered within the hour, while unmonitored — especially unannounced — space can be quietly abused until reputation damage finally surfaces it.

Also Read

• What Is BGP? How Border Gateway Protocol Turns IP Addresses into Reachable Services
• How to Prevent IPv4 Hijacking During a Transfer: 10 Security Steps
• What Is IP Spoofing and How Do Networks Defend Against It?
• How DDoS Mitigation Works: Scrubbing, BGP Diversion, Anycast, and What Network Operators Should Prepare