Quick answer: A web shell is a malicious script (usually .php, .asp, .jsp) that an attacker places on a compromised web server, allowing them to run commands remotely and access files. It acts as a persistent backdoor on the server. It is usually placed through a file upload flaw or another vulnerability. Detection is done with file integrity monitoring, unusual file and request patterns, and server log analysis. In post hack cleanup, fully cleaning web shells is critical, otherwise the server is compromised again.

How does a web shell get placed and what does it do?

A web shell is a script that can be uploaded to and executed on a web server. The attacker usually places it through a file upload flaw, an application vulnerability or a compromised admin panel. Once placed, the attacker reaches this script from a browser or with a request and runs commands on the server, reads files, steals data or goes deeper.

Its danger is persistence: a web shell is a backdoor that lets the attacker return to the server even if the initial flaw is closed. That is why after a breach it is not enough to close only the initial flaw, all web shells must be found and cleaned.

Web shell signs and detection

Sign Detection method
Unexpected new files File integrity monitoring, new .php detection
Unusual request patterns Heavy POST requests to a single file in logs
Obfuscated code Content scanning, eval/base64 patterns in code
Abnormal server processes Unexpected command execution from the web server
Outgoing connections Unexpected traffic out from the server

Post hack cleanup

When a web shell is found, the correct order of cleanup is critical. First an image of the system is taken (for forensic evidence), then the logs are reviewed to determine the initial entry point and all placed files. Finding a single web shell is not enough, because the attacker usually leaves multiple and obfuscated backdoors. Cleanup is not durable without closing the root cause (such as a file upload flaw). After cleanup, passwords and keys are rotated and the system is rescanned.

The KAOS and DSET approach

In post hack forensic examination DSET detects web shells and backdoors, determines the initial entry point from the logs and shows the root cause. Our KAOS security engine reports web shell patterns and suspicious files during source code and server scans. In our field experience the most common mistake is deleting a single visible web shell and skipping the root cause and other hidden backdoors, which leads to the server being compromised again. Our goal is to close the entry point and provide durable cleanup.

Related reading: enterprise WordPress security hack cleanup, file upload flaws, fileless malware and LOLBins, web server hardening Nginx Apache, Windows event log forensics, ransomware first 24 hours.

Frequently asked questions

How does a web shell get onto a server? Usually through a file upload flaw: the application does not sufficiently validate user uploads and the attacker can upload and run a .php file. There are other ways too: an application vulnerability, a compromised admin panel or weak credentials. Once placed, it provides the attacker with persistent remote access.

Is deleting one web shell enough? No. The attacker usually leaves multiple and obfuscated web shells, and the initial entry flaw is still open. Deleting only the visible one does not stop the attacker from returning. The right approach is to review the logs to find all backdoors, close the root cause flaw and rotate passwords.

How do I detect a web shell? File integrity monitoring (unexpected new files), server log analysis (heavy suspicious requests to a single file), content scanning (obfuscation patterns such as eval, base64) and abnormal server processes are used together. The most reliable result comes from combining these methods within a forensic examination.

Sources

For web shell detection and post hack forensic examination on a compromised server, you can talk to our team at Ankara Hacettepe Technopark. Contact DSET.