Threat intelligence firm Defused has confirmed that attackers are actively targeting a chain of two Microsoft SharePoint vulnerabilities that, when combined, allow unauthenticated remote code execution on unpatched on-premises servers. A public proof-of-concept exploit is in circulation, which means the barrier to entry for exploitation has collapsed — this is no longer a capability reserved for sophisticated actors. Any internet-facing SharePoint Server that has not been fully patched should be treated as potentially compromised, not merely vulnerable.
SharePoint sits at the center of document management, collaboration, and increasingly authentication-adjacent workflows in most enterprises. A successful compromise yields not just a webshell on a web server, but a foothold inside the network with access to sensitive document repositories, service accounts with broad privileges, and — critically — the machine keys that can be used to forge authentication tokens against the farm even after patching. If you run SharePoint on-premises, this is a drop-everything event.
Technical Analysis
What Is Being Exploited
The attack chains two flaws in Microsoft SharePoint Server (on-premises editions — SharePoint Online in Microsoft 365 is not affected):
-
An authentication bypass / improper access control flaw that allows an unauthenticated attacker to reach a protected administrative endpoint — specifically, attackers have been observed sending crafted POST requests to the ToolPane administrative page (
/_layouts/15/ToolPane.aspx) with a manipulated referrer header to bypass authentication checks. -
An insecure deserialization flaw in SharePoint's handling of untrusted data, which the attacker reaches through the first flaw. Deserializing attacker-controlled objects in the context of the SharePoint application pool (the IIS worker process,
w3wp.exe, typically running as a farm service account) results in arbitrary code execution on the server.
The chained attack is fully remote and requires no credentials and no user interaction. Once code execution is achieved, observed post-exploitation behavior follows a consistent pattern:
- Webshell deployment into SharePoint's LAYOUTS virtual directory (a commonly observed artifact is an ASPX payload dropped under the
_layouts/15/path, e.g.,spinstall0.aspx-style filenames mimicking legitimate SharePoint components). - Theft of the ASP.NET MachineKey (ValidationKey and DecryptionKey) from the server's configuration. This is the most dangerous second-order effect: with these keys, an attacker can forge valid
__VIEWSTATEpayloads and re-compromise the server via deserialization even after the original vulnerabilities are patched, unless the keys are rotated. - Reconnaissance, credential dumping, and lateral movement from the SharePoint host into the domain.
Affected Products
- Microsoft SharePoint Server 2016
- Microsoft SharePoint Server 2019
- Microsoft SharePoint Subscription Edition
SharePoint Online (Microsoft 365) is not impacted. End-of-life versions such as SharePoint 2013 will not receive fixes and represent an unacceptable risk if exposed.
Exploitation Status
- Public proof-of-concept exploit available — the PoC chain is circulating publicly, per the reporting.
- Confirmed active in-the-wild targeting — Defused's telemetry shows attackers actively scanning for and exploiting vulnerable servers.
- Historically, SharePoint RCE chains of this class have been rapidly added to the CISA Known Exploited Vulnerabilities catalog and adopted by both nation-state operators and ransomware affiliates. Assume mass scanning is already underway and that any server exposed before patching may already be compromised.
Detection & Response
Detection priority should be: (1) hunt for the post-exploitation artifacts that are stable across actors — child processes of the IIS worker process and ASPX file drops in the LAYOUTS directory; (2) review IIS logs for anomalous requests to administrative endpoints; (3) verify patch level and machine key rotation. Because the exploit leaves no application-level authentication artifacts, process and filesystem telemetry are your highest-fidelity signals.
---
title: SharePoint IIS Worker Process Spawning Command Shell or Scripting Engine
id: 3f9c1a72-5e84-4b21-9d6a-2c7f8e4a1b93
status: experimental
description: Detects the SharePoint/IIS worker process (w3wp.exe) spawning command shells, PowerShell, or other scripting engines — a hallmark of successful RCE exploitation against SharePoint Server. The SharePoint application pool process does not legitimately launch these interpreters in normal operations.
references:
- https://www.bleepingcomputer.com/news/security/hackers-target-microsoft-sharepoint-rce-chain-with-poc-exploit/
- https://attack.mitre.org/techniques/T1190/
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/02/10
tags:
- attack.initial_access
- attack.t1190
- 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'
- '\pwsh.exe'
- '\cscript.exe'
- '\wscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
- '\net.exe'
- '\net1.exe'
- '\whoami.exe'
- '\nltest.exe'
- '\ipconfig.exe'
condition: selection_parent and selection_child
falsepositives:
- Rare third-party SharePoint solutions or custom timer jobs that shell out — investigate and whitelist by exact command line, never by parent alone
level: critical
---
title: ASPX Webshell Dropped in SharePoint LAYOUTS Directory
id: 8b2e4d61-7c93-4a58-bf21-9e3d6c5a7042
status: experimental
description: Detects creation or modification of ASPX files in the SharePoint LAYOUTS directory by the IIS worker process or other non-installer processes. Post-exploitation of the SharePoint RCE chain commonly drops a webshell (e.g., filenames mimicking legitimate components such as spinstall0.aspx) into this path for persistent unauthenticated access.
references:
- https://www.bleepingcomputer.com/news/security/hackers-target-microsoft-sharepoint-rce-chain-with-poc-exploit/
- https://attack.mitre.org/techniques/T1505.003/
author: Security Arsenal
date: 2026/02/10
tags:
- attack.persistence
- attack.t1505.003
logsource:
category: file_event
product: windows
detection:
selection_path:
TargetFilename|contains:
- '\_layouts\15\'
- '\_layouts\16\'
selection_ext:
TargetFilename|endswith:
- '.aspx'
- '.ashx'
- '.asmx'
filter_installers:
Image|endswith:
- '\msiexec.exe'
- '\setup.exe'
- '\psconfig.exe'
- '\psconfigui.exe'
condition: selection_path and selection_ext and not filter_installers
falsepositives:
- Legitimate SharePoint cumulative update installation or solution deployment — correlate with approved change windows
level: high
// Hunt: SharePoint RCE post-exploitation — w3wp.exe spawning suspicious child processes
// Scope to your SharePoint farm servers; extend the lookback to cover your patch gap window.
let Lookback = 30d;
let SharePointServers = dynamic(["SPSERVER01", "SPSERVER02"]); // TODO: replace with your farm hostnames or use a watchlist
DeviceProcessEvents
| where TimeGenerated >= ago(Lookback)
| where DeviceName has_any (SharePointServers)
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "cscript.exe", "wscript.exe",
"mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe",
"net.exe", "net1.exe", "whoami.exe", "nltest.exe", "ipconfig.exe", "vssadmin.exe", "wevtutil.exe")
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine,
InitiatingProcessCommandLine, SHA256, ReportId
| order by TimeGenerated asc;
// Hunt: Suspicious requests to SharePoint administrative endpoints (ingest IIS W3C logs via AMA/CEF)
// Look for unauthenticated POSTs to ToolPane.aspx and requests for unknown .aspx under _layouts.
CommonSecurityLog
| where TimeGenerated >= ago(Lookback)
| where RequestURL has_any ("/_layouts/15/ToolPane.aspx", "/_layouts/16/ToolPane.aspx")
or (RequestURL has "/_layouts/" and RequestURL endswith ".aspx" and RequestMethod == "POST")
| summarize Hits = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
by SourceIP, RequestURL, RequestMethod, DestinationHostName
| order by Hits desc;
-- Hunt SharePoint farm servers for webshell artifacts and RCE process chains
-- 1) Recently created/modified ASPX/ASHX files under the LAYOUTS directories
SELECT FullPath, Size, Mtime, Ctime, Btime
FROM glob(globs=[
'C:/Program Files/Common Files/microsoft shared/Web Server Extensions/*/TEMPLATE/LAYOUTS/*.aspx',
'C:/Program Files/Common Files/microsoft shared/Web Server Extensions/*/TEMPLATE/LAYOUTS/*.ashx',
'C:/inetpub/wwwroot/wss/VirtualDirectories/*/_layouts/*/*.aspx'
])
WHERE Mtime > now() - 2592000 -- last 30 days; widen to cover your exposure window
ORDER BY Mtime DESC
-- 2) IIS worker processes with suspicious command-line ancestry or loaded temp-path executables
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ 'w3wp'
OR CommandLine =~ 'spinstall0|_layouts.*aspx|ViewState|MachineKey'
Remediation
Act on all of the following — patching alone is not sufficient if exploitation may have already occurred:
-
Patch immediately. Apply the current Microsoft security updates for SharePoint Server 2016, SharePoint Server 2019, and SharePoint Subscription Edition via the Microsoft Security Update Guide (https://msrc.microsoft.com/update-guide). Verify the installed build against the latest released build on Microsoft's SharePoint Updates page (https://learn.microsoft.com/en-us/officeupdates/sharepoint-updates). Do not rely on Windows Update alone — SharePoint cumulative/security updates frequently require manual deployment and a PSCONFIG run.
-
If the server was internet-facing and unpatched at any point during the exposure window, assume compromise. Patching closes the door but does not evict an attacker who already dropped a webshell or stole machine keys. Initiate IR procedures: image the host, hunt per the detections above, and review IIS logs back to the earliest exposure date.
-
Rotate the ASP.NET machine keys on every farm server after patching. If the ValidationKey/DecryptionKey were exfiltrated, an attacker retains a deserialization path into the farm until keys are rotated and all services are restarted. This step is non-negotiable in any suspected-compromise scenario.
-
Run the Microsoft SharePoint AMSI integration (enabled by default in current builds — verify it) and ensure a supported antivirus with AMSI is scanning all web content in real time. AMSI integration specifically blunts webshell and in-memory payload execution in SharePoint.
-
Reduce exposure permanently: SharePoint should not be directly internet-facing without a reverse proxy/WAF with authentication pre-checks; restrict outbound internet access from SharePoint servers; enforce least privilege on farm service accounts; and enable attack surface reduction rules on the hosts.
Use the following PowerShell to verify patch posture, confirm AMSI, and sweep for likely webshell artifacts across a farm server:
# Run elevated on each SharePoint farm server
# 1) Report installed SharePoint build — compare against the latest build at
# https://learn.microsoft.com/en-us/officeupdates/sharepoint-updates
$sp = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\*\WSS" -ErrorAction SilentlyContinue
$sp | Select-Object PSChildName, Version
# 2) Check for pending security updates applicable to SharePoint
$Session = New-Object -ComObject Microsoft.Update.Session
$Searcher = $Session.CreateUpdateSearcher()
$Searcher.Search("IsInstalled=0").Updates |
Where-Object { $_.Title -match 'SharePoint' } |
Select-Object Title, IsDownloaded
# 3) Sweep LAYOUTS directories for recently modified script files (webshell triage)
$cutoff = (Get-Date).AddDays(-45)
$roots = @(
"C:\Program Files\Common Files\microsoft shared\Web Server Extensions",
"C:\inetpub\wwwroot\wss\VirtualDirectories"
)
foreach ($root in $roots) {
if (Test-Path $root) {
Get-ChildItem -Path $root -Recurse -Include *.aspx,*.ashx,*.asmx -ErrorAction SilentlyContinue |
Where-Object { $_.LastWriteTime -gt $cutoff -and $_.FullName -match '_layouts' } |
Select-Object FullName, LastWriteTime, Length
}
}
# 4) Confirm AMSI is functional on the host (antimalware provider registered)
Get-MpComputerStatus | Select-Object AMServiceEnabled, AMRunningMode, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
# 5) List w3wp child processes spawned in the last 7 days from the security event log (4688 with command line auditing enabled)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue |
Where-Object { $_.Message -match 'w3wp\.exe' -and $_.Message -match 'cmd\.exe|powershell\.exe|certutil\.exe|mshta\.exe' } |
Select-Object TimeCreated, Message -First 50
Finally, verify machine key rotation was performed post-patch (this is a manual, per-web-application operation in Central Administration or via PowerShell), and document exposure windows for your IR timeline. If any artifact from the hunts above is found, escalate to full incident response — do not simply delete the file and move on; webshell removal without key rotation and credential review leaves the farm compromised.
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.