VECT Ransomware: Uncovering the Accidental Wiper Flaw

In this detailed Q&A, we explore the findings of Check Point Research on the VECT 2.0 ransomware, which turned out to be an unintentional wiper due to a critical encryption flaw. From its emergence as a RaaS to the partnership with TeamPCP, and the technical analysis revealing a broken nonce implementation, this breakdown covers the key takeaways and background of the VECT ransomware campaign.

What is VECT ransomware and how did it emerge?

VECT Ransomware is a Ransomware-as-a-Service (RaaS) program first spotted in December 2025 on a Russian-language cybercrime forum. After claiming its initial victims in January 2026, it gained notoriety through a partnership with TeamPCP, the group behind several supply-chain attacks in March 2026. These attacks injected malware into popular software packages like Trivy, Checkmarx's KICS, LiteLLM, and Telnyx, impacting many downstream users. Shortly after those attacks made headlines, VECT announced its alliance with TeamPCP on BreachForums, aiming to exploit companies affected by the supply-chain compromises. Additionally, VECT partnered with BreachForums itself, promising every registered user affiliate status — giving them access to the ransomware, negotiation platform, and leak site. Traditionally, ransomware groups limit affiliates through vetting, but VECT's open approach marked a significant shift.

What critical flaw did Check Point Research discover in VECT 2.0?

Check Point Research uncovered a critical flaw in VECT 2.0's encryption implementation that permanently destroys large files instead of encrypting them. For any file exceeding 131,072 bytes (128 KB), three out of four decryption nonces are discarded — across all three platform variants: Windows, Linux, and ESXi. This means that full recovery is impossible, even for the attackers themselves. With a threshold of just 128 KB, this design error effectively turns VECT into a wiper for virtually any file containing meaningful data, including virtual machine disks, databases, documents, and backups. CPR confirmed this flaw exists in all publicly available VECT versions, making it a persistent vulnerability that cannot be fixed by updating the ransomware.

How does the encryption flaw make VECT a wiper by accident?

The ransomware's encryption logic splits files larger than 128 KB into four chunks, each encrypted with a unique nonce. However, due to a bug in the code, only the nonce for the first chunk is retained; the other three nonces are discarded. Without those nonces, decryption of the second, third, and fourth chunks is mathematically impossible. Since the first chunk is a small fraction of the file, the data is effectively destroyed. While VECT's operators intended to encrypt files for ransom, this flaw makes the ransomware a wiper — it permanently erases data, not because of malicious intent but because of a programming error. For victims, this means paying the ransom will not recover their files, as even the attackers lack the necessary nonces. The only recoverable portion is the tiny first chunk, which contains no meaningful content.

Why has the cipher used by VECT been misidentified?

Public reporting incorrectly identified the encryption cipher used by VECT. Most threat intelligence sources — and even VECT's own advertisements — claimed it used ChaCha20-Poly1305, an authenticated encryption scheme. In reality, Check Point Research found that VECT uses raw ChaCha20-IETF (RFC 8439) without any authentication. There is no Poly1305 MAC and therefore no integrity protection for the encrypted data. This misidentification matters because it can mislead defenders about the ransomware's capabilities. Without authentication, an attacker cannot verify that data hasn't been tampered with, and more importantly, the absence of a MAC simplifies the encryption logic — but also leaves it vulnerable to the nonce flaw. The reliance on a pure, unauthenticated stream cipher is another sign of amateur implementation behind a professional facade.

What are the issues with VECT's advertised encryption speed modes?

VECT advertised three encryption speed modes — --fast, --medium, and --secure — across its Linux and ESXi variants, giving operators the impression they could control performance versus security trade-offs. However, Check Point Research discovered that these flags are parsed and then silently ignored. Every execution uses identical hardcoded thresholds, regardless of the operator's selection. This means that the promised speed customization is entirely non-functional. For ransomware operators, this is a significant usability failure — they cannot tune the malware for different target environments. For defenders, knowing that all runs behave the same simplifies forensic analysis; the encryption pattern is deterministic and predictable, which can aid in identifying VECT infections.

How do the three platform variants compare in encryption design?

The Windows, Linux, and ESXi variants of VECT share an identical encryption engine built on libsodium, confirming a single codebase ported across platforms. All three use the same file-size thresholds, the same four-chunk logic, and crucially, the same nonce-handling flaw. This consistency indicates that the developer did not adapt the encryption for different operating systems but simply compiled the same flawed code. The unified design also means that when Check Point Research discovered the bug in one variant, it applied to all. For victims, this is particularly dangerous because all platforms where VECT has been deployed suffer from the permanent data loss issue. The lack of platform-specific optimization also suggests the developers prioritized speed of deployment over correctness.

What other bugs and design failures did CPR identify beyond the nonce flaw?

Check Point Research found multiple additional bugs and design failures across all VECT variants, painting a picture of amateur execution behind a professional marketing front. These include self-cancelling string obfuscation that effectively does nothing, permanently unreachable anti-analysis code (dead code that never executes), and a thread scheduler that actually degrades encryption performance instead of improving it. The scheduler, meant to parallelize encryption, introduces races and overhead that slow down the process. Collectively, these issues demonstrate that while VECT presents a polished RaaS brand with partnerships and leak sites, the underlying code is riddled with errors. For defenders, these bugs provide opportunities — for example, the dead anti-analysis code can be used to fingerprint VECT, and the deterministic nature of the flawed encryption can help recover some metadata.