文章总结： GlassWorm恶意软件通过73个OpenVSX休眠扩展实施供应链攻击，采用良性首发-信任积累-更新投毒策略。攻击者使用瘦加载器架构动态获取恶意载荷，针对性窃取开发者加密货币钱包和云凭证。文档详细分析了攻击链技术细节、威胁行为体画像及IOC特征，并提供了检测规则和应急响应建议，威胁等级评定为High。 综合评分： 92 文章分类： 供应链安全,恶意软件,威胁情报,漏洞预警,安全运营
良性首发-信任积累-更新投毒：GlassWorm 恶意软件通过 73 个 OpenVSX “沉睡者”扩展卷土重来
原创
威胁情报中心 威胁情报中心
奇安信威胁情报中心
2026年4月28日 11:37 北京
在小说阅读器读本章
去阅读
一、事件概述
GlassWorm 威胁活动近期在 OpenVSX 开源扩展生态中爆发新一轮大规模供应链攻击。根据 Socket 安全团队及多方情报交叉验证，攻击者于 2026 年 4 月向 OpenVSX 注册中心提交了 73 个”休眠（Sleeper）”恶意扩展，紧随 3 月份 72 个恶意包的第二波攻势。其中至少 6 个扩展已被激活并成功投递恶意载荷，其余处于潜伏状态等待后续更新触发。
本次攻击标志着 GlassWorm 战术体系的重大演进：攻击者彻底放弃早期直接在扩展源码中硬编码恶意代码或滥用不可见 Unicode 字符的粗糙手法，转而采用 “良性首发-信任积累-更新投毒” 的生命周期模型。恶意扩展仅作为”瘦加载器（Thin Loader）”，通过运行时从 GitHub 拉取辅助 VSIX 包、加载平台原生 .node 模块或执行高度混淆的解密脚本，动态获取核心窃密组件。攻击目标明确指向开发者工作站，旨在批量窃取加密货币钱包、云凭证、访问令牌及 SSH 私钥。鉴于供应链攻击的穿透性与开发者环境的高权限属性，该事件威胁等级评定为 High。
二、技术细节分析
1. 休眠架构与生命周期管理
攻击者利用扩展市场的审核机制盲区，采用典型的 Sleeper Malware 架构：
-
阶段一（上架期）
扩展包仅包含基础 UI 组件、静态资源或无害占位逻辑，通过市场自动扫描与人工初筛。
-
阶段二（信任期）
通过克隆流行扩展（如 VS Code 土耳其语语言包）的图标、命名与描述进行视觉欺骗（Typosquatting），配合新注册的 GitHub 账户（仅维护 1-2 个公开仓库作为掩护）积累下载量与用户信任。
-
阶段三（激活期）
通过标准扩展更新通道推送包含恶意加载器的版本，利用开发者”默认信任已安装扩展自动更新”的心理模型完成驻留。
2. 动态载荷投递机制（Thin Loader 架构）
为规避静态沙箱检测与代码签名验证，加载器采用多模态动态加载技术：
-
GitHub 托管 VSIX 注入
运行时通过 CLI 命令（如
code --install-extension <url>）静默安装托管于 GitHub 的二级 VSIX 包，实现模块化解耦。 -
原生模块滥用（.node）
捆绑平台特定的编译型
.node文件（据外部情报分析，部分变体使用 Zig 语言编译的 Dropper）。原生模块可绕过 Node.js/JS 沙箱限制，直接调用系统 API 进行文件系统遍历、进程注入与持久化。 -
运行时混淆解密
部分变体依赖重度混淆的 JavaScript，通过字符串变形、控制流平坦化与动态
eval()/Function构造器在内存中解密核心逻辑。内置加密或冗余备用 C2 URL，确保单点失效不影响载荷获取。
3. 跨平台与环境适配
扩展通过读取 process.platform 与 process.arch 动态选择对应 .node 二进制或混淆脚本，支持 Windows、Linux 与 macOS。macOS 变种还结合了木马化加密货币钱包客户端的辅助投递，形成多路径覆盖。
三、攻击链还原（MITRE ATT&CK 映射）
| 攻击阶段 | ATT&CK 技术编号 | 技术名称 | 战术实现描述 |
| — | — | — | — |
| 资源筹备 | T1583.006 / T1585.003 | 获取基础设施/开发账户 | 批量注册 GitHub 账户，伪造元数据，准备 .node 编译链与混淆引擎。 |
| 初始访问 | T1195.002 | 供应链攻击：软件供应链 | 将休眠扩展上传至 OpenVSX Registry，利用官方分发渠道触达目标。 |
| 执行 | T1059.006 / T1106 | 命令行与脚本/原生 API | 通过 IDE 扩展宿主进程 (extensionHost) 执行 JS 混淆代码或直接调用 .node 原生模块。 |
| 持久化 | T1547.001 | 启动项执行 | 利用 IDE 扩展机制实现每次编辑器启动时自动加载，无需修改系统注册表或 cron。 |
| 防御规避 | T1027 / T1036.005 / T1599 | 混淆/伪装/规避安全控制 | 首版无恶意特征；运行时解密；克隆合法扩展发布者标识与视觉元素；延迟触发逻辑。 |
| 凭证收集 | T1552.001 / T1552.004 | 凭据发现：本地存储/云凭证 | 扫描 ~/.ssh, ~/.aws/credentials, ~/.config/Code/User/globalStorage, 浏览器钱包目录。 |
| 数据外传 | T1041 / T1567 | 加密通道/收集后外传 | 通过 HTTPS 将加密后的钱包种子、API Key 传至攻击者控制的 C2 节点（域名/动态 IP 轮换）。 |
#
#
四、威胁行为体画像
| 维度 | 分析结论 | | — | — | | 身份与组织 | GlassWorm 并非单一漏洞利用团伙，而是具备 工程化流水线能力 的供应链攻击组织。其战术迭代速度（月度级波浪式攻击）与多生态覆盖（npm, GitHub, VSCode, OpenVSX）表明背后有专职开发、运维与情报团队支撑。 | | 核心动机 | 经济利益驱动 为主。直接目标为加密货币资产窃取与高价值开发者凭证（云 API、Git Token、CI/CD 权限）收割。窃取的凭证极可能用于二次勒索、代码库投毒或黑市交易，具备明显的”财务型 APT”特征。 | | 技术能力 | 高 。熟练掌握跨平台编译（Zig/C++）、JS 混淆工程、供应链分发机制、市场审核规避策略。采用”瘦加载器+动态拉取”架构，体现对现代端点检测（EDR）与静态沙箱的深刻认知。 | | 目标画像 | 全栈开发者、DevOps 工程师、开源贡献者、加密资产持有者。偏好使用 VS Code/OpenVSX 生态，对扩展更新缺乏深度审计习惯。 | | 历史活动轨迹 | 2024年10月首次曝光 → 2025年横向渗透至 npm/GitHub/macOS → 2026年3月（72包）测试”休眠”策略 → 2026年4月（73包）规模化部署并引入原生模块。攻击半径持续扩大，隐蔽性呈指数级提升。 |
#
#
五、IOC 深度分析
由于 GlassWorm 采用动态载荷与高频更新策略，传统静态 IOC（固定 Hash/IP）生命周期极短（通常 <72 小时）。本次分析聚焦 行为型与环境型 IOC，更适用于企业级威胁狩猎：
1. 扩展元数据异常
-
发布者标识不匹配
扩展包
publisher字段与displayName/icon不一致，或与官方同名扩展的unique identifier存在细微差异。 -
GitHub 仓库掩护特征
托管载荷的 GitHub 账户注册日期 < 90 天，仓库数量 ≤ 2，无 Star/Fork 互动，仅包含
.vsix或编译产物。
2. 运行时行为指纹
-
CLI 静默安装
node或extensionHost进程执行code --install-extension https://raw.githubusercontent.com/...或类似下载+安装命令序列。 -
原生模块异常加载
非 Node.js 项目目录中出现
.node文件，且由 IDE 扩展进程dlopen()加载；该模块导出函数包含文件系统遍历或网络请求逻辑。 -
高熵混淆特征
扩展主 JS 文件包含超长 Base64/Hex 编码块、动态字符串拼接、
atob()/Buffer滥用，且无合法业务逻辑对应。
3. 目标访问行为
-
非常规进程读取敏感目录
extensionHost或子进程访问~/.ssh/id_*,~/.aws/,~/.kube/config, 浏览器扩展存储路径（如Default/Local Extension Settings）。 -
隐蔽外传流量
IDE 进程向非官方域名发起 HTTPS POST，内容包含
Authorization、PRIVATE_KEY或mnemonic等关键字段（需结合网络代理日志）。
狩猎建议：在 EDR 中配置基于进程树与文件访问的关联规则；在流量侧对
code进程的非市场域名出站连接进行 TLS SNI 或 JA3 指纹监控。
#
#
六、影响评估
| 评估维度 | 详细分析 | | — | — | | 影响范围 | OpenVSX 作为 Eclipse Theia、Gitpod、GitLab Web IDE 及部分 JetBrains 插件的底层注册中心，其污染可间接波及多家企业级开发平台与云 IDE 服务商。 | | 业务风险 | 高危 。开发者环境拥有生产级权限（CI/CD Token、云控制台、代码仓库 Write 权限）。凭证泄露将直接导致供应链下游投毒、云资源劫持、源代码窃取或加密资产归零。 | | 行业靶点 | 软件开发、金融科技/区块链、云原生企业、开源基金会、外包开发团队。加密货币开发者与 Web3 项目贡献者为高优先级目标。 | | 暴露面扩大因素 | “休眠”策略导致大量已安装扩展成为定时炸弹；开发者普遍缺乏扩展版本回滚与差异审计习惯；部分企业未对 IDE 实施网络隔离或扩展白名单策略。 |
#
#
七、检测与响应建议
1. 检测规则思路
Sigma 规则示例（进程与 CLI 监控）：
title: IDE Extension Host Spawning VSIX Installer via GitHub
logsource: process_creation
detection:
selection:
ParentImage|endswith: 'node.exe' # 或 code-insiders/node/extensionHost
Image|endswith: 'code.exe'
CommandLine|contains|all:
- '--install-extension'
- 'github.com'
- 'raw.githubusercontent.com'
condition: selection
level: high
YARA 规则思路（混淆 JS 与 .node 特征）：
- 扫描高熵字符串块（
entropy > 6.5）+ 动态执行关键字（eval|Function|vm.runInThisContext）+ 网络请求库调用（axios|node-fetch|https.request）。 - 扫描
.node模块的 ELF/PE 头，匹配特定节区名称（如.rsrc中隐藏配置）或导出符号表包含steal,wallet,token等变体（需配合 AI 辅助模式匹配）。
网络检测：
- 监控 IDE 进程向
raw.githubusercontent.com发起的.vsix或.tar.gz下载请求，对比 OpenVSX 官方更新源域名差异。
2. 应急响应措施
-
隔离与清理
立即卸载 Socket 公布的 73 个扩展清单；清理
~/.vscode/extensions与~/.openvsx缓存目录。 -
凭证轮换（强制）
假设已沦陷，立即轮换所有 SSH 密钥、Git Token、AWS/GCP/Azure Access Key、数据库密码及加密货币钱包助记词。
-
主机取证
使用 EDR 回溯
extensionHost进程树，检查是否存在持久化计划任务、注册表修改或隐藏账户；提取内存中的解密后载荷样本。 -
流程加固
实施 IDE 扩展企业级白名单；禁用自动更新，强制人工审核变更日志；对 OpenVSX/npm 依赖实施 SBOM 追踪与签名验证。
#
#
八、未来趋势研判
-
战术常态化与架构升级
“休眠供应链”已成为高级财务型攻击的标准配置。未来载荷将进一步向 WASM（WebAssembly） 或 Rust/Zig 编译的二进制 迁移，利用跨平台兼容性与更难逆向的特性对抗静态分析。动态加载将结合 AI 生成的多态混淆，实现”一机一密”。
-
生态横向渗透
攻击者将加速复制该模型至 PyPI、RubyGems、Cargo、Maven 等包管理器。针对 Go/Java 生态的供应链投毒将增加
vendor/目录篡改与模块替换手法。 -
防御博弈升级
扩展市场将引入 动态沙箱更新验证（对比更新前后代码 Diff）、发布者身份强校验与行为基线监控。攻击者将采用 条件触发器（如仅当检测到特定地理 IP、企业域名后缀或反沙箱环境时才激活载荷）以延长存活期。
-
战略建议
组织需从”信任默认依赖”转向 “零信任依赖链”。建立自动化 SBOM 监控、实施 IDE 网络微隔离、引入扩展行为审计代理（Extension Behavior Agent），并将开发者工作站纳入与生产服务器同等级的威胁检测体系。供应链安全已从代码审计扩展至 全生命周期运行时监控。
点击阅读原文至ALPHA 9.3
即刻助力威胁研判
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：奇安信威胁情报中心 威胁情报中心 威胁情报中心《良性首发-信任积累-更新投毒：GlassWorm 恶意软件通过 73 个 OpenVSX “沉睡者”扩展卷土重来》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论