Misconfigured Security Controls Open the Door for Storm-2949

The Microsoft Defender Security Research Team and Microsoft Threat Intelligence documented a campaign in which Storm-2949 abused Microsoft Entra ID accounts to exfiltrate data from Microsoft 365 and Azure environments. The attack shows how cloud intrusions increasingly unfold through identity systems, administrative features, and legitimate platform capabilities rather than obvious malware or traditional endpoint compromise.

According to the report, the attackers used compromised identities to move across SaaS, PaaS, and IaaS layers while blending into normal cloud activity. Once they had access, they used Microsoft Graph API queries, cloud management functions, and administrative operations to enumerate users, applications, privileged identities, service principals, storage resources, databases, virtual machines, and other cloud assets.

Legitimate Features Became the Attack Path

The campaign reportedly started with targeted social engineering tied to Microsoft’s Self-Service Password Reset (SSPR) process. Attackers impersonated internal IT support staff, persuaded users to approve fraudulent MFA prompts, reset passwords, removed existing authentication methods, and registered their own devices as authenticators.

Microsoft said the same technique was repeated across multiple users, including IT personnel and senior leadership. The attackers appeared to understand which identities could help them advance access, reach sensitive systems, or unlock additional administrative paths.

After compromising identities, Storm-2949 moved deeper into Microsoft 365 and Azure. The attackers accessed OneDrive and SharePoint to identify and download sensitive files, including documents related to VPN configurations and remote access procedures. From there, the campaign expanded into Azure resources such as App Services, Key Vaults, Storage accounts, SQL databases, and virtual machines.

Much of the activity involved legitimate administrative capabilities. The attackers accessed publishing profiles, manipulated Key Vault access configurations, retrieved secrets, modified storage account network settings, listed storage account keys, changed SQL firewall rules, and abused Azure VM features such as Run Command and VMAccess. In one sequence, Microsoft said the attackers accessed dozens of Key Vault secrets in four minutes, then used those secrets to pursue access to a production application.

The Preventative Controls That Mapped to the Attack

The attack path depended on a chain of security control gaps across identity, SharePoint access, endpoint protection, application control, and event visibility. Each misconfigured security control gave the attackers an opening and more room to move after the initial identity compromise. Let’s take a closer look at the security controls mapped directly to the steps that Storm-2949 actually executed, and how proper configuration could have likely thwarted forward progress for Storm-2949.

Microsoft Entra ID Conditional Access: Harden the Identity Entry Point

Storm-2949’s initial access depended on abusing SSPR and MFA workflows and weakened security controls. Hardening the following Microsoft Entra ID Conditional Access controls could have helped:

Conditional Access > Authentication strengths

• The misconfiguration: User-interactive MFA methods (push notifications, voice call, or SMS) were available and accepted. The attacker socially engineered users into approving fraudulent prompts during the SSPR-driven flow.
• Recommended state: "Phishing-resistant MFA" authentication strength assigned to all administrators, IT staff, and senior leadership for all cloud apps. Apply the same strength for "Microsoft Azure Management" and "Microsoft Graph" cloud apps for any user.

Conditional Access > Policies > User action: Register security information

• The misconfiguration: After resetting the password and stripping existing methods, the attacker enrolled Microsoft Authenticator on their own device to establish persistent access and lock out the legitimate user.
• Recommended state: Policy targeting "Register security information" user action with grant requirement of trusted network location and/or compliant device. If enabled, the MFA registration from attacker IPs (176.123.4.44, 91.208.197.87) would have been blocked.

Conditional Access > Policies (SharePoint and OneDrive)

• The misconfiguration: The attacker accessed OneDrive via the web interface from their own infrastructure and downloaded thousands of files in a single action.
• Recommended state: Policy targeting "Office 365 SharePoint Online" cloud app.
  
  • Grant: require compliant device or Hybrid Entra joined.
  • Session: enable "Use app enforced restrictions" so the SharePoint admin center unmanaged-devices setting fires.
  • Session: route through Defender for Cloud Apps for download blocking.

Conditional Access > Policies (Azure management plane)

• The misconfiguration: The attacker invoked privileged Azure Resource Manager operations (publishxml, listKeys, firewallrules/write, VM extension deployment) directly from their own infrastructure.
• Recommended state: Policy targeting "Microsoft Azure Management" cloud app.
  
  • Grant: require compliant device and phishing-resistant MFA. This forces all ARM operations to originate from managed devices held by authenticated administrators.

Conditional Access > Policies (Microsoft Graph)

• The misconfiguration: The attacker ran a custom Python script against Microsoft Graph to enumerate users, roles, and service principals from their own infrastructure.
• Recommended state: Policy requiring compliant device for Graph API access by users, or a workload identity Conditional Access policy restricting Graph calls to known IP ranges.

Entra ID > Identity Protection > Sign-in risk policy (enforced via Conditional Access)

• The misconfiguration: Sign-ins from attacker infrastructure generated detections but were not blocked.
• Recommended state: Enable sign-in risk policy, scoped to all users, set to block at high risk. Require phishing-resistant MFA at Medium risk. Enable user risk policy with password change requirement at Medium and above.

Reach can identify when these types of policies are missing, mis-scoped, or not enforced for the right high-risk users and applications, and remediate to correct the policy gap and monitor for drift when authentication strength, device compliance, or session control settings change over time.

Microsoft SharePoint: Limit What Compromised Users Can Reach

Storm-2949 accessed OneDrive and SharePoint to find and download sensitive files, including documents related to VPN configurations and remote access procedures. Hardening the following Microsoft Sharepoint controls could have helped:

SharePoint admin center > Policies > Access control > Unmanaged devices

• ‍The misconfiguration: The attacker accessed OneDrive from their own infrastructure and used the web interface to download thousands of files in a single action.‍
• Recommended state: Set to "Block access" or at minimum "Allow limited, web-only access." Combined with the Conditional Access policy above so the setting is actually enforced.

SharePoint admin center > Policies > Access control > Idle session sign-out and Network location

• ‍The misconfiguration: Sessions remained active long enough for bulk download. No IP-based restriction limited where sessions could originate from.‍
• Recommended state: Idle session sign-out enabled with short timeout (1 hour). Network location restriction configured to trusted IP ranges if the organization operates from known networks.

SharePoint site permissions (site-level)

• ‍The misconfiguration: IT runbook content was accessible to broad IT personnel and senior leadership groups, both of which the attacker compromised. Multiple compromised accounts each had access to the sensitive site, which is why the bulk download was repeated.‍
• Recommended state: Limit site access to specific security groups only. Enforce via Restricted Access Control policy on the Microsoft 365 group so site permissions alone don't grant access.

Reach can proactively identify these types of security control blind spots, like SharePoint sites where unmanaged device access is allowed, sensitive content exposed to overly broad groups, or if restricted access policies are missing. From there, Reach can correct the misconfiguration and continuously validate that site permissions, sharing settings, and access restrictions stay aligned to policy.

Microsoft Defender for Endpoint and Intune: Block Tampering and Persistence

Storm-2949 also abused Azure virtual machines and used administrative capabilities to support persistence and further credential access. The attack path included script activity, VMAccess extension abuse, Run Command execution, and ScreenConnect installation on Azure VMs. Microsoft Defender for Endpoint and Intune controls map directly to this stage, and hardening the following Microsoft Defender for Endpoint controls could have helped:

Defender for Endpoint > Settings > Indicators

• ‍The misconfiguration: The ScreenConnect instance communicated with 185.241.208.243, and the attacker authenticated from 176.123.4.44 and 91.208.197.87.‍
• Recommended state: All three IOC IPs added as block indicators. Set web content filtering to block the "Remote monitoring and management" category as a baseline.

Defender for Endpoint > EDR in block mode and Automated Investigation and Response

• ‍The misconfiguration: Even with detections firing, response wasn't fast enough to prevent the script from completing its tampering and installation actions on multiple VMs.‍
• Recommended state: EDR in block mode enabled so Defender can act on malicious artifacts even when other AV is passive. Automated Investigation set to "Full - remediate threats automatically" for high-confidence detections.

Reach can rapidly identify and remediate these control misconfigurations, help validate whether Tamper Protection is properly deployed through Intune, whether known IOCs are blocked, whether application control is actually enforced, and whether event forwarding is configured. If endpoint controls weaken over time, Reach detects the configuration drift, including when allowlists become too permissive, or logging coverage changes.

Control Validation Has to Be Continuous

Storm-2949 shows how legitimate administration can become the attack path when controls are misconfigured, misaligned, or inconsistently enforced. Conditional Access policies change, SharePoint sites accumulate permissions, and temporary exceptions can become permanent. Endpoint settings drift, allowlist policies weaken, and logging pipelines break or get scoped too narrowly.

Security teams need to know when those changes create exposure. The practical lesson is to harden the controls that map to real attack paths, remediate the gaps that give attackers room to move, and continuously validate that those controls stay aligned to policy before a compromised identity becomes a broader cloud intrusion.

‍