In This Article
- What Microsoft Disclosed About Storm-2949
- The SSPR Abuse Path: How One Phone Call Becomes a Cloud-Wide Breach
- Why This Lands So Hard on Banks, Credit Unions, and Mortgage Companies
- Microsoft 365 Hardening: Six Controls to Configure This Week
- Azure Hardening: The Four Management-Plane Operations to Alert On
- A Five-Day Response Plan for Banks, Credit Unions, and Mortgage Companies
- Frequently Asked Questions
On Monday, May 18, 2026, Microsoft Threat Intelligence published a profile on a threat actor they call Storm-2949. The post is worth reading in full if you run identity for a bank, a credit union, or a mortgage company. The short version is the kind of story that should change how every financial institution thinks about cloud identity this week.
Storm-2949 turned one compromised cloud identity into a cloud-wide breach. The attacker exfiltrated data from Microsoft 365 applications, file-hosting services, and Azure-hosted production environments. There was no ransomware payload, no novel malware family, no fresh CVE. The attacker reset a few passwords, talked some users through a few legitimate-looking multifactor prompts, and then used regular cloud and Azure management features to walk from one Entra ID account into OneDrive, SharePoint, App Service, Key Vault, Storage, and SQL.
That is the part worth absorbing. The whole campaign ran on identity and configuration. The same controls a community bank, a credit union, or a mortgage company already pays for inside Microsoft 365 and Microsoft Azure can break this attack chain. The work this week is making sure those controls are turned on, monitored, and aimed at the right places.
What Microsoft Disclosed About Storm-2949
Microsoft Threat Intelligence describes Storm-2949 as a threat actor focused on one outcome: extracting as much sensitive data as possible from a target organization's high-value assets. The campaign that Microsoft documented unfolded across two clear phases, identity compromise inside Microsoft Entra ID and then cloud infrastructure compromise inside Microsoft Azure. Neither phase used traditional malware to get in. Both phases used legitimate cloud features the way an administrator would, just from the wrong side of the keyboard.
In the identity phase, Storm-2949 abused Microsoft's Self-Service Password Reset feature combined with social engineering to take over a small set of Microsoft Entra ID accounts. The victims were not random. Microsoft assesses that the attacker deliberately selected IT personnel and senior leadership, the identities that carry privileged role assignments and broad administrative reach. Once the attacker had a foothold, they used Microsoft Graph API queries to enumerate other users and applications inside the tenant, then repeated the same social engineering pattern against three additional cloud accounts to broaden the foothold.
Why This Matters for Financial Institutions
The pattern Microsoft documented is the same pattern fraud teams at banks, credit unions, and mortgage companies already see in business email compromise and account takeover cases against your customers. Now it is being run against the IT staff and executives who hold privileged Microsoft Entra ID roles inside your own tenant. The exposure surface is your operational data in Microsoft 365 and Azure, not just your customers' funds.
In the cloud phase, Storm-2949 used the privileged Azure role assignments those compromised users already carried to reach App Service web applications, Azure Key Vault, Azure Storage, and Azure SQL. They pulled App Service publishing profiles using a documented Azure management-plane operation, opened SQL firewall rules and deleted them afterward to cover their tracks, manipulated storage account network access, and dumped Shared Access Signature tokens and storage keys with another documented operation. Every one of those moves writes a record to the Azure activity log. The defense is not blocking the operations, it is being awake when they happen.
The whole campaign ran on identity and configuration. The same controls a community bank, a credit union, or a mortgage company already pays for inside Microsoft 365 and Microsoft Azure can break this attack chain.
The SSPR Abuse Path: How One Phone Call Becomes a Cloud-Wide Breach
Self-Service Password Reset is a Microsoft Entra ID feature most financial institutions enable on purpose. It lets a user who forgets a password reset it themselves after passing a multifactor challenge, instead of opening a help desk ticket. It cuts help desk volume, it shortens recovery times, and it removes a step where a help desk analyst has to verify the caller is who they say they are. All of that is good engineering. SSPR is also the door Storm-2949 walked through. The pattern is in the same family as the Microsoft 365 device code phishing campaign that hit financial institution tenants earlier this year, just routed through a different identity flow.
Microsoft documented the attack chain in seven beats. Read them slowly. Each beat is a place where a Microsoft 365 control can intervene.
The attacker identifies a target user by name and role inside the financial institution. Storm-2949 specifically picked IT personnel and senior leaders because those identities carry privileged Microsoft Entra ID role assignments.
The attacker starts the Microsoft Entra ID Self-Service Password Reset flow on the target user's behalf. The reset process triggers a multifactor authentication prompt to the legitimate user's registered device.
The attacker calls the user, claims to be internal IT support, and tells them their account needs urgent verification. The user is told to approve the multifactor prompt that just appeared on their phone as part of a routine reset.
The legitimate user, believing they are helping IT, taps approve. The attacker now controls the password reset session.
The attacker sets a new password the user does not know, then removes every existing authentication method on the account: phone number, alternate email, Microsoft Authenticator registration.
The attacker enrolls Microsoft Authenticator on their own device. The legitimate user is now locked out, the attacker has persistent access, and from Microsoft Entra ID's perspective the account is healthy with MFA enabled.
The attacker uses Microsoft Graph API queries to enumerate other privileged identities, then repeats steps 1 through 6 against three more users. After that, the attacker leverages the privileged Azure role assignments those accounts already hold to reach App Service, Key Vault, Storage, and SQL.
The Lesson in Plain English
Self-Service Password Reset is not the vulnerability. The vulnerability is the registration session that lets a freshly authenticated user add and remove authentication methods. If a financial institution does not gate that session with a phishing-resistant authentication strength and conditional access controls, a single approved push notification becomes a permanent foothold inside Microsoft Entra ID.
Why This Lands So Hard on Banks, Credit Unions, and Mortgage Companies
Three structural realities make Storm-2949 a particularly bad fit for financial institutions, and a particularly good fit for an attacker willing to invest a few hours in research.
The privileged identities are easy to find and look credible to attack
Community banks, credit unions, and mortgage companies publish their org charts. Lenders and underwriters appear on company websites. CIO and CISO names appear on Boards, examination filings, and FFIEC reports. Senior leadership is identifiable from LinkedIn in minutes. Storm-2949 did not need an insider tip to know which users carry Microsoft Entra ID Global Administrator, Application Administrator, or Privileged Role Administrator assignments. They just needed a roster.
The data that lives one identity hop away is exactly what an attacker wants
The Microsoft 365 tenant a bank, credit union, or mortgage company runs is where the operational record lives. OneDrive and SharePoint hold loan files, vendor management documentation, internal audit workpapers, board packets, and the kinds of IT documents the Storm-2949 actor specifically went looking for, including VPN configurations and remote access procedures. The Azure subscriptions next to that tenant typically host customer-facing applications, integration endpoints to your core banking or loan origination system, and the Key Vaults that protect database connection strings and API keys.
The detection surface is configuration, not signature
Financial institutions are used to threat detection that looks like signatures: a known phishing sender, a known malware hash, a known C2 domain. Storm-2949 produces none of that. The campaign runs through Microsoft Entra ID sign-in logs, Microsoft Entra ID audit logs, Microsoft Graph activity logs, and Microsoft Azure activity logs. If those telemetry sources are not flowing into Microsoft Sentinel or Microsoft Defender XDR with the right user and entity behavior analytics, the institution will not see the attack until data is already moving out.
Microsoft Defender for Cloud Apps surfaces anomalous administrative behavior, mass file download from OneDrive, and SAS token generation patterns. Microsoft Defender for Identity highlights privilege escalation, unusual Graph API enumeration, and Active Directory or Microsoft Entra ID reconnaissance. Microsoft Sentinel correlates Microsoft Entra ID sign-in anomalies with Azure activity log spikes against Key Vault, Storage, and SQL management-plane operations. ABT-managed tenants on M365 Guardian receive these detections as part of the operating model. Tenants that have not enabled the underlying connectors will miss the campaign even after Microsoft publishes the indicators.
Microsoft 365 Hardening: Six Controls to Configure This Week
The Storm-2949 campaign is a configuration problem with configuration answers. Six Microsoft 365 controls together close most of the attack chain. None of them require a new license for a Microsoft 365 E5 or Microsoft 365 E3 with Microsoft Entra ID P2 tenant. All six should be reviewed inside the next five business days at every bank, credit union, and mortgage company on Microsoft 365.
| Control | What it does against Storm-2949 | Where to configure it |
|---|---|---|
| Microsoft Entra Conditional Access on the security info registration session | Forces a phishing-resistant authentication strength (FIDO2 security key, passkey, or Windows Hello for Business) before a user can add or remove an authentication method. Defeats the MFA-stripping step. See our deeper walkthrough on Conditional Access policies for financial institutions. | Microsoft Entra admin center, Protection, Conditional Access. Target the User actions cloud app named Register security information. |
| Phishing-resistant MFA for privileged roles | Removes push notification and SMS as valid factors for Global Admin, Privileged Role Admin, Application Admin, and Helpdesk Admin. Push notification approval is exactly what Storm-2949 exploited. The phishing-resistant MFA guidance for financial institutions covers the FIDO2 and passkey rollout sequence. | Microsoft Entra Authentication strengths plus Conditional Access policy scoped to those role assignments. |
| Microsoft Entra ID Protection user risk and sign-in risk policies | Triggers a step-up challenge or block when Microsoft assesses elevated risk on the sign-in. The Storm-2949 sign-in profile (new device, sometimes new geography, immediately followed by authentication method changes) typically produces a risk event. | Microsoft Entra ID Protection. Enable both user risk and sign-in risk policies. Start in report-only, move to enforce inside one week. |
| Help desk verification policy on SSPR-adjacent calls | Adds a non-Microsoft control to defeat the social engineering call. Mandates a callback to the user's number of record (not a number the caller provides) before any conversation about MFA or password changes. | Written runbook for the help desk plus inclusion in annual phishing and BEC training for IT staff and senior leaders. |
| Microsoft Purview Data Loss Prevention on OneDrive and SharePoint | Catches the OneDrive web download of thousands of files in a single action. Storm-2949 specifically targeted IT documents about VPN and remote access configurations. | Microsoft Purview compliance portal. Apply DLP policies that detect bulk download, sensitive content, and unusual download geography to OneDrive and SharePoint. |
| Microsoft Defender for Cloud Apps anomaly detection | Surfaces unusual administrator activity, impossible travel, mass download, suspicious OAuth grants, and SAS token generation patterns. | Microsoft Defender portal, Cloud Apps, Policies. The default Anomaly detection policy and the Activity policies for administrative behavior both apply here. |
Want a clear read on where your Microsoft 365 tenant sits against the Storm-2949 controls?
Ten minutes inside Microsoft Entra and Microsoft Defender will tell you whether your SSPR registration session is gated, whether your privileged identities are still accepting push notifications, and whether your OneDrive bulk-download detections are turned on. Run the assessment, share the result with your CISO and IT director, and decide what to fix this week.
Get Your Security Grade Talk to an ABT ExpertAzure Hardening: The Four Management-Plane Operations to Alert On
The Azure phase of Storm-2949 is the easiest phase to detect, because every step the attacker took produces a record in the Azure activity log. The hard part is that most financial institutions are not yet alerting on the specific operations Microsoft published. Four operations stand out. A Microsoft Sentinel analytics rule, a Microsoft Defender for Cloud Apps activity policy, or even a focused Azure Monitor alert can fire on each of them.
microsoft.Web/sites/publishxml/action
This operation retrieves an Azure App Service publishing profile. Storm-2949 used it to pull deployment credentials for Kudu, FTP, and Web Deploy on auxiliary web apps in the same ecosystem as the production target. Legitimate use is rare and almost always tied to a deployment pipeline. Any invocation outside the known DevOps service principals is worth alerting on, and any invocation by an interactive user identity should page on-call.
microsoft.sql/servers/firewallrules/write
Storm-2949 opened SQL firewall rules to allow connections from attacker-owned IP addresses, then deleted those rules afterward to cover their tracks. A Microsoft Sentinel rule that fires when a firewall rule is added and removed within a short window is a strong primary signal. Static firewall rules in Azure SQL change rarely. A burst of write and delete activity is almost always either a misconfigured deployment or an attacker.
microsoft.Storage/storageAccounts/listkeys/action
This operation retrieves the account access keys for an Azure Storage account. Once an attacker has those keys, they can authenticate to the storage account from any IP, with no further interactive sign-in. Storm-2949 used it to enable static, non-interactive authentication against multiple storage accounts. Legitimate retrievals are typically scoped to deployment pipelines or rotation jobs. Any retrieval by an interactive user identity deserves an alert.
microsoft.storage/storageaccounts/write
Storm-2949 used this operation to manipulate storage account network access policies, enabling public access to storage accounts from a closed set of attacker IPs. A baseline rule that detects changes to network access policies on production storage accounts, especially changes that move a storage account from restricted access to broader access, will fire on the move from preparation to exfiltration.
Already ingests Microsoft Entra ID sign-in and audit logs, Azure activity logs, and Microsoft 365 unified audit logs, and you have analytics rules covering the four operations above plus the Microsoft Entra ID security information registration cloud app, you are well positioned. Verify the alerts fire end-to-end this week using a planned test.
Does not ingest Azure activity logs from every production subscription, or your analytics rules are still the out-of-box defaults, treat that as a priority backlog item. ABT-managed tenants on M365 Guardian operate inside a known telemetry baseline. Tenants without that baseline will see Storm-2949 only after data has moved out, which is too late.
A note on what ABT does for managed financial institution tenants
ABT manages Microsoft 365 tenants for more than 750 financial institutions, and hosts Azure environments for the financial institution customers that run on MortgageWorkSpace, MortgageExchange, or Calyx PointCentral. For the Microsoft 365 surface, the controls above land inside our managed identity and security baseline. For Azure, our hosted environments inherit the four-operation alert pattern by default. Tenants and subscriptions outside our managed footprint require an explicit configuration review against this checklist. The work is straightforward, but it needs to be deliberate.
A Five-Day Response Plan for Banks, Credit Unions, and Mortgage Companies
Most security advisories ask the reader to plan a project. This one asks the reader to spend roughly one calendar week. Storm-2949 is an active campaign. The actor is not waiting for a quarterly review.
Inventory privileged Microsoft Entra ID identities
List every account holding Global Administrator, Privileged Role Administrator, Application Administrator, Authentication Administrator, Conditional Access Administrator, or Helpdesk Administrator. Verify that every one of those accounts has phishing-resistant authentication enrolled and that no shared accounts hold any of these roles.
Gate the security information registration session
Configure Microsoft Entra Conditional Access against the Register security information user action. Require the strongest available authentication strength your tenant supports, in this order of preference: FIDO2 security key, Windows Hello for Business, passkey, or certificate-based authentication. Push notification and SMS are the methods Storm-2949 abused, so they should not be the gate on the registration session.
Verify telemetry flow into Microsoft Sentinel
Confirm Microsoft Entra ID sign-in logs, Microsoft Entra ID audit logs, Microsoft 365 unified audit logs, and Azure activity logs from every production subscription are flowing into Microsoft Sentinel or your SIEM of record. Confirm Microsoft Defender for Cloud Apps anomaly policies are active and tuned, not in the default state.
Deploy the four Azure management-plane analytics rules
Add or verify Microsoft Sentinel analytics rules for the four operations Microsoft documented. Test each rule by invoking the corresponding operation from a known-good admin account against a non-production resource, confirming the alert fires. If you do not run Microsoft Sentinel, the equivalent activity policy lives in Microsoft Defender for Cloud Apps.
Issue a help desk advisory and refresh user training
Tell the help desk team in writing that any phone call about an unexpected multifactor prompt is to be treated as suspicious. The handler should hang up, call the user back at the number on record, and verify identity before any further action on the account. Refresh the IT staff and senior leadership training material to include the specific Storm-2949 pattern. Banks, credit unions, and mortgage companies that already run quarterly phishing tests should add an SSPR-themed scenario to the next round.
The Bottom Line
Storm-2949 is not a vulnerability scan finding. It is a tenant configuration check. The controls that defeat it are already in your Microsoft 365 license. The operations that detect it are already in your Microsoft Azure activity log. The week between when Microsoft publishes a profile like this and when the wider attacker community absorbs the playbook is the window where banks, credit unions, and mortgage companies decide whether they will be the early defenders or the late headlines.
Frequently Asked Questions
Storm-2949 is a threat actor that Microsoft Threat Intelligence profiled on May 18, 2026, in a Microsoft Security Blog post titled "How Storm-2949 turned a compromised identity into a cloud-wide breach." The actor combines Self-Service Password Reset abuse and social engineering to compromise Microsoft Entra ID identities, then uses the privileged Azure role assignments those identities carry to exfiltrate data from Microsoft 365 OneDrive and SharePoint, Azure App Service, Azure Key Vault, Azure Storage, and Azure SQL. The campaign uses no traditional malware.
The actor does not technically bypass multifactor authentication. They convince the legitimate user to approve a multifactor prompt by impersonating IT support during a Self-Service Password Reset flow the actor initiated. Once the user approves, the actor resets the password, removes every existing authentication method on the account, and enrolls Microsoft Authenticator on the actor's own device. From Microsoft Entra ID's perspective the account still has MFA enabled, but the new MFA device is the attacker's.
No. Disabling SSPR would push password resets back into the help desk and create a different attack surface. The right answer is to gate the Microsoft Entra ID security information registration session with phishing-resistant authentication strength through Conditional Access, configure Microsoft Entra ID Protection user risk and sign-in risk policies, and add a written help desk runbook that requires a callback to the user's number of record before any conversation about multifactor changes.
The full control set is available with Microsoft 365 E5 or Microsoft 365 E3 with Microsoft Entra ID P2 added. Microsoft 365 Business Premium and Microsoft 365 E3 alone include Conditional Access and Authentication strengths, which cover the registration session gate and phishing-resistant MFA on privileged roles. Microsoft Entra ID Protection user and sign-in risk policies, Microsoft Defender for Cloud Apps anomaly detection, and Microsoft Sentinel require the higher tiers or add-on licenses. A licensing assessment from ABT can map a specific financial institution's seat count to the right tier.
Configure Microsoft Entra Conditional Access against the Register security information user action and require a phishing-resistant authentication strength. That single policy breaks the MFA-stripping step in the Storm-2949 attack chain. Even if a user is tricked into approving a multifactor prompt under social engineering pressure, the attacker cannot change authentication methods on the account without satisfying a FIDO2 key, Windows Hello, passkey, or certificate-based challenge that the legitimate user holds.
ABT-managed tenants on M365 Guardian receive a tuned baseline across Microsoft Entra ID Protection, Microsoft Defender for Cloud Apps, Microsoft Defender for Identity, and Microsoft Sentinel. The Storm-2949 detection coverage includes Conditional Access enforcement on the security information registration session, anomaly policies on bulk OneDrive download and SAS token generation, analytics rules on the four documented Azure management-plane operations, and a help desk verification runbook that defeats the social engineering call. The same telemetry feeds the evidence pack ABT delivers for an FFIEC IT examination readiness review, so the work doubles as audit-ready governance. The Guardian operating model takes those detections from one-time configuration to ongoing monitoring across the lifetime of the relationship.
Get a Storm-2949 Posture Review for Your Microsoft 365 and Microsoft Azure Tenant
Banks, credit unions, and mortgage companies that ran a focused review against the Storm-2949 control list this week will close the most common identity-only intrusion path of the year. ABT walks the same checklist with you, scores your tenant, and stages the Microsoft Entra, Microsoft Defender, Microsoft Sentinel, and Microsoft Purview policies that move you from late headline to early defender.
Talk to an ABT Expert Get Your Security Grade
