Recently, I've thoroughly enjoyed brushing up my offensive security skills. I've worked in the defensive security field for longer than I care to remember, and gaining more insight into how attackers perceive the world has really opened my eyes. My background is two-and-half decades of Linux and securing containers over the last seven years or so. An area that always piques my interest is Linux-based local privilege escalation. Once you have found a way of gaining access to a machine, the Holy Grail is elevating your privileges to the root user so you have full control.

Sometimes achieving root can take a little time. As an attacker, it is important to be able to return at a later date if you haven't achieved root user privileges yet or you want to monitor changeable data on a machine. Penetration testers and attackers would call this ongoing access persistence, which is the ability to gain a foothold and then maintain access; you might also call it creating a backdoor.

Attackers have a multitude of ways for ensuring that, if a machine reboots or some other event occurs, a backdoor is re-established automatically. This article looks at reverse shells and provides some examples of how to achieve persistence once you have gained access to a Linux machine. It should go without saying that you should use the following information for testing, practicing, and improving your knowledge and not for some nefarious purpose.

Backwards and Forwards

Two popular types of remote access for an attacker are reverse shells and bind shells. A bind shell (sometimes called a forward shell) is where a target machine (the machine under attack) can be accessed remotely by the attacker over the network. For purposes of this article, a bind shell is presented over a network port in a way that an attacker can connect back into the target machine. Bind shells are less common because they require firewalling to be in a more malleable state for the attacker. A number of security controls might be stopping inbound traffic on a server (upstream firewalling with specifically whitelisted IP ranges and various types of inbound traffic being blocked, for example).

A reverse shell, on the other hand, is where the target machine (the one suffering the attack) phones home to an IP address that the attacker controls. In most firewall configurations, outbound traffic is much more open. Often, any process on a machine that initiates network connections is permitted to do so by default. This avoids the need to worry about firewalling between the target machine and the attacker (unless very strict iptables are configured, for example).

Bash It into Shape

The target machine is the computer suffering the attack. The target can be any kind of networkable device, of course, but it is usually a server. Bear the terminology in mind because things can get pretty confusing when other machines are involved and you're reversing the direction of traffic from a target.

I will start with an example from the best shell on the market, Bash. I have an Ubuntu Linux laptop that I will call the "attacking" machine and my "target" machine is a Debian Linux server on AWS (an EC2 instance). The variety of Linux doesn't matter at all in my examples (and as Ubuntu Linux is a Debian derivative, you could swap the roles around without changing any of the command syntax). The straightforward Bash commands that follow should work with most distributions without any changes, although the package installation details might vary.

I'll start by installing the undisputed heavyweight champion of reverse shells, netcat, on the attacking machine (my laptop) so I can listen for the target machine phoning home. On the attacking machine, I will start by creating what's called a listener to catch the reverse shell connection when the target machine phones home.

There are a number of varieties of netcat, mainly for legacy reasons. (I discuss these reasons in my book Linux Server Security: Hack and Defend [1] if you're interested.) Listing 1 shows the results of searching the Ubuntu package lists for the word "netcat."

ncat/jammy-updates 7.91+dfsg1+really7.80+dfsg1-2ubuntu0.1 amd64
  NMAP netcat reimplementation
netcat/jammy,jammy 1.218-4ubuntu1 all
  TCP/IP swiss army knife -- transitional package
netcat-openbsd/jammy,now 1.218-4ubuntu1 amd64 [installed,automatic]
  TCP/IP swiss army knife
netcat-traditional/jammy 1.10-47 amd64
  TCP/IP swiss army knife

As you can see in Listing 1, Ubuntu users have four flavors of netcat to choose from. If your attacking machine doesn't have netcat built-in already and it is a Debian derivative:

$ apt install netcat

I prefer to trust the Nmap project's version where possible (named ncat). According to the Nmap website [2], "Ncat is a feature-packed networking utility that reads and writes data across networks from the command line. Ncat was written for the Nmap Project as a much-improved reimplementation of the venerable Netcat."

To install ncat, use the following command on Debian derivatives:

$ apt install ncat

Setting Up the Shell

Now that the listener software is in place, I am ready to set up a reverse shell. The first step is to look up my laptop's IP public address. My favorite way to look up an IP address is using the curl command.

The ifconfig.io website is an excellent tool for discovering your publicly presented IP address via curl. You can also get lots of detailed information about your current networking information. The following command dutifully reports back my laptop's public IP address (via a VPN which you may need to switch off initially while testing):

$ curl ifconfig.io
217.XXX.XXX.XXX

The next step is to fine-tune any firewalling on the attacking machine. I use the excellent Gufw Linux firewall [3] that is included in Ubuntu (Figure 1). Look in the Report column (the tab is shown in Figure 1) for useful information about exposed ports. You can even create rules from listening ports in the Report column, making light work of tricky configurations.

Figure 1: Opening up a list of rules so I can test reverse shells and leave my firewall enabled.

The red text in Figure 1 shows a list of four inbound traffic rules that punch a hole in my laptop's firewall. I've opened these inbound ports: 4444, 4445, 8888, and 8889. I tend to use a couple of ports at once and like to have a spare one or two so these choices make sense for my needs.

Note: If you're using NAT to get to the Internet (which you most likely are from both home and the office), you will need a port forwarding rule on your router to get traffic forwarded to TCP Port 8888 in the examples.