How to Secure Your Microsoft 365 Account Against Data Theft Attacks

Attackers no longer need malware to steal your organization’s data from Microsoft 365. A threat actor tracked as Storm-2949 recently demonstrated how a single hijacked Microsoft account, obtained through a phone call and a manipulated MFA prompt, can lead to thousands of files downloaded from OneDrive and SharePoint within hours.

Microsoft’s Defender Security Research Team documented the full attack chain in May 2026. The entry point in every case was identity, not infrastructure. Weak MFA configuration, overly trusted SSPR flows, and missing Conditional Access policies gave the attacker everything they needed to move from a single compromised account to organization-wide data exfiltration.

This guide covers exactly how attackers target Microsoft 365 accounts and the specific controls you need to stop them.

How Attackers Target Microsoft 365 Accounts

Storm-2949 uses a technique that abuses Microsoft’s Self-Service Password Reset (SSPR) flow combined with direct phone-based social engineering. The attack follows a repeatable sequence.

First, the attacker identifies a high-value target inside the organization, typically someone in IT or senior leadership, and obtains their phone number and Microsoft 365 email address. They then initiate the SSPR process for that account and immediately call the target on the phone.

On the call, the attacker poses as an internal IT support representative and tells the target their account needs urgent verification. They instruct the target to approve the MFA prompt currently appearing on their device. This is the same manipulation tactic used in tech support scams, where urgency and impersonation pressure the victim into acting without questioning the request.

Once the target approves the prompt, the attacker resets the account password, removes all existing authentication methods including registered phone numbers, email addresses, and Microsoft Authenticator entries, and enrolls their own device as the new MFA method. The legitimate user loses access immediately and cannot recover the account through normal channels.

With persistent access established, Storm-2949 uses a custom Python script through the Microsoft Graph API to enumerate users, roles, applications, and service principals across the tenant. This maps out additional high-value accounts and application-level access paths for follow-on attacks.

The attacker then repeats the same SSPR technique on additional accounts inside the same organization, specifically targeting identities with access to different file repositories. They access OneDrive and SharePoint, search for VPN configurations, IT operational files, and remote access credentials, and then execute large-scale downloads. In one documented instance, Storm-2949 downloaded thousands of files from OneDrive in a single action using the web interface. The pattern repeated across every compromised account.

How to Secure Your Microsoft 365 Account Against Data Theft

Switch to Phishing-Resistant MFA

Standard push notification MFA is the core vulnerability that Storm-2949 exploits. When a user receives an unexpected MFA push and an incoming phone call at the same moment, social pressure frequently wins.

Phishing-resistant MFA methods break this attack completely because they do not involve the user approving a prompt that an attacker can trigger remotely.

• Set up a passkey for your Microsoft account and remove SMS-based verification. Microsoft confirmed that SMS authentication is now a leading source of account fraud across its platforms.
• Require FIDO2 security keys or passkeys specifically for administrator accounts, IT personnel, and anyone in senior leadership. These are the roles Storm-2949 targets first.
• Use Conditional Access authentication strength policies to enforce phishing-resistant MFA for critical applications across your tenant.
• Ensure every privileged user has a registered MFA method already in place. Accounts with no registered method allow attackers to be the first to enroll a device during an SSPR event.

Tighten SSPR Configuration

SSPR is a useful feature, but its default configuration creates unnecessary risk for organizations with targeted threat exposure.

• Require multiple authentication methods to complete SSPR, not just one. Requiring two separate verification steps makes it significantly harder for an attacker to push the victim through the entire flow in a single phone call.
• Restrict SSPR to users who have already registered at least one strong authentication method. Block SSPR for accounts with only SMS or voice call methods registered.
• Enable SSPR audit logging and alert on any password reset followed immediately by MFA method changes. This specific sequence is the fingerprint of the Storm-2949 technique.
• Consider restricting SSPR access for administrator and privileged accounts entirely. Require IT-assisted resets with identity verification for those roles.

Configure Conditional Access Policies

Conditional Access is the most effective layer of defense against credential-based attacks because it evaluates every sign-in attempt against your security requirements, even after a password reset.

• Enable device compliance requirements. An attacker logging in from an unmanaged device should fail Conditional Access even if they hold valid credentials and a registered MFA method.
• Restrict sign-ins to trusted IP ranges or named locations for privileged accounts. A sign-in from an unfamiliar country or IP block triggers re-authentication or blocks access outright.
• Enable sign-in risk policies through Microsoft Entra ID Protection. Risk-based Conditional Access automatically challenges or blocks sign-ins that match known attack patterns such as impossible travel, unfamiliar locations, or anonymous proxy usage.
• Require re-authentication for high-sensitivity actions such as bulk file downloads, MFA method changes, and application permission grants.

Restrict Microsoft Graph API Access

Storm-2949 uses the Microsoft Graph API immediately after account compromise to map the entire tenant. Unmonitored Graph API access makes this enumeration invisible until the damage is done.

• Audit all applications and service principals in your tenant that hold Microsoft Graph API permissions. Remove any that have more access than their function requires.
• Enable logging for Graph API calls and alert on large-scale directory enumeration queries. Repeated automated calls to list users, roles, and applications from a single identity are a strong indicator of post-compromise discovery.
• Apply the principle of least privilege to all service principal permissions. Avoid granting Directory.Read.All or User.Read.All to applications that do not explicitly need them.
• Disable or restrict service principal credential addition for non-admin identities. Storm-2949 attempted to add credentials to compromised service principals to create persistence independent of the hijacked user accounts.

Protect OneDrive and SharePoint from Mass Download

OneDrive and SharePoint are the primary exfiltration targets once an attacker holds a valid Microsoft 365 identity. Storm-2949 focuses specifically on IT documents, VPN configurations, and remote access files because these enable lateral movement into the endpoint network.

• Enable session policies in Microsoft Defender for Cloud Apps that limit or block bulk downloads from unmanaged or risky devices.
• Configure alerts for mass download events in OneDrive and SharePoint. A single user downloading thousands of files in minutes is not normal behavior.
• Apply sensitivity labels to documents containing VPN configurations, IT operational data, and remote access credentials. Label-based policies can block download or require additional authentication for labeled content.
• Restrict external sharing settings for SharePoint sites that contain sensitive IT infrastructure documentation.
• Enable Microsoft Purview audit logging to capture all file access and download events across OneDrive and SharePoint for investigation purposes.

Monitor Identity Risks with Microsoft Entra ID Protection

Microsoft Entra ID Protection monitors sign-in and user behavior across your tenant and surfaces risk signals that standard audit logs miss.

• Turn on Entra ID Protection and configure risk-based Conditional Access policies for both sign-in risk and user risk. High-risk sign-ins should trigger MFA step-up or block access automatically.
• Review risky users and risky sign-ins reports regularly. Entra ID Protection flags events like anonymous IP usage, atypical travel, and malware-linked IP addresses.
• Enable the “Suspicious addition of default third-party MFA method” alert in Microsoft Defender for Identity. This alert fires when an attacker registers their own device as a new MFA method, which is the persistence step Storm-2949 takes immediately after account takeover.
• Connect Microsoft Defender for Cloud Apps to your Microsoft 365 environment to monitor SaaS activity and detect behavioral anomalies across OneDrive, SharePoint, and Exchange.

Signs Your Microsoft 365 Account Has Been Compromised

Watch for these specific indicators that map directly to the Storm-2949 attack pattern:

• You receive an unexpected MFA prompt with no corresponding login attempt on your end.
• You lose access to your account immediately after approving what appeared to be a routine IT verification request.
• Audit logs show a password reset followed within seconds by removal of all MFA methods and re-registration of a new authenticator.
• Microsoft Entra ID Protection flags a sign-in from an unusual location or anonymous IP shortly after an SSPR event.
• Defender for Cloud Apps surfaces a mass download alert from your OneDrive or SharePoint account.
• You notice the AADSTS50058 silent sign-in error appearing repeatedly, which can indicate session disruption from a concurrent account takeover.

What to Do After a Microsoft 365 Account Takeover

If an attacker has already compromised a Microsoft 365 account in your organization, take these steps immediately:

1. Revoke all active sessions for the compromised account from the Microsoft Entra admin center using the “Revoke sessions” option.
2. Remove the attacker’s registered MFA device from the account’s authentication methods. Add a verified method back under controlled conditions.
3. Reset the account password from a trusted admin account, not through SSPR, to prevent the attacker from repeating the takeover.
4. Review Entra ID audit logs for every action the compromised identity performed after the SSPR event, including Graph API calls, file access, and any application permission grants.
5. Check for new service principal credentials or application registrations the attacker may have added for persistence.
6. Scan all devices the compromised user accessed for remote access trojans or other tools the attacker may have installed using the account’s permissions.
7. Run a full Microsoft Defender virus scan on every endpoint associated with the compromised identity.
8. If authentication methods were completely removed and you cannot recover access through standard channels, follow the full recovery process for a hacked and deleted Microsoft account.
9. If you continue to experience sign-in failures after recovery, check for MFA method conflicts or Conditional Access policy mismatches left over from the attacker’s changes.

Related Tech Guides

• How to Set Up a Passkey for Your Microsoft Account and Remove SMS Authentication
• How to Run a Microsoft Defender Virus Scan (Beginner-Friendly)
• What is a Remote Access Trojan (RAT)? Detection and Removal Guide for Windows

Errors and Fixes

• Microsoft Account Hacked and Deleted: How to Recover It Step by Step
• Can’t Sign In to Microsoft Azure Account? 7 Fixes That Work
• How to Fix AADSTS50058 Error in Azure (Silent Sign-In Request Failed)