Storm-2949: Hacker Group Turns MFA Into a "Golden Key" to Steal Azure Data

Summary of the campaign

The new attack campaign by threat actor group Storm-2949 has raised alarms about the risks of identity self-service features in cloud computing environments. By exploiting the Self-Service Password Reset (SSPR) feature combined with social engineering techniques targeting IT administrators and senior leadership, Storm-2949 successfully bypassed multi-factor authentication (MFA). The most serious consequence of this campaign is the ability to move laterally from M365 SaaS to the Azure Control Plane. The attacker abuses server management features like Azure VM extensions (Run Command, VMAccess) to install remote control tools (ScreenConnect), disable Microsoft Defender, and extract sensitive data from SQL Database, Key Vault, and App Services.

Businesses operating hybrid systems on Azure face a significant risk of intrusion if the SSPR configuration is too lax. The most urgent action now is to disable the new self-enrollment MFA feature without approval and limit the execution rights of Run Command on Azure virtual machines.

Who is Storm-2949?

Why is it called "Storm"?

Microsoft uses various prefixes to categorize threat actors: Storm-xxxx refers to groups being monitored but not yet fully identified or lacking sufficient data to classify as an official APT. Volt / Midnight / Sandstorm / Blizzard... are groups that have been more clearly identified in terms of origin or campaign.

Therefore: "Storm-2949" means a group actively monitored by Microsoft that hasn't been officially linked to any specific country or organization.

The main target

According to Microsoft, Storm-2949 targets: Azure admin accounts, IT administrators, service accounts, accounts with Owner/Contributor rights, senior personnel, and organizations with high-value cloud data. The ultimate goals are usually: data theft, cloud infrastructure access, stealing secrets and credentials, and eventually expanding privileges within the Azure tenant.

Characteristics of Storm-2949's operations

Unlike many traditional ransomware groups, Storm-2949 does not primarily rely on malware. Instead, this group:

Storm-2949 stands out by not requiring zero-day exploits, complex malware, or traditional persistence. According to recorded reports, the group frequently uses legitimate Azure features to operate, such as Microsoft Graph API, Azure management plane, Kudu console, Azure Run Command, VM extensions, publishxml/action, and Key Vault access.

This inadvertently makes their activities very difficult to distinguish from legitimate admin actions, hard to detect by EDR, and particularly challenging to create traditional IOCs.

Social engineering techniques are very strong.

One of the most dangerous aspects is how Storm-2949 perfectly combines tools and features: SSPR abuse, MFA fatigue, voice phishing (vishing), and impersonation of IT support.

Hackers often: trigger password resets, impersonate IT in phone calls, ask victims to approve MFA, and take over accounts within minutes.

Event timeline

Event timeline	Attack phase	Specific operations of Storm-2949
Day 1	Initial Access	Abuse SSPR and social engineering to take over the first Entra ID admin account; register the attacker's Authenticator device.
Day 1 (after 2 hours)	Directory Discovery	Use Graph API and custom Python scripts to scan all users, groups, and applications in the tenant.
Day 1 (after 4 hours)	SaaS Data Theft	Access OneDrive/SharePoint, download thousands of VPN configuration documents and IT network diagrams.
Day 2	lateral Movement (Cloud)	Use the RBAC permissions of the compromised account to read the PublishXML file via the API publishxml/action and access the Kudu Console on Azure App Services.
Day 2 (after 1 hour)	Credential Access	Pivoting through Azure Key Vault using an account with Owner permissions; altering access configurations and stealing dozens of database connection strings in just 4 minutes.
Day 3 - 5	Data Exfiltration	Change the IP firewall of Azure SQL and Storage Accounts; use a Python script to download large amounts of Blobs using SAS Tokens and Access Keys.
Day 5	Persistence & Evasion	Use VMAccess and Run Command on Azure VMs to create a local admin backdoor; disable Microsoft Defender Antivirus; install ScreenConnect.
Day 6	Cleanup & Discovery	Collect .pfx certificate from VM; scan files containing passwords; delete Windows Event Logs and traces of command execution on the host.

Detailed technical analysis

Initial Access & MFA Bypass via abusing SSPR

We observed that Storm-2949 did not use typical Adversary-in-the-Middle (AitM) phishing kits but instead directly exploited Microsoft's Self-Service Password Reset (SSPR) flow. The attacker collected a list of email addresses of senior IT personnel and executives, then proactively initiated the SSPR process on the Microsoft login portal.

Immediately, they made a vishing call impersonating the internal IT Support department or Microsoft's tech support, contacting the victim under the pretense of "urgent account verification due to suspicious login activity." The victim inadvertently pressed approve on the Microsoft Authenticator app.

After bypassing MFA, Storm-2949 proceeded to reset the password and delete all previously registered authentication methods of the victim (phone number, recovery email). The attacker registered a completely new Authenticator device under their control. This way, they established permanent access and completely locked the legitimate user out of the system.

Entra ID & Microsoft Graph API

After successfully taking over the identity, Storm-2949 quickly moved to the directory reconnaissance phase. Instead of manually using the Azure Portal interface, the attacker automated the activity with a custom Python script that directly called the Microsoft Graph API.

This script performs batch queries to list users in the Entra ID system, identify accounts assigned with administrative roles (Privileged Roles), and search for active applications and service accounts (Service Principals). During this process, the attacker attempted to add a new credential to a Service Principal to establish a backup access channel, but this action failed because the compromised account lacked sufficient privileges. Nevertheless, they quickly continued to exploit the aforementioned vishing/SSPR technique to seize three more administrative accounts.

Infiltrate OneDrive/SharePoint to gather network information

Before delving deeper into the cloud infrastructure, Storm-2949 focused on exploiting the victim's SaaS storage resources. Using the compromised accounts, they accessed OneDrive and SharePoint Online to search for technical documents containing sensitive keywords related to network diagrams, VPN setup documents, and remote access procedures.

The analysis team determined this was an important preparatory step to facilitate lateral movement from the cloud environment back to the company's on-premises network. After locating directories containing sensitive IT documents, the attacker performed a mass download of thousands of files directly to their device using the OneDrive web interface.

Attack Azure App Services & Kudu Console

Using the compromised administrative accounts with high Role-Based Access Control (RBAC) privileges on production Azure Subscriptions, Storm-2949 shifted focus to cloud services within the PaaS and IaaS layers. The attacker initially targeted a web application running on Azure App Service that contained sensitive data but encountered obstacles from the application's network IP restriction policies.

To overcome this barrier, the attacker shifted focus to auxiliary web apps within the ecosystem that had more lenient security policies. Storm-2949 exploited Azure's management API to invoke functions:

This API allows for the export of the web application's PublishXML configuration, which contains Basic Authentication credentials used for Web Deploy and FTP. With this information, the attacker directly logged into the Kudu Console, an advanced management interface integrated with Azure App Service. The Kudu Console provides the attacker with a direct command execution shell, file system browsing rights, and access to all environment variables containing application secrets without having to bypass the usual security gateways.

Compromise Secrets in Azure Key Vault

Once Storm-2949 understood the application's architecture through the Kudu Console, they discovered a compromised administrative account holding the Owner role on an Azure Key Vault containing the core credentials of the production system. Within just 4 minutes, the attacker modified the Key Vault's access policies to grant themselves permissions, then queried all the secrets stored there.

• Extract dozens of database connection strings.

• Steal API keys of linked services.

• Obtain login credentials of the main web application admin account.

As soon as they obtained these credentials, the attacker successfully logged into the targeted production web application, immediately changed the application's password to maintain exclusive control, and began extracting data from it..

Modify the firewall configuration to drain Azure SQL & Storage Accounts.

To execute their plan of large-scale data theft from backend repositories, Storm-2949 continued to exploit RBAC privileges to directly interfere with the network configuration of Azure SQL Server and Azure Storage Accounts.

For the Azure SQL Server service, the attacker altered firewall rules using a write command:

This action registered the attacker's IP on the allowlist for direct database connections. Storm-2949 then used the credentials obtained from the Key Vault to log into the database and extract sensitive information. To cover their tracks, they deleted these firewall rules immediately after completing the session.

For Azure Storage Accounts, the attacker used a similar tactic by modifying the firewall settings to allow public access from a group of IPs they controlled. At the same time, the attacker called the API:

To retrieve the Storage Account Keys and generate Shared Access Signatures (SAS) to establish a static, non-interactive access channel. The attacker ran a custom Python script using the Azure SDK for Storage library on their machine to navigate the Blob structure and automatically download all critical business documents over several consecutive days.

Abuse VM Extensions & deploy ScreenConnect Backdoor

Alongside data extraction, Storm-2949 attempted to expand their control to the IaaS layer by attacking Azure Virtual Machines (VMs). The attacker exploited two common system administration features: VMAccess and Run Command.

1. Exploiting VMAccess: The attacker deployed the VMAccess extension configuration to the VM to reset passwords and create a new local administrator account on the virtual machine, enabling direct login via RDP/SSH.

2. Abusing Run Command: Using the Run Command feature to execute a PowerShell script at the SYSTEM privilege level on the VM's operating system without going through the internal network. The attacker attempted to query the Azure Instance Metadata Service (IMDS) at the static IP address 169.254.169.254 to steal the Managed Identity token associated with this VM to escalate privileges back to the Key Vault. However, this attempt failed because the VM's Managed Identity was not granted access to the Key Vault beforehand.

To maintain long-term control over the VM and avoid detection by the SOC team, the PowerShell script executed via Run Command carried out a series of actions to undermine system defenses:

Set-MpPreference -DisableRealtimeMonitoring $true

Set-MpPreference -DisableBehaviorMonitoring $true

After successfully disabling the real-time protection and behavior monitoring features of Microsoft Defender Antivirus, the attacker downloaded and installed the ScreenConnect remote management software (RMM) from their command and control (C2) server. This tool was carefully disguised as legitimate system files, and the ScreenConnect service was renamed to mimic default Windows operating system components.

Through ScreenConnect, the attacker conducted deeper reconnaissance within the internal domain, searching for shared files containing clear-text passwords and exporting .pfx certificate files with private keys to support future attacks. Before ending the session, the attacker executed commands to delete all Windows Event Logs, PowerShell history, and temporary directories to maximize the difficulty of digital forensics.

IOC

IP Addresses

• 176.123.4[.]44

• 91.208.197[.]87

• 185.241.208[.]243

MITRE ATT&CK

Tactic	Technique ID	Technique Name	Description of Storm-2949's actual activities
Initial Access	T1566	Phishing	Using vishing calls to persuade users to approve MFA.
	T1078.004	Valid Accounts: Cloud Accounts	Abusing valid Entra ID accounts after successful takeover.
Execution	T1059.001	PowerShell	Run commands to disable Defender and install ScreenConnect on the VM.
	T1609	Charting / Cloud Administration Command	Using Azure's Run Command feature to execute scripts at the operating system level.
Persistence	T1098.005	Account Manipulation: Device Registration	Register the attacker's new Authenticator device to the Entra ID account.
	T1136.003	Create Account: Cloud Account	Using VMAccess to create a new local admin account on Azure VM.
Defense Evasion	T1562.001	Impair Defenses: Disable or Modify Tools	Disable Windows Defender's Real-time & Behavior Monitoring.
	T1070.001	Indicator Removal: Clear Windows Event Logs	Delete Event Logs and command history on the compromised virtual machine.
	T1564.001	Hide Artifacts: Service Masquerading	Rename the ScreenConnect service to masquerade as a legitimate Windows process.
Credential Access	T1555.004	Credentials from Password Stores: Private Keys	Export sensitive .pfx certificates from the virtual machine system.
	T1528	Steal Application Access Token	Request an IMDS token via address 169.254.169.254 to access Key Vault.
	T1212	Exploitation for Credential Access	Export PublishXML to retrieve the Deploy password for Azure App Services.
Collection	T1114.002	Email Collection: Cloud Email	Collect sensitive information from SaaS services.
	T1213	Data from Information Repositories	Break into OneDrive and SharePoint to download thousands of VPN configuration documents.
Exfiltration	T1020	Automated Exfiltration	Use a Python script to automatically upload blobs and databases through the opened firewall IP.

Expert analysis

The attack by Storm-2949 demonstrates exceptional technical maturity and reflects a major trend in cybersecurity: the shift in targets from physical endpoints to the control plane of clouds. The attackers don't need to write complex malware or exploit zero-day vulnerabilities in the operating system; instead, they meticulously study the operational mechanisms of the Azure platform, abusing legitimate administrative features designed to support IT engineers (such as SSPR, Run Command, Kudu Console, or VMAccess).

The analysis team observed that in the Vietnamese market, the trend of migrating infrastructure to the cloud is extremely strong, but awareness of cloud information security often does not match this pace.

• Misunderstanding about security responsibility: Many organizations believe that once they move their systems to Azure or AWS, the cloud service provider will be responsible for all protection. In reality, the Shared Responsibility Model clearly states: the provider only protects the physical infrastructure (Security OF the Cloud), while secure configuration of identity, RBAC permissions, and data protection (Security IN the Cloud) is entirely the responsibility of the business.

• Abuse of privileges and monitoring vulnerabilities: Assigning the Owner or Contributor role directly to individual accounts on Azure Subscription is common. When these accounts are compromised through MFA fatigue or vishing, the entire PaaS and IaaS system collapses immediately. More concerning is that traditional SOC monitoring systems, which focus on collecting logs from Endpoint/OS, will be completely "blind" to actions like changing Key Vault policies, exporting PublishXML, or modifying Azure Storage firewall rules—actions that are legitimate at the Management Plane level.

Storm-2949's campaign is a profound wake-up call: To protect the cloud, organizations must ensure correlated visibility across all three pillars: Identity (Entra ID), Control Plane (Azure Activity logs), and Endpoint (EDR on VMs).

Recommendation

Immediate Action (Within 24 hours)

1. Deploy Phishing-Resistant MFA: Configure policies to mandate the use of phishing-resistant MFA methods (such as FIDO2 physical security keys or Windows Hello for Business) for all accounts with administrative roles (Global Admin, Subscription Owner/Contributor).

2. Review MFA-registered devices: Conduct a thorough examination of all devices (Entra ID Joined/Registered Devices) associated with administrative accounts to identify and revoke any suspiciously registered devices.

3. Review SSPR activity: Query login logs to search for consecutive successful self-service password reset (SSPR) events, followed by actions registering new authentication methods or changing Service Principal credentials.

Short-term Action (Within 1 - 7 days)

1. Isolate Key Vault & Storage Account configurations:

   • Completely prohibit public network access to Azure Key Vault, Azure SQL, and Azure Storage. Replace it with Private Endpoints to restrict access only from trusted internal virtual networks (VNETs).

   • Enable Purge Protection and Soft Delete on Azure Key Vault with a minimum retention period of 90 days.

2. Review and Decompose RBAC Permissions:

   • Never use direct Owner permissions for daily operations. Replace them with a Just-In-Time (JIT) access model using Entra Privileged Identity Management (PIM).

   • Separate the infrastructure admin role (Subscription Admin) from the key management role (Key Vault Secrets Officer).

3. Monitor sensitive activity on the Management Plane: Configure real-time security alerts (KQL alerts) in the SIEM/Microsoft Sentinel system to detect unusual administrative API calls such as:

   • microsoft.Web/sites/publishxml/action

   • microsoft.Storage/storageAccounts/listkeys/action

   • microsoft.sql/servers/firewallrules/write

Long-term Plan (Ensure a Secure and Sustainable Architecture)

1. Switch to Managed Identities: Completely eliminate storing static accounts (username/password) or hard-coded connection strings in source code or web application configuration files. Transition to using System-Assigned/User-Assigned Managed Identities for automatic authentication between Azure resources (e.g., from App Service to Key Vault/Storage).

2. Store logs centrally for at least one year: Configure the export of activity logs (Azure Activity Logs, Key Vault Diagnostic Logs, App Service Logs) to a centralized storage (Log Analytics Workspace) and maintain a minimum retention period of one year to support incident investigation in case of anomalies.

3. Implement a Zero Trust architecture: Continuously assess the security of cloud configurations using CSPM (Cloud Security Posture Management) solutions to detect misconfigurations early before attackers can exploit them.

Reference

Microsoft Self-Service Password Reset abused in Azure data theft attacks

How Storm-2949 turned a compromised identity into a cloud-wide breach | Microsoft Security Blog