VECT 2.0 Ransomware Wiper Analysis: Why Files Over 128 KB Are Permanently Unrecoverable

VECT 2.0, a ransomware-as-a-service targeting Windows, Linux, and VMware ESXi, contains a critical encryption bug that permanently destroys the first three-quarters of every file above 128 KB. The three ChaCha20 decryption nonces required to recover those file segments are discarded at encryption time — never saved to disk, the Windows registry, or the attacker’s command-and-control server. Incident response teams, cyber insurance adjusters, and CISO advisors need to understand this before any ransom payment decision is made: the decryptor the operator sells cannot recover the files that matter most.

What Is VECT 2.0 Ransomware

VECT debuted in December 2025 on a Russian-language cybercrime forum as a ransomware-as-a-service offering. Affiliates receive an automated build system, a dark-web data-leak site, and a victim negotiation panel — a feature set comparable to established RaaS programs like LockBit and BlackCat. Version 2.0, released in February 2026, extended the platform to Linux and VMware ESXi alongside the original Windows variant.

Across all three platforms, VECT follows a consistent execution pattern:

• Disables host-based defences (Windows Defender via PowerShell on Windows; service shutdown on Linux/ESXi)
• Clears Windows event logs and modifies boot configuration to hamper forensic recovery
• Exfiltrates victim data to 158.94.210.11 on port 8000 before encryption begins
• Renames encrypted files with the .vect extension and drops ransom notes as !!!READ_ME!!!.txt, VECT_RECOVERY_GUIDE.txt, and README_VECT.html

Researchers at Check Point Research identified the encryption flaw in April 2026 after reverse-engineering samples from all three platform variants and confirming the same bug is present in each.

How VECT 2.0’s Broken Nonce Loop Works

VECT encrypts files using raw ChaCha20-IETF (RFC 8439) via the libsodium cryptographic library. Multiple threat intelligence reports have misidentified the cipher as ChaCha20-Poly1305 AEAD; the actual implementation uses ChaCha20 without an authentication tag. This means encrypted data can be silently corrupted without any integrity failure being detected, which compounds the data-loss risk.

The encryption path forks based on a single size threshold of 131,072 bytes (128 KB):

Files at or below 128 KB are encrypted in a single pass with one randomly generated 12-byte nonce. That nonce is written alongside the ciphertext and remains available to any decryptor holding the correct key.

Files above 128 KB are divided into four equal chunks and processed in a loop. Each iteration generates a fresh 12-byte nonce via randombytes(), encrypts the corresponding chunk, then advances to the next iteration — overwriting the nonce buffer in memory.

// Pseudocode reconstruction of VECT 2.0's large-file encryption loop
uint8_t nonce[12];  // single buffer, shared across all iterations

for (int i = 0; i < 4; i++) {
    randombytes(nonce, 12);                       // fresh random nonce
    chacha20_encrypt(chunk[i], key, nonce);        // encrypts chunk i
    // nonce is NOT saved; next iteration overwrites it
}

append_to_file(nonce);   // only nonce from iteration 3 (final chunk) is persisted

The result: only the nonce for the fourth chunk is ever written to disk. The nonces for chunks 0, 1, and 2 are generated, used exactly once, then gone. They are not stored in the file header, the Windows registry, or any network-transmitted structure captured by analysis of the C2 protocol.

ChaCha20 decryption requires both the 256-bit key and the exact 96-bit nonce used to encrypt each ciphertext block. Without the three discarded nonces, the first 75% of every large file is unrecoverable — not operationally difficult, but mathematically impossible given 96 bits of entropy in each lost nonce.

Check Point confirmed the identical bug is present in the Windows, Linux, and ESXi variants, indicating it originated in shared source code rather than independent per-platform implementations.

Why This Matters: Ransom Payment Cannot Recover Large Files

The RaaS business model rests on one proposition: pay, receive the key and decryptor, recover your data. VECT 2.0 breaks that proposition for the majority of enterprise data.

For files under 128 KB, the proposition holds. The operator retains the key, the single nonce was saved, and a functional decryptor can reconstruct the plaintext. For files over 128 KB, the operator cannot provide a working decryptor — not because they are withholding key material, but because the three nonces required to decrypt 75% of each large file were lost on the victim’s own machine at the moment of encryption.

The 128 KB threshold eliminates recovery for essentially all high-value enterprise assets:

Cyber insurance policies that include ransom payment as a recovery mechanism provide no benefit for the file categories that matter most in a VECT 2.0 incident. The wiper behaviour is almost certainly unintentional — a ransomware operator whose decryptor does not work collects no payment — but the effect on victim data is identical to deliberate destruction.

Real-World Impact and Affected Sectors

As of late April 2026, confirmed VECT 2.0 victims span manufacturing, education, healthcare, and technology sectors. Known victim distribution includes four organizations in Brazil, four in the United States, three in India, and two in South Africa, with single victims in Egypt, Spain, Colombia, Italy, and Namibia — consistent with the opportunistic targeting common to RaaS affiliates selecting for internet-exposed Windows and ESXi hosts.

Files most commonly rendered permanently unrecoverable in documented incidents include VM disk images on ESXi hosts, SQL Server database files, and enterprise backup archives — precisely the assets organizations rely on for business continuity and disaster recovery.

Incident Response: What to Do If You’re Hit

The standard ransomware IR playbook assumes a functional decryptor exists. VECT 2.0 invalidates that assumption for large files. Adjust the response sequence accordingly.

Step 1: Audit file sizes before any ransom decision.
Before engaging with the attacker or advising the victim to pay, enumerate encrypted files and determine what percentage exceed 128 KB. If critical data assets — databases, VM disks, backups — are in the affected category, a ransom payment buys nothing for those files.

# Linux / ESXi: count encrypted files above 128 KB
find /mountpoint -name "*.vect" -size +128k | wc -l

# Windows PowerShell equivalent
Get-ChildItem -Recurse -Filter "*.vect" |
  Where-Object { $_.Length -gt 131072 } |
  Measure-Object | Select-Object Count

Step 2: Attempt live memory acquisition if the process is still running.
If a VECT encryption process is active, the 256-bit ChaCha20 key may still be present in process memory. A memory image captured before the process exits creates the possibility of future key extraction, even if no extraction tooling is available at incident time.

# Linux: dump memory from the live VECT ELF process (replace <PID>)
dd if=/proc/<PID>/mem of=/forensics/vect_memdump.bin

# Windows: WinPmem for kernel-mode memory acquisition
winpmem_mini_x64.exe /forensics/memdump.raw

Step 3: Check for surviving Volume Shadow Copies.
VECT 2.0 does not reliably delete shadow copies on all Windows versions. Verify their state before assuming they are gone — a surviving VSS snapshot may allow partial file recovery.

vssadmin list shadows
Get-WmiObject Win32_ShadowCopy | Select-Object InstallDate, DeviceObject

Step 4: Pivot immediately to offline backup restoration.
For any file above 128 KB, restoring from an air-gapped or immutable backup is the only viable recovery path. Begin backup integrity verification in parallel with containment, not after ransom negotiation concludes.

Detection and Defensive Measures

Hunt for these behavioural indicators before the ransom note stage:

• svc_host_update.exe (Windows) or enc_esxi.elf (Linux/ESXi) executing with an unusual parent process
• PowerShell commands disabling Windows Defender real-time protection (Set-MpPreference -DisableRealtimeMonitoring $true)
• wevtutil cl calls clearing system, security, or application event logs
• bcdedit /set safeboot modifications
• High-volume outbound connections to 158.94.210.11:8000
• Mass file rename activity appending .vect to existing extensions

A minimal YARA rule for static binary detection:

rule VECT_Ransomware_2_0 {
    meta:
        description = "Detects VECT 2.0 ransomware binary markers"
        date        = "2026-04"
        reference   = "https://research.checkpoint.com/2026/vect-ransomware-by-design-wiper-by-accident/"
    strings:
        $note_1 = "!!!READ_ME!!!" ascii
        $note_2 = "VECT_RECOVERY_GUIDE" ascii
        $ext    = ".vect" ascii
        $c2     = "158.94.210.11" ascii
    condition:
        3 of them
}

Preventive controls that reduce VECT exposure:

• Deploy application allowlisting to block unsigned executables in %APPDATA%, %TEMP%, and other user-writable paths
• Enable EDR tamper protection to resist PowerShell-based Defender disabling — this is one of VECT’s first actions on Windows hosts
• Monitor and alert on vssadmin delete shadows execution and bcdedit safe-boot modifications
• Maintain verified, offline, immutable backups tested regularly for restoration — the only reliable recovery mechanism for large-file encryption scenarios
• Block egress to 158.94.210.11/32 on all perimeter firewalls to prevent data exfiltration before encryption

Conclusion

VECT 2.0 ransomware functions as a wiper for any file above 128 KB, not by design, but because a nonce buffer is overwritten on each loop iteration and only the final value is saved to disk. The missing nonces are gone permanently — no payment, negotiation, or cryptanalytic technique can recover them. IR teams responding to VECT incidents should treat all large encrypted files as unrecoverable, focus forensic effort on live memory acquisition and shadow copy triage, and ground recovery planning on offline backup availability rather than ransom payment outcomes.

See our analysis of Threat Actors Publishing Structured OPSEC Playbooks to Systematically Evade Detection to understand how ransomware affiliates like VECT structure pre-encryption activity to avoid early detection →

Thank you for reading this post, don't forget to subscribe!