News thumbnail
Business / Tue, 19 May 2026 CyberSecurityNews

Hackers Abuse Microsoft Entra ID Accounts to Exfiltrate Microsoft 365 and Azure Data

A threat actor known as Storm-2949 has launched a sophisticated, multi-layered cloud attack campaign targeting Microsoft Entra ID accounts to steal sensitive data from Microsoft 365 and Azure environments. Instead, the attackers used legitimate Microsoft cloud management tools and administrative features to silently move through an organization’s entire cloud infrastructure. Hackers Abuse Microsoft Entra ID AccountsStorm-2949 gained initial access through a social engineering technique that abused Microsoft’s Self-Service Password Reset process. Azure-Wide Data Breach and Lateral MovementWith compromised accounts holding privileged Azure role-based access control permissions, Storm-2949 moved aggressively into the Azure environment. ]44 Attacker egress IP address used during the campaign IP Address 91.208.197[.

A threat actor known as Storm-2949 has launched a sophisticated, multi-layered cloud attack campaign targeting Microsoft Entra ID accounts to steal sensitive data from Microsoft 365 and Azure environments.

The campaign was recently uncovered and has raised serious concerns about how modern attackers can abuse legitimate cloud features to carry out large-scale data theft across organizations.

What makes this attack stand out is that it did not rely on traditional malware or device-level exploits. Instead, the attackers used legitimate Microsoft cloud management tools and administrative features to silently move through an organization’s entire cloud infrastructure.

Sensitive files, database credentials, application secrets, and stored data all fell into the attackers’ hands.

Microsoft said in a report shared with Cyber Security News (CSN) that Storm-2949 executed a relentless campaign focused on exfiltrating as much sensitive data as possible from a target organization’s high-value assets.

The attack spanned Microsoft 365 applications, file-hosting services, and Azure-hosted production environments, hitting SaaS, PaaS, and IaaS layers across the board.

The breach began with a targeted identity compromise and quickly escalated into a full takeover of the organization’s cloud infrastructure.

Analysts noted that the attackers deliberately targeted IT staff and senior leadership, showing clear signs of prior reconnaissance and a calculated plan to maximize damage.

This incident highlights a growing shift in how threat actors approach cloud environments. Rather than targeting individual devices, attackers are zeroing in on cloud identities and control-plane access, where they can blend with expected administrative behavior and go undetected for extended periods.

Hackers Abuse Microsoft Entra ID Accounts

Storm-2949 gained initial access through a social engineering technique that abused Microsoft’s Self-Service Password Reset process.

Storm-2949 attack (Source – Microsoft)

The attackers impersonated internal IT support staff and tricked targeted users into approving fraudulent multi-factor authentication prompts, effectively handing over full account control.

Once a user approved the fake prompt, the attackers reset the account password, removed all existing authentication methods, and registered their own device as a new authenticator.

This gave them persistent access while locking the real user out entirely. The same technique was repeated across multiple accounts within the same organization.

After establishing a foothold, the attackers used a custom Python script and Microsoft Graph API queries to enumerate user accounts and privileged identities within the tenant.

They then turned to Microsoft 365, targeting OneDrive and SharePoint to locate and bulk-download thousands of sensitive files, particularly those related to VPN configurations and remote access procedures.

Azure-Wide Data Breach and Lateral Movement

With compromised accounts holding privileged Azure role-based access control permissions, Storm-2949 moved aggressively into the Azure environment.

They targeted Azure App Services, Key Vaults, Storage accounts, and SQL databases, using legitimate management-plane operations to extract secrets and reconfigure access controls.

By accessing a Key Vault that contained database connection strings and identity credentials, the attackers dramatically expanded the breach’s blast radius.

Within just four minutes, they read dozens of secrets and used those credentials to authenticate into the primary production web application they had been pursuing all along.

To pull data from Azure Storage, the attackers manipulated network access settings and abused storage account key listing operations to obtain Shared Access Signature tokens.

They then used a custom Python script to systematically download large volumes of data over several days, while SQL server firewall rules were altered to allow access and then deleted to cover their tracks.

The attackers also compromised Azure Virtual Machines using the VMAccess extension to create backdoor admin accounts, and deployed ScreenConnect after attempting to disable Microsoft Defender Antivirus.

Before exiting, they cleared Windows event logs and removed local artifacts to complicate any forensic investigation.

Organizations facing similar threats are encouraged to enforce phishing-resistant multi-factor authentication for all privileged users, apply least privilege across Azure role assignments, and restrict public network access to Key Vaults and Storage accounts.

Security teams should monitor suspicious management-plane activity and audit the use of Azure VM features such as Run Command and VMAccess to stop this type of lateral movement.

Indicators of Compromise (IoCs):-

Type Indicator Description IP Address 176.123.4[.]44 Attacker egress IP address used during the campaign IP Address 91.208.197[.]87 Attacker egress IP address used during the campaign IP Address 185.241.208[.]243 ScreenConnect instance infrastructure controlled by the attacker

Note: IP addresses and domains are intentionally defanged (e.g., [.] ) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.

© All Rights Reserved.