{
	"id": "7db0fce5-a84e-418d-bb26-3488c324f249",
	"created_at": "2026-04-06T00:15:13.79881Z",
	"updated_at": "2026-04-10T03:35:36.753852Z",
	"deleted_at": null,
	"sha1_hash": "f98063e2d8498587163a6c24850f3164f4613946",
	"title": "Storm-0501’s evolving techniques lead to cloud-based ransomware | Microsoft Security Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1758240,
	"plain_text": "Storm-0501’s evolving techniques lead to cloud-based ransomware\r\n| Microsoft Security Blog\r\nBy Microsoft Threat Intelligence\r\nPublished: 2025-08-27 · Archived: 2026-04-05 12:47:14 UTC\r\nMicrosoft Threat Intelligence has observed financially motivated threat actor Storm-0501 continuously evolving\r\ntheir campaigns to achieve sharpened focus on cloud-based tactics, techniques, and procedures (TTPs). While the\r\nthreat actor has been known for targeting hybrid cloud environments, their primary objective has shifted from\r\ndeploying on-premises endpoint ransomware to using cloud-based ransomware tactics.\r\nUnlike traditional on-premises ransomware, where the threat actor typically deploys malware to encrypt critical\r\nfiles across endpoints within the compromised network and then negotiates for a decryption key, cloud-based\r\nransomware introduces a fundamental shift. Leveraging cloud-native capabilities, Storm-0501 rapidly exfiltrates\r\nlarge volumes of data, destroys data and backups within the victim environment, and demands ransom—all\r\nwithout relying on traditional malware deployment.\r\nStorm-0501’s targeting is opportunistic. The threat actor initially deployed Sabbath ransomware in an attack\r\nagainst United States school districts in 2021. In November 2023, the actor targeted the healthcare sector. Over the\r\nyears, the actor switched ransomware payloads multiple times, using Embargo ransomware in 2024 attacks.\r\nIn September 2024, we published a blog detailing how Storm-0501 extended its on-premises ransomware\r\noperations into hybrid cloud environments. The threat actor gained a foothold by compromising Active Directory\r\nenvironments and then pivoted to Microsoft Entra ID, escalating privileges on hybrid and cloud identities to gain\r\nglobal administrator privileges. The impact phase of these attacks took one of two forms: implanting backdoors in\r\nEntra ID tenant configurations using maliciously added federated domains to allow sign-in as nearly any user or\r\ndeploying on-premises ransomware to encrypt endpoints and servers, eventually demanding ransom for the\r\ndecryption keys.\r\nStorm-0501 has continued to demonstrate proficiency in moving between on-premises and cloud environments,\r\nexemplifying how threat actors adapt as hybrid cloud adoption grows. They hunt for unmanaged devices and\r\nsecurity gaps in hybrid cloud environments to evade detection and escalate cloud privileges and, in some cases,\r\ntraverse tenants in multi-tenant setups to achieve their goals.\r\nIn this blog post, we describe the impact of a recent Storm-0501 attack on a compromised cloud environment. We\r\ntrace how the threat actor achieved cloud-based ransomware impact through cloud privilege escalation, taking\r\nadvantage of protection and visibility gaps across the compromised environment, and pivoting from on-premises\r\nto cloud pivots. Understanding how such attacks are conducted is critical in protecting cloud environments. Below\r\nwe share protection and mitigation recommendations, including strengthening protections for cloud identities and\r\ncloud resources, and detection guidance across Microsoft security solutions to help organizations harden their\r\nnetworks against these attacks.\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 1 of 20\n\nFigure 1. Overview of Storm-0501 cloud-based ransomware attack chain\r\nOn-premises compromise and pivot to the cloud\r\nIn a recent campaign, Storm-0501 compromised a large enterprise composed of multiple subsidiaries, each\r\noperating its own Active Directory domain. These domains are interconnected through domain trust relationships,\r\nenabling cross-domain authentication and resource access.\r\nThe cloud environment mirrors this complexity. Different subsidiaries maintain separate Microsoft Azure tenants,\r\nwith varying Microsoft Defender product coverage. Notably, only one tenant had Microsoft Defender for Endpoint\r\ndeployed, and devices from multiple Active Directory domains were onboarded to this single tenant’s license. This\r\nfragmented deployment created visibility gaps across the environment.\r\nActive Directory domains were synchronized to several Entra ID tenants using Entra Connect Sync servers. In\r\nsome cases, a single domain was synced to more than one tenant, further complicating identity management and\r\nmonitoring. For clarity, this blog focuses on the two tenants impacted by the attack: one where on-premises\r\nactivity was observed, and another where cloud-based activity occurred.\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 2 of 20\n\nFigure 2. Storm-0501 on-premises attack chain\r\nOn-premises activity\r\nFor the purposes of this blog, we focus our analysis on the post-compromise phase of the on-premises attack,\r\nmeaning that the threat actor had already achieved domain administrator privileges in the targeted domain. Read\r\nour previous blog for a more comprehensive overview of Storm-0501 tactics in on-premises environments.\r\nThe limited deployment of Microsoft Defender for Endpoint across the environment significantly hindered\r\ndetection. Of the multiple compromised domains, only one domain had significant Defender for Endpoint\r\ndeployment, leaving portions of the network unmonitored. On the few onboarded devices where Storm-0501\r\nactivity was observed, we noted that the threat actor conducted reconnaissance before executing malicious actions.\r\nSpecifically, the threat actor used the following commands:\r\nsc query sense\r\nsc query windefend\r\nThe threat actor checked for the presence of Defender for Endpoint services, suggesting a deliberate effort to\r\navoid detection by targeting non-onboarded systems. This highlights the importance of comprehensive endpoint\r\ncoverage.\r\nLateral movement was facilitated using Evil-WinRM, a post-exploitation tool that utilizes PowerShell over\r\nWindows Remote Management (WinRM) for remote code execution. The abovementioned commands were\r\nexecuted over sessions initiated with the tool, as well as discovery using other common native Windows tools and\r\ncommands such as quser.exe and net.exe. Earlier in the attack, the threat actor had compromised an Entra Connect\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 3 of 20\n\nSync server that was not onboarded to Defender for Endpoint. We assess that this server served as a pivot point,\r\nwith the threat actor establishing a tunnel to move laterally within the network.\r\nThe threat actor also performed a DCSync attack, a technique that abuses the Directory Replication Service (DRS)\r\nRemote Protocol to simulate the behavior of a domain controller. By impersonating a domain controller, the threat\r\nactor could request password hashes for any user in the domain, including privileged accounts. This technique is\r\noften used to extract credentials without triggering traditional authentication-based alerts.\r\nPivot to the cloud\r\nFollowing the on-premises compromise of the first tenant, the threat actor leveraged the Entra Connect Sync\r\nDirectory Synchronization Account (DSA) to enumerate users, roles, and Azure resources within the tenant. This\r\nreconnaissance was performed using AzureHound, a tool designed to map relationships and permissions in Azure\r\nenvironments and consequently find potential attack paths and escalations.\r\nShortly thereafter, the threat actor attempted to sign in as several privileged users. These attempts were\r\nunsuccessful, blocked by Conditional Access policies and multifactor authentication (MFA) requirements. This\r\nsuggests that while Storm-0501 had valid credentials, they lacked the necessary second factor or were unable to\r\nsatisfy policy conditions.\r\nUndeterred, Storm-0501 shifted tactics. Leveraging their foothold in the Active Directory environment, they\r\ntraversed between Active Directory domains and eventually moved laterally to compromise a second Entra\r\nConnect server associated with different Entra ID tenant and Active Directory domain. The threat actor extracted\r\nthe Directory Synchronization Account to repeat the reconnaissance process, this time targeting identities and\r\nresources in the second tenant.\r\nIdentity escalation\r\nAs a result of the discovery phase where the threat actor leveraged on-premises control to pivot across Active\r\nDirectory domains and vastly enumerate cloud resources, they gained critical visibility of the organization’s\r\nsecurity posture. They then identified a non-human synced identity that was assigned with the Global\r\nAdministrator role in Microsoft Entra ID on that tenant. Additionally, this account lacked any registered MFA\r\nmethod. This enabled the threat actor to reset the user’s on-premises password, which shortly after was then\r\nlegitimately synced to the cloud identity of that user using the Entra Connect Sync service. We identified that that\r\npassword change was conducted by the Entra Connect’s Directory Synchronization Account (DSA), since the\r\nEntra Connect Sync service was configured on the most common mode Password-Hash Synchronization (PHS).\r\nConsequently, the threat actor was able to authenticate against Entra ID as that user using the new password.\r\nSince no MFA was registered to that user, after successfully authenticating using the newly assigned password, the\r\nthreat actor was redirected to simply register a new MFA method under their control. From then on, the\r\ncompromised user had a registered MFA method that enabled the threat actor to meet MFA conditions and comply\r\nwith the customer’s Conditional Access policies configuration per resource.\r\nTo access the Azure portal using the compromised Global Admin account, the threat actor had to bypass one more\r\ncondition that was enforced by Conditional Access policies for that resource, which require authentication to occur\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 4 of 20\n\nfrom a Microsoft Entra hybrid joined device. Hybrid joined devices are devices that are joined to both the Active\r\nDirectory domain and Entra ID. We observed failed authentication attempts coming from company devices that\r\nare either domain-joined or Entra-joined devices that did not meet the Conditional Access condition. The threat\r\nactor had to move laterally between different devices in the network, until we observed a successful sign-in to the\r\nAzure portal with the Global Admin account coming from a server that was hybrid joined.\r\nFrom the point that the threat actor was able to successfully meet the Conditional Access policies and sign in to\r\nthe Azure portal as a Global Admin account, Storm-0501 essentially achieved full control over the cloud domain.\r\nThe threat actor then utilized the highest possible cloud privileges to obtain their goals in the cloud.\r\nFigure 3. Storm-0501 cloud identity and cloud environment compromise leading to extortion\r\nCloud identity compromise: Entra ID\r\nCloud persistence\r\nFollowing successful authentication as a Global Admin to the tenant, Storm-0501 immediately established a\r\npersistence mechanism. As was seen in the threat actor’s previous activity, Storm-0501 created a backdoor using a\r\nmaliciously added federated domain, enabling them to sign in as almost any user, according to the ImmutableId\r\nuser property. The threat actor leveraged the Global Administrator Entra role privileges and the AADInternals tool\r\nto register a threat actor-owned Entra ID tenant as a trusted federated domain by the targeted tenant. To establish\r\ntrust between the two tenants, a threat actor-generated root certificate is provided to the victim tenant, which in\r\nturn is used to allow authentication requests coming from the threat actor-owned tenant. The backdoor enabled\r\nStorm-0501 to craft security assertion markup language (SAML) tokens applicable to the victim tenant,\r\nimpersonating users in the victim tenant while assuming the impersonated user’s Microsoft Entra roles.\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 5 of 20\n\nCloud compromise: Azure\r\nAzure initial access and privilege escalation\r\nA tenant’s Entra ID and Azure environments are intertwined. And since Storm-0501 gained top-level Entra ID\r\nprivileges, they could proceed to their final goal, which was to use cloud-based ransomware tactics for monetary\r\ngain. To achieve this goal, they had to find the organization’s valuable data stores, and these were residing in the\r\ncloud: in Azure.\r\nBecause they had compromised a user with the Microsoft Entra Global Administrator role, the only operation they\r\nhad to do to infiltrate the Azure environment was to elevate their access to Azure resources. They elevated their\r\naccess to Azure resources by invoking the Microsoft.Authorization/elevateAccess/action operation. By doing so,\r\nthey gained the User Access Administrator Azure role over all the organization’s Azure subscriptions, including all\r\nthe valuable data residing inside them.\r\nTo freely operate within the environment, the threat actor assigned themselves the Owner Azure role over all the\r\nAzure subscriptions available by invoking the Microsoft.Authorization/roleAssignments/write operation.\r\nDiscovery\r\nAfter taking control over the organization’s Azure environment, we assess that the threat actor initiated a\r\ncomprehensive discovery phase using various techniques, including the usage of the AzureHound tool, where they\r\nattempted to locate the organization’s critical assets, including data stores that contained sensitive information, and\r\ndata store resources that are meant to back up on-premises and cloud endpoint devices. The threat actor managed\r\nto map out the Azure environment, including the understanding of existing environment protections, such as Azure\r\npolicies, resource locks, Azure Storage immutability policies, and more.\r\nDefense evasion\r\nThe threat actor then targeted the organization’s Azure Storage accounts. Using the public access features in Azure\r\nStorage, Storm-0501 exposed non-remotely accessible accounts to the internet and to their own infrastructure,\r\npaving the way for data exfiltration phase. They did this by utilizing the public access features in Azure Storage.\r\nTo modify the Azure Storage account resources, the threat actor abused the Azure\r\nMicrosoft.Storage/storageAccounts/write operation.\r\nCredential access\r\nFor Azure Storage accounts that have key access enabled, the threat actor abused their Azure Owner role to access\r\nand steal the access keys for them by abusing the Azure Microsoft.Storage/storageAccounts/listkeys/action\r\noperation.\r\nExfiltration\r\nAfter exposing the Azure Storage accounts, the threat actor exfiltrated the data in these accounts to their own\r\ninfrastructure by abusing the AzCopy Command-line tool (CLI).\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 6 of 20\n\nImpact\r\nIn on-premises ransomware, the threat actor typically deploys malware that encrypts crucial files on as many\r\nendpoints as possible, then negotiates with the victim for the decryption key. In cloud-based ransomware attacks,\r\ncloud features and capabilities give the threat actor the capability to quickly exfiltrate and transmit large amounts\r\nof data from the victim environment to their own infrastructure, destroy the data and backup cloud resources in the\r\nvictim cloud environment, and then demand the ransom.\r\nAfter completing the exfiltration phase, Storm-0501 initiated the mass-deletion of the Azure resources containing\r\nthe victim organization data, preventing the victim from taking remediation and mitigation action by restoring the\r\ndata. They do so by abusing the following Azure operations against multiple Azure resource providers:\r\nMicrosoft.Compute/snapshots/delete – Deletes Azure Snapshot, a read-only, point-in-time copy of an Azure\r\nVM’s disk (VHD), capturing its state and data at a specific moment, that exists independently from the\r\nsource disk and can be used as a backup or clone of that disk.\r\nMicrosoft.Compute/restorePointCollections/delete  – Deletes the Azure VM Restore Point, which stores\r\nvirtual machines (VM) configuration and point-in-time application-consistent snapshots of all the managed\r\ndisks attached to the VM.\r\nMicrosoft.Storage/storageAccounts/delete – Deletes the Azure storage account, which contains and\r\norganization’s Azure Storage data objects: blobs, files, queues, and tables. In all of Storm-0501 Azure\r\ncampaigns we investigated, this is where they mainly focused, deleting as many Azure Storage account\r\nresources as possible in the environment.\r\nMicrosoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/delete – Deletes an Azure\r\nrecovery services vault protection container. A protection container is a logical grouping of resources (like\r\nVMs or workloads) that can be backed up together, within the Recovery Services vault.\r\nDuring the threat actor’s attempts to mass-delete the data-stores/housing resources, they faced errors and failed to\r\ndelete some of the resources due to the existing protections in the environment. These protections include Azure\r\nresource locks and Azure Storage immutability policies. They then attempted to delete these protections using the\r\nfollowing operations:\r\nMicrosoft.Authorization/locks/delete – Deletes Azure resource locks, which are used to prevent accidental\r\nuser deletion and modification of Azure subscriptions, resource groups, or resources. The lock overrides\r\nany user permission.\r\nMicrosoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/delete – Deletes Azure\r\nstorage immutability policies, which protect blob data from being overwritten or deleted.\r\nAfter successfully deleting multiple Azure resource locks and Azure Storage immutability policies, the threat actor\r\ncontinued the mass deletion of the Azure data stores, successfully erasing resources in various Azure\r\nsubscriptions. For resources that remained protected by immutability policies, the actor resorted to cloud-based\r\nencryption.\r\nTo perform cloud-based encryption, Storm-0501 created a new Azure Key Vault and a new Customer-managed\r\nkey inside the Key Vault, which is meant to be used to encrypt the left Azure Storage accounts using the Azure\r\nEncryption scopes feature:\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 7 of 20\n\nMicrosoft.KeyVault/vaults/write – Creates or modifies an existing Azure Key Vault. The threat actor creates\r\na new Azure key vault to host the encryption key.\r\nMicrosoft.Storage/storageAccounts/encryptionScopes/write – Creates or modifies Azure storage encryption\r\nscopes, which manage encryption with a key that is scoped to a container or an individual blob. When you\r\ndefine an encryption scope, you can specify whether the scope is protected with a Microsoft-managed key\r\nor with a customer-managed key that is stored in Azure Key Vault.\r\nThe threat actor abused the Azure Storage encryption scopes feature and encrypted the Storage blobs in the Azure\r\nStorage accounts. This wasn’t sufficient, as the organization could still access the data with the appropriate Azure\r\npermissions. In attempt to make the data inaccessible, the actor deletes the key that is used for the encryption.\r\nHowever, it’s important to note that Azure Key vaults and keys that are used for encryption purposes are protected\r\nby the Azure Key Vault soft-delete feature, with a default period of 90 days, which allows the user to retrieve the\r\ndeleted key/vault from deletion, preventing cloud-based encryption for ransomware purposes.\r\nAfter successfully exfiltrating and destroying the data within the Azure environment, the threat actor initiated the\r\nextortion phase, where they contacted the victims using Microsoft Teams using one of the previously\r\ncompromised users, demanding ransom.\r\nMitigation and protection guidance\r\nMicrosoft recently implemented a change in Microsoft Entra ID that restricts permissions on the Directory\r\nSynchronization Accounts (DSA) role in Microsoft Entra Connect Sync and Microsoft Entra Cloud Sync. This\r\nchange helps prevent threat actors from abusing Directory Synchronization Accounts in attacks to escalate\r\nprivileges. Additionally, a new version released in May 2025 introduces modern authentication, allowing\r\ncustomers to configure application-based authentication for enhanced security (currently in public preview). It is\r\nalso important to enable Trusted Platform Module (TPM) on the Entra Connect Sync server to securely store\r\nsensitive credentials and cryptographic keys, mitigating Storm-0501’s credential extraction techniques.\r\nThe techniques used by threat actors and described in this blog can be mitigated by adopting the following\r\nsecurity measures:\r\nProtecting on-premises\r\nTurn on tamper protection features to prevent threat actors from stopping security services such as\r\nMicrosoft Defender for Endpoint, which can help prevent hybrid cloud environment attacks such as\r\nMicrosoft Entra Connect abuse.\r\nRun endpoint detection and response (EDR) in block mode so that Defender for Endpoint can block\r\nmalicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft\r\nDefender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate\r\nmalicious artifacts detected post-breach.\r\nTurn on investigation and remediation in full automated mode to allow Defender for Endpoint to take\r\nimmediate action on alerts to help remediate alerts, significantly reducing alert volume.\r\nProtecting cloud identities\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 8 of 20\n\nSecure accounts with credential hygiene: practice the principle of least privilege and audit privileged\r\naccount activity in your Microsoft Entra ID and Azure environments to slow or stop threat actors.\r\nEnable Conditional Access policies – Conditional Access policies are evaluated and enforced every time\r\nthe user attempts to sign in. Organizations can protect themselves from attacks that leverage stolen\r\ncredentials by enabling policies such as device compliance or trusted IP address requirements.\r\nSet a Conditional Access policy to limit the access of Microsoft Entra ID Directory Synchronization\r\nAccounts (DSA) from untrusted IP addresses to all cloud apps.  Please refer to the advanced hunting\r\nsection and check the relevant query to get those IP addresses.\r\nFor Entra Connect Sync servers using application-based authentication, use Conditional Access for\r\nworkload identities to restrict the application’s service principal from similar unauthorized access.\r\nEnsure multifactor authentication (MFA) requirement for all users. Adding more authentication methods,\r\nsuch as the Microsoft Authenticator app or a phone number, increases the level of protection if one factor is\r\ncompromised.\r\nEnsure phishing-resistant multifactor authentication strength is required for Administrators.\r\nEnsure Microsoft Azure overprovisioned identities should have only the necessary permissions.\r\nEnsure separate user accounts and mail forwarding for Global Administrator accounts. Global\r\nAdministrator (and other privileged groups) accounts should be cloud-native accounts with no ties to on-premises Active Directory. See other best practices for using Privileged roles here.\r\nEnsure all existing privileged users have an already registered MFA method to protect against malicious\r\nMFA registrations\r\nImplement Conditional Access authentication strength to require phishing-resistant authentication for\r\nemployees and external users for critical apps.\r\nRefer to Azure Identity Management and access control security best practices for further steps and\r\nrecommendations to manage, design, and secure your Entra ID environment.\r\nEnsure Microsoft Defender for Cloud Apps connectors are turned on for your organization to receive alerts\r\non the Microsoft Entra ID Directory Synchronization Account and all other users.\r\nEnable protection to prevent by-passing of cloud Microsoft Entra MFA when federated with Microsoft\r\nEntra ID. This enhances protection against federated domains attacks.\r\nSet the validatingDomains property of federatedTokenValidationPolicy to “all” to block attempts to sign-in\r\nto any non-federated domain (like .onmicrosoft.com) with SAML tokens.\r\nIf only Microsoft Entra ID performs MFA for a federated domain, set federatedIdpMfaBehavior to\r\nrejectMfaByFederatedIdp to prevent bypassing MFA CAPs.\r\nTurn on Microsoft Entra ID protection to monitor identity-based risks and create risk-based Conditional\r\nAccess policies to remediate risky sign-ins.\r\nProtecting cloud resources\r\nUse solutions like Microsoft Defender for Cloud to protect your cloud resources and assets from malicious\r\nactivity, both in posture management, and threat detection capabilities.\r\nEnable Microsoft Defender for Resource Manager as part of Defender for Cloud to automatically monitor\r\nthe resource management operations in your organization. Defender for Resource Manager runs advanced\r\nsecurity analytics to detect threats and alerts you about suspicious activity.\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 9 of 20\n\nEnabling Defender for Resource Manager allows users to investigate Azure management operations\r\nwithin the Defender XDR, using the advanced hunting experience.\r\nUtilize the Azure Monitor activity log to investigate and monitor Azure management events.\r\nUtilize Azure policies for Azure Storage to prevent network and security misconfigurations and maximize\r\nthe protection of business data stored in your storage accounts.\r\nImplement Azure Blog Storage security recommendations for enhanced data protection.\r\nUtilize the options available for data protection in Azure Storage.\r\nEnable immutable storage for Azure Blob Storage to protect from accidental or malicious modification or\r\ndeletion of blobs or storage accounts.\r\nApply Azure Resource Manager locks to protect from accidental or malicious modifications or deletions of\r\nstorage accounts.\r\nEnable Azure Monitor for Azure Blob Storage to collect, aggregate, and log data to enable recreation of\r\nactivity trails for investigation purposes when a security incident occurs or network is compromised.\r\nEnabled Microsoft Defender for Storage using a built-in Azure policy.\r\nAfter enabling Microsoft Defender for Storage as part of Defender for Cloud, utilize the\r\nCloudStorageAggregatedEvents (preview) table in advanced hunting to proactively hunt for storage\r\nmalicious activity.\r\nEnable Azure blob backup to protect from accidental or malicious deletions of blobs or storage accounts.\r\nApply the principle of least privilege when authorizing access to blob data in Azure Storage using\r\nMicrosoft Entra and RBAC and configure fine-grained Azure Blob Storage access for sensitive data access\r\nthrough Azure ABAC.\r\nUse private endpoints for Azure Storage account access to disable public network access for increased\r\nsecurity.\r\nAvoid using anonymous read access for blob data.\r\nEnable purge protection in Azure Key Vaults to prevent immediate, irreversible deletion of vaults and\r\nsecrets. Use the default retention interval of 90 days.\r\nEnable logs in Azure Key Vault and retain them for up to a year to enable recreation of activity trails for\r\ninvestigation purposes when a security incident occurs or network is compromised.\r\nEnable Microsoft Azure Backup for virtual machines to protect the data on your Microsoft Azure virtual\r\nmachines, and to create recovery points that are stored in geo-redundant recovery vaults.\r\nGeneral hygiene recommendations\r\nUtilize Microsoft Security Exposure Management, available in the Microsoft Defender portal, with\r\ncapabilities such as critical asset protection and attack path analysis that enable security teams to\r\nproactively reduce exposure and mitigate the impact of Storm-0501 hybrid attack tactics. In this case, each\r\nof the critical assets involved – Entra Connect server, users with DCSync permissions, Global\r\nAdministrators – can be identified by relevant alerts and recommendations.\r\nInvestigate on-premises and hybrid Microsoft Security Exposure Management attack paths. Security teams\r\ncan use attack path analysis to trace cross-domain threats that exploit the critical Entra Connect server to\r\npivot into cloud workloads, escalate privileges, and expand their reach. Teams can use the ‘Chokepoint’\r\nview in the attack path dashboard in Microsoft Security Exposure Management to highlight entities\r\nappearing in multiple paths.\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 10 of 20\n\nUtilize the Critical asset management capability in Microsoft Security Exposure Management by\r\nconfiguring your own custom queries to pinpoint your organization’s business-critical assets according to\r\nyour needs, such as business-critical Azure Storage accounts.\r\nMicrosoft Defender XDR detections\r\nMicrosoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR\r\ncoordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide\r\nintegrated protection against attacks like the threat discussed in this blog.\r\nCustomers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate\r\nand respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.\r\nTactic \r\nObserved\r\nactivity \r\nMicrosoft Defender coverage \r\nInitial\r\naccess\r\n– Suspicious\r\nsign-ins\r\nMicrosoft Defender XDR\r\n– Authentication with compromised credentials\r\n– Compromised user account in a recognized attack pattern\r\n– Malicious sign in from a risky IP address\r\n– Malicious sign in from an IP address associated with\r\nrecognized attacker infrastructure\r\n– Malicious sign in from recognized attacker infrastructure\r\n-Malicious sign-in from an unusual user agent\r\n– Malicious sign-in from known threat actor IP address\r\n– Successful authentication from a malicious IP\r\n– Successful authentication from a suspicious IP\r\n– Successful authentication using compromised credentials\r\n– User compromised through session cookie hijack\r\n– User signed in from a known malicious IP Address\r\n– Suspicious Azure sign-in by user with active session on a\r\ndevice involved in a credential theft attempt\r\nMicrosoft Defender for Identity\r\n– Possibly compromised user account signed in\r\n– Possibly compromised service principal account signed\r\nin\r\nMicrosoft Defender for Cloud Apps\r\n– Suspicious login from AADInternals tool  \r\nMicrosoft Defender for Cloud\r\nDefender for Resource Manager\r\n– Suspicious invocation of a high-risk ‘Initial Access’\r\noperation detected (Preview)  \r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 11 of 20\n\nDefender for Storage\r\n– Access from an unusual location to a storage account\r\n– Access from an unusual location to a sensitive blob\r\ncontainer\r\n– Access from a known suspicious IP address to a sensitive\r\nblob container\r\n– Access from a suspicious IP address\r\n– Unusual unauthenticated public access to a sensitive blob\r\ncontainer\r\nExecution \r\n– Various types\r\nof execution-related\r\nsuspicious\r\nactivity by an\r\nattacker were\r\nobserved\r\n– Crafting access\r\ntokens and\r\nexecuting actions\r\nagainst the cloud\r\nMicrosoft Defender for Endpoint\r\n– Compromised account conducting hands-on-keyboard\r\nattack\r\n– Potential human-operated malicious activity\r\n– Suspicious cmdlets launch using AADInternals\r\nPersistence \r\n– Federated\r\ndomain backdoor\r\nwas added\r\nMicrosoft Defender for Cloud Apps\r\n– Backdoor creation using AADInternals tool  \r\nPrivilege\r\nescalation\r\n– Elevated\r\naccess to Azure\r\nresources\r\n– Assignment of\r\nOwner Azure\r\nrole\r\nMicrosoft Defender XDR\r\n– Suspicious Azure elevate access operation by a user with\r\nan active session on a device involved in a credential theft\r\nattempt\r\n– Possibly compromised Microsoft Entra Connect Sync\r\naccount elevated its access to Azure resources\r\n– Possibly compromised user elevated access to Azure\r\nresources\r\nMicrosoft Defender for Cloud\r\nDefender for Resource Manager\r\n– Suspicious elevate access operation\r\n– Suspicious invocation of a high-risk ‘Privilege\r\nEscalation’ operation detected (Preview)\r\n– Suspicious Azure role assignment detected (Preview)\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 12 of 20\n\nDefense\r\nevasion\r\n– Attempts to\r\ntamper with\r\nMicrosoft\r\nDefender\r\nAntivirus\r\n– Manipulation\r\nof Azure Storage\r\naccount\r\nconfigurations  \r\nMicrosoft Defender for Endpoint –\r\nAttempt to turn off Microsoft Defender Antivirus\r\nprotection\r\nMicrosoft Defender for Cloud\r\nDefender for Resource Manager\r\n– Suspicious invocation of a high-risk ‘Defense Evasion’\r\noperation detected (Preview)\r\nCredential\r\naccess\r\n– Entra Connect\r\nSync server\r\ncompromise and\r\nsync accounts\r\nextraction\r\n– Extracting\r\ncredentials from\r\nremote machines\r\n– Executing\r\nDCSync\r\noperation against\r\na domain\r\ncontroller\r\n– Access Azure\r\nStorage accounts\r\naccess keys\r\n– Creation of a\r\nkey inside an\r\nAzure Key Vault\r\nfor encryption of\r\nAzure Storage\r\ndata\r\nMicrosoft Defender Antivirus\r\n– Trojan:Win32/SuspAdSyncAccess.A!EntraConnect\r\n– Backdoor:Win32/AdSyncDump!EntraConnect\r\n–\r\nBehavior:Win32/DumpADConnectCreds.A!EntraConnect\r\n– Trojan:Win32/SuspAdSyncAccess.A!EntraConnect\r\n– Behavior:Win32/SuspAdsyncBin.A!EntraConnect  \r\nMicrosoft Defender for Endpoint\r\n– Entra Connect Sync credentials extraction attempt\r\n– Indication of local security authority secrets theft\r\n– Potential Entra Connect Tampering\r\n– Ongoing hands-on-keyboard attack using Impacket\r\ntoolkit\r\n– Possible source of DCSync attack  \r\nMicrosoft Defender for Identity\r\n– Suspected DCSync attack (replication of directory\r\nservices)  \r\nMicrosoft Defender for Cloud Apps\r\n– Compromised Microsoft Entra ID Cloud Sync account\r\n– AADInternals tool used by a Microsoft Entra Sync\r\naccount\r\n– Entra Connect Sync account suspicious activity\r\nfollowing a suspicious login\r\n– Suspicious sign-in to Microsoft Entra Connect Sync\r\naccount  \r\nMicrosoft Defender for Cloud\r\nDefender for Resource Manager\r\n– Suspicious invocation of a high-risk ‘Credential Access’\r\noperation detected (Preview)  \r\nDefender for Key Vault\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 13 of 20\n\n– Suspicious key vault recovery detected\r\n– Unusual application accessed a key vault\r\n– Unusual operation pattern in a key vault\r\n– Unusual user accessed a key vault\r\nDiscovery\r\n– Verifying\r\nwhether\r\nMicrosoft\r\nDefender for\r\nEndpoint is\r\nonboarded on a\r\nmachine\r\n–\r\nReconnaissance\r\nactivity against\r\nActive\r\nDirectory/Entra\r\nID/Azure\r\n– AzureHound\r\ntool invocation\r\nin the cloud\r\nenvironment\r\nMicrosoft Defender for Endpoint\r\n– Suspicious sequence of exploration activities  \r\nMicrosoft Defender for Cloud Apps\r\n– Suspicious use of AzureHound  \r\nMicrosoft Defender for Identity\r\n– Reconnaissance tool was observed  \r\nMicrosoft Defender for Cloud\r\nDefender for Resource Manager\r\n– AzureHound tool invocation detected\r\nLateral\r\nmovement\r\n– Lateral\r\nmovement\r\nbetween\r\nendpoints in the\r\nnetwork\r\n– Lateral\r\nmovement using\r\nEvil-WinRM\r\n– Cloud sign-in\r\nattempts using\r\nstolen credentials\r\nor access tokens\r\nextracted from\r\ncompromised\r\nendpoints\r\nMicrosoft Defender for Endpoint\r\n– Possibly malicious use of proxy or tunneling tool\r\n– Suspicious remote PowerShell execution  \r\nMicrosoft Defender for Cloud Apps\r\n– Suspicious login from AADInternals tool  \r\nExfiltration – Data collection\r\nand theft from\r\nAzure Storage\r\naccounts\r\nMicrosoft Defender for Cloud\r\nDefender for Resource Manager\r\n– Suspicious invocation of a high-risk ‘Data Collection’\r\noperation detected (Preview)  \r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 14 of 20\n\nDefender for Storage\r\n– The access level of a potentially sensitive storage blob\r\ncontainer was changed to allow unauthenticated public\r\naccess\r\n– Publicly accessible storage containers successfully\r\ndiscovered\r\n– Publicly accessible storage containers unsuccessfully\r\nscanned\r\n– Unusual amount of data extracted from a storage account\r\n– Unusual deletion in a storage account\r\n– Unusual amount of data extracted from a sensitive blob\r\ncontainer\r\n– Unusual number of blobs extracted from a sensitive blob\r\ncontainer\r\n– Unusual SAS token was used to access an Azure storage\r\naccount from a public IP address\r\n– Suspicious external access to an Azure storage account\r\nwith overly permissive SAS token\r\n– Suspicious external operation to an Azure storage\r\naccount with overly permissive SAS token\r\n– Access from a suspicious IP address\r\nImpact\r\n– Mass Azure\r\ndata store\r\nresources\r\ndeletion and\r\nencryption\r\nMicrosoft Defender XDR\r\n– Suspicious Azure data store resources deletion attempt by\r\na user with an active session on a device involved in a\r\ncredential theft attempt  \r\nMicrosoft Defender for Cloud\r\nDefender for Resource Manager\r\n– Suspicious backup resource deletion (Preview)\r\n– Suspicious invocation of a high-risk ‘Impact’ operation\r\ndetected (Preview)  \r\nDefender for Storage\r\n– Unusual deletion in a storage account\r\nThreat intelligence reports\r\nMicrosoft customers can use the following reports in Microsoft products to get the most up-to-date information\r\nabout the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the\r\nintelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated\r\nthreats found in customer environments.\r\nMicrosoft Defender XDR threat analytics\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 15 of 20\n\nActor Profile: Storm-0501\r\nActivity Profile: Ransomware actor Storm-0501 expands to hybrid cloud environments\r\nMicrosoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft\r\nDefender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the\r\nMicrosoft Defender portal to get more information about this threat actor.\r\nHunting queries\r\nMicrosoft Defender XDR\r\nMicrosoft Defender XDR customers can run the following query to find related activity in their networks:\r\nSign-in activity\r\nExplore sign-in activity from IdentityLogonEvents, look for uncommon behavior, such as sign-ins from newly\r\nseen IP addresses or sign-ins to new applications that are non-sync related:\r\nIdentityLogonEvents\r\n| where Timestamp \u003e ago(30d)\r\n| where AccountDisplayName contains \"On-Premises Directory Synchronization Service Account\"\r\n| extend ApplicationName = tostring(RawEventData.ApplicationName)\r\n| project-reorder Timestamp, AccountDisplayName, AccountObjectId, IPAddress, ActionType,\r\nApplicationName, OSPlatform, DeviceType\r\nThe activity of the sync account is typically repetitive, coming from the same IP address to the same application.\r\nAny deviation from the natural flow is worth investigating. Cloud applications that are usually accessed by the\r\nMicrosoft Entra ID sync account are Microsoft Azure Active Directory Connect, Windows Azure Active\r\nDirectory, and Microsoft Online Syndication Partner Portal.\r\nCloud activity\r\nExplore the cloud activity (ActionType) of the sync account. Similar to sign-in activity, this account by nature\r\nperforms a certain set of actions including update User., update Device., and so on. New and uncommon activity\r\nfrom this user might indicate an interactive use of the account, which could legitimate action from someone in the\r\norganization or malicious action by the threat actor.\r\nCloudAppEvents\r\n| where Timestamp \u003e ago(30d)\r\n| where AccountDisplayName has \"On-Premises Directory Synchronization Service Account\"\r\n| extend Workload = RawEventData.Workload\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 16 of 20\n\n| project-reorder Timestamp, IPAddress, AccountObjectId, ActionType, Application, Workload,\r\nDeviceType, OSPlatform, UserAgent, ISP\r\nPay close attention to action from different DeviceTypes or OSPlatforms, this account automated service is\r\nperformed from one specific machine, so there shouldn’t be any variety in these fields.\r\nAzure management events\r\nExplore Azure management events by querying the new CloudAuditEvents table in advanced hunting in the\r\nDefender portal. The OperationName column indicates the type of control-plane event executed by the user.\r\nlet Storm0501Operations = dynamic([\r\n//Microsoft.Authorization\r\n\"Microsoft.Authorization/elevateAccess/action\",\r\n\"Microsoft.Authorization/roleAssignments/write\",\r\n\"Microsoft.Authorization/locks/delete\",\r\n//Microsoft.Storage\r\n\"Microsoft.Storage/storageAccounts/write\",\r\n\"Microsoft.Storage/storageAccounts/listkeys/action\",\r\n\"Microsoft.Storage/storageAccounts/delete\",\r\n\"Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/delete\",\r\n\"Microsoft.Storage/storageAccounts/encryptionScopes/write\",\r\n//Microsoft.Compute\r\n\"Microsoft.Compute/snapshots/delete\",\r\n\"Microsoft.Compute/restorePointCollections/delete\",\r\n//Microsoft.RecoveryServices\r\n\"Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/delete\",\r\n//Microsoft.KeyVault\r\n\"Microsoft.KeyVault/vaults/write\"\r\n]);\r\nCloudAuditEvents\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 17 of 20\n\n| where Timestamp \u003e ago(30d)\r\n| where AuditSource == \"Azure\" and DataSource == \"Azure Logs\"\r\n| where OperationName in~ (Storm0501Operations)\r\n| extend EventName = RawEventData.eventName\r\n| extend UserId = RawEventData.principalOid, ApplicationId = RawEventData.applicationId\r\n| extend Status = RawEventData.status, SubStatus = RawEventData.subStatus\r\n| extend Claims = parse_json(tostring(RawEventData.claims))\r\n| extend UPN = Claims[\"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn\"]\r\n| extend AuthMethods = Claims[\"http://schemas.microsoft.com/claims/authnmethodsreferences\"]\r\n| project-reorder ReportId, EventName, Timestamp, UPN, UserId, AuthMethods, IPAddress, OperationName,\r\nAzureResourceId, Status, SubStatus, ResourceId, Claims, ApplicationId\r\nExposure of resources and users\r\nExplore Microsoft Security Exposure Management capabilities by querying the ExposureGraphNodes and\r\nExposureGraphEdges tables in the advanced hunting in the Defender portal. By utilizing these tables, you can\r\nidentify critical assets, including Azure Storage accounts that contain sensitive data or protected by an immutable\r\nstorage policy. All predefined criticality rules can be found here: Predefined classifications\r\nExposureGraphNodes\r\n| where NodeLabel =~ \"microsoft.storage/storageaccounts\"\r\n// Criticality check\r\n| extend CriticalityInfo = NodeProperties[\"rawData\"][\"criticalityLevel\"]\r\n| where isnotempty( CriticalityInfo)\r\n| extend CriticalityLevel = CriticalityInfo[\"criticalityLevel\"]\r\n| extend CriticalityLevel = case(\r\nCriticalityLevel == 0, \"Critical\",\r\nCriticalityLevel == 1, \"High\",\r\nCriticalityLevel == 2, \"Medium\",\r\nCriticalityLevel == 3, \"Low\", \"\")\r\n| extend CriticalityRules = CriticalityInfo[\"ruleNames\"]\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 18 of 20\n\n| extend StorageContainsSensitiveData = CriticalityRules has \"Databases with Sensitive Data\"\r\n| extend ImmutableStorageLocked = CriticalityRules has \"Immutable and Locked Azure Storage\"\r\n// Exposure check\r\n| extend ExposureInfo = NodeProperties[\"rawData\"][\"exposedToInternet\"]\r\n| project-reorder NodeName, NodeId, CriticalityLevel, CriticalityRules, StorageContainsSensitiveData,\r\nImmutableStorageLocked, ExposureInfo\r\nThe following query can identify critical users who are mainly assigned with privileged Microsoft Entra roles,\r\nincluding Global Administrator:\r\nExposureGraphNodes\r\n| where NodeLabel =~ \"user\"\r\n| extend UserId = NodeProperties[\"rawData\"][\"accountObjectId\"]\r\n| extend IsActive = NodeProperties[\"rawData\"][\"isActive\"]\r\n// Criticality check\r\n| extend CriticalityInfo = NodeProperties[\"rawData\"][\"criticalityLevel\"]\r\n| where isnotempty(CriticalityInfo)\r\n| extend CriticalityLevel = CriticalityInfo[\"criticalityLevel\"]\r\n| extend CriticalityLevel = case(\r\nCriticalityLevel == 0, \"Critical\",\r\nCriticalityLevel == 1, \"High\",\r\nCriticalityLevel == 2, \"Medium\",\r\nCriticalityLevel == 3, \"Low\", \"\")\r\n| extend CriticalityRules = CriticalityInfo[\"ruleNames\"]\r\n| extend GlobalAdministrator = CriticalityRules has \"Global Administrator\"\r\n| project-reorder NodeName, NodeId, UserId, IsActive, CriticalityLevel, CriticalityRules,\r\nGlobalAdministrator\r\nOmri Refaeli, Karam Abu Hanna, and Alon Marom\r\nLearn more\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 19 of 20\n\nFor the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat\r\nIntelligence Blog.\r\nTo get notified about new publications and to join discussions on social media, follow us on LinkedIn, X\r\n(formerly Twitter), and Bluesky.\r\nTo hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat\r\nlandscape, listen to the Microsoft Threat Intelligence podcast.\r\nSource: https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nhttps://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/\r\nPage 20 of 20",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/"
	],
	"report_names": [
		"storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "c2f84ab8-e990-4fa8-97db-81eb3166b207",
			"created_at": "2025-10-29T02:00:51.915334Z",
			"updated_at": "2026-04-10T02:00:05.318636Z",
			"deleted_at": null,
			"main_name": "Storm-0501",
			"aliases": [
				"Storm-0501"
			],
			"source_name": "MITRE:Storm-0501",
			"tools": [
				"Impacket",
				"Tasklist",
				"Cobalt Strike",
				"Rclone",
				"Nltest",
				"AADInternals"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "6a0c148e-64fe-40fa-a35a-4d9a6ddd7fb0",
			"created_at": "2024-10-04T02:00:04.769179Z",
			"updated_at": "2026-04-10T02:00:03.716865Z",
			"deleted_at": null,
			"main_name": "Storm-0501",
			"aliases": [],
			"source_name": "MISPGALAXY:Storm-0501",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434513,
	"ts_updated_at": 1775792136,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f98063e2d8498587163a6c24850f3164f4613946.pdf",
		"text": "https://archive.orkl.eu/f98063e2d8498587163a6c24850f3164f4613946.txt",
		"img": "https://archive.orkl.eu/f98063e2d8498587163a6c24850f3164f4613946.jpg"
	}
}