Detecting Web Server Process and Behaviour Anomalies

A web server’s job is narrow, so exploitation of the server or its applications (T1190) tends to produce behaviour that no legitimate workload does: launching a command interpreter, writing an executable to disk, or connecting to an arbitrary address. If you build a baseline for each application and alert on departures, you detect exploitation by effect rather than by vulnerability, which is what you need for the flaw you have not heard about yet.

Signals at a Glance

Baselining Child Processes

The strongest generic detection is rarity. For each web server host and parent process, build a list of child process names over a few weeks of normal activity, then alert on new entries. The same query works as a hunt before it works as an alert:

// Defender (KQL) - first-seen child processes of web server processes
let baseline = DeviceProcessEvents
  | where Timestamp between (ago(30d) .. ago(1d))
  | where InitiatingProcessFileName in~ ("w3wp.exe", "httpd.exe", "nginx.exe", "tomcat9.exe", "java.exe", "php-cgi.exe")
  | summarize by DeviceName, InitiatingProcessFileName, FileName;
DeviceProcessEvents
| where Timestamp > ago(1d)
| where InitiatingProcessFileName in~ ("w3wp.exe", "httpd.exe", "nginx.exe", "tomcat9.exe", "java.exe", "php-cgi.exe")
| join kind=leftanti baseline on DeviceName, InitiatingProcessFileName, FileName
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
// Tune/validate: app deployments and patching legitimately add new children.

Add a high-severity override list of known abused binaries that should alert even when they appear in the baseline, because attackers sometimes cause an application to spawn them early enough to pollute it:

| tstats summariesonly=true count from datamodel=Endpoint.Processes
  where Processes.parent_process_name IN ("w3wp.exe","httpd","nginx","php-fpm","java","tomcat9.exe")
    AND Processes.process_name IN ("cmd.exe","powershell.exe","pwsh.exe","certutil.exe","bitsadmin.exe",
        "mshta.exe","rundll32.exe","regsvr32.exe","sh","bash","curl","wget","nc","whoami","id")
  by Processes.dest Processes.user Processes.parent_process_name Processes.process_name Processes.process
| `drop_dm_object_name(Processes)`
# Tune/validate: tune per application pool; add allow-list for verified helper scripts.

Add File and Network Context

• Pair each process alert with file events from the same host in the previous few minutes. A new script plus a new child is far stronger than either alone.
• Egress is the cheapest corroboration. Web tier servers should talk to a small, stable set of internal systems; add a rule for any other destination (see the DMZ outbound page).
• Alert on unusual parent-child chains involving the web account, for example a web process starting a scheduler or service creation tool (T1053).
• Keep a per-application baseline owner. When an application team ships a feature that launches a helper, the baseline update is a change-management step.
• Record the web server user’s privileges, and reduce them. A baseline helps detection, but least privilege limits damage when detection is late.