Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
The Border Gateway Protocol (BGP) is how the internet’s roughly 70,000+ autonomous systems (ASes) tell each other which IP prefixes they can reach and by which path. It was designed in the late 1980s on an assumption of mutual trust between operators: any AS can announce reachability for any prefix, and by default nothing cryptographically stops it from announcing a prefix it does not actually own. BGP hijacking is what happens when that assumption is violated — accidentally through operator error, or deliberately for traffic interception, censorship, or spam — and traffic destined for a legitimate network gets routed to an attacker instead, globally, in minutes.
RPKI (Resource Public Key Infrastructure) is the industry’s primary answer: a cryptographic system that lets a prefix owner publish a signed statement of which AS is authorized to originate their prefix, and lets routers along the path reject announcements that do not match. It does not fix BGP’s trust model wholesale — it specifically addresses origin validation, not path validation — but origin hijacks are the overwhelming majority of real-world incidents, which makes RPKI adoption one of the highest-leverage routing security investments a network operator can make.
Attack Prerequisites
A BGP hijack, accidental or deliberate, requires:
- Control of an Autonomous System and a BGP session to at least one upstream provider or peer willing to accept and propagate the announcement — historically many transit providers accepted announcements with little or no filtering.
- A victim prefix that either has no RPKI ROA published, or whose transit providers do not enforce Route Origin Validation (ROV) — a hijack against a prefix with a valid ROA is rejected by any router doing ROV, regardless of how convincing the announcement looks otherwise.
- A more-specific or equally-specific announcement that competing routers’ BGP best-path selection will prefer — longest-prefix-match means a /24 hijack against a legitimately announced /16 wins for any router that accepts it, since more specific routes are always preferred regardless of AS path length.
How It Works
BGP routers select the best path to a destination using a well-defined decision process, but the two properties that matter most for hijacking are origin trust and prefix specificity. BGP has no built-in way to verify that the AS originating a route announcement is actually authorized to route that prefix — the protocol simply propagates whatever NLRI (Network Layer Reachability Information) it receives, subject to whatever filtering the receiving operator chose to configure. And because routers use longest prefix match, an attacker announcing a smaller, more specific block than the legitimate owner — a /24 slice of a victim’s /16, for example — will win the routing decision for that /24 across essentially the entire internet, even though the victim’s broader announcement is still present and otherwise valid. This is why a huge share of real hijacks are “sub-prefix hijacks”: they do not need to out-compete the victim on AS path length or any tie-breaker, specificity alone wins.
A related but distinct failure is a route leak: a network re-announces routes it learned from one provider or peer to another, without authorization, usually due to a misconfigured filter rather than malicious intent. This can still cause large-scale traffic misdirection — famously, in April 2010, China Telecom briefly re-announced roughly 15% of the internet’s prefixes through a single AS, an incident widely attributed to a route leak rather than a targeted hijack. Deliberate hijacks, by contrast, are usually narrowly targeted: the April 2008 Pakistan Telecom incident, in which an attempt to block YouTube domestically via a bogus null-route announcement leaked to Pakistan Telecom’s upstream and briefly took YouTube offline globally, and the April 2018 hijack of Amazon’s Route 53 address space (via a compromised or malicious announcement from a smaller AS) that redirected traffic for myetherwallet.com to an attacker-controlled server to steal cryptocurrency, are both widely documented examples.
RPKI closes the origin-validation gap without requiring every router to trust every other operator directly. A prefix holder creates a Route Origin Authorization (ROA) — a signed object stating “AS X is authorized to originate prefix Y, up to a maximum length Z” — and publishes it through their Regional Internet Registry (ARIN, RIPE NCC, APNIC, LACNIC, or AFRINIC), which acts as the trust anchor. Routers running Route Origin Validation (ROV) fetch the current set of ROAs from RPKI validator software (relying party tools like Routinator, rpki-client, or OctoRPKI) and classify each received announcement as Valid (origin AS and prefix length match a ROA), Invalid (a ROA exists for the prefix but the announcing AS or length does not match — the hijack case), or NotFound (no ROA published at all — unprotected, the most common state globally). Operators then apply local policy, typically rejecting or heavily de-preferring Invalid routes. RPKI explicitly does not validate the AS *path* — a technique called path validation, addressed by the much less-deployed BGPsec — so an attacker who can forge a valid-looking AS path while still originating from an authorized AS is outside RPKI’s protection; in practice this is a far narrower attack surface than unauthenticated origin announcement.
Vulnerable Code / Configuration
The most common “vulnerable configuration” in BGP hijacking is simply the absence of a ROA — a prefix that has never been covered, leaving ROV routers unable to distinguish the legitimate announcement from a hijack at all:
# Checking ROA coverage for a prefix via a public RPKI validator API
curl -s 'https://rpki-validator.ripe.net/api/v1/validity/AS64500/203.0.113.0/24' | jq .
# validity.state == "unknown" --> NotFound: no ROA exists, no protection at all
Equally common: an upstream provider’s BGP session configured without any prefix filter or max-prefix limit, accepting whatever the customer announces:
! VULNERABLE Cisco IOS-XR peer policy: no prefix-list, no RPKI-based filtering
router bgp 64500
neighbor 203.0.113.1
remote-as 65000
address-family ipv4 unicast
! no inbound prefix-list or route-policy applied
A hardened peer policy filters on both a registered prefix list (from an IRR-derived allowlist, e.g. via bgpq4) and RPKI validity state:
router bgp 64500
neighbor 203.0.113.1
remote-as 65000
address-family ipv4 unicast
route-policy CUSTOMER-IN in
route-policy CUSTOMER-OUT out
!
route-policy CUSTOMER-IN
if rpki-state is invalid then
drop
endif
if destination in PREFIX-LIST-CUSTOMER then
pass
endif
drop
end-policy
Walkthrough / Exploitation
Assessing an organization’s exposure starts with checking whether its prefixes are covered by valid ROAs and whether upstreams enforce ROV — this is a defensive audit, since actually originating a hijack against production internet routing without authorization is both illegal and operationally reckless, so testing is done against RPKI tooling and lab/simulated ASes:
# Look up an AS's announced prefixes and current RPKI validity via a routing
# intelligence service (e.g. RIPEstat, bgp.he.net) as part of an audit
curl -s 'https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=203.0.113.0/24'
# In a lab environment, build ROAs and validate origin/length pairs
# with a relying-party validator such as Routinator
routinator vrps --format=csv
# Confirm a specific origin/prefix pair validates as expected
routinator validate --asn 64500 --prefix 203.0.113.0/24
Historical incidents are best studied through public BGP monitoring services — BGPMon-style alerting and RIPE’s routing-history tools let an analyst reconstruct an announcement timeline (origin AS churn, sudden more-specific announcements) after the fact, which is the standard forensic approach since active hijack reproduction is not something to test on live infrastructure.
Note: RPKI protects origin, not path. An attacker who compromises or colludes with an AS that IS authorized to originate a prefix, or who forges a plausible AS path while originating correctly, is not caught by ROV alone — BGPsec addresses path validation but has seen negligible real-world deployment to date.
Opsec: A NotFound RPKI state is not neutral — it means zero protection, identical to having no RPKI at all for that prefix. Auditors should treat any prefix without a covering ROA as an open finding, not a low-priority one, since it is directly exploitable with a same-or-more-specific announcement.
Detection and Defense
Routing security is a shared responsibility between prefix holders and transit providers:
- Publish ROAs for every announced prefix at the correct max-length, and keep them synchronized with actual announcements — an overly broad max-length still leaves room for sub-prefix hijacks within that range.
- Enable Route Origin Validation (ROV) on edge/peering routers and reject or heavily de-preference RPKI-Invalid announcements.
- Filter customer BGP sessions with IRR- or RPKI-derived prefix lists, not an open policy, and apply max-prefix limits to bound blast radius from a misconfiguration or leak.
- Monitor announcements for your own prefixes with a BGP monitoring service so an unauthorized more-specific announcement anywhere on the internet is flagged within minutes, not discovered from customer complaints.
- Adopt MANRS (Mutually Agreed Norms for Routing Security) commitments — filtering, anti-spoofing, coordination, and global validation — as an operational baseline, particularly for transit and IXP participants.
Real-World Impact
BGP hijacks and leaks have repeatedly demonstrated internet-scale impact from a single misconfigured or malicious announcement: the April 2008 Pakistan Telecom/YouTube incident took a global video platform offline for hours from what began as a domestic censorship attempt, and the April 2018 hijack targeting Amazon Route 53 to redirect myetherwallet.com traffic showed that routing-layer attacks can directly enable financial theft, not just denial of service. These incidents, among others, are the primary reason major cloud and content providers have driven aggressive RPKI ROA publication and pushed transit providers toward enforcing ROV as a baseline peering requirement.
Conclusion
BGP’s original design trusted every operator to announce only what they legitimately controlled, and the internet has spent over a decade building cryptographic scaffolding — RPKI, ROAs, and Route Origin Validation — around that gap without needing to redesign BGP itself. The residual risk is almost entirely adoption: prefixes without published ROAs and networks that do not enforce ROV remain exactly as exposed as the internet was before RPKI existed. Publishing accurate ROAs and enforcing origin validation on transit sessions is the single highest-leverage step any network operator can take against hijacking.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments