Storm-0501的演进技术导致基于云的勒索攻击 | 微软安全博客

微软威胁情报观察到出于经济动机的威胁行为者Storm-0501持续演进其攻击活动，将重点聚焦于基于云的战术、技术和程序（TTP）。虽然该威胁行为者一直以针对混合云环境而闻名，但其主要目标已从部署本地端点勒索软件转向使用基于云的勒索策略。

与传统本地勒索软件不同（威胁行为者通常部署恶意软件加密受损网络内端点的关键文件，然后协商解密密钥），基于云的勒索软件引入了根本性转变。Storm-0501利用云原生能力，快速外泄大量数据，销毁受害者环境内的数据和备份，并索要赎金——所有这些都不依赖传统的恶意软件部署。

Storm-0501的攻击目标是机会主义的。该威胁行为者最初在2021年针对美国学区的攻击中部署了Sabbath勒索软件。2023年11月，该行为者针对医疗保健部门。多年来，该行为者多次更换勒索软件载荷，在2024年的攻击中使用了Embargo勒索软件。

2024年9月，我们发布了一篇博客，详细介绍了Storm-0501如何将其本地勒索操作扩展到混合云环境。该威胁行为者通过入侵Active Directory环境获得立足点，然后转向Microsoft Entra ID，提升混合身份和云身份的权限以获得全局管理员权限。这些攻击的影响阶段采取以下两种形式之一：在Entra ID租户配置中植入后门（使用恶意添加的联合域，允许以几乎任何用户身份登录），或部署本地勒索软件以加密端点和服务器，最终要求为解密密钥支付赎金。

Storm-0501持续展示了在本地和云环境之间移动的熟练度，这体现了威胁行为者如何随着混合云采用的增长而适应。他们搜寻混合云环境中未受管理的设备和安全漏洞，以规避检测并提升云权限，在某些情况下，在多租户设置中穿越租户以实现其目标。

在本博客文章中，我们描述了最近一次Storm-0501攻击对受损云环境的影响。我们追踪了该威胁行为者如何通过云权限提升、利用受损环境的保护和可见性漏洞，以及从本地到云的横向移动，实现基于云的勒索影响。了解此类攻击的执行方式对于保护云环境至关重要。下面我们分享保护和缓解建议，包括加强云身份和云资源的保护，以及跨微软安全解决方案的检测指南，以帮助组织强化其网络以抵御这些攻击。

图1. Storm-0501基于云的勒索攻击链概览

本地入侵及向云的横向移动

在最近的一次活动中，Storm-0501入侵了一家由多个子公司组成的大型企业，每个子公司运营着自己的Active Directory域。这些域通过域信任关系互连，实现了跨域身份验证和资源访问。

云环境反映了这种复杂性。不同的子公司维护着独立的Microsoft Azure租户，并具有不同的Microsoft Defender产品覆盖范围。值得注意的是，只有一个租户部署了Microsoft Defender for Endpoint，并且来自多个Active Directory域的设备被载入到该单一租户的许可证中。这种分散的部署在整个环境中造成了可见性漏洞。

Active Directory域使用Entra Connect Sync服务器同步到多个Entra ID租户。在某些情况下，单个域同步到多个租户，这进一步复杂化了身份管理和监控。为清晰起见，本博客重点介绍受攻击影响的两个租户：一个观察到本地活动，另一个发生基于云的活动。

图2. Storm-0501本地攻击链

本地活动

就本博客而言，我们将分析重点放在本地攻击的入侵后阶段，这意味着威胁行为者已在目标域中获得域管理员权限。请阅读我们之前的博客以获取关于Storm-0501在本地环境中战术的更全面概述。

Microsoft Defender for Endpoint在整个环境中的有限部署严重阻碍了检测。在多个受损域中，只有一个域有显著的Defender for Endpoint部署，导致部分网络未被监控。在观察到Storm-0501活动的少数载入设备上，我们注意到威胁行为者在执行恶意操作之前进行了侦察。具体来说，威胁行为者使用了以下命令：

1
2

sc query sens
sc query windefend

威胁行为者检查了Defender for Endpoint服务的存在，这表明其有意通过针对未载入系统来避免检测。这凸显了全面端点覆盖的重要性。

横向移动是使用Evil-WinRM实现的，这是一种利用PowerShell over Windows Remote Management (WinRM) 进行远程代码执行的入侵后工具。上述命令是通过使用该工具启动的会话执行的，同时还使用了其他常见的原生Windows工具和命令（如quser.exe和net.exe）进行发现。在攻击的早期，威胁行为者入侵了一台未载入Defender for Endpoint的Entra Connect Sync服务器。我们评估认为该服务器充当了横向移动支点，威胁行为者建立隧道以在网络内横向移动。

威胁行为者还执行了DCSync攻击，这是一种滥用目录复制服务（DRS）远程协议来模拟域控制器行为的技术。通过冒充域控制器，威胁行为者可以请求域中任何用户（包括特权账户）的密码哈希。此技术通常用于提取凭据而不触发传统的基于身份验证的警报。

向云的横向移动

在第一个租户的本地入侵之后，威胁行为者利用Entra Connect Sync目录同步账户（DSA）来枚举租户内的用户、角色和Azure资源。此侦察是使用AzureHound执行的，该工具旨在映射Azure环境中的关系和权限，从而找到潜在的攻击路径和权限提升方法。

此后不久，威胁行为者尝试以多个特权用户身份登录。这些尝试未成功，被条件访问策略和多因素身份验证（MFA）要求阻止。这表明虽然Storm-0501拥有有效的凭据，但他们缺乏必要的第二因素或无法满足策略条件。

Storm-0501并未气馁，转而改变策略。利用他们在Active Directory环境中的立足点，他们在Active Directory域之间穿行，并最终横向移动以入侵与不同Entra ID租户和Active Directory域关联的第二台Entra Connect服务器。威胁行为者提取了目录同步账户以重复侦察过程，这次针对第二个租户中的身份和资源。

身份权限提升

由于在发现阶段威胁行为者利用本地控制权在Active Directory域之间横向移动并广泛枚举云资源，他们获得了对该组织安全态势的关键可见性。然后他们识别出一个非人类同步身份，该身份在该租户的Microsoft Entra ID中被分配了全局管理员角色。此外，该账户缺少任何注册的MFA方法。这使得威胁行为者能够重置用户的本地密码，该密码随后通过Entra Connect Sync服务合法同步到该用户的云身份。我们识别出该密码更改是由Entra Connect的目录同步账户（DSA）执行的，因为Entra Connect Sync服务配置为最常见的模式——密码哈希同步（PHS）。因此，威胁行为者能够使用新密码针对Entra ID以该用户身份进行身份验证。

由于该用户没有注册MFA，在成功使用新分配的密码进行身份验证后，威胁行为者被重定向以简单地在其控制下注册一个新的MFA方法。从那时起，被入侵的用户有了一个注册的MFA方法，使得威胁行为者能够满足MFA条件并遵守客户按资源配置的条件访问策略。

为了使用被入侵的全局管理员账户访问Azure门户，威胁行为者必须绕过由该资源的条件访问策略强制实施的另一个条件，该条件要求身份验证必须来自Microsoft Entra混合加入的设备。混合加入的设备是同时加入Active Directory域和Entra ID的设备。我们观察到来自公司设备的失败身份验证尝试，这些设备要么是域加入的，要么是Entra加入的设备，但不满足条件访问条件。威胁行为者必须在网络中的不同设备之间横向移动，直到我们观察到从一个混合加入的服务器成功登录到Azure门户，使用的是全局管理员账户。

从威胁行为者能够成功满足条件访问策略并以全局管理员账户登录Azure门户的那一刻起，Storm-0501基本上实现了对云域的完全控制。然后，威胁行为者利用最高级别的云权限来实现其在云中的目标。

图3. Storm-0501云身份和云环境入侵导致勒索

云身份入侵：Entra ID

云持久化

成功以全局管理员身份验证到租户后，Storm-0501立即建立了一个持久化机制。正如在该威胁行为者之前的活动中所见，Storm-0501使用恶意添加的联合域创建了一个后门，使他们能够根据ImmutableId用户属性以几乎任何用户身份登录。威胁行为者利用全局管理员Entra角色特权和AADInternals工具，将一个威胁行为者拥有的Entra ID租户注册为目标租户受信任的联合域。为了在两个租户之间建立信任，向受害者租户提供了一个威胁行为者生成的根证书，该证书进而用于允许来自威胁行为者拥有的租户的身份验证请求。该后门使Storm-0501能够制作适用于受害者租户的安全声明标记语言（SAML）令牌，在受害者租户中冒充用户，并承担被冒充用户的Microsoft Entra角色。

云入侵：Azure

Azure初始访问和权限提升

租户的Entra ID和Azure环境是相互交织的。由于Storm-0501获得了顶级的Entra ID权限，他们可以继续实现其最终目标，即使用基于云的勒索策略获取金钱利益。为了实现这一目标，他们必须找到组织的有价值的数据存储，而这些数据存储在云中：在Azure中。

因为他们入侵了一个拥有Microsoft Entra全局管理员角色的用户，要渗透Azure环境，他们唯一需要做的操作就是将其访问权限提升到Azure资源。他们通过调用Microsoft.Authorization/elevateAccess/action操作来提升对Azure资源的访问权限。通过这样做，他们获得了对组织所有Azure订阅的用户访问管理员Azure角色，包括其中的所有有价值数据。

为了在环境中自由操作，威胁行为者通过调用Microsoft.Authorization/roleAssignments/write操作，为自己分配了所有可用Azure订阅的所有者Azure角色。

发现

在控制了组织的Azure环境后，我们评估认为威胁行为者使用各种技术启动了全面的发现阶段，包括使用AzureHound工具，他们试图定位组织的关键资产，包括包含敏感信息的数据存储，以及用于备份本地和云端点设备的数据存储资源。威胁行为者设法绘制出Azure环境的地图，包括了解现有的环境保护措施，例如Azure策略、资源锁、Azure Storage不可变性策略等。

防御规避

威胁行为者随后针对组织的Azure存储账户。利用Azure Storage中的公共访问功能，Storm-0501将无法远程访问的账户暴露给互联网和他们自己的基础设施，为数据外泄阶段铺平道路。他们通过利用Azure Storage中的公共访问功能来实现这一点。为了修改Azure存储账户资源，威胁行为者滥用了Azure Microsoft.Storage/storageAccounts/write操作。

凭据访问

对于启用了密钥访问的Azure存储账户，威胁行为者滥用其Azure所有者角色，通过滥用Azure Microsoft.Storage/storageAccounts/listkeys/action操作来访问和窃取访问密钥。

外泄

在暴露了Azure存储账户之后，威胁行为者通过滥用AzCopy命令行工具（CLI）将这些账户中的数据外泄到他们自己的基础设施。

影响

在本地勒索软件中，威胁行为者通常部署恶意软件，加密尽可能多端点上的关键文件，然后与受害者协商解密密钥。在基于云的勒索攻击中，云特性和能力使威胁行为者能够快速将大量数据从受害者环境外泄和传输到自己的基础设施，销毁受害者云环境中的数据和备份云资源，然后要求赎金。

完成外泄阶段后，Storm-0501启动了包含受害者组织数据的Azure资源的大规模删除，阻止受害者通过恢复数据采取补救和缓解措施。他们通过滥用以下针对多个Azure资源提供程序的操作来实现这一点：

• Microsoft.Compute/snapshots/delete – 删除Azure快照，这是Azure VM磁盘（VHD）的只读时间点副本，捕获其在特定时刻的状态和数据，独立于源磁盘存在，可用作该磁盘的备份或克隆。
• Microsoft.Compute/restorePointCollections/delete – 删除Azure VM还原点，该点存储虚拟机（VM）配置以及附加到VM的所有托管磁盘的时间点应用程序一致性快照。
• Microsoft.Storage/storageAccounts/delete – 删除Azure存储账户，该账户包含组织的Azure Storage数据对象：Blob、文件、队列和表。在我们调查的所有Storm-0501 Azure活动中，这是他们主要关注的领域，尽可能删除环境中的Azure存储账户资源。
• Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/delete – 删除Azure恢复服务保管库保护容器。保护容器是资源（如VM或工作负载）的逻辑分组，可以在恢复服务保管库内一起备份。

在威胁行为者尝试大规模删除数据存储/承载资源期间，由于环境中存在的保护措施，他们遇到错误并未能删除某些资源。这些保护措施包括Azure资源锁和Azure Storage不可变性策略。然后他们尝试使用以下操作删除这些保护措施：

• Microsoft.Authorization/locks/delete – 删除Azure资源锁，该锁用于防止用户意外删除和修改Azure订阅、资源组或资源。该锁覆盖任何用户权限。
• Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/delete – 删除Azure存储不可变性策略，该策略保护Blob数据不被覆盖或删除。

在成功删除了多个Azure资源锁和Azure Storage不可变性策略后，威胁行为者继续大规模删除Azure数据存储，成功清除了各种Azure订阅中的资源。对于仍然受不可变性策略保护的资源，行为者转而采用基于云的加密。

为了执行基于云的加密，Storm-0501创建了一个新的Azure Key Vault和一个新的客户管理密钥 inside the Key Vault，该密钥旨在用于通过Azure加密范围功能加密剩余的Azure存储账户：

• Microsoft.KeyVault/vaults/write – 创建或修改现有的Azure Key Vault。威胁行为者创建一个新的Azure密钥保管库来托管加密密钥。
• Microsoft.Storage/storageAccounts/encryptionScopes/write – 创建或修改Azure存储加密范围，该范围管理使用限定于容器或单个Blob的密钥进行加密。当您定义加密范围时，您可以指定该范围是受Microsoft管理的密钥保护还是受存储在Azure Key Vault中的客户管理密钥保护。

威胁行为者滥用了Azure Storage加密范围功能，并加密了Azure存储账户中的存储Blob。但这还不够，因为组织仍然可以通过适当的Azure权限访问数据。为了试图使数据无法访问，行为者删除了用于加密的密钥。然而，重要的是要注意，用于加密目的的Azure Key Vault和密钥受Azure Key Vault软删除功能保护，默认期限为90天，这允许用户从删除中检索已删除的密钥/保管库，从而防止基于云的加密用于勒索目的。

在成功外泄并销毁了Azure环境内的数据后，威胁行为者启动了勒索阶段，他们使用Microsoft Teams通过一个先前被入侵的用户联系受害者，要求赎金。

缓解和保护指南

微软最近在Microsoft Entra ID中实施了一项更改，限制了Microsoft Entra Connect Sync和Microsoft Entra Cloud Sync中目录同步账户（DSA）角色的权限。此更改有助于防止威胁行为者在攻击中滥用目录同步账户来提升权限。此外，2025年5月发布的新版本引入了现代身份验证，允许客户配置基于应用程序的身份验证以增强安全性（目前处于公开预览版）。同样重要的是在Entra Connect Sync服务器上启用可信平台模块（TPM），以安全地存储敏感凭据和加密密钥，从而缓解Storm-0501的凭据提取技术。

本博客中描述的威胁行为者使用的技术可以通过采用以下安全措施来缓解：

保护本地环境

• 开启防篡改保护功能，以防止威胁行为者停止安全服务（如Microsoft Defender for Endpoint），这有助于防止混合云环境攻击，例如Microsoft Entra Connect滥用。
• 在阻止模式下运行端点检测和响应（EDR），以便Defender for Endpoint可以阻止恶意项目，即使您的非Microsoft防病毒软件未检测到威胁或当Microsoft Defender防病毒正在被动模式下运行时也是如此。阻止模式下的EDR在后台工作，以修复入侵后检测到的恶意项目。
• 在完全自动模式下开启调查和修复，以允许Defender for Endpoint立即对警报采取行动，帮助修复警报，显著减少警报量。

保护云身份

• 通过凭据卫生保护账户：实践最小权限原则，并审核Microsoft Entra ID和Azure环境中的特权账户活动，以减缓或阻止威胁行为者。
• 启用条件访问策略 – 每次用户尝试登录时都会评估和执行条件访问策略。组织可以通过启用策略（如设备合规性或受信任IP地址要求）来保护自己免受利用被盗凭据的攻击。设置条件访问策略，以限制Microsoft Entra ID目录同步账户（DSA）从不受信任的IP地址访问所有云应用。请参阅高级搜寻部分并检查相关查询以获取这些IP地址。
• 对于使用基于应用程序的身份验证的Entra Connect Sync服务器，使用工作负载身份的条件访问来限制应用程序的服务主体免受类似的未经授权访问。
• 确保所有用户都需要多因素身份验证（MFA）。添加更多身份验证方法（例如Microsoft Authenticator应用程序或电话号码）可以在一个因素被泄露时增加保护级别。
• 确保管理员需要防网络钓鱼的多因素身份验证强度。
• 确保Microsoft Azure过度配置的身份只拥有必要的权限。
• 确保全局管理员账户使用单独的用户账户和邮件转发。全局管理员（及其他特权组）账户应该是云原生账户，与本地Active Directory没有关联。请参阅此处使用特权角色的其他最佳实践。
• 确保所有现有的特权用户都已注册MFA方法，以防止恶意的MFA注册。
• 实施条件访问身份验证强度，要求员工和外部用户对关键应用程序进行防网络钓鱼的身份验证。
• 参考Azure身份管理和访问控制安全最佳实践，以获取管理、设计和保护Entra ID环境的进一步步骤和建议。
• 确保为您的组织开启Microsoft Defender for Cloud Apps连接器，以接收关于Microsoft Entra ID目录同步账户和所有其他用户的警报。
• 启用保护，以防止在与Microsoft Entra ID联合时绕过云Microsoft Entra MFA。这增强了对联合域攻击的保护。
• 将federatedTokenValidationPolicy的validatingDomains属性设置为“all”，以阻止尝试使用SAML令牌登录到任何非联合域（如.onmicrosoft.com）。
• 如果只有Microsoft Entra ID对联合域执行MFA，请将federatedIdpMfaBehavior设置为rejectMfaByFederatedIdp，以防止绕过MFA CAPs。
• 开启Microsoft Entra ID保护以监控基于身份的风险，并创建基于风险的条件访问策略以修复有风险的登录。

保护云资源

• 使用Microsoft Defender for Cloud等解决方案来保护您的云资源和资产免受恶意活动侵害，包括态势管理和威胁检测能力。
• 启用作为Defender for Cloud一部分的Microsoft Defender for Resource Manager，以自动监控组织中的资源管理操作。Defender for Resource Manager运行高级安全分析以检测威胁，并就可疑活动向您发出警报。
• 启用Defender for Resource Manager允许用户在Defender XDR中使用高级搜寻体验调查Azure管理操作。
• 利用Azure Monitor活动日志来调查和监控Azure管理事件。
• 利用Azure Storage的Azure策略来防止网络和安全配置错误，并最大化存储在存储账户中的业务数据的保护。
• 实施Azure Blob Storage安全建议以增强数据保护。
• 利用Azure Storage中可用的数据保护选项。
• 为Azure Blob Storage启用不可变存储，以防止Blob或存储账户被意外或恶意修改或删除。
• 应用Azure资源管理器锁以防止存储账户被意外或恶意修改或删除。
• 为Azure Blob Storage启用Azure Monitor，以收集、聚合和记录数据，以便在发生安全事件或网络受损时能够重新创建活动轨迹用于调查目的。
• 使用内置Azure策略启用Microsoft Defender for Storage。
• 在启用作为Defender for Cloud一部分的Microsoft Defender for Storage后，利用高级搜寻中的CloudStorageAggregatedEvents（预览）表主动搜寻存储恶意活动。
• 启用Azure Blob备份以保护Blob或存储账户免受意外或恶意删除。
• 在使用Microsoft Entra和RBAC授权访问Azure Storage中的Blob数据时应用最小权限原则，并通过Azure ABAC为敏感数据访问配置细粒度的Azure Blob Storage访问。
• 使用Azure存储账户访问的私有终结点，以禁用公共网络访问来增加安全性。
• 避免对Blob数据使用匿名读取访问。
• 在Azure Key Vault中启用清除保护，以防止保管库和机密被立即、不可逆转地删除。使用90天的默认保留间隔。
• 在Azure Key Vault中启用日志并将其保留长达一年，以便在发生安全事件或网络受损时能够重新创建活动轨迹用于调查目的。
• 启用Microsoft Azure Backup for virtual machines以保护Microsoft Azure虚拟机上的数据，并创建存储在异地冗余恢复保管库中的恢复点。

一般卫生建议

• 利用Microsoft安全暴露管理（在Microsoft Defender门户中可用），其具有关键资产保护和攻击路径分析等功能，使安全团队能够主动减少暴露并缓解Storm-0501混合攻击策略的影响。在这种情况下，所涉及的每个关键资产——Entra Connect服务器、具有DCSync权限的用户、全局管理员——都可以通过相关警报和建议进行识别。
• 调查本地和混合Microsoft安全暴露管理攻击路径。安全团队可以使用攻击路径分析来追踪利用关键Entra Connect服务器横向移动到云工作负载、提升权限并扩大其范围的跨域威胁。团队可以使用Microsoft安全暴露管理中攻击路径仪表板中的“瓶颈点”视图来突出显示出现在多个路径中的实体。
• 利用Microsoft安全暴露管理中的关键资产管理功能，通过配置您自己的自定义查询，根据您的需求精确定位组织的业务关键资产，例如业务关键的Azure存储账户。

Microsoft Defender XDR检测

Microsoft Defender XDR客户可以参考下面的适用检测列表。Microsoft Defender XDR协调跨端点、身份、电子邮件、应用程序的检测、预防、调查和响应，以提供针对本博客讨论的威胁的综合保护。

具有预配访问权限的客户还可以在Microsoft Defender中使用Microsoft Security Copilot来调查和响应事件、搜寻威胁，并使用相关威胁情报保护其组织。

威胁情报报告

微软客户可以在微软产品中使用以下报告，以获取有关本博客讨论的威胁行为者、恶意活动和技术的最新信息。这些报告提供情报、保护信息以及建议的操作，以预防、缓解或响应在客户环境中发现的相关威胁。

Microsoft Defender XDR威胁分析

• 行为者档案：Storm-0501
• 活动档案：勒索软件行为者Storm-0501扩展到混合云环境

Microsoft Security Copilot客户还可以使用Microsoft Defender威胁情报中的Microsoft Security Copilot集成，无论是在Security Copilot独立门户中还是在Microsoft Defender门户中的嵌入式体验中，以获取有关此威胁行为者的更多信息。

搜寻查询

Microsoft Defender XDR

Microsoft Defender XDR客户可以运行以下查询以在其网络中找到相关活动：

登录活动

探索IdentityLogonEvents中的登录活动，寻找不常见的行为，例如来自新发现的IP地址的登录或登录到与同步无关的新应用程序：

1
2
3
4
5

IdentityLogonEvents
| where Timestamp > ago(30d)
| where AccountDisplayName contains "On-Premises Directory Synchronization Service Account"
| extend ApplicationName = tostring(RawEventData.ApplicationName)
| project-reorder Timestamp, AccountDisplayName, AccountObjectId, IPAddress, ActionType, ApplicationName, OSPlatform, DeviceType

同步账户的活动通常是重复性的，来自相同的IP地址访问相同的应用程序。任何偏离自然流程的行为都值得调查。通常由Microsoft Entra ID同步账户访问的云应用程序是Microsoft Azure Active Directory Connect、Windows Azure Active Directory和Microsoft Online Syndication Partner Portal。

云活动

探索同步账户的云活动（ActionType）。与登录活动类似，该账户本质上执行一组特定的操作，包括更新用户、更新设备等。来自此用户的新颖和不常见的活动可能表明该账户被交互式使用，这可能是组织中某人的合法行动，也可能是威胁行为者的恶意行动。

1
2
3
4
5

CloudAppEvents
| where Timestamp > ago(30d)
| where AccountDisplayName has "On-Premises Directory Synchronization Service Account"
| extend Workload = RawEventData.Workload
| project-reorder Timestamp, IPAddress, AccountObjectId, ActionType, Application, Workload, DeviceType, OSPlatform, UserAgent, ISP

请密切关注来自不同DeviceTypes或OSPlatforms的操作，该账户的自动化服务是从一台特定机器执行的，因此这些字段中不应有任何变化。

Azure管理事件

通过在Defender门户的高级搜寻中查询新的CloudAuditEvents表来探索Azure管理事件。OperationName列指示用户执行的控制平面事件的类型。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

let Storm0501Operations = dynamic([
//Microsoft.Authorization
"Microsoft.Authorization/elevateAccess/action",
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Authorization/locks/delete",
//Microsoft.Storage
"Microsoft.Storage/storageAccounts/write",
"Microsoft.Storage/storageAccounts/listkeys/action",
"Microsoft.Storage/storageAccounts/delete",
"Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/delete",
"Microsoft.Storage/storageAccounts/encryptionScopes/write",
//Microsoft.Compute
"Microsoft.Compute/snapshots/delete",
"Microsoft.Compute/restorePointCollections/delete",
//Microsoft.RecoveryServices
"Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/delete",
//Microsoft.KeyVault
"Microsoft.KeyVault/vaults/write"]);
CloudAuditEvents
| where Timestamp > ago(30d)
| where AuditSource == "Azure" and DataSource == "Azure Logs"
| where OperationName in~ (Storm0501Operations)
| extend EventName = RawEventData.eventName
| extend UserId = RawEventData.principalOid, ApplicationId = RawEventData.applicationId
| extend Status = RawEventData.status, SubStatus = RawEventData.subStatus
| extend Claims = parse_json(tostring(RawEventData.claims))
| extend UPN = Claims["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
| extend AuthMethods = Claims["http://schemas.microsoft.com/claims/authnmethodsreferences"]
| project-reorder ReportId, EventName, Timestamp, UPN, UserId, AuthMethods, IPAddress, OperationName, AzureResourceId, Status, SubStatus, ResourceId, Claims, ApplicationId

资源和用户的暴露

通过在Defender门户的高级搜寻中查询ExposureGraphNodes和ExposureGraphEdges表来探索Microsoft安全暴露管理功能。通过利用这些表，您可以识别关键资产，包括包含敏感数据或受不可变存储策略保护的Azure存储账户。所有预定义的关键性规则可以在这里找到：预定义分类

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

ExposureGraphNodes
| where NodeLabel =~ "microsoft.storage/storageaccounts"
// Criticality check
| extend CriticalityInfo = NodeProperties["rawData"]["criticalityLevel"]
| where isnotempty( CriticalityInfo)
| extend CriticalityLevel = CriticalityInfo["criticalityLevel"]
| extend CriticalityLevel = case(
            CriticalityLevel == 0, "Critical",
            CriticalityLevel == 1, "High",
            CriticalityLevel == 2, "Medium",
            CriticalityLevel == 3, "Low", "")
| extend CriticalityRules = CriticalityInfo["ruleNames"]
| extend StorageContainsSensitiveData = CriticalityRules has "Databases with Sensitive Data"
| extend ImmutableStorageLocked = CriticalityRules has "Immutable and Locked Azure Storage"
// Exposure check
| extend ExposureInfo = NodeProperties["rawData"]["exposedToInternet"]
| project-reorder NodeName, NodeId, CriticalityLevel, CriticalityRules, StorageContainsSensitiveData, ImmutableStorageLocked, ExposureInfo

以下查询可以识别主要被分配了特权Microsoft Entra角色（包括全局管理员）的关键用户：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

ExposureGraphNodes
| where NodeLabel =~ "user"
| extend UserId = NodeProperties["rawData"]["accountObjectId"]
| extend IsActive = NodeProperties["rawData"]["isActive"]
// Criticality check
| extend CriticalityInfo = NodeProperties["rawData"]["criticalityLevel"]
| where isnotempty(CriticalityInfo)
| extend CriticalityLevel = CriticalityInfo["criticalityLevel"]
| extend CriticalityLevel = case(
            CriticalityLevel == 0, "Critical",
            CriticalityLevel == 1, "High",
            CriticalityLevel == 2, "Medium",
            CriticalityLevel == 3, "Low", "")
| extend CriticalityRules = CriticalityInfo["ruleNames"]
| extend GlobalAdministrator = CriticalityRules has "Global Administrator"
| project-reorder NodeName, NodeId, UserId, IsActive, CriticalityLevel, CriticalityRules, GlobalAdministrator

Omri Refaeli, Karam Abu Hanna, and Alon Marom

了解更多

有关来自微软威胁情报社区的最新安全研究，请查看微软威胁情报博客。

要获取新发布的通知并参与社交媒体的讨论，请在LinkedIn、X（前身为Twitter）和Bluesky上关注我们。

要听取微软威胁情报社区关于不断演变的威胁形势的故事和见解，请收听微软威胁情报播客。