When Identity Becomes the Attack Path, Recovery Must Restore Control
- Daniel Smith
- 14 hours ago
- 7 min read
The next major recovery failure may not start with data.
It may start with identity.
That is the real lesson from Microsoft’s Storm-2949 research. What began as targeted Microsoft Entra ID compromise rapidly evolved into a wider cloud infrastructure breach spanning Microsoft 365 applications, file-hosting services and Azure-hosted production environments. Microsoft describes the attack as crossing SaaS, PaaS and IaaS layers, with the attacker using legitimate cloud and Azure management features to gain control-plane and data-plane access.
That matters because identity is no longer just where people log in.
Identity is where control lives.
Users.
Groups.
MFA.
Admin roles.
Conditional Access.
Service principals.
Application assignments.
SaaS access.
Azure RBAC permissions.
Cloud resource access.
When identity is compromised, the organisation does not just face an access problem.
It faces a control problem.
And when the control plane has been abused, recovery is no longer just about getting users back online.
It is about restoring a known-good identity state the business can trust.
Storm-2949 shows the new recovery problem
Microsoft’s investigation breaks the attack into two major phases: targeted identity compromise and cloud infrastructure compromise. That distinction matters because it shows how quickly identity abuse can move beyond the account and into the wider cloud estate.
The attacker did not need to start with traditional endpoint malware.
The path began with identity.
Microsoft assessed with high confidence that Storm-2949 used social engineering consistent with abuse of Microsoft’s Self-Service Password Reset process. The attacker impersonated internal IT support, persuaded users to complete MFA prompts, reset passwords, removed existing authentication methods and registered their own authenticator to maintain access.
That is not just account takeover.
That is control-plane entry.
Once the attacker had valid cloud identities, the better question became:
What can those identities control?
The attack expanded through legitimate cloud operations
After the initial identity takeover, Microsoft says the attacker used Microsoft Graph API for directory discovery, enumerating users and applications, searching for privileged identities and mapping application-level access paths. The attacker also attempted to add credentials to a compromised service principal, showing an effort to create persistence beyond the original user accounts.
That is the part many recovery plans still miss.
The issue is not only that an account was compromised.
The issue is what that account could see, change, enumerate, assign, weaken or abuse.
Storm-2949 then used the compromised accounts to access and exfiltrate Microsoft 365 data, including OneDrive and SharePoint content. Microsoft noted that the attacker focused on sensitive files, including IT documents related to VPN configuration and remote access procedures.
From there, the attack shifted deeper into Azure.
Microsoft says the attacker targeted Azure App Services, Key Vaults, Storage accounts, SQL databases and virtual machines. This marked the move from identity-centric abuse and SaaS data theft into broader cloud infrastructure compromise.
That is why the recovery question changes.
It is no longer enough to ask:
Was the user account secured?
The better question is:
Which control paths did that identity open?
Key Vault shows why identity compromise can become production compromise
The Key Vault detail in Microsoft’s write-up is one of the most important parts of the story.
Microsoft says the attacker used privileged Azure RBAC permissions to manipulate Key Vault access configurations and access dozens of secrets. Those secrets included database connection strings, identity credentials and other sensitive material. Microsoft states this dramatically expanded the attack’s blast radius.
That is the point.
Identity was not the final target.
Identity was the path.
Once the attacker reached Key Vault, the breach could move from user accounts into production systems, databases, application credentials and cloud-hosted services.
That is where identity security becomes business recovery.
Because after this kind of compromise, the organisation has to answer difficult questions:
Which secrets were accessed?
Which credentials were exposed?
Which applications depended on those secrets?
Which RBAC roles were abused?
Which policies were changed?
Which accounts had persistent access added?
Which service principals were touched?
Which access paths need to be revoked or rebuilt?
Which state can still be trusted?
These are not simple helpdesk questions.
They are recovery questions.
Native recovery is not enough when identity runs the business
Most native identity recovery thinking is still too narrow.
It focuses on restoring access:
Reset the password.
Revoke the session.
Re-register MFA.
Disable the account.
Re-enable the account.
Remove the attacker’s authentication method.
All of that matters. But it is not enough.
After a control-plane compromise, the organisation needs to know what changed across the identity environment and whether it can return to a trusted state.
That means recovering more than the user.
It means recovering the relationships:
Users and groups.
Roles and privileges.
Policies and settings.
Service principals and applications.
Authentication methods.
Conditional Access.
SaaS assignments.
Cloud permissions.
Administrative relationships.
If those elements cannot be compared, validated and restored, recovery becomes manual reconstruction under pressure.
That is where the real business risk sits.
Recovery needs a known-good identity state
A clean recovery process needs a known-good identity state.
Not a vague assumption.
Not “we think everything is back to normal.”
Not “we reset the compromised users.”
A known-good state.
That means the organisation can compare the current identity environment against a trusted point in time and identify what changed.
Who was added?
Who was removed?
Which groups changed?
Which privileged roles were assigned?
Which MFA methods were modified?
Which policies were weakened?
Which applications gained access?
Which service principals were altered?
Which SaaS permissions changed?
Which relationships need to be restored?
Without that visibility, recovery becomes guesswork.
And in an identity-driven breach, guesswork is dangerous.
Because the attacker may have used legitimate administrative functions. They may have blended into expected behaviour. They may have created persistence through permissions, credentials, service principals or management-plane changes. Microsoft specifically notes that Storm-2949 used legitimate cloud and Azure management features in ways that allowed activity to blend into expected administrative behaviour.
That is exactly why identity recovery has to be treated differently.
The goal is not only to restore access.
The goal is to restore trust.
Security controls reduce risk. Recovery restores control.
Security controls are still essential.
Microsoft’s mitigation guidance includes least privilege, privileged account auditing, Conditional Access, MFA, phishing-resistant MFA for administrators and privileged users, protection against malicious MFA registrations, Entra ID protection, and monitoring across identity, cloud and endpoint environments.
Those controls matter.
But prevention and detection are not the same as recovery.
A strong identity security strategy should reduce the chance of compromise.
A strong identity recovery strategy should help the organisation regain control when compromise happens anyway.
That is the missing layer.
Identity security asks:
How do we stop this happening?
Identity recovery asks:
What do we do when the control plane has already been abused?
That second question is now a board-level issue.
Because the impact does not stop at login.
In the Storm-2949 case, the attacker moved through Microsoft 365 data, Azure resources, Key Vault secrets, Storage accounts, SQL databases and virtual machines. Microsoft also describes abuse of Azure VM management features such as VM extensions and Run Command to create access paths and conduct further discovery.
That is a business resilience problem.
Not just an identity administration problem.
The board-level question has changed
The old question was:
Can users get back in?
That is too narrow.
The better question is:
Can the organisation restore the trusted identity state the business depends on?
That includes:
Users.
Groups.
Roles.
Policies.
MFA methods.
Privileged access.
Application assignments.
Service principals.
SaaS integrations.
Administrative settings.
Cloud access relationships.
It also includes proof.
Can the organisation prove what changed?
Can it compare against a known-good state?
Can it recover the right objects and relationships?
Can it avoid manually rebuilding trust during an incident?
Can it restore identity outside the original blast radius?
That is the identity recovery conversation boards and executives need to understand.
Because when identity is the control plane, recovery failure is not just technical downtime.
It is loss of control.
Identity recovery is now part of cyber resilience
Storm-2949 is not important only because it involved Microsoft Entra ID.
It is important because it shows where cloud attacks are heading.
Attackers are targeting identities.
They are targeting administrative paths.
They are targeting cloud control planes.
They are targeting the relationships between identity, SaaS, secrets, workloads and infrastructure.
That changes the recovery conversation.
Backup is no longer only about files, mailboxes or SaaS records.
Recovery must include the identity layer that controls access to those systems.
For Microsoft Entra ID and Okta environments, that means identity backup and recovery need to be assessed as part of the organisation’s broader cyber resilience strategy.
Not as a future maturity item.
As a current control.
Because when identity becomes the attack path, recovery must restore more than data.
It must restore control.
Assess your identity recovery readiness
FullBackup helps Australian organisations assess identity recovery readiness across Microsoft Entra ID and Okta.
As a Keepit Elite Reseller Partner, FullBackup helps organisations strengthen SaaS and identity recovery with independent backup, immutable protection and recovery designed to sit outside the original blast radius.
Assess your identity recovery readiness:
Need a workload-specific view?
Explore Microsoft Entra ID recovery:
Explore Okta backup and recovery:
Sources
Primary source: Microsoft Security Blog - How Storm-2949 turned a compromised identity into a cloud-wide breach.
Supporting news source: Cyber Security News - Hackers Abuse Microsoft Entra ID Accounts to Exfiltrate Microsoft 365 and Azure Data.
Comments