How to Harden SSPR, Azure RBAC and VM Run Command Against Identity-Led Attacks

Storm-2949 moved from a social-engineered password reset to Azure-wide control using RBAC permissions and VM management features. Here is how to harden each step.

Step 1: Harden SSPR and MFA registration

• Require two strong methods for SSPR; remove SMS and security questions where possible.
• Protect security info registration with Conditional Access (require compliant device, trusted location or Temporary Access Pass).
• Notify users and admins when passwords or MFA methods change.
• Consider disabling SSPR for privileged accounts and handling their resets through a stronger process.

Step 2: Reduce standing Azure RBAC

• Find Owner, Contributor and User Access Administrator assignments at management group and subscription scope.
• Move them to PIM eligible assignments with approval and MFA on activation.
• Use narrower built-in roles (for example, Key Vault Secrets User rather than Contributor).
• Remove direct user assignments in favor of groups.

Step 3: Protect Key Vault, Storage and SQL

• Use RBAC authorization for Key Vault, with separation between administrators and secret readers.
• Private endpoints and disabled public network access.
• Disable shared key access on Storage.
• Immutable storage for critical data.
• Diagnostic logs to Log Analytics.

Step 4: Restrict VM management features

• Limit Microsoft.Compute/virtualMachines/runCommand/action and .../extensions/write permissions to a small group.
• Use Azure Policy to allow only approved extensions (deny VMAccess where not needed).
• Alert on Run Command and extension deployment.

Step 5: Protect endpoints

• Tamper protection in Defender for Endpoint so attackers can't disable it.
• Block unapproved remote access tools (ScreenConnect and others) with application control.

Verify

Simulate a compromised standard user: what Azure resources can they reach? What can a help desk reset unlock?