"to exfiltrate as much sensitive data from a target organization’s high-value assets as possible," Microsoft says — a blunt summary of an intrusion that combined social engineering, cloud administration features, and scripted data-pull techniques to drain production Microsoft 365 and Azure environments.
Storm-2949’s social engineering and SSPR abuse
Microsoft tracks the actor responsible as Storm-2949. According to the company’s account, the operation began with targeted social engineering of users in privileged roles — IT staff and senior leadership — to obtain Microsoft Entra ID credentials. The attacker exploited the Self-Service Password Reset (SSPR) flow by initiating password resets and tricking victims into approving multi-factor authentication (MFA) prompts; the adversary posed as IT support and claimed urgent verification was required. Once the ruse succeeded, the attacker reset the password, removed existing MFA controls, and enrolled Microsoft Authenticator on their own device to consolidate access.
How the actor moved through Microsoft 365
With hijacked accounts, Storm-2949 used the Microsoft Graph API and custom Python scripts to enumerate users, roles, applications, and service principals to assess persistence and access opportunities. The intruder focused on OneDrive and SharePoint, searching specifically for VPN configurations and operational IT files that could support lateral movement from cloud resources into endpoint networks. In one documented instance, the actor used the OneDrive web interface to download thousands of files in a single action to their infrastructure. Microsoft says that pattern of bulk data theft repeated across compromised identities, likely because different accounts gave the attacker access to different folders and shared directories.
Pivot into Azure: RBAC, Key Vaults, VMs, SQL and storage
Storm-2949 expanded beyond Microsoft 365 into Azure production subscriptions by compromising identities that held privileged custom Azure role-based access control (RBAC) roles. With those RBAC permissions, the actor uncovered and extracted sensitive assets from production-based subscriptions. Techniques included deploying FTP, Web Deploy, and using the Kudu console for Azure App Services to browse file systems, inspect environment variables, and execute commands within app contexts.
The actor modified Azure Key Vault access settings and stole dozens of secrets, explicitly including database credentials and connection strings. They altered firewall and network access rules on Azure SQL servers and Storage accounts, retrieved storage keys and SAS tokens, and exfiltrated data using custom Python scripts. Azure VM management features — VMAccess and Run Command — were abused to create rogue administrator accounts, run remote scripts, and harvest credentials, enabling deeper access across the environment.
Observed tools, persistence and forensic cleanup
In later stages Microsoft observed the deployment of ScreenConnect as a remote access tool on compromised systems. The attacker also attempted to disable Microsoft Defender protections and to wipe forensic evidence, moves intended to preserve persistence and frustrate detection. Throughout the operation, Microsoft captured indicators of compromise and provided extensive mitigation and detection guidance alongside those IOCs.
What this means for technologists, procurement leaders, and end users
- Technologists and security teams: Microsoft recommends adopting the principle of least privilege, limiting Azure RBAC permissions, enabling conditional access policies, and adding MFA protection for all users. For privileged roles, the company specifically advises ensuring phishing-resistant MFA and monitoring for high-risk Azure management operations. The firm also recommends retaining Azure Key Vault logs for up to a year, reducing access to Key Vaults, and restricting public access.
- Procurement and cloud operations leaders: The attacks underline the need to require and validate cloud hardening controls from vendors and third parties — including RBAC limits, Key Vault protections, data-protection options for Azure Storage, and log-retention practices — as part of sourcing and contract obligations.
- End users and privileged role holders: The intrusion shows how convincing an SSPR-based social-engineering ruse can be; Microsoft’s account describes attackers posing as IT support and pressing for urgent MFA approval. Users with elevated access should expect targeted prompts and treat unsolicited password resets and verification requests as high-risk.
Microsoft notes that "Storm" is a temporary designation used for activity that is new or developing. The company has packaged indicators of compromise, detailed mitigation steps, and monitoring guidance to help defenders respond.
Taken together, the episode is a reminder that cloud-native administration features and convenience flows — SSPR, RBAC, Key Vault access, and VM management tools — can become attack surfaces when combined with credential theft and social engineering. The next step for affected organizations is tactical: apply the recommended hardening steps, ingest the provided IOCs, and validate that conditional access and phishing‑resistant MFA actually block the described techniques.
Original report: https://www.bleepingcomputer.com/news/security/microsoft-self-service-password-reset-abused-in-azure-data-theft-attacks/
