Weevely creates a PHP backdoor on webservers running PHP. It is pretty straightforward to use, and pretty easy to get onto a webserver. You get to it through Applications | PostExploitation | Weevely:
When you first launch Weevely from the menu, it opens a terminal window and gently chides you about using the script improperly:
This is actually a more helpful doc string than the weevely --help command gives:
We know now that we can generate an agent, which can be dropped on a webserver. We can run a terminal to the target, and we can load an existing session file.
Weevely is a Python script, and there are a couple of improvements you will have to make to Python to use Weevely:
root@kali:~# apt-get install python-pip libyaml-dev root@kali:~# pip install prettytable Mako pyaml dateutils –upgrade root@kali:~# pip install pysocks --upgrade
If you get in a hurry and skip this step, you might get the following error message:
To create an agent, all we have to do is decide on an innocuous name, and a password:
We save malware files in their own folder in the Kali /root/ directory, so we can find them again when needed. A better name for this directory might be as follows:
Weevely is cross-platform, and should work wherever you are serving PHP pages. Here's an example of running Weevely against a webserver on the Kali Linux host:
It is just as simple to test Weevely on a Windows server if the Windows server is running PHP – for instance, if it is a web server running WordPress or some other PHP-based script. The server we are using for this test is Windows Server 2012 with PHP running. If you were just inside the Windows server using Metasploit, it is possible to drop our metrics01.php file, made by Weevely, into the webroot folder:
Once you have the file in place, you can do a lot of things with it. We have chosen just a few actions, though there are fifty commands you might be able to do. First, you contact your agent by using the following code:
weevely http://192.168.56.103/metrics01.php evilHacker
The same kind of entry success output appears as when we tested it on the Kali webserver:
To find out what Weevely can do, we will run the help command to see what is available for you to run on the Windows server:
weevely> :help
The help file reads out as in the following table. Note that there is a colon ":" at the beginning of each of the commands:
The next section of the help file shows you the commands you can use to simulate an unrestricted shell. For some inscrutable reason, the command and description are reversed in this section:
|
Description, or Internal Command |
Weevely Command |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
whoami, hostname, pwd, uname |
system_info |
|
rm |
file_rm |
|
cat |
file_read |
Once you have looked over the help files, a logical next step is to find out as much about the system as you can. To do this, you run the system_info command. This provides you with a nice little table of the details of the machine:
You can get used to the file navigation commands pretty easily. Here is the ls /dir command, and the cd command. These do exactly what you might imagine in some cases, but are likely to fail if you are trying to go places that the webserver user doesn't have permission to see:
Sadly, Weevely doesn't let us get long-form directory listings. It does give us a short-form listing like the preceding screenshot, and an explanation of what is happening:
Since it is a Windows filesystem, we can guess that the list items without an extension are probably directories, so let's move into one of those directories. In this case, it's the wolf24 directory, as shown in figure, shown previously:
We can see from the file names here that this subdirectory is an ASP.NET site. There is a folder called Umbraco, which is a .Net CMS script, and if that is not proof enough, there is a default.aspx file in the folder.
There is a command that lets you edit remote files on your local machine. The command is file_edit:
file_edit default.aspx
This opens the file in vi by default in Kali Linux, so let's try and edit the file:
On some servers, this will result in another directive being added to the CMS, which could do anything at all that the webserver user has the right to do. Let's try and write a totally new file to the server:
As it happens, our victim server doesn't let us upload this file. Since we have gotten system-level access in another action, we could well have made sure we had that ability before beginning the Weevely work:
Just for fun, let's see if the webroot has the same careful permissions as the CMS directory. We will change to the upper directory, and see if we can add a line of code to the index file there:
We have a successful page breach, based on changing the permissions for the page previously using Metasploit. Weevely can be very useful for attacking sites that do not have proper permissions set:
