Detect web shells on Linux servers by monitoring web root directories for new PHP, JSP, or other executable scripts, and by correlating them with unexpected child processes from the web server account. Check for unusual command execution, outbound network connections, and changes to files owned by the web service user. Review access logs for probing, uploads, and repeated command-like requests.
What makes web shells hard to spot on Linux servers?
Web shells usually blend in with normal web content, so detection depends on spotting behaviour that does not fit the application. The strongest signals are a new executable file in a web-facing directory, especially one created by the web service account, followed by command execution from the web server process. That combination is more meaningful than any single file name or extension.
On Linux, the most useful first pass is to compare what the web server should be doing with what it is actually spawning. If Apache, Nginx with a handler, PHP-FPM, or another web worker suddenly launches a shell, script interpreter, package manager, or network tool, treat that as suspicious and verify whether the activity lines up with maintenance or deployment.
File-system review matters because many shells are dropped into writable paths, then renamed to look ordinary. Watch for recent changes under document roots, upload directories, temporary directories, and application cache paths. A file owned by the web user but modified outside the normal deployment window is more interesting when it appears alongside unusual outbound traffic or a burst of command-like HTTP requests.
Which artefacts and behaviours should you correlate?
The most reliable detection is correlation. A lone PHP or JSP file may be legitimate, but the file becomes far more suspicious when it appears with process creation, odd request patterns, and egress from the server. Review web access logs for repeated probing, parameter tampering, long or encoded query strings, and requests that look like command execution attempts rather than normal browsing.
Process telemetry should be paired with network telemetry. Web shells often trigger reverse connections, DNS lookups, or HTTP callbacks that do not match the server’s usual role. If the web service account starts child processes that touch the network, write to unexpected locations, or persist beyond a single request, investigate whether the file is acting as an interactive command proxy rather than a static page.
Integrity checks also help. File monitoring, baseline comparisons, and alerting on changes to executable content in web paths can expose shells that are otherwise quiet. Where you have EDR or auditd coverage, look for command execution by the web server user, creation of new scripts, and changes to permissions or ownership that make a dropped file runnable. That is often the point where a web upload flaw turns into live remote execution.
How should you investigate and confirm a suspected shell?
Start by confirming whether the file is expected. Check deployment records, package manifests, configuration management history, and application release timing before assuming malicious activity. If the file is not part of a known change, inspect its content for obfuscation, encoded payloads, command dispatch logic, or references to system utilities, environment variables, or hard-coded callbacks.
Then validate scope. Look for other writable paths, sibling files with similar naming patterns, cron entries, init changes, startup hooks, or secondary implants placed after the first shell. A web shell is often only the entry point, so the practical question is whether the attacker used it for discovery, privilege escalation, or lateral movement after landing on the host.
For broader hunting and exposure review, use an attack surface inventory to identify web servers and admin-facing services that may have been overlooked, and File Upload Security Guide to understand the upload failures that often precede a web shell drop. For persistence patterns, Persistence Techniques Guide helps connect a suspicious web file to the follow-on actions that keep access alive.
Risk and Threat Considerations
Web shells are dangerous because they convert a web-facing code path into an interactive control channel. Once the shell is present, the attacker can issue commands through ordinary HTTP traffic, which means the compromise may look like routine web activity until the host begins spawning unexpected processes or reaching out to external infrastructure.
Failure mechanism: A writable web directory, upload flaw, or code injection path allows an attacker to place executable content on the server, then invoke it through the web process to gain remote command execution and persistence.
Impact: The server can be used for data theft, credential harvesting, internal reconnaissance, lateral movement, and repeat access even after the original vulnerable request is removed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-10 — Data Recovery | Web shell detection depends on recovery-ready logging and file restoration evidence. |
| CIS-3 — Data Protection | Monitoring web-root changes and uploaded executable content aligns to protection of exposed web assets. | |
| Recommendation — Retain immutable logs and restore clean web content before reintroducing the host. Restrict write access to web paths and block executable uploads. | ||
| MITRE ATT&CK | T1505.003 — Web Shell | The subject is direct detection of a web shell implant on a Linux server. |
| T1059 — Command and Scripting Interpreter | Web shells typically enable command execution through shell or script interpreters. | |
| T1105 — Ingress Tool Transfer | Web shells often stage additional tools or payloads after initial access. | |
| Recommendation — Hunt for web-shell placement, execution, and follow-on activity in web directories. Correlate web-server activity with spawned interpreters and command execution. Inspect the host for downloaded tools and staged payload retrieval. | ||
Practitioner Guidance
What to verify: Confirm whether every executable file under the web root is owned, deployed, and change-controlled as expected. If a new script appears without a matching release record, assume it is suspicious until proven otherwise.
Common mistake: Teams often alert on the file itself but miss the child process tree. The process chain, web logs, and outbound connections usually tell you more than the filename or extension.
Decision rule: If a file in a web-facing path is executed through the web server account and produces shell-like behaviour, treat it as a potential compromise and move quickly to containment, host triage, and credential review for any related application or deployment accounts.
Practitioner takeaway: The best signal is not “a suspicious script,” it is “a suspicious script plus web-server-driven execution and unexpected network or process activity.” Correlate those three layers and you will find most web shells faster.
Related resources from NHI Mgmt Group
- How do you detect China Chopper web shell activity on Windows servers?
- How do you detect web shell activity on Windows servers?
- Why do Linux backdoors that rely on web shells and stealthy C2 routines create long term espionage risk?
- How should security teams detect web shells in HTTP access logs before attackers gain persistent command access?