CISA has confirmed what many of us in IR have suspected for weeks: encryption-based cyber incident gangs — ransomware operators — are now actively abusing a high-severity unauthenticated remote code execution vulnerability in on-premises Microsoft SharePoint Server. The flaw has been flagged as actively exploited since early July 2025, and its inclusion in ransomware intrusion chains marks a significant escalation. What began as espionage-style webshell planting against perimeter SharePoint boxes has matured into a full ransomware delivery mechanism.
If you run SharePoint Server 2016, 2019, or Subscription Edition on-premises and it is reachable from the internet — or even reachable from a segment an attacker can pivot into — you are in the blast radius. SharePoint Online (Microsoft 365) is not affected. The unauthenticated nature of this flaw is the critical detail: no credentials, no phishing, no user interaction. An attacker sends crafted requests to the server and executes code in the context of the SharePoint web application pool account, which in far too many environments runs with excessive privilege.
This post breaks down the attack chain from a defender's perspective, gives you production-quality Sigma, KQL, and VQL detections, and walks through remediation — including the machine key rotation step that most organizations skip and get re-compromised over.
Technical Analysis
Affected Products
- Microsoft SharePoint Server Subscription Edition (on-premises)
- Microsoft SharePoint Server 2019 (on-premises)
- Microsoft SharePoint Server 2016 (on-premises)
- Not affected: SharePoint Online in Microsoft 365
End-of-life versions (SharePoint 2013 and earlier) do not receive fixes. If you are still running them exposed, that is a separate, urgent conversation.
How the Attack Works
From observed intrusions, the chain follows a consistent pattern:
- Initial access: The attacker sends specially crafted HTTP POST requests to SharePoint web endpoints — no authentication required. The vulnerability allows deserialization-style abuse that yields code execution inside the IIS worker process (
w3wp.exe) serving the SharePoint application pool. - Webshell deployment: Post-exploitation, operators consistently drop ASPX webshells into the SharePoint LAYOUTS directory (
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\on SharePoint 2019/SE,...\15\...on 2016). Filenames observed in the wild follow the pattern of randomized names such asspinstall0.aspxand similar. These files are web-accessible under/_layouts/15/or/_layouts/16/without additional auth. - Machine key theft: A defining behavior of this campaign is extraction of the SharePoint server's ASP.NET
ValidationKeyandDecryptionKey(machine keys) via the webshell. Possession of these keys lets the attacker forge valid__VIEWSTATEpayloads and re-enter the server at will — even after patching. This is why patching alone is insufficient. - Discovery and lateral movement: From
w3wp.exe, operators spawncmd.exeandpowershell.exefor enumeration (whoami,ipconfig,net group,nltest, AD discovery), dump LSASS where privileges allow, and move laterally via SMB/RDP/WMI toward domain controllers and file servers. - Encryption: The ransomware payload is staged, backups (VSS) are deleted via
vssadminorwmic, and mass encryption follows — often days to weeks after the initial SharePoint compromise.
Exploitation Status
- Actively exploited since early July 2025, confirmed by Microsoft, CISA, and multiple incident response firms.
- Listed in the CISA Known Exploited Vulnerabilities (KEV) catalog with a federal remediation deadline — treat that deadline as your own, regardless of sector.
- Now confirmed in use by ransomware/encryption-based extortion crews, per CISA's latest update. This moved from targeted intrusion to commoditized ransomware initial access.
- Public exploit code and scanner tooling exist. Scanning for vulnerable SharePoint instances is trivially automated — assume every internet-exposed on-prem SharePoint server has been probed.
The key operational takeaway: the dwell time problem. Many organizations patched in July but never hunted for the webshells or stolen machine keys left behind. Ransomware crews buy or reuse that access. If you patched without investigating, you may have an attacker already inside.
Detection & Response
Sigma Rules
---
title: SharePoint IIS Worker Process Spawning Command Shell
id: 9b2e4f61-3c8a-4d71-b5e2-7f0a1c9d4e6b
status: experimental
description: Detects the SharePoint IIS worker process (w3wp.exe) spawning command interpreters or scripting engines, consistent with webshell activity following exploitation of the unauthenticated SharePoint RCE flagged by CISA as actively exploited since July 2025.
references:
- https://www.bleepingcomputer.com/news/security/cisa-microsoft-sharepoint-flaw-now-exploited-in-ransomware-attacks/
- https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/01/15
tags:
- attack.persistence
- attack.t1505.003
- attack.execution
- attack.t1059
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith: '\w3wp.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\powershell_ise.exe'
- '\pwsh.exe'
- '\cscript.exe'
- '\wscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\wmic.exe'
- '\vssadmin.exe'
- '\net.exe'
- '\net1.exe'
- '\whoami.exe'
- '\nltest.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
condition: selection_parent and selection_child
falsepositives:
- Rare legitimate SharePoint admin tooling; verify against change windows and administrator accounts
level: high
---
title: Webshell Dropped in SharePoint LAYOUTS Directory
id: 4d7a8c20-1e5b-4f93-a6d8-2b9c3e7f5a01
status: experimental
description: Detects creation or modification of ASPX/ASP files in the SharePoint TEMPLATE LAYOUTS directory by non-standard processes, matching webshell deployment tradecraft (e.g., spinstall0.aspx-style artifacts) observed in the actively exploited SharePoint campaign.
references:
- https://www.bleepingcomputer.com/news/security/cisa-microsoft-sharepoint-flaw-now-exploited-in-ransomware-attacks/
- https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/01/15
tags:
- attack.persistence
- attack.t1505.003
logsource:
category: file_event
product: windows
detection:
selection_path:
TargetFilename|contains:
- '\Web Server Extensions\15\TEMPLATE\LAYOUTS\'
- '\Web Server Extensions\16\TEMPLATE\LAYOUTS\'
selection_ext:
TargetFilename|endswith:
- '.aspx'
- '.asp'
- '.ashx'
- '.asmx'
condition: selection_path and selection_ext
falsepositives:
- Legitimate SharePoint solution deployments during maintenance windows; correlate with change tickets
level: critical
---
title: Shadow Copy Deletion Preceding Ransomware Encryption
id: 6f1c9b34-8d2e-4a67-c3f5-9e0b4d8a2c17
status: experimental
description: Detects deletion or resizing of Volume Shadow Copies, a near-universal precursor to ransomware encryption activity, as seen in encryption-based attacks leveraging the SharePoint intrusion vector.
references:
- https://www.bleepingcomputer.com/news/security/cisa-microsoft-sharepoint-flaw-now-exploited-in-ransomware-attacks/
- https://attack.mitre.org/techniques/T1490/
author: Security Arsenal
date: 2026/01/15
tags:
- attack.impact
- attack.t1490
logsource:
category: process_creation
product: windows
detection:
selection:
CommandLine|contains:
- 'vssadmin delete shadows'
- 'vssadmin resize shadowstorage'
- 'wmic shadowcopy delete'
- 'bcdedit'
- 'wbadmin delete catalog'
- 'wbadmin delete systemstatebackup'
condition: selection
falsepositives:
- Legitimate backup maintenance scripts; rare in production
level: high
KQL — Microsoft Sentinel / Defender Hunting
This query hunts the core post-exploitation behavior — w3wp.exe on SharePoint servers spawning shells and reconnaissance tooling — plus suspicious ASPX file drops in LAYOUTS paths. Run it across a 30-day lookback; do not limit to the last few days.
let Lookback = 30d;
let SharePointProcs = dynamic(["cmd.exe","powershell.exe","pwsh.exe","net.exe","net1.exe","whoami.exe","nltest.exe","ipconfig.exe","wmic.exe","vssadmin.exe","certutil.exe","bitsadmin.exe","mshta.exe","rundll32.exe","regsvr32.exe"]);
union
(DeviceProcessEvents
| where TimeGenerated >= Lookback
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ (SharePointProcs)
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, InitiatingProcessId, ReportId
| extend Hunt = "SharePoint w3wp child process"),
(DeviceFileEvents
| where TimeGenerated >= Lookback
| where FolderPath has_any (@"\Web Server Extensions\15\TEMPLATE\LAYOUTS\", @"\Web Server Extensions\16\TEMPLATE\LAYOUTS\")
| where FileName endswith ".aspx" or FileName endswith ".ashx" or FileName endswith ".asmx"
| project TimeGenerated, DeviceName, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256, ReportId
| extend Hunt = "ASPX write in LAYOUTS")
| order by TimeGenerated desc
A complementary network-side hunt for scanning and POST exploitation attempts against SharePoint endpoints (requires WAF/IIS/firewall logs ingested via CEF/Syslog or similar):
let Lookback = 14d;
CommonSecurityLog
| where TimeGenerated >= Lookback
| where RequestURL has_any ("/_layouts/", "/_vti_bin/", "/_api/")
| where RequestMethod =~ "POST"
| where SourceIP !startswith "10." and SourceIP !startswith "192.168." and SourceIP !startswith "172.16."
| summarize Hits = count(), DistinctURIs = dcount(RequestURL), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, DestinationHostName
| where Hits > 50 or DistinctURIs > 10
| order by Hits desc
Velociraptor VQL Hunt
Deploy this as a hunt across your SharePoint servers. It enumerates ASPX artifacts in LAYOUTS directories (with hashes for reputation checks) and enumerates child processes spawned under w3wp.exe.
-- SharePoint compromise hunt: webshell artifacts in LAYOUTS + w3wp child processes
LET webshells = SELECT FullPath, Size, Mtime, Btime, hash(path=FullPath).SHA256 AS SHA256
FROM glob(globs=[
'C:/Program Files/Common Files/Microsoft Shared/Web Server Extensions/15/TEMPLATE/LAYOUTS/*.aspx',
'C:/Program Files/Common Files/Microsoft Shared/Web Server Extensions/16/TEMPLATE/LAYOUTS/*.aspx',
'C:/Program Files/Common Files/Microsoft Shared/Web Server Extensions/15/TEMPLATE/LAYOUTS/**/*.ashx',
'C:/Program Files/Common Files/Microsoft Shared/Web Server Extensions/16/TEMPLATE/LAYOUTS/**/*.ashx'
])
WHERE Mtime > parse(time='2025-07-01T00:00:00Z')
ORDER BY Mtime DESC
LET children = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Ppid IN (SELECT Pid FROM pslist() WHERE Name =~ 'w3wp')
AND Name =~ 'cmd|powershell|pwsh|net|whoami|nltest|wmic|vssadmin|certutil|mshta'
SELECT * FROM webshells
UNION ALL
SELECT * FROM children
Note: the UNION approach above is illustrative — in production, run webshells and children as two separate artifacts so the notebooks render cleanly and results are triaged independently.
Verification & Hardening Script
Run this on every on-prem SharePoint server. It inventories suspicious ASPX files created since July 2025, checks for w3wp.exe child process lineage in recent event history, confirms whether the July 2025 (or later) SharePoint security update is installed, and flags whether machine keys have been rotated post-patch.
# SharePoint compromise verification - run elevated on each SharePoint server
$ErrorActionPreference = 'SilentlyContinue'
$since = Get-Date '2025-07-01'
Write-Host "=== [1] ASPX/ASHX files in LAYOUTS modified since July 2025 ===" -ForegroundColor Cyan
$layouts = @(
"$env:CommonProgramFiles\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS",
"$env:CommonProgramFiles\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS"
)
foreach ($path in $layouts) {
if (Test-Path $path) {
Get-ChildItem -Path $path -Recurse -Include *.aspx,*.ashx,*.asmx |
Where-Object { $_.LastWriteTime -gt $since } |
Select-Object FullName, LastWriteTime, Length,
@{N='SHA256';E={(Get-FileHash $_.FullName -Algorithm SHA256).Hash}} |
Format-List
}
}
Write-Host "=== [2] w3wp.exe spawning shells (Sysmon EID 1 / Security EID 4688) ===" -ForegroundColor Cyan
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddDays(-30)} |
Where-Object { $_.Message -match 'w3wp\.exe' -or ($_.Message -match 'w3wp\.exe' -and $_.Message -match 'cmd\.exe|powershell\.exe|net\.exe|whoami\.exe|vssadmin\.exe') } |
Select-Object TimeCreated, Message -First 25 | Format-List
Write-Host "=== [3] Installed SharePoint security updates ===" -ForegroundColor Cyan
Get-HotFix | Where-Object { $_.InstalledOn -gt $since } |
Sort-Object InstalledOn -Descending | Format-Table HotFixID, Description, InstalledOn -AutoSize
Write-Host "=== [4] SharePoint build version ===" -ForegroundColor Cyan
$spConfig = Get-Item "HKLM:\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\16.0\WSS"
Write-Host "SharePoint binaries present. Cross-reference build against the July 2025+ CU/security update baseline."
Write-Host "=== [5] Machine key rotation reminder ===" -ForegroundColor Yellow
Write-Host "If the server was EVER unpatched and internet-reachable after July 2025, the ASP.NET ValidationKey/DecryptionKey MUST be rotated via SharePoint Central Admin > Security > Machine Keys, then IISRESET. Patching alone does not evict an attacker holding stolen keys."
Write-Host "=== [6] Recent IIS logs: POSTs to suspicious endpoints ===" -ForegroundColor Cyan
$iisLogs = Get-ChildItem "C:\inetpub\logs\LogFiles" -Recurse -Filter "*.log" |
Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-14) } | Sort-Object LastWriteTime -Descending
foreach ($log in $iisLogs | Select-Object -First 5) {
Select-String -Path $log.FullName -Pattern 'POST.*(_layouts|_vti_bin|ToolPane)' |
Select-Object -First 20 | ForEach-Object { $_.Line }
}
Remediation
- Patch immediately. Apply Microsoft's July 2025 (or later cumulative) security update for your SharePoint version — Server Subscription Edition, 2019, or 2016. Pull the exact KB for your build from Microsoft's security update guide at https://msrc.microsoft.com/update-guide and the SharePoint team's emergency update guidance at https://techcommunity.microsoft.com/category/sharepoint. Verify the installed build number against the patched baseline — do not trust patch status reports alone.
- Rotate the ASP.NET machine keys. This is the step that separates remediated organizations from re-victimized ones. If the server was exposed and unpatched at any point since early July 2025, assume the ValidationKey and DecryptionKey are compromised. Rotate them (SharePoint Central Administration or via the SharePoint Management Shell), then run
IISRESETon all farm servers. Microsoft explicitly calls this out in its guidance; skipping it leaves a forged-viewstate backdoor in place. - Hunt before you trust. Run the KQL, VQL, and PowerShell above. Any ASPX artifact in LAYOUTS created after July 2025 that you cannot tie to a documented deployment is treated as a webshell until proven otherwise. Check for persistence (new local admins, suspicious services, run keys, scheduled tasks) and credential access.
- Isolate and rebuild if compromised. If you find webshells, stolen keys, or
w3wp.exechild process execution: isolate the server from the network, perform a full credential reset for the farm account and any service accounts that touched it, and strongly consider a clean rebuild rather than surgical cleanup. Ransomware crews demonstrate they will sit on access for weeks. - Remove internet exposure. SharePoint on-prem should not be directly internet-facing in 2026. Put it behind a VPN/ZTNA gateway or retire it to SharePoint Online. If exposure is a hard business requirement, front it with a WAF with virtual-patching rules and enforce strict egress filtering on the SharePoint servers (they have no legitimate need to initiate outbound internet connections).
- Comply with the CISA KEV deadline. The flaw is in the KEV catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog). Federal civilian agencies face a binding deadline; every other organization should adopt the same timeline. KEV listing plus confirmed ransomware usage is the highest-priority patching signal that exists.
- Harden for the ransomware phase. Enforce MFA and tiered administration on all paths from the SharePoint tier to domain controllers, enable tamper protection on your EDR, ensure VSS/backup deletion commands alert (Rule 3 above), and verify your backups are offline or immutable — because the encryption crews now using this vector will look for them first.
The window between "patched" and "safe" is exactly the width of your machine key rotation and threat hunt. Close it this week.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.