The internet works because BGP (routing), DNS (naming), and CAs (identity via TLS certs) all extend trust from single actors to global scale. Each layer was designed with minimal cryptographic verification. Each layer has been abused at scale. This module covers the three internet-wide trust failures every defender and pentester should understand — because they’re not going away.
Why this happens
BGP (1989), DNS (1983), and the CA system (1994) were designed to work, not to be secure. The founding assumption was “participants behave honestly.” When participants have turned out to not be fully honest (or compromised, or coerced), the layers have been patched with various cryptographic mitigations (DNSSEC, RPKI, Certificate Transparency) — but deployment is uneven, enforcement is weak, and the fundamental trust model remains “we trust the registered authority.”
The result: a motivated actor (often nation-state, sometimes criminal) can hijack traffic at scale by subverting one of these layers.
BGP hijacking
Every network has an Autonomous System Number (ASN) and advertises which IP prefixes it owns. Other networks accept the advertisements and route accordingly. No built-in verification that the advertising network actually owns the prefix.
# Real BGP hijack example (2018 - MyEtherWallet)
# Attacker advertised routes for Amazon's DNS Route 53 prefixes
# Users trying to reach MyEtherWallet had DNS queries routed to attacker
# Attacker returned DNS pointing to phishing site
# Site used valid TLS cert (obtained via DV challenge from hijacked IP)
# Total cryptocurrency stolen: ~$160,000
# Attacker's ASN temporarily routed around a third of the internet's traffic
# Route was withdrawn after ~2 hours
Technical mechanism
AS path: sequence of ASNs a route traversed. BGP picks shortest AS path by default. Attacker advertises a more-specific prefix (smaller block = more specific = wins). Traffic flows through attacker’s AS. Attacker can drop, inspect, or forward it.
Real incidents
- Pakistan Telecom (2008): Accidentally advertised YouTube prefixes. YouTube globally unreachable for ~2 hours. Pure misconfiguration but showed the protocol’s fragility.
- China Telecom (2010): Leaked routes for ~15% of internet prefixes. Traffic for significant chunks of US+EU government, Dell, IBM, Microsoft, and others transited China for ~18 minutes.
- MyEtherWallet (April 2018): Hijack + DNS manipulation + TLS cert obtained from hijacked IP = full session hijack for cryptocurrency theft.
- KlaySwap (2022): BGP + DNS hijack to steal ~$1.9M from Korean DeFi platform users.
- Various 2023-2025 route leaks: ongoing weekly events, most documented at RIPEstat / Cloudflare Radar.
RPKI defense
Resource Public Key Infrastructure: cryptographically-signed record that “AS X is authorized to originate prefix Y.” Routers validate advertisements against RPKI; reject invalid ones. Deployment ~50% globally as of 2026.
# Operator side: create Route Origin Authorization (ROA) in RIR portal
# RIPE, ARIN, APNIC, etc.
# ROA: Prefix 203.0.113.0/24, Max length /24, Origin AS 64500
# Router side: validate via RPKI cache
router bgp 64500
rpki server 192.0.2.10 port 3323
bgp bestpath prefix-validate allow-invalid 0
! Rejects RPKI-invalid routes
# Check your RPKI status:
# - bgp.tools
# - ripe.net/analyse/YANG
DNS cache poisoning
Dan Kaminsky (2008) demonstrated that DNS resolvers were trivially poisonable via birthday-attack math on the 16-bit transaction ID. Resolvers were patched to include port randomization. In 2020, SAD DNS (Side-channel AttackeD DNS) showed port randomization could be leaked via ICMP rate-limit side channels.
🔐 Advanced Module · Pro Tier
Continue reading with Pro tier (₹4,999/year)
You've read 25% of this module. Unlock the remaining deep-dive, quiz, and every other Advanced/Expert module.
136+ modulesAll levels up to this tier
20-question quizzesUnlimited retries with explanations
Completion certificatesShareable on LinkedIn
9 more sections locked below
