Web shell · Lablypedia

Web shells can be coded in any programming language supported by a server, with PHP being the most prevalent due to its widespread use in web applications. Other languages, such as Active Server Pages, ASP.NET, Python, Perl, Ruby, and Unix shell scripts, are also employed.

Attackers identify vulnerabilities often in web server application using network monitoring tools, which can be exploited to deploy a web shell.

Once installed, a web shell allows attackers to execute shell commands, perform privilege escalation, and manage files by uploading, deleting, downloading, or executing them on the server.

General usage

Web shells are favored in cyberattacks for their versatility and elusiveness. Common applications include:

Data theft
Infecting visitors through watering hole attacks
Website defacement by altering files with malicious intent
Launching DDoS attacks
Relaying commands to inaccessible network segments
Serving as a command and control hub, such as in botnet systems or to compromise external networks

Web shells enable hackers to extract data, corrupt systems, and deploy more damaging malware. The threat intensifies when compromised servers are used to infiltrate additional systems. They are also employed in cyber espionage targeting sectors like government, finance, and defense. A notable example is the "China Chopper" web shell.

4 more chapters are free with a Lably account.

Delivery of web shells

Web shells are deployed by exploiting vulnerabilities in web applications or weak server configurations, including:

SQL injection
Flaws in applications and services (e.g., web server software like NGINX or content management systems like WordPress)
File processing and upload vulnerabilities (mitigated by restricting file types)
Remote file inclusion (RFI) and local file inclusion (LFI) vulnerabilities
Remote code execution
Exposed administration interfaces

Attackers may also spoof the Content-Type header during file uploads to bypass weak file validation, enabling shell deployment.

Example

The following is a basic PHP web shell that executes a shell command and displays the output:

<span id="mwnA"></span><span class="o" id="mwnQ"><?=</span><span class="sb" id="mwng">`$_GET[x]`</span><span class="cp" id="mwnw">?></span>

With a filename of example.php, the command to display the /etc/passwd file could be:

https://example.com/example.php?x=cat%20%2Fetc%2Fpasswd

This executes the command cat /etc/passwd. Such risks can be mitigated by disabling PHP shell functions to prevent arbitrary command execution.

Prevention and mitigation

Preventing web shell installation requires addressing server vulnerabilities. Key measures include:

Regularly updating applications and the host server's operating system to patch known bugs
Implementing a demilitarized zone (DMZ) between web-facing servers and internal networks
Securing web server configurations
Closing unused ports and services
Validating user input to limit local and remote file inclusion vulnerabilities
Using a reverse proxy to restrict administrative URLs to legitimate sources
Conducting frequent vulnerability scans (though ineffective against zero-day attacks)
Deploying a firewall
Disabling directory browsing
Avoiding default passwords

Detection

Web shells are challenging to detect due to their modifiability, often evading antivirus software.

Indicators of a web shell include:

Unusually high web server activity from downloading/uploading
Files with abnormal timestamps (e.g., newer than last modification)
Unknown files on the server
Suspicious references (e.g., cmd.exe or eval)
Unusual connections in server logs

For instance, a PNG file with POST parameters or dubious logins between DMZ servers and internal subnets may signal a web shell.

Web shells may include disguised login forms, such as fake error pages.

Attackers can modify the .htaccess file (on Apache HTTP Server) to redirect search engine queries to malware or spam pages, often tailoring content based on user-agent detection. Identifying the shell may require altering the crawler's user-agent, after which it can be easily removed.

Analyzing server logs can pinpoint the web shell's location, as legitimate users typically have diverse user-agents and referers, while attacker access is more uniform.