VECT’s failure goes beyond the known nonce bug. The Windows implementation contains additional flaws that can leave files renamed, partially encrypted, inconsistently modified, or damaged in ways the attacker’s own decryptor cannot reliably reverse.
Morphisec is built to address both sides of this problem: preventing VECT from completing the attack and recovering eligible files when encryption has already occurred.
Our analysis of a Windows VECT 2.0 sample shows how these recovery gaps are created, why affected files may end up in different states, and why specialized prevention and recovery capabilities matter.
Check Point Research established the cross-platform nonce-loss flaw in VECT’s encryption design. This post focuses on the Windows file-processing path and the recovery-relevant edge cases we observed, including rename-first behavior, medium-file buffer handling, shared global state, and file-state classification.
Threat Analysis
Sample Overview
The analyzed sample is a 64-bit Windows PE identified as VECT 2.0. We also compared it with related VECT-family builds, including one with DEVMAN 3.0 branding, to separate common behavior from build-specific implementation details.
File Targeting and Rename Behavior
VECT’s targeting model is hard coded exclusion-based. Rather than encrypting only a narrow list of document extensions, the malware walks accessible paths and skips selected system directories, protected filenames, and executable file types such as .exe, .dll, and .sys. This leaves common business data, including documents, PDFs, archives, backups, databases, and virtual disks, in scope when they are accessible.
The file processing order is important. VECT appends the .vect suffix and renames the file before encryption begins. Only after the rename does it open the new path and modify file content. This means the .vect extension is an indicator of processing, not proof that encryption was completed successfully. A file can be renamed and still be plaintext, partially modified, or structurally inconsistent.
Minimal Recovery Metadata
The on-disk metadata is minimal. VECT appends only a 12-byte trailer containing the last ChaCha20-IETF nonce produced during encryption. There is no magic value, version field, original file size, chunk table, encrypted key blob, or authentication tag. In the sample analyzed here, the same encryption context is reused across file operations, while a fresh 12-byte ChaCha20-IETF nonce is generated for each encrypted region.
The known large-file issue follows directly from this design. For files larger than 128 KB, VECT divides the file into four quadrants and encrypts a 32 KB block at the start of each quadrant, using four different nonces, but only the final nonce is preserved on disk. That means VECT can create damaged files that its own decryptor cannot fully restore, because the file format does not retain enough metadata to describe what the malware did.
Additional Windows Implementation Flaws
Our research found additional Windows-specific flaws beyond that published nonce-loss issue.
First, the single-pass encryption path contains a buffer-size mismatch. VECT routes files with a file size up to 0x20000 bytes, or 128 KB, into a code path that may pass the full file size to ReadFile. The encryption buffer, however, is only 0x8000 bytes, or 32 KB. Files in the range 32 KB < size <= 128 KB can therefore enter a code path whose destination buffer is too small. Depending on runtime behavior, the file may be renamed without being encrypted, fail during processing, or end up in an inconsistent state.
Second, the encryptor uses process-global buffers for critical per-file state. The path buffer used to build the .vect filename and the 32 KB content buffer used for file reads are shared across encryptor threads. VECT creates scanner and encryptor workers to process files concurrently, but the per-file routine does not keep this state local to the worker handling the file. Under concurrent execution, one worker can overwrite path or content state while another worker is still using it.
Recovery Implications
These bugs change the recovery picture. A VECT incident does not necessarily produce one clean class of encrypted files. The same .vect suffix can represent several outcomes: a file that was only renamed, a file encrypted in a single pass, a large file with only selected regions modified, or a file left inconsistent by failed writes or shared-state races.
That distinction matters because a generic decryptor usually follows the attacker’s assumptions about the file format. VECT’s own implementation violates those assumptions.
How Morphisec Helps
Morphisec’s approach is prevention-first and the Morphisec Anti-Ransomware Assurance Platform is designed to stop ransomware execution paths before encryption can be completed, reducing the attacker’s ability to reach scale across endpoints and workloads.
When encryption has already occurred, Morphisec’s Adaptive Recovery capabilities address the second side of the problem: identifying the file states VECT leaves behind and recovering files without relying on VECT’s own recovery logic.
That is the core gap exposed in our research findings.
VECT can damage files in ways its own decryptor cannot reliably repair. Morphisec helps close that gap by preventing the attack, and by decrypting files.
Book a demo today to see how Morphisec stops advanced threats.
Stay up-to-date
Get the latest resources, news, and threat research delivered to your inbox.
