BGP hijacking 2025: Why forged docs beat crypto

Only 43.17% of IPv4 prefixes enforce validation. The rest sit exposed to sophisticated BGP route hijacking that sidesteps cryptographic checks entirely. This isn't a protocol failure; it's a process failure. Modern attacks now fuse protocol manipulation with identity fraud, spoofing ASN ownership without ever triggering an invalid state. The fix demands more than just signing ROA records; it requires configuring ASPA and hardening the human layer of provisioning.

The July 2025 case study presented by APNIC and LACNIC at APRICOT 2026 laid bare a critical flaw: adversaries forged documents to convince upstream providers to accept unauthorized transit. (APNIC's rpkis 2025 year in review) Even as zero-trust Architecture becomes a baseline expectation in 2026, this incident proved that verification gaps in provisioning let malicious actors redirect traffic through compromised autonomous systems. Attackers executed three precise hijack events lasting merely five to twenty minutes. They used a victimized ISP's identity to propagate false announcements that slipped past standard detection filters.

Data from APNIC shows a dangerous disconnect. Over half of all prefixes possess Route Origin Authorizations, yet the gap between signature coverage and active enforcement remains lethal. The adversary reconstructed infrastructure to test propagation limits, proving technical controls fail without rigorous identity verification at the registry level. Network operators must close the loop between cryptographic validity and operational reality. In 2025, routing security depends as much on human processes as algorithmic proof.

The Dual Nature of Modern Route Hijacking Attacks

Defining BGP Hijacking via Spoofed ASN and Weak Identity Verification

Attackers don't always break the crypto; they break the handshake. BGP hijacking via spoofed ASN exploits weak upstream identity checks to propagate false routes without triggering ROV invalid states. By forging autonomous system numbers to mimic legitimate providers, bad actors bypass origin validation because the cryptographic signature appears valid. This isn't misconfiguration; it's deliberate social engineering designed to convince upstream providers to accept fraudulent peering requests. The attacker redirects traffic through a compromised upstream, creating a path that looks authorized despite the illegitimate origin.

The numbers tell a grim story. While over 50% of BGP prefixes possess ROA coverage, only approximately 50% Broad maxLength values in existing ROAs further exacerbate the risk. These broad settings allow attackers to announce more specific prefixes that still validate correctly. The July 2025 incident demonstrated how spoofed ASNs avoid creating an invalid state, facilitating the propagation of false announcements through non-enforcing networks.

Cryptographic origin validation alone cannot stop attacks targeting the provisioning layer. Identity verification failures at the upstream provider level render ROA signatures useless against determined adversaries.

Three distinct hijack events struck LACNIC space on July 9, 10, and 12, 2025, lasting roughly 20, 15, and five minutes respectively. The attacker spoofed the origin ASN to maintain a valid RPKI state, ensuring Route Origin Validation filters accepted the announcements as legitimate. This technique exploits non-ROV legacy paths to divert traffic silently, a pattern documented in recent empirical research. Email delivery failed because data-plane traffic followed the forged path while control-plane monitoring showed no anomalies. The upstream provider enabling this transit was a victim of social engineering, not an accomplice to the theft. Attackers used weak identity verification during customer onboarding to establish the BGP session before injecting the short bursts.

Stealthy hijacking thrives on the disparity between high Route Origin Authorization coverage and low enforcement rates. Attackers bypass origin validation by routing announcements through legacy paths where neighbors skip Route Origin Validation filtering, leaving valid signatures ineffective against data-plane diversion. This forces a strategic shift from simple origin checks to full path validation using ASPA objects. Empirical studies confirm that malicious origins often disappear from the control plane because ROV-enabled peers drop invalid states, yet traffic flows normally over unvalidated links. Attackers use this inconsistency to maintain plausible deniability while siphoning data.

Publishing ROA records without enforcing reject policies creates a false sense of security. Without mandatory enforcement, cryptographic signatures remain advisory rather than protective. Signing does not equal protection.

Mechanisms of Identity Spoofing and Protocol Exploitation

Forged corporate papers tricked a multinational provider into enabling BGP for AS X without validating domain ownership. The attacker did not bypass RPKI; instead, they exploited weak identity‑verification processes in upstream provisioning to establish a trusted session. This social engineering vector renders origin signatures useless because the router accepts the path as legitimate from an authorized peer. Malicious actors use this trust to insert legitimate ASNs into fake paths, exploiting the BGP path selection vulnerability where shorter or cleaner routes win preference. Unlike the Celer Bridge Attack which manipulated unauthenticated IRR databases, this 2025 incident succeeded by bypassing technical checks entirely through human deception.

ROA MaxLength discipline cannot stop an announcement coming from a provisioned upstream. Operators must shift focus from pure cryptographic validation to procedural hardening of customer onboarding.

Without ASPA deployment to cryptographically sign valid upstream relationships, any provider with lax hiring practices becomes an entry point for hijacks. The cost of manual verification is low compared to the reputational damage of facilitating traffic theft.

Short announcements behind AS X lasted only minutes, disappearing before standard polling intervals could capture the anomaly. Attackers exploit the BGP path selection vulnerability. This tactic relies on forged upstream relationships where providers skip identity checks, allowing traffic to flow through a trusted but compromised session. Detection requires comparing expected paths against live data using RIPE Atlas probes (RIPE's resource certification roa management) com/blog/post/2026-03-20-detect-ipv6-bgp-hijacking/view) to spot unexpected changes in hop one or two. Legacy monitoring tools often miss these bursts entirely, leaving operators blind to the initial diversion.

Operators must deploy ASPA to block unauthorized upstreams, as origin validation alone cannot stop a trusted peer from announcing spoofed prefixes. The cost of this defense is increased RIR coordination, yet the alternative leaves networks exposed to stealthy hijack Broad ROA MaxLength values increased the scale of the incident by allowing more specific prefixes to appear valid. An RFC 9582 ROA object authorizes an Origin AS Number to announce prefixes, yet an optional maxLength field permitting broader ranges inadvertently validates unauthorized subnets. Attackers exploit this permissiveness to announce /25s under a /24 authorization, creating technically valid but operationally fraudulent paths. The cost is measurable: broad configurations expand the attack surface without triggering Route Origin Validation rejects.

Research indicates that a significant majority of ASes derive some benefit from RPKI, yet this protection fails when maxLength fields are misconfigured. Operators must align maxLength values with actual subnetting plans rather than defaulting to /24 or /32 limits. Overly broad values validate hijacks that precise configurations would drop immediately. This discipline prevents attackers from using valid signatures to mask illicit traffic diversion.

Strategic Configuration of ROA and ASPA for Defense

Broad ROA MaxLength values accidentally authorize unauthorized subnets by letting more-specific prefixes validate under ROV. An RFC 9582 Attackers exploit this configuration to announce /25 subdivisions beneath a /24 authorization, rendering the route technically Valid despite operational fraud. The validation outcome remains positive because the signature covers the broader range, masking the hijack from standard filters. Matching maxLength to real deployment needs restricts the attack surface to only those prefixes actually in service. Overly broad settings increase incident scale by legitimizing forged announcements that stricter policies would reject as Invalid. Operators must audit existing ROAs to eliminate unnecessary latitude in prefix specificity. Precise discipline prevents stealthy hijacking vectors that rely on permissive origin authorizations.

This method closes the gap where social engineering succeeds against weak provisioning checks.

ASPA Deployment to Block Forged Upstream Relationships

ASPA prevents forged upstream relationships by validating the AS path sequence rather than just the origin. RPKI validates route origins using ROAs, whereas ASPA verifies if an ASN is authorized to provide transit for another, stopping attacks where social engineering bypasses identity checks. The July 2025 incident demonstrated this gap: attackers convinced a multinational provider to enable transit for a spoofed ASN, injecting short announcements that propagated because the path appeared legitimate. If ASPA validation had been active, routers would have rejected these paths as invalid due to missing provider authorizations.

Operator policy remains the limitation; enforcement requires explicit configuration to reject invalid paths rather than merely logging them. Without this step, the protocol signals an error but permits traffic flow, leaving the network exposed.

Operators must treat upstream provisioning as a vital security boundary, verifying domain metadata and contacting registered peers before enabling sessions. This dual approach blocks the specific vector where attackers exploit weak onboarding to inject traffic through otherwise trusted peers.

Optimizing ROA Efficiency Ratios Across Regional Registries

Regional efficiency diverges sharply. RIPE NCC operators average 6.6 prefixes per ROA while ARIN and LACNIC lag at 1. This disparity directly impacts validator load, as fragmented objects force routers to process excessive cryptographic signatures for identical address space. Operators must audit their prefix-to-ROA ratios against these regional benchmarks to identify unnecessary granularity that strains local validation infrastructure.

Strict ROA MaxLength configuration remains necessary even when aggregation improves, because broad masks still permit unauthorized subnets to validate as legitimate. Implementing domain metadata checks during upstream provisioning complements this by verifying identity before any route object creation occurs. Aggregation lowers memory consumption on edge routers, yet operators must verify that merged objects do not inadvertently authorize unused space.

Operational Steps for Securing Upstream Provisioning

Implementation: ROA MaxLength Discipline and Prefix Specificity Constraints

Set maxLength values to the exact prefix length of deployed subnets to prevent validating unauthorized specifics. Broad configurations allow attackers to announce more-specific prefixes that remain technically Valid under Route Origin Verification.

1. Audit existing ROAs for prefix lengths exceeding actual subnet masks.
2. Restrict maxLength to the deepest specific prefix currently announced.
3. Reject customer requests for broader ranges without documented justification.
4. Implement automated alerts for ROA changes increasing prefix allowance.

Restrictive policies require frequent updates during network renumbering events. Efficiency varies by region; RIPE NCC users average 6.6 prefixes per ROA, suggesting tighter aggregation than other registries. High validator load results from fragmented objects common in regions with lower efficiency ratios.

Deploying ASPA objects requires publishing valid customer-to-provider relationships in the RPKI to stop path forgery.

1. Generate ASPA records defining authorized upstreams for each customer ASN within the operator's portfolio.
2. Submit these objects to the local RIR registry, ensuring the AS path validation logic has authoritative data.
3. Configure border routers to enforce reject policies on any path violating the published provider authorization list.

This process blocks the social engineering vector used in July 2025, where attackers spoofed the ASN Without ASPA, routers accept paths from unauthorized providers if the origin signature is valid. The publication of specific case studies Operators must treat upstream provisioning as a security boundary requiring cryptographic proof rather than administrative trust.

Coordination latency creates a window of vulnerability; providers cannot enforce policies until customers publish their ASPA records. This dependency leaves legacy paths viable for exploitation. Failure to align AS path permissions with physical topology leaves the network exposed to stealthy redirection attempts.

Validating Upstream Customer Identity to Prevent Fraudulent Requests

Verify corporate identity against RIR records before enabling any BGP session to block fraudulent provisioning requests.

1. Cross-reference the applicant's ASN with RIR delegation data to confirm legitimate ownership status.
2. Contact registered phone numbers directly, rejecting forged Letters of Authorization that lack verbal confirmation.
3. Analyze domain metadata for age and similarity patterns that indicate impersonation attempts.
4. Require multi-party coordination across Network Operator Groups to validate unusual transit requests.

The July 2025 incident proved that attackers exploit weak onboarding rather than technical protocol flaws. That multinational provider failed to validate corporate identity, allowing a spoofed ASN to inject traffic. This gap persists because operators prioritize speed over security during customer onboarding. Enforcing strict identity frameworks by March 2026 will mandate these checks globally. Manual verification delays circuit turnaround times significantly. InterLIR recommends integrating automated RIR lookups into provisioning workflows to balance speed and security. Without this step, ASPA objects remain useless because the underlying relationship data is already corrupted by fraud.