Microsoft 365 Ransomware Recovery: What Actually Happens During an Incident

This article provides a technical examination of the mechanics involved in a ransomware incident within a Microsoft 365 environment. It outlines the progression of an attack from initial compromise through to the various recovery pathways available to an organisation. The focus remains on the procedural reality of restoration, API limitations, and the impact of identity compromise on the recovery timeline.

How Ransomware Affects Microsoft 365

In a cloud-productivity context, ransomware typically does not “infect” the Microsoft 365 cloud servers directly. Instead, the incident usually originates at the endpoint level. When a device with an active Microsoft OneDrive or SharePoint sync client is compromised, the ransomware begins encrypting files on the local disk.

The Microsoft 365 sync engine interprets these changes as legitimate file updates. Consequently, the encrypted versions of the files are synchronised to the cloud, overwriting the healthy versions in SharePoint Online and OneDrive for Business. In a mass encryption event, thousands of files are modified simultaneously, triggering a high-volume sync operation that propagates the encrypted state across the entire shared document library.

Alternatively, attackers may use automated scripts via compromised administrative credentials to perform mass deletions or to move data into hidden folders. In these scenarios, the data is not necessarily encrypted but is rendered inaccessible to standard users, creating an operational blackout similar to traditional ransomware.

Diagram 1: Identity Compromise and Token Theft Flow. A flat, labeled process flow showing AiTM/phishing leading to session/token theft, token replay, Conditional Access bypass, and privileged actions via the stolen identity. Primary Blue #153379 and Accent Yellow #FEF600 used for structure and highlights.

What Native Protections Do and Do Not Cover

Microsoft 365 includes native features designed for data integrity, specifically Versioning and the Recycle Bin. While effective for individual file accidental deletions, their utility changes during a large-scale incident.

Versioning Limits

SharePoint and OneDrive maintain a history of file versions. When ransomware encrypts a file, it creates a new version. To recover, each file must be reverted to the previous version. While Microsoft provides a “Restore your OneDrive” feature for end-users to roll back an entire library to a specific point in time within the last 30 days, this process is governed by specific retention settings and may not cover all file types or complex SharePoint configurations.

Recycle Bin Retention

Deleted items are moved to the first-stage Recycle Bin, then to a second-stage (Site Collection) Recycle Bin, with a total retention period of 93 days. If an attacker performs a mass deletion, the data remains recoverable within this window. However, if the attacker gains sufficient privileges to “purge” the Recycle Bin, native recovery becomes reliant on Microsoft’s secondary internal backups, which generally have a strict 14-day window for restoration requests via support tickets.

What Breaks During Tenant Compromise

A critical distinction in modern incidents is the shift from simple file encryption to total identity compromise. When the identity trust boundary collapses, the tools intended for recovery may be turned against the organisation.

Restoration attempts are ineffective until identity integrity is restored and malicious tokens are invalidated.

Conditional Access Bypass Scenarios

Attackers often bypass Multi-Factor Authentication (MFA) through session hijacking or “adversary-in-the-middle” (AiTM) attacks. By stealing a valid session cookie, an attacker can bypass Conditional Access policies that would otherwise require a fresh MFA prompt. This allows the attacker to operate within the tenant with the same permissions as a legitimate administrator.

Token Theft Persistence

Once a session token is stolen, the attacker can maintain persistence even if the user’s password is changed. Unless the administrator explicitly revokes all active refresh tokens, the attacker remains authenticated. During an incident, this means the attacker can continue to encrypt or delete data while the IT team is attempting to perform restoration tasks.

Identity Trust Boundary Collapse

If an administrative account is compromised, the attacker can:

• Disable security defaults and audit logging.
• Modify or delete retention policies.
• Exfiltrate data via mail flow rules or external sharing links.
• Delete existing backups if the backup solution is integrated via a global admin account without sufficient isolation.

In this context, the incident is no longer just a “data” problem; it is an “identity” problem. Recovery cannot begin until the identity environment is re-secured and all malicious tokens are invalidated.

Recovery With Independent Backup

Recovery using an independent, third-party backup solution follows a different procedural path than native tools. Because the backup data is stored outside the Microsoft 365 production environment: ideally in an immutable format: it remains unaffected by tenant-level administrative compromise.

The process involves:

1. Point-in-Time Selection: Identifying the exact state of the data before the encryption or deletion event began.
2. Granular Restoration: Restoring specific folders, mailboxes, or sites without needing to roll back the entire tenant.
3. Automated Overwrite: The backup software uses the Microsoft Graph API to push healthy versions of files back into the tenant, overwriting the encrypted versions.

For a deeper look at the technical requirements of these solutions, refer to our guide on how to evaluate a Microsoft 365 backup solution.

Diagram 2: Tenant Boundary Breach and Persistent Access. A flat, labeled boundary diagram showing how a compromised admin token enables persistent control across Entra ID, Exchange Online, SharePoint/OneDrive, and Security/Compliance controls. Primary Blue #153379 and Accent Yellow #FEF600 used for structure and key risk points.

Recovery Without Independent Backup

Without an independent backup, the recovery process is manual and high-friction. This often involves:

• Manual Reversion: Using the “Restore your OneDrive” feature for every affected user. This is limited to 30 days and requires individual user or admin intervention for every single account.
• PowerShell Scripting: For SharePoint sites, administrators may need to write and execute scripts to iterate through thousands of files and revert them to a previous version based on a timestamp.
• Microsoft Support Escalation: If the Recycle Bin has been purged, the organisation must open a “Severity A” case with Microsoft. There is no self-service interface for this; it relies on Microsoft’s internal engineers to locate and restore the site collection to its state at a specific point in time. This is an “all or nothing” restore that can overwrite any legitimate work performed between the incident and the restoration.

Recovery Timeline Expectations

The Recovery Time Objective (RTO) in a Microsoft 365 environment is largely dictated by data volume and API throughput.

API Throttling

Microsoft 365 limits the speed at which data can be written back into the tenant to maintain service stability for other users. This is known as “throttling.” Even with a high-speed internet connection, the Microsoft Graph API will only allow a certain number of requests per second. For tenants with several terabytes of data, the restoration process can take days or even weeks to complete.

Data Volume and Indexing

Once data is restored, SharePoint and OneDrive must re-index the files for search and metadata. During this time, users may find that while files are present, they are not searchable, and certain collaboration features may be sluggish.

Diagram 3: Phased Recovery Timeline and API Constraints. A flat, labeled timeline showing identity containment/validation before restoration, plus bulk restore stages constrained by Microsoft Graph API throttling and throughput limits. Primary Blue #153379 and Accent Yellow #FEF600 used for structure and constraint highlights.

Conclusion

The technical reality of a Microsoft 365 ransomware incident involves complex identity challenges and significant procedural friction during restoration. While native tools provide a basic safety net for accidental deletions, they are not designed for the rapid, large-scale restoration required after a coordinated attack.

Organisations should evaluate their current recovery capabilities against the reality of API throttling and identity compromise. True preparedness is measured not by the existence of a backup, but by validated recovery testing outcomes and a clear understanding of API throughput constraints during large-scale restoration.