Ransomware Gangs Are Mass-Exploiting a Microsoft SharePoint Flaw: What Security Teams Need to Know

Ransomware Gangs Are Mass-Exploiting a Microsoft SharePoint Flaw: What Security Teams Need to Know

Ransomware operators have joined state-aligned and financially motivated crews in a wave of mass exploitation targeting a widely deployed Microsoft SharePoint vulnerability. With public exploit code, automated scanning, and living-off-the-land tradecraft, on-prem SharePoint servers are being turned into turnkey entry points for domain-wide ransomware. This post unpacks what’s happening, how the exploits work, and the concrete steps to detect and defend.

Background

Over recent weeks, multiple security vendors and incident response teams have reported a surge in compromises of on-premises Microsoft SharePoint Server environments. The activity accelerated shortly after reliable proof-of-concept (PoC) exploit code circulated in public repositories and exploit frameworks. Ransomware groups—some previously known for abusing edge services like Exchange and VPN appliances—have now operationalized SharePoint exploitation to gain initial access, stage tooling, and pivot across Windows domains. The victims span mid-market to large enterprises across manufacturing, healthcare, education, and local government, reflecting the broad install base of legacy SharePoint farms. While campaign branding and payloads vary (with families such as LockBit derivatives and smaller affiliates observed), the pre-ransom playbook is strikingly consistent: exploit SharePoint, drop a webshell, enumerate, harvest creds, move laterally, exfiltrate, then encrypt.

Technical Analysis

The exploitation chains reported in the wild commonly abuse a server-side vulnerability in Microsoft SharePoint that enables remote code execution (RCE) via crafted HTTP requests to application pages or API endpoints. The vulnerability class is input validation and access control failure leading to code execution in the SharePoint web application context. In practice, attackers combine two steps: first, they achieve authenticated or pseudo-authenticated reachability to a susceptible endpoint; second, they trigger code execution to plant a persistent webshell or run living-off-the-land commands.

Key technical characteristics observed across incidents:
• Initial vector: Crafted POST/GET requests against SharePoint application pages (/_layouts/15/ and related virtual directories) exploiting a deserialization or parameter injection condition to execute arbitrary code under the SharePoint application pool identity (often a privileged service account in poorly hardened environments). Public PoCs automate request crafting and parsing of server responses to confirm code execution.
• Post-exploitation payloads: Lightweight ASPX webshells (variants of China Chopper-like stagers and simplified cmd-exec shells) dropped into writable locations, often unterminated log or temp directories that are later requested directly. Some actors leverage built-in SharePoint features (e.g., uploading page templates or using site assets) to smuggle payloads with benign-looking names.
• Living off the land: Execution via PowerShell (powershell.exe, powershell_ise.exe), certutil for payload staging, regsvr32 and mshta for LOLBIN-based stagers, and rundll32 for reflective DLL loading. WMI (wmic.exe) and scheduled tasks facilitate lateral movement and persistence.
• Credential access: Dumping LSASS via comsvcs.dll or procdump, harvesting cached credentials from the SharePoint server (which often has elevated access to SQL and domain resources), and abusing NTLM relays if SMB/LDAP signing is weak. In several cases, attackers leveraged the SharePoint service account’s over-privileged rights to access file shares and SQL backends.
• Discovery and lateral movement: Net view, nltest, AdFind/SharpHound for AD mapping; remote service creation (sc.exe), PsExec/WinRM for code execution on other hosts. SQL Server pivoting is common when SharePoint DBs are co-located or reachable from the compromised host.
• Ransomware staging: Before detonation, operators exfiltrate data using Rclone, Mega CLI, or SFTP, disable security tooling where possible, and deploy encryption binaries or scripts via GPO or PsExec. Dwell times have ranged from hours to a few days due to the low-friction initial access and high-privilege context.

Impact & Implications

Organizations running unpatched on-premises Microsoft SharePoint Server are at high risk of rapid, high-impact compromise. The combination of public exploit code, ubiquitous internet-facing deployments, and frequent misconfigurations (over-privileged service accounts, broad SQL access, legacy authentication) creates a near-ideal initial access vector. Beyond ransomware, the same foothold enables data theft, business email compromise via delegated rights, and supply-chain risk if SharePoint hosts integrate with build or release automation. Managed service providers hosting multi-tenant SharePoint farms face elevated blast radius. Even environments with EDR coverage are challenged because post-exploitation heavily uses native binaries and signed tooling. In short: this is not a niche bug—this is an operational trend, and attackers are standardizing it into their playbooks.

Defensive Recommendations

Prioritize these actions, in order:

1) Patch and verify: Apply the latest cumulative updates and security patches for Microsoft SharePoint Server across all farms (application, search, and front-end roles). Validate build numbers post-maintenance and confirm that the specific vulnerable endpoints return expected behavior. Where feasible, remove direct internet exposure and require VPN/ZTNA for administrative and user access.
2) Reduce privileges: Audit the SharePoint application pool and service accounts. Remove domain admin or high-privilege rights; adopt least privilege for SQL and file share access. Rotate credentials and enforce strong, unique service account passwords with Kerberos constrained delegation where needed.
3) Harden the surface: Enforce TLS-only, disable legacy authentication, and restrict access to /_layouts and admin pages with conditional access or reverse proxy rules. Use a web application firewall (WAF) or application gateway to filter anomalous HTTP methods and payloads; add virtual patch rules matching known exploit parameters and user agents from public PoCs.
4) Detect webshells and LOLBIN abuse: Monitor SharePoint content and IIS directories for unexpected ASPX, ashx, and asmx files. Alert on child processes of w3wp.exe spawning powershell.exe, cmd.exe, mshta.exe, regsvr32.exe, rundll32.exe, and certutil.exe. Collect and analyze IIS logs (sc-status 200/500 anomalies, spikes in POSTs to uncommon endpoints). Enable command-line auditing and PowerShell Script Block Logging.
5) Contain lateral movement: Enforce SMB and LDAP signing, restrict remote admin tools (PsExec/WinRM), and segment SharePoint servers from tier-0 assets (DCs, PKI). Apply endpoint rules to block LSASS dumping and disable WDigest. Evaluate Protected Process Light (PPL) for LSASS where supported.
6) Backup and recovery readiness: Maintain offline, immutable backups. Regularly test bare-metal restore for SharePoint and SQL content databases. Prepare an incident playbook covering SharePoint compromise, including isolating web front-ends, rotating service secrets, and re-securing farm configuration.
7) Threat hunting cues: Look for unexpected modifications under C:\\inetpub\\wwwroot\\wss\\VirtualDirectories\\, sudden changes in web.config, creation of new application pools or virtual directories, and spikes of 401/403 followed by 200 on sensitive endpoints. Correlate with outbound connections to file-sharing endpoints (e.g., rclone patterns) and sudden growth of scheduled tasks.

Conclusion

Ransomware actors have industrialized SharePoint exploitation because it’s reliable, scalable, and frequently yields privileged access. Expect continued weaponization in automated scanners and affiliate toolkits. Security teams should treat exposed SharePoint like any other critical edge service: patch aggressively, reduce privileges, instrument for web-tier post-exploitation, and contain pathways to tier-0. If your SharePoint is internet-facing and not fully current, assume exposure and hunt now. The window between PoC release and mass exploitation is measured in days—closing it is a matter of disciplined hygiene and layered detection.