How to Secure SharePoint Server File Repositories

When on-premises SharePoint users and admins upload a file, that file is scanned with either a third-party antivirus or AMSI-compatible engines (such as Microsoft Defender). If the file passes that initial scan, it’s considered handled. Clean once, clean forever. The assumption is exactly how malware and ransomware payloads get to sit inside the repository undetected;, sometimes for years.

Microsoft says as much directly: SharePoint’s malware protection can limit damage, but doesn’t serve as a single point of defense.

For BFSI (Banking, Financial Services, and Insurance), healthcare, government, and OT (Operational Technology) or Critical Infrastructure environments, the data at risk means compliance filings, patient records, case files, and engineering documentation. All sitting in a library that keeps growing, year over year, while nothing goes back to re-examine what's already inside.

What follows comes down to three things: how SharePoint antivirus scanning actually works, what it doesn't cover, and what layered, effective SharePoint file repository security should look like.

Enlyft's technology-adoption data tracks 256,295 companies currently running Microsoft SharePoint, spanning industries from IT services to banking, healthcare, oil and gas, and government. These companies typically range in the 50–200 employee, with $1M–$10M in revenue.

The scale is exactly why attackers pay attention and treat SharePoint repositories as high-value targets.

None of the above is to say that SharePoint doesn’t secure its servers or neglects file security. Per Microsoft’s documentation, SharePoint Server integrates with two possible scanning interfaces;:

• VSAPI (Virus Scanning API), a SharePoint antivirus integration interface that allows compatible third-party antivirus software to scan documents during operations such as upload and download.

• AMSI (Antimalware Scan Interface), a Microsoft antimalware integration framework that enables SharePoint Server to submit files to AMSI-compatible antivirus engines (such as Microsoft Defender) for malware scanning during supported content operations.

The SharePoint Server can be configured to use VSAPI, AMSI, or automatic mode. Regardless of which option is set, only one scanning engine evaluates a file at a time.

Scanning is event-based and triggered when users upload or download documents, not retroactively or periodically. Only one engine (the Microsoft Malware Protection Engine, commonly known as MpEngine.dll) evaluates the file.

Key takeaway: Files are scanned with a single engine, at upload or download, using that engine's current signatures and detection capabilities.

The approach isn’t designed to catch a file-borne threat purpose-built to evade that specific engine detection logic. Advanced persistent threats, in particular, often exploit precisely this limit, lying undetected for extended periods.

That persistence opens a door for attackers to weaponize trusted SharePoint content. There already are documented attacks where threat actors abused compromised SharePoint sites to host phishing documents and malicious links.

A zero-day will clear the scan the same way a clean file does, simply because there's no engine flagging it yet. And because SharePoint doesn't re-scan existing content later, a zero-day file that passes on day one doesn't get a second look on day two hundred, even after the vendor ships a signature update that would catch it.

Unknown threats follow the same logic. With no signature attached to it, static analysis (what antivirus engines do), can’t detect the threat.

Note: these are gaps in scope rather than defects. SharePoint Server's native antivirus was built for point-in-time checks at specific interaction points, not for continuously re-validating a growing, versioned repository against an evolving threat landscape.

In July 2025, Microsoft disclosed active exploitation of an unauthenticated remote-code-execution chain affecting on-premises SharePoint Server: CVE-2025-49706, CVE-2025-49704, later joined by CVE-2025-53770 and CVE-2025-53771. The exploit didn’t need credentials or a login to work.

Microsoft then patched it, and the exploit chain got a name: ToolShell.

Per Eye Security's analysis, cited by Infosecurity Magazine, 396 compromised systems turned up across 145 organizations in 41 countries. Government took the hardest hit, accounting for 30% of confirmed infections, and the US alone made up 31% of the total. Separately, the Shadowserver Foundation reported that more than 10,700 SharePoint instances remained exposed, reachable by anyone running the same exploit chain, even after the vulnerability, which compromised hundreds of organizations, went public. Storm-2603, one of the groups behind the exploit, turned that exposure into a Warlock ransomware payload.

Once they were in, Storm-2603 used stolen credentials and legitimate admin tools to move laterally across systems. This movement didn’t raise any alarms, as it relied on tools which were supposed to be there. Storm-2603 installed web shells and exfiltrated important data. They maintained access even after the vulnerability was patched, because the attackers had already stolen the keys needed to fake valid authentication tokens.

ToolShell was built on four CVEs, chained together, with patch bypasses built in from the start. CVE-2025-53770 and -53771 exist specifically because the original fixes for CVE-2025-49704 and -49706 could be routed around.

What really matters is that an an attacker adapted faster than the patch cycle, twice, on the same target, within weeks.

Static controls like single AVs checking a file once, against one vendor's signatures were never designed to catch a server-side exploit chain in the first place. And they can’t defend against an attacker who returns after the patch with a bypass for the patch.

ToolShell demonstrates the level of sophistication now aimed at SharePoint servers specifically. There's no reason to assume it was the last time such an exploit happened. Is the data sitting on these servers protected by something built to keep up, or by a scan that checks once and calls it done?

To be fair, ToolShell wasn't a malicious document slipping past an upload scan. But the web shell (spinstall0.aspx and its renamed variants) attackers dropped? That's a file. It sat on the server and whether it got flagged came down to the same limits described earlier: one engine, checked once, at a single point in time.

That's the mechanism connecting this incident back to the broader argument. Patching closes the ToolShell exploit chain specifically. It does nothing for the next unscanned file already sitting in a repository.

None of the above matters much for content sitting untouched since 2023 unless it actually gets scanned.

This is the layer native SharePoint antivirus can't support: revisiting stored content, including older versions retained through version history, on a recurring or continuous basis rather than only at upload or download. Real-time, scheduled, and on-demand rescanning addresses the gap, periodically inspecting files as databases update.

Individually, each of these controls closes one specific gap addressed earlier. Together, they form the kind of layered defense Microsoft's own documentation points toward when it says built-in antivirus isn't meant to be a single point of defense.

MetaDefender Storage Security can be deployed through various models: physical Servers for direct hardware installations, Virtualization Platforms (compatible with VMware, Hyper-V, and XenServer), IaaS (Infrastructure as a Service) from major cloud providers, or through containerized deployments in Kubernetes clusters.

This checklist is based on CISA's guidance on the ToolShell exploit.

1. Confirm patch status.

All CVEs exploited have security updates available, but unpatched servers remain exposed to ToolShell. Apply Microsoft's security updates for all affected SharePoint Server versions.

2. Verify AMSI is configured.

Deployed but misconfigured AMSI leaves the same gap as no AMSI at all. Confirm AMSI integration is enabled and an antivirus solution is deployed on every SharePoint server.

3. Rotate ASP.NET machine keys

Stolen machine keys let attackers forge valid authentication tokens even after a server is patched. Patching alone doesn't invalidate keys already stolen. Rotate machine keys, apply the security update, then rotate machine keys again. Restart IIS using iisreset.exe after each rotation to remove malicious entries from applicationHost.config and web.config.

4. Manually look for signs of prior compromise.

CISA notes that .dll payloads used in this campaign can be used to obtain machine keys. Patching doesn't remove the payload already dropped on the server. Inspect systems and specific files for IOCs (Indicators of Compromise), not just for the vulnerability itself.

5. Check for end-of-life or end-of-service versions.

Some SharePoint instances are EOL and receive no further security updates, regardless of exploitation activity. Check if versions used by your company are still supported. If not, take the necessary steps.

6. Review logs for known indicators

CISA identifies specific request patterns and IPs tied to this campaign. Search logs for requests matching CISA references.

7. Audit admin and layout privileges.

To limit damage scope, review who holds layout and administrative permissions on SharePoint and remove access that isn't actively needed.

8. Assess what's already stored, not just what's currently exposed

Everything above addresses the exploit chain itself. None of it evaluates content already sitting in document libraries, including files that predate any of these patches.

Determine whether existing repository content has been rescanned since the relevant patches and signature updates, or whether it's still carrying its original, potentially outdated scan verdict.