VAServ hacker damages 100,000 websites

happygeek 0 Tallied Votes 290 Views Share

Hackers managed to get root access to a large Internet Service Provider, reportedly via a zero day vulnerability over the weekend, and destroy data from 100,000 websites as a result. The UK-based ISP, VAServ, has stated that the attackers apparently exploited a vulnerability in virtualisation software called HyperTM in order to gain access to the servers.

It would appear that around 100,000 of the websites hosted at Vaserv had data destroyed in one hit on Sunday, possibly courtesy of a recursive delete 'rm -rf' Unix command. Unfortunately, many VAServ customers have an unmanaged account with no data backup. It is estimated that half the sites hosted at VAServ are still offline as a result.

The compromise has all the hallmarks of being a highly targeted SQL injection attack on the ISP's central management software, a deliberate infrastructure breach rather than kiddies doing random scanning according to a spokesman for VAServ.

A VAServ admits "We have worked tirelessly through the night and over the last 48 hours to recover as many VPS as possible. However, we have now reached the end of all of our servers, and as such, if your server is not currently up, or not partly up (i.e. it is up but not working due to a configuration issue) then it is unfortunate that you will have lost your data due to this third party attack."

Dani AI

Generated

As noted, this thread documents a catastrophic control‑plane compromise at a host with widespread customer data loss. The useful follow‑up is practical: immediate triage to preserve anything recoverable, and concrete steps to reduce the chance of the same failure in future.

Immediate triage and evidence preservation:

  • Stop normal rebuilds or bulk changes that overwrite disks. Preserve the current state and collect artifacts.
  • If possible take full disk images or host-provided snapshots before any recovery attempts. Example imaging and log collection commands (adjust device paths as needed):
dd if=/dev/sda of=/root/server-image-$(date +%F).img bs=4M conv=sync,noerror
tar -czf /root/logs-$(date +%F).tgz /var/log
  • Gather control-panel exports, database dumps, cron lists, SSH keys, and any management‑plane logs. Ask the provider for raw images, snapshot copies and a timeline of admin actions.
  • Look for external copies (developer checkouts, source control, search‑engine caches, archived mirrors) as a last resort for site content.

Forensic cautions and escalation:

  • Do not run recovery tools on a live production disk; operate on a copy. Running undirected recovery risks further permanent loss.
  • Document timestamps and actions, preserve chain of custody, and consider professional incident response. Notify relevant authorities or CERT if required by law or policy.

Longer‑term mitigations (practical items to implement now):

  • Adopt a 3‑2‑1 backup policy with immutable/offsite copies and routine restore tests.
  • Isolate and harden the management plane (separate network, least privilege, MFA).
  • Fix application risks: parameterized queries/ORMs to prevent SQL injection, WAF, input validation, and centralized logging + file‑integrity monitoring.

A short, automated backup example for a single site:

0 2 * * * tar -czf /backups/site-$(date +\%F).tgz /var/www/site && rsync -a /backups/ backupuser@backup.example.com:/backups/

These steps focus on preserving evidence and rebuilding from known good sources, while preventing a single control‑plane failure from destroying all customer data in future.

happygeek 2,411 Most Valuable Poster Team Colleague Featured Poster

Oh boy, this one just gets worse and worse: looks like the boss of the company that developed HyperVM has killed himself. He was found hanged in his Bangalore house.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.