New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
ransomware via Virtualizor exploit ?
Shakespeare
Member
Is it possible to switch back to SolusVM?
@DediRock
@DeluxHost
@rarecloud
@ColoCrossing
Thanked by 1DediRock
Comments
Ok
virtfusion?
Solusvm v2 could be a good alternative.
just don't use providers who use virtualizor, always helps to vote with your wallet.
@Shakespeare
Can you shed some light on the claim about ransomware via a Virtualizor exploit?
Ransomware doesn’t just magically appear on a node and start encrypting data. In almost all cases, it’s the result of insufficient security controls on the host itself (exposed services, weak credentials, outdated software, poor isolation, etc.), not the mere presence of a provisioning or management module.
That said, I’m not aware of the exact mechanics of a ransomware scenario that specifically originates from a Virtualizor exploit, which is why I’m asking for clarification.
If there’s a documented attack path, CVE, or real-world example where Virtualizor was the entry point leading to node-level compromise and ransomware deployment, I’d genuinely like to understand the details. Virtualizor was an option to migrate our services but we dropped that after 2 moths of tests, because of technical limitations of the platform/module, but the GUI was eye candy versus what we have now.
Thanks!
EDIT:
If you refer tot his: https://lowendtalk.com/discussion/214073/what-happened-to-cloudcone-was-it-hacked#latest
This clearly falls under weak credentials, exposed management surfaces, insufficient isolation, or outdated software, rather than the mere presence of a provisioning or management platform.
Most likely, this was enabled by public exposure of the management plane in some form (panel access, execution path ), which is fundamentally poor security planning for a Tier-0 control system.
Funny, we just had a reply to why it is a bad idea to give GUI access to proxmox nodes to customers yesterday.
Sorry for the parties involved, shit happens.
No Virtualizer, no exploit.™
Disable Virtualizer. Be like DaddyRock.
I would go with, no public access to nodes, no exploit.™ - there you go, I fixed it for you
Through what, QEMU Guest Agent?
Root Virtualizor GUI gives you a terminal option, similar to cPanel can give you terminal as a shared user although that is jailed shell to copy files/extract zips ect
Not via QEMU Guest Agent.
QEMU Guest Agent runs inside the VM and can only do what the VM itself is allowed to do (shutdown, IP reporting, filesystem freeze, etc.). It has no authority over the host and cannot execute arbitrary commands on the node.
What’s being discussed here is host-level access via the management plane.
In the CloudCone case, attackers abused the control panel’s ability to open a host terminal (root shell) on connected nodes. That’s entirely outside the VM and outside anything a customer VM can influence.
Think of it as:
QEMU Guest Agent → VM → limited, opt-in, guest-side helper
– Runs inside the VM
– Can only perform explicitly allowed actions (shutdown, IP reporting, fs-freeze, etc.)
– No host visibility, no hypervisor control
Panel “Server Terminal” → Host → root shell → full control
– Runs on the hypervisor
– Full root access
– No VM boundary anymore
If you have root access on a node, you can do essentially anything:
At this level, the host:
sees all VMs
controls their disks, memory, and network
can snapshot, mount, modify, or replace VM disks offline
can inject or observe data regardless of in-VM credentials
If someone has access to the management panel that grants host-level execution, VM passwords, guest agents, or “changing credentials” inside the VM become largely irrelevant.
This is exactly why exposing a Tier-0 management plane (panel GUI / terminal / API / whatever alse ) without strict isolation is such a high-risk gamble.
Different layers. Different threat models.
Even create a $7/y VM in my account? 🥺
to be serious I agree with you @host_c , thanks for detailed explanation
I understand that many people here are relatively new to this space, and I also recognize the appeal of “shiny” solutions that just work out of the box. That said, over the past decade, the industry has largely shifted its focus from quality to quantity, whether we’re talking about software or hardware. ( most probably due to the fact that everyone "wants the new model" each 3 moths )
Some who’ve been around longer tend to invest more effort into building limits, filters, ACLs, and layered protections, but that translates into a much longer time to implement the new changes the majority wishes for.
Experience teaches you that convenience often comes at the cost of control, and control is what ultimately keeps infrastructure safe.
To be clear, I’m not blaming CloudCone in any way. What they went through can happen to anyone — that’s the reality of running infrastructure at scale.
My point is simply to underline the need for greater attention to detail. New features and convenience layers should be postponed until there is reasonable confidence they are safe, at least within one’s own threat model and aligned with established best practices (and where applicable, RFCs or similar standards).
Thanks for the explanation. I'm not impacted, but using the opportunity to learn. What does isolation look like in the context of a business running a multi-national operation where techs can't be physically connected to the node?
We offer an unlimited nodes, unlimited servers, unlimited clients whitelabel version of our control panel: https://cloudblast.io/whitelabel
And you are a piece of shit for writing a comment like this in the current situation.
Isolation in a multi-national operation is not easy, especially when engineers cannot be physically present at the node. Defining who has access, to what, under which circumstances, and through what kind of physical or logical path is extremely difficult to get right.
There is no magic formula and no single correct answer. It varies with:
What you consider “secure enough” today, you’ll often realize six months later was dangerously optimistic.
- this apples to the smallest host having 3 nodes in a basement, the mindset must be the same here, otherwise you will blow up on your own later down the road.
The approach that worked best for us was checklists. I borrowed that mindset from aviation: when pilots face an incident at 30,000 feet, they don’t have the luxury to do a "system scan and ask GPT". There’s no time, no margin, and no “pull over and fix it later.” They rely on predefined procedures because hundreds of souls — including their own — depend on it.
Infrastructure is similar. When something goes wrong ( aka shit hits a 30.000 RPM fan ), you don’t want creativity — you want process, checklists.
There’s no straight answer here, but my strong recommendation is to build infrastructure from the ground up, guided by RFCs and best practices, and not skip steps. Skipped steps don’t always hurt immediately, but they tend to bite you mid-run.
RFCs aren’t sacred texts, but they force you to answer uncomfortable questions early:
Plus, they have the habit of forcing you not to "improvise" as improvisations do not work well with standards.
As one concrete example: I personally cannot access our infrastructure from my laptop, from home, or from arbitrary locations. I won’t go deeper than that, as those details don’t belong on a public forum.
I’ll repeat what I consider the biggest recurring mistakes:
Yes, these controls are inconvenient. They slow things down. They frustrate people.
But convenience is temporary, a compromised platform is....... well, not ideal.
EDIT:
PS: when a provider skips most of the safeguards described above, what many would call best practices, customers usually love it. No 2FA, no KYC, no friction, no security checks. Deals sell fast, praise flows with "chicken", and everything feels smooth.
But when that same provider inevitably goes down, those very same customers who previously applauded the lack of controls and limits, are often the first to tear him apart publicly, labeling him incompetent or reckless.
Security rarely gets credit when it works. It only gets noticed when it’s missing.
but do you own the servers you use?
Looks like convoy panel. Is it convoy panel?
Mentally strong people don’t hide behind allowlists or separations.
Instead, we separate everything by signing keys.
https://github.com/pollere/DCT
The recipient will accept a command, only if it’s signed by a key that is authorized to issue such command.
Every command that can possibly exist must be covered by a schema that defines which keys may issue this command.
Any command that doesn’t match the schema or isn’t signed by an acceptable key will be dropped, either by the recipient or by a network router.
No addresses, no firewalls, just vibes and a data centric protocol that is fundamentally secure.
Yes we do, all of them
There are credible reasons to suspect there's a vulnerability in the Virtualizor WHMCS module, which is under active exploitation and has affected multiple hosts: https://www.virtualizor.com/docs/billing/whmcs-module/
It's important to note that it's only reasonable suspicion and nothing is proven at this point, but if this is occuring because of an exploit then things like 2FA, IP allow lists and vLANs probably won't help much because authentication is being bypassed and the permitted infrastructure is being abused to facilitate the hack.
It's possible that all the incidents are due to misconfigurations and/or mistakes by the affected hosts, but it's increasingly likely that a vulnerability is being exploited, (especially since a forum user has claimed responsibility):
https://lowendtalk.com/discussion/comment/4724181/#Comment_4724181
That's an interesting permission to ask for.
Translated: "cloudblast.io wants to search and connect to any device in your local network"
WARNING: MASSIVE RED FLAG
This is part of active fingerprinting. The website also checks for ad blockers and LLMs running on localhost.
They have either been hacked or give zero fucks about their visitors’ privacy, because the website goes far beyond normal user-profiling mechanisms.
At the very least, isolate management interfaces to your internal VPN. If you can get away with it, don't expose physical hosts to the internet. If you cannot, expose as little as possible. There is very little harm that can by done to a single wireguard port.
Run everything on the principle of least-privilege. Instead of letting your commands as root, do fine-grained ACLs for management activities. There are proper enterprise-ready solutions for this, but the "backyard" solution is to set up per-group permissions in your
sudoers.dfor running various commands, and then add technician/service accounts to only the groups they need to run. Your deployment system should have access to create VMs, but probably doesn't need access to filesystem operations beyond that. That way, if the deployment system gets pwned, the attackers can only create infinity VMs and not mount disks of those infinity VMs to encrypt shit.host_c talks about security vs convenience and how customers hate security. That is true, but that doesn't mean your techs shouldn't be using 2FA etc.
As for the broader issue - there may very well be an exploitable vector in the control panel. I generally loathe the idea of web-based control panels for anything.
its prolly broader issue since now my hostslick vps has been encrypted with same message like cloudcone had
@HostSlick
Wow. Screenshot?
Slightly off topic... but when I am on my work device... a LOT of sites I would normally go to for work purposes... have been asking for this permission A LOT.
Of course I hit block.
Yes. I’ve been chatting with him and he’s working on it as we speak. Allow him some time.
I’ve also had this issue as I’ve replied on CloudCone regarding this. I’ve had 4 providers contact me personally after I replied on the other thread who had this same issue but didn’t go public about it and since it’s happened to CloudCone/HostSlick makes me not regret coming public about this issue. I’m pretty sure it’s an API key exposure via billing system WHMCS & Blesta.
Normally I wouldn’t reply to something like this, but I wanted to be transparent after seeing your comment and also help CloudCone in some way as it may or may not be their fault hence why we ourselves haven’t went public with this until now.
We were also victims of a similar incident around two months ago. Our main master node had Google Authenticator 2FA enabled, along with SSH terminal 2FA via PAM. Despite this, the attacker somehow managed to gain access to the master and use the server terminal (so we thought). To this day, we still don’t know how the 2FA was bypassed.
The attacker contacted us on Telegram demanding payment. During the incident, we lost around 300 VMs, as they continued to threaten further deletions. Eventually, we paid an undisclosed amount significantly less than what they initially demanded. They promised to explain how access was gained, but stopped responding once the payment was sent.
Since then, we’ve moved the master node to a different location and implemented additional security hardening. We haven’t experienced any further issues. We currently manage around 2,300 VMs, but we’re still questioning how access was possible with multiple layers of 2FA in place.
I strongly suspect a vulnerability in a Blesta or WHMCS module. Our Virtualizor installation is white-labelled and has no direct links or connections to our main website, yet the attacker still knew it was Hostcay’s node. This makes me believe the entry point may have been through a billing application vulnerability.
They were able to execute VM deletions and upload ransomware, which I initially assumed was done via the terminal but there’s still no clear explanation as to how 2FA could have been bypassed.
We chose to restore the data, apply further security measures, and move on. I’m sharing this in case it helps others. I won’t be commenting further on the matter.