Storm-0501 Threat Actor Profile Guide: How Hybrid Identity Becomes Cloud Ransomware

Storm-0501 turns a compromised on-premises Active Directory into control of Microsoft Entra ID and Azure, then steals, deletes and encrypts cloud data without needing to drop ransomware on cloud workloads. This profile draws on MITRE ATT&CK (G1053), Microsoft Threat Intelligence's 2024 and 2025 reports and Mandiant's earlier reporting on the Sabbath brand. It covers how the group moves through hybrid identity, which ATT&CK techniques it uses, which detections and settings break the chain, and how to measure progress. It is for identity, cloud and security operations leads running hybrid Microsoft estates; attribution follows each source's wording.

Key takeaways

• The sync server is the bridge. Microsoft reports Storm-0501 extracting credentials for Entra Connect Sync accounts and using a compromised Entra Connect Sync server to move into the cloud (ATT&CK T1021.007). Treat sync servers as Tier 0.
• A non-human admin account was the weak point. In the 2025 case Microsoft describes a synced non-human identity holding Global Administrator with no registered MFA method; the attacker reset its on-premises password, let Password Hash Synchronization carry it to Entra ID, then registered its own MFA.
• Persistence lives in federation. With Global Administrator rights the group used AADInternals to add an attacker-controlled federated domain, letting it forge SAML tokens and impersonate users (T1484.002).
• Cloud ransomware is an identity attack. Elevate access, Owner role assignment, storage key theft, deletion of backups, locks and immutability policies, then encryption with an attacker-created Key Vault key: every step used Azure control-plane permissions.
• The fixes are configuration, not new products. Application-based authentication for Entra Connect, cloud-only admins with phishing-resistant MFA, federation hardening, resource locks, immutability and Key Vault purge protection close most of the documented path.

Who they are (names and aliases)

MITRE ATT&CK tracks Storm-0501 as group G1053 and describes it as a financially motivated cybercriminal group, active since 2021, that uses commodity and open-source tools for ransomware operations. "Storm-" is Microsoft's prefix for a developing cluster, so the name may change if Microsoft later folds it into a named actor. See the Threat Actor Naming Conventions Guide.

Because the group moves between RaaS brands, a ransom note's brand tells you little about the operator. Key detection on its identity behaviour instead. See the ALPHV BlackCat Threat Actor Profile and the Hunters International Threat Actor Profile for two of the programmes involved.

Targeting and motivation

• Motivation: financial. MITRE records double extortion (T1657): data theft, direct contact with victims who refuse to pay and posting data on leak sites.
• Sectors: Microsoft's 2024 report names US government, manufacturing, transportation and law enforcement, plus recent targeting of US hospitals. Microsoft's 2025 report adds the healthcare sector in November 2023 and calls the group opportunistic.
• Victim shape: the 2025 case was a large enterprise with several subsidiaries, each with its own AD domain and Azure tenant, domain trusts between them and uneven Defender coverage. Only one tenant ran Defender for Endpoint, and the attacker checked for it (sc query sense, sc query windefend) before acting, which Microsoft reads as targeting unmonitored systems.

Tactics and techniques (MITRE ATT&CK)

All IDs below are ATT&CK v20 entries in the G1053 technique list, checked against the official dataset. Tactic labels follow v20, where Defense Impairment replaced the old defence evasion grouping.

How they abuse identities and credentials

The sync accounts

Entra Connect Sync historically authenticated with two service accounts: an on-premises AD account prefixed MSOL_ and a cloud Directory Synchronization Account prefixed sync_<server name>_. Microsoft assessed with high confidence in 2024 that Storm-0501 extracted plaintext credentials for both from the sync server, building on earlier Impacket and DPAPI key theft. With the cloud account the actor could obtain a Microsoft Graph token and potentially set passwords on hybrid accounts. Microsoft has since restricted the permissions of the Directory Synchronization Accounts role, and in 2025 the actor used the sync account mainly for AzureHound reconnaissance; when Conditional Access and MFA blocked privileged sign-ins, it repeated the process from a second Connect server linked to another tenant.

These non-human identities have tenant-wide reach: treat them like a domain controller. See the Microsoft Entra Connect and Cloud Sync Hardening Guide for the server-side detail this profile does not repeat.

The privileged account without MFA

The 2025 pivot depended on a synced, non-human account holding Global Administrator with no MFA method registered. Resetting its on-premises password was enough: Password Hash Synchronization replicated the change, the attacker signed in to Entra ID and enrolled its own authenticator. That is a governance failure: a service-style account in the top cloud role, synced from on premises, with no owner forcing MFA registration. Microsoft's guidance is to keep Global Administrators cloud-native, separate and MFA-registered. See the Tiered Administration and Enterprise Access Model Guide and the Break-Glass Account Guide.

Federation as a backdoor

Using AADInternals, the actor added its own tenant as a trusted federated domain with a root certificate it generated. That lets it mint SAML tokens for any user whose ImmutableId it knows, bypassing MFA; Microsoft observed Office 365 sign-ins with such tokens, and some 2024 victims had only this backdoor and no ransomware. Resetting the original account's password does not remove it. See the Federation and Trust Relationships Guide.

Azure control plane and keys

Global Administrator can toggle elevate access to gain User Access Administrator at root scope; the actor then assigned itself Owner everywhere. The encryption step itself used an attacker-created Key Vault key and storage encryption scopes, with the key deleted afterwards; soft delete (90 days by default) allowed the victim to recover it. See the Azure RBAC and Service Principals Guide.

Notable incidents

Microsoft names no victims, and the 2025 report starts with the actor already holding Domain Admin.

Detection and defence

Controls that break the chain

• Move Entra Connect to application-based authentication: Microsoft Learn describes a certificate-based OAuth client credential flow that replaces the legacy DSA username and password, with automatic onboarding from Entra Connect 2.5.76.0. Keys are held in the TPM where one exists, which is why Microsoft also recommends enabling TPM on sync servers. Remove the legacy account afterwards (Remove-ADSyncAADServiceAccount). Watch the Application Administrator role, which Microsoft warns can add credentials to the sync application.
• Restrict sync identities: Conditional Access to block DSA sign-ins from untrusted IPs, and Conditional Access for workload identities once you use application-based authentication.
• Cloud-only, MFA-registered admins: no synced account in Global Administrator, phishing-resistant authentication strength for admins, and a recurring check that every privileged account has registered methods. See the Phishing-Resistant MFA Guide and the Privileged Identity Management (PIM) Guide.
• Harden federation: Microsoft recommends setting validatingDomains to "all" in federatedTokenValidationPolicy and federatedIdpMfaBehavior to rejectMfaByFederatedIdp where applicable, plus alerts on any domain authentication change.
• Protect the recovery layer: resource locks, immutable blob storage, Azure Backup, Key Vault purge protection and Key Vault logs retained for up to a year. Backup administration should not share an identity path with production. See the Backup Identity Isolation Guide.
• Endpoint basics on Tier 0: tamper protection, EDR in block mode, automated investigation in full mode, and WDAC or AppLocker blocking unapproved RMM tools.

Detection signals

Correlating identity and cloud control-plane events is the job of ITDR. See the ITDR Guide.

Rollout

1. Week 1: list every account in Global Administrator and Privileged Role Administrator; remove synced and non-human accounts, and force MFA registration on the rest. Confirm two cloud-only break-glass accounts work before changing anything else.
2. Weeks 2 to 4: onboard every Entra Connect server to EDR, enable TPM, and switch to application-based authentication in a staging server first; roll back by re-running the wizard if synchronisation errors appear (Event IDs 1011 and 1012 flag certificate rotation problems).
3. Weeks 4 to 6: apply federation policy settings, alert on federation, elevate access and role assignment changes, and run sync account Conditional Access in report-only mode before enforcing.
4. Weeks 6 to 10: enable resource locks, immutability and purge protection on backup and critical storage, test a restore, and disable shared key access where applications allow.
5. Ongoing: tabletop the 2025 chain and re-check after every new tenant or acquisition.

Small vs large: a single-tenant organisation can finish the first three steps in weeks. Multi-tenant groups like the 2025 victim should treat each Connect server and tenant as a separate Tier 0 asset, with consistent EDR coverage first.

Metrics

• Synced or non-human accounts holding Global Administrator (target zero).
• Percentage of privileged accounts with a registered phishing-resistant method (target 100%).
• Entra Connect servers using application-based authentication and onboarded to EDR (target 100%).
• Median time from a federation or elevate access change to analyst review.
• Percentage of backup vaults and critical storage accounts with locks, immutability and purge protection.

Common failure patterns

• Sync servers outside Tier 0: not onboarded to EDR, administered from ordinary workstations.
• Uneven coverage across subsidiaries: the attacker deliberately chose devices without Defender.
• Privileged service-style accounts without MFA: the exact 2025 pivot.
• Backups administered from the same tenant identities: Owner on the subscription meant Owner on the backups.
• Treating password reset as eviction: a rogue federated domain survives it.

Framework mapping

Practitioner checklist

• Remove every synced and non-human account from Global Administrator and other Tier 0 roles.
• Confirm every privileged account has a registered phishing-resistant MFA method.
• Treat every Entra Connect server as Tier 0: EDR onboarded, TPM enabled, admin access from privileged workstations only.
• Move Entra Connect to application-based authentication and remove the legacy Directory Synchronization Account.
• Restrict sync identity sign-ins with Conditional Access and alert on any use outside the sync server.
• Apply federatedTokenValidationPolicy and federatedIdpMfaBehavior settings and alert on federation changes.
• Alert on elevate access, tenant-wide Owner assignments, listKeys and lock or immutability deletions.
• Protect backups with locks, immutability and Key Vault purge protection, administered by separate identities, and test a restore.

Standards and references

• MITRE ATT&CK: Storm-0501 (G1053)
• Microsoft Threat Intelligence: Storm-0501's evolving techniques lead to cloud-based ransomware
• Microsoft Threat Intelligence: Storm-0501: Ransomware attacks expanding to hybrid cloud environments
• Microsoft Learn: Authenticate to Microsoft Entra ID by using application identity (Entra Connect Sync)
• Mandiant (Google Cloud): Sabbath ransomware affiliate program (UNC2190)
• MITRE ATT&CK: Domain or Tenant Policy Modification: Trust Modification (T1484.002)
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide · Identity Recovery Guide · Ransomware Groups Guide · Threat Actors Targeting SaaS and Cloud Identity Guide · Backup Security and Immutable Backup Guide