A web shell can provide an attacker with continued command execution through a compromised web server. Even when the original vulnerability is no longer visible, creation or modification of server-side executable files can leave evidence that defenders can monitor.
The source defines two complementary detection approaches: Wazuh File Integrity Monitoring and Sysmon file-creation events.
Why Web-Shell File Monitoring Matters
The behavior covered by this hunt includes arbitrary file upload, path traversal, deserialization, command injection, and post-RCE persistence.
The detection focuses on file extensions and directories commonly associated with server-side execution:
ASPX files under SharePoint or IIS;
JSP files under Java application directories;
PHP files under web roots;
CGI files in CGI directories;
ASHX files under IIS.
A new file in one of these locations is not automatically malicious. Applications and deployments can legitimately create files. However, unexpected server-side scripts—especially in production environments—should be reviewed.
Wazuh File Integrity Monitoring Query
rule.groups:syscheck and syscheck.event:(added or modified) and syscheck.path:(*spinstall*.aspx or *\_layouts\*.aspx or *\inetpub\wwwroot\*.aspx or */webapps/*.jsp or */j2ee/cluster/apps/*.jsp or */htdocs/*.php or */www/*.php or */public_html/*.php or */cgi-bin/*.cgi)
This query monitors files that were added or modified in selected application paths.
Sysmon File-Creation Query
data.win.system.eventID:11 and data.win.eventdata.targetFilename:(*spinstall*.aspx or *\_layouts\*.aspx or *\inetpub\wwwroot\*.aspx or *\webapps\*.jsp or *\wwwroot\*.ashx)
Sysmon Event ID 11 provides another way to detect creation of suspicious files on Windows systems.
The source recorded zero matches during the previous 30 days.
How to Investigate a Match
A single file event should be enriched with context before a conclusion is made.
Important questions include:
Which process created or modified the file?
Which account performed the action?
Was there a deployment or patching activity at the same time?
Does the filename match the application baseline?
Was the file accessed through HTTP after creation?
Did the server subsequently launch
cmd.exe, PowerShell, or another shell?Does the file contain unexpected scripting or command-execution functionality?
File hash comparison against known-good application packages can also help determine whether the file belongs to an approved deployment.
Correlating with Process Activity
Web-shell detection becomes stronger when file events are correlated with process creation.
For example:
new ASPX file → HTTP access → w3wp.exe → powershell.exe
provides more confidence than any single event by itself.
The same applies on Java or PHP systems. A new JSP or PHP file followed by unexpected shell execution deserves significantly higher priority.
Tuning the Detection
Because application deployments can legitimately modify web directories, tuning should account for known release pipelines and approved maintenance windows.
Exceptions should be specific. Instead of excluding an entire web root, consider limiting an exception to a known deployment process, expected path, approved package, or service account.
The objective is to preserve visibility into unexpected file changes while reducing noise from controlled changes.
Operational Use
The source did not identify matches in the 30-day period, but the absence of events can still be useful. A low-volume rule can become a high-value alert when deployed in a stable production environment where server-side executable files rarely change.
For web servers, application platforms, and SharePoint environments, file integrity monitoring remains an important complement to process and network telemetry when hunting for exploitation and persistence.
