Web Shell Response Playbook: Finding, Removing and Recovering From Web Shells

Deleting a web shell rarely ends the incident, because the shell was only the door, and whatever the attacker took through it, especially keys and service credentials, still works. This template gives [Organisation] a ready-to-adopt playbook for responding to web shells (ATT&CK T1505.003) on internet-facing and internal web servers: IIS, Apache, Nginx and Tomcat hosts, Microsoft Exchange and SharePoint, and appliances with web management interfaces. It is written for security operations, web and platform engineers, identity administrators and incident managers. NSA and the Australian Signals Directorate warn that removing only the shell, without investigating, lets the attacker return by other routes; this playbook is built around that point. Replace every [bracketed] placeholder and exercise it at least yearly.

How to use this template

• Adopt, then tailor: copy sections 1 to 8 into your incident response plan beside the Incident Response Plan Template, and add one appendix per web platform you run (paths, log locations, application pool identities).
• Treat a shell as an intrusion: scope the whole host and everything it can reach before you remove anything.
• Plan the secret rotation: web servers hold machine keys, connection strings, certificates and service account credentials. Section 5.3 lists them.
• Keep a known-good copy: detection and recovery both depend on comparing production against a verified clean build of each application.
• Review annually and after every incident or major platform change. Owner: [Head of Security Operations].

1. Scope and triggers

1.1 A web shell is a script or module placed on a web server that lets an attacker run commands through ordinary HTTP or HTTPS requests. This playbook covers script shells (ASPX, ASHX, PHP, JSP, CGI), malicious server modules such as IIS components (T1505.004) and Apache modules, and shells planted on appliances and content management platforms.

1.2 Common entry routes: exploitation of a public-facing application (T1190), such as the Exchange and SharePoint vulnerability chains of recent years; insecure file upload features; stolen administrator or deployment credentials (T1078); and compromised plugins or build pipelines.

1.3 Triggers:

• EDR alert for a web server process (w3wp.exe, httpd, nginx, java or tomcat) spawning cmd.exe, powershell.exe, sh or bash, or running reconnaissance commands such as whoami, net or dir. Microsoft describes this parent-child pattern as a strong sign of compromise.
• New or changed executable files (.aspx, .ashx, .php, .jsp, .war) in web-accessible directories, from file integrity monitoring or a known-good comparison.
• Web log anomalies: a URI requested by very few IP addresses or user agents, POST requests to static-looking pages, missing referrers, unusually large responses or regular off-hours access (NSA and ASD guidance).
• A vendor or CISA advisory for a vulnerability under active exploitation in a product you run, or an entry in the CISA Known Exploited Vulnerabilities catalogue.
• Unexpected listening ports or outbound connections from a web server.

2. Roles and contacts

2.1 Record 24/7 contacts for the hosting provider, the product vendor's support, the incident response retainer and the cyber insurer, with an offline copy.

3. Detection and triage

1. Confirm the shell: collect the file (hash, path, size, owner) or the module registration. Do not trust file timestamps: NSA and ASD note that attackers alter them. Compare the directory with the known-good build.
2. Find how it got there: match the file creation time to web logs (IIS logs under %SystemDrive%\inetpub\logs\LogFiles by default, Apache access and error logs) and to vulnerability advisories for the product.
3. Find what it was used for: list every request to the shell URI, the source IPs, and process trees spawned by the web server process. Look for PowerShell (T1059.001), downloads of further tools (T1105), credential dumping (T1003.001) and reads of configuration files.
4. Find other footholds: sweep all servers in the same farm or cluster for other new scripts and modules, new accounts, scheduled tasks and remote access tools. Check applicationHost.config and web.config for added modules and handlers on IIS, and loaded module lists on Apache.
5. Assess reach: using flow data and packet captures, determine whether the attacker pivoted from the server to internal systems, as NSA and ASD advise.

Decision point A: if the shell ran commands, accessed configuration or reached other hosts, raise severity to High or Critical and run the full playbook. If it was uploaded but never requested, and no exploitation is evident, a scoped Medium response may be justified; record the reasoning.

Evidence to preserve: a copy of the shell and any modules; memory from the web server (in-memory and module shells may leave no file); disk image or cloud snapshot; web server, WAF, load balancer and reverse proxy logs; EDR process telemetry; Windows Security, PowerShell Operational (4104) and Sysmon logs or Linux auditd logs; application and database logs. Follow the Evidence Handling and Chain of Custody Guide.

4. Containment

1. Block access to the shell at the WAF or reverse proxy by URI and by attacker source, while keeping logging on. See the Web Application Firewall Guide.
2. Restrict the server's network reach: block egress except what the application needs, and block connections from the server into internal segments.
3. Isolate the host with EDR or remove it from the load balancer pool if commands were run, after evidence capture. Where the application must stay up, fail over to a clean node.
4. Apply the vendor fix or mitigation for the entry vulnerability, or take the service offline. CISA advised that affected SharePoint servers which could not have the Antimalware Scan Interface (AMSI) enabled be taken offline until mitigations were available.
5. Disable accounts the attacker used or created, including deployment and service accounts.

Decision point B: remove the shell now versus observe briefly to learn more. Default to immediate blocking at the edge; observation needs the Incident Lead's approval, a fixed time limit and no evidence of data access.

Decision point C: clean in place versus rebuild. Rebuild whenever commands were run, a malicious module was loaded or the root cause is not fully understood.

5. Eradication

5.1 Rebuild from known-good: redeploy the server and the application from trusted images and source, patched to current. Do not copy web directories back from the compromised host.

5.2 Remove configuration persistence: on IIS, remove malicious entries from applicationHost.config and web.config before restarting; CISA's SharePoint guidance warns that otherwise malicious modules reload. On Apache and Nginx, check every configuration include and module directive. Remove added accounts, scheduled tasks and services.

5.3 Credential and NHI resets. Assume every secret readable by the web server process is exposed.

5.4 The ToolShell campaign showed why section 5.3 matters: attackers used a web shell to read SharePoint machine keys, which kept working after patching until they were rotated. See the ToolShell SharePoint Exploitation 2025 breach analysis.

6. Recovery

1. Restore application data from backups verified clean and taken before the earliest malicious file or request.
2. Bring the rebuilt server into the pool behind the WAF, with file integrity monitoring and EDR active, and confirm the web process cannot write to web-accessible directories.
3. Run functional tests, then remove temporary edge blocks in stages; keep blocks for known attacker infrastructure.
4. Monitor for [30] days: requests to the old shell paths, web server processes spawning shells, use of rotated credentials and forged session tokens.

7. Communication and notification

8. Post-incident review

8.1 Within [10] business days, run the review with the Post-Incident Review and Root Cause Analysis Template.

8.2 Ask: how long between the vendor patch and our patch; how long between shell placement and detection; did file integrity monitoring and EDR cover the server; could the web process write to its own code directories; which secrets were on the host and could they have been elsewhere; was every secret in 5.3 rotated.

8.3 Feed results into the Patch Management Guide process for internet-facing systems, and share indicators with CISA, the NCSC or your sector ISAC.

Implementation guidance

Detection methods compared (based on NSA and ASD guidance).

Rollout.

1. Inventory internet-facing web servers, their platforms, owners and the secrets each holds.
2. Enable file integrity monitoring on web roots and configuration files, and EDR rules for web server processes spawning shells, first in alert mode for [2] weeks to tune exclusions, then as high-priority alerts.
3. Remove write permission for web processes on code directories; allow uploads only to non-executable, scanned locations.
4. Place web servers in a DMZ with restricted egress and no direct route to internal segments.
5. Test with a tabletop based on a recent advisory and a drill using a harmless test file in the web root, timing detection and rotation of a test machine key. Document how to roll back every WAF and firewall rule.

Small vs large organisations. A small organisation hosting a few sites should prefer managed hosting with vendor patching, and keep its own list of secrets to rotate. A large organisation needs per-platform appendices, automated rebuild pipelines so rebuilding is faster than cleaning, and central secrets management so rotation is routine.

Metrics. Days from vendor patch to deployment on internet-facing servers; percentage of web servers with file integrity monitoring and EDR; mean time from shell placement to detection; percentage of host secrets rotated within [24] hours of confirmation; repeat compromise of the same server within 90 days.

Framework mapping.

For the attacks that commonly place web shells, see the Web Application Attacks Guide and the SharePoint and OneDrive Security Guide.

Standards and references

• NSA and ASD: Detect and Prevent Web Shell Malware
• CISA: Microsoft Releases Guidance on Exploitation of SharePoint Vulnerabilities
• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• MITRE ATT&CK: T1505.003 Web Shell
• MITRE ATT&CK: T1505.004 IIS Components
• Microsoft Security: Web shell attacks continue to rise
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Incident Response Plan Template · NIST SP 800-61 Incident Response Guide · Web Application Firewall Guide · Malware Outbreak Playbook