RPKI vs social engineering: A case study in route hijacking

The incident

The first report came from a user who could not send email. Messages were accepted by the server but never reached the recipient. At first, this looked like a routine system issue because it occurred late in the evening, so the team planned to investigate the next day. A closer review showed that part of LACNIC’s address space was being originated by networks that were not authorized to do so.

Analysis showed that the attacker spoofed the Autonomous System Number (ASN) in a way that avoided creating an invalid state. This choice helped the false announcements propagate. The attacker also redirected traffic through an upstream that was later confirmed to be another victim, not an accomplice.

Three short hijack events occurred:

• 2025‑07‑09 19:47 (UTC −3) for about 20 minutes
• 2025‑07‑10 20:34 (UTC −3) for about 15 minutes
• 2025‑07‑12 10:13 (UTC −3) for about five minutes

No further activity followed. This ASN had a history of similar events across AFRINIC, ARIN, LACNIC, and APNIC, which supported the conclusion that this was deliberate rather than accidental.

The team was also able to reconstruct some of the attacker’s infrastructure. They identified an email server, a web server, and another system listening on many ports, which may have been a scanning tool or honeypot.

The activity showed clear signs of reconnaissance. The announcements appeared in short bursts, at random times, and only reached a small part of the Internet. The attacker also depended on a forged upstream relationship to make the traffic flow. These behaviours matched other attacks where adversaries test how far invalid or suspicious routes will propagate.

The investigation

LACNIC escalated the case to APNIC, which then contacted APJII/IDNIC as the National Internet registry (NIR) of Indonesia, which delegated the ASN. The findings were unexpected: The legitimate ASN holder had no involvement. They were a small ISP with a local upstream, and they were also a victim. A malicious actor had impersonated them using forged documents and a domain name similar to the real organization.

The attacker convinced a multinational upstream provider to enable transit for the hijacked ASN (which we’ll call ‘AS X’). Once the BGP session was active, the attacker used AS X only as transit and injected short announcements from several spoofed origin ASNs behind it. These bursts lasted only minutes and disappeared quickly, which made them difficult to trace.

Coordination across LACNIC, APNIC, and APJII/IDNIC was essential. This joint effort confirmed the fraud, identified the upstream victim, and demonstrated the value of cross‑RIR and NIR escalation paths.

Attack flow

Figure 1 — Overview of the impersonation and upstream provisioning process. Source.

Figure 1 shows the legitimate ASN holder, the hijacked ASN, and the bad actor using forged identity documents to request transit from a multinational provider. The provider enables BGP, and the attacker issues short, random announcements using the hijacked ASN.

The attacker did not bypass RPKI. Instead, they exploited weak identity‑verification processes in upstream provisioning. The multinational provider failed to validate the customer’s corporate identity or domain ownership before enabling BGP, which allowed the unauthorized announcements to proceed. The resulting hijacks propagated widely because Route Origin Validation (ROV) is inconsistently deployed, and many networks still accept NotFound routes. Additionally, the presence of broad ROA MaxLength values increased the scale of the incident by allowing more specific prefixes to appear valid.

Incident resolution

APNIC, LACNIC, APJII/IDNIC, and the legitimate ASN holder confirmed that the upstream request was fraudulent. The upstream provider then terminated the BGP session. They also agreed that the incident could be used as an example for the routing security community.

Speakers at the session also apologised to the small ISP, which had initially been suspected until the investigation confirmed they were another victim.

Routing security lessons

Several broader lessons emerge from this incident, highlighting where current routing security practices can be strengthened.

ROA MaxLength discipline

Broad MaxLength values allow unintended, more‑specific routes to validate under ROV. Operators should:

• avoid broad MaxLength
• match MaxLength to real operational needs
• review ROAs regularly

This is general best practice and not specific to this incident.

ASPA and unauthorized upstreams

ASPA can prevent forged upstream relationships. If ASPA were deployed, this attack would have been far harder to perform. Enforcement depends on operator policy and router support.

Figure 2 — Recommended routing security controls. Source.

Figure 2 highlights two key defences: Setting precise ROA MaxLength values and using ASPA to prevent unauthorised upstream providers.

Upstream provisioning is a security boundary

The attack targeted the onboarding process used by large providers. Strengthening this process is essential. Providers should:

• Check RIR and Internet Routing Registry (IRR) records
• Call registered contacts to confirm requests
• Reject letters of authorisation (LOAs), which are easy to forge
• Check domain metadata, including age, similarity, and registration patterns
• Adopt ASPA validation as support becomes available

Multi‑party coordination matters

Routing incidents cross organizational and regional boundaries. Coordination across RIRs, NIRs, operators, and Network Operator Groups (NOGs) helps confirm identities, match patterns, and contain incidents.

Conclusion

Routing security covers more than cryptography. ROAs and ASPA reduce technical risks, but they cannot stop attacks that exploit weak identity checks. Stronger ROA discipline, ASPA adoption, better onboarding verification, and continued coordination across the Internet community will reduce the chance of similar attacks. Combining routing‑layer controls with identity‑layer checks will create a more resilient Internet.

Watch Carlos’ and Sanjaya’s Routing Security SIG presentation during APRICOT 2026/APNIC 61.