How do you detect web shell activity on Windows servers?

What to look for when IIS or a web app starts behaving like an execution host

web shell usually show up as a shift in behaviour, not a single obvious signature. On Windows servers, the important clue is that a web-facing process begins acting like an interactive launcher: spawning shells, script engines, or admin tools; touching files it should not; and reaching outward in ways normal web traffic does not require. That is why process ancestry, command lines, and file activity matter more than filename alone.

Watch for worker processes such as w3wp.exe, httpd-style service processes, or application pools launching cmd.exe, powershell.exe, cscript.exe, wscript.exe, mshta.exe, or rundll32.exe. Also flag script execution from web roots or upload directories, because a web shell often lives where the server can execute it directly after a successful upload or file write.

File telemetry should be read alongside process telemetry. A new .aspx, .ashx, .jsp, .php, or similarly executable script in a web directory may be legitimate, but a very short file, a recently modified file with encoded or obfuscated content, or a file that appears immediately after an upload event deserves review. For upload-driven footholds, the File Upload Security Guide is the natural companion because upload validation failures are one of the most common paths to web shell placement.

Why correlation matters more than any single alert

A web shell rarely stays isolated. Strong detection usually comes from correlating execution with recent uploads, unexpected outbound connections, privilege escalation attempts, and repeated use of built-in administration utilities. The goal is to separate routine web application behaviour from a short burst of post-exploitation activity that tries to blend into normal server noise.

Outbound connections are especially useful when they follow soon after suspicious script execution. A web shell may stage tools, pull additional payloads, or test reachability to command-and-control infrastructure. The same host may also begin enumerating local groups, checking privileges, or invoking native tools such as net.exe, whoami.exe, icacls.exe, reg.exe, or certutil.exe in sequences that are unusual for a web server role. When that pattern appears, treat it as a compromise hypothesis, not a curiosity.

Behavioural context also helps with false positives. Administrative scripts, deployment jobs, and health checks can create child processes too, but they usually do so in known maintenance windows, under known service accounts, and with stable command lines. Web shell activity is more often ad hoc, compressed into a short burst, and tied to a web request path or a recently changed file in the application tree.

For post-exploitation tradecraft, the Persistence Techniques Guide is useful because web shells are frequently one step in a broader foothold that later adds scheduled tasks, services, or other survival mechanisms.

How to confirm and investigate suspicious web shell activity

Start by establishing a time line: file upload or write event, first execution, child process chain, network connection, and any privilege changes. Then inspect the exact command line, parent process, and script engine invocation to see whether the activity can be explained by a deployment, a management job, or a known application function. If the execution path runs through a web directory and the command line is obfuscated, encoded, or truncated in a way that hides intent, assume the attacker is trying to reduce visibility.

Review web server logs for the originating request path, request method, user agent, and response codes around the same time. A successful shell upload often leaves a trail of a file write followed by an immediate GET or POST to the same location, or repeated probing of a newly dropped page. If you find evidence that the shell was used to run commands, check for follow-on access to sensitive directories, credential material, or configuration files.

Directory and environment visibility matters too. The Attack Surface Management Guide is relevant because untracked web roots, forgotten admin pages, and exposed application paths are common places where malicious uploads or shells hide long enough to be used.

When the web shell is used to modify code, add scheduled tasks, or replace binaries, expand the investigation beyond the web tier. Those actions suggest the shell was only the initial access point, not the full extent of compromise.

Risk and Threat Considerations

Web shells are dangerous because they convert a single web application weakness into repeatable remote command execution. Once the attacker can issue commands through the server, the session can be used for reconnaissance, credential theft, lateral movement, and persistence while looking like ordinary application traffic.

Failure mechanism: The attacker places or reaches a script that the web server can execute, then uses that script to launch local processes, read files, or call out to external infrastructure. Short obfuscated content, upload abuse, and execution from web roots are the usual mechanisms that make the shell hard to spot early.

Impact: The server can become an interactive foothold for broader compromise, including access to configuration secrets, lateral movement into adjacent systems, and repeated remote control even after the original web request is closed.

Practitioner Guidance

What to verify: Confirm whether suspicious child processes were spawned by a web worker and whether the file path, timestamp, and command line align with an approved deployment or maintenance action. If they do not, treat the event as an active intrusion lead rather than a benign anomaly.

Decision rule: If the executable or script lives under a web root or upload directory, prioritise containment, file preservation, and credential review before deep tuning of detections. If the same activity also touches admin utilities or outbound connections, widen the scope immediately to adjacent hosts and accounts.

Practitioner takeaway: The most reliable web shell detections come from linking execution, file change, and network behaviour into one timeline, because any single signal can be noisy while the sequence is rarely accidental.

Related resources from NHI Mgmt Group

• How do you detect China Chopper web shell activity on Windows servers?
• What are the signs that file monitoring on Windows servers is failing to detect suspicious activity?
• How do you detect DnsAdmins ServerLevelPluginDll abuse on Windows DNS servers?
• What are the risks of using static credentials in MCP servers?