10 台云主机 + 一个大模型 = 180 万款 App 的密钥被扒光：Anthropic 154 页报告里的 AI 攻击流水线

2026 年 9 月 13 日，Anthropic 公开一份 154 页的威胁情报报告，首次系统披露了攻击者如何在实战中把 Claude 改造成攻击中枢。

报告里最有画面感的一组数字是：一个团伙在 AWS 上租了 10 台高性能 EC2 实例，搭出一条全程无需人工干预的流水线，对 180 万个安卓 APK 做反编译与语义级密钥提取，把验证可用的凭据自动推送到 Telegram 频道。

这份报告的价值不在于「黑客也在用 AI」——这件事已经不新鲜了。价值在于它给出了具体的工业参数：多少台机器、多少个样本、什么工具链、什么产出、什么回传通道。

有了参数，攻击就不再抽象。下面按报告内容拆，然后接一个更硬的问题：当「混淆不够好但没人会专门看」这个前提失效之后，防御该靠什么。

一、先看清流水线：180 万个 APK 是怎么被榨干的

报告追踪的团伙代号 GTG-50014（法语区黑客组织，疑与知名勒索团伙 ShinyHunters 关联）。它的流水线有四道工序：

① 全网爬取 APK
自动化脚本从多个主流及第三方安卓市场批量抓取 180 万个独立 APK 安装包。注意是「多个主流和第三方市场」——第三方市场是重灾区，因为它们对上架包的审核强度远低于官方商店，且同一款 App 的历史版本往往长期可下载。

② 解包与语义审计
结合开源扫描引擎 TruffleHog 与 Claude API，对拆解后的 Java/Kotlin 源代码、资源配置与 native 库做语义级敏感数据挖掘。

这一步是整条流水线的分水岭。传统密钥扫描工具（TruffleHog 属于这一类）靠正则与熵值工作：找形如 AKIA[0-9A-Z]{16} 的字符串，或找高熵值长串。这类工具的老问题是误报率高——测试样本、示例代码、公开文档里的假密钥都会被命中，需要人工逐个判读。180 万个包产生的噪声，人工是消化不完的。

Claude 在这里承担的是语义判读：分辨这是不是真密钥、属于哪家服务、有没有实际权限。这一步把「能扫出来」变成了「能直接用」。

③ 自动去伪存真
报告的表述是「自动过滤无效测试字符，精准提取云服务 AccessKey、数据库连接串、支付商网关私钥以及内部服务 Token」。

注意提取的四类目标，价值量级完全不一样：

凭据类型	拿到之后能做什么	为什么它会在客户端里
云服务 AccessKey	直接操作云资源：读存储桶、起机器、看日志	图省事，把后端签名逻辑塞进客户端
数据库连接串	直连数据库，批量导出	早期架构遗留，或本地调试配置被打包
支付网关私钥	伪造回调、篡改订单状态、发起真实交易请求	服务端私钥被误放进移动端 SDK
内部服务 Token	横向进入内网服务	测试环境配置混入生产构建

④ 情报即时回传
「经校验具有真实登录权限的凭据，第一时间通过自动化机器人推送至黑客的 Telegram 暗网变现频道。」

「经校验」三个字是关键——这不是「把所有可疑字符串打包卖掉」的粗放模式，而是交付前完成可用性验证的工业化交付。买家拿到手就能用。

这条流水线的经济学

把四个数字摆在一起看：

10 台 EC2 实例（按小时计费，用完即弃）
180 万 个样本（此前这个量级只有大厂或国家级实验室才可能处理）
几美分 级别的算力成本（报告明确提到「以几美分的算力成本调动大模型并发审计数百万份代码」）
全自动（无需人工干预）

结论很直接：过去阻止大规模代码审计的不是技术，是人力成本。 当判读环节被大模型接管，成本结构变了，规模就从「不可能」变成「一次周末任务」。

而且这条流水线有一个此前不存在的能力：它对「没人专门看」这类侥幸是免疫的。你的密钥之所以过去安全，不是因为它藏得好，是因为审计它的人力成本高于它的价值。现在这个不等式反过来了。

二、木马被杀软拦下之后，AI 当场重写一遍

第二个案例是报告里技术含量最高的：GTG-20006（俄罗斯国家背景，关联 Midnight Blizzard / APT29）。

流程是这样：

组织在目标内网部署 Windows 植入物（后门木马）。
该植入物被防病毒产品以静态签名阻断（被查杀）。
系统立即将告警特征回传。
由 Claude 实时重构代码架构、替换混淆手法并重新编译分发。

注意第 3 步：告警特征回传。这意味着防御方的查杀动作本身，成了攻击方的输入信号。杀软报了什么特征，攻击方就知道要改什么。

为什么这件事比「AI 能写免杀」更严重

「AI 能生成免杀木马」已经说了两年，但那指的是生成阶段。这份报告描述的是闭环迭代阶段——一个运行时的反馈回路：

1	部署 → 被检测 → 采集检测特征 → AI 重构 → 重编译 → 重新部署 → 再被检测 → ...

传统恶意软件有个隐含的时间成本：一个版本从被发现到变种上线，需要人工分析、改写、测试。这个周期通常以天计，给了防御方推送特征库、下发处置策略的窗口。

闭环把这个周期压到了和检测同频。如果防御方每小时更新一次特征，攻击方就能每小时出一个新版本。特征库因此从「防线」降级为「触发器」——每次更新都在驱动对方进化。

报告给出的定性是：这套流程「彻底消解了防御方的静态特征封堵能力」。这句话是准确的，因为静态特征防御的前提是样本在空间上有限（攻击者写不过来）；而这个前提被算力抹平了。

那么防御要换成什么

报告给的方向是三条，这里展开一下：

1. 行为检测替代特征检测。
不看「这个文件像不像木马」，看「这个进程在做什么」。具体是三类信号：

父子进程异动：正常业务进程的派生关系是稳定的，winword.exe 起 powershell.exe 起网络连接，无论文件叫什么名字都不正常。
内存注入：无文件落地、反射式加载、远程线程注入——这些动作在 API 调用层面有固定形态，改不了。
出站网络行为：木马无论怎么改写，都要回连。域名/IP/时序是可以被建模的。

2. 缩短「检测—处置」到「检测—隔离」的距离。
既然特征会失效，就把检测点放在动作发生时而不是文件落盘时。EDR 的价值在这里不在特征库，在能否实时阻断。

3. 别把告警当成终点。
这条最反直觉：既然查杀动作会回馈攻击方，那告警信息本身要分级——不要把完整的检出特征暴露给终端侧可读的位置。

三、多智能体：攻击开始有「岗位分工」

报告点名了另外两个团伙：

GTG-50020（黑产经济组织）：在 4 天窗口期内密集扫描并针对 30 余家 AI 提供商，尝试盗取未公开模型与商业 API Key。
GTG-50029（多智能体单兵作战）：自主部署多 Agent 挖掘 CMS 逻辑漏洞，并搭建自动化社工窃密网络。

它们的共同点是多智能体工作流：不同 Agent 分别承担不同角色，在无人干预下持续并行攻击数十家企业目标，时间跨度从数小时到数天。

分工本身就是能力放大

把攻击拆成岗位，和把生产拆成流水线的效果是一样的：

1	资产测绘 Agent → 漏洞投递 Agent → 权限维持 Agent → 数据渗漏 Agent

这种结构带来三个此前不容易同时具备的特性：

并行度。四个岗位可以同时对不同目标开工，而不是一个人串行推进。
容错性。某个 Agent 失败不影响其他环节，流水线会自动重试。
可复用性。测绘 Agent 产出的资产清单可以直接喂给下一轮攻击。

这和昨天写的（2026 网安周：AI 治理框架一年一更，今年为什么把「智能体」单独拎出来）、今天写的（当智能体拿到生产权限：OWASP 2026 智能体十大安全风险逐条拆解）放在一起看更清楚：攻防两侧在同一时间段里，用同一种范式（多智能体分工）重构了自己。 这不是巧合，是因为这条范式对「规模化」的收益最大——谁先规模化谁占优。

一个 0day：WordPress 重装竞态

报告还提到一个具体成果：黑客利用 Claude 发现了一处此前未被记录的 WordPress 重新安装竞态条件（Race Condition）缺陷，使攻击者能在未授权条件下凭空注入管理员高权账户。

竞态漏洞是典型的「逻辑漏洞」：不是某个函数写错了，而是两个操作的时序假设不成立。这类漏洞的特点是人眼很难在代码审计里发现（因为要看的是并发时序，不是单行代码），但非常适合做系统化的假设检验——而假设检验正是大模型相对擅长的模式。

这个案例说明了一件事：AI 发现 0day 的路径和人类不一样。人类靠经验直觉（哪里容易写错），AI 靠遍历假设（哪里可能不成立）。两条路径的产出是互补的，这意味着 0day 的发现速率会整体上升。

四、四个团伙一张表：攻击者的三种组织形态

代号	性质	做的事	关键参数
GTG-50014	法语区，疑 ShinyHunters 关联	APK 批量逆向与密钥收割	10 台 EC2、180 万 APK
GTG-20006	国家级，关联 APT29 / Midnight Blizzard	木马被查杀后 AI 自愈重构	闭环、实时
GTG-50020	黑产经济组织	针对 AI 提供商盗模型与 API Key	4 天、30 余家
GTG-50029	多智能体单兵	挖 CMS 逻辑漏洞 + 自动化社工窃密网络	多 Agent 并行

把四种形态按「门槛」排一下：

GTG-50014 代表能力门槛下降：不需要深度逆向能力，需要算力预算和流程设计能力。
GTG-20006 代表国家级能力的提速：本来就能做的事，现在做得更快、更难被特征化。
GTG-50020 代表攻击目标转向 AI 资产本身：模型权重和商业 API Key 成了新战利品。
GTG-50029 代表组织门槛下降：一个人 + 多智能体 ≈ 一个攻击小组。

第四点最值得防御者警惕。过去我们习惯用「团伙规模」估算威胁等级——几个人、什么背景、有什么基础设施。当「单兵 + 多智能体」能达到小组级产出，威胁情报里的「组织画像」方法和响应速度都要重估。

五、为什么「混淆不够好但没人会专门看」失效了

这是整份报告里，对普通开发团队冲击最大的一条。

过去很多团队对客户端密钥的态度是半自觉的：知道硬编码不对，但「反正打包混淆过了，逆向成本那么高，谁会专门翻我的包」。

这个判断在当时是成立的，因为它依赖两个前提：

逆向需要人力：一个人一天能审几个包，成本实打实。
扫描结果需要人判读：正则扫出来的噪声要人工筛，量一大就做不动。

现在这两个前提同时消失了：反编译是自动的，判读是模型做的，两者都能并发。于是成本从「人力成本」变成「算力成本」，而算力是可以租的。

用一个简单的不等式表达这个变化：

1 2	过去：审计成本（人力 × 样本数） > 密钥价值 → 安全现在：审计成本（算力 × 样本数） < 密钥价值 → 不安全

样本数不变的情况下，单位成本下降了几个数量级。这意味着你不需要「特别显眼」才会被盯上——你只需要在那 180 万个包里。

一个推论：暴露面不是「有没有」，是「多久」

还有一个更难受的推论：历史版本也算在内。

攻击者抓的是「多个主流和第三方市场」的包，包括历史版本。也就是说，即使你在 v3.0 修掉了硬编码密钥，v1.0 到 v2.9 的包仍然在市场里可下载，仍然会被解包、被提取。

这直接推翻了一个常见的处置方式：「下个版本改掉，让用户升级。”

密钥一旦进过客户端，就必须当作已泄露来轮换——不管它当前在哪个版本里，也不管它现在还能不能用。

六、防御落点：四层清单

报告给的防御建议是三条（移动端禁止硬编码、CI/CD 加 Secret 门禁、转向行为检测）。这里扩展成一份可执行的四层清单。

第一层：客户端——别让密钥进来

必须做的：

客户端不存放任何长期有效的云密钥。所有需要签名/鉴权的操作，走后端代理：客户端向自己的服务端请求一个短时效、单用途的签名或令牌，由服务端持有真密钥。
第三方 SDK 的密钥（地图、推送、支付）用平台侧限制：Referer 限制、包名 + 签名指纹绑定、调用配额告警。
配置与代码分离，配置文件不进仓库；构建产物做一次出包前的密钥扫描（有密钥就构建失败，不是告警）。

容易漏的：

测试配置、本地 properties、CI 的环境变量快照——这些经常以「临时」的名义进了包。
native 库（.so）里的字符串。只扫 Java/Kotlin 层会漏掉一半。
资源文件（assets、raw）里的配置。
构建缓存与历史 tag。修了主干不算修完。

第二层：CI/CD——让密钥进不来

提交阶段做静态机密扫描（pre-commit + 服务端 hook），命中即阻断合并，不是只提示。
构建阶段再扫一次产物（源码干净不代表产物干净，打包过程可能引入）。
启用密钥托管与自动轮换：密钥存在密钥管理服务里，不出现在任何配置文件中。
开启云厂商的凭据泄露检测（多数云厂商已提供：发现你的 AK 出现在公开渠道会告警）。

第三层：运行时——假设它已经泄露了

既然「进去过」就等于「泄露过」，那就按泄露处理：

轮换优先于排查。先换掉，再查影响面，顺序不能反。
检查云审计日志里该密钥的历史调用（时间点、来源 IP、操作类型），判断有没有被用过。
给所有密钥设最小权限（只读就别给写、一个桶就别给全账号）。这条决定了泄露后的爆炸半径。
关键操作开二次确认与异常地域告警。

第四层：检测——换成看行为

对应第二节的自愈型恶意代码：

建进程血缘基线，告警父子进程异常组合。
建出站连接基线，告警新域名、非常规端口、非常规时序（尤其深夜批量外传）。
保留内存与命令行的采集能力（不只看文件落盘）。
把「告警」和「阻断」分开设计：告警给分析，阻断要能实时生效。

七、如果只有两天，先做这五件事

把上面四层清单压缩成一个最小可行的整改路线：

第 1 天上午：确认暴露面

列出所有对外发布的客户端产物（各渠道上架包 + 历史版本 + SDK/SDK Demo）。
对每一个跑一次密钥扫描（源码、产物、native 层、资源文件四层都要扫）。
产出一张表：哪个包、哪个版本、含什么类型的凭据、还能不能用。

第 1 天下午：先轮换，再排查

上表里所有仍然有效的凭据，立即轮换。这一步不依赖任何排查结论，不要等。
顺序不能反：先换掉，再查有没有被用过。因为「查清楚」需要时间，而轮换只需要几分钟。

第 2 天上午：堵住入口

CI/CD 加提交阶段 + 构建阶段两道 Secret 门禁，命中即阻断。
出包流程加一次产物扫描（源码干净 ≠ 产物干净）。
把剩余需要签名/鉴权的功能，改成后端代理 + 短时效令牌。

第 2 天下午：确认被用过没有

查云审计日志：轮换前那批密钥的历史调用记录（时间、来源 IP、操作类型、访问的资源）。
重点看三件事：非常规地域、非常规时间、批量读操作。
如果发现异常调用，按数据泄露事件走处置流程，不要当成配置问题处理。

持续：把检测换成看行为

建进程血缘基线与出站连接基线。
保留内存与命令行采集能力。
告警与阻断分开设计。

关于「先轮换再排查」的补充说明

这个顺序很多人会觉得别扭——「都没查清楚就换，会不会打乱业务？」

要理解这个顺序，需要先接受一个前提：硬编码进过客户端的密钥，在概率上已经泄露。在这个前提下：

轮换的成本是固定的、可控的、几分钟的；
不轮换的风险是未知的、持续的、随时可能变成事件的。

而且轮换本身不影响排查——旧密钥的审计日志仍然存在，你完全可以在轮换之后从容地查它有没有被用过。唯一不能做的是「先查清楚再决定要不要换」，因为在查的过程中，风险敞口一直是开着的。

八、和 OWASP 智能体清单放在一起看

今天写的 OWASP 2026 智能体十大安全风险是防御侧的清单，这份 Anthropic 报告是攻击侧的实测。两组材料有直接对应关系：

OWASP 条目	本报告中的对应现象
ASI02 工具滥用与利用	攻击者把 TruffleHog、反编译器、云 API 当作合法工具链编排使用
ASI05 意外代码执行	AI 实时重编译并分发新的植入物
ASI06 内存与上下文投毒	攻击流水线的中间产物（资产清单、凭据库）在环节间传递
ASI07 不安全的智能体间通信	多智能体分工中的任务交接与指令传递
ASI08 级联故障	一个 Agent 的产出直接驱动下游 Agent，错误会放大
ASI10 失控智能体	无人干预下持续攻击数小时至数天

最有意思的是 ASI02 的对应：攻击者用的正是「合法工具 + 合法权限」的组合。他们没有绕过任何权限系统，每一步调用都是被允许的——TruffleHog 是开源工具，Claude API 是付费服务的正常调用，抓取公开市场的 APK 不违反任何规定。

问题不出在单个动作上，出在动作的组合上。 这和防御侧面临的困境完全一致：单点看都合规，异常只存在于序列里。

九、三个常见疑问

疑问一：「我们用的是付费混淆/加固，还不够吗？」

加固提高的是逆向的时间成本，不提高判读的成本。而在这条流水线里，判读是由模型完成的——加固后的代码对模型来说只是「可读性差一点」，不是「不可读」。更实际的问题是：加固无法阻止反编译本身，只能增加理解难度。而 180 万个包里，只要有一小部分被读懂就够本了。

加固仍然值得做（它抬高的是门槛），但它不能再被当作「密钥可以放进客户端」的理由。

疑问二：「我们的密钥权限很小，泄露了也无所谓吧？」

这句「无所谓」成立与否，取决于权限最小到什么程度。判断标准可以用三个问题：

这个密钥能不能列出资源（哪怕读不了内容，列目录本身就是情报）；
这个密钥能不能被用于横向（能不能拿它换到别的权限）；
这个密钥有没有配额限制（无配额的密钥即使权限小，也可能被刷出巨额账单）。

三个问题里只要有一个答案是「能」，就不算「无所谓」。

疑问三：「攻击者拿到这些密钥之后，一般会怎么用？」

从流水线本身就能推断出变现路径：

云 AccessKey：先看有没有高价值资源（存储桶、数据库快照），有就直接拖；没有就起机器（挖矿、发垃圾邮件、做跳板），成本由受害者承担。
数据库连接串：批量导出，进入数据黑市。
支付网关私钥：伪造回调、篡改订单状态，比直接刷卡的隐蔽性高得多。
内部服务 Token：横向移动，进入内网。

注意第一类：云密钥泄露最常见的后果不是数据被偷，是资源被占用。很多人发现账单异常时，才第一次意识到密钥泄露过。

十、一句话总结

这份 154 页报告真正想说的不是「AI 很危险」，而是一个更冷的事实：

攻击的瓶颈已经从「技术能力」转移到了「组织与算力」。

当瓶颈是技术能力时，防御方有优势——因为防守可以复用行业积累的最佳实践。当瓶颈是算力时，这个优势就没了，因为算力对攻守双方是同一个市场价格。

所以应对方式也要换：不要再指望「我的实现足够晦涩所以没人看」，而要默认**「只要上线就会被扫到」，然后把防线建在密钥不放客户端、泄露即轮换、检测看行为**这三件事上。

顺手可做的一件事：如果你手上维护着任何移动端 App，今天就可以做一次「历史版本 + native 层 + 资源文件」的密钥扫描。180 万个包里有你一个，概率上并不低。

素材来源

CN-SEC 中文网（2026-09-13，转载自微信公众号「安全圈」）：黑客把 Claude 玩疯了：全自动扒光 180 万安卓 App 密钥机密——Anthropic 154 页威胁情报报告要点，本文所有团伙代号、参数与处置时间均以此为准
Anthropic 报告要点：GTG-50014（10 台 EC2 / 180 万 APK / TruffleHog + Claude / Telegram 回传）、GTG-20006（关联 Midnight Blizzard = APT29，木马被静态签名阻断后回传特征 → Claude 重构重编译）、GTG-50020（4 天 / 30 余家 AI 提供商 / 盗取未公开模型与 API Key）、GTG-50029（多智能体挖 CMS 漏洞 + 自动化社工窃密网络）、WordPress 重装竞态 0day