VECT 2.0 Ransomware: A Flawed Encryption Design That Destroys Data Permanently
Key Discovery: Ransomware That Acts as a Wiper
Check Point Research (CPR) has uncovered a critical flaw in the VECT 2.0 ransomware that renders it more destructive than intended. Instead of encrypting large files, the ransomware permanently destroys them, making full recovery impossible—even for the attackers themselves. The flaw lies in the encryption implementation shared across all three platform variants: Windows, Linux, and ESXi. For any file exceeding 131,072 bytes (128 KB), the encryption process discards three out of four decryption nonces. This means that for virtually every file containing meaningful data—such as virtual machine disks, databases, documents, and backups—the ransomware acts as a permanent wiper. CPR confirmed this flaw exists in all publicly available VECT versions.
The Encryption Implementation Flaw
Misidentified Cipher
Public reporting has misidentified VECT's encryption algorithm. Several widely cited threat intelligence reports, as well as VECT's initial advertisements, claimed the ransomware uses ChaCha20-Poly1305 AEAD. However, CPR's analysis reveals that VECT actually employs raw ChaCha20-IETF (RFC 8439) without any authentication. There is no Poly1305 MAC and no integrity protection. This misidentification has led to inaccurate assumptions about the ransomware's capabilities.
Nonce Handling Failure
The core issue stems from how VECT handles nonces during encryption. The implementation uses a four-chunk encryption logic for files above 128 KB. For each chunk, the algorithm should generate a unique nonce. Instead, it reuses the same nonce for the first three chunks and only generates a distinct nonce for the fourth. Because the decryption process requires all four nonces, and three are never stored or transmitted, recovery becomes impossible. This is not a deliberate design choice but a programming error that makes the ransomware effectively a wiper for any substantial file.
Cross-Platform Consistency: One Flawed Codebase
VECT 2.0 ransomware is available for Windows, Linux, and ESXi environments. CPR discovered that all three variants share an identical encryption engine built on libsodium. The same file-size thresholds, the same four-chunk logic, and the same nonce-handling flaw appear across every platform. This confirms that the ransomware is developed from a single codebase, ported directly to different operating systems. Despite the varying distribution methods and execution environments, the underlying vulnerability remains consistent.
Advertised Features That Do Not Work
Encryption Speed Modes Not Implemented
VECT advertises three encryption speed modes: --fast, --medium, and --secure. These flags appear in the Linux and ESXi variants. However, CPR found that the software parses these flags and then silently ignores them. Every execution uses identical hardcoded thresholds regardless of which mode the operator selects. This means the advertised performance optimization is a complete facade.
Professional Facade, Amateur Execution
Beyond the critical nonce flaw, CPR identified multiple additional bugs and design failures across all VECT variants:
- Self-cancelling string obfuscation: The obfuscation method used to hide strings inadvertently cancels itself out, making the strings easily readable.
- Permanently unreachable anti-analysis code: Some code paths intended to hinder reverse engineering are never executed due to logical errors.
- Ineffective thread scheduler: A custom thread scheduler designed to improve encryption performance actually degrades it, actively slowing down operations.
These issues highlight how VECT presents itself as a sophisticated Ransomware-as-a-Service (RaaS) but suffers from fundamental programming mistakes that undermine its effectiveness and reliability.
Background of VECT Ransomware
VECT Ransomware first appeared in December 2025 on a Russian-language cybercrime forum as a Ransomware-as-a-Service (RaaS) program. After claiming its first two victims in January 2026, the group gained public attention through a partnership with TeamPCP, the actor behind several supply-chain attacks in March 2026. These attacks injected malware into popular software packages such as Trivy, Checkmarx's KICS, LiteLLM, and Telnyx, affecting a large base of downstream consumers. Shortly after these attacks made headlines, VECT announced on BreachForums their collaboration with TeamPCP, aiming to exploit the companies impacted by those supply-chain incidents.
Additionally, VECT announced a partnership with BreachForums itself. The group promised that every registered forum user would become an affiliate, gaining access to the VECT ransomware, negotiation platform, and leak site for operations. Traditionally, ransomware groups allow affiliates to join either base. This move was unusual and aimed at expanding their affiliate network rapidly.
Given the encryption flaw detailed above, any organization affected by VECT should not expect to recover large files. The ransomware's design, intended to extort money, instead destroys data permanently. Security teams must consider this when planning incident response and recovery efforts.