A China-linked threat group tracked as Warlock is actively breaching critical infrastructure and public-sector organizations by exploiting vulnerabilities in on-premises Microsoft SharePoint servers. Confirmed victims include a water utility, a telecommunications provider, a regional government body, and a university — a target selection that deliberately blends critical infrastructure disruption potential with espionage-friendly access. After gaining initial access through internet-facing SharePoint instances, the group moves through victim networks and ultimately deploys its encryption-based payload, a ransomware strain that has been observed damaging operations at each victim organization.
This campaign matters for two reasons. First, it confirms what defenders suspected the moment mass SharePoint exploitation began: the initial-access wave was not just espionage — access was being handed off, or directly used, for ransomware deployment. Second, the victimology (water, telecom, government, higher-ed) tells you exactly who is in the blast radius. If you operate an on-prem SharePoint farm — especially one reachable from the internet — you should treat this as an active intrusion scenario, not a patching exercise. Assume breach, hunt first, patch second.
Technical Analysis
What We Know About the Campaign
Per the reported incidents, the Warlock group's intrusion chain follows a now-familiar pattern against SharePoint:
- Initial access: Exploitation of vulnerabilities in internet-facing, on-premises SharePoint Server instances. The attackers send crafted requests to the SharePoint web application that allow unauthenticated remote code execution in the context of the IIS worker process (
w3wp.exe). - Webshell deployment: Post-exploitation, the actors drop ASPX webshells into SharePoint's web directories — historically the
LAYOUTSfolder (C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\) or the15hive on SharePoint 2016 — giving them persistent, file-based access even if the original exploited request path is later blocked. - Machine key theft: A hallmark of this exploitation wave is theft of SharePoint's ASP.NET MachineKey (ValidationKey/DecryptionKey). With these keys, attackers can forge valid
__VIEWSTATEpayloads and re-enter the server at will — meaning patching alone does not evict them. Key rotation is mandatory. - Discovery and lateral movement: The actors execute reconnaissance commands via the webshell (whoami, net, nltest, quser), stage tooling in writable directories such as
C:\ProgramDataandC:\Windows\Temp, and move laterally to domain controllers and file servers, frequently using valid credentials harvested from the SharePoint server itself. - Impact: Deployment of the Warlock encryptor across Windows infrastructure, with data theft (double extortion) consistent with the group's prior operations.
Affected Platforms
- Microsoft SharePoint Server 2016 (on-premises)
- Microsoft SharePoint Server 2019 (on-premises)
- Microsoft SharePoint Subscription Edition (on-premises)
SharePoint Online (Microsoft 365) is not affected by this exploitation pattern — but hybrid environments with on-prem SharePoint front-ends absolutely are.
Exploitation Status
Confirmed active exploitation in the wild against named critical-infrastructure victims. This is not theoretical. The SharePoint exploitation campaign this activity rides on has been subject to emergency CISA directives, and the pivot from exploitation to ransomware deployment materially raises the urgency: every unpatched, unrotated SharePoint server exposed to the internet should be considered potentially already compromised.
Detection & Response
The detections below focus on the highest-fidelity, lowest-noise behaviors in this chain: IIS worker processes spawning shells, webshell files in SharePoint directories, and the reconnaissance commands the actors run post-exploitation. These fire on attacker behavior, not administrator behavior — that distinction is what keeps them enabled in production.
Sigma Rules
---
title: IIS Worker Process Spawning Shell - SharePoint Exploitation
id: 8f3a2b71-4c9d-4e5a-b1f2-9d8c7a6e5f4a
status: experimental
description: Detects cmd.exe, powershell.exe, or other command interpreters spawned by w3wp.exe, consistent with SharePoint webshell and post-exploitation activity seen in Warlock intrusions. In healthy SharePoint farms w3wp.exe almost never spawns command shells.
references:
- https://www.bleepingcomputer.com/news/security/warlock-ransomware-breach-sharepoint-in-water-telecom-operator-attacks/
- https://attack.mitre.org/techniques/T1505/003/
- https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.initial_access
- attack.t1190
- attack.persistence
- attack.t1505.003
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'
- '\certutil.exe'
- '\bitsadmin.exe'
condition: selection_parent and selection_child
falsepositives:
- Rare custom SharePoint solutions or third-party add-ins that legitimately shell out from the app pool - validate against known application behavior before suppressing
level: critical
---
title: Webshell ASPX File Created in SharePoint LAYOUTS Directory
id: 2c7d9e14-6a3b-4f58-c2d1-8b4e5a7f9c3d
status: experimental
description: Detects creation or modification of ASPX files in SharePoint TEMPLATE\LAYOUTS or IIS web directories by non-IIS-setup processes, a hallmark of webshell deployment following SharePoint exploitation.
references:
- https://www.bleepingcomputer.com/news/security/warlock-ransomware-breach-sharepoint-in-water-telecom-operator-attacks/
- https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
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\'
- '\inetpub\wwwroot\'
selection_ext:
TargetFilename|endswith:
- '.aspx'
- '.ashx'
- '.asmx'
filter_setup:
Image|endswith:
- '\setup.exe'
- '\msiexec.exe'
- '\psconfig.exe'
- '\psconfigui.exe'
condition: selection_path and selection_ext and not filter_setup
falsepositives:
- SharePoint cumulative update installation and solution (WSP) deployments - correlate with patch windows
level: high
---
title: Reconnaissance Commands Executed Under IIS Context
id: 5b1e8f42-7d4c-4a69-e3b2-1f9d6c8a4e7b
status: experimental
description: Detects batch execution of discovery commands (whoami, net, nltest, quser, ipconfig) with an IIS worker process ancestry, matching hands-on-keyboard reconnaissance observed after SharePoint webshell deployment.
references:
- https://www.bleepingcomputer.com/news/security/warlock-ransomware-breach-sharepoint-in-water-telecom-operator-attacks/
- https://attack.mitre.org/techniques/T1033/
- https://attack.mitre.org/techniques/T1087/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.discovery
- attack.t1033
- attack.t1087.002
- attack.t1482
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\w3wp.exe'
- '\cmd.exe'
selection_cmd:
CommandLine|contains:
- 'whoami'
- 'nltest /dclist'
- 'nltest /domain_trusts'
- 'net group "Domain Admins"'
- 'net group "Enterprise Admins"'
- 'quser'
- 'net localgroup administrators'
condition: selection_parent and selection_cmd
falsepositives:
- Monitoring agents and health-check scripts running under app pool identity - tune per host after baseline
level: high
KQL — Microsoft Sentinel / Defender
This query hunts the core webshell behavior — w3wp.exe spawning command interpreters — and enriches with file drops into SharePoint LAYOUTS paths, giving analysts a single pane across the two most reliable artifacts of this intrusion set.
// Hunt: SharePoint w3wp.exe spawning shells + webshell file drops (Warlock intrusion pattern)
let Lookback = 14d;
let ShellProcs = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "cscript.exe", "wscript.exe", "mshta.exe", "rundll32.exe", "certutil.exe", "bitsadmin.exe", "whoami.exe", "nltest.exe", "net.exe"]);
let ProcEvents =
DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ (ShellProcs)
| project ProcTime=TimeGenerated, DeviceName, AccountName,
InitiatingProcessCommandLine, FileName, ProcessCommandLine,
ProcessId, InitiatingProcessId, ReportId;
let FileEvents =
DeviceFileEvents
| where TimeGenerated > ago(Lookback)
| where FolderPath has_any ("Web Server Extensions\\15\\TEMPLATE\\LAYOUTS",
"Web Server Extensions\\16\\TEMPLATE\\LAYOUTS",
"inetpub\\wwwroot")
| where FileName endswith ".aspx" or FileName endswith ".ashx"
| where not(InitiatingProcessFileName in~ ("msiexec.exe", "psconfig.exe", "psconfigui.exe", "setup.exe"))
| project FileTime=TimeGenerated, DeviceName, FolderPath, FileName,
InitiatingProcessFileName, SHA256, FileReportId=ReportId;
ProcEvents
| union FileEvents
| sort by DeviceName, ProcTime asc
If you ingest IIS logs (via Azure Monitor Agent / W3CIISLog), add this companion query to catch the exploitation requests themselves — attackers probing SharePoint application pages that legitimate users almost never touch directly:
// Hunt: suspicious POSTs to SharePoint application pages (requires W3CIISLog ingestion)
W3CIISLog
| where TimeGenerated > ago(14d)
| where csMethod == "POST"
| where csUriStem has_any ("/_layouts/15/ToolPane.aspx", "/_layouts/16/ToolPane.aspx", "/_controltemplates/")
or csUriQuery has "__VIEWSTATE"
| summarize RequestCount = count(), DistinctIPs = dcount(cIP), IPs = make_set(cIP, 10)
by csUriStem, csUserAgent, bin(TimeGenerated, 1h)
| where RequestCount > 0
| sort by TimeGenerated desc
Velociraptor VQL
Use this artifact for rapid triage of a SharePoint server you suspect is compromised — it inventories ASPX files in the SharePoint hives sorted by recent modification, which surfaces freshly dropped webshells immediately, then cross-references child processes of the IIS worker.
-- SharePoint webshell triage: recent ASPX in LAYOUTS + w3wp child processes
LET aspx_hunt =
SELECT FullPath, Size, Mtime, Btime,
hash(path=FullPath).SHA256 AS SHA256
FROM glob(globs=[
'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/*.aspx',
'C:/Program Files/Common Files/microsoft shared/Web Server Extensions/16/TEMPLATE/LAYOUTS/*.ashx'
])
WHERE Mtime > now() - 30*24*3600
ORDER BY Mtime DESC
LET shell_children =
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Ppid IN (SELECT Pid FROM pslist() WHERE Name =~ 'w3wp')
AND Name =~ '(?i)(cmd|powershell|pwsh|cscript|wscript|mshta|rundll32|certutil|net|whoami|nltest)'
SELECT * FROM aspx_hunt
UNION ALL
SELECT FullPath=NULL, Size=NULL, Mtime=NULL, Btime=NULL,
SHA256=format(format='PROC: %v %v pid=%v cmd=%v', args=[Name, Username, Pid, CommandLine])
FROM shell_children
Remediation and Verification Script
Run this on each SharePoint front-end. It inventories recently modified ASPX files in the web roots (webshell triage), flags suspicious IIS child processes from recent logs, confirms installed SharePoint build, and verifies MachineKey rotation status so you can close the persistence loop. Review output before taking destructive action.
# Warlock / SharePoint exploitation - triage and hardening verification
# Run elevated on each SharePoint web front-end
Write-Host "=== 1. Recently modified script files in SharePoint web dirs (last 30 days) ===" -ForegroundColor Cyan
$dirs = @(
"$env:CommonProgramFiles\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS",
"$env:CommonProgramFiles\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS"
)
foreach ($d in $dirs) {
if (Test-Path $d) {
Get-ChildItem -Path $d -Include *.aspx,*.ashx,*.asmx -Recurse -ErrorAction SilentlyContinue |
Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) } |
Sort-Object LastWriteTime -Descending |
Select-Object FullName, LastWriteTime, Length |
Format-Table -AutoSize
}
}
Write-Host "=== 2. Suspicious child processes of w3wp.exe (current) ===" -ForegroundColor Cyan
$w3wpPids = (Get-CimInstance Win32_Process -Filter "Name='w3wp.exe'").ProcessId
Get-CimInstance Win32_Process |
Where-Object { $w3wpPids -contains $_.ParentProcessId -and
$_.Name -match 'cmd|powershell|pwsh|cscript|wscript|mshta|rundll32|certutil|net\.exe|whoami|nltest' } |
Select-Object ProcessId, ParentProcessId, Name, CommandLine, CreationDate |
Format-List
Write-Host "=== 3. Installed SharePoint build ===" -ForegroundColor Cyan
$spKey = 'HKLM:\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions'
Get-ChildItem $spKey -ErrorAction SilentlyContinue | ForEach-Object {
$ver = (Get-ItemProperty $_.PSPath -ErrorAction SilentlyContinue).Version
if ($ver) { Write-Host "$($_.PSChildName): $ver" }
}
# Compare against the latest security update baseline at:
# https://learn.microsoft.com/en-us/officeupdates/sharepoint-updates
Write-Host "=== 4. MachineKey rotation check ===" -ForegroundColor Cyan
# After patching, ASP.NET machine keys MUST be rotated to evict attackers who stole them.
# Microsoft provides Update-SpMachineKey / rotation guidance; verify last rotation date manually:
# Central Administration > Security > Manage machine keys (or via SP PowerShell)
Write-Host "ACTION REQUIRED: Confirm MachineKey rotation was performed AFTER patching." -ForegroundColor Yellow
Write-Host "Reference: https://support.microsoft.com (SharePoint security update guidance)" -ForegroundColor Yellow
Write-Host "=== 5. Internet exposure check ===" -ForegroundColor Cyan
$bindings = Get-WebBinding -ErrorAction SilentlyContinue | Select-Object protocol, bindingInformation
$bindings | Format-Table -AutoSize
Write-Host "REVIEW: If SharePoint sites are bound to public IPs, restrict to VPN/ZTNA or place behind WAF immediately." -ForegroundColor Yellow
Remediation
1. Patch every on-prem SharePoint server now. Apply the latest cumulative security updates from Microsoft for SharePoint 2016, 2019, and Subscription Edition. Pull the current update baseline from the official SharePoint Updates page and verify build numbers on every front-end and application server — a partially patched farm is an unpatched farm.
2. Rotate the ASP.NET MachineKeys — this is not optional. Attackers who exploited these servers before patching have likely stolen the ValidationKey and DecryptionKey and can forge authenticated payloads against a fully patched server. Rotate machine keys on every server in the farm, then restart IIS (iisreset /noforce). Treat this like a credential compromise: patch first, rotate keys second, in that order.
3. Hunt before you trust. Deploy the Sigma, KQL, and VQL content above. Look for ASPX files you cannot account for, w3wp.exe child processes, and outbound connections from SharePoint servers to unfamiliar infrastructure. If you find a webshell, you are in IR mode — isolate the host, preserve memory and IIS logs, and scope laterally before remediating.
4. Remove SharePoint from the public internet. There is no defensible business case for a directly internet-exposed on-prem SharePoint farm in 2026. Place it behind a VPN, ZTNA broker, or at minimum a WAF with virtual patching rules for SharePoint exploitation patterns. If external collaboration is required, migrate that workload to SharePoint Online.
5. Enable AMSI and Defender for Endpoint on SharePoint servers. Ensure AMSI integration is enabled in SharePoint (it is on by default in current builds and inspects requests before execution) and that AV/EDR is running with the recommended SharePoint exclusions — not broad exclusions that blind the sensor to the LAYOUTS directories.
6. Constrain egress from SharePoint servers. Web front-ends need to talk to Microsoft update endpoints and internal SQL/DCs — not arbitrary internet hosts. Egress filtering here breaks webshell C2 and ransomware staging.
7. Critical-infrastructure operators: review segmentation. The water utility victim underscores that IT-side SharePoint compromise can become an OT concern. Verify there is no routable path from SharePoint servers toward operational technology networks, and confirm backup infrastructure is isolated and immutable — Warlock's endgame is encryption, and recoverable offline backups are the difference between an incident and a catastrophe.
Related Resources
Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.