Detecting IIS Web Shells: w3wp.exe Children and New ASPX Files

IIS hosts a large share of the internet-facing Windows estate, which makes its worker process, w3wp.exe, a favourite foothold. Once an attacker lands a script in a web-served directory, every command they run is a child of the application pool. Normal IIS applications rarely launch command interpreters, so process lineage, file creation and request shape combine into a strong, low-noise detection set.

Signals at a Glance

Process Lineage from the Worker Process

The core detection is simple: w3wp.exe should not launch interpreters or discovery tools in most environments. Start with a broad rule, then add exclusions for the handful of applications you know shell out on purpose.

title: IIS Worker Process Spawning Shell or Discovery Tool
logsource:
  category: process_creation
  product: windows
detection:
  parent:
    ParentImage|endswith: '\w3wp.exe'
  child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\whoami.exe'
      - '\net.exe'
      - '\net1.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
  filter_known_apps:
    ParentCommandLine|contains: 'ReplaceWithYourKnownAppPool'  # tune/validate
  condition: parent and child and not filter_known_apps
level: high
# Tune/validate: record which app pools legitimately shell out before enabling.

Pair the process rule with a file-creation hunt. New script files in a web root that were not written by your deployment account are the second half of the story:

// Defender / Sentinel (KQL) - script files created in IIS content paths
DeviceFileEvents
| where ActionType == "FileCreated"
| where FolderPath has_any (@"\inetpub\wwwroot", @"\inetpub\", @"\aspnet_client")
| where FileName endswith_cs ".aspx" or FileName endswith_cs ".ashx"
      or FileName endswith_cs ".asmx" or FileName endswith_cs ".config"
| where InitiatingProcessAccountName !in~ ("deploy-svc")  // tune/validate: your CI account
| project Timestamp, DeviceName, FolderPath, FileName, SHA256,
          InitiatingProcessFileName, InitiatingProcessAccountName

IIS Log Patterns

IIS W3C logs rarely prove a web shell on their own, but they are the best way to scope one after the fact and to find shells that run inside the worker process without spawning children. Enable the cs-method, cs-uri-stem, cs(User-Agent) and c-ip fields, and ship them to your SIEM.

• Rank URIs by the ratio of POST to GET requests, and look at those with few unique client IPs and a first-seen date that matches a file-creation event.
• Hunt requests to script files that return HTTP 200 with a tiny, constant response size, or that never appear in your sitemap or application map.
• Watch for scripts requested with unusual parameters followed shortly by a w3wp.exe child process on the same host.
• Compare file hashes in the web root against a known-good deployment manifest; anything extra is a lead, and anything modified outside a change window is a stronger one.
• Remember in-memory shells: no file write and no child process. Look for .NET assemblies loaded from unusual paths into w3wp.exe (T1620) using your EDR’s module-load telemetry.