VECT 2.0 Ransomware Irreversibly Corrupts Files Over 131KB on Windows, Linux, and ESXi

VECT 2.0 — a new ransomware variant documented by Trend Micro researchers and confirmed across active incident response engagements in April 2026 — combines encryption with deliberate partial data corruption, permanently destroying content in files larger than 131,072 bytes (128KB). Unlike conventional ransomware where files can be decrypted after payment or recovered from backups, files affected by VECT 2.0’s corruption routine cannot be fully reconstructed regardless of whether the ransom is paid. The ransomware runs on Windows, Linux, and VMware ESXi, targeting the full enterprise server estate in a single coordinated attack.

The Destructive Mechanism

VECT 2.0’s design distinguishes between small files (≤131KB) and large files (>131KB). Small files are encrypted conventionally and can theoretically be recovered if the decryption key is obtained. Large files undergo a two-stage process: the ransomware first overwrites the initial 131KB of each file with random data, then encrypts the remainder. Because the overwritten header region contains the file system metadata, compression headers, and format-specific structures required to parse the file, the corruption of the first 131KB makes the remainder of the file unrecoverable even with the encryption key.

The 131KB threshold is not arbitrary — it is calibrated to maximise damage to enterprise data types while keeping the ransomware’s execution time competitive with standard encryptors. Database files, virtual disk images, document files, log archives, and most enterprise application data files are larger than 131KB. Files under the threshold — configuration files, scripts, and small documents — may be decryptable, but these typically represent a small fraction of organisational data value.

The encryption scheme itself uses a combination of AES-256 for file content and RSA-4096 for key exchange — technically sound cryptography that makes encrypted files unrecoverable without the attacker’s private key.

Cross-Platform Scope

VECT 2.0 is written in Go, enabling compilation for multiple target platforms from a single codebase. Three confirmed variants exist:

Windows variant: Deployed via PowerShell dropper; terminates VSS (Volume Shadow Copy Service) and backup agent processes before encryption begins. Specifically kills processes associated with Veeam, Acronis, BackupExec, and Windows Server Backup before running.

Linux variant: Targets /var/www, /data, /home, /srv, and database directories. Specifically processes MySQL/PostgreSQL data directories and terminates database services before encryption to avoid file locking conflicts.

ESXi variant: Stops all running virtual machines, then encrypts VMDK, VMEM, and NVRAM files on all mounted datastores. The ESXi variant’s ability to corrupt VMDK headers means entire virtualised server environments may be unrecoverable without verified, isolated backups.

Campaign Activity

Active VECT 2.0 campaigns have been confirmed against manufacturing companies in Germany and the Netherlands, logistics operators in the UK and US, and at least two healthcare systems in the US Midwest. Initial access vectors across confirmed incidents include: phishing leading to credential theft, exploitation of internet-exposed RDP, and at least one instance where a compromised managed service provider was used as the entry point.

Ransom demands in confirmed incidents range from €400,000 to €2.5 million, with a 72-hour payment deadline. Threat actors operating VECT 2.0 have demonstrated willingness to publish samples of stolen data if payment is not received.

Impact on Recovery Strategies

VECT 2.0 fundamentally challenges standard backup-based ransomware recovery:

• Online backups are at risk — backup systems mounted as network shares or accessible via backup agent protocols can be targeted by the Linux and Windows variants. Organisations relying on continuously-mounted backup destinations (NAS devices, mapped network drives) may find backups corrupted alongside primary data.
• ESXi snapshots may be corrupted — ESXi volume-level snapshots stored on the same datastores as primary VMDK files are subject to corruption by the ESXi variant before the ESXi service terminates them.
• Partial file corruption is not detectable from backup metadata — backup systems that check file presence and size (not content hash) will not detect that VECT 2.0 has corrupted file headers, and may report backup as successful for files that are already damaged.

Recommended Actions

• Verify backup isolation — confirm that at least one backup tier is air-gapped or logically isolated from the production environment and not reachable by the backup agent’s service account from production systems. Tape, offline object storage, or immutable cloud backup targets are the effective options.
• Test backup recoverability — restore a representative sample of large files (database dumps, virtual disk images, critical application files) from your most recent backup to confirm they are intact and recoverable.
• Audit ESXi management access — restrict access to vSphere/ESXi management interfaces; enable MFA on vCenter; confirm ESXi hosts are not directly reachable from production server VLANs.
• Review endpoint detection rules for Go-compiled malware — VECT 2.0’s Go binary characteristics are detectable; ensure your EDR has updated signatures. The VSS deletion command sequence (vssadmin delete shadows /all /quiet) is a high-fidelity indicator of pre-ransomware activity.
• Brief incident response teams on irrecoverability — ensure your IR team understands that ransom payment will not recover data corrupted by VECT 2.0’s file header overwrite; recovery decisions must be based on backup availability, not on payment feasibility.