Storm-3168 Azure攻击：发生了什么

微软披露了一场其追踪代号为Storm-3168的攻击活动，攻击者在此次活动中入侵了Azure服务主体（即应用程序和自动化服务用于向Azure进行身份验证的身份对象），并利用该访问权限删除了存储账户。根据微软自己的描述，该活动看起来不像是一次打砸抢式的数据窃取行动，更像是勒索软件的前期准备或主动破坏。值得注意的是，微软尚未确认此次特定事件中发生了勒索或数据外泄，尽管其手法类似于勒索软件攻击的早期阶段。

这一区别很重要。删除存储账户可能与加密存储账户造成同等严重的破坏，尤其是在没有备份的情况下，但这与攻击者悄悄复制文件后消失是两种不同的威胁模型。对于依赖Azure的组织而言，核心教训是：攻击者不需要窃取数据就能造成严重损害。获得正确身份的掌控权就足够了。

为什么服务主体是首要目标

服务主体容易被忽视，因为它们不是人类用户账户。它们是让一个Azure服务或应用程序与另一个进行通信的凭据，通常拥有较高权限且日常监管极少。这使其成为攻击者的理想目标：攻陷一个服务主体，你可能就继承了對存储、数据库或基础设施的广泛访问权限，而无需触碰任何人的登录界面。

这是安全研究人员在微软云生态系统中一直标记的更广泛模式的一部分。攻击者越来越多地针对幕后存在的凭据和信任关系，而非直接瞄准终端用户。这与Storm-3032针对BYOD设备获取Microsoft 365访问权限的语音钓鱼行动等攻击活动的逻辑类似——其目标不是当场诱骗某人交出密码，而是找到身份链条中最薄弱的环节，借此进入更大的环境。

相关警告：隐藏在数据库中的勒索信

虽然Storm-3168 Azure事件（就目前记录而言）尚未升级为勒索，但安全公司Sysdig报告的另一起案例显示了这类访问权限若不加以控制可能导致何种后果。在该事件中（由SOCFortress进行了总结），一名攻击者获得了对数据库环境的访问权限，加密了数据、删除了数据库表，并留下了勒索要求。研究人员发现，攻击者创建了一个名为README_RANSOM的表，其中包含一个比特币钱包地址和一个用于协商付款的Proton Mail联系方式。

微软的Storm-3168活动没有达到那个阶段，但两者的相似之处具有启发意义。两起案件的开端相同：攻击者获取了本应受到严格控制的凭据或访问权限，并利用这一立足点威胁存储数据的完整性。无论最终结果是删除、加密还是勒索信，根本原因都一样。有人进入了一个本不应被触及的账户。

这对你意味着什么

如果你的组织或个人项目依赖Azure或类似的云平台，这次攻击活动提醒我们：这些攻击的胜负取决于身份安全，而不仅仅是边界防御。无论你是在管理企业基础设施还是小型企业的云存储，以下几个实用步骤都适用：

  • 定期审计服务主体权限。 许多组织在设置自动化时授予广泛权限，之后再也不复查。应将权限缩减到仅所需范围。
  • 在所有支持的地方启用多因素身份验证，包括管理账户和服务账户，而不仅仅是标准用户登录。
  • 审查访问日志中异常的认证模式，尤其是与服务账户相关的来自意外位置或异常时间的登录。
  • 在主要环境之外独立备份存储账户，这样删除或加密就不会意味着永久丢失。
  • 按计划轮换凭据和密钥，而不是让服务主体密钥无限期有效。

凭据窃取仍然是进入云环境最常见的路径之一，强身份验证结合谨慎的访问管理比任何单一工具都更能阻止这些攻击。使用VPN保护管理员和远程员工连接的网络增加了另一层防护，但它最好与良好的身份卫生习惯配合使用，而非替代后者。

要点总结

Storm-3168 Azure攻击表明，攻击者不需要外泄数据就能造成损害；通过被入侵的服务主体删除存储账户本身就具有足够的破坏性。结合Sysdig案例中的勒索信细节，这是一个明确的信号：云身份管理值得组织给予与防火墙和终端安全同等的审视。审查谁和什么有权访问你的云存储、收紧权限、在所有账户类型上启用多因素身份验证，是你今天就可以采取的实际步骤，以降低成为下一个案例研究的风险。