Hackers Didn’t Hack the Update Server. They Hijacked the Internet Instead

• The Mess: Attackers hijacked Internet routing for infrastructure used by Softaculous and Virtualizor, redirected update traffic to their own servers and delivered a malicious Virtualizor update to a small number of installations. The attack did not require breaking into the legitimate update server.

That’s what makes this one nasty.

The attackers went after the road instead of the destination.

Virtualizor is a VPS management platform used by hosting providers and infrastructure operators to create and manage virtual servers.

Its update infrastructure became part of a supply-chain attack after traffic intended for Softaculous systems was diverted through a Border Gateway Protocol, or BGP, hijack.

BGP is the system networks use to announce where Internet traffic should go.

If the wrong network successfully announces that it can reach an IP range, traffic can be sent in the wrong direction.

That’s exactly what happened here.

Between August 28 and August 30, traffic intended for Softaculous infrastructure was redirected toward attacker-controlled systems.

The affected infrastructure included services used for Virtualizor software updates.

The attackers then served a malicious update package to installations checking for updates while their traffic was being diverted. Virtualizor confirmed that the malicious package reached a small number of installations rather than the wider user base.

The attacker did not need the password to the update server.

They did not need to compromise the company’s source code repository.

They did not need to replace the legitimate package on the official infrastructure.

They simply convinced part of the Internet to send update requests somewhere else.

And then answered those requests.

• The Damage: Some affected Virtualizor systems received a malicious update that could establish persistent root-level access on infrastructure used to manage virtual servers.

This is where the story stops being an interesting networking incident and becomes a serious supply-chain compromise.

HTTPS did not save the affected update requests.

According to reporting on the incident, the attacker obtained and used a technically valid TLS certificate for Softaculous domains while the traffic was being redirected.

That meant affected systems could communicate with the attacker-controlled infrastructure without necessarily seeing a certificate warning.

The connection looked encrypted.

The domain appeared valid.

The update request worked.

The package was malicious.

A hosting provider investigating the incident reported that five out of 34 checked Virtualizor hypervisors had sustained root-level compromise.

That figure should not be treated as the total number of affected systems worldwide.

It represents one provider’s investigation.

Virtualizor itself said it could not determine exactly how many installations may have received the malicious package because the diverted traffic never reached its legitimate infrastructure logs.

And that is the ugly part.

The vendor cannot simply open its logs and count every victim.

When the traffic was stolen at the routing layer, some of the affected update requests never arrived where they were supposed to go.

The update infrastructure was effectively bypassed.

One independent reconstruction of the incident highlighted another uncomfortable technical problem: the update client relied on the HTTPS channel rather than independently cryptographically verifying the update package itself.

That distinction matters.

TLS protects the connection.

Package signing verifies the software.

Those are not the same thing.

If an attacker can redirect traffic and successfully impersonate the update endpoint with a valid certificate, HTTPS alone does not necessarily tell the update client whether the package itself came from the legitimate publisher.

That turns a routing attack into a software supply-chain attack.

The reported indicators of compromise also suggest the attackers were not simply experimenting.

The malicious update was associated with persistence capable of surviving beyond the initial compromise.

For a hosting provider, that is particularly dangerous.

A compromised Virtualizor server can sit at the infrastructure layer managing virtual machines.

The victim isn’t necessarily just one website.

The victim can be the system responsible for creating and controlling other servers.

• The Fix: Virtualizor operators should immediately review systems that checked for updates during the affected period, inspect for persistence and root compromise, rotate credentials and rebuild confirmed compromised hypervisors from trusted images.

Virtualizor has urged operators to check their installations for signs of compromise.

Administrators should pay particular attention to systems that contacted the update infrastructure during the BGP hijacking window.

A normal-looking successful update does not automatically mean the system received a legitimate package.

Infrastructure teams should investigate unexpected services, modified system files and unexplained persistence.

One publicly reported indicator is a suspicious systemd service associated with the malicious activity.

But defenders should not limit their investigation to a single filename.

Attackers can change filenames.

They can change service names.

They can change payloads.

The important question is whether the hypervisor’s integrity can still be trusted.

If root-level compromise is confirmed, this is not a “delete the suspicious service and move on” incident.

A hypervisor is infrastructure with privileged access.

Treating a root compromise like ordinary malware cleanup is how attackers get to come back later.

Affected organizations should also rotate credentials that may have been accessible from compromised systems.

That includes administrator passwords, API keys, SSH credentials and any secrets stored on or reachable from the affected infrastructure.

And this incident should trigger a broader audit of update mechanisms.

If your software updater trusts the network channel but does not independently verify the cryptographic signature of the package it installs, this attack should make you uncomfortable.

Because the same basic trick can work elsewhere.

Bugstoday Opinion

Supply-chain attacks usually have a familiar headline.

Someone hacked the vendor.

Someone stole a signing key.

Someone compromised the build server.

This one took a different route.

The attackers hijacked the road.

They didn’t need the update server.

They just needed the Internet to temporarily believe their server was the update server.

Then TLS did what TLS was supposed to do.

It encrypted the connection.

Unfortunately, it encrypted the connection to the attacker.

That’s the lesson hiding inside this incident.

Encryption is not magic.

A secure connection does not automatically mean you received trustworthy software.

And when a privileged update client downloads infrastructure software capable of running with root-level access, trusting the network alone becomes a very expensive assumption.

This attack also exposes something deeper.

We like to think of the Internet as a collection of secure services.

But before your request reaches a secure service, the Internet has to decide where to send it.

BGP makes that decision.

And sometimes BGP can be lied to.

When that happens, the difference between a routing incident and a full supply-chain compromise may come down to one question:

Did the updater verify the package — or did it only trust the connection?

In this case, attackers found out.

They didn’t hack the update server. They made the Internet send the update request to them.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

Virtualizor — Security Incident: BGP Hijacking

The Hacker News — BGP Hijack Delivers Malicious Virtualizor Update That Establishes Persistent Root Access

SecurityWeek — Malicious Virtualizor Update Served via BGP Hijacking

BleepingComputer — Hackers Push Malicious Virtualizor Update in BGP Hijacking Attack