Can SharePoint files be recovered after ransomware?

Usually, yes. Ransomware reaching SharePoint through a synced client either edits files in place (recoverable from version history) or deletes and recreates them (recoverable from the recycle bin within 93 days). Restore this library covers the last 30 days for a whole-library rollback.

Does Microsoft 365 protect against ransomware?

SharePoint and OneDrive keep version history and a 93-day recycle bin, OneDrive detects mass-encryption patterns and offers a rollback, and Microsoft 365 Backup (paid) adds restore points. None of that helps if the infected device is still syncing.

Should I use "Restore this library" after ransomware?

If the whole library was encrypted and it happened within 30 days, yes — it is the fastest full rollback. If only part of the library was hit, a targeted restore of the affected files avoids undoing other people's work.

Ransomware hit a SharePoint library. The recovery order that doesn't re-infect you

SharePoint keeps versions and a recycle bin, so encrypted files are usually recoverable. The order matters — clean the endpoints, stop the sync, identify the pattern, then restore — or the restored files get encrypted again.

Ransomware on a laptop that syncs a SharePoint library turns into ransomware in SharePoint within minutes. The good news: SharePoint's version history and recycle bin mean the data is almost always still there. The bad news: people restore first and clean up second, and watch the restored files get encrypted again.

1. Contain before you restore

Isolate the infected devices. Off the network, or at least sign out of OneDrive on them. Every minute they stay connected they can re-encrypt what you restore.
Find every device syncing the affected libraries. SharePoint admin centre → the site → Activity, or the audit log filtered on FileSyncDownloadedFull / FileModified from the incident window, shows which users' clients were writing.
Disable the affected users' sign-ins if you are not sure which device it was. Their tokens are what the malware is using.
Only then move on. Everything below assumes the encryption has stopped.

2. Work out which pattern you are dealing with

Open one encrypted file's version history. Ransomware does one of two things:

Edit in place. The file keeps its name (or gets an extension appended), version history shows the clean version followed by the encrypted one. Recovery = restore the prior version. This is the common case with synced clients.
Delete and recreate. The original is gone (in the recycle bin), a new file with a ransom extension sits in its place with only one version. Recovery = delete the new files, restore the originals from the recycle bin.

Many strains do both across a library. Check a few files in different folders.

3. Decide: whole library, or targeted

Whole library, within 30 days: Restore this library (library → Settings gear → Restore this library), set to one minute before the first encrypted write. It handles both patterns in one pass and is the fastest route when nothing legitimate happened in the library since. Files created by the malware move to the recycle bin; encrypted edits revert.

Targeted: when other people kept working in the library, or it is past 30 days, or the hit was one folder tree. Restore only the files modified by the compromised account(s) in the incident window:

Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/Finance -Interactive

$accounts = 'victim1@contoso.com','victim2@contoso.com'
$from     = Get-Date '2026-07-19 22:40'

Get-PnPListItem -List 'Shared Documents' -PageSize 2000 -Fields FileRef,Modified,Editor |
  Where-Object { $accounts -contains $_['Editor'].Email -and $_['Modified'] -gt $from -and $_.FileSystemObjectType -eq 'File' } |
  ForEach-Object {
    $prev = Get-PnPFileVersion -Url $_['FileRef'] | Where-Object Created -lt $from | Sort-Object Created -Descending | Select-Object -First 1
    Restore-PnPFileVersion -Url $_['FileRef'] -Identity $prev.Id -Force
  }

Files with no prior version are the delete-and-recreate cases; the restore fails on them. Remove those and restore the originals from the recycle bin filtered by Deleted by those accounts.

That is the 80% version. The checks that stop it restoring the wrong thing — showing you the list first, skipping files it should not touch, and confirming afterwards — are the part we built the tool for.

4. Verify, then reconnect

Spot-check restored files open cleanly.
Search the library for the ransom extension; anything left is a new-created file to delete.
Only after the endpoints are rebuilt, re-enable sync. Prefer Add shortcut to OneDrive over syncing whole libraries; it limits what a future infection can reach.
Preserve the list of restored files and the audit log export for the insurer and the incident report.

What Microsoft gives you, and what it doesn't

Version history (500 major versions by default), the 93-day recycle bin and Restore this library are enough for most sync-borne incidents. OneDrive's own ransomware detection covers personal OneDrive, not SharePoint libraries. Microsoft 365 Backup adds proper restore points and reaches further than 30 days, at a per-GB price. None of it is a substitute for step 1.

The part that is genuinely hard by hand is the targeted restore: building the list of affected files, seeing which have a clean prior version and which do not, and running the restores with a record of what was done. Rollback365's dry run does exactly that classification before anything is restored, and restores by named version, so it removes nothing.