Web Shell Detected on Server [CHK-3029]
This ticket is opened when Microsoft Defender detects a web shell on a web-facing server in your environment. A web shell is a small script placed inside a website's own files that lets whoever knows its address run commands on the server. The affected server, the file involved and the actions Attic has already taken are written into the ticket by the MDR pipeline.
Rationale
A web shell is remote access that does not look like remote access. There is no new service listening, no unusual outbound connection, no logon event: the attacker simply requests a page over HTTPS, on port 443, through the same web server that serves your legitimate site. To a firewall it is ordinary web traffic.
Web shells are usually a consequence rather than a cause. Something let the attacker write a file into the web root first: an unpatched vulnerability in the application or server software, an exposed upload feature, or stolen administrative credentials. Finding the shell means that initial weakness has already been exploited, and it is still there unless you find it too.
They are also a persistence mechanism, which is what makes them urgent. A web shell survives password resets and reboots, and gives an attacker a reliable way back in long after the original vulnerability is patched. On a domain-joined server it is frequently the pivot point into the internal network. Removing the file alone is not sufficient.
Follow-up
Follow these steps to adequately address this detection:
- Isolate the server first. In Microsoft Defender, isolate the affected machine. A web shell is live access, and the priority is closing it before investigating. If isolation would take down a business-critical service, restrict it at the network or WAF level while you work.
- Determine what was done through it. This matters more than the file itself:
- Review the web server logs for requests to the shell's path. These show when it was first used, from which addresses, and how often. First use is normally close to the initial compromise.
- Review process creation on the server around and after that time. Commands run through a web shell appear as child processes of the web server process (
w3wp.exe,php-fpm,httpd). - Look for lateral movement and credential access from that server, and treat every credential stored or used on it as exposed.
- Find how it got there. Look for the upload: an unpatched application, an exposed upload endpoint, or a stolen administrator account. Removing the shell without closing the entry point means it returns.
- Search for others. Web shells are rarely deployed alone. Compare the web root against a known-good deployment or source control, and look for recently modified files across the whole tree rather than only where the detection fired.
- Rebuild rather than clean, where you can. Redeploying the application from source onto a clean server is the only way to be confident about what remains. If the server must be cleaned in place, treat that as a temporary measure.
- Escalate to IR. Contact Attic for incident response support. A confirmed web shell on an internet-facing server justifies a full investigation. This is one of the detections where the finding is almost never the whole story.