VECT 2.0 ransomware can damage files its own decryptor may not restore

VECT 2.0 ransomware can leave victims with broken files even if they pay for a decryptor. The problem comes from flaws in the ransomware’s own file handling and encryption logic, which can rename files, partially encrypt them, or destroy recovery data needed for decryption.

A new Morphisec analysis of a Windows VECT 2.0 sample found that the malware can create several file states during one infection. Some files may receive the .vect extension without full encryption. Others may become partially modified or structurally damaged.

The findings build on earlier research from Check Point Research, which warned that VECT 2.0 can behave like a wiper for files larger than 128 KB. In those cases, full recovery may be impossible because the ransomware discards nonce data required to reverse the encryption process.

Why VECT 2.0 can break recovery

VECT 2.0 targets Windows, Linux, and VMware ESXi systems. The Windows sample analyzed by researchers is a 64-bit portable executable that targets common business data, including documents, archives, databases, backups, PDFs, and virtual disk files.

Instead of targeting only a small list of file extensions, the malware walks accessible paths and skips selected exclusions. That approach puts a wide range of business files at risk whenever the ransomware reaches shared drives or local storage.

One major design issue starts before encryption begins. VECT renames files first by adding the .vect extension, then attempts to encrypt their contents. As a result, a .vect file does not always prove that encryption succeeded.

File state	What it means	Recovery impact
Renamed only	The file has the .vect extension but may still contain plaintext data.	Recovery may require triage before any decryptor is used.
Partially encrypted	Only selected blocks were modified before the process failed or moved on.	Standard decryption may not repair the file cleanly.
Structurally damaged	The malware changed file content without preserving enough recovery data.	The attacker’s own decryptor may fail.
Fully processed by flawed logic	The malware completed its intended routine but saved incomplete nonce data.	Large files may remain unrecoverable.

The nonce flaw makes large files especially risky

For larger files, VECT 2.0 uses intermittent encryption. It splits the target into sections and encrypts selected chunks instead of encrypting the full file from start to finish.

The problem is that each encrypted chunk needs its own nonce for safe decryption. Check Point found that VECT keeps only the final 12-byte nonce and discards the earlier ones for files above 128 KB.

That makes the damage permanent in many cases. Even if the ransomware operator provides a working decryptor and a valid key, the decryptor cannot reconstruct nonce values that the malware never saved.

Morphisec found more Windows-specific problems

The latest Morphisec report says the Windows implementation has additional recovery problems beyond the known large-file nonce issue. These include rename-first behavior, buffer handling errors, and shared global state across worker threads.

Files between 32 KB and 128 KB may enter a single-pass encryption path where buffer handling can fail. Depending on runtime behavior, the ransomware may rename the file without encrypting it, fail during processing, or leave the file in an inconsistent state.

Multi-threading also creates risk. VECT uses worker threads to process files at the same time, but those workers share global buffers for paths and file content. If one thread overwrites data while another still relies on it, the result can include corrupted paths, incorrect writes, or broken output files.

VECT’s operation is still expanding

VECT appeared as a ransomware-as-a-service operation in late 2025 and began attracting attention in early 2026. JUMPSEC reported that the group promoted an affiliate model and later connected itself to TeamPCP activity after supply chain attacks involving developer and security tools.

That wider access model matters because even flawed ransomware can cause serious business disruption. The code may fail at reliable decryption, but it can still damage files, interrupt operations, and create a costly recovery event.

Halcyon also warned that victims should not assume ransom payment will restore data. Its analysis says VECT’s flawed modes can make recovery ineffective and may require organizations to pivot quickly toward backups and incident response.

What makes VECT different from ordinary ransomware

Most ransomware groups rely on the promise that payment unlocks files. VECT weakens that promise because its own encryption workflow can destroy or omit the information required for recovery.

This does not make the malware less dangerous. It makes it more unpredictable. A victim may face encrypted files, renamed plaintext files, partially modified data, and corrupted files inside the same incident.

That inconsistency can slow recovery teams because they cannot treat every .vect file the same way. They must first classify what happened to each file before choosing a restoration path.

• Do not assume every .vect file was encrypted successfully.
• Preserve affected systems before running third-party tools.
• Check file headers and sample file contents before bulk recovery attempts.
• Prioritize clean offline backups over ransom negotiation.
• Collect forensic evidence for incident response and insurance review.
• Isolate affected systems to stop further file processing.

Detection and response priorities

Security teams should focus on prevention and early containment. Once VECT processes files, the attacker’s decryptor may not reliably return them to a usable state.

The most visible artifact is the .vect extension, but that alone does not prove successful encryption. Defenders should also monitor for ransom notes, unexpected file renaming activity, high-volume file modifications, and suspicious execution from user-writable directories.

Halcyon’s ransomware alert notes that VECT checks for a marker file at C:\ProgramData\.vect before execution. Organizations should validate defensive recommendations in a controlled environment before deploying any mitigation broadly.

Indicator or behavior	Why it matters
.vect extension	Shows that VECT attempted to process the file, but does not prove full encryption.
!!!READ_ME!!!.txt	Ransom note associated with VECT activity.
dvm3_wall.bmp	Wallpaper artifact linked to VECT 2.0 branding.
Rapid file renaming	May appear before full encryption or before failed encryption attempts.
Unusual file writes across shares	May indicate active ransomware movement through accessible storage paths.

Why backups matter more than payment

VECT’s technical flaws change the recovery calculation. Paying a ransom does not guarantee access to working data because some files may lose the information required for decryption during the attack itself.

Organizations should rely on tested, isolated, and immutable backups. They should also rehearse restoration procedures so teams know how long recovery will take before a real incident occurs.

JUMPSEC’s analysis described VECT as an operation with a professional-looking affiliate structure but weak technical execution. That mix can still harm businesses because unreliable ransomware can create the same downtime as a polished criminal tool, while leaving fewer clean recovery options.

The practical lesson is direct. VECT 2.0 should be treated as both ransomware and a potential data-destruction risk. Prevention, segmentation, least privilege, and reliable backups remain the strongest defense.

FAQ