Web Shells. An Introduction and Detection Strategies with YARA Hands-On Labs.

11 min readOct 5, 2020

As a cybersecurity leader, your organization most likely runs a publicly facing web site. If an attacker manages to gain Initial Access to the associated web server by Exploiting a Publicly Facing Application or using a Valid Account to log into an administrative panel, the actor will likely deploy a Web Shell to maintain Persistence.

A Web shell is a Web script that is placed on an openly accessible Web server to allow an adversary to use the Web server as a gateway into a network. A Web shell may provide a set of functions to execute or a command-line interface on the system that hosts the Web server. [1]

With an actor having a working web shell, there is a risk of data exfiltration or other operational impacts. Additionally, if a web site is compromised, there are reputational risks given a public facing web site is highly visible to customers. Cybersecurity leaders and analysts should be familiar with the risks of web shells as well as detection strategies to mitigate these risks.

Web Shell Detection YARA Hands-On Lab

With any testing, having a dedicated lab environment that can be quickly created, easily managed, and destroyed once finished is critical to completing the learning objectives.

If you do not have a lab environment, DigitalOcean provides an environment that meets these objectives: Disclaimer! this is an affiliate link: https://m.do.co/c/5c28b1b39512

If you have a lab environment with two dedicated systems, skip ahead to Installing WordPress.

Create the Web Shell Project

Create a new project called webshell as a Class project / Education purposes.

DigitalOcean create new webshell project

When the webshell project is created, click on the Get Started with a Droplet.

From the Marketplace tab, choose the WordPress on 18.04 image. WordPress is a popular and open-source content management system. This instance will be used to stage a web site for the lab.

For this lab, the minimum plan for most virtual private server providers will be sufficient.

Select the datacenter region most applicable to your geo graphic location.

For the lab, select Password for remote access and enter a password. In a product deployment, additional remote access security controls would likely be implemented.

Enter webshell-webserver as the hostname and create the instance.

Click the Create button and add an additional droplet for the webshell project.

Choose an Ubuntu 20.04 LTS x64 image.

Repeat the steps above for the plan selection, datacenter region, and password authentication.

Enter webshell-rsync as the hostname and create the instance.

Verify that webshell is selected as the project.

Verify that both the webshell-rsync and webshell-webserver instances are created.

On macOS open the terminal app and ssh as root to the IP address. On Windows, utilities like putty can be leveraged to connect to the webshell-webserver IP address.

ssh root@$IP_ADDRESS

Web Server Setup

WordPress Install

Using the DigitalOcean One-Click WordPress Droplet, when first logging in via SSH, a configuration prompt is returned. In the lab, the webshell-webserver will be targeted in a simulated attack to upload a web shell. Running a WordPress instance will provide a more realistic target given the popularity of the content management system.

For the configuration, enter the following:

Domain/Subdomain name: IP address of the webshell-webserver
Your Email Address: An email you own
Username: webshelllab
Password: A unique password
Blog Title: Web Shell Lab
Is the information correct? Enter y
Would you like to use LetsEncrypt (certbot) to configure SSL(https) for your new site? Enter n

The WordPress installation will complete.

Open a web browser and type in the IP address of your webserver-webshell instance.

Access the WordPress administrative panel by adding /wp-login.php.

WordPress Plugin

WordPress Plugins are often utilized to provide additionally functionality to a web site.

WordPress Plugins are PHP scripts that extend the functionality of WordPress. They enhance the features of WordPress, or add entirely new features to your site. [2]

When an exploitable vulnerability is identified in a WordPress Plugin, attackers can compromise at a greater scale if mitigations are not in place. One recent example of this is with the File Manager plugin. A remote code execution vulnerability was identified that allowed attackers to upload files and implant a web shell. While the vulnerability was patched, the recent activity highlights the Initial Access an attacker can utilize to upload a web shell.

File Manager Install

For the lab, a vulnerable version of the File Manager plugin will not be installed. The plugin will only be used to demonstrate how an attacker can upload a web shell. To install the File Manager WordPress plugin, select Plugins from the side menu.

Enter File Manger in the search bar. Click Install Now.

Once installed, click Activate to enable the File Manager plugin.

Once activated, File Manager can now be accessed in the side menu.

This completes the WordPress and File Manager plugin setup for the lab.

Configure rsync

Rsync is a file copying tool that will be used to copy files from the WordPress directory on the webshell-webserver to the webshell-rsync instance. An organization may opt not to run certain niche endpoint cybersecurity tools, like YARA, on production systems to prevent operational availability impacts. A utility like rsync can be leveraged to minimize this risk, while still giving cybersecurity teams file visibility. This file visibility can allow cybersecurity teams to create custom detection signatures for software that may not be detected by commercial endpoint protection solutions.

Setup Passwordless Public Key Authentication

Public key authentication for SSH can be utilized for rsync to remotely copy files. For the lab, passwordless public key authentication will be used with rsync.

On the webshell-webserver instance, issue the following command to create a passwordless public and private key pair.

root@webshell-webserver:
ssh-keygen -f ~/.ssh/id_rsa -q -P ""

Once the key pairs have been created, the cat command can be used to view the public key. The entire output of this command will need to be copied to an authorized_keys file on the webshell-rsync instance. The public key will be unique and should be protected.

root@webshell-webserver:
cat ~/.ssh/id_rsa.pub

From the webshell-webserver instance, SSH to the webshell-rsync instance. Enter yes to accept the key fingerprint and enter the password for root on the webshell-rsync instance.

root@webshell-webserver:
ssh root@$WEBSHELL-RSYNC_IP-ADDRESS

Once connected to the webshell-rsync instance, edit the authorized_keys file using nano.

root@webshell-rsync:
nano ~/.ssh/authorized_keys

Paste in the id_rsa.pub contents and save the authorized_keys file. Issue the exit command to return to the webshell-webserver instance.

root@webshell-rsync:
exit

From the webshell-webserver instance, SSH to the webshell-rsync instance again.

root@webshell-webserver:
ssh root@$WEBSHELL-RSYNC_IP-ADDRESS

With the authorized_keys setup, you will not be prompted for a password when connecting to the webshell-rsync instance.

Setup rsync

With passwordless public key authentication configured, rsync can now be setup.

SSH into the webshell-rsync server and create a directory where all copied files will reside. For the lab, a securityops directory will be created in a root directory.

root@webshell-rsync:
cd /
mkdir securityops

Rsync can now be run on webshell-wordpress to copy the WordPress directory to the webshell-rsync instance. In the lab, WordPress was installed to /var/www/html. This entire directory will be copied via rsync to the webshell-rsync instance. To copy the local WordPress directory on webshell-webserver to the remote webshell-rsync instance in the securityops folder, the following command can be used.

root@webshell-webserver: 
rsync -avz -e "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" /var/www/html root@$WEBSHELL-RSYNC_IP-ADDRESS:/securityops/

If setup correctly, the command will complete successfully. To verify, SSH into the webserver-rsync instance, change to the securityops directory, and list all files via the ls command. All WordPress files should now be copied to this instance.

Automating rsync

The rsync process can be automated via the crontab command.

On the webshell-wordpress instance, use the nano command to create a file named wordpress_rsync.sh.

root@webshell-webserver:
cd /root
nano wordpress_rsync.sh

Paste in the rsync command issued in the steps above and save the file. Use the chmod command to give the user execution permission on the file.

root@webshell-webserver:
chmod u+x wordpress_rsync.sh

Enter the crontab command to create a new cron job. Select option 1 to use the nano editor.

root@webshell-webserver:
crontab -e

For the lab, the rsync command in the wordpress_rsync shell script, will be run every 15 minutes. In a production deployment, this timing may vary.

Add the following entry and save the file.

*/15 * * * * /root/wordpress_rsync.sh

Install YARA

For an overview of YARA and a lab on installing the tool, follow the steps in the post YARA. A Powerful Malware Analysis Tool. For this lab, YARA should be installed and configured on the webshell-rsync instance.

Weevely Web Shell

For the lab, weevely will be used as the web shell. Ideally, weevely would be setup on an additional instance, but for this lab, weevely can be installed and run on webshell-rsync.

Weevely is a web shell designed for post-exploitation purposes that can be extended over the network at runtime.
Upload weevely PHP agent to a target web server to get remote shell access to it. It has more than 30 modules to assist administrative tasks, maintain access, provide situational awareness, elevate privileges, and spread into the target network.

Install Weevely

Open a web browser and access the weevely GitHub page. Click the Code button and copy the HTTPS clone link.

Issue the git clone command to download the weevely repository.

root@webshell-rsync:
cd /root
git clone https://github.com/epinna/weevely3.git

The weevely install guide notes that several dependencies are required prior to an install.

root@webshell-rsync:
sudo apt-get install -y python3 python3-pip curl
cd weevely3/
sudo pip3 install -r requirements.txt --upgrade

The weevely web shell can be created using the following command.

root@webshell-rsync:
./weevely.py generate labpassword webshell.phpGenerated 'webshell.php' with password 'labpassword' of 751 byte size.

To view the weevely web shell code, run the cat command on the file. The output shows the code is heavily obfuscated. While not a definitive measure, if the file was uploaded to a service like VirusTotal, the output may provide some perspective on vendor coverage and the value of developing a YARA signature.

YARA Signature Creation

Looking at the source code of weevely as well as generating multiple web shells, shows that a function is obfuscating the PHP output. At a cursory glance, the “str_replace” function is not obfuscated and can likely be used to generate a YARA signature. In the weevely generated web shells, there is a variable declaration using a single uppercase or lowercase alpha character. A simple YARA rule can be crafted to match these conditions.

rule weevely {
 strings:
  $php = "<?php" // PHP file
  $obf = /\$[A-Za-z]{1}=str_replace/ // Variable with str_replace function
 condition:
  all of them
}

From the YARA lab, a rules directory should exist and a file called weevely.yara can be created and saved.

cd /
mkdir rules
cd rules
nano weevely.yara

The YARA signature in this scenario could be easily bypassed if the weevely authors changed the variable declaration to multiple characters, included numeric values, or obfuscated the “str_replace”. Changing a code base often does require a significant effort, but this risk does reinforce the need for multiple detection strategies for web shells. This will be discussed at the end of the post.

Web Server Exploitation

For this lab, the exploitation of the webshell-webserver instance will be emulated and no exploit code will be run. This scenario could reflect the Valid Accounts technique being utilized for initial access.

From the File Manager plugin menu, browse to the wp-content → plugins folder. Manually drag the webshell.php file to the location.

With the web shell uploaded, the rsync cron job will copy the file over on a maximum of a 15 minute interval. For the lab, check the associated directory on the webshell-rsync instance. The webshell.php file should be present.

YARA Signature Match

For the lab, we’ll manually run YARA to identify the web shell. In a production deployment, YARA would be setup to run on a cron job and would email or log output to a centralized file for a security information and event management (SIEM) integration on a match.

Run the following YARA command and identify the match. It’s important to note that the YARA rule did not match any of the default WordPress files, making it a higher fidelity rule.

root@webshell-rsync:
yara -msr /rules/weevely.yara /securityops/

Closing Remarks.

Cybersecurity analysts should be familiar with Web Shells and detection strategies to mitigate the risk of an actor having Persistence to the web server and ultimately being used to exfiltrate data or impact an organization’s operations. Given these risks, in subsequent posts additional web shell detection strategies will be covered while continuing to use the weevely web shell.

If you made it this far, thanks for reading! Any feedback is always appreciated.