VECT：设计成勒索软件，意外成了擦除器

2026-05-04 04:44:38 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： CheckPointResearch发现VECT2.0勒索软件存在致命缺陷，加密超过128KB文件时仅保存最后一个随机数，导致连攻击者也无法解密数据，实质沦为数据擦除器。该缺陷跨Windows、Linux和ESXi三平台一致存在。此外，该软件误用未认证的ChaCha20算法，多线程调度极其低效且反分析代码未启用，技术实现极不成熟。 综合评分： 91 文章分类： 恶意软件,漏洞分析,逆向分析,威胁情报

▲ 图13：VECT 2.0 Windows锁定器使用的桌面壁纸

目标选择和排除

驱动器枚举包括逻辑驱动器和网络映射资源。文件选择逻辑跳过以下内容，以使操作系统保持足够功能，让受害者能够访问支付门户：

排除的目录：Windows、Windows.old、Boot、$Recycle.Bin、System Volume Information、Program Files、Program Files (x86)、ProgramData
排除的启动文件：bootmgr、bootmgr.efi、bootmgfw.efi、bootsect.bak、boot.ini、ntldr
排除的扩展名：.exe、.dll、.sys

这些是构建器默认值；联盟会员可以在样本生成时配置额外的排除项。

进程和服务中断

当以提升权限运行时，锁定器通过Windows服务控制管理器停止服务，并在加密开始前终止以下进程以释放文件句柄：sql.exe、oracle.exe、mysqld.exe、excel.exe、winword.exe、outlook.exe、firefox.exe、thunderbird.exe。

与典型的RaaS产品中联盟会员可以自定义终止列表不同，这个列表是构建器硬编码的，在样本生成时无法修改。

持久化和安全模式准备

当启用了–force-safemode时，锁定器执行bcdedit /set {default} safeboot minimal来配置下一次启动进入最小安全模式，然后将其自身的可执行路径写入Windows注册表中的安全启动服务加载路径，值为”Service”。这确保了锁定器在随后的安全模式启动时运行，此时大多数安全产品被禁用。执行完成后，启动配置条目被删除以避免持久启动循环。在执行期间，任务管理器也通过注册表被禁用。

横向移动

锁定器包含多个编码的远程执行脚本模板，允许使用操作员提供的凭据（–creds）传播到其他Windows主机。方法包括：管理共享文件复制、通过cmdkey的Windows凭据管理器存储、WMI执行、DCOM/MMC应用程序实例化、远程计划任务创建、通过sc.exe的远程服务安装以及PowerShell远程处理。主机发现结合了Windows域枚举和使用网络适配器信息的本地子网扫描。

反分析

Windows版本实现了三层分析环境检测机制。所有三种检测机制都以编译形式存在，但从未被调用。交叉引用分析确认，在此构建中没有任何调用点能够到达这三个功能中的任何一个。这与一个在构建时被禁用的条件编译标志一致，代表了一个有意义的漏洞：在此样本下使用任何目标工具的分析员不会触发任何规避响应。

没有应用代码混淆，尽管最面向操作员的字符串使用一个旋转的64位XOR方案隐藏：每个字节与固定64位密钥的对应字节进行XOR，循环遍历所有八个密钥字节。

▲ 图14：基于XOR的字符串解密示例（Windows锁定器）

运行进程扫描：获取完整进程快照，并将每个进程名称与硬编码的44个分析工具列表（最初是47个，但我们去掉了重复项）进行比较，涵盖调试器、导入重构器、PE实用工具、进程监视器、网络嗅探器和沙盒控制器（检测到的工具完整列表见附录部分）。

▲ 图15：检测44个分析工具

父进程检查：检索父进程映像路径，并与调试环境列表匹配：devenv、windbg、x64dbg、x32dbg、ollydbg、ida。从这些进程启动的进程被视为在分析下运行。
内核调试对象查询：Windows原生API NtQueryInformationProcess在运行时从ntdll.dll动态解析（避免静态导入检测），并查询ProcessDebugObjectHandle信息类。非空返回值表示附加了调试器。

防御规避和清理

ESXi锁定器——虚拟机管理程序勒索软件

VECT勒索软件的ESXi版本针对VMware ESXi虚拟机管理程序，在中断各种系统服务、擦除日志和加密受害者文件之前使用地理围栏和反调试，默认定位到/vmfs/volumes下的VMware文件系统挂载点。恶意软件还支持基于SSH的横向移动，尝试使用可用凭据连接到已知的SSH主机。

反分析和地理围栏

在执行任何恶意代码之前，勒索软件使用两个简单的反分析检查：首先，检查是否在CIS国家运行，如果是则退出而不加密。恶意软件运行timedatectl并将时区与黑名单比较，检查LANG和LC_ALL环境变量，验证国家代码是否不与排除的国家匹配。

▲ 图16：国家代码黑名单

2022年之前，CIS检查在RaaS恶意软件中非常常见。在俄乌战争开始时，大多数RaaS程序从CIS国家列表中移除了乌克兰。近年来这些检查已大多从勒索软件中移除。VECT包含这样的检查，甚至将乌克兰添加到排除列表中，这相当不寻常。Check Point Research对这个观察有两个理论：要么这段代码是AI生成的，LLM训练时乌克兰被包含在CIS中；要么VECT使用了旧的勒索软件代码库。

此外，恶意软件通过检查/proc/self/status中的TracerPid值来探测调试器的存在，如果发现任何跟踪进程则退出。

为了混淆基本静态分析，作者决定将字符串实现为栈字符串。一些字符串，最明显的是不同的命令行选项，还额外用单字节密钥进行XOR：

▲ 图17：XOR加密的命令行开关（ESXi版本）

命令行界面和SSH横向移动

可用的命令行选项：

–path 目标目录（默认：/vmfs/volumes） –spread 启用SSH横向移动 –fast 快速模式：仅加密1MB –medium 中等模式：加密4个部分（每个64MB） –secure 安全模式：加密100%（默认） –no-kill-vms 不杀死运行的虚拟机（仅加密） –verbose 启用详细输出 –help 显示帮助信息

操作员似乎可以在三种加密方法之间选择——–fast、–medium和–secure——以在加密速度和彻底性之间找到权衡。然而，勒索软件实际上并没有实现这些不同的模式——代码解析了它们，但从未读取回去。每次执行，无论操作员选择了什么标志，都应用相同的硬编码阈值：131,072字节的大文件边界和32,768字节的最大块大小。Linux版本也是如此，我们稍后描述。

如果提供了–spread选项，恶意软件会尝试像基于SSH的蠕虫一样横向传播：

从home和/root目录中提取所有可读密钥
读取并解析/etc/ssh/ssh_config和~/.ssh/config，查找主机名和对应用户名
清零所有known_hosts文件以避免主机密钥警告
对于每个主机，锁定器尝试使用收集到的每个用户名以及一个硬编码的常用用户名列表进行连接
如果连接成功，恶意软件通过scp复制自身，并通过ssh执行自身

服务中断、日志擦除和加密

在运行任何加密之前，恶意软件确保关闭任何可能持有文件锁或以其他方式干扰该进程的服务。它首先通过esxcli工具禁用ESXi防火墙，以及特定的防火墙规则集，并关闭各种ESXi健康监控进程：

▲ 图18：用于禁用防火墙和规则集的esxcli命令

之后，它继续关闭其他服务和进程，如数据库、备份工具、虚拟机管理程序相关服务和安全产品。关闭尝试通过systemctl stop和service stop优雅地完成，或通过pkill -9和systemctl disable –now激进地进行。目标服务的完整列表见附录。

为了移除虚拟机磁盘文件上的任何锁，VECT锁定器调用各种合法的管理工具来关闭任何正在运行的虚拟机。然而，与其名称相反，锁定器不仅针对ESXi，还针对其他常见的虚拟机管理程序：

接下来，/var/log中的各种shell历史文件和日志被删除或清零。这包括来自虚拟机管理程序、容器服务、数据库、web服务器、审计日志或其他系统日志和日志的日志（完整列表见附录）。

在这段前奏之后，实际的加密过程开始：如果没有提供路径，则使用默认路径/vmfs/volumes，这是所有数据存储的默认VMware文件系统（VMFS）挂载点。在多线程进程中，每个数据存储被搜索以查找文件进行加密。勒索软件维护一个明智的黑名单，排除了几个主要包含可执行文件、系统文件或配置文件的目录：

/proc, /sys, /dev, /bin, /sbin, /lib64, /usr, /etc, /boot, /var/run, /var/lib, /bootbank, /altbootbank, /store, /locker, /vmfs/volumes/.sdd.sf, /vmfs/volumes/.fbb.sf, /vmfs/volumes/.fdc.sf, /vmfs/volumes/.pb, /vmfs/volumes/.vh

再次，线程数选择得相当过度，将CPU核心数乘以4，限制在32到256之间。

由于与其他版本共享代码库，加密过程是相同的，并且包含相同的实现缺陷：在处理大文件时只包含最新的随机随机数：

▲ 图19：加密缺陷（ESXi版本）

最后，如果恶意软件配置为这样做，赎金说明会被丢弃到/home、/root和/tmp，以及各种系统路径：

Linux锁定器

Linux版本基于与ESXi相同的代码库，并实现了其功能的一个子集。比较主函数的执行流程时这一点很明显：

▲ 图20：ESXi锁定器（左）与Linux锁定器（右）的执行流程

与ESXi版本一样，恶意软件首先杀死任何可能干扰加密的服务和进程，关闭任何虚拟机（有趣的是也包括ESXi虚拟机），并擦除系统日志和shell历史文件。然后，加密开始，默认路径为系统根目录/，赎金说明写入磁盘。Linux锁定器与其ESXi对应版本一样，支持–spread SSH横向移动功能。由于共享代码库，锁定器在加密大文件时也未能保存前三个随机随机数，使得大文件无法完全恢复。

Linux版本在加密实现中还有一个疏忽。就像ESXi锁定器中一样，命令行标志本应被加密，但作者意外设计了一个双重XOR加密方案，这抵消了加密并导致二进制文件中出现明文字符串：

▲ 图21：双重XOR“加密”

顺便提一下，甚至连ASCII艺术都是错的，因为开发人员忘了转义反斜杠字符：

▲ 图22：损坏的ASCII艺术

结论

VECT 2.0展现出雄心勃勃的威胁形象：多平台覆盖、活跃的联盟计划、通过TeamPCP合作的供应链分发，以及一个光鲜的操作员面板。但实践中，技术实现远未达到其宣传的水平。

Check Point Research的分析揭示，勒索软件的加密缺陷不是一个微小的边界情况，而是一个根本的设计错误，影响了几乎所有有意义的文件。阈值只有128KB，小于典型的电子邮件附件或办公文档，被代码归类为大文件不仅包括VM磁盘、数据库和备份，还包括常规文档、电子表格和邮箱。实际上，受害者想恢复的东西几乎没有什么低于这个边界。

随机随机数处理bug在所有三个平台版本中完全相同，并且通过对VECT 2.0发布前已在野发现的较早变体的分析确认，自操作员首次公开观察到的部署以来就一直存在。它从未被修复。支付赎金的受害者无法得到针对其最大文件的可用解密器——不是因为操作员欺骗，而是因为解密所需的信息在加密的那一刻就已经不可逆地销毁了。一个过度激进的线程调度器主动伤害加密吞吐量

参考资料

[1] https://www.virustotal.com/gui/file/a7eadcf81dd6fda0dd6affefaffcb33b1d8f64ddec6e5a1772d028ef2a7da0f2

[2] https://research.checkpoint.com/2026/vect-ransomware-by-design-wiper-by-accident/

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲《VECT：设计成勒索软件，意外成了擦除器》