Microsoft Threat Intelligence has observed financially motivated threat actor Storm-0501 continuously evolving their campaigns to achieve sharpened focus on cloud-based tactics, techniques, and procedures (TTPs). While the threat actor has been known for targeting hybrid cloud environments, their primary objective has shifted from deploying on-premises endpoint ransomware to using cloud-based ransomware tactics.
Unlike traditional on-premises ransomware, where the threat actor typically deploys malware to encrypt critical files across endpoints within the compromised network and then negotiates for a decryption key, cloud-based ransomware introduces a fundamental shift. Leveraging cloud-native capabilities, Storm-0501 rapidly exfiltrates large volumes of data, destroys data and backups within the victim environment, and demands ransom—all without relying on traditional malware deployment.
Storm-0501’s targeting is opportunistic. The threat actor initially deployed Sabbath ransomware in an attack against United States school districts in 2021. In November 2023, the actor targeted the healthcare sector. Over the years, the actor switched ransomware payloads multiple times, using Embargo ransomware in 2024 attacks.
In September 2024, we published a blog detailing how Storm-0501 extended its on-premises ransomware operations into hybrid cloud environments. The threat actor gained a foothold by compromising Active Directory environments and then pivoted to Microsoft Entra ID, escalating privileges on hybrid and cloud identities to gain global administrator privileges. The impact phase of these attacks took one of two forms: implanting backdoors in Entra ID tenant configurations using maliciously added federated domains to allow sign-in as nearly any user or deploying on-premises ransomware to encrypt endpoints and servers, eventually demanding ransom for the decryption keys.
Storm-0501 has continued to demonstrate proficiency in moving between on-premises and cloud environments, exemplifying how threat actors adapt as hybrid cloud adoption grows. They hunt for unmanaged devices and security gaps in hybrid cloud environments to evade detection and escalate cloud privileges and, in some cases, traverse tenants in multi-tenant setups to achieve their goals.
In this blog post, we describe the impact of a recent Storm-0501 attack on a compromised cloud environment. We trace how the threat actor achieved cloud-based ransomware impact through cloud privilege escalation, taking advantage of protection and visibility gaps across the compromised environment, and pivoting from on-premises to cloud pivots. Understanding how such attacks are conducted is critical in protecting cloud environments. Below we share protection and mitigation recommendations, including strengthening protections for cloud identities and cloud resources, and detection guidance across Microsoft security solutions to help organizations harden their networks against these attacks.
On-premises compromise and pivot to the cloud
In a recent campaign, Storm-0501 compromised a large enterprise composed of multiple subsidiaries, each operating its own Active Directory domain. These domains are interconnected through domain trust relationships, enabling cross-domain authentication and resource access.
The cloud environment mirrors this complexity. Different subsidiaries maintain separate Microsoft Azure tenants, with varying Microsoft Defender product coverage. Notably, only one tenant had Microsoft Defender for Endpoint deployed, and devices from multiple Active Directory domains were onboarded to this single tenant’s license. This fragmented deployment created visibility gaps across the environment.
Active Directory domains were synchronized to several Entra ID tenants using Entra Connect Sync servers. In some cases, a single domain was synced to more than one tenant, further complicating identity management and monitoring. For clarity, this blog focuses on the two tenants impacted by the attack: one where on-premises activity was observed, and another where cloud-based activity occurred.
On-premises activity
For the purposes of this blog, we focus our analysis on the post-compromise phase of the on-premises attack, meaning that the threat actor had already achieved domain administrator privileges in the targeted domain. Read our previous blog for a more comprehensive overview of Storm-0501 tactics in on-premises environments.
The limited deployment of Microsoft Defender for Endpoint across the environment significantly hindered detection. Of the multiple compromised domains, only one domain had significant Defender for Endpoint deployment, leaving portions of the network unmonitored. On the few onboarded devices where Storm-0501 activity was observed, we noted that the threat actor conducted reconnaissance before executing malicious actions. Specifically, the threat actor used the following commands:
sc query sense
sc query windefend
The threat actor checked for the presence of Defender for Endpoint services, suggesting a deliberate effort to avoid detection by targeting non-onboarded systems. This highlights the importance of comprehensive endpoint coverage.
Lateral movement was facilitated using Evil-WinRM, a post-exploitation tool that utilizes PowerShell over Windows Remote Management (WinRM) for remote code execution. The abovementioned commands were executed over sessions initiated with the tool, as well as discovery using other common native Windows tools and commands such as quser.exe and net.exe. Earlier in the attack, the threat actor had compromised an Entra Connect Sync server that was not onboarded to Defender for Endpoint. We assess that this server served as a pivot point, with the threat actor establishing a tunnel to move laterally within the network.
The threat actor also performed a DCSync attack, a technique that abuses the Directory Replication Service (DRS) Remote Protocol to simulate the behavior of a domain controller. By impersonating a domain controller, the threat actor could request password hashes for any user in the domain, including privileged accounts. This technique is often used to extract credentials without triggering traditional authentication-based alerts.
Pivot to the cloud
Following the on-premises compromise of the first tenant, the threat actor leveraged the Entra Connect Sync Directory Synchronization Account (DSA) to enumerate users, roles, and Azure resources within the tenant. This reconnaissance was performed using AzureHound, a tool designed to map relationships and permissions in Azure environments and consequently find potential attack paths and escalations.
Shortly thereafter, the threat actor attempted to sign in as several privileged users. These attempts were unsuccessful, blocked by Conditional Access policies and multifactor authentication (MFA) requirements. This suggests that while Storm-0501 had valid credentials, they lacked the necessary second factor or were unable to satisfy policy conditions.
Undeterred, Storm-0501 shifted tactics. Leveraging their foothold in the Active Directory environment, they traversed between Active Directory domains and eventually moved laterally to compromise a second Entra Connect server associated with different Entra ID tenant and Active Directory domain. The threat actor extracted the Directory Synchronization Account to repeat the reconnaissance process, this time targeting identities and resources in the second tenant.
Identity escalation
As a result of the discovery phase where the threat actor leveraged on-premises control to pivot across Active Directory domains and vastly enumerate cloud resources, they gained critical visibility of the organization’s security posture. They then identified a non-human synced identity that was assigned with the Global Administrator role in Microsoft Entra ID on that tenant. Additionally, this account lacked any registered MFA method. This enabled the threat actor to reset the user’s on-premises password, which shortly after was then legitimately synced to the cloud identity of that user using the Entra Connect Sync service. We identified that that password change was conducted by the Entra Connect’s Directory Synchronization Account (DSA), since the Entra Connect Sync service was configured on the most common mode Password-Hash Synchronization (PHS). Consequently, the threat actor was able to authenticate against Entra ID as that user using the new password.
Since no MFA was registered to that user, after successfully authenticating using the newly assigned password, the threat actor was redirected to simply register a new MFA method under their control. From then on, the compromised user had a registered MFA method that enabled the threat actor to meet MFA conditions and comply with the customer’s Conditional Access policies configuration per resource.
To access the Azure portal using the compromised Global Admin account, the threat actor had to bypass one more condition that was enforced by Conditional Access policies for that resource, which require authentication to occur from a Microsoft Entra hybrid joined device. Hybrid joined devices are devices that are joined to both the Active Directory domain and Entra ID. We observed failed authentication attempts coming from company devices that are either domain-joined or Entra-joined devices that did not meet the Conditional Access condition. The threat actor had to move laterally between different devices in the network, until we observed a successful sign-in to the Azure portal with the Global Admin account coming from a server that was hybrid joined.
From the point that the threat actor was able to successfully meet the Conditional Access policies and sign in to the Azure portal as a Global Admin account, Storm-0501 essentially achieved full control over the cloud domain. The threat actor then utilized the highest possible cloud privileges to obtain their goals in the cloud.
Cloud identity compromise: Entra ID
Cloud persistence
Following successful authentication as a Global Admin to the tenant, Storm-0501 immediately established a persistence mechanism. As was seen in the threat actor’s previous activity, Storm-0501 created a backdoor using a maliciously added federated domain, enabling them to sign in as almost any user, according to the ImmutableId user property. The threat actor leveraged the Global Administrator Entra role privileges and the AADInternals tool to register a threat actor-owned Entra ID tenant as a trusted federated domain by the targeted tenant. To establish trust between the two tenants, a threat actor-generated root certificate is provided to the victim tenant, which in turn is used to allow authentication requests coming from the threat actor-owned tenant. The backdoor enabled Storm-0501 to craft security assertion markup language (SAML) tokens applicable to the victim tenant, impersonating users in the victim tenant while assuming the impersonated user’s Microsoft Entra roles.
Cloud compromise: Azure
Azure initial access and privilege escalation
A tenant’s Entra ID and Azure environments are intertwined. And since Storm-0501 gained top-level Entra ID privileges, they could proceed to their final goal, which was to use cloud-based ransomware tactics for monetary gain. To achieve this goal, they had to find the organization’s valuable data stores, and these were residing in the cloud: in Azure.
Because they had compromised a user with the Microsoft Entra Global Administrator role, the only operation they had to do to infiltrate the Azure environment was to elevate their access to Azure resources. They elevated their access to Azure resources by invoking the Microsoft.Authorization/elevateAccess/action operation. By doing so, they gained the User Access Administrator Azure role over all the organization’s Azure subscriptions, including all the valuable data residing inside them.
To freely operate within the environment, the threat actor assigned themselves the Owner Azure role over all the Azure subscriptions available by invoking the Microsoft.Authorization/roleAssignments/write operation.
Discovery
After taking control over the organization’s Azure environment, we assess that the threat actor initiated a comprehensive discovery phase using various techniques, including the usage of the AzureHound tool, where they attempted to locate the organization’s critical assets, including data stores that contained sensitive information, and data store resources that are meant to back up on-premises and cloud endpoint devices. The threat actor managed to map out the Azure environment, including the understanding of existing environment protections, such as Azure policies, resource locks, Azure Storage immutability policies, and more.
Defense evasion
The threat actor then targeted the organization’s Azure Storage accounts. Using the public access features in Azure Storage, Storm-0501 exposed non-remotely accessible accounts to the internet and to their own infrastructure, paving the way for data exfiltration phase. They did this by utilizing the public access features in Azure Storage. To modify the Azure Storage account resources, the threat actor abused the Azure Microsoft.Storage/storageAccounts/write operation.
Credential access
For Azure Storage accounts that have key access enabled, the threat actor abused their Azure Owner role to access and steal the access keys for them by abusing the Azure Microsoft.Storage/storageAccounts/listkeys/action operation.
Exfiltration
After exposing the Azure Storage accounts, the threat actor exfiltrated the data in these accounts to their own infrastructure by abusing the AzCopy Command-line tool (CLI).
Impact
In on-premises ransomware, the threat actor typically deploys malware that encrypts crucial files on as many endpoints as possible, then negotiates with the victim for the decryption key. In cloud-based ransomware attacks, cloud features and capabilities give the threat actor the capability to quickly exfiltrate and transmit large amounts of data from the victim environment to their own infrastructure, destroy the data and backup cloud resources in the victim cloud environment, and then demand the ransom.
After completing the exfiltration phase, Storm-0501 initiated the mass-deletion of the Azure resources containing the victim organization data, preventing the victim from taking remediation and mitigation action by restoring the data. They do so by abusing the following Azure operations against multiple Azure resource providers:
- Microsoft.Compute/snapshots/delete – Deletes Azure Snapshot, a read-only, point-in-time copy of an Azure VM’s disk (VHD), capturing its state and data at a specific moment, that exists independently from the source disk and can be used as a backup or clone of that disk.
- Microsoft.Compute/restorePointCollections/delete – Deletes the Azure VM Restore Point, which stores virtual machines (VM) configuration and point-in-time application-consistent snapshots of all the managed disks attached to the VM.
- Microsoft.Storage/storageAccounts/delete – Deletes the Azure storage account, which contains and organization’s Azure Storage data objects: blobs, files, queues, and tables. In all of Storm-0501 Azure campaigns we investigated, this is where they mainly focused, deleting as many Azure Storage account resources as possibl
