Orange Spain BGP Hijack 2024: RPKI Weaponized via Stolen RIPE Credentials
On January 3, 2024, Orange Spain — the Spanish subsidiary of the French Orange Group, operating AS12479 — suffered a BGP routing incident that knocked out approximately half of its internet traffic for several hours. What made this incident remarkable was its mechanism: the attacker did not exploit a BGP implementation vulnerability or misconfigure a peer's router. They simply logged into Orange Spain's RIPE NCC account, altered the company's RPKI Route Origin Authorizations, and made Orange's own BGP announcements cryptographically invalid. The very security system designed to protect BGP routing was weaponized against its own operator.
Background: RPKI and Route Origin Authorizations
RPKI (Resource Public Key Infrastructure) allows IP address holders to cryptographically assert which autonomous systems are authorized to originate routes for their prefixes. This is done through Route Origin Authorizations (ROAs) — signed certificates that specify a prefix, a maximum prefix length, and an authorized origin ASN. BGP routers at networks that implement RPKI validation drop announcements that are "RPKI-invalid" — where the announcing AS does not match any ROA for that prefix.
ROAs are managed through the member portals of the five Regional Internet Registries. An organization that holds IP address space from RIPE NCC, for example, logs into the RIPE portal to create, modify, and delete ROAs for that space. The portal is the control plane for RPKI: whoever controls the portal credentials controls the ROAs.
How the Attack Happened
The attacker obtained the username and password for Orange Spain's RIPE NCC member portal account. According to subsequent analysis by security researchers and RIPE NCC, the credentials had been stolen by an infostealer malware — a category of credential-harvesting trojan that exfiltrates browser-saved passwords, session cookies, and authentication tokens from infected machines. The stolen credentials were available in infostealer logs circulating in criminal forums.
The password for the RIPE NCC account was reportedly "ripeadmin" — an egregiously weak credential for an account with direct control over internet routing infrastructure. The account had no two-factor authentication enabled. RIPE NCC, like the other RIRs, offered 2FA but did not mandate it for member accounts at the time of the incident.
The attacker logged into the RIPE portal using the stolen credentials, identifying themselves in portal activity logs with the handle "Ms_Snow_OwO". Once inside, they took two actions:
- Created new ROAs that specified incorrect or invalid origin ASNs for Orange Spain's IP prefixes — making Orange's own announcements from AS12479 RPKI-invalid
- Potentially modified or deleted existing valid ROAs
With invalid ROAs in place, BGP routers at RPKI-validating networks worldwide began treating Orange Spain's route announcements as invalid and dropping them. Orange's own BGP sessions were functioning normally — the routers were announcing the correct routes. But a large fraction of the internet now discarded those announcements as RPKI-invalid.
The Irony of RPKI Weaponized
RPKI was designed to prevent BGP hijacks — scenarios where a malicious network announces someone else's prefix and attracts their traffic. In the canonical hijack scenario, RPKI protects the victim: networks that validate RPKI would reject the attacker's announcement because it lacks a valid ROA.
The Orange Spain incident inverts this completely. The attacker did not try to hijack Orange's traffic — they tried to make Orange's own legitimate announcements appear invalid. In an internet with high RPKI adoption, this is actually a more effective denial-of-service attack than a traditional hijack would be. Where a hijack only diverts traffic at networks that choose to forward it, a ROA invalidation attack causes traffic loss at every network that implements RPKI validation — which increasingly means the majority of the internet's traffic-carrying capacity. The more widely RPKI is deployed, the more damaging a ROA manipulation attack becomes.
This also highlights a difference between RPKI as a technical system and the security of the management infrastructure around it. The cryptographic integrity of ROAs themselves — the signed certificates — was not compromised. The certificates were validly signed by RIPE NCC's keys. The problem was that the attacker had legitimate authenticated access to the portal and used it to create validly-signed certificates with malicious content.
Timeline of the January 3, 2024 Incident
The attacker accessed the RIPE portal and modified ROAs in the early morning hours (UTC) of January 3, 2024. RPKI relying parties (router validation caches) fetch updated ROA data periodically; once the malicious ROAs propagated through the RPKI repository system, validating networks began dropping Orange Spain's announcements. Traffic loss was observed and reported publicly within hours.
Orange Spain's network operations center identified the anomaly by noticing the traffic drop in their monitoring systems and correlating it with the absence of expected route acceptance at upstream providers. Diagnosing an RPKI-driven route rejection requires checking RPKI validation state from external vantage points — a harder diagnostic path than standard BGP troubleshooting.
RIPE NCC responded to Orange Spain's report and worked with them to restore the correct ROAs. Once the valid ROAs were in place and the invalid ones removed, RPKI caches updated and validating networks resumed accepting Orange's announcements. The total traffic impact lasted several hours.
RIPE NCC's Response and Industry Changes
Following the incident, RIPE NCC announced a series of security improvements to the member portal:
- Mandatory two-factor authentication for all member portal accounts with RPKI management capabilities
- Email notifications for ROA changes, providing an alert mechanism when modifications are made
- Session anomaly detection to flag logins from unusual locations or devices
- Increased logging and audit trails for RPKI management actions
The other RIRs reviewed their own portal security practices in response. ARIN, APNIC, LACNIC, and AFRINIC all examined whether their own ROA management portals had similar exposure to credential-compromise attacks.
The incident also prompted discussion about whether the RPKI trust model needs to be extended. Currently, the RIRs are the root of trust for RPKI — their signing keys authorize the entire certificate hierarchy. This means that portal-level compromise at an RIR is a systemic risk. Proposals for additional safeguards include requiring time-delays before ROA changes take effect (giving operators time to detect and revert unauthorized changes), out-of-band notifications via multiple channels, and multi-party authorization requirements for ROA modifications.
Credential Security for Network Operators
The immediate lesson from the Orange Spain incident is that RIR portal credentials are as critical as access to production network devices. An account with ROA management access has the ability to disrupt routing for every IP prefix the organization holds — effectively the same capability as physical access to the organization's border routers, but accessible from anywhere on the internet.
| Security Control | Status Before Incident | Recommended State |
|---|---|---|
| Two-factor authentication | Available, not enabled | Mandatory for all RIR portal access |
| Password strength | "ripeadmin" — trivially weak | Long, random, unique credential |
| Credential management | Stored in browser, harvested by infostealer | Hardware security key or password manager |
| ROA change monitoring | No alerting configured | Automated alerts on any ROA modification |
| ROA change authorization | Single account, no review required | Multi-party approval for production changes |
The "ripeadmin" password is particularly notable: it suggests that the account may have been created with a temporary or default password that was never changed, or that the credential was set by someone who did not understand the access it controlled. Either scenario is a process failure, not just a technical one.
Connections to Other BGP Security Incidents
The Orange Spain incident sits in a broader pattern of routing security events. Traditional BGP hijacks like the 2018 MyEtherWallet attack exploit BGP's lack of authentication to announce prefixes the attacker doesn't own. The Rostelecom 2020 hijack and the 2010 China Telecom incident are further examples. RPKI was developed as the systematic defense against all of these — but as the Orange Spain incident demonstrates, the security of RPKI's management infrastructure is now a critical attack surface.
The incident also relates to the broader problem of internet infrastructure account security. RIR accounts, domain registrar accounts, and DNS provider accounts all represent keys to critical infrastructure. Compromising any of them can cause routing or resolution failures as severe as a BGP hijack or a direct network misconfiguration. Treating these credentials with the same security rigor applied to production network device access is now a baseline operational requirement.
Explore It Live
Examine Orange Spain's current routing and RPKI state:
- AS12479 — Orange Spain; see current prefix announcements and routing data
- AS3352 — Telefonica de Espana; Orange's Spanish competitor for comparison
- AS5400 — BT Group; another European carrier with significant RPKI deployment
Use the lookup tool to inspect any AS or prefix and see its current BGP routing state. RPKI validation status for prefixes is increasingly visible through tools like RIPE Stat and Cloudflare Radar, providing real-time monitoring of the kind that would have caught the Orange Spain ROA manipulation within minutes.