Warlock Ransomware Still Exploiting ToolShell SharePoint Flaws — Detection and Remediation Guide for Unpatched On-Prem Servers

More than a year after the ToolShell SharePoint zero-day chain dominated headlines in mid-2025, the Warlock ransomware operation is still walking through the same door — and organizations are still leaving it open. According to reporting tracked by Symantec and covered by Security Affairs, Warlock operators continue to exploit unpatched on-premises Microsoft SharePoint servers to breach water utilities, telecommunications providers, government agencies, and universities worldwide.

This is not a novel zero-day story. This is a patch-management failure story with ransomware consequences. If your organization runs on-premises SharePoint — particularly internet-facing instances — and you have not verified your patch state against the July 2025 ToolShell fixes, you are operating with a known, actively exploited pre-authentication remote code execution path into your network. Critical infrastructure operators in the water and telecom sectors should treat this as an imminent-risk item, not a backlog ticket.

Technical Analysis

What is ToolShell?

ToolShell is the name given to a chained exploitation of authentication bypass and remote code execution vulnerabilities in on-premises Microsoft SharePoint Server. The chain, first exploited as zero-days in mid-2025, allows an unauthenticated remote attacker to execute arbitrary code on the SharePoint server with the privileges of the IIS worker process (w3wp.exe). The attack requires no credentials and no user interaction — the only prerequisite is network reachability to the SharePoint web application.

Affected Products

• Microsoft SharePoint Server 2016 (on-premises)
• Microsoft SharePoint Server 2019 (on-premises)
• Microsoft SharePoint Server Subscription Edition
• SharePoint Online / Microsoft 365 is not affected by this on-prem attack surface

Attack Chain (Defender's View)

Based on the original ToolShell tradecraft and Warlock's continued use of it, the intrusion chain typically looks like this:

1. Initial access: Unauthenticated HTTP POST requests are sent to the SharePoint server's ToolPane endpoint (/_layouts/15/ToolPane.aspx) with a crafted Referer: /_layouts/SignOut.aspx header — a hallmark indicator of the ToolShell chain — bypassing authentication and triggering insecure deserialization.
2. Webshell deployment: The attacker drops an ASPX webshell (historically spinstall0.aspx, though names vary) into SharePoint's LAYOUTS directory, commonly C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\ or the 16 equivalent for newer versions.
3. Machine key theft: The webshell is used to extract the ASP.NET ValidationKey and DecryptionKey from the SharePoint configuration. This is the critical persistence-enabling step — stolen machine keys allow the attacker to forge valid __VIEWSTATE payloads and re-enter the server even after the underlying vulnerability is patched.
4. Post-exploitation: The w3wp.exe process spawns command interpreters (cmd.exe, powershell.exe) for reconnaissance, credential theft, and lateral movement, followed by staging of Warlock ransomware payloads for domain-wide encryption.

Exploitation Status

• Confirmed active exploitation in the wild, ongoing since mid-2025 and continuing into the present campaign per Symantec tracking.
• The ToolShell vulnerabilities were added to the CISA Known Exploited Vulnerabilities (KEV) catalog shortly after disclosure and remain there.
• Public proof-of-concept exploit code and Metasploit modules have been available since 2025, meaning the barrier to entry for this intrusion vector is effectively zero. Any internet-facing unpatched SharePoint server should be assumed to be under active scanning and likely already probed.

The fact that Warlock is still achieving breaches with a year-old chain tells us two things: a meaningful population of SharePoint servers remains unpatched, and a second population was patched but never had its machine keys rotated — leaving the stolen-key re-entry path open.

Detection & Response

Sigma Rules

The following rules target the highest-fidelity behaviors in this chain: IIS worker processes spawning command shells, webshells landing in the LAYOUTS directory, and child processes spawned by webshell execution. These are tuned to minimize noise — w3wp.exe should almost never spawn cmd.exe or powershell.exe in a healthy SharePoint farm.

---
title: SharePoint w3wp Spawning Command Shell - ToolShell Exploitation
id: 9c1f4a72-3b8e-4f2d-a6c1-7e5d9b2a4f01
status: experimental
description: Detects the IIS worker process (w3wp.exe) spawning cmd.exe, powershell.exe, or other command interpreters — a high-fidelity indicator of SharePoint webshell execution consistent with ToolShell exploitation by Warlock operators.
references:
  - https://attack.mitre.org/techniques/T1505/003/
  - https://securityaffairs.com/200304/malware/warlock-ransomware-still-exploits-year-old-sharepoint-flaws-to-hit-critical-infrastructure.html
author: Security Arsenal
date: 2026/01/14
tags:
  - attack.persistence
  - attack.t1505.003
  - attack.execution
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\w3wp.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\net.exe'
      - '\net1.exe'
      - '\whoami.exe'
      - '\nltest.exe'
      - '\rundll32.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare; some SharePoint administrative solutions invoke commands from IIS — baseline per farm and whitelist known-good command lines
level: high
---
title: ASPX File Created in SharePoint LAYOUTS Directory
id: 2d7e8b41-5c3a-4e9f-b1d8-6a4c7f0e3b92
status: experimental
description: Detects creation of ASPX files in SharePoint TEMPLATE\LAYOUTS directories. ToolShell intrusions historically dropped webshells such as spinstall0.aspx in this path. Legitimate deployments rarely write new ASPX files here outside of solution package installs.
references:
  - https://attack.mitre.org/techniques/T1505/003/
  - https://securityaffairs.com/200304/malware/warlock-ransomware-still-exploits-year-old-sharepoint-flaws-to-hit-critical-infrastructure.html
author: Security Arsenal
date: 2026/01/14
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: windows
detection:
  selection:
    TargetFilename|contains:
      - '\Web Server Extensions\15\TEMPLATE\LAYOUTS\'
      - '\Web Server Extensions\16\TEMPLATE\LAYOUTS\'
    TargetFilename|endswith: '.aspx'
  filter_known_files:
    TargetFilename|endswith:
      - '\settings.aspx'
      - '\ToolPane.aspx'
  condition: selection and not filter_known_files
falsepositives:
  - Legitimate SharePoint solution (WSP) deployments — correlate with change windows and deployment accounts
level: high
---
title: Suspicious HTTP POST to SharePoint ToolPane Endpoint
id: 4a9c1e63-8d2b-4f7a-9e5c-3b6d8a1f5c07
status: experimental
description: Detects HTTP POST requests to the SharePoint ToolPane.aspx endpoint with a SignOut.aspx referer — the request signature of the ToolShell authentication bypass. Deploy against IIS logs or web proxy data ingested into your SIEM.
references:
  - https://attack.mitre.org/techniques/T1190/
  - https://securityaffairs.com/200304/malware/warlock-ransomware-still-exploits-year-old-sharepoint-flaws-to-hit-critical-infrastructure.html
author: Security Arsenal
date: 2026/01/14
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
  product: iis
detection:
  selection:
    cs-method: 'POST'
    cs-uri-stem|contains: '/ToolPane.aspx'
    cs-referer|contains: 'SignOut.aspx'
  condition: selection
falsepositives:
  - Extremely rare; this request pattern has no legitimate business use case
level: critical

KQL — Microsoft Sentinel / Defender

This query hunts across both endpoint telemetry (Defender process events) and IIS/W3C logs ingested into Sentinel. Run the process hunt over at least the last 90 days given the longevity of this campaign, and the IIS query retroactively across all retained web logs.

// Part 1: Hunt for w3wp spawning command interpreters (ToolShell webshell behavior)
DeviceProcessEvents
| where TimeGenerated > ago(90d)
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "net.exe", "whoami.exe", "nltest.exe", "rundll32.exe", "certutil.exe", "bitsadmin.exe")
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessCommandLine
| order by TimeGenerated desc;

// Part 2: Hunt IIS/proxy logs for ToolShell request signature (CommonSecurityLog via CEF/Syslog ingestion)
CommonSecurityLog
| where TimeGenerated > ago(90d)
| where RequestMethod == "POST"
| where RequestURL contains "ToolPane.aspx"
| where tostring(AdditionalExtensions) contains "SignOut.aspx"
| project TimeGenerated, SourceIP, DestinationHostName, RequestURL, RequestMethod
| order by TimeGenerated desc;

// Part 3: Hunt for ASPX file drops in LAYOUTS directories
DeviceFileEvents
| where TimeGenerated > ago(90d)
| where FolderPath has_any ("Web Server Extensions\\15\\TEMPLATE\\LAYOUTS", "Web Server Extensions\\16\\TEMPLATE\\LAYOUTS")
| where FileName endswith ".aspx"
| project TimeGenerated, DeviceName, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessAccountName
| order by TimeGenerated desc

Velociraptor VQL

Use this artifact to sweep SharePoint servers for suspicious ASPX files in LAYOUTS directories and suspicious child processes of w3wp.exe — useful both for proactive hunting and for triage during an IR engagement where you need to quickly establish whether a server was compromised before patching.

-- Hunt for webshell artifacts and ToolShell post-exploitation on SharePoint servers
SELECT * FROM foreach(
  row={
    SELECT FullPath AS WebshellPath, Mtime AS WebshellMtime, Size AS WebshellSize
    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'
    ])
    WHERE Mtime > now() - 86400 * 400
  },
  query={
    SELECT WebshellPath, WebshellMtime, WebshellSize
    FROM scope()
  })

-- Additionally enumerate any live w3wp child processes indicative of webshell execution
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)cmd|powershell|pwsh|net|whoami|rundll32|certutil'
  AND Ppid IN (
    SELECT Pid FROM pslist() WHERE Name =~ '(?i)w3wp'
  )

Verification and Hardening Script

Run this PowerShell on each on-premises SharePoint server to inventory suspicious ASPX files in LAYOUTS, check recent w3wp child-process telemetry via WMI process auditing where available, and confirm whether ASP.NET machine keys are configured in a way consistent with post-ToolShell Microsoft guidance. Note: the authoritative patch check is against the SharePoint build number — compare your farm's build against the July 2025 (and all subsequent) security updates via Get-SPProduct -Local and the Central Administration "Check product and patch installation status" page.

# Warlock / ToolShell SharePoint Triage & Hardening Verification Script
# Run elevated on each on-prem SharePoint server. READ-ONLY checks plus key-rotation reminder.

# 1. Inventory recently created/modified ASPX files in LAYOUTS directories
$layoutsPaths = @(
    "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS",
    "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS"
)
foreach ($path in $layoutsPaths) {
    if (Test-Path $path) {
        Write-Host "=== Scanning $path for ASPX files modified in the last 400 days ===" -ForegroundColor Cyan
        Get-ChildItem -Path $path -Filter *.aspx |
            Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-400) } |
            Select-Object FullName, LastWriteTime, Length |
            Format-Table -AutoSize
    }
}

# 2. Check current SharePoint build (verify against July 2025+ security update baselines)
Write-Host "=== SharePoint Patch/Build Status ===" -ForegroundColor Cyan
try {
    Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction Stop
    Get-SPProduct -Local
    (Get-SPFarm).BuildVersion
} catch {
    Write-Warning "SharePoint snap-in unavailable. Verify build manually via Central Administration."
}

# 3. Search IIS logs (last 30 days) for ToolShell request signature: POST ToolPane.aspx with SignOut referer
$iisLogRoot = "C:\inetpub\logs\LogFiles"
if (Test-Path $iisLogRoot) {
    Write-Host "=== Scanning IIS logs for ToolShell request pattern ===" -ForegroundColor Cyan
    Get-ChildItem $iisLogRoot -Recurse -Filter *.log |
        Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) } |
        Select-String -Pattern "POST.*ToolPane\.aspx.*SignOut" |
        Select-Object -First 50 Path, LineNumber, Line
}

# 4. CRITICAL REMINDER: Patching alone does NOT evict attackers who stole ASP.NET machine keys.
Write-Host "=== ACTION REQUIRED ===" -ForegroundColor Red
Write-Host "If this server was EVER unpatched and internet-facing since July 2025, rotate the ASP.NET ViewState/machine keys after patching:"
Write-Host "  - In Central Admin or via PowerShell, generate new ValidationKey and DecryptionKey for every web application."
Write-Host "  - Force re-authentication of all sessions after rotation."
Write-Host "  - Investigate for webshells BEFORE rotation, or you will lock in attacker persistence."

Remediation

If you take nothing else from this post: patching is necessary but not sufficient. Organizations that patched in mid-2025 but skipped machine-key rotation are the ones Warlock is re-entering today.

1. Verify patch state immediately. Confirm every on-prem SharePoint server (2016, 2019, Subscription Edition) has the July 2025 security updates that remediated the ToolShell chain applied, plus all subsequent cumulative and security updates. Check the farm build via Central Administration's patch status page — do not trust WSUS/SCCM "compliant" flags without verifying the actual build on the server.
2. Rotate ASP.NET machine keys. For any server that was internet-facing and unpatched at any point since mid-2025, generate new ValidationKey and DecryptionKey values for every SharePoint web application. Stolen keys allow forged __VIEWSTATE payloads that bypass the patched vulnerability entirely. This step is mandatory, not optional.
3. Assume breach and hunt. Before rotating keys, sweep for webshells using the detections above. Examine LAYOUTS directories, review IIS logs for the ToolPane/SignOut pattern, and look for w3wp child processes. If you find evidence of compromise, move to IR mode — do not simply clean and patch. Ransomware operators sit on access for weeks; the webshell is rarely the whole story. Check for lateral movement, credential theft, and staged payloads.
4. Remove internet exposure. SharePoint should not be directly internet-facing in 2026 without a compelling, documented business justification. Place it behind a VPN, ZTNA broker, or at minimum a properly configured WAF/reverse proxy with the ToolPane/SignOut signature blocked. Microsoft and CISA guidance from the original ToolShell disclosure also recommends enabling AMSI integration with SharePoint and ensuring Defender Antivirus (or equivalent with AMSI) is running on all SharePoint servers.
5. Meet CISA KEV obligations. The ToolShell vulnerabilities remain in the CISA KEV catalog. Federal civilian agencies are bound by BOD 22-01 remediation timelines; everyone else should treat KEV entries as patch-now directives. If you are past the KEV due date and unpatched, escalate this to your CISO as a material risk today.
6. Segment and prepare for the ransomware phase. Warlock's endgame is domain-wide encryption. Verify SharePoint servers cannot reach domain controllers or file shares beyond what the farm requires, confirm your backups are offline/immutable and tested, and validate that your EDR is actually deployed and in block mode on every SharePoint server — not in audit mode.
7. Critical infrastructure operators: water and telecom organizations are named targets in this campaign. If you operate in these sectors and run on-prem SharePoint, treat this as an active-threat incident scenario, not a vulnerability-management backlog item.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub