GachiLoader：利用API追踪击败Node.js恶意软件

研究团队： Sven Rath (@eversinc33), Jaromír Hořejší (@JaromirHorejsi)

关键要点

• YouTube幽灵网络 是一个恶意软件分发网络，利用被入侵的账户推广恶意视频并传播窃密软件等恶意软件。
• 观察到的一个攻击活动中使用了一种新的、经过高度混淆的Node.js编写的加载器恶意软件，我们称之为 GachiLoader。
• 为了更容易分析混淆的Node.js恶意软件，Check Point Research开发了一个开源的Node.js追踪器，它显著减少了分析此类恶意软件和提取配置所需的工作量。
• GachiLoader 的一个变种部署了第二阶段的恶意软件 Kidkadi，它实现了一种用于可移植可执行文件（PE）注入的新技术。该技术加载一个合法的DLL，并滥用Vectored Exception Handling来动态地将其替换为恶意负载。

引言

在之前的一份报告中，我们研究了YouTube幽灵网络，这是一个利用被入侵账户滥用平台推广恶意软件的协调集合。在当前的研究中，我们分析了该网络的一个特定攻击活动，其突出之处在于部署的恶意软件使用了一种先前未文档化的PE注入方法，该方法滥用Vectored Exception Handling来加载其恶意负载。

攻击活动概述

与我们之前记录的类似，感染链始于被入侵的账户，这些账户托管旨在诱使观众从外部文件托管平台下载恶意软件的视频。此活动的主题是游戏作弊器和各种破解软件：

图 1 — 被入侵账户示例开始分享恶意游戏作弊广告

视频描述随后提供包含恶意软件的存档文件的密码，以及通常包括禁用Windows Defender的说明。

我们识别出属于此活动的超过一百个视频，它们累计获得了大约 220,000次观看。这些视频分布在 39个被入侵账户上，第一个视频于2024年12月22日上传。这意味着此活动已持续运行超过9个月。在我们向YouTube报告这些视频后，大部分已被下线，尽管新视频将继续出现在新被入侵的账户上。

自我们开始监控此特定活动以来，它部署了 Rhadamanthys 窃密软件作为最终负载，该软件通过一个我们称之为 GachiLoader 的自定义加载器分发。

GachiLoader

GachiLoader 是一个高度混淆的Node.js JavaScript恶意软件，用于向受感染的机器部署额外的负载。Node.js是威胁行为者为传播恶意软件不断适应使用非传统编程语言和平台的长线工具之一。

由于混淆的JavaScript需要大量时间和精力进行手动去混淆，我们开发了一个 Node.js脚本追踪器 来动态分析此类恶意软件，击败常见的反分析技巧，并显著减少手动分析工作量。这个工具不仅对 GachiLoader 有用，而且对任何分析高度混淆的Node.js恶意软件的人都有用。因此，我们决定在此与研究人员社区分享：

https://github.com/CheckPointSW/Nodejs-Tracer

一些分析过的 GachiLoader 样本会丢弃一个第二阶段的加载器，我们称之为 Kidkadi。这个加载器特别有趣，因为它实现了一种 新颖的PE注入技术，该技术欺骗Windows加载器从内存加载恶意PE，而不是合法的DLL。我们分析了这种我们称之为 Vectored Overloading 的技术，并在下面分享的概念验证（PoC）中重新实现了它。

技术分析

GachiLoader的JavaScript模块使用 nexe 打包器捆绑成一个独立可执行文件，大小大约在60到90 MB之间。 nexe 是一个开源项目，它将Node.js应用程序编译成单个可执行文件，并捆绑Node.js运行时，以便该文件可以在没有安装Node.js的主机上运行。虽然可执行文件的大小相当大，但受害者期望接收一个软件包，因此并不显得可疑。工具 nexe_unpacker 可用于从PE中提取混淆的JavaScript源代码。

图 2 — 混淆（但格式化了）的JavaScript源代码

反分析功能

为了避免被安全研究人员或自动化沙箱分析，GachiLoader JavaScript模块采用了多种反虚拟机（anti-VM）和反分析检查：

• 检查总RAM是否至少为4GB。
• 检查是否至少可用2个CPU核心。
• 将用户名与一个列表进行比较，该列表包含可能与各种沙箱或分析系统相关的用户名（完整列表见附录A）。
• 将主机名与类似的主机名列表进行比较（完整列表见附录B）。
• 探测正在运行的程序并与一个列表进行比较，该列表包含分析工具、沙箱指示器或虚拟机上运行的常见程序（完整列表见附录C）。

然后，恶意软件继续运行多个PowerShell命令，通过 WMI 枚举系统资源和功能：

• 检查是否存在至少一个端口连接器对象：(Get-WmiObject Win32_PortConnector).Count
• 获取驱动器制造商并与黑名单比较：Get-WmiObject Win32_DiskDrive | Select-Object -ExpandProperty Model（所有驱动器制造商列表见附录D）。
• 通过 Get-WmiObject Win32_VideoController | Select-Object -ExpandProperty Name 解析视频控制器，并根据与VM环境相关的黑名单检查名称（所有视频控制器名称列表见附录E）。

如果任何这些检查表明存在虚拟机、沙箱或分析环境，恶意软件将进入一个循环，向良性网站（如 linkedin.com、grok.com、whatsapp.com 或 twitter.com）发送 HTTP GET 请求：

图 3 — 当检测到实验室环境时无限循环发送GET请求

最后，为了避免在短时间内多次运行，程序在首次运行时会在 %TEMP% 目录中创建一个随机生成的、带 .lock 扩展名的互斥文件。如果该文件已存在或在过去5分钟内被修改过，程序将终止。

我们能够使用Node.js Tracer轻松绕过所有这些反分析检查：该工具钩住相应的方法，并将结果欺骗给调用者（即恶意软件），允许脚本运行并暴露其恶意行为：

图 4 — 使用Node.js Tracer绕过反分析检查

通过UAC提示进行权限提升

如果恶意软件判断环境不是沙箱，它会通过运行 net session 命令检查是否在提升的上下文中运行，如果由非管理员用户运行，该命令预计会失败。如果命令失败，恶意软件会尝试使用以下PowerShell命令以提升的上下文重新启动自身：

1

powershell -WindowStyle Hidden -Command "Start-Process cmd.exe -Verb RunAs -WindowStyle Hidden -ArgumentList '/c \"<path_to_program_itself>\"'"

虽然这会触发UAC提示，但受害者很可能接受该提示，因为他们期望运行某种软件的安装程序，这通常需要管理员权限。

防御规避

为了避免检测后续负载，恶意软件尝试通过运行 taskkill /F /IM SecHealthUI.exe 来终止Windows Defender的 SecHealthUI.exe 进程，并通过 Add-MpPreference -ExclusionPath 为以下路径添加Defender排除项：

• C:\Users\
• C:\ProgramData\
• C:\Windows\
• 对于所有其他现有驱动器，在根目录下（例如 D:\）。

此外，通过 Add-MpPreference -ExclusionExtension '.sys' 为 *.sys 文件添加排除项，尽管我们未观察到分析过的样本丢弃任何 *.sys 文件。

负载投递与执行

为了获取下一阶段的负载，恶意软件有两个变种：

• 一个变种从远程URL获取负载。
• 另一个变种丢弃另一个加载器 kidkadi.node，该加载器使用Vectored Overloading方法加载最终负载。该负载嵌入在加载器的JavaScript源代码中。

第一个变种 - 远程负载

图 5 — 第一个GachiLoader变种加载远程负载

GachiLoader 首先获取其运行主机的信息，例如防病毒产品和操作系统版本，并通过 POST 请求发送到其C2（命令与控制）地址的 /log 端点。所有样本都嵌入了多个C2地址以实现冗余，并依次尝试每个地址，正如我们通过追踪器追踪调用时看到的那样：

图 6 — 通过Node.js Tracer追踪到的C2通信

接下来，向 /richfamily/<key> 端点（其中 <key> 是每个样本的唯一值）发送带有 X-Secret: gachifamily 请求头的 GET 请求，获取要下载的最终负载的URL，该URL以Base64编码。只有再次使用正确的 X-Secret 请求头（这次使用嵌入在二进制文件中的唯一密钥，例如 X-Secret: 5FZQY1gYj0UKw4ZC99d1oNYR8LvTPtrfN357Eh5gmRvsMaPYgXtMxRXpMb2bTFOb2h2HqMnvUKT9CUpj9864gckmPUzf9uLIIU9）时才能获取最终负载。否则，Web服务器将返回 Forbidden 错误。

然后将最终负载下载到 %TEMP% 目录，并使用随机名称保存，模仿合法软件，例如 KeePass.exe、GoogleDrive.exe、UnrealEngine.exe 等，其中包含使用VMProtect或Themida打包和保护的Rhadamanthys窃密软件。

第二个变种 - Kidkadi

我们在野外观察到的第二个变种并未联系C2服务器获取第二负载，而是嵌入了负载，该负载通过另一个加载器执行，该加载器被丢弃到磁盘的 %TEMP% 下，命名为 kidkadi.node：

图 7 — GachiLoader的第二个变种丢弃Kidkadi

.node 文件是Node.js的原生插件，本质上是可以通过 dlopen 从Node.js代码调用的DLL。因此，当Node-API没有暴露足够的功能时，开发人员可以使用它们。

恶意软件向Node.js公开了一个要调用的函数，该函数的名称在不同样本中有所不同。在某些情况下，名称以及某些样本中的错误消息具有俄语起源：

图 8 — 向JavaScript代码公开一个函数

加载器通过这个暴露的函数将负载PE作为二进制缓冲区传递给 Kidkadi，然后通过反射式PE加载运行该负载。我们发现该加载器采用了一种新颖的 模块重载 手法，滥用Vectored Exception Handlers（VEHs）来欺骗Windows操作系统在调用 LoadLibrary 加载任意DLL时运行最终负载。这种技术尚未有文档记录，表明作者对Windows内部有相当的理解。我们将这种方法命名为 Vectored Overloading。

通过Vectored Overloading进行PE加载

恶意软件首先从合法的 wmp.dll（Windows Media Player使用的DLL）创建一个带有 SEC_IMAGE 属性的新节。然后，它用负载（要加载的PE）的内容覆盖这个节，并通过 NtMapViewOfSection 将该节的视图映射到进程中。然后，PE的各个节被逐个复制到内存中，并应用重定位以及正确的保护：

图 9 — PE映射器

这导致恶意的PE视图被映射到进程中，该视图由合法的DLL wmp.dll 支持。这个节视图正是Windows加载器（即 ntdll!Ldr*）稍后将被欺骗加载的对象。

由于通过 LoadLibrary 调用的Windows加载器并不加载任意的PE，只加载那些具有DLL特性的文件，因此如果负载不是DLL，则会将 FileHeader 的 Characteristics 设置为 IMAGE_FILE_DLL。此外，入口点被清零，可能是为了避免加载器调用非DLL的入口点。如果负载是DLL，则头不会被更改。

图 10 — 检查并更新FileHeader的Characteristics

之后，恶意软件注册一个Vectored Exception Handler（VEH）。 VEH是用户模式回调，当发生异常时由操作系统调用。滥用VEH的一种常见恶意软件技术是在特定指令上注册硬件断点（HWBP），当到达该指令时会触发异常。该异常随后由VEH处理，它可以拦截调用并，例如，更改参数。这实质上允许在不修补内存的情况下挂钩函数，就像使用经典的蹦床挂钩时那样。

在这种情况下，硬件断点设置在 NtOpenSection 上：

图 11 — 在NtOpenSection上设置硬件断点

然后恶意软件通过 LoadLibrary 加载 amsi.dll，从而启动注入：

图 12 — 加载目标库并移除异常处理程序

对 LoadLibrary 的调用内部最终会由Windows加载器创建要加载的目标DLL的节对象，该对象通过调用 NtOpenSection 打开。这会触发硬件断点，随后触发先前注册的VEH。这是主要注入逻辑实现的地方。

为了使加载器映射恶意的PE而不是实际的 amsi.dll 节，指向 amsi.dll 的节对象被交换为之前创建的恶意负载节。VEH只是将之前创建的节句柄放置在栈上对应于 NtOpenSection 的 [out] PHANDLE SectionHandle 参数的位置。然后，VEH将指令指针 eip 前进到 ret 指令并恢复执行。这跳过了对内核的实际调用，同时仍然返回一个有效的句柄，实质上模拟了 NtOpenSection：

图 13 — 跳过对NtOpenSection的调用，用指向恶意负载的SectionHandle替换期望的输出参数

在退出VEH之前，硬件断点被重新设置为 NtMapViewOfSection。

图 14 — 在NtMapViewOfSection上设置硬件断点

NtMapViewOfSection 随后被Windows加载器用来将节映射到进程中，这再次触发硬件断点。为了确保恶意负载被映射，系统调用再次通过推进指令指针并用相关值（如节基址或节大小）替换 [out] 参数来模拟。这是可能的，因为当恶意负载被写入 wmp.dll 的视图时，节视图已被恶意软件早期映射：

图 15 — 跳过对NtMapViewOfSection的调用，用指向恶意负载的指针替换期望的输出参数

然后设置最后一个硬件断点到 NtClose，恶意软件在此处简单地验证正确的节句柄被关闭。

图 16 — 在NtClose上设置硬件断点

回到程序的正常流程中，在VEH之外，如果负载是常规PE，入口点将被调用。如果它是DLL，加载器期望它是另一个 .node 模块，并解析正确的导出进行调用：

图 17 — EXE和DLL调用

与此活动完全无关，我们发现一个原始文件名为 HookPE.exe 的文件，它是该技术的64位PoC版本，带有调试打印信息，使用该技术将 calc.exe 加载到内存中。此二进制文件中的错误字符串表明加载器使用来自 libpeconv 的代码进行PE操作。

图 18 — HookPE PoC项目，使用相同的技术

与“经典”的RunPE风格反射式加载相比，这种注入技术具有多重优势：

• 就像使用模块重载技术时一样，注入的DLL将显示为由合法映像（如 wmp.dll）支持，因为该节最初是为该DLL创建的。但是，由于内存中的代码将与磁盘上的代码不同，因此像 Moneta 这样的工具能够检测到它。 图 19 — 虽然Moneta检测到不匹配的模块，但大多数分析工具显示原始DLL名称
• 一些加载器工作被卸载到Windows加载器。这显著降低了恶意软件作者的复杂性，因为他们不必实现例如解析导入或TLS回调，这反过来提高了负载兼容性。例如，许多公开可用的PE加载器不能正确处理TLS回调。
• 通过模拟系统调用，相应的内核端回调（如ETWti）不会被调用，因为对内核的调用被完全跳过。这可能会欺骗仅依赖这些节的ETWti事件的安全解决方案。当然，注入之前的早期调用（当映射映像时）仍然会触发这些事件，但不是通常预期的顺序。

我们发布了一个重新实现的64位变种注入方法作为工具，供安全研究人员分析该技术和测试检测规则：

https://github.com/CheckPointSW/VectoredOverloading

大规模动态配置提取

由于JavaScript源代码的去混淆是一项繁琐且部分手动的工作，我们决定通过Node.js Tracer运行所有可用的 GachiLoader 样本，以绕过反分析检查并接收最终负载。通过钩住文件系统相关的Node API，下载的文件在恶意软件试图删除其痕迹之前被保存下来供分析人员使用。

图 20 — 追踪器显示GachiLoader将Kidkadi丢弃到磁盘

GachiLoader 两个变种的最终负载都使用Themida或VMProtect进行打包和保护。在自动沙箱中运行它们时，从内存中转储未受保护的配置，然后允许我们提取最终负载的C2服务器。

图 21 — 最终负载的Detect-it-Easy输出

作为此活动一部分的所有分析样本都丢弃了Rhadamanthys作为最终恶意软件。提取的C2服务器可以在下面的IoC部分找到。

结论

为Node.js平台编写的恶意软件已变得越来越普遍，并且大多以混淆形式出现，静态去混淆和分析起来很繁琐。通过使分析人员能够使用我们的开源Node.js Tracer动态追踪和钩住Node-API执行，在分类和分析上必须花费的时间显著减少，并且可以轻松击败常见的反分析检查。

GachiLoader 背后的威胁行为者展示了精通Windows内部结构的能力，创造了一种已知技术的新变体。这突显了安全研究人员需要及时了解PE注入等恶意软件技术，并积极寻找恶意软件作者试图逃避检测的新方法。

YouTube幽灵网络背后的威胁行为者利用对YouTube平台的信任来诱骗受害者下载恶意软件。用户应特别警惕提供破解软件、破解补丁、修改器或作弊器的提议，因为这些文件经常被植入旨在窃取数据和/或危害设备的恶意软件。虽然安全社区和YouTube都积极努力识别并删除此类内容，但这些攻击仍然持续存在。

保护措施

Check Point Threat Emulation 和 Harmony Endpoint 提供全面的攻击战术、文件类型和操作系统覆盖，并保护免受本报告中描述的攻击和威胁。

威胁指标（IoC）