VECT Ransomware: Encryption Flaw Turns It Into an Accidental Wiper

Overview

Ransomware groups usually aim to encrypt files to demand a ransom. But a recent discovery by Check Point Research (CPR) shows that the VECT ransomware—marketed as a sophisticated encryption tool—actually destroys large files instead of locking them. A critical design flaw in its encryption logic renders recovery impossible for victims and even the attackers themselves. This article dissects the flaw, its implications, and the broader context of VECT's activities.

Key Findings

• Permanent destruction of large files: VECT 2.0 irreversibly wipes files larger than 128 KB instead of encrypting them.
• Fatal nonce handling flaw: Across all three platform variants (Windows, Linux, ESXi), the encryption implementation discards three out of four decryption nonces for files exceeding 131,072 bytes (128 KB). This makes full recovery impossible for anyone.
• Misidentified cipher: Public reports incorrectly claim VECT uses ChaCha20-Poly1305 AEAD. CPR confirmed it uses raw ChaCha20-IETF (RFC 8439) with no authentication—no Poly1305 MAC, no integrity protection.
• Unimplemented speed modes: The advertised --fast, --medium, and --secure flags in Linux and ESXi variants are parsed but silently ignored. All executions apply the same hardcoded thresholds.
• Shared flawed engine: Windows, Linux, and ESXi versions share identical encryption logic built on libsodium, with the same file-size thresholds, four-chunk approach, and nonce bug, indicating a single codebase ported across platforms.
• Amateur execution behind a professional facade: Beyond the nonce flaw, CPR identified multiple bugs including self-cancelling string obfuscation, unreachable anti-analysis code, and a thread scheduler that actually degrades encryption performance.

Background

VECT emerged in December 2025 as a Ransomware-as-a-Service (RaaS) offering on a Russian-language cybercrime forum. Its first known victims appeared in January 2026. The group gained broader attention after announcing a partnership with TeamPCP, an actor behind several supply-chain attacks in March 2026. These attacks injected malware into widely used software packages like Trivy, Checkmarx KICS, LiteLLM, and Telnyx, affecting a large downstream base. Shortly after those incidents made headlines, VECT posted on BreachForums declaring its alliance with TeamPCP, aiming to exploit companies impacted by the supply-chain compromises.

In a further move, VECT also partnered with BreachForums itself, promising that every registered forum user would become an affiliate—able to use the VECT ransomware, negotiation platform, and leak site for operations. This open recruitment strategy contrasts with typical ransomware groups that vet affiliates carefully.

Technical Analysis of the Encryption Flaw

How VECT Encrypts Files

VECT uses the ChaCha20-IETF stream cipher from the libsodium library. The encryption process divides files into four chunks: the first chunk contains metadata and is encrypted normally; the next two chunks store encryption parameters; the fourth chunk contains the bulk of the data. The critical bug lies in how the encryption nonces are derived and stored.

The Nonce Bug

For files larger than 128 KB, VECT divides the data into segments and encrypts each segment with a different nonce. However, the implementation incorrectly writes only one nonce—the first—into the file header, discarding the nonces for the remaining three chunks. Without those nonces, decryption is impossible. Since the file is irreversibly scrambled, VECT effectively acts as a wiper for any file containing meaningful data, including enterprise assets such as VM disks, databases, documents, and backups.

CPR confirmed this flaw exists in all publicly available VECT versions, suggesting it was never caught during development or testing.

Misidentified Cipher

Several prominent threat intelligence reports (and VECT's own advertisements) claimed the ransomware used ChaCha20-Poly1305 AEAD, which includes authentication via a MAC. In reality, VECT employs raw ChaCha20-IETF (RFC 8439) without any Poly1305 MAC. This means there is no integrity protection; an attacker or victim cannot verify whether a file was tampered with—though given the nonce flaw, integrity is moot anyway.

Unimplemented Features

The Linux and ESXi variants include command-line flags for encryption speed modes: --fast, --medium, and --secure. These are parsed but then silently ignored; every execution uses the same hardcoded thresholds regardless of the operator's selection. This reveals rushed development and a failure to deliver advertised capabilities.

Three Platforms, One Flawed Engine

VECT offers variants for Windows, Linux, and ESXi. CPR's analysis shows that all three share an identical encryption design built on libsodium, with the same file-size thresholds, the same four-chunk logic, and the same nonce-handling flaw. This confirms a single codebase ported across platforms—a double-edged sword that made the bug universal.

Additional Bugs and Design Failures

Beyond the critical nonce flaw, CPR found multiple amateur mistakes:

• Self-cancelling string obfuscation: Obfuscated strings in the binary cancel themselves out, making the obfuscation pointless.
• Unreachable anti-analysis code: Dead code intended to evade debugging is permanently unreachable.
• Ineffective thread scheduler: A custom thread scheduler meant to improve encryption performance actually degrades it due to poor implementation.

These issues underscore a wide gap between VECT's professional marketing and its amateur coding.

Implications for the Cybersecurity Community

The discovery that VECT is an accidental wiper has several implications:

• No recovery possible: Victims cannot pay to recover their data because even the attackers lack the decryption nonces. Backup restoration is the only option—but if backups were also encrypted (or wiped), data loss is permanent.
• Reputation damage for RaaS operators: VECT's partners, including TeamPCP and BreachForums affiliates, may face backlash as victims realize the ransomware does not deliver the promised decryption. This could erode trust in the RaaS model.
• Need for better code review: The bug highlights the importance of thorough testing in ransomware (and all) software. A simple unit test checking nonce storage would have caught this flaw.

Check Point Research recommends that organizations treat any VECT infection as a destructive attack, not a typical ransomware incident. Incident response teams should focus on containment and restoring from clean backups, without any expectation of paying for decryption.

Conclusion

VECT ransomware marketed itself as a professional tool, but under the hood it suffers from a catastrophic design flaw that turns it into a wiper for files over 128 KB. The same bug plagues all three platform variants, and the lack of authentication, unimplemented speed modes, and additional amateur mistakes paint a picture of a hastily assembled operation. For defenders, the key takeaway is clear: if you encounter VECT, treat it as a wiper—and ensure your backups are offline and immutable.