他们使用 Microsoft Graph API——这是微软云平台用于访问用户、应用、组和权限数据的官方接口——对目录进行大规模枚举。
微软观察到攻击者使用 自定义 Python 脚本 自动化发送 Graph API 请求,以批量获取:
这些查询还会根据 用户名模式和角色属性 搜索可能拥有高权限的账户,从而为后续权限提升寻找路径。
在攻击过程中,一个关键步骤是 滥用 Self‑Service Password Reset(SSPR) 功能。
SSPR 原本是 Microsoft Entra ID 提供的账户恢复机制,让用户在忘记密码时通过验证方式自行重置密码。
但在 Storm‑2949 事件中,攻击者利用该恢复流程,在已控制账户的基础上建立 更稳定、更持久的访问权限。
由于这种操作属于合法功能,日志中的行为往往看起来像正常用户活动,从而降低了被安全系统发现的概率。
完成侦察后,攻击者没有利用传统系统漏洞,而是直接通过 云控制平面权限机制进行权限提升。
关键工具包括:
通过识别拥有高权限的账户、角色或服务主体,攻击者逐步扩大访问范围,使其可以管理更多 Azure 资源。
权限提升后,攻击者进入多个关键云服务,其中包括:
这些资源通常保存 应用密钥、凭据、业务数据和生产环境工作负载,因此在云入侵中属于高价值目标。
这也说明,在权限控制不严格的环境中,一个被盗账号可能迅速演变成对整个云基础设施的访问。
Storm‑2949 的另一特点是 几乎没有部署恶意软件。
攻击者主要使用 Azure 原生管理工具,例如:
这些工具本来就是系统管理员日常使用的功能,因此在日志中往往与正常运维操作难以区分。
这种“以合法工具完成攻击”的方式,使得传统依赖恶意文件或恶意进程检测的安全系统很难发现异常。
微软指出,攻击者在入侵环境中 持续多天进行数据外泄(data exfiltration)。
这意味着攻击者在较长时间内保持了稳定访问权限,并能够访问多个云服务的数据资源。
Storm‑2949 反映了云安全领域的一个明显趋势:
攻击者越来越多地依赖 身份系统与合法 API,而不是传统恶意软件。
这类攻击难以发现的原因包括:
当攻击完全发生在可信云服务内部时,传统终端安全工具往往几乎看不到明显异常。
微软建议组织重点加强 身份安全与云控制平面监控,以降低类似攻击风险。
关键措施包括:
加强身份保护
确保单个账号被攻陷不会导致整个租户沦陷。
审查 SSPR 配置
特别是高权限账户,避免恢复流程被攻击者滥用。
强制多因素认证(MFA)和条件访问
减少被盗凭据的价值。
监控 Microsoft Graph API 活动
识别异常的目录枚举或自动化查询行为。
审计 Azure RBAC 权限
确保遵循最小权限原则。
监控管理工具使用情况
例如 VMAccess、Run Command 和 PowerShell 的异常调用。
加强关键资源访问控制
对 Key Vault、数据库和生产虚拟机实施严格访问和日志监控。
Storm‑2949 事件再次证明:
在现代云环境中,“身份”已经成为最重要的攻击面。
一旦攻击者控制账户,他们可以通过 API、权限系统和管理工具在云环境中移动,而完全不需要部署恶意软件。
因此,企业的云安全策略也必须从传统的“终端与恶意代码检测”转向 身份行为、API使用、权限变化和控制平面活动的全面监控。