CIO Brief: One Compromised Identity, Every Cloud Layer
The short version: In May 2026, Microsoft described an attack group, Storm-2949, that started by tricking employees into approving fake login requests during a password reset — and ended up controlling databases, storage, secrets vaults and servers across the victim's Azure cloud.
Why one identity reached everything
In many organizations, the same accounts that use email and Teams also hold permissions in Azure — sometimes broad ones like "Owner" or "Contributor." Once attackers controlled those identities, they used normal Azure management features to access secrets, change firewalls and take over servers.
The business impact
- Data theft across email, files, databases and applications.
- Persistent access through installed remote tools.
- Disabled security software on compromised servers.
Questions to ask your team
- How many people have permanent high-level access to our Azure environment?
- Could a password reset scam give an attacker those permissions?
- Are risky Azure features — like remotely running commands on servers — restricted and monitored?
- Are our secrets vaults and databases reachable only through private networks?
What good looks like
Phishing-resistant MFA for anyone with cloud admin rights, temporary rather than permanent admin access, password reset processes that resist social engineering, restricted management features and private access to data services.
The decision
Ask for the number of permanent Owner and Contributor assignments in Azure, and a plan to convert them to temporary, approved access.
Sources
- Storm-2949 (May 2026): From a Fake IT Call to an Azure-Wide Breach Incident Teardowns
- How to Harden SSPR, Azure RBAC and VM Run Command Against Identity-Led Attacks How-To & Hardening
- Detecting SSPR Social Engineering: Defender for Cloud and Sentinel KQL Detection & Response