Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
Home β€Ί General
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.

What happened to CloudCone? Was it hacked?

1246711

Comments

  • NeoonNeoon Community Contributor, Veteran

    @Cloudcone said:
    Hello,

    We acknowledge the incident that has happened today

    What We First Observed

    We were initially alerted to the incident when our monitoring systems detected that several VMs lost network connectivity. Upon investigating, we found ransom messages being displayed at boot on all of the affected VMs.

    Our engineering teams immediately isolated the affected servers and began analysis. During the investigation, we confirmed that the boot sectors of impacted VM disks had been overwritten with the ransom message. We are attempting to recover the data by various means including examining raw block devices, reconstructing partition tables, and searching for intact filesystems.

    How the Attack Was Executed

    Meanwhile, the team investigating the breach discovered that a remote bash script (which is no longer accessible) had been executed across all affected nodes. Shell histories on those hosts had also been cleared. We performed a thorough review of authentication activity using system journals, rotated log files, login records and auditing data and found no evidence of unauthorized SSH access. All recorded user logins matched known internal accounts.

    At this point, we started looking into other infrastructure that could have facilitated this attack and discovered that logs of one of our Virtualizor instances had been cleared from around the time of the incident. This is the Virtualizor instance that all of the affected nodes are connected to.

    At this time, based on the available evidence, we believe that the attackers used the "Server Terminal" functionality within Virtualizor to gain shell access to connected nodes and execute the malicious script. This access method does not use SSH, which explains the lack of evidence relating to SSH connectivity, and we also discovered that this doesn't leave any login records on the nodes (all root level logins are also alerted via emails), explaining why we didn't find anything out of the ordinary earlier.

    Scope of Impact

    We use Virtualizor instances to support our VPS services. At this time, we have confirmed that only nodes connected to a single Virtualizor instance were impacted. Nodes attached to our other platforms were not affected.

    We also do not store personal or billing information of our users within virtualization platforms such as Virtualizor. Our investigation has found no evidence that customer databases or billing systems were accessed or compromised.

    We are currently working on the way forward, and all affected clients shall be emailed, and we apologize for the inconvenience this has caused to all our affected clients.

    If they have a shell and run a script and the ssh history is gone.
    You think your logs are legit? brother....

    Thanked by 2loay Gravely
  • ralfralf Member

    @oloke said:

    @MaxTakeba

    I still can't understand why would anyone pay.
    I don't even have $100 to spend on LET providers. Let alone some hacker who tries to extort people.

    It depends what you're using the servers for. If it's a business, you might easily have more than $100 of pending orders there that you don't know about, so even if you had up-to-date backups it might still be worth paying. If your server is down for days, you probably would be losing more than $100 a day in lost revenue. Maybe it's worth it.

    That said, personally, it's unlikely I'd ever pay such a thing - but mostly only because I have borg backups of all my servers, including a copy on a server in my house running borg in append-only mode that only allows logins from within my house as my very last line of defense. So even if hackers destroyed all my backups as well as my servers, I should still have a copy of everything important locally.

    Another thing to consider is that if they had access to your machine sufficient to encrypt it, they probably had plenty of opportunity to compromise it in other ways. Maybe they install a backdoor after you pay up and before they unlock it. You should probably never consider that server safe again, and not trust any data on it or on machines that could be accessed with credentials on it. You should still wipe it and probably move to another provider, even if you did pay the ransom to see if there was important data since your last backup.

    Thanked by 1nghialele
  • nghialelenghialele Member
    edited January 30

    @Levi said:

    @nghialele said: Buy a damn physical SSD

    Nghia lele, did you saw prices on those SSDs? 7$ VPS is way better in short term dopamine secretion.

    Sir, they asking for proper backup solutions, and it's aint cheap.

  • @Cloudcone said:
    Hello,

    We acknowledge the incident that has happened today

    What We First Observed

    We were initially alerted to the incident when our monitoring systems detected that several VMs lost network connectivity. Upon investigating, we found ransom messages being displayed at boot on all of the affected VMs.

    Our engineering teams immediately isolated the affected servers and began analysis. During the investigation, we confirmed that the boot sectors of impacted VM disks had been overwritten with the ransom message. We are attempting to recover the data by various means including examining raw block devices, reconstructing partition tables, and searching for intact filesystems.

    How the Attack Was Executed

    Meanwhile, the team investigating the breach discovered that a remote bash script (which is no longer accessible) had been executed across all affected nodes. Shell histories on those hosts had also been cleared. We performed a thorough review of authentication activity using system journals, rotated log files, login records and auditing data and found no evidence of unauthorized SSH access. All recorded user logins matched known internal accounts.

    At this point, we started looking into other infrastructure that could have facilitated this attack and discovered that logs of one of our Virtualizor instances had been cleared from around the time of the incident. This is the Virtualizor instance that all of the affected nodes are connected to.

    At this time, based on the available evidence, we believe that the attackers used the "Server Terminal" functionality within Virtualizor to gain shell access to connected nodes and execute the malicious script. This access method does not use SSH, which explains the lack of evidence relating to SSH connectivity, and we also discovered that this doesn't leave any login records on the nodes (all root level logins are also alerted via emails), explaining why we didn't find anything out of the ordinary earlier.

    Scope of Impact

    We use Virtualizor instances to support our VPS services. At this time, we have confirmed that only nodes connected to a single Virtualizor instance were impacted. Nodes attached to our other platforms were not affected.

    We also do not store personal or billing information of our users within virtualization platforms such as Virtualizor. Our investigation has found no evidence that customer databases or billing systems were accessed or compromised.

    We are currently working on the way forward, and all affected clients shall be emailed, and we apologize for the inconvenience this has caused to all our affected clients.

    Does he mean that the data can still be recovered?

  • backtogeekbacktogeek Member, Host Rep

    @zhaochangzeng said: Does he mean that the data can still be recovered?

    it means its possible, but dont count on it.

  • VoidVoid Member

    CloudGone literally

  • @zhaochangzeng said:

    @Cloudcone said:
    Hello,

    We acknowledge the incident that has happened today

    What We First Observed

    We were initially alerted to the incident when our monitoring systems detected that several VMs lost network connectivity. Upon investigating, we found ransom messages being displayed at boot on all of the affected VMs.

    Our engineering teams immediately isolated the affected servers and began analysis. During the investigation, we confirmed that the boot sectors of impacted VM disks had been overwritten with the ransom message. We are attempting to recover the data by various means including examining raw block devices, reconstructing partition tables, and searching for intact filesystems.

    How the Attack Was Executed

    Meanwhile, the team investigating the breach discovered that a remote bash script (which is no longer accessible) had been executed across all affected nodes. Shell histories on those hosts had also been cleared. We performed a thorough review of authentication activity using system journals, rotated log files, login records and auditing data and found no evidence of unauthorized SSH access. All recorded user logins matched known internal accounts.

    At this point, we started looking into other infrastructure that could have facilitated this attack and discovered that logs of one of our Virtualizor instances had been cleared from around the time of the incident. This is the Virtualizor instance that all of the affected nodes are connected to.

    At this time, based on the available evidence, we believe that the attackers used the "Server Terminal" functionality within Virtualizor to gain shell access to connected nodes and execute the malicious script. This access method does not use SSH, which explains the lack of evidence relating to SSH connectivity, and we also discovered that this doesn't leave any login records on the nodes (all root level logins are also alerted via emails), explaining why we didn't find anything out of the ordinary earlier.

    Scope of Impact

    We use Virtualizor instances to support our VPS services. At this time, we have confirmed that only nodes connected to a single Virtualizor instance were impacted. Nodes attached to our other platforms were not affected.

    We also do not store personal or billing information of our users within virtualization platforms such as Virtualizor. Our investigation has found no evidence that customer databases or billing systems were accessed or compromised.

    We are currently working on the way forward, and all affected clients shall be emailed, and we apologize for the inconvenience this has caused to all our affected clients.

    Does he mean that the data can still be recovered?

    @zhaochangzeng said:

    @Cloudcone said:
    Hello,

    We acknowledge the incident that has happened today

    What We First Observed

    We were initially alerted to the incident when our monitoring systems detected that several VMs lost network connectivity. Upon investigating, we found ransom messages being displayed at boot on all of the affected VMs.

    Our engineering teams immediately isolated the affected servers and began analysis. During the investigation, we confirmed that the boot sectors of impacted VM disks had been overwritten with the ransom message. We are attempting to recover the data by various means including examining raw block devices, reconstructing partition tables, and searching for intact filesystems.

    How the Attack Was Executed

    Meanwhile, the team investigating the breach discovered that a remote bash script (which is no longer accessible) had been executed across all affected nodes. Shell histories on those hosts had also been cleared. We performed a thorough review of authentication activity using system journals, rotated log files, login records and auditing data and found no evidence of unauthorized SSH access. All recorded user logins matched known internal accounts.

    At this point, we started looking into other infrastructure that could have facilitated this attack and discovered that logs of one of our Virtualizor instances had been cleared from around the time of the incident. This is the Virtualizor instance that all of the affected nodes are connected to.

    At this time, based on the available evidence, we believe that the attackers used the "Server Terminal" functionality within Virtualizor to gain shell access to connected nodes and execute the malicious script. This access method does not use SSH, which explains the lack of evidence relating to SSH connectivity, and we also discovered that this doesn't leave any login records on the nodes (all root level logins are also alerted via emails), explaining why we didn't find anything out of the ordinary earlier.

    Scope of Impact

    We use Virtualizor instances to support our VPS services. At this time, we have confirmed that only nodes connected to a single Virtualizor instance were impacted. Nodes attached to our other platforms were not affected.

    We also do not store personal or billing information of our users within virtualization platforms such as Virtualizor. Our investigation has found no evidence that customer databases or billing systems were accessed or compromised.

    We are currently working on the way forward, and all affected clients shall be emailed, and we apologize for the inconvenience this has caused to all our affected clients.

    Does he mean that the data can still be recovered?

    Sure it's on the hackers drive, possibel can recover at some costs, and not sure if it deliver

  • angstromangstrom Moderator

    To all concerned customers:

    We recommend to activate your Disaster Recovery Plan.

  • Virtualizor on top.

  • loayloay Member

    @Cloudcone said: We use Virtualizor instances to support our VPS services. At this time, we have confirmed that only nodes connected to a single Virtualizor instance were impacted.

    Virtualizor is almost always NOT the problem.

    /s

  • @Cloudcone said:
    Hello,

    We acknowledge the incident that has happened today

    What We First Observed

    We were initially alerted to the incident when our monitoring systems detected that several VMs lost network connectivity. Upon investigating, we found ransom messages being displayed at boot on all of the affected VMs.

    Our engineering teams immediately isolated the affected servers and began analysis. During the investigation, we confirmed that the boot sectors of impacted VM disks had been overwritten with the ransom message. We are attempting to recover the data by various means including examining raw block devices, reconstructing partition tables, and searching for intact filesystems.

    How the Attack Was Executed

    Meanwhile, the team investigating the breach discovered that a remote bash script (which is no longer accessible) had been executed across all affected nodes. Shell histories on those hosts had also been cleared. We performed a thorough review of authentication activity using system journals, rotated log files, login records and auditing data and found no evidence of unauthorized SSH access. All recorded user logins matched known internal accounts.

    At this point, we started looking into other infrastructure that could have facilitated this attack and discovered that logs of one of our Virtualizor instances had been cleared from around the time of the incident. This is the Virtualizor instance that all of the affected nodes are connected to.

    At this time, based on the available evidence, we believe that the attackers used the "Server Terminal" functionality within Virtualizor to gain shell access to connected nodes and execute the malicious script. This access method does not use SSH, which explains the lack of evidence relating to SSH connectivity, and we also discovered that this doesn't leave any login records on the nodes (all root level logins are also alerted via emails), explaining why we didn't find anything out of the ordinary earlier.

    Scope of Impact

    We use Virtualizor instances to support our VPS services. At this time, we have confirmed that only nodes connected to a single Virtualizor instance were impacted. Nodes attached to our other platforms were not affected.

    We also do not store personal or billing information of our users within virtualization platforms such as Virtualizor. Our investigation has found no evidence that customer databases or billing systems were accessed or compromised.

    We are currently working on the way forward, and all affected clients shall be emailed, and we apologize for the inconvenience this has caused to all our affected clients.

    @virtualizor I never bothered reading that long DM you sent me about the @ouiheberg hack, but I doubt it's a coincidence that your product is implicated in yet another incident πŸ™„

  • @qwerttaa said:
    0xEf35250A9A2A763F87E406C2a9187A5a389c09AA
    TWJr7y6cwF3t8hqVoGHvwYuGbP9AtJDVMw
    UQBzr3lIN_8t9o4zN10M4cuD7OO2643GT-wFgia3EN-MSI39

    you can see how much money is in hacker's account.

    How much?

  • rpqurpqu Member

    @Murv said:
    No worries guys, I'm a professional at negotiating with terrorists.

    πŸ˜† Should've start with Anime memes with arabic texts

  • Is there any progress?

  • @default said:
    Maybe we should stop comparing this with ColoCrapping - that was their mistake (not some Virtualizor vulnerability as they assumed at the beginning and was never proven).

    Don't you mean OuiHeberg? They made such claims, but didn't provide evidence.

    Thanked by 2oloke MannDude
  • defaultdefault Veteran
    edited January 30

    @LowEndStalker said:
    Virtualizor on top.

    @loay said:

    Virtualizor is almost always NOT the problem.

    /s

    @CloudHopper said:
    @virtualizor I never bothered reading that long DM you sent me about the @ouiheberg hack, but I doubt it's a coincidence that your product is implicated in yet another incident πŸ™„

    So far on LET we have just 2 low-end providers blaming Virtualizor and within isolated scenarios. If there would be a serious Virtualizor vulnerability, we would see a lot of providers from the whole internet having lots of serious breaches.

    Please cut it out with blaming Virtualizor which is already open-source. Maybe, just maybe, we get monkeys in some responsible jobs because companies wish to cut down costs while paying peanuts (including artificial intelligence).

    Thanked by 2whynotlearn host_c
  • @RCVmedia said:

    @default said:
    Maybe we should stop comparing this with ColoCrapping - that was their mistake (not some Virtualizor vulnerability as they assumed at the beginning and was never proven).

    Don't you mean OuiHeberg? They made such claims, but didn't provide evidence.

    This. It was not a bug, just poor management for which CC never took responsibility publicly.

    Thanked by 2host_c RCVmedia
  • whynotlearnwhynotlearn Member
    edited January 30

    @default said:

    @LowEndStalker said:
    Virtualizor on top.

    @loay said:

    Virtualizor is almost always NOT the problem.

    /s

    @CloudHopper said:
    @virtualizor I never bothered reading that long DM you sent me about the @ouiheberg hack, but I doubt it's a coincidence that your product is implicated in yet another incident πŸ™„

    So far on LET we have just 2 low-end providers blaming Virtualizor and within isolated scenarios. If there would be a serious Virtualizor vulnerability, we would see a lot of providers from the whole internet having lots of serious breaches.

    Please cut it out with blaming Virtualizor which is already open-source. Maybe, just maybe, we get monkeys in some responsible jobs because companies wish to cut down costs while paying peanuts (including artificial intelligence).

    Wait I don't think virtualizor is open source. I can be wrong I usually am but I couldn't find anything in their github (much) and I am seeing that they have pricing tier and everything which also makes me doubt as if its open source, I don't think its virtualizor, can you point out how its open source please?

  • ralfralf Member

    @Murv said:
    No worries guys, I'm a professional at negotiating with terrorists.

    image

    Are you trying to make them double the ransom price?

  • LeviLevi Member

    @Cloudcone said: a remote bash script

    A what? There is no such thing as "remote bash script". There is compromised root account of the node.

    Good luck with your business.

  • why can they be hacked twice within one year?

  • LeviLevi Member

    @stayforu said:
    why can they be hacked twice within one year?

    Incompetence.

    Thanked by 1default
  • defaultdefault Veteran
    edited January 30

    @whynotlearn said:

    @default said:

    @LowEndStalker said:
    Virtualizor on top.

    @loay said:

    Virtualizor is almost always NOT the problem.

    /s

    @CloudHopper said:
    @virtualizor I never bothered reading that long DM you sent me about the @ouiheberg hack, but I doubt it's a coincidence that your product is implicated in yet another incident πŸ™„

    So far on LET we have just 2 low-end providers blaming Virtualizor and within isolated scenarios. If there would be a serious Virtualizor vulnerability, we would see a lot of providers from the whole internet having lots of serious breaches.

    Please cut it out with blaming Virtualizor which is already open-source. Maybe, just maybe, we get monkeys in some responsible jobs because companies wish to cut down costs while paying peanuts (including artificial intelligence).

    Wait I don't think virtualizor is open source. I can be wrong I usually am but I couldn't find anything in their github (much) and I am seeing that they have pricing tier and everything which also makes me doubt as if its open source, I don't think its virtualizor, can you point out how its open source please?

    I was wrong. I can't find the source code either. They mention an "open source version" and an "Virtualizor OS Distro", making it look as open-source to searches, but there is no downloadable source code from what I see. I stand corrected.

    Back on topic: They do provide an installation script and free trial. In my opinion if it was insecure or vulnerable, we would see an insane amount of hacked machines with hacked providers. I simply assume (without proof) that providers are simply cutting costs on workforce, resulting in big human mistakes which end up impacting some customers.

    Thanked by 2host_c whynotlearn
  • defaultdefault Veteran
    edited January 30

    @Levi said:

    @stayforu said:
    why can they be hacked twice within one year?

    Incompetence.

    As providers try to cut costs more and more to survive in a failing politicised economy, I'm afraid we will see more and more irresponsible workforce being hired. It is so damn easy to cheat and lie on your resume using AI.

    Thanked by 1host_c
  • update: i could login to my vps, and its still running.
    might be their main node/billing etc have been hacked.
    but I've changed a/c password and vps passwords as precaution.

  • @JasonM said:
    update: i could login to my vps, and its still running.
    might be their main node/billing etc have been hacked.
    but I've changed a/c password and vps passwords as precaution.

    My VPS not hacked either - old customer though. Maybe it was just a new node with some bad configuration or bad password. This is good though, because it could mean they don't use same password everywhere. :smiley:

  • host_chost_c Patron Provider, Top Host, Megathread Squad
    edited January 30

    @JasonM said:
    update: i could login to my vps, and its still running.
    might be their main node/billing etc have been hacked.
    but I've changed a/c password and vps passwords as precaution.

    That would have almost no impact in this scenario.

    If an attacker has root access on the bare-metal host, anything running on top of it (VMs included) is effectively untrusted. Changing VPS or account passwords is good on paper, but it doesn’t meaningfully mitigate a host-level compromise.

    At that point:

    • the hypervisor controls disk, memory, and network I/O

    • VM integrity cannot be guaranteed

    • credentials inside the VM can be observed or modified regardless of password changes

    The only real remediation after a confirmed host compromise is node isolation, rebuild, and restore from known-good backups. ( and implement counter measures to limit the blast radius )

  • @Frameworks said:

    @qwerttaa said:
    0xEf35250A9A2A763F87E406C2a9187A5a389c09AA
    TWJr7y6cwF3t8hqVoGHvwYuGbP9AtJDVMw
    UQBzr3lIN_8t9o4zN10M4cuD7OO2643GT-wFgia3EN-MSI39

    you can see how much money is in hacker's account.

    How much?

    A hundred

    Thanked by 1Frameworks
Sign In or Register to comment.