How do you detect web shells on Exchange Server?

Detect Exchange web shells by watching the places they land and the processes that should stay quiet. Sweep aspnet_client and the OWA and ECP auth folders for recent .aspx or .ashx files and compare them with a clean install of the same cumulative update. Alert when the Exchange w3wp.exe pool or UMWorkerProcess.exe spawns a shell or writes script files. Review management-log events for virtual directory changes with script-like URLs, and correlate IIS logs for POST requests to newly created files. Treat any hit as potential credential exposure for the Exchange service accounts.

Detecting Exchange Web Shells: OAB, ECP and aspnet_client Drops

Exchange has been a repeated target for web shell deployment, and the same handful of locations keep appearing in public incident reports: the aspnet_client directory, the front-end OWA and ECP auth folders, and the Offline Address Book virtual directory. Because Exchange has a well-defined file layout and a small set of processes that should ever run, deviation is easier to spot here than on a general-purpose web server.

Signals at a Glance

Signal	Where	ATT&CK
New .aspx or .ashx in aspnet_client, OWA/ECP auth folders or Exchange bin paths	Sysmon 11, EDR file events	T1505.003
w3wp.exe (MSExchange pools) spawning cmd.exe or powershell.exe	Sysmon 1, EDR	T1059.001
UMWorkerProcess.exe or umservice.exe spawning a shell or writing script files	Sysmon 1/11, EDR	T1059.003
Set-OabVirtualDirectory with a script-like ExternalUrl	MSExchange Management log, cmdlet logging	T1505.003
Mailbox export cmdlets run outside admin change windows	Exchange audit and management logs	T1114.002

Hunting the Known Drop Locations

On a healthy server, aspnet_client holds static framework files and very little else. A quick sweep for recent script files across the usual paths is one of the cheapest checks you can run. Replace the paths with your installation root.

# PowerShell - recent script files in typical Exchange web-shell locations
$roots = @(
  "C:\inetpub\wwwroot\aspnet_client",
  "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth",
  "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ecp\auth"
)
Get-ChildItem -Path $roots -Recurse -Include *.aspx,*.ashx,*.asmx -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-90) } |
  Select-Object FullName, Length, CreationTime, LastWriteTime
# Tune/validate: compare against a clean install of the same cumulative update.

Cmdlet logging also records changes to virtual directories. A script-like value in an Offline Address Book external URL is a well-documented way of writing a shell through Exchange itself. Hunt management-log events and process lineage together:

index=wineventlog (source="MSExchange Management" OR source="WinEventLog:MSExchange Management")
  ("Set-OabVirtualDirectory" OR "Set-ActiveSyncVirtualDirectory" OR "Set-OwaVirtualDirectory")
| rex field=_raw "ExternalUrl\s*[:=]\s*(?<ext_url>.+)"
| where like(ext_url, "%script%") OR like(ext_url, "%eval%") OR like(ext_url, "%Request%")
| table _time host user ext_url _raw
# Tune/validate: field names depend on your Windows event ingestion.

Worker Processes That Should Stay Quiet

Alert on the Exchange application pool worker (w3wp.exe with an MSExchange pool name in its command line) launching cmd.exe, powershell.exe or discovery binaries.
Treat UMWorkerProcess.exe and umservice.exe creating any file with a script extension, or spawning a shell, as high severity. Unified Messaging has no business writing web content.
Correlate IIS logs for the Exchange front end: POST requests to a recently created file, from an unfamiliar client, with a tiny response, are the typical access pattern for a shell.
Run the vendor’s own scanning and health-check scripts on a schedule, and keep the results; they show exactly which files and settings differ from a known-good state.
After any positive hit, assume the account running Exchange services was exposed and scope for credential theft and mailbox access (T1114.002).

Vetted sources

Use the SigmaHQ Exchange and w3wp.exe rules, the Elastic Exchange web shell detections, Splunk ESCU analytics for IIS and Exchange, the vendor’s published scanner and health-check scripts, and CISA advisories on Exchange hunting. Compare against a clean install of your own cumulative update before declaring a file malicious.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Hunting the Known Drop Locations

Worker Processes That Should Stay Quiet

Build Detections That Fire

Edge Device & Web Shell Detection

Detection Hub

IIS Web Shell Detection

Web Server Anomaly Detection