← CIO Briefings · Critical Impact ACTION REQUIRED

VECT 2.0 Ransomware Permanently Destroys Data — Backups and Ransom Payment Cannot Recover Files

VECT 2.0 is a new cross-platform ransomware that deliberately corrupts large files beyond recovery before encrypting them, rendering both ransom payment and standard backup restoration ineffective. Active campaigns are hitting manufacturing, logistics, and healthcare. Organisations should immediately verify that at least one backup tier is fully isolated from production systems.

4 min read

What Happened

A new ransomware variant called VECT 2.0 has been deployed in active attacks against manufacturing, logistics, and healthcare organisations across Europe and the United States. Unlike conventional ransomware that encrypts files and offers decryption in exchange for payment, VECT 2.0 permanently destroys the structural integrity of all files larger than 128KB before encrypting the remaining content. This means that even organisations that pay the ransom — or that have decryption keys — cannot reconstruct the original files. The damage is irreversible.

VECT 2.0 runs simultaneously on Windows servers, Linux systems, and VMware ESXi virtualisation hosts, allowing it to destroy an organisation’s entire server estate in a single coordinated attack. It specifically terminates backup software processes before executing, targeting tools from Veeam, Acronis, and other enterprise backup vendors to prevent automatic backup of undamaged files.

Business Impact

The destruction model changes the economics and consequence severity of ransomware incidents in three fundamental ways:

Ransom payment does not restore operations. Paying the ransom in a conventional ransomware incident returns access to encrypted files. With VECT 2.0, paying the ransom returns a decryption key that cannot undo the prior deliberate corruption — the files remain unreadable. This removes the option that many organisations have relied upon as a recovery path of last resort.

Standard backup recovery may fail. VECT 2.0 specifically targets backup agent processes and terminates them before executing. Backup systems whose destination storage is mounted as a network share or accessible via the backup agent’s service account are themselves subject to corruption. Organisations that have not maintained air-gapped or immutable backups that are completely isolated from production access may find that their backup recovery capability has been eliminated alongside their primary data.

Virtualised environments face total loss. The ESXi variant corrupts virtual disk files at the infrastructure level — every virtual machine running on affected hosts becomes unrecoverable unless isolated backups of the VMDK files exist at a location the ESXi host cannot reach.

Active incidents have resulted in operational outages measured in weeks and total business losses in the range of €5 million to €30 million per victim, reflecting both direct recovery costs and business interruption.

Board-Ready Summary

  • VECT 2.0 ransomware permanently destroys files — paying the ransom does not restore data, and backup recovery only works if backups were fully isolated from the network at the time of attack
  • Attacks are active now in manufacturing, logistics, and healthcare; initial access uses methods already present in most enterprise environments (phishing, exposed remote access)
  • The board should authorise emergency verification of backup isolation status today, and be briefed on the organisation’s current recovery capability if a VECT 2.0 attack were to occur

  1. Emergency (today): Direct your IT/security team to confirm that at least one complete backup is stored in an air-gapped location (offline tape, immutable cloud storage, or a physically isolated system) that cannot be reached from production servers or the backup agent’s service account. If this cannot be confirmed, initiate an emergency off-site backup immediately.

  2. Emergency (today): Test restoration of at least one critical system from the most recent isolated backup to confirm the backup is intact and the recovery process works. Do not rely on backup monitoring dashboards that report “successful backup” — verify the actual data is restorable.

  3. Within 24 hours: Assess ESXi and virtualisation infrastructure: confirm vSphere/ESXi management interfaces are not accessible from production server VLANs; verify ESXi snapshots are stored separately from primary datastores; confirm you have recent off-host backups of all critical VMs.

  4. Within 48 hours: Review and harden backup agent service account permissions — backup agents should not have write access to the backup destination, or should connect via protocols that prevent the production environment from initiating connections to the backup system (pull-based backup models).

  5. Ongoing: Ensure your incident response plan explicitly addresses the scenario where backup recovery is not available; identify which business functions can be restored from manually maintained records, paper-based processes, or third-party systems, and what the acceptable recovery timeline is for each.