devgo.cn想象一下这样的场景：你公司的某个普通员工账号被重置了密码，仅此而已。没有暴力破解，没有零日漏洞，甚至没有恶意软件。但几个小时后，攻击者已经拿到了你 Kubernetes 集群的 kubeconfig 文件，并且能访问超过 50 个下游资源。这不是科幻小说，而是微软在 2026 年 9 月披露的真实事件：一个被追踪为 Storm-3068 的黑客组织，通过滥用自助密码重置（SSPR，即用户自己重置密码的功能）攻陷了一个 Azure AD 身份，然后利用 Azure DevOps 管道（CI/CD 自动化流程）窃取了 Kubernetes 集群的凭证，最终偷走了七个 kubeconfig 文件（Kubernetes 客户端连接集群所需的配置文件），获得了大量资源的访问权。
这起事件最值得警惕的地方在于：除了最初的 SSPR 滥用外，攻击链的每一步用的都是合法功能——Intune 设备注册（微软的设备管理平台）、管道编辑、服务连接（Azure DevOps 中让管道访问外部资源的授权机制）。没有恶意软件签名可查，传统的端点防护完全失效。防御必须建立在权限边界和异常检测上，而不是靠杀毒软件。
攻击链从一次密码重置开始。攻击者先是获得了某目标账号的恢复信息（可能是通过钓鱼或撞库），然后完成了自助密码重置。重置后，攻击者立刻注册了攻击者控制的设备，并把它加入了 Intune，让这台设备在租户中获得可信状态。紧接着，攻击者注册了自己的 MFA（多因素认证）方法，并删除了合法用户的 MFA 方法，这样就从一次性凭证窃取变成了持续的、可重复认证的账号控制。
账号完全在手后，攻击者开始用正常的已认证 API 调用侦察 Azure DevOps 的仓库、管道、部署环境和服务连接。然后他们在已有管道中创建或修改了任务，让管道以 Kubernetes 代理步骤运行，利用管道自身的服务连接权限去执行 `kubectl config view --raw`（查看原始 kubeconfig 内容的命令），把结果提交到仓库里。一个恶意管道就被授权接触到 50 多个资源。为了持久化，攻击者又修改管道部署了 Atera（一个合法的远程监控软件，这里被滥用作远程访问）和 Chisel（一个 TCP/UDP 隧道工具，可以用来把 Kubernetes API 流量代理回攻击者的基础设施）。
为什么这个攻击比普通钓鱼报告更值得重视？因为从初始的 SSPR 之后，每一步用的都是正常产品功能，没有恶意软件特征可捕捉。防御方必须靠权限边界和异常检测，而不是靠终端保护。
针对这条攻击链，微软给出了五条修复措施，每一条都卡在关键节点上。
**修复 1：锁死自助密码重置。** 入口点是 SSPR 在没有设备或位置上下文的情况下就完成了。要求 SSPR 成功之前必须有可信信号：在 Entra 管理中心的条件访问策略里新建一条策略，要求所有用户的设备必须是合规的，或者必须是混合 Azure AD 加入的设备。注意目标资源要选“用户流程”中的“自助密码重置”。如果没法要求所有设备合规，至少要先覆盖管理员角色和服务账号所有者——这些身份一旦被攻破，攻击者就能接触 Azure DevOps 和生产基础设施。
**修复 2：对 MFA 方法变更告警，而不只是登录告警。** Storm-3068 的持久化步骤——删除合法 MFA 方法并注册新方法——是整个链条中信号最强、噪音最低的检测点。大多数租户记录了这类事件但不会告警。下面这段 Sentinel/Log Analytics 查询可以帮你找出这种自助变更：
```
// Microsoft Sentinel / Log Analytics
| where TimeGenerated > ago(1d)
| where OperationName in ("User registered security info", "User deleted security info", "Admin deleted security info")
| extend TargetUser = tostring(TargetResources[0].userPrincipalName)
| extend ActorUser = tostring(InitiatedBy.user.userPrincipalName)
| where TargetUser == ActorUser // 自助变更，非管理员发起
| project TimeGenerated, OperationName, TargetUser, Result, IPAddress = tostring(parse_json(tostring(AdditionalDetails))[0].value)
```
再配一条规则：当 MFA 方法删除后几分钟内，又有新方法从不同于该账号历史基线的 IP 或设备指纹注册时，就要触发告警——这个序列正是把一次性的 SSPR 攻陷变成长期访问权的关键。
**修复 3：审计并收缩 Azure DevOps 服务连接的作用域。** 管道攻击能成功，很大程度上是因为服务连接经常被授予比单个管道需求更宽的权限。列出每个管道到底能触碰什么：用 `az devops service-endpoint list` 和 `az devops service-endpoint show` 命令查询项目里所有服务连接的名称、类型、认证方案以及是否授权给所有管道。最关键要加固的几点：
- 在所有 Kubernetes/集群服务连接上禁用“允许所有管道访问”的选项，改为按管道显式授权。
- 把每个连接的作用域限制到单个集群/命名空间，而不是订阅级或多集群的服务主体。一个部署到暂存环境的管道不应该拿着能读取生产 kubeconfig 的凭证。
- 要求管道 YAML 必须来自受保护分支（在审批和检查中启用分支控制），这样就算攻击者有仓库写权限，也无法重新定义可信管道的行为。
**修复 4：从源头轮换和限制 Kubernetes 凭证。** 即使做了管道作用域收缩，也要假设任何经过 CI/CD 系统的 kubeconfig 都应该被视为短期凭证，而不是长期存续的。优先使用工作负载身份联合（workload identity federation）而不是长期 kubeconfig 密钥——启用 OIDC 签发器和工作负载身份。另外，审计现有的服务账号令牌是否设置过长有效期：`kubectl get secrets --all-namespaces -o json | jq -r '.items[] | select(.type=="kubernetes.io/service-account-token") | .metadata.namespace + "/" + .metadata.name'`。Kubernetes 1.24 之后默认使用投影服务账号令牌，一小时内就过期——通过恶意管道偷到的 kubeconfig，对一个长期静态凭证来说价值会大打折扣。如果你的集群还在为 CI/CD 签发长期服务账号密钥，迁离这个机制是首要任务。
**修复 5：追踪持久化工具。** Atera 和 Chisel 都是合法工具，被滥用了，所以基于签名的杀毒软件不会标记它们。要直接针对它们的网络和进程指纹做狩猎：检测构建代理上非浏览器的出站连接，凡是命中 Atera 域名，或者发起进程不是 chrome/msedge/svchost 且远程端口非常规 443/80 的 TCP 连接，都要警惕。任何在自托管 Azure DevOps 代理或构建运行器上出现的这种连接都该立即隔离——Atera 和 Chisel 在 CI/CD 执行环境里没有正当理由存在。
如果租户里发现了这条攻击链的痕迹，微软的应急响应清单按顺序有五步，第一步是禁用被攻陷的账号。后续包括撤销攻击者注册的设备、重置所有相关密钥、审计管道历史、以及删除恶意管道和持久化工具。
最让我意外的是，整条攻击链没有用到任何新漏洞，全是“合法功能滥用”。这意味着防御思路必须转变：不要只盯着终端检测，要盯着身份变更的异常序列，盯着权限的“最小够用”原则。你可以在自己公司里立刻做三件事：给 SSPR 加设备合规要求、对 MFA 方法变更设告警、把 Azure DevOps 服务连接的“所有管道可访问”开关全关掉。这三步能截断 90% 的同类路径。另外，任何用了长期 kubeconfig 的 CI/CD 项目，都应该尽快迁移到短期投射令牌或工作负载身份联合——这是把凭证被偷的损失从“全集群沦陷”降到“一小时内过期”的关键。
内容与图片版权归原作者所有 · 原文: https://dev.to/iamdevbox/storm-3068-how-sspr-abuse-turns-one-azure-ad-account-into-kubernetes-credential-theft-41h0