Now that we’ve reviewed OS Command injection concepts like how they work, the impact they can have, and techniques that can be used to exploit vulnerable targets, let’s put all of this into practice. In this post, we will be creating and uploading backdoor shells on target hosts with Weevely and Commix.
The main point of using backdoor shells is to persist access for as long as possible. We do this in the post exploitation phase, which focuses on identifying the value of our target as well as extending and elevating our access.
The term “backdoor” is used because we are figuratively creating a “back door” on the server running the vulnerable application, so that we can exploit that backdoor any time that we want. This can be a great way to show how far you can exploit a vulnerability, and how critical that vulnerability is, when you are performing pentests for your client or employer.
There are multiple ways of generating and uploading backdoors after you’ve found an OS Command injection vulnerability (or even other types of vulnerabilities), but in this post, we will be using two tools: Weevely and Commix.
What is Weevely?
Weevely is a weaponized shell, meaning that it is designed to be used once a system has been compromised. It’s a lightweight, simple approach, that we can use to generate our payload and then exploit that payload, once it’s been planted on our target host.
It is so lightweight, in fact, that Weevely only comes with 3 core options (although you can also use modules):
- Generate a backdoor agent
- Load a session file
- Establish a connection with a backdoor agent
First, we’ll use it to generate the backdoor agent. Then, we’ll upload the agent to our target host. Finally, we’ll establish a connection to that agent with Weevely.
Once we’ve established a connection, we can use shell access to look for valuable information (credentials, files, other vulnerabilities, network information, system information, etc). We can also attempt to elevate our permissions in order to extend an even greater foothold.
Once we have more information, and once we’ve been able to escalate our privileges (if that’s even needed – some servers may be badly configured making it so that you already have root access), we can attempt to move laterally – meaning through the target’s systems, networks, and environments.
These are more advanced topics that we won’t cover in this post, but they are worth mentioning since the actions in this post can help us get to that point.
What is Commix?
Commix (short for [comm]and [i[njection e[x]ploiter) is an autmated tool that can be used by web developers, pentetration testers, or even security researchers in order to test web-based applications. The goal of the tool is to help find bugs, errors, or vulnerabilities related to command injection attacks.
In this post, we’re assuming that you already found command injection vulnerabilities that you are now looking to exploit. So, the reason we still mention Commix is because we will be using it to upload our payload to the target host once it’s been generated by Weevely.
We have to find a way to upload the payload onto the server hosting the application, otherwise we won’t be able to create that backdoor. Weevely itself does not do this, so we partner it up with Commix.
Start your vulnerable environment
Now that we know which tools we are going to use and what their purpose is, let’s start up our vulnerable environment that we’re going to exploit safely and legally.
For this, I typically like to use Docker containers since they are easy to spin up and take down, and we can run them in an isolated virtual machine running our operating system of choice.
Once installed, we’ll start Docker and pull in the Commix Testbed environment:
systemctl start dockerdocker run --rm -it -d -p 3000:80 cybrcom/commix-testbed
Generate the Weevely payload
Then, I’ll move to my Documents directory:
Once there, let’s generate our Weevely payload.
If you’re not using a distribution that already has Weevely pre-installed (like Kali), you’ll need to install it first. Then, run this command:
weevely generate commix weevely.phpCode language: CSS (css)
This will create a
weevely.php file in our current directory with the password commix. To view the contents, we can type:
cat weevely.phpCode language: CSS (css)
As you can see, the code is obfuscated through encryption, but this code is what creates our backdoor.
The creators of Weevely call this the backdoor agent, and this is the file that we want to upload to the target web folder. Once it’s uploaded to the target web folder, we will have the web server execute that PHP code which is what gives us remote access. So, the agent has to be reachable from a URL you have access to, otherwise this won’t work.
Upload the backdoor with Commix
In order to upload it, we have to go back to using Commix.
But before I do that, I’m going to cheat a little bit because our upload attempt will actually fail at first, and I want to show you why. Let’s jump inside of the container:
Grab the container ID and use it for this command:
docker exec -it <id> /bin/bashCode language: HTML, XML (xml)
Now let’s pull up the apache error logs to monitor what happens.
Now (and in a different terminal window), let’s go back to Commix and run our attack:
With this command, we are uploading the Weevely file to the target destination (
It will ask if we want to enable an HTTP server to which we will respond Y.
Then we get this warning in the results:
And the file did not write because our user running the application does not have proper permissions, which we can see in the Apache logs from our other terminal window. This is because of how permissions have been set up on the server/container.
If we exit out of the error logs, and we run an
ls -l, we will see that the directory is owned by root. While I would not recommend having root own the web application directory, in this case it prevented us from uploading files via the command injection vulnerability, so that is something to keep in mind when we explore defenses later in the course! Permissions can play a role in preventing compromises, but they also should not be the only defense.
Let’s change these permissions so that we can demonstrate the file upload:
chown -R www-data:www-data commix-testbedCode language: CSS (css)
Now, let’s re-run our attack.
And there you have it!
We’ve uploaded our backdoor agent to the server, and we can verify with the Pseudo-terminal:
ls weevely.phpCode language: CSS (css)
Connect to your backdoor agent
After uploading the backdoor agent, we can execute the script from Weevely back on our system.
As a reminder, the commix at the end is the password we used to encrypt this file.
We now have shell access to the server/container, and if this were not a lab environment, we could keep this access for as long as our victims don’t realize the backdoor is there.
Concluding creating backdoor shells with Weevely and Commix
Considering that this
weevely.php file is just one of thousands of files on this system, depending on how sophisticated your target is, it could be that they never find this file. You could even change this to be a filename that blends in even more. For example, there are a bunch of files in here that start with
classic_, so you could name yours
classic_advanced_auth.php and it would blend right in.
But, enough of me giving you bad ideas.
As we saw in this post, generating, delivering, and exploiting backdoor agents can be very straightforward under the right circumstances, and it can lead to serious breaches. In future posts and in our free Introduction to OS Command Injections course, we teach other methods of exploiting OS Command injection vulnerabilities, as well as defense techniques that should be used to defend our applications against this type of threat.