VECT 2.0 ransomware can leave victims with files that even the attacker’s own decryptor cannot reliably restore. While researchers previously exposed a cross-platform design flaw that discards nonces for earlier parts of large files, our Windows-focused analysis shows additional implementation errors that create more recovery gaps.
These errors can leave files renamed, partially encrypted, inconsistently modified, or otherwise damaged in ways the decryptor cannot reverse.
The sample we analyzed is a 64-bit Windows PE labeled VECT 2.0 ransomware. Comparing it with related builds helped separate common VECT behaviors from mistakes unique to this Windows implementation.
VECT targets by exclusion: it walks accessible folders and skips certain system directories, protected filenames, and executable types such as .exe, .dll, and .sys.
That means ordinary business data documents, PDFs, archives, backups, databases, and virtual disks remain in scope whenever accessible.
A critical detail is the file processing order. VECT renames files by appending a .vect suffix before it starts encrypting content.
As a result, the presence of .vect signals that a file entered processing, but not that encryption succeeded. Files can be renamed and still remain plaintext, partially modified, or structurally inconsistent.
According to Morphisec, positions its technology to address both sides of this problem: stopping VECT from completing its attack and recovering eligible files after encryption has occurred.
There is no magic marker, version number, original file size, chunk table, encrypted key blob, or authentication tag. In the sample we observed, the encryptor reuses an encryption context across files while generating a fresh 12-byte nonce for each encrypted region.
That design produces the known large-file problem: for files larger than 128 KB, VECT splits a file into four quadrants and encrypts a 32 KB block at the start of each quadrant using four different nonces, but writes only the final nonce to disk.
Because earlier nonces are lost, the decryptor cannot reconstruct the other encrypted regions, producing damaged files after attempted recovery.
VECT 2.0 Ransomware Breaks Files
Beyond this design-level nonce loss, the Windows build exhibits further implementation flaws that worsen recoverability. First, a single-pass encryption path contains a buffer-size mismatch.
On-disk metadata from VECT is minimal. The ransomware appends only a 12-byte trailer that stores the last ChaCha20 IETF nonce used during encryption.
Files up to 0x20000 bytes (128 KB) are routed into a code path that may pass the full file size to ReadFile, yet the actual encryption buffer allocated for content reads is only 0x8000 bytes (32 KB).
Files whose size is between 32 KB and 128 KB can therefore be read into an undersized buffer. Depending on timing and runtime conditions, such a file might be renamed without being encrypted, processing may fail partway through, or writes may leave the file inconsistent.
Second, the encryptor uses process-global buffers to hold per-file state. The routine that builds the .vect filename uses a shared path buffer, and the content read buffer (32 KB) is reused across worker threads.
VECT creates concurrent scanner and encryptor workers to speed processing, but the per-file routine does not keep that state local.
Under concurrent execution, one worker can overwrite the path or content buffer while another worker still depends on it.
Those race conditions can produce partially written or corrupted files, inconsistent filenames, and other anomalies that a generic decryptor is not designed to handle.
These design and implementation problems mean a VECT rarely produces a single, uniform class of encrypted files.
The same .vect suffix can indicate a file that was only renamed, a file encrypted in a single pass, a large file with scattered encrypted blocks, or a file left inconsistent by failed writes or buffer races.
Generic decryptors assume a consistent file format; when that assumption is violated, recovery fails. That’s why prevention and recovery tools that understand these edge cases blocking the attack early and performing tailored recovery when safe are essential to limit damage from VECT 2.0.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
Click Here For The Original Source.
