2026-04-13 05:54:12 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文剖析Apifox桌面端供应链投毒事件。攻击者篡改官方CDN的JS脚本，利用Electron未启用沙箱缺陷，通过七层混淆与多级加载器静默窃取SSH、Git及K8s等凭据，借CDN隐蔽流量与概率触发精准打击。建议立即升级并全面轮换凭据。 综合评分： 94 文章分类： 供应链安全,恶意软件,应急响应,漏洞分析

cover_image

Apifox供应链投毒事件分析报告

原创

佚名佚名

星宇Sec

2026年4月9日 16:41 山东

一、事件背景

Apifox 是国内广泛使用的 API 一体化协作平台，其桌面端基于 Electron 框架开发，支持 Windows、macOS、Linux 三平台。因客户端未严格启用 sandbox 参数并暴露了 Node.js 原生 API 接口，攻击者得以通过植入恶意 JavaScript 代码完整控制用户终端，三个平台均受影响。

2026 年 3 月 25 日，安全研究人员在工作监测中首次发现 Apifox 官方 CDN 上的事件追踪脚本存在被投毒迹象。受攻击文件为 Apifox 桌面端启动时自动加载的合法埋点脚本（hxxps://cdn[.]apifox[.]com/www/assets/js/apifox-app-event-tracking.min.js）。正常版本大小约 34KB，投毒后文件体积膨胀至约 77KB，攻击者在合法 SDK 代码末尾追加了约 42KB 经严重混淆的恶意载荷。

根据被动 DNS 记录，恶意 C2 域名 apifox[.]it[.]com 于 2026 年 3 月 4 日通过 Cloudflare 上线，并在持续活跃 18 天后于 3 月 22 日撤收，导致受影响时间窗口为 2026 年 3 月 4 日至 3 月 22 日。Apifox 私有化部署版本不受影响。

警告：任何在 2026 年 3 月 4 日至 2026 年 3 月 22 日期间使用过 Apifox 公网 SaaS 版桌面客户端（版本低于 2.8.19）的用户，均应视所有本机敏感凭据存在泄露风险，须立即执行凭据轮换。

值得特别关注的是，本次攻击采用概率性触发机制，并非所有启动 Apifox 的用户均必然触发恶意载荷。攻击者通过对 C2 服务器返回内容的精细控制，实现了对目标的主动筛选，高价值目标（如金融机构、加密货币交易所等）可能遭受超出凭据窃取的深度入侵。

二、攻击链溯源分析

2.1 攻击事件时间线

| 日期 | 事件 | | — | — | | 2026-03-04 | C2 域名 apifox[.]it[.]com 上线（Cloudflare 托管），Apifox 官方 CDN 上的埋点脚本遭到替换，投毒正式开始。 | | 2026-03-04 至 2026-03-22 | 活跃期（18 天）：被投毒的 JS 文件通过 Apifox 官方 CDN 持续分发，攻击者经由 Cloudflare 隐藏真实 C2 源站，向受害者主机下发凭据窃取载荷。 | | 2026-03-22 | C2 域名 DNS 记录下线，恶意载荷停止分发；但 C2 后端源站 IP（13.192.121.27）仍在响应。 | | 2026-03-25 | 安全研究人员公开披露投毒事件；CDN 上的恶意文件已被替换为干净版本；Wayback Machine 存档中可见投毒版本。 | | 2026-03-25（事后处置） | Apifox 官方发布风险提示公告，确认公网 SaaS 版桌面客户端受影响，建议用户升级至 2.8.19 及以上版本并轮换凭据。 |

2.2 C2 基础设施与域名分析

社会工程学伪装，利用高仿域名诱导：攻击者使用的 C2 域名 apifox[.]it[.]com 极具迷惑性。.it.com 并非意大利国别域名的子域，而是一个商业性质的二级域名注册服务，不受 ICANN 标准监管，无公开 WHOIS 信息，注册门槛极低，非常适合攻击者滥用。对受害者而言，该域名极易被误认为 Apifox 的内部测试域名、意大利区域服务域名或某子产品域名，充分体现了攻击者在社会工程学层面的精心设计。

基础设施伪装与流量混淆，通过 CDN 代理隐匿：攻击者利用 Cloudflare 作为前置 CDN 代理，同时获得了合法 HTTPS 证书与全球加速能力，使恶意流量在网络层面难以与正常 CDN 流量区分。通过证书字段（cert:"apifox.it.com"）测绘，可将 C2 服务定位至日本东京 AWS EC2 实例（IP：13.192.121.27），后端为 Nginx/Express 架构。

2.3 入侵路径分析

本次攻击的入侵路径呈现出典型的“合法渠道劫持”模式：攻击者直接篡改 Apifox 官方 CDN 上的合法埋点脚本，利用用户对官方分发渠道的天然信任，实现了无需用户主动操作的静默投毒。

关键利用条件在于 Apifox 桌面端未启用 Electron 沙箱（sandbox: false）且暴露了 Node.js 原生 API 接口。这意味着在 Electron 渲染进程中运行的 JavaScript 代码可直接访问文件系统（require("fs")）、操作系统信息（require("os")）、加密模块（require("crypto")）等 Node.js 特权接口，而这些接口在普通浏览器环境中完全不可用，使攻击效果仅在桌面客户端中完整生效。

三、恶意代码与攻击手法分析

3.1 被投毒文件结构

| 区域 | 大小 | 内容 | | — | — | — | | 第一部分（合法） | 34KB | 原始 Apifox 事件追踪 SDK（含 GA4、百度统计、阿里云 SLS、PostHog 等），Webpack 打包，本身不含恶意行为 | | 第二部分（恶意） | 42KB | 攻击者追加的严重混淆 JavaScript 后门代码，7 层混淆叠加，包含完整 C2 通信与载荷执行逻辑 |

3.2 混淆技术分析

恶意代码采用了 7 层混淆叠加，逆向难度极高：

3.3 攻击载荷执行链

| 阶段 | 行为 | 目标数据 | | — | — | — | | 一级加载器 | 反混淆后的 JS 直接内嵌于合法埋点脚本末尾，采集机器指纹（MAC+CPU+主机名+用户名的 SHA-256 哈希）、窃取 Apifox 登录 Token 并调用官方 API 获取账号邮箱，将所有信息经 RSA-2048 加密后通过自定义 HTTP 头携带，向 C2 服务器请求下一阶段载荷，并以 eval() 执行 C2 返回的 RSA 解密后的 JS 代码。定时轮询间隔 30 分钟 – 3 小时，即使出错也不停轮询。 | 机器指纹、操作系统信息、Apifox 账号邮箱与用户名 | | 二级加载器 | C2 返回 344 字节 RSA 密文，解密后为 IIFE 代码，向 document.head 动态插入 <script> 标签加载第三阶段脚本，加载完成后立即从 DOM 中移除该节点，实现反取证。每次 Stage-1 请求生成不同的随机 8 位十六进制文件名（如 b8ee3b68.js），历史路径返回 404，阻碍基于 URL 的检测。 | 过渡层，不直接窃取数据 | | 信息窃取 | 明文 Node.js 脚本（约 3.4KB），保留完整中文开发注释。读取 ~/.ssh/（递归）、~/.zsh_history、~/.bash_history、~/.git-credentials，执行 ps aux（macOS/Linux）或 tasklist（Windows）。数据经 JSON -> Gzip -> AES-256-GCM 加密（密码 apifox / 盐 foxapi / scrypt 派生密钥）后 POST 上传。 | SSH 密钥（全目录）、Bash/Zsh 历史、Git 明文凭证、进程列表 | | 纵深窃取 | C2 服务器后续升级的增强载荷（约 4.4KB），新增第二轮窃取，数据上报至 /event/2/log 端点。攻击者可根据 Stage-3 v1 回传的机器指纹与邮箱信息筛选高价值目标，定制后续攻击策略。 | ~/.zshrc （含 API Key/数据库连接串）、~/.npmrc（npm Token）、~/.kube/*（K8s 集群配置）、~/.subversion/*（SVN 凭证）、主目录/桌面/文档目录树（深度 1~2 层），Windows 额外扫描 D/E/F 盘 |

3.4 数据窃取手法和基础设施

窃取的数据通过以下加密流程进行打包与外泄：

原始 JSON -> Gzip 压缩 -> AES-256-GCM 加密 -> Base64 编码 -> HTTPS POST 上传

AES-256-GCM 加密参数：

加密密码：apifox（硬编码）
盐值：foxapi（硬编码）
密钥派生：scryptSync(password, salt, 32)
IV：12 字节随机值
格式：Base64(IV[12] + AuthTag[16] + CipherText)

外泄端点：

POST hxxps://apifox[.]it[.]com/event/0/log（Stage-3 v1）
POST hxxps://apifox[.]it[.]com/event/2/log（Stage-3 v2）

攻击者将 RSA-2048 私钥硬编码于一级加载器的恶意脚本中，这一 OPSEC（操作安全）失误使得安全研究人员得以完整还原 C2 通信内容并解密全部阶段载荷。与此同时，信息窃取阶段的载荷中保留了详尽的中文开发注释（包括对加密参数的“教学式”说明），与入口混淆层截然相反的 OPSEC 水平，暗示入口层与后端载荷可能并非同一人编写。

3.5 持久化与规避机制

定时轮询持久化：通过 setTimeout 机制，在 30 分钟 – 3 小时的随机间隔后重复执行一级加载器，只要 Apifox 保持运行即持续活跃；即使网络请求失败或 eval 抛出异常，finally 块中的 scheduleNext() 也保证下一轮调度不会中断。
URL 随机化反检测：二级加载器每次生成随机 8 位十六进制文件名，历史路径返回 404，使基于 URL 特征的网络检测规则快速失效。
DOM 自清理反取证：二级加载器脚本标签在 onload 后立即从 DOM 中移除，减少在页面中残留可见痕迹。
服务端指纹校验：C2 服务器要求客户端携带完整的 af_uuid、af_os、af_user、af_name 等自定义请求头，缺少任一字段均不下发有效载荷，默认 curl 等工具无法直接复现攻击场景。
Cloudflare CDN 混淆：通过 Cloudflare 隐藏真实源站 IP 并获得合法 TLS 证书，使恶意流量在网络层面极难与正常 CDN 请求区分。

四、Apifox 被攻击原因分析

（一）Electron 沙箱配置缺失（直接技术原因）

Apifox 桌面端未严格启用 Electron 的 sandbox 参数，并在渲染进程中暴露了 Node.js 原生 API 接口。这使得任何能够在渲染进程中执行的 JavaScript 代码都拥有等同于本地程序的系统权限，可直接读写文件系统、执行系统命令。这是本次攻击得以造成严重危害的根本性技术缺陷。

（二）CDN 资产缺乏完整性校验（供应链防护缺失）

Apifox 桌面端在启动时动态加载外部 CDN 上的 JavaScript 文件，却未对文件内容实施子资源完整性（SRI）校验。CDN 资产被篡改后，客户端无任何机制感知文件哈希变化，直接执行了膨胀至 77KB 的恶意版本。这一缺陷使 CDN 成为整条攻击链最脆弱的环节。

（三）高价值凭据的集中暴露（API 开发工具攻击价值高）

API 开发者群体（Apifox 的核心用户群）通常在工作机上同时持有 SSH 私钥、Git 凭证、云服务 AccessKey、数据库密码、K8s 集群配置等多类高权限凭据。攻击者将窃取目标精准对准这些高价值文件路径，一次投毒即可在海量受害者机器上批量获取企业级凭据，攻击收益远高于针对普通用户的攻击。

（四）概率性触发与服务端筛选（精准打击高价值目标）

攻击者设计了概率性触发机制与服务端指纹校验，使载荷仅对符合条件的目标下发。这一设计实现了“广撒网、精捞鱼”：对普通用户降低暴露风险，对特定高价值目标（如金融、加密货币等行业）实施深度定制化后续攻击。当前公开的 IoC 仅涵盖侦察与凭据采集阶段，无法排除高价值目标遭受后门植入、横向移动、源码窃取等更深度入侵的可能。

五、典型风险场景分析

（一）开发者工作站完全失陷（凭据批量泄露）

受影响用户的工作机通常同时持有 SSH 私钥、GitHub/GitLab Personal Access Token、AWS/GCP/Azure 访问凭据、数据库连接密码等。Stage-3 一次性递归读取 ~/.ssh/ 整个目录，意味着攻击者可获取受害者可达的全部服务器访问权限，影响范围从个人开发环境延伸至生产服务器。

（二）Kubernetes 集群被横向控制（云原生环境高危）

Stage-3 v2 针对性窃取 ~/.kube/* 目录下的全部 K8s 集群配置文件，含集群 APIServer 地址、OIDC Token 及 ServiceAccount 凭证。攻击者获取后可直接枚举全集群 Secrets，进而实施特权 Pod 部署、持久化后门安装及全集群横向移动，造成云原生基础设施的系统性失陷。

（三）代码仓库供应链二次投毒（攻击链传导）

.git-credentials 记录了 Git 仓库的明文访问凭证，~/.npmrc 记录了 npm 私有仓库的认证 Token。攻击者获取后可对代码仓库实施未授权提交、向私有 npm 包植入后门，形成从 Apifox 投毒 -> 开发者凭据泄露 -> 下游代码/制品再次被投毒的供应链二次传导，影响范围随依赖链指数级扩大。

（四）Shell 历史泄露隐性高价值信息（间接凭据失陷）

.zsh_history 和 .bash_history 中往往记录着通过命令行传递的临时密码、export 形式的 API Key、含凭据的 curl 命令等，这些敏感信息往往不被纳入常规的凭据管理范畴。攻击者从 Shell 历史中提取的有效凭据可能涵盖数据库、内部 API、云服务等，是被严重低估的高价值数据源。

特别提示：当前公开的 IoC 仅涵盖侦察和凭据采集阶段。该恶意软件本质上是一个基于 eval() 的完整灵活 C2 平台，攻击者在每次轮询中均可下发不同的任意 JavaScript 代码。受影响用户切不可因当前公开的 IoC 仅涵盖侦察行为就低估威胁等级，应按“已完全失陷”的最高级别进行应急响应。

六、应急处置指南

6.1 排查是否受影响

满足以下任一条件，即可基本确认受影响：

时间与版本：在 2026 年 3 月 4 日至 3 月 22 日期间，曾启动过 Apifox 公网 SaaS 版桌面客户端（版本低于 2.8.19）。
本机存储排查（Windows）：

Select-String -Path "$env:APPDATA\apifox\Local Storage\leveldb\*" -Pattern "rl_mc","rl_headers" -List | Select-Object Path

本机存储排查（macOS）：

grep -arlE&nbsp;"rl_mc|rl_headers"&nbsp;~/Library/Application\ Support/apifox/Local\ Storage/leveldb

网络侧排查：检查防火墙/代理/DNS 日志中是否出现对 apifox[.]it[.]com、13.192.121.27 的出站访问记录，或 /public/apifox-event.js、/event/0/log 等特征路径请求。
客户端存储（开发者工具）：在 Apifox 桌面端打开开发者工具（Ctrl+Shift+I / Cmd+Option+I），在 Application -> Local Storage 中检查是否存在 _rl_mc、_rl_headers 键，若 _rl_headers 中出现 af_uuid、af_user 等字段则高度相关。

安全版本为 Apifox 2.8.19 及以上。

6.2 清除感染

立即升级 Apifox 客户端至 2.8.19 或以上版本（官网下载最新正式版，覆盖安装）。
在防火墙、企业 DNS 或本机 hosts 中封锁已知恶意域名及 IP：apifox[.]it[.]com、cdn[.]openroute[.]dev、upgrade[.]feishu[.]it[.]com、13.192.121.27。
清除 Apifox 本地缓存数据，包括 Local Storage 中的 _rl_mc 和 _rl_headers 键，以消除机器指纹留存。

6.3 凭据轮换（按优先级执行）

| 凭据类型 | 处置说明 | 优先级 | | — | — | — | | SSH 私钥（~/.ssh/） | 在服务器端移除旧公钥，重新生成密钥对并轮换部署；审计 auth.log 中的异常公钥认证记录 | 极高 | | Git 凭证（~/.git-credentials） | 删除该文件，在 GitHub/GitLab 等平台吊销并重建 Personal Access Token，修改账号密码，改用系统凭据助手（osxkeychain/manager） | 极高 | | Shell 历史中的凭据（~/.zsh_history、~/.bash_history） | 逐项排查历史中出现的数据库口令、API Key、云 AccessKey 等，依次轮换，不能仅改密码而忽略历史中的其他 Secret | 极高 | | K8s 集群配置（~/.kube/*） | 吊销受影响的 ServiceAccount Token 与 OIDC 凭证，重新颁发；审计集群中的异常权限操作记录 | 极高 | | 云服务凭据（AWS/GCP/Azure AccessKey） | 在云控制台立即停用旧密钥并生成新密钥，检查异常 API 调用记录 | 极高 | | ~/.npmrc 中的 npm Token | 在 npm/私有仓库控制台吊销 Token 并重新生成；审计近期的包发布记录 | 极高 | | ~/.zshrc 等 Shell 配置中的环境变量 | 排查是否含 API Key、数据库连接串、Vault 地址等，逐项轮换 | 高 | | Apifox 账号密码 | 修改 Apifox 账号密码，在客户端退出登录后重新登录以刷新 accessToken；检查团队与项目内是否有异常操作 | 高 | | SVN 凭证（~/.subversion/*） | 更新 SVN 服务端凭证，重新配置本地认证信息 | 中 |

七、IoC

八、总结与启示

Apifox 供应链投毒事件的本质，是攻击者利用“Electron 沙箱缺失 + CDN 完整性校验缺位 + 开发者工作站富凭据特性”三者叠加形成的系统性风险，对 API 开发者生态的信任基础发起冲击。正值 LiteLLM 投毒事件余波未散之际（详见下篇文章），本次事件再次警示：供应链攻击已进入常态化、精准化的新阶段。

（一）Electron 应用安全亟需重视（沙箱配置是安全基线）

基于 Electron 开发的桌面应用应将启用 sandbox 参数与禁用 nodeIntegration 视为不可妥协的安全基线，而非可选配置。在渲染进程中暴露 Node.js 接口，本质上是将系统级权限拱手让给任何可在渲染进程中执行代码的攻击者。

（二）CDN 资产完整性校验是防御关键（SRI 机制应强制落地）

对于从外部 CDN 动态加载并执行的 JavaScript 资源，必须强制实施子资源完整性（SRI）校验，或改为将资源打包至客户端本地，消除 CDN 被篡改带来的风险。

（三）开发工具软件成为供应链攻击的首选入口（高价值低防护）

API 工具、IDE 插件、代码分析工具等深度集成于开发流程、持有大量高权限凭据的软件，是供应链攻击者优先觊觎的目标。一旦这类工具被攻陷，攻击者可直接获取开发者可达的全部系统权限，形成远超普通用户攻击的规模化危害。

（四）攻击工具化与精准化是重要趋势（C2 平台化）

本次攻击的恶意软件本质上是一个完整的远程代码执行平台，C2 服务器可在每次轮询中下发截然不同的任意载荷。攻击者基于回传的机器指纹、账号邮箱、SSH 密钥、K8s 配置等信息主动筛选高价值目标，实施量身定制的后续攻击，标志着供应链攻击正向“侦察 -> 分级 -> 精准打击”的 APT 化模式演进。

（五）应急响应不能止步于“已公开 IoC”（防御姿态需更积极）

当前公开的 IoC 仅涵盖侦察和凭据采集阶段，不代表攻击的终点。受影响机构和个人应按“已完全失陷”的最高级别启动应急响应，而非仅根据公开 IoC 做浅层排查，以避免遗漏可能已发生的深度入侵。

（六）供应链安全需从被动修复转向主动治理（体系化建设）

从 LiteLLM 到 Apifox，供应链攻击已形成持续性威胁态势。企业和开发者需将供应链安全纳入与功能开发同等优先级的体系化建设中：包括 CDN 资产 SRI 校验、开发工具沙箱化运行、凭据动态轮换机制、供应链 SBOM 管理、构建流程完整性保护等，从制度和技术两个维度重构对开发工具链的信任体系。

PDF版：

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：星宇Sec 佚名佚名《Apifox供应链投毒事件分析报告》