BGP Hijacking Explained: How Nation-States Redirect Internet Traffic

BGP overview

If you’d like to try it out, please clone my repo: https://github.com/cybersecbella/scapy

git clone https://github.com/cybersecbella/scapy.git

Goal: route network prefixes (blocks of IP addresses that are reachable); do not route packets, but route the directions to networks

BGP stands for Border Gateway Protocol; The routing protocol allows autonomous systems (ASes ) on the internet exchange information needed to reach each other (blocks of IP addresses that are reachable and through which paths). An AS is an independent administrated network with a routing policy; An AS is identified by its unique Autonomous System Number (ASN). An AS will advertise a route and the exact ASNs the traffic must take in a path to reach the AS’s destination. Border routers are routers that sit on the edge of the an AS which the hold the routing tables. Peering is the agreement between border routers to exchange data (IP prefixes, subnet masks, Path Attributes, protocol state messages)

eBGP (external BGP) - use when routing information exchanged between different ASes

iBGP (internal BGP) - use when routing information within one AS

---

How it works

It operates over TCP port 179 (guarantees reliable routing updates) as an Exterior Gateway Protocol (EGP). The steps are as follows:

1. Border routers establish a TCP connection + authenticate eachother as peers
2. exchange UPDATE messages to state which IP prefixes they can route packets to
3. Picks the best path based on AS_PATH length, network policies, etc.
4. Border router puts the path into its routing table + advertise to its peers

A BGP UPDATE contains 3 critical fields:

1. NLRI: The announced prefix — the block of IP space being advertised (e.g. 208.65.153.0/24).
2. AS_PATH: The ordered list of ASNs a packet would traverse to reach that prefix.
3. ORIGIN: The originating AS — always the last (rightmost) ASN in the AS_PATH (list of ASNs data must cross to reach its destination).

BGP Vulnerabilities

• BGP is a trust-based protocol meaning any AS can announce any prefix. (No verification/authenticity of prefix ownership)
• no built-in cryptographic verification of whether an AS actually owns the address space it is advertising

Meaning any BGP-speaking router can lie about its reachability and the paths to take get there. Since this is over the internet, the lie propagates globally and its blast radius is global. In fact, no credentials or malware is required to start an attack. (Feb 2003) Pakistan Telecom with instructions to block Youtube within Pakistan announced the prefix 208.65.153.0/24 to its provider PCCW, and PCCW propagated the prefix announcement without filtering it. This resulted in internet traffic meant for Youtube being redirected to Pakistan. The attack did not require any credentials or malware, just a misconfigured router and an upstream provider with no prefix filters. Used the BGP hijack detector against a simulation resembling this attack.

---

Detecting BGP Hijacks with Wireshark

Wireshark analyzes PCAP files which capture network traffic.

sudo tshark -i eth0 -f 'tcp port 179' -w bgp_capture.pcap

Capture live BGP traffic on interface eth0 or apply the BGP filter in wireshark

Display Filter	What it catches
bgp.update.path_attribute.type == 2	Show only messages containing AS_PATH attributes
bgp.update.nlri_prefix	Filter to UPDATEs with announced NLRI prefixes
bgp.update.path_attribute.as_path	Expose the raw AS_PATH field for inspection
bgp && ip.src == <peer_ip>	Isolate UPDATEs from a specific BGP peer
bgp.type == 2	UPDATE messages only (type 2)

What does a hijack look like?

A BGP UPDATE message might have:

• More-specific: The announced NLRI prefix is a prefix your AS does not own OR a sub-prefix of a legitimate prefix with a longer mask.
• Wrong origin: The AS_PATH ends in an unexpected origin ASN.
• Unexpected next-hop: The NEXT_HOP (ip addr of the next-hop router) resolves to an IP in a foreign autonomous system.
• Withdrawal + re-announcement: The same prefix appears first de-announced (WITHDRAWN ROUTES) then re-announced by a different AS within seconds.

tshark One-Liner for a rapid Triage

tshark -r bgp_capture.pcap -Y 'bgp.type==2' \
  -T fields \
  -e frame.time \
  -e ip.src \
  -e bgp.update.nlri_prefix \
  -e bgp.update.path_attribute.as_path \
  -E separator=, > bgp_updates.csv

Extracts all announced prefixes and their origin AS from a PCAP. The last produces a csv of prefix, as_path, peer_ip, and timestamp. Origin ASNs can be cross referenced against the RPKI (routing information database).

Fix: RPKI — Cryptographic Defense Against BGP Hijacking

RPKI stands for Resource Public Key Infrastructure. The cryptographic framework binds IP addresses resources to ASNs using X.509 certificates. Prefix owners can clarify which AS numbers are authorized to originate their address space.

How it works

RPKI introduces a new object type called the Route Origin Authorization (ROA). A ROA is a signed certificate stating:

1. which IP prefix is being authorized
2. which AS is allowed to originate it
3. the max prefix length that can be sub-allocated

RPKI State – shows validation	Meaning
Valid	A matching ROA exists and the originating AS matches — legitimate
Invalid	A ROA exists for this prefix but with a different ASN, or the prefix is more specific than the max-length — strong hijack indicator
Not Found	No ROA covers this prefix — no cryptographic assertion of ownership either way
bgp && ip.src == <peer_ip>	Isolate UPDATEs from a specific BGP peer
bgp.type == 2	UPDATE messages only (type 2)

How routers enforce RPKI

1. Border routers run a local RPKI Relying Party (RP) software a. Gets the signed ROA database from RIR trust anchors (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC)
2. RP validates the certificate chain
3. RP exports a Validated ROA payload (VRP) list to the router using the RTR protocol
4. Router marks each received BGP prefix as Valid, Invalid, or Not Found > drops/de-prefers Invalid routes

RPKI Limitations

• ROAs validate prefix origin not the whole AS_PATH – BGP path manipulation attacks cannot be prevented
• Operators have to create and maintain ROAs – legacy prefixes are uncovered
• RPKI does not protect against route leaks – valid ASN accidentally re-advertises prefixes

---

BGP Hijack Detector - Tested against real C2 traffic from the 2003 Pakistan Telecom attack

• BGP hijack detector: monitor route announcements and flag suspicious prefix origins using Scapy + RPKI validation
• AI PCAP analyzer: parse capture files with pyshark, extract flows → send to LangChain agent for threat narrative
• Beaconing detector: statistical analysis of packet timing to identify C2 beaconing (consistent intervals = malware)
• DNS exfiltration detector: flag unusually long DNS queries and high-entropy subdomains (common data exfiltration technique)

Architecture:

scapy/

├── ai_pcap_analyst/ ← your new package

│ ├── init.py

│ ├── dispatcher.py ← routes packets to correct detector

│ ├── bgp_hijack.py ← BGP route monitoring + RPKI validation

│ ├── ai_analyzer.py ← pyshark flow extractor + LangChain

│ ├── beaconing.py ← statistical C2 beacon detector

│ ├── dns_exfil.py ← DNS exfiltration detector

│ ├── aggregator.py ← combines all findings + ATT&CK tagging

│ ├── langchain_agent.py ← threat narrative LangChain agent

DNS exfiltration is when attackers encode stolen data as base64 in DNS subdomains:

How to detect:

• High entropy – random looking subdomains (base64/hex) vs real worlds
  • Entropy means randomness
  • High entropy suggests randomly generated characters = encoded data
  • Uses Shannan entropy equation to determine this!
• Unusual length – legitimate subdomains usually have 20 characters max, if exceed is suspicious

dns_exfil.py – detects data exfiltration by looking for high entropy/long subdomains within DNS queries

bgp_hijack.py - Monitors BGP UPDATE messages and validates against RPKI ROAs

Detect BGP route hijacks by analyzing the PCAP files. It validates the announced routes (validation status: Invalid, Valid, not-found) against RPKI ROAs using the RIPE NCC API. The web service specifies if a given IP prefix is being announced by an authorized AS. It checks the legitimacy of the BGP route advertisements. MIITRE ATT&CK tags and risk score are assigned for potential hijack events.

langchain_agent.py - process aggregated findings and generate an Incident Report with remediation steps

Other py files are in my repo.

Time to test

Simulated the Pakistan Telecom 2003 attack.

python tests/generate_tests_pcap.py 
python tests/create_dns_test.py 

Generates pcap files

dns_exfil.py - returns potential data exfiltration attempts masquerading as legitimate DNS queries

python ai_pcap_analyst/dns_exfil.py tests/sample_pcaps/dns_test.pcap

beaconing.py - looks for periodic communication patterns and suspicious port usage within network traffic

python ai_pcap_analyst/beaconing.py tests/sample_pcaps/monitoring_beaconing.pcap

bgp_hijack.py - returns the prefix and ASN; checks validation status

python ai_pcap_analyst/bgp_hijack.py tests/sample_pcaps/pakistan_telecom_bgp_hijack.pcap

dispatcher.py - packets put into DNS and BGP buckets

python ai_pcap_analyst/dispatcher.py tests/sample_pcaps/combined_incident.pcap

840 DNS queries found - DNS queries are usually UDP; Only TCP if a domain transfer is being done

ai_analyzer.py - analyzes packets and lists suspicious C2 channels

python ai_pcap_analyst/ai_analyzer.py tests/sample_pcaps/youtube_victim_traffic.pcap

28 suspicious flows; IPs identified

langchain_agent.py - interactive REPL

python ai_pcap_analyst/langchain_agent.py tests/test_report.json

python ai_pcap_analyst/langchain_agent.py tests/test_report.json interactive
attck

Queried the REPL and asked for attck path