VECT 2.0: Ransomware by Design and Wiper by Accident

Check Point Research (CPR) published an in-depth analysis on April 28, 2026, revealing that VECT 2.0, a ransomware-as-a-service (RaaS) strain targeting Windows, Linux, and VMware ESXi systems, contains a fundamental coding flaw that renders it incapable of functioning as ransomware at all. For the vast majority of enterprise files, the malware is, in practice, an irreversible data wiper.

Background: A Rapidly Expanding RaaS Operation

VECT first appeared in December 2025 on a Russian-language cybercrime forum. After claiming its first two victims in January 2026 and releasing version 2.0 in February 2026, the group began aggressively expanding its affiliate network. A March 2026 partnership announcement with TeamPCP — the threat actor responsible for supply-chain compromises of popular developer tools including Trivy, Checkmarx’s KICS, LiteLLM, and Telnyx — dramatically raised the group’s profile. Both confirmed victims on VECT’s leak site stem from those TeamPCP supply-chain attacks.

In a further escalation, VECT announced a partnership with the hacking forum BreachForums itself, granting every registered forum member automatic affiliate status — access to the ransomware builder, negotiation platform, and leak site with no entry fee required. Check Point confirmed this arrangement was fully active as of April 2026 and used this open access to obtain samples and conduct their analysis.

The Core Flaw: A Broken Encryption Engine

Cipher Misrepresentation

VECT’s own advertisements and numerous third-party threat intelligence reports described the malware as using ChaCha20-Poly1305 AEAD encryption. Check Point’s reverse engineering of all three variants establishes this is incorrect. The actual cipher is raw ChaCha20-IETF (RFC 8439), implemented via the libsodium library’s crypto_stream_chacha20_ietf_xor function — with no Poly1305 authentication tag, no message authentication code (MAC), and no integrity protection of any kind.

The Fatal Nonce-Handling Bug

For files smaller than 131,072 bytes (128 KB), VECT’s encryption is functionally intact — the file is encrypted as a single chunk with a single nonce, which is saved alongside the ciphertext. Recovery is theoretically possible for these small files.

For any file exceeding 128 KB — which includes virtually every database, virtual machine disk image, document, backup archive, and production asset in an enterprise environment — the encryption logic splits the file into four independent chunks. Each chunk is encrypted with a freshly generated, random 12-byte nonce. The critical error: only the fourth and final nonce is written to disk. The first three nonces are generated, used once, and silently discarded.

Because ChaCha20-IETF decryption requires both the 32-byte encryption key and the exact 12-byte nonce used for each individual chunk, the first three-quarters of every large file are rendered permanently unrecoverable. The nonces are not stored on disk, not written to the Windows registry, and not transmitted to the operator’s command-and-control (C2) server. They simply cease to exist. No amount of compute power, no decryption key, and no ransom payment can undo this.

Check Point confirmed that this flaw is present across all publicly available VECT versions — it predates the 2.0 release and was never corrected in any build seen in the wild. The identical nonce-handling logic across the Windows, Linux, and ESXi variants confirms a single C++ codebase ported to all three platforms.

Additional Flaws: Amateur Execution Behind a Professional Façade

The nonce bug is not an isolated error. Check Point identified multiple additional technical failures across all three variants.

Linux & ESXi: Unusual Geofencing Behavior

The Linux and ESXi variants implement CIS-country geofencing — a standard tactic among Russian-speaking cybercrime groups that avoid targeting their own region. VECT checks locale and timezone settings and exits without encrypting if a CIS country is detected. Notably, Check Point observed that Ukraine remains on the protection whitelist — an anomaly, as virtually all other Russian-language RaaS operators removed Ukraine from such lists following the outbreak of full-scale conflict in early 2022. Researchers speculate this may indicate code copied wholesale from a pre-2022 source, or possibly from AI-generated code trained on outdated datasets.

Implications for Enterprise Security

The 128 KB threshold is deceptively low. As Check Point notes, it is “smaller even than a simple document.” In practice, every asset of operational consequence in an enterprise environment — VM disk images, SQL and NoSQL databases, ERP backups, email stores, code repositories, and log archives — far exceeds this threshold and will be irrecoverably wiped on contact with VECT 2.0.

The threat is compounded by VECT’s open affiliate model. By granting every BreachForums member access to the builder, the group has dramatically lowered the barrier to deployment. Attackers do not need technical sophistication — they simply need access to a target and a working payload.

Recommendations for Security Teams

• 1
  Do not pay the ransom under any circumstances. VECT 2.0’s structural flaw makes large-file recovery impossible regardless of whether a valid decryption key is obtained. Payment provides no benefit to the victim.
• 2
  Prioritize offline, immutable backups. Given VECT 2.0’s wiper behavior, the only viable recovery path is a clean, tested offline backup. Backups must be isolated from the production network and validated on a regular schedule.
• 3
  Monitor and restrict SSH and supply-chain entry points. Confirmed VECT victims were initially compromised via TeamPCP supply-chain attacks. Lateral movement relies on SSH/SCP credential theft. Audit SSH access, rotate credentials, and enforce multi-factor authentication on all remote access paths.
• 4
  Implement rapid network isolation procedures. VECT’s open affiliate model means detection windows will be short. Pre-defined incident response runbooks and automated isolation triggers are essential to limit blast radius once an intrusion is confirmed.
• 5
  Update threat intelligence for VECT’s actual cipher. Widely cited intelligence reports — and VECT’s own advertising — incorrectly describe the cipher as ChaCha20-Poly1305 AEAD. Security teams should update internal documentation; the correct cipher is raw, unauthenticated ChaCha20-IETF with no MAC.