一个此前未被记录的 Windows 加载程序（名为 OXLOADER）正在通过恶意 Google 广告传播 CASTLESTEALER 信息窃取程序，在静态引擎和沙箱测试中的检测率都很低。加载器使用多个混淆层（控制流扁平化、不透明谓词、混合布尔算术）、自修改解密存根，并滥用 Windows .reloc部分来放置 shellcode。

Elastic Security Labs 在针对我们一位客户的活跃攻击活动中发现了 OXLOADER；针对独联体地区和俄语的排除表明这是一个以经济利益为目的的、讲俄语的威胁行为者。我们此前没有找到任何关于这个家庭的公开报道。

关键要点

• Elastic Security Labs 发现新的加载器 (OXLOADER)
• 在通过恶意谷歌广告分发 CASTLESTEALER 的活动中发现了 OXLOADER
• 排除独联体地区以及俄语检查表明，这是一个讲俄语、以经济利益为目的的威胁行为者。
• 静态发动机和沙箱爆震的检测率低
• Elastic Defend 利用先进的防御功能阻止整个攻击链。

恶意广告如何将 OXLOADER 送达受害者手中

OXLOADER 通过冒充 Node.js 的恶意 Google 广告进行传播。受害者通过中间域重定向到 Storj 托管的批处理脚本，该脚本下载并执行 OXLOADER。

感染始于用户搜索lts version of node.js并点击赞助结果，该结果导致用户访问node-js[.]prentiva99[.]info ，这是一个恶意着陆页，旨在冒充合法的 Node.js 部署平台。该威胁行为者发起了一项针对美国受害者的 Google Ads 广告活动；该广告最后一次展示是在 4 月23 、 2026 ，该网站现已下线。广告商注册名称为ВОЛОДИМИР ТЕРЕЩЕНКО ，注册地为乌克兰。这究竟反映的是实际操作者、幌子公司还是购买的身份，目前尚不清楚。5月14 、 2026 ，该广告商及其相关的广告活动被谷歌完全移除。

交互后，用户被重定向到app[.]miloyannopoulos[.]com/download?subid1=download ， 响应302 Found到有效负载 URL link[.]storjshare[.]io/raw/jux4e4ky5mruo4jkxsssp42sau4q/ruslan/BATPackageBuilderSetup.bat 。这会将一个 Windows 批处理脚本发送到Storj 的合法链接共享服务上，攻击者利用该脚本来规避基于域的信誉过滤。

该批处理脚本显示一个虚假的软件安装向导 UI，立即通过 PowerShell 从 Storj URL link.storjshare[.]io/raw/jwwvr4oskkkjsgevt774ta62ehya/ruslan/aBsvwbdas.exe下载下一阶段可执行文件，并使用-Verb RunAs启动它以触发 UAC 提升提示。

在执行批处理脚本后，Elastic Defend 检测到恶意行为（策略设置为仅检测），触发了多个行为规则，包括Microsoft Common Language Runtime Loaded from Suspicious Memory ，暗示存在与CASTLESTEALER一致的基于 .NET 的有效负载。

以下是攻击链从有效载荷下载到CASTLESTEALER部署的执行图。

OXLOADER恶意软件加载器：技术分析

我们团队分析的第一个 OXLOADER 样本伪装成 rohitab.com 的热门工具 API Monitor 。由于大量合法代码和代码隐藏技术的存在，该加载器能够躲过静态文件分析器的检测。

OXLOADER 如何在运行时解包自身

恶意软件在 CRT 初始化阶段开始执行，在任何用户代码运行之前。CRT 函数cinit()调用initterm() ， 遍历 C++ 初始化表 ( __xc_a → __xc_z ) 并调用每个条目。恶意软件开发者劫持了其中一个条目，指向一个在尾跳进入第一个解密存根之前发出RegisterClipboardFormatW()调用的函数。

加载器使用自修改技术和多个解密存根来展开自身。下面是一个在运行时跳转到解密存根之前，先进行修补的示例。

修补完成后，加载器会解密一个 28,233 字节的区域。每个字节都使用单字节 XOR 密钥进行解密，该密钥在每次迭代后都会更新：刚刚解密的明文字节被添加到密钥中，然后使用该密钥解密下一个字节。类似的解密程序总共运行三次，每次针对不同的区域。

用于规避静态检测的混淆技术

OXLOADER 使用四种分层混淆技术（控制流扁平化 (CFF)、混合布尔算术 (MBA)、不透明谓词和跨非连续代码区域的函数分块）来破解 IDA Pro 等二进制分析工具中的自动函数边界检测。函数之间通过无条件跳转连接起来，有些区域通过间接跳转到达，其目标地址在运行时通过 MBA 算术计算得出。结果是 IDA Pro 无法可靠地重建功能边界，需要手动修正。

加载器在运行时使用以下字符串解密算法解密各种字符串：

uint32_t obf_xor_a1_with_a2_plus_33FDA(uint32_t a1, uint32_t a2) { 
return a1 ^ (a2 + 0x33FDA); 
}

代码完全解包/解密后，恶意软件将此字符串解密函数与 Adler-32 API 哈希算法结合起来，以动态解析其导入。

OXLOADER是如何绕过沙箱和虚拟机检测的？

在解析其 API 之后，OXLOADER 会执行各种检查，以确保机器在干净的环境中执行，避免在沙箱环境中执行。

第一个检查尝试使用mpr!WNetAddConnection2W连接到故意格式错误的网络资源 ( *72s@1s )。这种技术似乎可以绕过那些可能会无条件地钩住或返回成功连接的模拟/沙箱。恶意软件开发者通过直接访问 TEB 来验证此调用，以检索LastErrorValue 。加载器期望此错误代码为ERROR_BAD_NAME (0x43) ，如果错误代码不是此值，恶意软件将执行失败分支并停止执行。

第二个检查是基于处理器数量的反沙箱测试：加载程序要求主机至少有 3 CPU 才能继续。为了节省资源，许多沙箱和分析虚拟机只配备了一到两个 CPU，因此该阈值会将这些自动化分析环境排除在外。

下一个检查使用GlobalMemoryStatusEx()来验证主机是否至少有 3 GB 的可用物理内存。

进一步检查使用 WMI 查询系统显示器的刷新率，执行 WQL 语句SELECT CurrentRefreshRate FROM Win32_VideoController ，并将返回值（以赫兹为单位）与阈值 20 进行比较。物理监视器通常报告 60 Hz 或更高，而无头和默认虚拟化配置通常报告 0 或 1，低于 20 值会导致加载程序中止。

地理和语言方面的限制

最后两项检查会在主机位于独联体国家或配置为俄语时停止执行。此类别中的第一个检查使用GetUserGeoID检索系统的地理区域，并将其与硬编码的独联体国家 GEOID 列表进行比较。

第二个检查使用GetUserDefaultUILanguage ，并与 LANGID ( 0x419 - Russian, Russia ) 进行匹配，这是俄语 Windows 安装的标准配置。

通过 .reloc 进行 Shellcode 暂存部分和 OCX 文件

所有检查通过后，恶意软件会复制 Windows DirectUI 引擎 DLL ( C:\Windows\System32\dui70.dll )，并将其存储在临时位置，使用带有.ocx扩展名的随机生成名称 ( PFHemkxVk.ocx )。这个扩展名的选择启发了OXLOADER家族名称的由来。

OXLOADER 然后在此目标 DLL ( PFHemkxVk.ocx ) 中创建一个名为 ( .xtext ) 的新节。

这个新部分（ .xtext ）配置了 RWX（读/写/执行）保护，准备存储和执行恶意代码的下一阶段。

然后，通过LoadLibraryA将更新后的 DLL ( PFHemkxVk.ocx ) 加载到现有的加载进程中。

在普通的 Windows 可执行文件中， .reloc部分包含一个IMAGE_BASE_RELOCATION块表，当映像加载到其首选基址以外的地址时，Windows 加载程序会应用该表来修补绝对地址。在这个示例中，恶意软件开发者使用的是
.reloc部分用于存放恶意代码，而不是基本重定位条目。这是一个严重的静态分析危险信号：合法的工具链不会向.reloc部分输出代码。

然后，将.reloc部分中的 shellcode 复制到 OCX 文件中新创建的部分 ( .xtext )，加载器随后调用此代码。

如前所述，还有另一个解密存根用于解包下一阶段。

通过 DonutLoader 和 .NET 程序集进行内存信息窃取程序的传输

下一阶段的 shellcode 是由DonutLoader配置的有效载荷，DonutLoader 是一个开源 shellcode 生成器，用于将 .NET 程序集、DLL 和 EXE 封装成位置无关 shellcode (PIC)，以便在内存中执行。在解包过程中，shellcode 使用 CTR 模式下的 Chaskey-LTS 分组密码，以密钥 ( 6E0A1F8F77F7011561F6F9CA96B71B8F ) 和 IV ( 956C6128E9362E075F8D006C93616A66 ) 解密加载器的嵌入式配置和执行上下文。

解密后，有效载荷通过 aPLib 解压缩，然后通过 DonutLoader 的RunPE()函数进行引导。最后一个有效载荷是Huntress新发现的信息窃取程序，名为 CASTLESTEALER。该归属基于先前样本中0xDEADBEEF标记之间 C2 通信所使用的相同 AES 密钥。

第二种 OXLOADER 变体：相同的加载器，不同的伪装程序

第二个 OXLOADER 变体伪装成 Node.js 安装程序而不是 API Monitor，但使用了相同的加载机制。

在 5 月13 、 2026 ，我们发现重定向端点app.miloyannopoulos[.]com/download响应时会随机选择两个Location标头字段中的一个：

• https://link.storjshare[.]io/raw/jv5uebuqwzfpmtahj34q753ptykq/node/BATPackageBulderSetup.bat
• https://link.storjshare[.]io/raw/jvsmdybqmvwep2oawbobp6ub7aza/node/node-v24.15.0-x64-86.exe

批处理安装脚本（ BATPackageBulderSetup.bat ，其中“Builder”拼写错误）基本保持不变。唯一的区别是 Storj 有效载荷链接现在指向名为node-v24.15.0-x64-86.exe的不同二进制文件。

该有效载荷试图伪装成良性的 CMake 代码，同时在文件名中保留“node”，可能是为了保持诱饵主题不变。我们认为之前出现的“API Monitor”样本可能是运营商分发错误造成的。

执行后，我们注意到相同的模式：使用间接跳转进行内存中的自解密，然后加载mpr.dll并调用WNetAddConnection2W 。我们确认它是之前讨论过的相同的装载机机制，并且该样品也装载CASTLESTEALER 。

下面是一个包含自解密过程的代码片段。与 CMake 相关的虚拟字符串似乎被作为参数传递给函数调用，该函数调用会在调用点之后立即将一个小的解密存根修补到内存中。然后执行跳转到存根以解密后续指令，此过程重复 2 次，直到主要恶意软件主体被解密。

结论：为什么防守方应该关注 OXLOADER

OXLOADER 目前还处于早期运营阶段，但其背后的工程技术表明，这个系列值得关注。代码混淆、反虚拟机措施、用于伪装其二进制文件的看似良性的代码以及独特的部署技术，都反映了为逃避分析而做出的刻意工程选择。这项投资正在取得成效，静态发动机和爆震试验的检测率都很低，这使得 OXLOADER 在被追捕之前有时间进行操作。

REF8372 通过 MITRE ATT&CK

Elastic 使用MITRE ATT&CK框架来记录威胁针对企业网络使用的常见策略、技术和程序。

战术

策略代表了技术或子技术的原因。 这是对手的战术目标：采取行动的原因。

• 资源开发
• 初始访问
• 执行
• 防御规避
• 发现
• 命令和控制
• 收集
• 渗漏

技术

技术代表对手如何通过采取行动来实现战术目标。

• 获取基础设施：恶意广告
• 阶段功能：上传恶意软件
• User Execution: Malicious File
• 命令和脚本解释器：PowerShell
• 滥用提升控制机制：绕过用户帐户控制
• 混淆文件或信息：加密/编码文件
• 对文件或信息进行反混淆/解码
• 混淆文件或信息：嵌入式有效载荷
• 伪装：匹配合法名称或位置
• 劫持执行流程：DLL 侧加载
• 虚拟化/沙盒规避：系统检查
• System Location Discovery: System Language Discovery
• 反射式代码加载

修复 REF8372

预防

• 潜在的浏览器信息发现
• 利用硬件断点的潜在规避方法
• 可疑的线程上下文操纵
• 来自未签名 DLL 的 VirtualAlloc API 调用
• 可疑的远程内存分配
• 从可疑的堆栈尾部字节执行
• Microsoft Common Language Runtime Loaded from Suspicious Memory
• 可疑的 PowerShell 执行
• 从复制库中调用模块

雅拉

Elastic Security 已创建 YARA 规则来识别此活动。

• Windows.Trojan.OxLoader
• Windows.Trojan.CastleStealer

观察结果

本研究讨论了以下可观察的结果。