How do you detect web shells dropped on Microsoft Exchange servers?

What to look for in Exchange directories and IIS logs

Web shells on Microsoft Exchange usually show up first as a small change on disk, not as an obvious alert. The highest-signal check is for new or recently modified ASPX files in Exchange-related web directories, especially when the change does not line up with a planned patch window, a maintenance task, or a normal deployment. Treat a new script file in a web-accessible path as suspicious until you can explain why it is there.

File presence alone is not enough. A legitimate update can also write ASPX content, so the better test is whether the file content, timestamp, path, and hosting process all make sense together. Suspicious shells often sit where Exchange and IIS can execute them directly, and they may contain short command runners, encoded payloads, or script fragments that do not resemble the surrounding application code.

To improve fidelity, compare the file activity with IIS request history. A shell is more convincing when a new ASPX file is followed by execution attempts, unusual HTTP methods, odd URL patterns, or requests from unfamiliar source addresses. Correlating file integrity monitoring with web server logs helps separate benign admin activity from attacker staging.

Which behaviors show the shell is being used

Once a shell is planted, the attacker usually tries to use it quickly for command execution, credential theft, or lateral movement. Look for the Exchange server making outbound connections it normally would not make, especially to unusual IPs, uncommon ports, or hosts that do not fit the server’s role. That outbound traffic often appears alongside command output, process creation, or child activity triggered through the web shell.

Authentication anomalies matter as much as network anomalies. A web shell is often paired with abnormal sign-in patterns, repeated failures, unexpected use of administrative accounts, or requests that suggest the attacker is testing which privileges are available. If the shell is being used to move laterally, you may also see the server reaching out to internal systems in ways that do not match its standard operational profile.

When the shell is actively abused, the content on disk may change as well. Attackers sometimes rename the file, alter the script body, or drop additional tooling nearby to keep access stable. That means defenders should look not only for the first malicious file, but also for later modifications that suggest the attacker is maintaining persistence or adapting after detection.

How to confirm, contain, and investigate safely

Confirmation should combine host evidence, web logs, and network telemetry. A single indicator can be noisy, but a file change plus IIS execution plus suspicious outbound activity is difficult to dismiss. If the server is still exposed, preserve evidence before cleanup so you can understand whether the shell was only dropped or whether it was already used to harvest data or pivot deeper into the environment.

Containment should focus on stopping reuse of the access path, not just deleting the file. If the shell was used to authenticate, execute commands, or reach other systems, assume the attacker may have obtained credentials, session material, or other access artifacts that survive file removal. That is why compromise assessment should include adjacent accounts, recent logons, and any systems contacted from the Exchange host after the suspected drop.

For a structured response to exploitation and post-exploitation hunting, the Zero-Day and Exploited Vulnerabilities Guide is useful for the patch-gap and post-patch-hunting mindset, while Persistence Techniques Guide helps when the shell has already been used to establish follow-on access. If the shell arrived through a web-facing upload or other application weakness, the Web Application Attacks Guide and File Upload Security Guide provide the adjacent failure modes to investigate.

Risk and Threat Considerations

A dropped web shell is dangerous because it turns a web server into an interactive foothold. On Microsoft Exchange, that foothold can expose mailboxes, internal trust relationships, and management functions, then be reused for lateral movement or persistence if defenders only remove the file and stop there.

Failure mechanism: The attacker abuses web-executed script code on a server that already has broad network reach, then uses the shell to execute commands, stage tools, or pivot into adjacent systems before normal monitoring catches up.

Impact: The practical impact can extend beyond the Exchange host itself, including credential exposure, additional backdoors, internal reconnaissance, and deeper compromise if responders do not assess whether the shell was actively used.

Practitioner Guidance

What to verify: Confirm that the ASPX file is truly out of band by checking whether it appeared outside patching or deployment activity, whether IIS could execute it, and whether the file path is web reachable. If those three conditions align, treat the finding as active compromise evidence rather than a simple filesystem anomaly.

Common mistake: Teams often delete the shell and declare success without checking command execution, outbound connections, or adjacent account use. That leaves the real problem untouched if the attacker already used the shell to establish a second access path.

Practitioner takeaway: The detection decision should hinge on correlation, not a single file finding, because the most important question is whether the shell was merely dropped or whether it already became a live attack interface.

Related resources from NHI Mgmt Group

• How do you detect China Chopper web shell activity on Windows servers?
• What are the risks of using static credentials in MCP servers?
• How should security teams detect web shells in HTTP access logs before attackers gain persistent command access?
• Why do web shells create such a high risk for web servers and exposed applications?