URGENT: Virtualizor Compromised (31st AUG)

neighhouse

@AirnodeHosting do y'all use virtualizor?

zed

https://www.bleepingcomputer.com/news/security/hackers-push-malicious-virtualizor-update-in-bgp-hijacking-attack/

torchbyte

After a quick look at the java file installed as a service by this hack I have come to think all it was meant to do was participate in a botnet for DDoS attacks, especially against Minecraft servers

Glad to see the hack was "wasted" on this kind of thing

It also scraped data about the server like CPU count, RAM etc. and perhaps even VM count

tentor

Why it ends up being Minecraft DDoS related every freaking time?

default

If everybody switches to Virtfusion, wouldn't that mean that almost every cloud would be based on a single system? Virtfusion will have a huge target painted on it. Maybe competition is good, even if sometimes it fails.

forest

@torchbyte said: After a quick look at the java file installed as a service by this hack I have come to think all it was meant to do was participate in a botnet for DDoS attacks, especially against Minecraft servers

No fucking WAY lmfao

AndreyGubanov

@neighhouse said:
@AirnodeHosting do y'all use virtualizor?

AlbaHost

In general, I would be careful with the argument that an upstream firewall alone means a node could not have been compromised.

If the Virtualizor update infrastructure/IP space was hijacked and controlled by the attacker, the hypervisor itself would still initiate an outbound connection to what it believed was the legitimate Virtualizor update network. Since Virtualizor updates are automatic, an inbound firewall would normally not prevent that.

The more important point is that once malicious code is delivered through the update mechanism and executed as root, the attacker can potentially execute arbitrary commands, modify files, create users, install services, alter firewall rules, deploy additional payloads, or establish outbound C2 connections. At that stage, SSH is only one of many possible access methods.
In our case, for example, the attacker even modified the local firewall and allowed their own 193.32.127.0/24 subnet to our non-standard SSH port, but that was simply one post-compromise action.

The initial problem was already root-level code execution through the compromised update path.

It is also interesting that @Jamie_DreamIT , and ourselves seem to be among the few publicly confirming infections. Maybe we're the black sheep. 😉 I genuinely hope everyone else avoided it, but given the automatic update mechanism and the nature of the compromise, I would be very cautious about assuming a system was unaffected purely because a particular inbound path was firewalled.

Mainfrezzer

@AlbaHost said:
In general, I would be careful with the argument that an upstream firewall alone means a node could not have been compromised.

If the Virtualizor update infrastructure/IP space was hijacked and controlled by the attacker, the hypervisor itself would still initiate an outbound connection to what it believed was the legitimate Virtualizor update network. Since Virtualizor updates are automatic, an inbound firewall would normally not prevent that.

The more important point is that once malicious code is delivered through the update mechanism and executed as root, the attacker can potentially execute arbitrary commands, modify files, create users, install services, alter firewall rules, deploy additional payloads, or establish outbound C2 connections. At that stage, SSH is only one of many possible access methods.
In our case, for example, the attacker even modified the local firewall and allowed their own 193.32.127.0/24 subnet to our non-standard SSH port, but that was simply one post-compromise action.

The initial problem was already root-level code execution through the compromised update path.

It is also interesting that @Jamie_DreamIT , and ourselves seem to be among the few publicly confirming infections. Maybe we're the black sheep. 😉 I genuinely hope everyone else avoided it, but given the automatic update mechanism and the nature of the compromise, I would be very cautious about assuming a system was unaffected purely because a particular inbound path was firewalled.

Certainly worth considering outbound rules in general for certain systems. I do have 1 particular server that has some, let's call it, paranoid lockdown on it

AlbaHost

@Mainfrezzer said:

@AlbaHost said:
In general, I would be careful with the argument that an upstream firewall alone means a node could not have been compromised.

If the Virtualizor update infrastructure/IP space was hijacked and controlled by the attacker, the hypervisor itself would still initiate an outbound connection to what it believed was the legitimate Virtualizor update network. Since Virtualizor updates are automatic, an inbound firewall would normally not prevent that.

The more important point is that once malicious code is delivered through the update mechanism and executed as root, the attacker can potentially execute arbitrary commands, modify files, create users, install services, alter firewall rules, deploy additional payloads, or establish outbound C2 connections. At that stage, SSH is only one of many possible access methods.
In our case, for example, the attacker even modified the local firewall and allowed their own 193.32.127.0/24 subnet to our non-standard SSH port, but that was simply one post-compromise action.

The initial problem was already root-level code execution through the compromised update path.

It is also interesting that @Jamie_DreamIT , and ourselves seem to be among the few publicly confirming infections. Maybe we're the black sheep. 😉 I genuinely hope everyone else avoided it, but given the automatic update mechanism and the nature of the compromise, I would be very cautious about assuming a system was unaffected purely because a particular inbound path was firewalled.

Certainly worth considering outbound rules in general for certain systems. I do have 1 particular server that has some, let's call it, paranoid lockdown on it

Yeah, agreed. I think outbound filtering is something worth looking at more seriously after this.
That said, if the Virtualizor update IPs themselves were hijacked, the initial update traffic could still have looked completely legitimate. But it definitely could have helped afterwards by blocking C2 traffic or any other unexpected outbound connections.