InfoSecBulletin Cybersecurity for mankind
Threat hunters say that the cybercrime group called VECT 2.0 is more like a wiper than ransomware. This is because of a big mistake in how it encrypts files on Windows, Linux, and ESXi systems, making recovery impossible even for the criminals.
Check Point Research (CPR) looked at VECT 2.0 samples for Windows, Linux, and VMware ESXi and found a main design problem in the core encryption method used by all three platforms.
After BDJobs, Directorate of Secondary and Higher Education 390k data surfaced online
Researchers show new technique to bypass AI safety guardrails in Grok and Gemini
About thousands of leaked AWS keys Held Full Admin Rights
US Bank investigates LockBit’s Data Breach Claims
Five new malware families actively targeting Asian Gov.t infra
T-Mobile Cuts Cables to Remove Chiness Salt Typhoon Hackers from Network
Splunk, Zyxel Patch Multiple Flaws Enabling RCE and Root Command Execution
“Zombie Card” attack revels expired Visa card may be used for contactless payments
Critical Zimbra RCE Flaw Actively Exploited in the Wild
Operation CameraSwarm
A single hacker compromise 1400+ Dahua camera worldwide
VECT’s locker destroys big files instead of encrypting them. This means victims who pay the ransom still can’t get their data back because the malware throws away the decryption keys while it’s encrypting.
“VECT is being marketed as ransomware, but for any file over 131KB – which is most of what enterprises actually care about – it functions as a data destruction tool,” said Eli Smadja, group manager at Check Point Research.
“CISOs need to understand that in a VECT incident, paying is not a recovery strategy. There is no decrypter that can be handed over, not because the attackers are unwilling, but because the information required to build one was destroyed the moment their software ran. The focus has to be on resilience: offline backups, tested recovery procedures, and rapid containment – not negotiation.”
The group has teamed up with the BreachForums cybercrime site and the TeamPCP hacking group. This partnership aims to make it easier for ransomware attackers and encourage them to launch attacks by using data that was stolen before.
“The convergence of large-scale supply chain credential theft, a maturing RaaS operation, and mass dark web forum mobilization represents an unprecedented model of industrialized ransomware deployment,” Dataminr noted earlier this month.
| Property | Windows | Linux | ESXi |
|---|---|---|---|
| Architecture | PE64 (x86-64) | ELF64 (x86-64) | ELF64 (x86-64) |
| Toolchain | MinGW-w64 / C++ | GCC / C++ | GCC / C++ |
| Crypto library | libsodium (static) | libsodium (static) | libsodium (static) |
| Cipher | ChaCha20-IETF (RFC 8439) | ChaCha20-IETF (RFC 8439) | ChaCha20-IETF (RFC 8439) |
| Key size | 32 bytes | 32 bytes | 32 bytes |
| Nonce size | 12 bytes | 12 bytes | 12 bytes |
| Small file threshold | 131,072 bytes | 131,072 bytes | 131,072 bytes |
| Large file chunks | 4 | 4 | 4 |
| Chunk offset formula | file_size / 4 × index | file_size / 4 × index | file_size / 4 × index |
| Max chunk size | 32,768 bytes | 32,768 bytes | 32,768 bytes |
| Nonces written to disk | 1 (last chunk only) | 1 (last chunk only) | 1 (last chunk only) |
| Encrypted extension | .vect | .vect | .vect |
| Ransom note filename | !!!READ_ME!!!.txt | !!!READ_ME!!!.txt | !!!READ_ME!!!.txt |
| Default target path | All drives | / | /vmfs/volumes |
| Lateral movement | WMI / DCOM / SMB / SC / Schtasks / PSRemoting | SSH / SCP | SSH / SCP |
| Geofencing / CIS bypass | No | Yes (locale + timezone) | Yes (locale + timezone) |
| Anti-debug | Process scan + kernel object query | TracerPid check | TracerPid check |
| Encryption mode flags | N/A | Parsed, not implemented | Parsed, not implemented |
Click here to read the full report.
