Remote Shells

Remote shells are an important part of ethical hacking. You will be spending a lot of time using them during penetration tests, and if you take part in CTF competitions.

In the previous topic we introduced the concept of shells. In this article we will discuss remote shells, and demonstrate how we can use them to communicate with a remote system.

In these examples we will be using Linux. You should be familiar with common Linux shell commands from the LinuxTrainer from earlier in the module

Telnet

Telnet was one of the original (1969) methods of getting a remote shell on a server. While the protocol is now rarely used over the internet, due to lack of encryption, it is still commonly used for accessing embedded devices over serial connections.

Note

Due to the way it processes line endings compared to Netcat, I also find Telnet useful for interacting with services such as mail servers.

We can initiate a Telnet session with the command telnet <target For example:

$telnet 172.16.0.1
Trying 172.16.0.1...
Connected to 172.16.0.1.
Escape character is '^]'.

Once we have connected over Telnet, we can interact with the remote system using whatever shell has been set up.

While Telnet is not normally used as a remote shell, it still is useful for interacting with other remote services. For example, we can have a simple form of banner grabbing. In the example below I connect to a HTTP server. As part of the response we get the server version.

$telnet cueh.coventry.ac.uk 80 
Trying 192.168.72.47...
Connected to cueh.coventry.ac.uk.
Escape character is '^]'.
get /
HTTP/1.1 400 Bad Request
Date: Mon, 15 Apr 2019 12:57:49 GMT
Server: Apache/2.4.7 (Ubuntu)
Content-Length: 319
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at hvs-eec-web01.coventry.ac.uk Port 80</address>
</body></html>
Connection closed by foreign host.

Secure Shell (SSH)

This is probably the most common way of getting a shell on a remote service. Unlike Telnet, which communicates in plain text, SSH allows encrypted communication to a server.

When using a terminal to connect over SSH the command consists of three parts:

ssh <user>@<host>

ssh is the command name
user is the username to login as
host is the service you wish to connect to, which can be either an IP address or a domain name

So to SSH into the hacker account on example.org we would use:

ssh hacker@example.org

Windows users can also connect over SSH using tools such as Putty or Moba Xterm (see further reading if you're interested).

Like Telnet once we have once we have connected over SSH, we are presented with a remote version of the shell on the target system.

Remote shells on Windows

By default, Windows doesn't come with any remote shell utilities enabled (probably due to its GUI focus). However, depending on the software installed, we can still access a Windows box via a remote shell.

For example, every Windows installation comes with a Telnet server installed, so if it is enabled we can use this to connect in the same way we would a 'Nix system. Other options include SSH servers, or executing commands remotely using PSExec.

During a pentest, a common way of getting a remote shell on a windows box is by uploading and executing a script on the server. For example, we could use a vulnerable web server to upload a PHP reverse shell. We can connect to these in the same way as we would on a Linux-based target, although the shell itself will normally be CMD.exe.

In summary

In this article we have looked at the 'traditional' ways of getting a remote shell. SSH is pretty much the standard for connecting to remote systems, although we do still encounter Telnet on occasion.

However, while being able to use these shells is fundamental for the system admin side of pentesting, we will normally need a sneakier way of getting a shell on the system. In the next article we will look at Netcat, a tool that comes up in most engagements, and also look at more interesting ways of getting a remote shell.