微软威胁情报称攻击者利用能自动调用工具和调整操作的AI智能体，快速把公开代码库中的凭据滥用为对云资源的入侵；在至少一例观察中，从GitHub发现密钥到从Azure Key Vault外传数据仅用了五分钟。报告强调删除仓库中的秘密并不足以阻断访问，建议立即轮换凭据、回查使用记录并收窄应用权限。
微软在2026年11月5日公布的一项威胁研究中称，攻击者正借助能够调用工具、分析结果并继续操作的AI智能体，把公开代码库中的凭据泄露迅速转化为云端入侵。在至少一个观察案例中，从在GitHub搜索应用客户端秘密，到从Azure Key Vault外传数据，整个过程只用了五分钟。
这个数字来自微软威胁情报团队的实际观察，不是独立复测结果，也不是所有同类攻击的平均耗时。它揭示的风险是：一段误传到公开仓库的认证信息，可能不只是一次代码管理失误，而是通向企业云资源、文件和更多凭据的入口。
这也不是11月5日当天才开始的攻击。微软表示，公开仓库扫描活动自2026年8月起就已出现；使用有效应用凭据的部分后续活动，最早可追溯至10月28日。11月5日是这份研究的公开日期，应与攻击发生时间分开理解。
一把泄露的“钥匙”，为何能打开更多资源
在公开仓库寻找密钥、令牌和密码并非新手法。开发者为方便部署，可能把应用客户端秘密、连接字符串或API密钥写入配置文件和脚本，随后连同代码一起提交。攻击者过去也会搜索这些材料，但寻找目标、判断凭据用途和开展后续操作，往往需要人工衔接。
微软称，包括ARTEX在内的智能体渗透测试工具，能把搜索、结果分析和后续行动接成连续流程，减少攻击者在各环节手动操作的需要。其观察到的GitHub查询，通常会组合目标组织名称、秘密相关关键词，以及云服务或AI服务提供商名称。
真正决定损害范围的，是泄露凭据背后的应用身份及其权限。微软Entra ID中的“服务主体”，可理解为应用在特定租户内使用的身份：应用通过它进行程序化认证，访问已经获授权的资源。攻击者拿到有效凭据后，便可能冒用这一身份，而不必先取得员工的交互式登录账户。
微软记录到的后续操作包括枚举云订阅、资源组、权限和AI模型部署，以及寻找存储账户密钥、应用设置、连接字符串等。在部分受影响环境中，被滥用的应用还访问了SharePoint和OneDrive，出现文件下载和邮件项目访问。多租户应用的凭据若在供应商一侧失陷，风险还可能延伸至已授权该应用的下游客户租户。
这些行为不意味着一份凭据天然拥有整个云环境的控制权。可访问哪些资源、能否读取秘密或执行操作，仍取决于应用原先获得的权限及相关访问控制。但如果一个应用既能读取秘密库，又能访问其他业务系统，一次凭据泄露就可能产生连锁影响。
五分钟案例之外，AI参与程度仍需看证据
微软还披露了与“适应性排错”一致的请求序列：部分云API请求先因版本不匹配等原因失败，随后更换参数并成功返回。例如，一组针对Key Vault资源的请求失败后，约28秒便开始使用合适版本重新请求，并收到HTTP 200响应。
这一现象支持自动化工具能够根据反馈调整操作的判断，但不能单凭请求序列，就证明整条攻击链完全没有人工参与。HTTP 200也只是对应请求成功的证据，不能把每一次成功响应都直接解释为数据外泄；五分钟案例中的数据外传，是微软另外明确报告的观察结果。
另一个重要限制来自微软文中链接的安全公司Todyl的调查。该公司在11月3日发布、11月4日更新的报告中，描述了使用被盗应用凭据访问Entra ID、Azure和Microsoft 365的活动，其中包含与微软报告重合的网络指标。
但Todyl明确表示，它没有将所见活动关联到某个具体智能体工作流或进攻框架，其遥测也没有显示AI模型正在指挥操作，因此对AI辅助这一可能性的判断仅为低置信度。该公司还指出，部分初始秘密的使用历史更像来自文件存储或运行中的后端，最初取得凭据的方式仍不清楚。
因此，两份报告能够相互补充应用身份被滥用、攻击快速向其他资源推进的风险，却不能合并成“所有凭据都来自GitHub、所有操作都由AI自主完成”的结论。微软观察到的仓库扫描、五分钟案例与不同客户中的后续活动，也不应被简单拼接为每个受害者都经历过的同一条路径。
这与此前微软披露的Storm-0940及ConnectWise供应链攻击存在技术背景上的联系，但不是同一项新披露。那篇报道聚焦供应商应用身份与下游租户信任；本次新增重点是公开仓库秘密扫描及其向云端资源滥用的快速推进。不能据此把本篇涉及的全部活动归因于Storm-0940；Todyl也将其调查的活动评估为与10月的ConnectWise事件无关。
删掉代码里的密钥，不等于终止访问
两份研究都把处置重点放在身份和凭据，而不是只封禁某个工具或网络地址。微软强调，公开过的凭据应被视为已经失陷：删除仓库中的文本，不会令凭据失效，也无法收回可能留在提交历史、缓存或其他系统中的副本。
企业因此需要立即撤销或轮换暴露的凭据，并回查其历史使用。调查范围也不能停留在最初泄露的那把“钥匙”：如果受影响应用能读取某个Key Vault，微软建议轮换其中存放的秘密，以及已访问文档中的凭据，并检查攻击者是否添加了新的客户端秘密、证书或联合身份凭据。
令牌则是另一层问题。微软提醒，已经签发的令牌可能在到期前继续有效。这意味着更换客户端秘密，并不等于所有已建立的访问能力同时消失；安全团队仍需结合受影响身份、会话和资源访问记录，判断是否需要禁用服务主体或采取其他隔离措施。
检测也应覆盖失败尝试与成功操作之间的联系。微软建议关联服务主体登录、Azure活动、Key Vault和存储诊断、Azure DevOps以及Microsoft 365审计日志，留意一个来源短时间尝试多个应用，或同一应用连续请求多个云服务令牌的模式。只盯着成功登录，可能漏掉攻击者反复尝试失效凭据后终于获得访问的过程。
针对已知IP的阻断可以用于应急，但不应代替行为分析。微软指出，攻击者能够更换IP地址和客户端标识；用于工作负载身份的条件访问策略也有许可及应用范围限制，不能被理解为覆盖所有身份和所有云服务的统一开关。
长期防线是减少秘密，并收窄身份权限
在开发流程中，GitHub的秘密扫描文档说明，扫描会检查各分支的完整Git历史，并在发现泄露后发出告警；公开仓库自动免费扫描。企业还可按条件启用公共监控，发现企业成员在其他公开仓库中泄露的秘密。扫描能帮助发现问题，但告警仍需要及时处置，不能替代撤销凭据。
微软的应用认证迁移指南则建议，在支持的场景中使用托管身份或工作负载身份联合，减少应用代码中长期保存客户端秘密的需要。短期无法迁移的应用，仍需轮换秘密并妥善存储。
不过，减少代码里的秘密，并不意味着身份从此没有风险。应用依然需要权限，身份提供方和运行环境仍需保护，秘密库本身也不能向不必要的应用敞开。最小权限、应用清单、凭据生命周期管理和完整审计，是限制连锁损害的基础。
五分钟案例的警示，不是每次凭据泄露都会在五分钟内变成数据失窃，而是防守方不能再假设，发现公开秘密后总有充足时间等待人工处理。AI工具可能加快旧有攻击路径；真正需要切断的，是公开凭据、过宽权限与可连续访问的敏感资源之间的连接。