Most ransomware damage in Microsoft 365 happens after the first compromised sign-in, not at the first alert. If you wait to investigate properly before cutting access, the attacker can keep encrypting files, setting inbox rules, and planting back doors. A swift and effective Microsoft 365 ransomware response is critical to stopping the progression of an attack.
While Microsoft manages the underlying infrastructure, the shared responsibility model dictates that customers are responsible for securing their own data and identities. Even if you have multi-factor authentication in place, attackers often find ways to bypass these defenses. When a breach occurs, you must take immediate action to protect your data across Microsoft Entra ID, Exchange Online, SharePoint, Teams, and the rest of your tenant.
The steps below are built for admins and security teams who need a practical playbook when time is short.
Key Takeaways
- Prioritize containment over immediate cleanup: Stop the attacker’s ability to sync, forward, or authenticate before attempting to wipe devices or delete malicious configurations, as premature action can destroy critical forensic evidence.
- Address identity as the primary vector: Treat compromised accounts as fully exposed, necessitating immediate password resets, revocation of active refresh tokens, and removal of suspicious OAuth consent grants or hidden inbox rules.
- Manage recovery in phases: Restore data only after thoroughly cleaning the identity and device paths to prevent re-infection through automated sync processes, ensuring recovery occurs in order of business priority.
- Adopt a Zero Trust security posture: Implement phishing-resistant MFA for all administrators and maintain strict control over Conditional Access policies to prevent lateral movement and persistent unauthorized access across the Microsoft 365 tenant.
Start with containment and mitigation
In the first hour, your job is simple: stop the attacker from moving, syncing, forwarding, or signing back in. Do not start broad deletions, do not wipe devices yet, and do not remove every trace before you have captured what happened.
Begin with this order:
- Move the response team onto known-clean devices.
- Isolate suspected endpoints from the network.
- Block or disable compromised accounts, starting with admins.
- Revoke active sessions and refresh tokens.
- Pause sync and sharing paths the attacker may still use.
- Preserve evidence before wide remediation starts.
If Microsoft Defender XDR is in place, isolate devices there first. If it is not, disconnect wired and wireless access, remove VPN, and document the exact time. If a device holds live evidence and an incident responder is engaged, avoid rebooting it unless that team says otherwise.
Then, secure privileged access. Check Global Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator, Intune Administrator, and any custom high-privilege roles. Attackers love admin roles because one stolen account can fan out across the whole tenant. Simultaneously, review your Exchange Online Protection settings to ensure the attacker has not altered mail hygiene rules to facilitate further exploitation.
Capture first, clean second. If you delete logs, wipe devices, or remove rules too early, you may lose the best record of the attack.
Export what you can while it is fresh. Pull Microsoft Entra sign-in logs, Microsoft 365 audit events, Defender incident timelines, message traces, and screenshots of suspicious settings. If you are using Microsoft Sentinel, keep the incident, alerts, and entity timeline intact.
Microsoft’s own ransomware incident response plan follows the same logic. Contain the blast radius first, then work methodically.
Lock down identity in Microsoft Entra ID
Identity is usually the control point that decides whether ransomware stays local or becomes a tenant event. Once the first account is suspected, treat every token and MFA method tied to it as exposed until proven clean. Effectively managing your identity security within Entra ID is the primary way to stop lateral movement.
Reset the account properly
A password reset alone is not enough. Attackers often keep access through refresh tokens, stolen browser sessions, or added MFA methods. For each compromised user or admin, follow these steps to maintain a Zero Trust posture:
- Block sign-in until you understand the account’s role in the incident.
- Reset the password from a clean admin session.
- Revoke all active sessions and refresh tokens.
- Review and remove unknown authentication methods.
- Force multi-factor authentication re-registration after the account is back under your control.
For admin accounts, move straight to phishing-resistant methods if you have not already. In 2026, passkeys and FIDO2 security keys are the safer default. SMS and phone prompts are weak options for privileged identities, and enforcing least privilege access is essential to minimize the impact of a compromised account.
Also, check break-glass accounts. You should have at least two cloud-only emergency accounts with long passwords, tight monitoring, and limited use. Make sure they still work, and verify that the attacker did not modify them.
Review Conditional Access and consent abuse
Next, inspect your conditional access policies. Look for recent edits, disabled rules, added exclusions, trusted locations that should not exist, and any reopening of legacy authentication. A single exclusion for all cloud apps can undo months of hardening.
Then, inspect application consent and enterprise apps. Ransomware crews and initial access brokers often add OAuth consent so they can read mail, pull files, or maintain access without passwords. Review:
- User consent grants
- Enterprise applications
- App registrations
- Service principals with broad Graph or Exchange permissions
- Workload identities tied to scripts or automation
Pay close attention to permissions like mail read, file read and write, offline access, or directory access. If an app looks unfamiliar, disable it, capture its details, and trace who consented to it.
Do not forget Azure-connected automation within Entra ID. Check Azure runbooks, logic apps, storage access, and service principals if your tenant links business data across Microsoft 365 and Azure. Attackers do not care which admin center the access came from, only that it works.
Hunt for mail abuse in Exchange Online
Exchange Online is often the attacker’s quiet channel. Even when the main goal is file encryption, mail access helps with phishing emails, payment fraud, and persistence.
Start with compromised and high-risk mailboxes. Review inbox rules, hidden forwarding rules, delegate access, mailbox forwarding, transport rules, and suspicious shared mailbox changes. Forwarding rules to external domains deserve immediate attention, even if they look old.
Then move up a level and check tenant mail flow. Review connectors, accepted domains, and quarantine settings. Inspect your Exchange Online Protection configuration and Advanced Threat Protection settings for unauthorized modifications. Attackers sometimes add transport rules that delete alerts, copy invoices, or bypass malware detection to route mail around your standard security checks.
Use message trace to spot bursts of suspicious mail, internal phishing, or mailbox access that aligns with the attack window. Also, review sign-in history for Exchange access from odd locations, unfamiliar user agents, or impossible travel, and confirm that multi-factor authentication was not bypassed via session hijacking.
A quick Exchange Online checklist helps keep the search tight:
- Export suspicious rules before removing them
- Remove unknown forwarding addresses
- Review admin audit activity for transport and connector changes
- Check shared mailbox permissions and send-as rights
- Search for deleted security alerts or moved messages
- Confirm mailbox auditing is still active, noting that versioning and retention settings are critical for reviewing or recovering deleted items
If the attacker had OAuth access, mailbox abuse may continue after a password reset. That is why the app consent review in Entra and the mailbox review in Exchange Online must happen together.
Measure the blast radius across OneDrive, SharePoint, Teams, and Exchange
Once active access is blocked, work out what changed. This is where many teams move too fast. They restore one site, one device, or one mailbox, then miss the wider pattern. Ransomware in Microsoft 365 often spreads through sync, sharing, and reused credentials.
Focus on impact by workload, not by admin center. Teams files live in SharePoint and OneDrive. Mailbox content can feed phishing. Device sync can reintroduce bad changes after a restore.
This table gives a fast triage view:
| Workload | What to inspect first | Early recovery option |
|---|---|---|
| OneDrive | Mass renames, encrypted file names, share links, sync activity | File version history, recycle bin, OneDrive restore |
| SharePoint | Site library deletes, permission changes, external sharing, sync spread | Version restore, recycle bin, site restore where available |
| Teams | Guest adds, app installs, channel files, chat-linked phishing | Remove guest access, review files in linked SharePoint sites |
| Exchange Online | Inbox rules, forwarding, deleted items, mailbox delegation | Recover deleted items, restore folders, remove bad rules |
| Azure workloads | Storage changes, automation accounts, access keys, VM impact | Rotate secrets, restore clean backups, stop bad automation |
The pattern matters more than any single item. If one laptop encrypted a synced folder, the damage may already sit in SharePoint and OneDrive versions. If a mailbox sent phishing, Teams chats may have carried the same lure.
Use Microsoft Purview audit, data loss prevention, and content tools where licensing allows. These resources help you confirm scope, preserve records, and support legal review. For SharePoint and OneDrive, analyze large spikes in file updates, delete actions, and external sharing changes. You can leverage native versioning and retention policies to effectively roll back mass file renames. When investigating suspicious file modifications, consult Advanced Threat Protection logs to trace the point of entry.
For Teams, review guest additions, message links, and third-party app installs. For Exchange, check deleted or moved messages that hide alerts or payment threads.
This phase is also where you decide whether the event was only encryption or encryption combined with data exfiltration. Because double extortion is a growing risk factor for business continuity, identifying if sensitive files were accessed or moved is critical. That distinction drives legal, privacy, and customer notice obligations later.
Isolate and clean devices without destroying evidence
A tenant incident usually starts on an endpoint. If the device stays dirty, restored data can get hit again as soon as sync resumes, especially since infected endpoints will automatically push local changes back to SharePoint and OneDrive.
Use Microsoft Defender for Endpoint to isolate affected devices and collect investigation data. This endpoint detection and response platform provides the visibility needed to identify lateral movement, tool transfer, or credential theft activity. If these behaviors appear, widen the search before reintroducing any user to production systems. You should also verify if automated remediation was triggered or disabled, as this feature is critical for effective containment and mitigation.
Intune plays a supporting role here. Mark suspect devices noncompliant, block access through Conditional Access if needed, and stop new app or profile deployment to actively compromised endpoints. Still, be careful with remote wipe or retire actions. Those tools are useful, but they can also remove evidence you still need.
A clean-device checklist keeps the order right:
- Preserve the device timeline, malware detection alerts, and collected artifacts
- Check for remote access tools and unknown local admins
- Review browser extensions and saved session data
- Patch the OS and apps after evidence capture
- Rebuild the device if trust is low or persistence is suspected
- Reconnect sync only after identity cleanup is complete
Rebuild is often the safer call for user devices that handled encrypted files or stolen tokens. On shared or high-value admin endpoints, full reimage is usually faster than arguing with uncertainty.
Also review admin workstations, jump boxes, and any device used to access the Microsoft 365 tenant during the attack window. If a compromised browser session touched the admin portal, your whole response can go sideways.
If you don’t have Defender on every endpoint, document that gap during the incident. It is not just a prevention issue. It is also a response speed issue.
Recover data in a way you can trust
Containment stops damage. Remediation removes attacker access. Recovery brings the business back. Those are separate jobs, and they need different sign-off points.
Do not restore broadly until you are confident about three things: the account path is clean, the device path is clean, and the sync process will not replay the attack. If any one of those is still open, restored data can get hit again.
For Microsoft 365 data, recovery usually starts with native options. You can leverage versioning and retention settings to roll back site libraries, as these tools often allow for simple recovery of specific files. SharePoint and OneDrive are the primary workloads involved in these recovery efforts, where recycle bins may cover deleted content and native history can reverse encryption events. For high-speed restoration during large-scale incidents, Microsoft 365 Backup Storage provides a modern, performant solution to get your data back online quickly.
Where native recovery is not enough, use tested immutable backups. This is essential for large-scale rollbacks, longer retention needs, or cases where the attacker damaged versions and deletions across many sites. A practical Microsoft 365 ransomware recovery guide is useful if you are weighing native restore against backup-led recovery.
Work in business order, not alphabet order. Restore the systems and datasets that keep payroll, patient care, jobsites, or client delivery moving first. Then, validate the environment with real users before you open the gates wider.
A few recovery rules save a lot of pain:
- Restore to a controlled group first.
- Watch for fresh encryption or mass rename activity.
- Reopen external sharing only after a thorough review.
- Rotate secrets and app credentials tied to affected systems.
- Keep heightened monitoring active for days, not hours.
If ransom payment enters the discussion, involve legal counsel, executive leadership, cyber insurance, and law enforcement contacts where appropriate. Payment does not prove decryption will work, and it does not erase breach or privacy duties.
Handle compliance, legal review, and the post-incident fix list
By the time recovery begins, the business will want one answer: “Are we back?” Security teams need a different one first: “Do we know what happened, what left the tenant, and whether the attacker still has access?”
Bring legal, privacy, and compliance leads in early if the incident touched regulated data. If your local capacity is exceeded, consider engaging the Microsoft Incident Response team to assist with complex investigations. This includes customer mail, HR records, health information, financial documents, and project data in SharePoint or Teams. If you are subject to breach notification rules or sector contracts, map the facts to those duties while evidence is fresh.
Purview can help preserve and review content, especially if you need to hold data, search for exposed records, or support an internal investigation. Keep copies of your timeline, decisions, logs, screenshots, and exported artifacts. Those records matter for insurers, auditors, customers, and board reporting.
After the dust settles, write the lessons learned while details are still clear. Incorporate findings from security audits into your updated incident response plan and keep the list blunt:
- Remove standing admin access where you can and use just-in-time access.
- Require phishing-resistant multi-factor authentication for admins.
- Review Conditional Access policies, legacy auth blocks, and specific app exclusions.
- Tighten app consent and monitor enterprise applications.
- Review Exchange Online Protection settings to better block phishing emails.
- Strengthen versioning and retention policies to protect against data loss.
- Perform regular SharePoint and OneDrive permissions checks.
- Test OneDrive, SharePoint, and Exchange recovery before the next incident.
- Put Defender, Intune, and audit coverage on every managed path.
Microsoft also keeps updated ransomware protection guidance for businesses, which is worth folding into your own runbooks.
A good post-incident review does not chase perfect paperwork. It fixes the gap that let the attacker in, then the gap that let them stay.
Frequently Asked Questions
Why shouldn’t I immediately wipe a device suspected of ransomware?
Wiping a device before capturing logs, screenshots, and forensic artifacts can destroy the best evidence of how the attacker gained access. It is vital to preserve the device timeline and configuration state to understand the attack’s scope and prevent recurrence.
Is a password reset enough to secure a compromised account?
No, a password reset alone is insufficient because attackers often maintain access through stolen browser sessions, active refresh tokens, or added unauthorized MFA methods. You must also revoke all active sessions and audit the account for newly added consent grants or malicious rules.
How does Microsoft 365 backup differ from native recovery tools?
Native tools like versioning and recycle bins are useful for simple file rollbacks, but they may be insufficient if an attacker has systematically deleted or encrypted content across multiple sites. Immutable backups provide a critical safety net for large-scale data restoration when native retention settings have been compromised.
Should I prioritize restoring data or securing the environment first?
Security and isolation must always come first to ensure the environment is safe before restoration begins. If you attempt to restore data while an attacker still holds an active session or a back door, the restored data is highly likely to be re-encrypted or stolen again.
Conclusion
Ransomware in Microsoft 365 is rarely one problem. It is an identity problem, a device problem, a mail problem, and a data problem at the same time.
The strongest Microsoft 365 ransomware response keeps those tracks separate: contain fast, preserve evidence, clean thoroughly, and restore with care. When your team treats identity as the first control point and recovery as the last step, the tenant comes back with fewer surprises. Ultimately, maintaining a Zero Trust posture is the best way to ensure identity remains a robust defense against evolving threats.
The best playbook is the one you have already tested before the next alert lands.