Case Study: Route Hijacking, RPKI, and Social Engineering#

Carlos Martínez (LACNIC), Guillermo Cicileo (LACNIC)

• Why: A fully investigated postmortem of a deliberate BGP hijack against an RIR itself, combining routing security with social engineering of the transit-provisioning trust chain. Concrete postmortems with real attribution are exactly what this operator program should up-rank.
• What: In July 2025, LACNIC's AS28001 and its São Paulo prefixes were hijacked intermittently in three windows (20, 15, and 5 minutes across July 9–12), degrading access to LACNIC's services from the rest of the Internet. The attacker — an Indonesian AS (142395) — impersonated both LACNIC's prefixes and its ASN, which is why RPKI/ROA origin validation did not help: the forged announcements carried the authorized origin AS. The enabling mechanism was a forged Letter of Authorization (a fake PDF with a scanned signature) accepted by an international transit provider; the Indonesian ISP involved was itself partly a victim. Resolution ran through APNIC's security team and APJII in Indonesia.
• How: Interactive walkthrough of how peering/transit agreements are verified in practice today — LoAs checked against WHOIS/IRR, which the deck describes as "as precarious as it looks" — why prefix+ASN impersonation cannot be accidental (vs. common accidental prefix mis-origination), the cross-RIR coordination path, and why this attack class is precisely what ASPA is designed to catch.
• Where applicable: Every operator that accepts customer announcements on the basis of LoA documents — i.e., nearly all transit providers — and anyone treating RPKI ROV as sufficient protection. Broadly applicable; the defensive lesson (treat PDF authorization letters as untrusted; anchor verification in cryptographic objects) is universal.