Just days ago, a Border Gateway Protocol (BGP) hijack was used as part of an attack on hosting software vendor Softaculous Ltd, the company behind the Softaculous auto-installer and the Virtualizor VM management platform.
In a blog post on the incident, the company explains that an attacker used a “technically valid TLS certificate” for their domains, in concert with a BGP hijack, to deliver a “malicious Virtualizor update package” to a “small number of installations”. They advise customers to follow a sequence of steps to check if they have been impacted.
What follows is a closer look at some of the technical details of this incident.
How did the attacker hijack this IP space?
Beginning at 20:57 UTC on 28 August 2026, a new prefix entered the global routing table. 162.55.80.0/24 was announced along the AS path:
… 6204 62390 24940This address range included IP addresses used for Softaculous’s software update endpoint as well as its client and billing site. It was a more specific hijack of the 162.55.0.0/16 normally originated by Hetzner Online (AS24940). The route likely originated with the penultimate AS in the path, NexonHost (AS62390), either through a compromise or a customer who took advantage of gaps in their security.
The hijack also included an AS path with a forged origin. Because the attacker appended 24940 as the rightmost Autonomous System Number (ASN) in the path, it was considered RPKI-valid for two reasons — the ROA required the origin to be AS24940 but also because it allowed the prefix length to be anywhere between 24 and 16. As a result, this route was RPKI-valid and would not be at risk of being dropped by ASes that reject RPKI-invalid routes.
Because there was no existing route for 162.55.80.0/24 to compete with, the announcement propagated as far as route filtering policies allowed. As a more specific prefix, it was preferred over the legitimate 162.55.0.0/16 route under the Internet’s longest-prefix-match routing behaviour, causing traffic destined for that address range to be directed to the hijacked route.
The timeline of the origination of 162.55.80.0/24 is depicted in Kentik’s BGP visualization in Figure 1. The graphic depicts the percentage of BGP vantage points that had 162.55.80.0/24 in their routing tables over time and can be interpreted as a measure of route propagation.
Figure 1’s visualization helps to illustrate the timeline of the presence of 162.55.80.0/24 in the global routing table. From the time it first emerged at 20:57 UTC on 28 August, the route pulsed on and off several times until the real AS24940 began announcing it nearly 12 hours later, at 08:44 UTC on 29 August. By 14:10 UTC the next day, AS24940 had withdrawn its route.
The hijack route returned at 19:55 UTC on 29 August and pulsed repeatedly until, once again, the real AS24940 intervened and began announcing 162.55.80.0/24 at 05:45 UTC on 30 August, at which time the hijack was withdrawn. At the time of this writing, AS24940 is still announcing 162.55.80.0/24.
As the visualization above depicts, the propagation of the hijack route was slightly lower than that of the legitimate route, so there was some route filtering happening that limited further propagation. Regardless, the hijack propagation was substantial and created the potential for widespread misdirection of traffic to 162.55.80.0/24.
How did the attacker get a valid TLS certificate?
The BGP hijack alone wasn’t enough to pull off this attack. Another critical piece to the puzzle is the issuance of valid TLS certificates to the attacker. The same flaw was exploited in the 2022 attack against KLAYswap, an online cryptocurrency exchange based in South Korea.
In their excellent post on that incident, Henry Birge-Lee and his colleagues at Princeton wrote,
Yet, ironically, KLAYswap and Kakao were properly using TLS, and it was not a vulnerability in the TLS protocol that was exploited during the attack. Instead, the attack exploited the false trust that TLS places in the routing infrastructure. \ … \ Using its BGP hijack, the adversary first targeted the PKI and launched a man-in-the-middle attack on the certificate distribution process. Only after it had acquired a valid digital certificate for the target domain did it aim its attack towards real users by serving its malicious JavaScript file over an encrypted connection.
Attackers exploit fundamental flaw in the web’s security to steal $2 million in cryptocurrency
TLS’s identity guarantee is only as trustworthy as the routing system that gets certificate validation traffic to the right place. To address this weakness, public Certificate Authority (CA) Let’s Encrypt has been doing Multi-Perspective Issuance Corroboration (MPIC) for several years.
In MPIC, instead of a CA validating domain control from a single vantage point (which a localized BGP hijack can spoof), the CA checks from multiple geographically and topologically diverse network locations simultaneously and requires a quorum to agree before issuing a certificate. A hijack that only reaches some vantage points gets caught by disagreement among the others.
However, in this case, because the hijack route was an uncontested more specific route, its global propagation created a quorum entirely controlled by the attacker.
Prevention and detection
Also in 2022, a BGP hijack successfully targeted the cryptocurrency service Celer Bridge, hosted by AWS. In the post I wrote at the time, I cited AWS’s then practice of using very liberal ROAs that allowed multiple origins and prefixes “ranging in size from a /10 all the way down to a /24” as a factor that limited RPKI Route Origin Validation’s (ROV) ability to help. In that post, I added,
An alternative approach to ROA creation would be to do what other networks such as Cloudflare and Comcast have done: set the origin and maximum prefix length to be identical to how the prefix is routed. While this approach incurs an overhead cost of updating an ROA every time a route is modified, it also leaves little room for alternate versions of the route to come into circulation.
What can be learned from recent BGP hijacks targeting cryptocurrency services?
AWS now does exact matches on its ROAs, but let’s be careful not to oversell the capabilities of RPKI ROV to save us from a ‘determined adversary’ such as this. We’ve always known that attackers can forge AS paths to render hijacks RPKI-valid. But had Hetzner Online used strict Route Origin Authorizations (ROAs) with maximum prefix lengths that matched its routes, the circulation of the hijack would have been greatly diminished, allowing MPIC to prevent the issuance of valid TLS certificates.
As was the case with the Celer Bridge attack, BGP monitoring could have alerted that a new /24 of Hetzner Online address space was being announced, although the forged origin may have caused it to appear legitimate.
But when this new /24 appeared with an unexpected upstream of NexonHost (AS62390), an alert should have drawn attention to this anomaly. The key detail here that would have distinguished this alert from the appearance of just another peer of Hetzner Online would have been that the new upstream was seen by the vast majority of BGP vantage points. In other words, this new prefix was getting exclusively transited by this relatively unknown hosting provider, and that could have caught the eye of the Hetzner Online NetOps team.
Conclusion
While RPKI ROV has meaningfully contributed to the reduction of routing mishaps, it is not designed to completely prevent an incident like this one. It works by reducing the propagation of leaked mis-originations, typically involving innocent mistakes. We’ve also seen the benefits of RPKI ROV during so-called ‘intentional, but also accidental’ hijacks, such as the blocking of Telegram in India back in June. Regardless, stricter ROAs could have allowed RPKI ROV to reduce the propagation of the hijacked route to the extent that MPIC could have prevented the issuance of a valid TLS certificate.
The infrastructure attacks like these highlight universal problems that aren’t restricted to cryptocurrencies or hosting software. Companies looking to secure their Internet-facing infrastructures need to deploy robust BGP and DNS monitoring of their infrastructure and any Internet-based dependencies they may have.
Companies should reject RPKI-invalid routes while creating strict ROAs for their IP address space by including maximum prefix lengths that match the prefix lengths used in their routes. In fact, RFC 9319, The Use of MaxLength in the Resource Public Key Infrastructure, states that it is a ‘best current practice’ that networks entirely avoid using the maxLength attribute in ROAs, except in certain circumstances. Leaving the maxLength field blank in a ROA has the same effect as setting the maxLength field to match the prefix. These steps can significantly reduce the window of opportunity for an attacker to subvert your Internet infrastructure.
Update
Following the publication of this blog post, Hetzner changed the ROA for 162.55.0.0/16 to include a maxLength of 16, thus removing the possibility of a similar sub-prefix attack in the future.
Hetzner did the same for the ROAs for 213.133.96.0/19 and 213.239.192.0/18. Prior to the hijack, they both had a maxLength of 24, and now they are 19 and 18, respectively. However, even after last week’s fixes to three ROAs, 50 of AS24940’s ROAs still show this pattern today. For example, 78.46.0.0/15 is routed as a /15, but the ROA allows up to /24 (a gap of 9), and most of the /16 blocks similarly allow /24 when only the /16 itself is routed. So the tightening found for 162.55.0.0/16 and two others appears to be partial; the same maxLength issue persists across most of their address space.
Additionally, Bryton Herdes of Cloudflare pointed out that Hetzner Online added an ASPA record to enumerate the list of authorized providers of AS24940. With this ASPA record in place, networks that check ASPA should be able to instantly reject routes with an AS_PATH that includes an upstream of AS24940 that is not on that list, such as AS62390 in this incident.
Doug Madory is the Head of Internet Analysis for Infoblox, where he works on Internet infrastructure analysis.
Originally published on the Kentik blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.