A sophisticated Border Gateway Protocol (BGP) hijacking incident recently targeted hosting software vendor Softaculous Ltd, the developer behind the widely used Softaculous auto-installer and the Virtualizor virtual machine management platform. The cyberattack combined a precise routing manipulation with a valid Transport Layer Security (TLS) certificate to successfully distribute a malicious software update to a targeted subset of customer installations.
In the wake of the incident, Softaculous published an advisory detailing the security breach and urging affected customers to review their systems by following specific verification steps. The attack highlights ongoing vulnerabilities at the intersection of global internet routing and Public Key Infrastructure (PKI) trust models, illustrating how attackers can subvert core protocols to compromise software supply chains.
How the Attacker Hijacked the IP Space
The malicious campaign began unfolding at 20:57 UTC on August 28, when a novel prefix suddenly appeared within the global internet routing table. An address block designated as 162.55.80.0/24 was announced along a specific Autonomous System path involving AS6204, AS62390, and AS24940.
This particular address range encompassed critical infrastructure IP addresses utilized by Softaculous for its software update endpoints, as well as its primary client portal and billing websites. The announcement functioned as a more specific route override of the broader 162.55.0.0/16 block traditionally originated by hosting provider Hetzner Online, which operates under AS24940. Industry analysts indicate that the route likely originated through the penultimate Autonomous System in the path, NexonHost operating under AS62390, either via direct infrastructure compromise or by exploiting security gaps associated with a customer account.
Crucially, the attacker constructed an AS path featuring a forged origin. By appending AS24940 as the rightmost Autonomous System Number within the path, the announcement satisfied the validation criteria for Resource Public Key Infrastructure (RPKI). Because the existing Route Origin Authorization (ROA) permitted prefix lengths ranging anywhere from 16 to 24, the fabricated announcement was treated as RPKI-valid. This prevented participating networks that routinely reject RPKI-invalid routes from dropping the malicious traffic.
Because no legitimate competing route existed for the specific 162.55.80.0/24 prefix at the time, the announcement propagated globally wherever upstream route filtering policies permitted. Under standard internet routing mechanics governed by the longest-prefix-match rule, routers preferred the newly introduced, more specific route over the legitimate 162.55.0.0/16 allocation, effectively redirecting all traffic destined for those endpoints toward the attacker’s infrastructure.
Telemetry data capturing the BGP propagation timeline reveals that the malicious prefix pulsed intermittently over several days. The unauthorized route first emerged on August 28 before disappearing when the legitimate network operator, Hetzner Online, intervened nearly twelve hours later to announce the prefix, subsequently withdrawing it on August 29. However, the fraudulent route reappeared later that evening, continuing to pulse until Hetzner Online reasserted control and stabilized the routing tables. While global propagation of the hijacked prefix was partially limited by regional route filtering, the reach was extensive enough to create severe risks of widespread traffic misdirection.
The Role of Valid TLS Certificates in Protocol Exploitation
The BGP hijack alone did not represent the entirety of the attack vector; a vital component involved obtaining a cryptographically valid TLS certificate for the targeted domains. This technique mirrors methodologies observed in past high-profile incidents, such as the 2022 attack against the South Korean cryptocurrency exchange KLAYswap.
Security researchers specializing in internet infrastructure analysis have long noted that web security protocols place implicit trust in the underlying routing infrastructure. During the Softaculous incident, the adversary leveraged their BGP manipulation to establish a man-in-the-middle position during the certificate validation procedure. By intercepting domain validation requests, the attacker successfully acquired a legitimately signed digital certificate from a public Certificate Authority before serving malicious payloads over an encrypted connection.
The foundational identity guarantees provided by TLS are only as robust as the routing protocols responsible for delivering certificate validation traffic to its proper destination. To mitigate this inherent architectural weakness, public Certificate Authorities like Let’s Encrypt have increasingly adopted Multi-Perspective Issuance Corroboration (MPIC).
Under an MPIC framework, a Certificate Authority validates domain control simultaneously from multiple geographically and topologically diverse network locations, requiring a consensus quorum before issuing any certificate. In theory, localized BGP hijacks are thwarted because vantage points outside the attacker’s immediate network influence will register discrepancies. However, because the Softaculous attack utilized an uncontested, highly propagated more specific prefix, the global validation quorum was entirely subverted, allowing the attacker to secure the fraudulent certificate without encountering resistance from diverse perspective checks.
Prevention, Detection, and Structural Defenses
Internet security experts emphasize that while RPKI Route Origin Validation (ROV) has drastically reduced the frequency of accidental routing mis-originations and simple leaks, it is fundamentally not designed to stop a determined adversary employing forged AS paths. Nevertheless, stricter operational configurations can significantly raise the barrier to entry for attackers.
A critical vulnerability in this incident stemmed from loose ROA definitions that permitted a wide range of maximum prefix lengths. When network operators configure ROAs with expansive maximum prefix length allowances—such as permitting a /24 allocation inside a broader /16 block—they inadvertently widen the attack surface for malicious sub-prefix announcements. Implementing strict ROAs where the maximum prefix length exactly matches the length of the natively routed block leaves virtually no operational window for unauthorized alternate routes to gain global circulation. Furthermore, if strict ROAs had been in place, the resulting reduction in route propagation would have enabled multi-perspective validation mechanisms to successfully flag the discrepancy and block the issuance of the fraudulent TLS certificate.
Advanced BGP monitoring systems remain an essential line of defense for enterprises managing internet-facing assets. In this scenario, the unexpected emergence of a new /24 prefix within Hetzner’s address space—combined with an unusual upstream transit provider like NexonHost—should have immediately triggered anomalous routing alerts. Monitoring the global visibility of such announcements can provide network operations teams with the early warnings necessary to intercept and neutralize infrastructure attacks before software distribution channels are compromised.
Industry standards are steadily evolving to address these systemic vulnerabilities. Best current practices, outlined in technical frameworks such as RFC 9319, explicitly advise network operators to avoid utilizing overly permissive maxLength attributes within their ROAs unless strictly necessary. Leaving the maxLength field unconfigured or matched directly to the announced prefix substantially restricts the capabilities of threat actors attempting to exploit routing trust.
In the immediate aftermath of the disclosure, infrastructure providers began implementing stricter controls. Hetzner Online updated its resource records to restrict broader address blocks to exact maximum prefix lengths, effectively closing the door on similar sub-prefix attacks across several core ranges, while industry observers continue to advocate for the broader deployment of Autonomous System Provider Authorization (ASPA) records to cryptographically verify authorized upstream routing relationships. As infrastructure threats continue to target software vendors and cloud services alike, organizations must integrate comprehensive BGP and DNS monitoring to protect their foundational internet dependencies.
Leave a Reply