BGP Hijacking: Detection and Prevention
Learn how BGP hijacking works, real-world incidents, and the layered defense strategy combining RPKI, IRR filtering, and monitoring.
What Is BGP Hijacking?
A BGP hijack occurs when a network announces IP prefixes that it is not authorized to originate. Because BGP trusts route announcements by default, neighboring routers accept and propagate the false route, diverting traffic.
Normal: 203.0.113.0/24 originated by AS 64512 (legitimate owner)
Hijacked: 203.0.113.0/24 originated by AS 99999 (attacker)
Result: Some or all internet traffic for 203.0.113.0/24
is routed to AS 99999 instead of AS 64512.
Types of BGP Hijacks
| Type | Method | Impact |
|---|---|---|
| Prefix hijack | Announce exact same prefix | Partial traffic diversion |
| Sub-prefix hijack | Announce more specific prefix (e.g., /25 vs /24) | Nearly complete diversion (longest match wins) |
| AS-path manipulation | Forge AS path to appear legitimate | Evades basic origin filtering |
| Route leak | Accidentally re-advertise learned routes | Widespread traffic misdirection |
Notable Incidents
- 2008 -- Pakistan Telecom / YouTube: Pakistan Telecom announced YouTube's /24 prefix to comply with a government censorship order. The announcement propagated globally, taking YouTube offline for two hours.
- 2018 -- Amazon DNS Hijack: Attackers hijacked an Amazon Route 53 prefix to redirect cryptocurrency wallet DNS queries, stealing $150,000 in Ethereum.
- 2019 -- China Telecom / European Traffic: Over 70,000 routes were briefly routed through China Telecom due to a route leak from a Swiss data center.
- 2022 -- KlaySwap / BGP + DNS: Attackers combined a BGP hijack of Kakao's DNS prefix with a fake DNS response to steal cryptocurrency.
Defense Layer 1: RPKI/ROV
Create Route Origin Authorizations (ROAs) for all your prefixes through your RIR:
ROA: {
Prefix: 203.0.113.0/24
MaxLength: /24
Origin AS: 64512
}
Setting maxLength to /24 prevents sub-prefix hijacks -- any announcement more specific than /24 from any AS will be RPKI-invalid and rejected by networks that enforce ROV.
Defense Layer 2: IRR Filtering
Maintain accurate Internet Routing Registry (IRR) records and ask your transit providers to filter based on IRR:
# RPSL route object
route: 203.0.113.0/24
origin: AS64512
mnt-by: MAINT-AS64512
Major transit providers (Lumen, NTT, Telia) filter customer announcements against IRR by default.
Defense Layer 3: Monitoring
Deploy continuous BGP monitoring to detect hijacks in real-time:
| Tool | Type | Alert Speed |
|---|---|---|
| bgp.tools | Web + API | Minutes |
| Cloudflare Radar | Web | Minutes |
| RIPE RIS | Route collector | Minutes |
| BGPStream (CAIDA) | Programmatic | Near real-time |
| ThousandEyes | Commercial | Real-time |
Set up alerts for:
- New origin AS for your prefix
- Unexpected AS path changes
- Sub-prefix announcements you did not make
- Visibility drops (your prefix disappearing from route collectors)
Incident Response
If you detect a hijack:
- Verify -- Confirm via multiple looking glass servers that the hijack is real.
- Contact upstream -- Ask your transit providers to filter the bogus announcement.
- Contact the offender's upstream -- Email their abuse@ and NOC contacts.
- Announce more specifics temporarily if the hijack is for your aggregate (e.g., announce two /25s if your /24 is hijacked).
- Document -- Record timestamps, AS paths, and affected traffic for potential law enforcement action.