VECT 2.0 勒索软件会擦除 Windows、Linux 和 ESXi 上的大量文件

“新型”VECT 2.0勒索软件本质上是一个跨平台数据擦除器，它会永久销毁大多数企业文件，而不是对其进行加密以便恢复。

对于任何大于 131,072 字节（128 KB）的文件，VECT 使用四个不同的随机生成的 ChaCha20-IETF nonce 处理四个独立的块，但只在文件末尾将最后一个 nonce 写入磁盘。

前三个 nonce 被生成、使用，然后被丢弃，不会存储在本地或被泄露，这使得前三个加密块在数学上对任何人（包括攻击者自己）都是无法恢复的。

即使阈值仅为 128 KB，这种行为也会影响企业中几乎所有重要的文件类型，包括 VM 磁盘映像、数据库文件、文档、归档和备份。

Check Point Research (CPR)分析了 Windows、Linux 和 VMware ESXi 的 VECT 2.0 样本，发现这三个平台共享的核心加密例程存在根本性的设计缺陷。

对于这类占主导地位的“大型”文件，VECT 2.0 的作用类似于带有勒索信的破坏性擦除器，而不是可恢复的勒索软件，这意味着支付赎金的受害者无法获得大部分关键数据的有效解密器。

VECT 2.0 勒索软件清除

所有三个VECT 2.0 加密库都是基于相同的 libsodium 加密引擎构建的静态编译C++ 二进制文件，具有相同的文件大小阈值、四块布局和 nonce 处理逻辑。

此外，VECT 还宣布与 BreachForums 建立合作伙伴关系，承诺每个注册论坛用户都将成为其合作伙伴，从而能够使用 VECT 勒索软件。

CPR 还证实，在 2.0 版本发布之前在实际环境中发现的 VECT 版本也存在同样的四块循环、共享 nonce 缓冲区和单个 EOF nonce 写入问题，这表明该缺陷自该操作首次部署以来就一直存在，并且从未得到修复。

公开报道甚至 VECT 自己的广告都错误地将储物柜描述为使用 ChaCha20‑Poly1305 AEAD 加密。

CPR 显示该恶意软件实际上通过 libsodium 的 crypto_stream_chacha20_ietf_xor 使用原始 ChaCha20-IETF，密钥为 32 字节，随机数为 12 字节，并且没有向密文附加任何 Poly1305 认证标签。

这意味着没有消息认证码，也没有任何完整性保护；磁盘上的布局只是密文加上一个随机数，而不是经过认证的加密方案。

VECT 还在 Linux 和 ESXi 版本中公开了“加密速度”标志，例如 –fast、–medium 和 –secure，表明了不同的性能调优覆盖级别。

实际上，这些选项会被解析和存储，但从未被使用：无论选择什么运算符，每次运行都会应用相同的 128 KB 阈值和 32 KB 块大小，这加剧了项目专业营销与其实际实现之间的差距。

RaaS 运营存在工程技术薄弱的问题

在运营方面，VECT 将自己定位为勒索软件即服务 (RaaS) 程序，于 2025 年末首次在俄语论坛上进行宣传，到 2026 年初至少与两名受害者有关。

加密引擎以固定的 1:7 扫描器与加密器比例生成工作线程，该比例由 CPU 数量分级乘数得出：对于最多 4 个 CPU 的机器，乘以 8；对于 5-8 个 CPU 的机器，乘以 6；对于 5-8 个 CPU 的机器，乘以 4；对于更多 CPU 的机器，乘以 4，总数上限为 256。

尽管采用了这种激进的扩张模式，但目前公开的泄露基础设施仅列出了少数受害者，而且核心加密库仍然存在明显的技术缺陷，从无法访问的反分析代码和自取消字符串“混淆”到降低加密性能的过度线程调度器。

该组织后来宣布与供应链参与者 TeamPCP和 BreachForums建立合作关系，承诺所有注册论坛成员都可以使用 VECT 的面板、储物柜、谈判平台和泄露网站作为联盟成员。