Episode 94 — BGP Hijacking: what it is and what mitigations look like
In Episode Ninety Four, titled “BGP Hijacking: what it is and what mitigations look like,” we frame route hijacking as stealing traffic by lying about paths, because that captures the essential idea the exam wants you to understand. When routing information is trusted without sufficient validation, an attacker can influence where traffic goes, and that can lead to interception, disruption, or confusing detours that look like random internet instability. Border gateway protocol, commonly called BGP after first mention, is foundational to how networks on the internet find each other, which is why failures and abuses can have outsized impact. The exam typically focuses on conceptual clarity and operational mitigations rather than on deep protocol mechanics, so the goal is to recognize what hijacking is, what it looks like, and how operators reduce the likelihood and impact.
Before we continue, a quick note: this audio course is a companion to the Cloud Net X books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
Border gateway protocol announcements are how autonomous systems tell each other which internet protocol networks are reachable and which paths should be used to get there. An autonomous system is a network under a single administrative domain that participates in internet routing, and it exchanges routing information with peers to build a global view of reachability. In practical terms, a border gateway protocol announcement is a claim: “I can reach this prefix, and here is the path to me,” and other networks decide whether to trust that claim and propagate it further. This trust model works because most participants behave, but it is vulnerable because the protocol was not originally designed with strong cryptographic validation baked in by default. The exam expects you to understand that border gateway protocol is about reachability advertisement at the network-to-network level, and that errors or abuse can redirect traffic without touching end systems. When you keep that model in mind, hijacking becomes easy to describe: the routing system is persuaded to believe a false claim.
A hijack occurs when an attacker, or sometimes a misconfigured network, advertises prefixes they do not own or do not have authorization to originate, causing some portion of the internet to send traffic toward the wrong place. The attacker’s advertisement can be more specific than the legitimate one, which often wins because longer prefixes are typically preferred in routing decisions. Even without a more specific prefix, an attacker can sometimes influence path selection by presenting an attractive path, leading certain networks to prefer the attacker’s route. The outcome can be interception, where traffic passes through the attacker’s infrastructure, blackholing, where traffic is dropped, or detouring, where traffic takes inefficient paths that degrade performance and create strange user experiences. The exam framing often highlights that hijacks can be accidental as well as malicious, but from a defensive standpoint the mitigations are similar because the routing system needs guardrails. What matters is that traffic direction is altered at the routing layer, so users may see redirects, delays, or outages without any change in application configuration.
Route filtering and prefix limits are practical, exam-friendly mitigations because they represent the basic hygiene of not accepting and propagating anything a peer says without constraints. Route filtering means defining what prefixes you will accept from each peer based on what that peer is supposed to announce, which prevents a peer from unintentionally or maliciously advertising unrelated space. Prefix limits, often implemented as maximum prefix thresholds, prevent a peer from sending an unexpectedly large number of routes, which can indicate a leak or a misconfiguration that would destabilize routing tables. These controls should be applied with all peers because trust boundaries exist at every peering relationship, and a single weak link can become the path through which false routes propagate. The exam tends to reward the principle that you do not rely on implied trust in routing relationships, because the blast radius of routing mistakes can be large. When filtering and limits are in place, you reduce both the probability that you will accept a bad route and the probability that you will become a conduit for spreading it.
Resource public key infrastructure, commonly called RPKI after first mention, is best understood conceptually as a way to validate that an origin autonomous system is authorized to announce a given prefix. In simple terms, it provides cryptographic attestations that bind prefix ownership or allocation to authorized announcing networks, allowing routers to validate whether a route origin is legitimate. The exam usually does not require deep cryptographic detail, but it does expect you to know that resource public key infrastructure enables origin validation, which helps block certain classes of hijacks and route leaks. It is important to recognize that resource public key infrastructure is not a complete solution by itself, because deployment and policy choices affect effectiveness, but it is a major improvement over blind trust. When origin validation is used, a route that claims an unauthorized origin can be marked invalid and rejected or deprioritized, depending on policy. Conceptually, this is the routing equivalent of certificate validation, where you are checking whether the announced identity is allowed rather than assuming it is.
Monitoring for unexpected path changes and new origins is essential because even with good filtering and validation, routing is dynamic and incidents can still occur through partial deployment gaps or complex propagation behaviors. Monitoring can watch for changes in origin autonomous systems for your prefixes, sudden shifts in path attributes, and the appearance of more specific prefixes that you did not intend to advertise. New origins are a particularly strong signal because your prefixes should generally be originated by a known set of autonomous systems, and changes there are often meaningful. Unexpected path changes can also indicate traffic detours that degrade user experience even if reachability remains, and those detours can be early signals of a hijack, a leak, or a provider issue. The exam expects you to connect monitoring to detection and response, because hijacks are time-sensitive and the faster you recognize them, the faster you can coordinate remediation. When monitoring is tuned to routing behavior, you can distinguish normal churn from suspicious changes that deserve escalation.
A scenario helps link symptoms to routing behavior, so imagine customers reporting redirects and traffic detours, where they reach the service but notice unusual latency, strange intermediate locations, or intermittent failures that vary by region. These reports often appear inconsistent because routing decisions differ across the internet, so some users take the legitimate path while others are pulled toward the hijacked or leaked route. From an operational perspective, responders might observe that traffic is arriving from unexpected upstream networks or that traceroute paths show unfamiliar autonomous systems in the middle. If the hijack is causing interception, users may see certificate warnings or content anomalies depending on what the attacker is doing, but many hijacks simply detour or blackhole traffic without visible tampering. The key diagnostic clue is that the problem is path-dependent, meaning the service works from some locations and fails or degrades from others, which is typical of routing anomalies. This scenario reinforces that border gateway protocol issues manifest as reachability and path variability rather than as a single clean failure within your own infrastructure.
A pitfall is accepting any route from a peer without validation, because that turns your network into an amplifier of false information and increases your own exposure to hijacks and leaks. Without filtering, a peer can accidentally leak routes learned from elsewhere, causing you to accept and potentially propagate a large set of routes you should not have. Without prefix constraints, a peer can overwhelm routing tables, creating instability that looks like a broad outage rather than a specific hijack. Without origin validation where possible, you have no systematic way to reject unauthorized announcements, so you fall back to ad hoc troubleshooting when customers complain. The exam framing often emphasizes that routing relationships are trust relationships that must be bounded, because trust without bounds is fragile. When you accept anything, you are betting that no peer will ever misconfigure and that no attacker will ever exploit weak links, which is not a defensible bet in real operations.
Another pitfall is poor documentation that hides which prefixes should be advertised, because you cannot filter or validate what you cannot define. Operators need a clear inventory of owned prefixes, which autonomous systems are authorized to originate them, and what advertisements are expected under normal multi-provider designs. In multihomed environments, where you connect to more than one upstream provider, documentation also needs to capture intended traffic engineering behavior, such as which prefixes are announced to which providers and under what conditions. If documentation is missing or outdated, teams may hesitate during an incident because they are unsure whether a new route is malicious, accidental, or simply a previously undocumented design choice. Poor documentation also undermines monitoring because alerts need to know what “unexpected” means, and that requires an authoritative definition of intended origins and advertisements. The exam tends to reward the idea that documentation supports security and reliability by enabling correct filtering and faster incident response.
Quick wins include implementing maximum prefix settings, using communities to influence routing policy, and adding alerting for abnormal announcements, because these changes can reduce risk without requiring a full protocol overhaul. Maximum prefix limits protect against leaks and misbehavior by shutting down or de-preferencing sessions that exceed expected route counts, which prevents large-scale instability. Communities are routing tags used to signal policy preferences to upstream providers, and while they are not a security control by themselves, they support predictable routing behavior, which reduces surprises during incidents and helps contain detours. Alerting can watch for new origins, new more-specific announcements, and sudden changes in path attributes, providing early detection signals that trigger coordination before users experience widespread impact. These quick wins work best when combined, because limits reduce blast radius, communities support predictable policy, and alerting accelerates response. The exam often frames mitigations as layered, where you combine preventative controls and detection mechanisms to manage a dynamic routing environment.
When a suspected hijack occurs, coordinating with providers is a critical operational step because routing is an inter-domain problem and remediation often requires action beyond your own network. Providers can help validate what routes they are seeing, apply filters, adjust policies, or propagate corrective announcements more effectively than you can alone. Coordination also helps when the source is accidental, because the offending network may need to withdraw incorrect announcements, and upstream providers can contact them through established abuse and network operations channels. During coordination, having clear documentation of your authorized prefixes and origins is invaluable, because it lets you communicate precisely what is wrong and what “right” should look like. The exam tends to test that you understand the response is collaborative, because border gateway protocol routing involves multiple administrative domains and no single party controls the entire path. When coordination is built into the runbook, response becomes faster and less chaotic.
A memory anchor that fits border gateway protocol hijacking defense is announce, validate, filter, monitor, respond, because it tracks the lifecycle of routing truth and operational action. Announce reminds you that reachability is expressed through advertisements, and that your own announcements must be correct and consistent. Validate reflects origin validation concepts like resource public key infrastructure, where you check whether an origin is authorized rather than trusting blindly. Filter captures route filtering and prefix limits with peers, bounding what you accept and what you propagate. Monitor highlights watching for unexpected origins and path changes, because detection is time-sensitive in routing incidents. Respond emphasizes coordination and corrective action when anomalies appear, because you must act across domains to restore correct routing quickly.
A useful exercise is listing three mitigations for a multihomed network, because multihoming introduces both resilience and complexity. Route filtering per peer is one mitigation, ensuring each upstream is only allowed to send and receive expected prefixes so that leaks and hijacks are less likely to propagate through your sessions. Maximum prefix limits are another mitigation, preventing route floods from destabilizing your edge and creating broad outages that mask the real problem. Origin validation through resource public key infrastructure is a third mitigation, improving your ability to reject unauthorized origin announcements and reducing susceptibility to certain hijack patterns. Monitoring and alerting for new origins and unexpected more-specific announcements reinforces these mitigations by providing early detection, and operational coordination plans ensure response can be executed quickly. The exam expects you to connect these mitigations to the multihomed reality, where multiple peers mean more opportunities for both resilience and misconfiguration.
Episode Ninety Four concludes with a defensive posture that treats routing as a trust system that must be bounded, validated where possible, and monitored continuously because path truth can change outside your control. Hijacking works by false advertisements that redirect, detour, or blackhole traffic, so defenses focus on filtering what you accept, validating authorized origins, and detecting abnormal changes quickly. Avoiding blind acceptance of peer routes and maintaining clear documentation of intended prefixes and origins are foundational because they enable every other control to function correctly. The prefix review drill is a practical rehearsal, where you review what prefixes you own, which autonomous systems should originate them, what peers should receive them, and what monitoring should alert on if anything changes. When you can narrate that review clearly, you are demonstrating exam-ready understanding of how border gateway protocol hijacking works and what real mitigations look like in day-to-day operations. With that mindset, route hijacking becomes a manageable risk rather than an unpredictable internet mystery.
