Storm-2949 abused Microsoft Entra ID accounts to steal Microsoft 365 and Azure data

Microsoft says a threat actor tracked as Storm-2949 turned compromised Microsoft Entra ID accounts into a wider cloud breach that hit Microsoft 365 data, Azure resources, and production environments.

The attackers did not rely on traditional malware at the start of the campaign. Instead, they used social engineering, Microsoft’s Self-Service Password Reset flow, legitimate cloud management features, Microsoft Graph API queries, and Azure control-plane operations to move through the victim environment.

The campaign shows how one compromised identity can become a cloud-wide breach when privileged accounts have broad access to Microsoft 365 files, Azure Key Vault secrets, storage accounts, SQL databases, virtual machines, and production web apps.

What Microsoft found

Microsoft Defender Security Research described Storm-2949 as a methodical threat actor focused on exfiltrating as much sensitive data as possible from high-value cloud assets.

The campaign started with targeted identity compromise and expanded into Microsoft 365 and Azure. The attackers targeted IT personnel and senior leadership, which suggests they had already identified users with useful access.

Once inside, Storm-2949 blended into normal administrative activity. Microsoft said the actor used legitimate cloud and Azure management features to gain control-plane and data-plane access, execute code remotely on virtual machines, and reach sensitive cloud resources.

Item	Details
Threat actor	Storm-2949
Main target	Microsoft Entra ID, Microsoft 365, and Azure environments
Initial access method	Social engineering and suspected SSPR abuse
Key services abused	Microsoft Graph API, OneDrive, SharePoint, Azure Key Vault, Azure Storage, Azure SQL, Azure VMs
Main objective	Large-scale data exfiltration from high-value cloud assets
Notable tool	ScreenConnect remote access software in later attack stages

How the attackers abused password reset

Microsoft assesses with high confidence that Storm-2949 used a technique consistent with Self-Service Password Reset abuse.

The attacker would start a password reset process for a targeted employee, then impersonate internal IT support and convince the user to approve MFA prompts. The prompts looked legitimate because they came from a real Microsoft identity flow.

After the victim approved the prompts, the attacker reset the account password, removed existing authentication methods, and enrolled Microsoft Authenticator on an attacker-controlled device. This locked out the legitimate user and gave the attacker persistent access.

What happened after account takeover

After taking over the first account, Storm-2949 used Microsoft Graph API queries and custom Python scripts to enumerate the tenant. The actor searched for users, applications, service principals, roles, and other paths to expand access.

The attackers also tried to add credentials to a service principal for persistence. Microsoft said that attempt failed due to insufficient permissions, but the actor continued mapping application-level access paths.

The same social engineering and password reset technique was then used against additional accounts. Microsoft said the attackers compromised three more cloud user accounts through similar activity.

• Enumerated users and applications through Microsoft Graph API.
• Searched for privileged identities and high-value targets.
• Explored service principals for persistence opportunities.
• Compromised additional user accounts through repeated identity abuse.
• Used legitimate cloud features to reduce suspicion.

Microsoft 365 files were downloaded at scale

Storm-2949 used the compromised user accounts to access OneDrive and SharePoint. Microsoft said the attackers looked for sensitive documents, including VPN configurations and remote access procedures.

That search pattern suggests the actor wanted to bridge cloud access into endpoint and internal network access. IT files can reveal private infrastructure, access instructions, naming conventions, credentials, and trusted pathways into production systems.

In one case, Microsoft said Storm-2949 used the OneDrive web interface to download thousands of files in one action to attacker infrastructure. The same pattern was repeated across compromised accounts, likely because each user had access to different folders and shared directories.

Storm-2949 then pivoted into Azure

The attack expanded when compromised identities had privileged custom Azure RBAC roles on several Azure subscriptions. That gave Storm-2949 access to high-value production assets.

Microsoft said the actor targeted Azure App Services, Azure Key Vaults, Azure Storage accounts, and Azure SQL databases. These services supported the victim organization’s cloud-hosted production ecosystem.

The shift from Microsoft 365 to Azure was important. It moved the campaign from file theft into production application compromise, secret theft, and cloud infrastructure abuse.

Azure target	How Storm-2949 abused it
Azure App Services	Retrieved publishing profiles and used Kudu-related access paths.
Azure Key Vault	Manipulated access settings and read secrets.
Azure Storage	Changed network access settings and used keys or SAS tokens for downloads.
Azure SQL	Changed firewall rules to enable access, then deleted rules to hide activity.
Azure VMs	Used VMAccess and Run Command to create access and run scripts.

Key Vault secrets expanded the breach

Azure Key Vault became a major turning point in the attack. Microsoft said Storm-2949 manipulated Key Vault access configurations and read dozens of secrets within four minutes.

Those secrets included database connection strings, identity credentials, and other material that widened the attack’s reach. Some credentials helped the actor reach the production web application it had been pursuing.

After authenticating to that application, the attacker changed its password to retain control and began exfiltrating sensitive data from it.

Storage and SQL data theft continued for days

Storm-2949 also targeted Azure Storage accounts and Azure SQL resources. The actor changed SQL firewall rules, connected with credentials taken from Key Vault, and then deleted modified rules to make investigation harder.

For Azure Storage, the actor changed network access settings to allow access from attacker-owned IP addresses. The attacker also abused storage account key listing operations to obtain SAS tokens and account keys.

Microsoft said Storm-2949 used a custom Python script with the Azure SDK for Storage to enumerate and download blobs to an attacker-controlled endpoint. This storage exfiltration continued over multiple days.

Azure VMs were abused for lateral movement

The attackers also used Azure VM management features, including Run Command and the VMAccess extension. These features have legitimate administrative uses, but they can become dangerous when attackers control privileged identities.

Microsoft said Storm-2949 used VMAccess to create a new local administrator account on a targeted virtual machine. The actor also used Run Command to run PowerShell scripts for credential harvesting, discovery, remote access, and defense evasion.

In later stages, the attackers attempted to disable Microsoft Defender Antivirus and deployed ScreenConnect for persistent remote access. They also cleared Windows event logs and removed local artifacts to make forensic work harder.

Observed behavior	Security meaning
SSPR abuse	Shows why MFA prompts can still be socially engineered.
Graph API enumeration	Reveals tenant mapping and privilege discovery activity.
OneDrive and SharePoint mass downloads	Signals large-scale Microsoft 365 file theft.
Key Vault secret reads	Can expose production credentials and connection strings.
Storage key listing	Can enable bulk data downloads outside normal user sessions.
VMAccess and Run Command use	Can create backdoor admin access and execute scripts on VMs.

Why identity controls matter more now

The Storm-2949 campaign shows that cloud identity is now a primary attack surface. Attackers do not need to exploit a server if they can trick a privileged user into approving an identity reset.

Once the attacker controls an account, normal admin tools can become attack tools. That makes identity logs, cloud audit trails, and management-plane activity as important as endpoint alerts.

Organizations should treat privileged Entra ID users, Azure role assignments, service principals, and workload identities as sensitive infrastructure, not just account records.

How organizations can reduce the risk

Microsoft recommends phishing-resistant multifactor authentication for privileged users. This includes methods such as passkeys, FIDO2 security keys, Windows Hello for Business, and certificate-based authentication.

Conditional Access can also help by requiring compliant devices, trusted locations, or stronger authentication for sensitive actions. Microsoft Entra protected actions can require stronger checks before high-risk administrative changes.

Azure administrators should also reduce standing privileges, protect Key Vault access, restrict public network access to sensitive services, and monitor VM extensions and Run Command activity closely.

1. Require phishing-resistant MFA for administrators and privileged users.
2. Restrict SSPR registration and reset flows for high-value accounts.
3. Use Conditional Access policies for privileged actions and sensitive cloud resources.
4. Review Azure RBAC roles and remove unnecessary standing privileges.
5. Limit Key Vault access to specific identities and trusted networks.
6. Disable public access to critical Key Vaults and use Private Link where possible.
7. Monitor Microsoft Graph API enumeration from unusual users or devices.
8. Alert on large OneDrive and SharePoint downloads.
9. Review storage account key listing and SAS token creation activity.
10. Audit Run Command, VMAccess, and new local administrator creation on Azure VMs.

Indicators Microsoft listed

Microsoft published indicators connected to the Storm-2949 activity, including attacker egress IP addresses and ScreenConnect infrastructure. Security teams should treat these as starting points, not as complete detection coverage.

Indicator type	Indicator	Description
IP address	176.123.4[.]44	Attacker egress IP address.
IP address	91.208.197[.]87	Attacker egress IP address.
IP address	185.241.208[.]243	Attacker-controlled ScreenConnect infrastructure.

What defenders should monitor

Defenders should look beyond sign-in events. Storm-2949 used a chain of identity, Microsoft 365, Azure management-plane, and endpoint actions that may look normal when viewed one event at a time.

High-risk signals include successful SSPR events for privileged users, MFA method removal, new authenticator registration, mass file downloads, Graph API enumeration, Key Vault secret reads, storage key listing, firewall rule changes, and VM extension abuse.

The best detection strategy combines identity, endpoint, cloud, and data signals. Microsoft said behavior-based detections across these areas help teams correlate activity that individual logs may not make obvious.

• New MFA registration shortly after password reset.
• Removal of existing authentication methods from privileged accounts.
• Large OneDrive or SharePoint downloads from unusual locations.
• Graph API calls that enumerate users, apps, roles, and service principals.
• Key Vault access policy changes followed by rapid secret reads.
• Storage account network changes and key listing operations.
• SQL firewall rule creation followed by deletion.
• Run Command or VMAccess use outside normal admin windows.
• ScreenConnect installation on Azure VMs.
• Windows event log clearing after remote command activity.

The cloud control plane is now a target

Storm-2949’s campaign shows how cloud attacks increasingly start with identity and then move through legitimate administrative features. This can produce fewer classic malware indicators while still causing major data loss.

The strongest defense combines phishing-resistant authentication, least privilege, tight Key Vault and storage controls, endpoint visibility, and monitoring across Microsoft 365 and Azure management activity.

For organizations running Microsoft cloud environments, the lesson is direct. Protect identities as production infrastructure, limit what each account can reach, and investigate suspicious cloud administration activity before it becomes a full breach.

FAQ