Vect 2.0 Case Study: When Ransomware Evolves into an Unintended Wiper

The appearance of Vect ransomware on the scene took place in late December 2025. The gang developed relationships with several underground communities, such as BreachForums and TeamPCP, with the goal of developing a massive RaaS platform through the recruitment of affiliates.

This ransomware family works under Windows, Linux, and VMware ESXi and employs an advanced encryption engine based on C++. The fast expansion of Vect caught everyone’s attention owing to its destructive capability towards virtual environments like virtual disks and back-ups.

It was presented as having extremely fast encryption capabilities that combine ChaCha20 cipher algorithm with Poly1305 integrity verification. But once again, there’s always the difference between what one says and does. In spite of promoting ChaCha20 with Poly1305, Vect does indeed employ ChaCha20 but without Poly1305 there’s just encryption without integrity verification.

Critical Encryption Flaw: From Ransomware to Wiper

A significant problem associated with Vect 2.0 is that of improper handling of keys.

In case of files greater than 128 kilobytes, Vect breaks them into four pieces, encrypting them using separate nonces. Yet due to some bug in the code, only one nonce is saved to the end of the file, while the other three nonces get deleted after processing in memory.

As a consequence:

• Only the final 25% of the file retains a valid encryption key.
• The remaining 75% becomes permanently unrecoverable.

Which makes it impossible for even the attackers to decrypt the files, because the required key data got lost along the way.

File Handling Behavior

Files smaller than 128 KB:

• Encrypted in a single pass
• A single 12-byte nonce is appended
• Fully recoverable with the correct key

Files larger than 128 KB:

• Split into four segments
• Each segment uses a different nonce
• Only the last nonce is preserved
• 75% of the file becomes unrecoverable

This flaw transforms Vect from ransomware into a wiper. Since the decryption keys are partially lost, recovery is impossible even if a ransom is paid.

Cross-Platform Design and Additional Weaknesses

All three versions of Vect that target Windows, Linux, and ESXi use the same code. Vect incorporates libsodium statically and applies the same encryption algorithm on all platforms.

But there are some features advertised by Vect that do not function properly:

• Command-line options such as --fast, --medium, and --secure are parsed but never used.
• All modes rely on the same fixed threshold (128 KB).
• String obfuscation routines are poorly implemented and effectively cancel each other out.

Despite the fact that the interface looks advanced, a lot of functions inside remain unimplemented.

As far as cryptography is concerned, Vect makes use of the ChaCha20-IETF cipher in all its communications. Even though the encryption algorithm proves to be effective when it comes to the lack of hardware acceleration for AES, the lack of Poly1305 authenticator becomes a significant flaw in the program.

Impact on Victims

Paying the ransom in a Vect attack does not provide a viable recovery path.

Because nonce data for large files is lost, most encrypted data cannot be restored. Even the attackers are incapable of providing a functional decryptor. This fundamentally differentiates Vect from typical ransomware, where data recovery is at least theoretically possible.

In this case, the attack behaves as a destructive operation rather than extortion.

Victims are left with only a few options:

• Restore from secure, offline backups
• Isolate affected systems immediately
• Execute incident response and recovery plans

The ransom note provides no real guarantee of recovery. Instead, the focus must shift to damage containment and rapid restoration.

Affiliations and Attack Techniques

Vect operators collaborate with groups such as TeamPCP and maintain ties to BreachForums, targeting high-value enterprise environments.

Observed attack techniques include:

Safe Mode Execution:
Vect reboots Windows systems into Safe Mode to disable security tools, allowing encryption to proceed with minimal interference.

Network Discovery and Lateral Movement:

• Uses SMB shares, WMI, and PowerShell Remoting on Windows
• Uses SSH/SCP on Linux and ESXi
• Spreads via stolen credentials and administrative privileges

Virtual Disk Targeting:
The ESXi variant specifically targets large virtual disk files (VMDK/VHD), which are highly susceptible to irreversible damage due to the encryption flaw.

Process and Service Termination:
Terminates backup, database, and security-related processes to ensure files can be encrypted.

Cryptocurrency Usage:
Operations rely on privacy-focused cryptocurrencies such as Monero. Infrastructure is hosted on Tor hidden services, complicating tracking and attribution.

Case Study: Xcitium vs. Vect Ransomware

This demonstration highlights how Xcitium protects endpoints from ransomware attacks using a prevention-first security model. In this test, multiple live Vect ransomware samples are executed in a controlled environment to simulate a realistic, multi-variant attack scenario.

Instead of relying on signatures, reputation checks, or reactive detection methods, Xcitium’s ZeroDwell isolation technology automatically classifies each Vect sample as untrusted at the moment of execution and runs it inside a secure isolation environment.

As a result, Vect is unable to complete its attack lifecycle. File encryption attempts including its flawed multi-segment encryption routine are fully isolated, preventing both data encryption and the irreversible data destruction caused by its nonce mismanagement bug. Persistence mechanisms fail to impact the host, and command-and-control communication does not succeed even though the ransomware samples are fully operational.

By eliminating the exposure window entirely, Xcitium keeps the endpoint fully functional and uncompromised. This video demonstrates how destructive ransomware like Vect capable of acting as a wiper due to critical implementation flaws is neutralized instantly through continuous zero-trust execution and real-time isolation.

MITRE ATT&CK Tactics, Techniques, and Procedures (TTPs)

Indicators of Compromise (IOCs)

Key indicators associated with Vect ransomware include:

• Encrypted File Extension: .vect (Added to all targeted files)
• Ransom Note: !!!READ_ME!!!.txt (Dropped in each directory after encryption)
• Monero Wallet: Example: 876yVkL4S7p5rW... (Used for ransom payments and affiliate transactions)
• Tor Address: vectordntlcrlmfkcm4alni734tbcrnd5lk44v6sp4lqal6noqrgnbyd.onion
bu7zr6fotni3qxxoxlcmpikwtp5mjzy7jkxt7akflnm2kwkbdtgtjuid.onion (TOR used for the affiliate panel and ransom negotiations)

Vect Ransomware SHA-1 Samples & Zero‑Dwell Threat Intelligence Reports

Conclusion: When Ransomware Becomes a Wiper by Mistake

Vect 2.0 proves that ransomware recovery is no longer something victims can assume. A critical nonce-handling flaw means large files are not just encrypted, they are partially destroyed. Only the final segment retains the information needed for recovery, leaving most of the data permanently unrecoverable, even for the attackers themselves.

Why This Threat Changes the Stakes

Traditional ransomware at least pretends recovery is possible after payment. Vect breaks that assumption.

• Files larger than 128 KB lose the nonce data needed to decrypt most of their contents.
• The flaw affects Windows, Linux, and ESXi variants that share the same codebase.
• Virtual disk files such as VMDK and VHD are especially exposed to irreversible damage.
• Paying the ransom does not create a viable recovery path.

When ransomware behaves like a wiper, response is already too late.

Where Xcitium Changes the Outcome

If you have Xcitium, this attack does not succeed.

With Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, Vect fails at execution.

• Vect samples are treated as untrusted the moment they run.
• Encryption attempts cannot reach real files or virtual disks.
• The flawed multi-segment routine never gets the chance to destroy recoverability.
• Persistence and command-and-control attempts fail before impact.

Code can run without being able to cause damage, even when the ransomware itself is broken enough to become destructive.

Protect Data Before Recovery Becomes Impossible

Vect 2.0 is a warning that some ransomware incidents cannot be fixed after the fact. Offline backups still matter, but prevention must happen before execution, before encryption, and before irreversible data loss begins.

Choose Xcitium Advanced EDR.