SharePoint Mass Deletion: Telling an Attack From a Folder Move

Why a Mass Deletion in SharePoint Is Hard to Read

A burst of deletions in the SharePoint audit log looks the same whether it is ransomware, a departing employee wiping a site, or someone quietly re-filing a folder into another site. The audit log records that files were deleted; it does not record why. The signals that separate an attack from routine work are all in what happened around the deletes, not in the deletes themselves.

The root cause is a quirk of the platform. SharePoint has no move-between-sites operation. When a person re-files a folder from one site to another, SharePoint records it as a download from site A, an upload into site B, and a delete of the originals in site A. That is the same event sequence as encrypt-and-replace ransomware: read the file, write a new one, remove the original.

So the first question is never "were files deleted". It is "did the content go away, or did it move".

The Six Signals That Separate Destruction From Reorganisation

These are the checks worth running before you escalate, in rough order of how much they tell you.

1. Do the deleted filenames reappear as uploads?

The strongest single signal. If most of the deleted names show up as uploads somewhere in the tenant, the content moved. Genuine ransomware uploads novel encrypted payloads whose names do not match what was deleted, and a genuine wipe uploads nothing at all.

A high match rate, in the region of 80 percent or more of uploaded names matching files downloaded or deleted in the same period, is strong evidence of a move.

2. Are the delete sites and the upload sites the same or different?

This is the check that separates encryption from re-filing, and it is easy to miss.

Ransomware rewrites files inside each site. It deletes the original and uploads the encrypted copy in the same place. A move deletes in one site and uploads in another. If the set of sites where deletes happened and the set where uploads happened are completely separate, that shape is a move, not an attack.

3. Is there any encryption evidence at all?

A file carrying an extension from the known ransomware set, .locked, .crypted and similar, is unambiguous and should veto every benign explanation above. So should a rename pattern consistent with encryption.

Equally, its absence is informative. A plain bulk delete with no encryption signal means the files were recycled, not rewritten, which usually means they are recoverable from the SharePoint recycle bin. A bulk delete of 170 files to the recycle bin is an action to verify, not an encryption incident. Treating every large delete as ransomware is how teams end up ignoring the alert that matters.

4. Were folders created as well as removed?

Folders both appearing and disappearing is the signature of a restructure. Destruction removes folders and creates none.

5. Count the whole day, not the alert window

This one catches out most rule-based tooling, and it produces the majority of false alarms.

A sync client does not delete and re-upload in the same instant. The delete burst can land hours before the matching uploads, so a detection window of a few minutes sees only the deletes and calls it destruction.

A real example: a user re-syncing a reorganised image dataset produced 374 deletes in a single burst, which looks alarming in isolation. Across the whole day the same account produced 3,128 uploads and created 10 folders. Nothing was destroyed. Any assessment that only looked at the burst would have escalated it.

6. Compare uploads against deletes

Encrypt-and-replace removes an original and adds its encrypted copy at roughly one for one. More uploads than deletes, with no encryption signal, is the opposite of encryption. It is ordinary content turnover.

A real example: 61 old PDFs recycled and 103 new, differently named PDFs uploaded across four document libraries. That is document management, not an attack.

The Related Pattern: A Modification Burst

A large number of modifications rather than deletions raises the same question, and has its own tell.

Divide modifications by the number of distinct files touched. Encryption rewrites each file about once, so it produces a high file count at a ratio near one. Office co-authoring produces the opposite: a handful of files modified dozens of times each, at a ratio of ten or more. The ratio, not the raw modification count, is what separates them.

Two more shapes look like encryption and are not:

• Upload-dominated bursts. When new uploads meet or exceed modifications with no deletes or renames, content is arriving rather than being rewritten. A phone bulk-uploading its camera roll through the OneDrive mobile app registers a file-modified event per thumbnail, so it reads as a large modify burst. Genuine encrypt-in-place rewrites existing files and creates almost no uploads.
• Application data churn. Deleted names like .sst, MANIFEST and LOCK are an application's internal data folder syncing, not documents being destroyed.

What the Audit Log Will Not Tell You

Working through those checks by hand is possible for one incident. It does not scale, for three reasons.

There is no alerting. The unified audit log is a record you query, not a system that tells you something happened. If nobody runs the search, nobody knows. The methods and their limits are covered in SharePoint audit log.

The comparisons are cross-user and cross-site. Every check above requires correlating deletes in one place against uploads in another, across a whole day. That is not a single query.

There is a retention limit. Audit data does not persist indefinitely, and the window is usually shorter than the time it takes for anyone to notice files are missing.

The Signal Most Worth Watching

One correlation is worth more than any single rule: a restore burst from the recycle bin by the same account that produced a delete burst earlier the same day.

On its own, a large restore is usually benign, someone undoing a mistake. Following that account's own bulk delete, it is either a genuine correction or an attempt to tidy up after one, and either way somebody should know. Restore activity maps to MITRE ATT&CK T1070, Indicator Removal, for exactly that reason.

Automating the Distinction

Burrow applies these checks continuously rather than after someone notices. It reads every SharePoint and Entra ID audit event, applies detection rules with per-user behavioural baselines, and emails a short queue of alerts written in plain English with the MITRE ATT&CK technique named. Mass deletion maps to T1485 Data Destruction; encrypt-and-replace to T1486 Data Encrypted for Impact.

The demotion logic matters as much as the detection. A cross-site move that satisfies the name-match and separate-sites tests is demoted rather than escalated, and that verdict is shared with the other rules the same delete burst would otherwise trip, so a genuine re-filing produces at most one low-severity record instead of an incident. Any encryption evidence vetoes the demotion and the alert stays critical.

Burrow is a SaaS addon to the Squirrel platform, so for existing Squirrel customers it is a subscription change rather than a new deployment. The full detection reference is in the Burrow rule catalog.

Delete bursts are one case of a wider problem. Twelve more patterns where the platform generates activity that reads as an attack are in SharePoint audit log noise.

Frequently Asked Questions

How can I tell if a SharePoint mass deletion was ransomware?

Look for encryption evidence first: files carrying known ransomware extensions such as .locked or .crypted, or an encryption-style rename pattern. Absent that, check whether the deleted filenames reappear as uploads elsewhere and whether the delete and upload sites are separate. Ransomware deletes and re-uploads inside the same site with novel filenames; a move deletes in one site and uploads matching names in another.

Why does moving files between SharePoint sites look like an attack?

Because SharePoint has no move-between-sites operation. A cross-site move is recorded as a download from the source, an upload into the destination, and a delete of the originals, which is the same event sequence as encrypt-and-replace ransomware. The distinguishing factors are whether the uploaded filenames match the deleted ones and whether the two sets of sites overlap.

How many deleted files should trigger an alert in SharePoint?

There is no universal number, because it depends on tenant size and how the organisation works. As a reference point, a common default is around 100 deletions in a short window for a high-severity alert and around 30 for medium, tightened or loosened according to how noisy the environment is. Service accounts running scheduled deletions are the largest single source of false positives and are better handled with per-account exceptions than by raising the threshold for everyone.

Are files deleted in bulk from SharePoint recoverable?

Usually yes, if they were recycled rather than encrypted. Deleted items go to the site recycle bin and remain recoverable for 93 days by default. The exceptions are content that was permanently deleted, content past the retention window, and files that were rewritten rather than removed. See SharePoint Recycle Bin for the recovery path.

Does the SharePoint audit log alert on mass deletion?

No. The unified audit log is a searchable record, not a monitoring system. It has no alerting, no cross-user correlation and a finite retention window, so a deletion goes unnoticed unless somebody runs a search that happens to cover it. Alerting requires a tool that watches the event stream continuously.

What MITRE ATT&CK technique covers mass deletion?

T1485, Data Destruction, covers deletion intended to make data unavailable. T1486, Data Encrypted for Impact, covers ransomware that encrypts rather than deletes. Recycle-bin restore bursts map to T1070, Indicator Removal, because restoring content is one way to obscure what happened.

Related reading

• SharePoint Recycle Bin: how to recover deleted files
• SharePoint audit log: what it records and how to search it
• SharePoint audit log monitoring and alerts
• Departing employee data theft in Microsoft 365
• Microsoft 365 backup: what it covers and what it does not

Check Before You Escalate

The next time a delete burst appears, run the six checks above before treating it as an incident, and before treating it as noise. If you would rather the distinction were made automatically, see how Burrow monitors SharePoint audit events. Questions: sales@smikar.com.