Broken VECT 2.0 Ransomware Acts as a Data Wiper for Large Files

What happened

Check Point researchers have disclosed that VECT 2.0 ransomware contains a critical flaw in its nonce handling logic that causes it to permanently destroy large files rather than encrypt them, making recovery impossible even if a victim pays the ransom.

The flaw affects VECT’s chunked encryption process for files above 128KB. Because all chunk encryptions use the same memory buffer for the nonce output, each new nonce overwrites the previous one. When processing completes, only the last nonce generated remains in memory and is written to disk. The result is that only the final 25% of any large file is recoverable. The preceding three quarters are permanently destroyed because the nonces required for decryption no longer exist anywhere, including on the attacker’s infrastructure. VECT operators could not decrypt affected files for paying victims even if they wanted to.

The same flaw is present across all VECT 2.0 variants, covering Windows, Linux, and ESXi. Check Point notes that at a 128KB threshold, virtually every file an enterprise would prioritize recovering falls into the unrecoverable category, including VM disks, database files, backups, spreadsheets, mailboxes, and routine office documents.

VECT has been advertised on BreachForums as a ransomware-as-a-service operation recruiting affiliates. Its operators announced a partnership with TeamPCP, the threat group behind recent supply chain attacks on Trivy, LiteLLM, and Telnyx, as well as an attack on the European Commission. The stated intent of the partnership was to deploy VECT ransomware payloads in environments already compromised through TeamPCP’s supply chain operations and to conduct further attacks against other organizations.

Who is affected

Any organization targeted by VECT 2.0 or operating in environments previously compromised by TeamPCP supply chain attacks faces a destructive wiper scenario rather than a recoverable ransomware event. ESXi and Linux environments are explicitly within scope alongside Windows, covering the virtualization and server infrastructure where the most valuable enterprise data typically resides.

Why CISOs should care

Paying the ransom does not work. That is the most operationally significant fact about VECT 2.0. Organizations that factor ransom payment into their incident response calculus as a recovery option need to understand that this ransomware, by accident rather than design, removes that option entirely. The data is gone.

The partnership between VECT operators and TeamPCP is also a meaningful escalation. TeamPCP has already established footholds across multiple organizations through the Trivy, LiteLLM, and Telnyx supply chain compromises. VECT gives that access a destructive payload. Organizations that have not fully remediated TeamPCP-related exposure from those incidents should treat this development as an active threat to operational continuity.

3 practical actions

1. Treat any VECT 2.0 infection as a destructive wiper event, not a recoverable ransomware incident: Do not factor ransom payment into your response planning. Activate disaster recovery procedures immediately, prioritize restoration from offline backups, and accept that files above 128KB that were processed by VECT 2.0 are permanently unrecoverable.
2. Validate offline backup integrity for environments exposed to TeamPCP supply chain compromises: Given the stated intent to deploy VECT payloads in environments compromised through Trivy, LiteLLM, and related supply chain attacks, organizations that used those tools should verify that their offline backups are clean, current, and restorable before a destructive event occurs.
3. Prioritize detection of VECT 2.0 indicators published by Check Point before encryption begins: The only viable response to a wiper disguised as ransomware is catching it before it runs. Integrate Check Point’s published indicators of compromise into your endpoint detection and threat hunting workflows, and review whether your monitoring covers the ESXi and Linux environments where the impact would be most catastrophic.