Detect ransomware activity in Microsoft 365 by looking for mass file encryption, unusual file renames, rapid deletion or download activity, and suspicious mailbox or SharePoint permission changes. Alert on impossible travel, risky sign-ins, new forwarding rules, and administrative actions that disable recovery controls. Correlate user behaviour with tenant audit and identity logs.
What to look for when ransomware starts moving through Microsoft 365
Detection in Microsoft 365 is mostly about spotting a pattern, not a single alert. Ransomware activity often shows up as rapid, high-volume changes across files, identities, and sharing settings, especially when the attacker is already inside the tenant and trying to encrypt, delete, exfiltrate, or block recovery before anyone notices.
The most useful signal is a burst of abnormal behaviour that spans multiple services at once. File systems, Exchange, SharePoint, OneDrive, Entra sign-ins, and audit logs should all be read together, because a compromise that begins with one account often spreads through permissions, sync clients, mailbox rules, and admin actions rather than through one obvious malware event.
Good detection starts with baselining what normal looks like for each user and role. A finance user renaming hundreds of files, a service account creating forwarding rules, or an admin changing recovery-related settings may each be benign in isolation. The pattern becomes meaningful when the volume, timing, and account type do not fit normal work.
Identity, mailbox, and SharePoint signals that matter most
Identity activity is often the earliest sign that the attacker is steering toward encryption or data theft. Impossible travel, risky sign-ins, MFA fatigue patterns, unfamiliar devices, and new geo-locations should be correlated with later tenant actions, because ransomware crews frequently use valid credentials before they touch files.
Watch for mailbox rule creation, auto-forwarding, delegate permission changes, and suspicious sign-in followed by bulk message access or deletion. In Microsoft 365, those actions can support operational disruption, phishing persistence, or evidence removal, and they often appear before the user reports any visible file problem.
SharePoint and OneDrive deserve separate attention because attackers may abuse sharing links, revoke access, or alter permissions to block recovery and widen impact. A change in folder ownership, external sharing state, or tenant-wide permission settings can be as important as file encryption when the objective is to control what defenders can still reach.
File, audit, and recovery-control patterns that indicate active ransomware
Mass file rename activity, rapid overwrite of documents, and a spike in failed file opens are classic indicators, but they are not enough on their own. The stronger signal is a sequence that combines those changes with deletion of shadow copies, disabling of backup or retention settings, and unusual administrative actions in the same time window.
Tenant audit logs should be checked for actions that disable or weaken recovery, such as changes to retention, eDiscovery, mailbox auditing, conditional access, or privileged role assignments. A ransomware operator who can reach these controls is trying to reduce the defender’s ability to respond, not just to damage data.
Endpoint telemetry and Microsoft 365 audit data should be correlated, not reviewed separately. A sync client or endpoint process may appear as the source of many file changes, but the underlying cause may still be a compromised identity, a malicious OAuth app, or a script using a legitimate account with excessive permissions.
Where to focus first when Microsoft 365 ransomware is suspected
Start by identifying the first account, device, or app that showed abnormal behaviour, then work outward from that point. If the same identity shows risky sign-ins, permission changes, forwarding rules, and mass file operations, treat it as the likely pivot point rather than looking for a single infected workstation.
Use the Microsoft 365 audit trail, Entra sign-in logs, and workload-specific logs to separate user error from active compromise. A small number of verified events that line up across services is more useful than a large number of isolated alerts that never connect to the same identity or time window. For a broader hardening baseline that supports this kind of triage, see the Microsoft 365 Security Guide.
If the behaviour involves shared tenants, backup tooling, or third-party integrations, validate whether the attacker is abusing a trusted connector or service account rather than a normal interactive user. That is especially important in Microsoft 365 because a compromise may surface first as administrative misuse, not as obvious malware on an endpoint. The SaaS Security Guide is useful when you need to trace that broader service-to-service trust path.
Risk and Threat Considerations
Microsoft 365 ransomware often succeeds by abusing legitimate access, not by dropping a loud executable. The threat is highest when one identity can modify files, permissions, forwarding rules, and recovery settings across multiple services, because that combination lets an attacker both cause damage and delay response.
Failure mechanism: A compromised account or app token is used to perform high-volume file operations, alter mailbox and SharePoint controls, and weaken recovery options before defenders can isolate the activity.
Impact: Organisations can lose availability, integrity, and recovery confidence at the same time, especially when the same identity has broad tenant permissions or access to shared content and backup-related settings.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Microsoft 365 ransomware detection depends on correlated audit and identity logs. |
| Recommendation — Centralise and review audit logs for sign-in, file, mailbox, and admin activity. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | The answer relies on correlating Microsoft 365 audit and identity telemetry to spot compromise. |
| IA-5 — Authenticator Management | Impossible travel, risky sign-ins, and credential abuse point to authenticator compromise or misuse. | |
| AC-6 — Least Privilege | Overbroad admin and SharePoint rights increase ransomware blast radius and recovery suppression. | |
| Recommendation — Analyze audit events across Microsoft 365 services for correlated signs of malicious activity. Rotate and revoke exposed credentials, tokens, and session material when compromise is suspected. Reduce privilege so no single account can alter files, sharing, and recovery controls broadly. | ||
Practitioner Guidance
What to prioritise: Correlate the first abnormal sign-in with the first mass file or permission change, then decide whether the account, device, or app is the primary compromise path. That sequence usually tells you more than the encryption events themselves.
What to verify: Confirm whether the suspicious activity came from an interactive user, a sync client, a delegated admin, or a non-interactive integration, because containment and credential rotation decisions differ for each.
What good looks like: You can explain the incident as one connected chain across sign-in, privilege, file activity, and recovery-control changes, rather than as a collection of unrelated Microsoft 365 alerts.
Practitioner takeaway: In Microsoft 365, ransomware detection is strongest when identity telemetry and workload telemetry tell the same story, because the attacker’s objective is usually to reach data and recovery controls through legitimate access.
Related resources from NHI Mgmt Group
- Guide: Ransomware Prevention Guide
- How do you detect activity performed by terminated users in Microsoft 365?
- How do you detect Microsoft 365 activity from anonymous or suspicious IP addresses?
- How do you detect suspicious OAuth app file download activity in Microsoft 365?
- What should you monitor to detect suspicious device activity in Microsoft Entra ID?