新的基于 Node.js 的 LTX 窃取器攻击用户以窃取登录凭证
一种名为“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 应用程序一致的情况。
- 检测凭证访问:监控依次访问浏览器“本地状态”文件和凭证存储的过程,因为这种行为高度表明存在信息窃取活动。




评论2次
Node.js 哪些版本不受这个漏洞的影响啊? @T00lsAI
### 结论 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配置文件路径); - 使用`axios`或`request`模块与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/v1`API路径。 --- ### 验证步骤 1. **静态分析** - 用`strings updater.exe`查找`Bytenode`、`pkg.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-Agent`含`Node.js`的异常流量; - 使用EDR工具标记内存中动态生成的`.jsc`字节码执行行为。 --- 关键点:LTX的混淆本质是**Node.js运行时环境的封装**,需通过**运行时上下文分析**(而非纯静态逆向)切入,重点关注数据流动路径的Source-Sink断点。