Hackers Hijack Internet Route to Deliver Malicious Virtualizor Update

The attackers made use of a BGP routing attack to change the way that certain Virtualizor customers can connect to Softaculous update servers.

The attacks took place from August 28 at 20:57 UTC and continued until around 06:10 UTC on August 30. The BGP routing was inactive the whole time. The attack came in two waves.

Softaculous, the maker of Virtualizor says, a small number of servers got a bad update. It has not found a bad update for its other products.

The company cannot name every affected server. The reason is simple. The bad update came from the attacker’s server. It did not pass through Softaculous systems or logs. Normal routing is restored, and the company asks Virtualizor operators to inspect their servers.

What Happened to the Virtualizor Update System

The attack targeted the 162.55.80.0/24 IP range. The range belongs to prominent hosting company Hetzner’s network. Softaculous used IPs in that range for key services. They included the Virtualizor update service and the Softaculous client and billing site.

The attackers sent out a false BGP route for the range. BGP helps networks on the internet find the right path to an IP address. The false route was more exact than Hetzner’s normal route. So, networks that took the false route sent some traffic to the attacker instead.

The route came from AS62390, which Softaculous identifies as NexonHost. It passed through AS6204, a network run by Zet.net.

The route spread far across the internet. Softaculous checked data from 368 RIPE route collectors. All 368 saw the false route at some point. During active parts of the attack, about 72% had it as their best path.

That 72% figure does not mean hackers got 72% of internet traffic. It measures how widely the false route spread across RIPE’s network view.

The Attack Came in Two Waves

The first wave began on August 28. It ran until about 08:50 UTC on August 29. Hetzner then started to announce the affected IP range itself. That move cut the route to the attacker to almost zero.

The fake route returned at around 20:00 UTC on August 29. The second wave continued until approximately 06:10 UTC on August 30.

The route also changed many times. That made the attack come and go for different networks. Ars Technica noted gaps in routing security and the lack of package signature checks in Softaculous’s update process.

A Valid Security Certificate Made the Attack Harder to Spot

The attackers also got a valid TLS certificate for Softaculous domains from Let’s Encrypt.

They could do this because the automatic domain check also went through the false route. The attacker could then use the certificate on the fake server. This meant affected connections did not have to show a normal certificate warning.

The false route sent users to the attacker’s server. The valid certificate made the server look more like the real one. The attackers then served a bad Virtualizor update to some systems that checked for updates during the attack.

Why the Update was Able to Run

The Virtualizor update client did not yet check package signatures. A signature can help a program confirm that an update came from the real vendor. Without that check, a server could accept a changed update file if the request reached the attacker’s server.

Softaculous confirmed that a bad Virtualizor update reached a handful of servers. The company cannot give users a full list of affected systems because the bad downloads never reached its logs. Softaculous is telling all Virtualizor admins to check their servers. That does not mean hackers hit all Virtualizor servers.

What Virtualizor Admins Should Check

Softaculous has named a key sign of infection: /etc/systemd/system/java-jre-update.service. Admins who find this file should not delete it at once. Softaculous wants them to contact the company first. This can help keep evidence for the review.

Admins should also reset their Virtualizor API keys. They should limit API access to trusted IP addresses and also check for unknown SSH keys and new user accounts. They should also look for odd scheduled tasks and strange outgoing network traffic. Hackers claimed to have stolen personal data from 120 Israelis and demanded $30,000 in Bitcoin. The case shows how stolen data can fuel extortion.

Users of the Softaculous Client Site Should Also Act

The same IP range served the Softaculous client and billing site. Anyone who signed in during the attack window should change their password. They should do the same on any other site where they used that password.

Anyone who entered card details during the same period should check their account and card statements. Softaculous says it does not process card payments on its own servers. Payment gateways handle those payments.

Other Softaculous Products have not been Linked to the Attack

Softaculous says it has not found a bad update for Backuply, Softaculous, SitePad, Webuzo, or its other products. The company says its review continues.

The incident also showed a weak point in the update process. A BGP attack can send users to the wrong server. A package signature can help stop a bad file from running after that.

Softaculous says it plans to add digital signatures to its software packages. That would give update clients a way to check that future files came from the real source.

For now, Virtualizor admins should not rely on the small number of confirmed cases. The company cannot see every bad update served during the route hijack.

The safest step is to check each Virtualizor server, reset exposed keys, and review access for signs of abuse. With normal routing now restored, Softaculous has put up the fake certificate for revocation. Also, a new Virtualizor version 3.2.9.9 is available now. The company released it on September 1.