Most ransomware discussions focus on local endpoints — encrypted C: drives, locked servers, ransom notes on desktops. What gets far less attention is what happens to your Microsoft 365 data when ransomware hits a machine that has the OneDrive sync client running. The answer, in too many real incidents, is: it gets encrypted and synced straight to the cloud, overwriting the originals.
This isn't a hypothetical. The FBI's Internet Crime Report has consistently listed BEC and ransomware as the two most financially damaging cyber threats to organizations. A meaningful percentage of those ransomware cases now involve cloud data destruction — not just local disk encryption.
How the Sync Attack Actually Works
When the OneDrive sync client is running on an infected machine, it maintains a real-time mirror between local folders and SharePoint document libraries or personal OneDrive. The sync client doesn't evaluate whether the files being uploaded are healthy or encrypted — it just syncs whatever's in the local folder.
Ransomware that targets documents in a synced OneDrive folder will encrypt the local copies, and those encrypted versions then propagate to the cloud within minutes. Depending on how many files are involved and the sync rate, an entire SharePoint document library can be corrupted before your security tools generate a single alert.
SharePoint version history technically survives this — you can go back to a version before the encryption started. But there are two problems. First, you need to know when the encryption started (ransomware often dwell for hours before triggering mass encryption). Second, SharePoint version limits exist — if the ransomware cycled through file versions rapidly enough, the clean version may have been pushed off the version stack entirely.
Microsoft's Native Ransomware Detection
Microsoft 365 does have some ransomware detection built in. Microsoft Defender for Office 365 can flag suspicious file extensions appearing in OneDrive and trigger an alert — and it'll actually email the user and admin offering to roll back the affected files. This works reasonably well for known ransomware families with obvious encrypted file extensions like .locked or .encrypted.
It struggles with ransomware that uses non-standard extensions, that moves slowly to avoid detection thresholds, or that's a newer variant the detection signatures haven't caught. And even when detection works, "roll back to before the ransomware started" is not always a clean operation when the precise start time is unclear.
Why Immutable Backups Are the Real Answer
An immutable backup stored in S3 Object Lock — outside your M365 tenant and outside the reach of the OneDrive sync client — can't be overwritten by ransomware. It's not reachable from the infected machine, it's not controlled by your M365 Global Admin account (which may itself be compromised in a sophisticated attack), and it's not subject to version limits or sync mechanics.
The recovery workflow is also cleaner. Instead of trying to determine the exact ransomware start timestamp and rolling back within SharePoint's own infrastructure, you restore from a known-good snapshot to a clean environment. The backup happened on a schedule; you pick the last good snapshot and restore to that point.
For organizations that must meet DORA, NIS2, ISO 27001, or NIST CSF requirements around resilience and recovery, immutable offline backup is increasingly the control that auditors specifically ask about. Having it also means you negotiate from a position of strength if ransomware does hit — you recover from backup rather than negotiating with attackers.
The sync attack vector isn't going away. The only control that definitively defeats it is a backup copy that the sync client and the ransomware cannot reach.