新的基于 Node.js 的 LTX 窃取器攻击用户以窃取登录凭证

2026-02-10 02:12:55 2 535

一种名为“LTX Stealer”的复杂新型恶意软件在网络安全领域出现,利用独特的基于 Node.js 的架构来攻击 Windows 系统。




一种名为“LTX Stealer”的复杂新型恶意软件在网络安全领域出现,利用独特的基于 Node.js 的架构来攻击 Windows 系统。
该恶意工具于2026年初首次出现,旨在收集敏感用户信息,包括登录凭证、浏览器 Cookie 和加密货币钱包数据。
该恶意软件通过在其负载中打包完整的 Node.js 运行时环境而区别于其他恶意软件,允许其在受害者的计算机上原生执行复杂的 JavaScript 代码,而无需事先安装该框架。
攻击通常以一个看似简单的入口点开始:一个名为“Negro.exe”的 Windows 安装文件。该文件使用合法的 Inno Setup 框架构建,这是一个常见的用于创建软件安装器的工具。
通过隐藏在可信的安装包装器中,恶意软件有效地使其恶意意图从标准安全扫描中隐藏。执行时,该安装程序会在受害者的系统中植入一个巨大的文件包——大约 271MB 大小。
Cyfirma 分析师在恶意软件出现后不久就识别了它,指出这个大文件大小是一种故意策略,以绕过通常跳过扫描大型文件以维持系统性能的反病毒引擎。
一旦进入,LTX Stealer 针对基于 Chromium 的浏览器,如 Google Chrome 和 Microsoft Edge。它访问“Local State”文件以提取加密密钥,然后使用这些密钥解锁保存的密码和会话 cookie。
同时,该恶意软件扫描加密货币钱包,并截取用户的屏幕截图。所有被盗数据都被压缩并准备传输到命令与控制服务器。
攻击者利用 Supabase 等云服务进行身份验证,并使用 Cloudflare 隐藏其服务器的真实位置,使基础设施能够抵抗下线。

通过字节码编译进行混淆
LTX Stealer 的一个显著技术特征是其高度依赖先进的混淆技术来阻碍逆向工程。
主要有效载荷 updater.exe 不是一个标准可执行文件,而是一个使用名为 pkg 的工具打包的 Node.js 应用程序。这捆绑了恶意 JavaScript 逻辑、依赖项和运行时到一个单一的二进制文件中。

LTX Stealer 安装程序属性(来源——Cyfirma)
为了进一步保护他们的代码,开发者使用 Bytenode 将 JavaScript 源代码编译成字节码( .jsc )。这种转换过程将可读代码转换为二进制格式,这对安全研究人员来说极难反编译或分析。

Chromium 主密钥解密流程(来源——Cyfirma)
通过完全移除原始源代码,攻击者确保理解恶意软件的内部逻辑需要具备 Node.js 内部的专业知识,显著提高了分析和检测的门槛。

为防御 LTX Stealer,组织应实施以下措施:
  • 阻止已知指标:配置防火墙和终端检测系统,阻止访问与恶意软件控制面板相关的域名(如 eqp.lol )和 IP 地址。
  • 监控文件创建:对用户可访问路径中创建的隐藏或系统标记的目录发出警报,特别是那些模仿合法供应商(如“Microsoft Updater”)的目录。
  • 标记大型二进制文件:调查未签名的、异常大的可执行文件(超过 100MB)且运行时行为与 Node.js 应用程序一致的情况。
  • 检测凭证访问:监控依次访问浏览器“本地状态”文件和凭证存储的过程,因为这种行为高度表明存在信息窃取活动。

关于作者

weak_hong40篇文章52篇回复

评论2次

要评论?请先  登录  或  注册
  • 2楼
    2026-2-11 15:43

    Node.js 哪些版本不受这个漏洞的影响啊? @T00lsAI

  • 1楼
    2026-2-10 11:37

    结论

    LTX Stealer以Node.js为攻击载体,通过混淆技术(Bytenode字节码+pkg打包)规避静态分析,利用合法工具链(Inno Setup)掩盖恶意行为。攻击链聚焦于源数据窃取(浏览器/钱包凭证)和Sink通道(Supabase+Cloudflare C2),需从代码执行链路、数据流动路径切入防御。


    分析路径

    L1攻击面识别

    1. 入口点Negro.exe(Inno Setup包装的安装器)

      • 检查安装器解压路径是否包含隐藏目录(如%APPDATA%\Microsoft\Updater
      • 验证解压的271MB文件包是否包含Node.js运行时(node.dll.jsc字节码文件)
    2. 攻击目标

      • Source(数据源):Chromium浏览器的Local State(密钥)、Login Data(凭证);
      • Sink(数据出口):加密压缩后的数据通过HTTP POST发送至eqp.lol等C2域。
    3. 混淆层

      • 主体逻辑以.jsc字节码形式存在,依赖pkg打包的Node.js运行时执行。

    L2假设与验证 假设混淆后的代码逻辑包含以下行为:

    • 解密Chrome主密钥(需调用bcrypt或自定义解密函数);
    • 遍历钱包目录(如Electrum、MetaMask配置文件路径);
    • 使用axiosrequest模块与C2通信。

    验证路径:

    • 通过ProcMon监控updater.exe对浏览器配置文件的访问顺序;
    • 动态调试:用Bytenode反编译.jsc或设置Node.js全局钩子(如process.on('exit')触发断点。

    L3边界/异常场景

    • 文件行为异常:未签名的超大Node.js可执行文件(>200MB);
    • 注册表/进程异常:伪装为Windows Update服务但PID异常波动;
    • 网络特征:TLS握手时携带Supabase API密钥或Cloudflare Ray ID。

    L4防御反推与修复

    • 绕过混淆:内存dump提取JIT编译后的代码逻辑;
    • 数据面防御:在浏览器Cookie解密前注入随机密钥污染;
    • Sink阻断:DNS层级拦截.lol域名,流量中拦截Supabase的rest/v1API路径。

    验证步骤

    1. 静态分析

      • strings updater.exe查找Bytenodepkg.mjs等字符串;
      • 使用7z x Negro.exe提取Inno Setup解压路径,检查是否存在.jsc文件。
    2. 动态分析

      • 在沙箱中注入updater.exe,用Cheat Engine搜索内存中的硬编码C2域名;
      • 监控%TEMP%\临时目录,捕获压缩的窃取数据包(通常为gzip格式)。
    3. 网络取证

      • 抓包分析HTTP请求头,检查是否存在Authorization:Bearer(Supabase API);
      • 通过CFF Explorer查看二进制PE文件的导出函数(如node.exe相关API)。

    修复建议

    1. 代码层

      • 在Node.js应用中添加运行时签名验证(如校验.jsc文件哈xi);
      • Local State文件添加访问控制(Windows ACL限制非可信进程读取)。
    2. 检测规则

      • 签名规则:匹配node.exe进程加载.jsc文件且父进程为explorer.exe
      • 行为规则:触发告警的条件为CreateFile(Local State) → Decrypt → HTTP POST链式动作。
    3. 基础设施防御

      • 在NGFW中设置策略:拦截任何User-AgentNode.js的异常流量;
      • 使用EDR工具标记内存中动态生成的.jsc字节码执行行为。

    关键点:LTX的混淆本质是Node.js运行时环境的封装,需通过运行时上下文分析(而非纯静态逆向)切入,重点关注数据流动路径的Source-Sink断点。