微软威胁情报在 11 月 5 日发布报告，披露一个名为 ARTEX 的智能体化攻击框架正在批量扫描 GitHub 公开仓库寻找泄露的凭据，并把找到的密钥直接用于入侵云环境。报告里最刺眼的一个数字是：在一次实际观察中，AI 智能体从在 GitHub 搜到某客户的客户端密钥，到从该组织的 Azure Key Vault 把数据取走，只用了 5 分钟。
这件事的重点不是「又一个密钥泄露案例」，而是防守方长期依赖的时间窗消失了。过去密钥泄露后，安全团队通常有几小时到几天去轮换，因为从发现仓库到读懂代码、测试凭据、串联下一步，全都需要人在键盘前。ARTEX 把这几个环节压缩成机器速度，同时取消了对人的依赖。
事件概述
微软从 2026 年 8 月起观察到该框架在向 GitHub 提交大批量查询。查询词的构造方式很机械：目标组织名 + 密钥类关键词（secret、token、key）+ 云服务关键词 + 其他 AI 服务商关键词。捞到的东西包括应用客户端密钥、存储账户密钥、AI 推理服务的 API Key，多数是从脚本、配置文件、源码里直接提交上去的。
从 10 月 28 日起，微软观察到这些凭据被用于对受感染组织的 Entra ID 租户发起服务主体登录，涉及多个应用程序 ID、数十个关联应用、多个租户。报告同时提到，有些场景下被攻陷的是供应商自有的多租户应用，泄露的凭据在源头被拿走，随后被用来访问大量下游客户租户。
技术细节
完整链条分五段。
一、找到密钥。智能体批量搜公开仓库，不只看文件内容，还看提交历史。
二、换到身份。用泄露的客户端密钥向 Entra ID 换取令牌，登录为服务主体。服务主体是应用用来做非交互认证的身份，天然绕过面向人类用户的 MFA 与部分条件访问策略，这是整条链能跑通的前提。
三、摸清家底。拿令牌枚举订阅、资源组、权限、AI 模型部署和服务配置，同时向 Microsoft Graph 发大批搜索类请求。
四、取走凭据。目标是能开更多门的钥匙：Key Vault 里的密钥、存储账户密钥、App Service 设置与发布凭据、连接字符串、AKS 用户凭据，以及 AI/机器学习连接和数据存储的配置。拿到 OAuth 应用后，还会在 Azure DevOps 里再搜一轮密钥。
五、取走数据并落地。下载 SharePoint 与 OneDrive 文件、读取邮箱条目，并用 Azure VM 的 Run Command 在虚机内执行脚本——虚机一动，未保护的本地凭据、工作负载身份、持久化和横向移动就都打开了。
报告里有一段很能说明「智能体」特性的细节：一批针对 Key Vault 的 ARM 请求返回 HTTP 400，原因是把 Key Vault 数据平面的 API 版本用在了 ARM 控制平面上；大约 28 秒后，同一批路径改用 ARM 的 2023-07-01 重放，返回 200。类似的自我纠错还出现在 Azure SQL 防火墙规则（约 60 秒）和 Application Insights 查询（约 80 秒）上，改动只是 URL 里的 api-version 参数。人会犯同样的错，但不会在多个服务上错得这么一致。
工具层面不刻意隐藏：Nmap、curl、wget、Playwright 驱动的无头 Chromium，流量带默认 User-Agent。所以单靠封 UA 拦不住，微软报告里也明说了这点。
影响评估
微软没有公布受影响组织数量，只说是「多个租户」和「部分受影响客户」。已公布的 IOC 有四个：
199.19.77[.]84：主要的服务主体登录来源199.19.77[.]18：次要登录来源，为 Tor 出口节点，可能混有其他无关活动65.87.223[.]26：UA 中内嵌 shell 命令，有明显漏洞利用迹象，并尝试获取 App Service 认证令牌157.22.126[.]128：针对受害者部署的 Azure AI 工作负载做侦察
这不是孤例：微软 10 月 21 日刚发过 Storm-0940 用 ARTEX 打 ConnectWise 供应链的报告，另有厂商记录该框架在 19 个国家、200 多个组织上的活动。
对国内做跨境电商、SaaS、独立站的企业，风险点非常具体：开发者把测试用的云密钥硬编码在开源脚本里推到 GitHub，是极常见的操作。这类仓库往往没有敏感信息扫描，也没人负责轮换。
修复建议
按紧急程度排序，前两条今天就能做。
# 1. 先查有没有被登录过（Entra 登录日志 / Sentinel）
# 重点错误码：AADSTS7000215 无效密钥，AADSTS7000222 过期密钥
# 失败后紧跟成功 = 说明对方手上有你的应用凭据，按紧急事件处理
# 2. 查 Key Vault 访问异常
# Defender for Key Vault 告警：Unusual operation pattern
# High volume of operations / Suspicious secret listing and query- 把泄露当成已失陷。删除提交没有用，副本还留在编辑历史、缓存、归档和日志里。正确动作只有轮换。
- 撤销整条信任链。受影响应用要移除全部客户端密钥、证书和联合凭据（包括攻击者自己加的），必要时禁用服务主体；已签发的令牌在过期前仍然有效，所以还要撤销 Entra 会话、Azure DevOps PAT 和 SSH 密钥。
- 在条件访问里封
199.19.77[.]84/32，封精确 IP 而不是整个 ASN；注意工作负载身份策略需要 Workload ID Premium 许可，且只覆盖单租户应用。 - 换掉长期凭据。迁移到托管标识，按实际需要裁权限；把「用户可注册应用」关掉，收紧 Application Developer 角色。
- 上欺骗性防御。微软在测试中验证，蜜罐、诱饵、tarpit 和「假胜利」能有效把自主智能体引离真实资产——tarpit 消耗它的时间和预算，假胜利让它误以为任务完成而停下。这一条对没有预算买高级检测的中小团队尤其划算。
顺手做一次全量仓库扫描（GitHub Advanced Security 或开源方案都行），别只扫默认分支。