Server Software Component

Server Software Component almost always follows Exploit Public-Facing Application (T1190). The attacker needs a way onto the server first, whether that is a ProxyShell chain against Exchange, a Log4Shell-style deserialization bug, or an unrestricted file-upload endpoint, and the web shell or module registration is the very next step, installed before the initial exploit's window closes. HAFNIUM's 2021 Exchange campaign is the reference case: after chaining CVE-2021-26855 and CVE-2021-27065, the group dropped .aspx web shells directly into the OWA authentication path within minutes of initial access, giving them a durable channel that no longer depended on the original vulnerability being exploitable.

Once installed, the web shell becomes the pivot point for everything that follows: credential dumping via LSASS access, lateral movement into the internal network, and, in ransomware intrusions, staging for encryption. Groups tracked using this technique span APT41, OilRig, Volt Typhoon, and Sandworm Team, and CISA's joint advisories on Exchange and SharePoint exploitation repeatedly cite web shells as the mechanism that let attackers maintain access for weeks after the initial vulnerability was patched. That gap, patched-but-still-compromised, is exactly why this technique gets its own detection layer instead of relying on vulnerability management alone.

Legitimate web applications do occasionally spawn child processes: a PHP application calling out to ImageMagick for thumbnail generation, a Java app server invoking a monitoring agent, or a CMS plugin that shells out to a conversion utility. Backup and inventory agents on Exchange or SharePoint servers can also write .aspx files during upgrades or cumulative-update installs, which will trip a naive file-path rule if it does not account for maintenance windows.

The fix is process-lineage and path allow-listing rather than disabling the rule. Build a short list of the specific interpreters and utilities your application legitimately invokes (per app pool, since IIS separates them cleanly) and exclude only those exact combinations, not the whole ParentImage. Pair file-creation-in-web-root alerts with a change-management or patch-window lookup so genuine Exchange Cumulative Update file writes get suppressed automatically, while anything landing outside a documented maintenance window still fires at full severity.

When a web server process spawns a shell or an unexpected file appears in a web-servable directory, first pull the file itself: is it a known web shell family (China Chopper, ASPXSpy, a generic single-line eval), and does its creation timestamp line up with any recent HTTP requests to that path in the web-access logs? Second, check what the child process actually did, whoami, net user, a download command, since even a first execution can tell you whether this is automated recon or a human on the keyboard. Third, confirm the vulnerability that got them there is still open; if the exploited CVE is unpatched, removing the shell alone just buys the attacker a re-drop.

Any confirmed web shell or unauthorized IIS module registration should be treated as an active intrusion, not cleaned up quietly. Isolate the host at the network layer while preserving the file system and process history for IR, since deleting the shell before capturing it destroys your best evidence of the initial access vector. Patch or WAF-block the exploited endpoint immediately so the attacker cannot simply re-exploit and redrop, rotate any credentials the compromised app pool or service account had access to, and hunt across the rest of the estate for the same file hash or IIS module signature, since these campaigns rarely stop at one server.