Ransomware Hit a File Share Synced to SharePoint — Recovery Steps

A ransomware infection on one computer can quickly become a SharePoint incident when a shared folder is synchronised through OneDrive.

The malware encrypts or renames files on the local device. OneDrive then treats those changes like ordinary edits and synchronises them to the SharePoint document library. Other employees may soon see unreadable files, unfamiliar extensions, ransom notes or thousands of unexpected changes.

The most important response is not to begin restoring immediately.

First, stop the synchronisation, isolate the infected equipment and identify when the malicious changes began. Restoring SharePoint while a compromised device is still connected can result in the recovered files being encrypted again.

Microsoft’s own ransomware guidance recommends immediately stopping OneDrive synchronisation or disconnecting any mapped drive connected to the affected SharePoint library before attempting recovery. 

This guide explains the practical recovery sequence.

How Ransomware Reaches SharePoint

SharePoint Online itself may not be the system on which the ransomware executed.

A typical chain looks like this:

1. An employee opens a malicious attachment or application.
2. Ransomware encrypts files available to that computer.
3. The affected folders include a SharePoint library synchronised through OneDrive.
4. The OneDrive client uploads the encrypted versions.
5. Other users receive the changed files through their own synchronisation clients.

The same problem can occur when a legacy file share is being migrated or continuously synchronised into SharePoint.

The cloud has faithfully copied the changes it was instructed to copy. Recovery therefore requires both endpoint containment and cloud restoration.

Step 1: Stop the Synchronisation Immediately

On every suspected affected device:

• Pause or quit OneDrive.
• Disconnect mapped drives to SharePoint.
• Disconnect the device from wired and wireless networks.
• Use endpoint security tooling to isolate the computer where available.
• Tell the user not to reconnect or restart synchronisation.

Do not simply close File Explorer.

The OneDrive client may continue synchronising in the background.

If several employees report encrypted files, determine whether more than one endpoint is affected. A second infected computer can continue uploading malicious changes after the first device is isolated.

Also consider temporarily restricting access to the affected SharePoint site while the investigation is underway. This can prevent well-meaning users from moving, renaming or restoring files and complicating the timeline.

Step 2: Protect the Rest of the Environment

Treat the incident as more than a damaged folder.

Investigate whether the ransomware gained access through:

• A compromised Microsoft 365 account
• A phishing email
• A malicious download
• Remote-access software
• An unpatched endpoint
• A shared administrator credential
• A vulnerable line-of-business application

Immediate containment may include:

• Blocking the affected user account
• Revoking active Microsoft 365 sessions
• Resetting credentials from a known-clean device
• Removing suspicious authentication methods
• Isolating additional endpoints
• Blocking malicious hashes, URLs and domains
• Reviewing administrative activity
• Checking other synchronised libraries

Do not reconnect the original computer merely because antivirus software reports that it removed one detected file. The endpoint should be considered untrusted until it has been properly investigated, cleaned or rebuilt.

Step 3: Record the Incident Timeline

Before restoring anything, determine when the malicious activity started.

Record:

• The first reported encrypted file
• The first unusual filename or extension
• The earliest ransom note
• The affected user and device
• The affected SharePoint sites and libraries
• OneDrive synchronisation activity
• Security alerts
• Sign-in events
• File modification and deletion activity
• Actions already taken by users or administrators

The restore point must be earlier than the first malicious change—not merely earlier than the time the incident was reported.

A user may notice the damage at 9 a.m. even though encryption started at 2:15 a.m.

The SharePoint library restore interface includes an activity graph and feed covering recent activity, which can help identify the start of a mass change or malware event. 

Step 4: Confirm the Scope

Identify whether the ransomware affected:

• One document library
• Several libraries in one site
• Multiple SharePoint sites
• Individual OneDrive accounts
• Teams files
• Local file shares outside Microsoft 365
• Backups or network storage

Files uploaded to standard Teams channels are stored in the connected SharePoint site. Files shared in chats are usually stored in the sender’s OneDrive. The recovery process may therefore involve both SharePoint library restoration and individual OneDrive restoration.

Search for common indicators such as:

• New file extensions
• Sudden mass renaming
• High volumes of modified files
• Bulk deletion
• Ransom-note filenames
• Activity from one user or endpoint

Avoid restoring unaffected libraries unnecessarily. A broad rollback can remove legitimate work created after the selected recovery point.

Step 5: Choose the Appropriate Recovery Method

There are several recovery options, and the correct one depends on the scale of the damage.

Restore Individual File Versions

Use version history when only a small number of files were encrypted or overwritten.

In SharePoint:

1. Locate the affected file.
2. Open its menu.
3. Select Version history.
4. Review versions created before the attack.
5. Restore the last known-good version.

SharePoint version history exists specifically to let users view and restore earlier versions after accidental changes or malicious activity such as ransomware. 

This method is suitable for a handful of documents, but manually restoring hundreds or thousands of files is inefficient and prone to error.

Restore Deleted Items

If the ransomware deleted files instead of encrypting them, check:

• The site Recycle Bin
• The second-stage site collection Recycle Bin
• The OneDrive Recycle Bin, where relevant

This is also useful for recovering files created after a wider library rollback, because newer files may be moved to the Recycle Bin during a point-in-time restore.

Restore the Entire SharePoint Library

When large numbers of files were changed, encrypted, renamed or deleted, use Restore this library.

A site administrator can:

1. Open the affected document library.
2. Select Settings.
3. Select Restore this library.
4. Choose a suggested date or a custom date and time.
5. Review the activity graph and list of changes.
6. Select a point immediately before the ransomware activity.
7. Start the restore.

The feature can undo actions within the previous 30 days and is intended for incidents including ransomware, file corruption and mass deletion. 

The restore returns the library to its state before the first selected activity. Microsoft also allows a library restore itself to be reversed if the wrong point was chosen. 

Restore an Entire OneDrive

When the affected content belongs to an individual OneDrive rather than a SharePoint library, use Restore your OneDrive.

This can undo file and folder actions from within the previous 30 days, including overwriting, deletion, corruption and malware-related changes. 

Step 6: Understand What a Library Restore Will Change

A point-in-time restoration is not limited to encrypted files.

It may also reverse legitimate actions that occurred after the selected restore point, including:

• New documents
• Approved edits
• Renamed folders
• Moved files
• Deletions
• Permission-related item changes

Before starting the restore:

• Inform site owners and affected teams.
• Identify business-critical files created after the restore point.
• Export or preserve unaffected new work where practical.
• Record the chosen date and time.
• Confirm who authorised the rollback.

Users should avoid editing the library while restoration is underway.

Afterwards, check the Recycle Bin for legitimate files created after the chosen point and restore them selectively where required.

Step 7: Keep All Sync Clients Disconnected During Recovery

Do not allow employees to resume OneDrive synchronisation as soon as files begin looking normal online.

The safe order is:

1. Contain and remove the ransomware.
2. Confirm the cloud restore has completed.
3. Validate representative files through the browser.
4. Rebuild or certify affected endpoints as clean.
5. Remove corrupted local synchronisation copies.
6. Reconnect one controlled test device.
7. Observe synchronisation.
8. Reconnect remaining devices gradually.

A computer containing encrypted local files may interpret them as newer changes and upload them again.

For heavily affected endpoints, rebuilding the operating system is often safer than trying to prove that every component of the malware has been removed.

Step 8: Validate the Recovered Data

Do not judge success solely by the absence of ransom-note files.

Test:

• Documents from several folders
• Different file types
• Recently modified files
• Older archive files
• Permissions and sharing links
• Teams access
• OneDrive synchronisation
• Business applications using the library

Ask business owners to confirm that the restored information is usable and complete.

Keep the affected library under heightened monitoring for renewed mass modification, deletion or renaming activity.

What if the Damage Is Outside the 30-Day Window?

The built-in Files Restore capability is designed around a 30-day recovery window. Reducing version-history availability can also weaken the effectiveness of library restoration because Files Restore relies on retained file versions. 

When the incident is older, options may include:

• Restoring available individual versions
• Recovering deleted content still within retention
• Using Microsoft 365 Backup
• Using an independent Microsoft 365 backup product
• Escalating the case to Microsoft Support
• Reconstructing data from other verified sources

Microsoft 365 Backup supports SharePoint and OneDrive restoration using available backup restore points, including full-site and selected-content recovery options. 

This is why version history and retention should not be treated as a complete backup strategy. They provide valuable recovery tools, but a separate backup service can offer longer recovery periods and additional operational options.

Preventing the Same Incident From Happening Again

After recovery, address the control failures that allowed the incident to spread.

Review:

• Endpoint detection and response coverage
• Device patching
• Local administrator rights
• Email attachment and link protection
• Multifactor authentication
• Conditional Access
• Legacy authentication
• OneDrive Known Folder Move
• SharePoint version-history limits
• Backup coverage and restore testing
• User security training

Do not disable OneDrive synchronisation permanently as the main lesson from the incident. Synchronisation provides important productivity benefits, and SharePoint offers recovery capabilities specifically designed for mass changes and ransomware.

The better solution is to strengthen the endpoints, identities, monitoring and recovery plan surrounding it.

Ransomware Recovery Checklist

Contain

• Stop OneDrive synchronisation.
• Disconnect mapped SharePoint drives.
• Isolate affected devices.
• Block compromised accounts where necessary.
• Revoke active sessions.
• Search for additional infected endpoints.

Investigate

• Identify the first malicious file activity.
• Determine every affected library and OneDrive.
• Review endpoint, sign-in and audit logs.
• Preserve ransom notes and security evidence.
• Confirm the likely initial access route.

Restore

• Select a restore point before the first malicious activity.
• Restore individual versions for limited damage.
• Use Restore this library for mass changes.
• Restore affected OneDrive accounts separately.
• Recover valid post-restore files from the Recycle Bin.
• Use backup recovery when built-in options are insufficient.

Validate

• Test restored documents.
• Confirm permissions and Teams access.
• Keep infected devices disconnected.
• Reconnect clean endpoints gradually.
• Monitor for repeated encryption or deletion.

Final Thoughts

When ransomware reaches SharePoint through a synchronised file share, speed matters—but restoring too quickly can make the situation worse.

Stop synchronisation first. Isolate the source device. Determine exactly when the damaging activity began, then choose the narrowest recovery method that fits the scale of the incident.

Use version history for individual files, the Recycle Bin for deletions and Restore this library for large-scale encryption or corruption. Keep every suspect endpoint disconnected until the restored SharePoint data has been validated and the devices are known to be clean.

The recovery sequence is straightforward:

Stop the sync. Contain the infection. Find the clean point. Restore once. Reconnect carefully.

Has Ransomware Damaged Your SharePoint or OneDrive Files?

Hamilton Group can help your business contain and recover from ransomware affecting Microsoft 365 and synchronised file storage.

Our experts can help you:

• Isolate infected devices
• Stop harmful OneDrive synchronisation
• Investigate Microsoft 365 accounts and endpoints
• Identify affected SharePoint libraries
• Restore document libraries and OneDrive accounts
• Recover files from version history and backups
• Validate restored business data
• Rebuild compromised devices safely
• Configure Microsoft 365 Backup
• Strengthen your ransomware response plan

Visit hgmssp.com, call Hamilton Group on 0330 043 0069, or book a meeting with one of our experts for urgent support recovering SharePoint and OneDrive data after ransomware.