The L in Linux Stands for Lateral Movement

This blog post is not intended as a guide to Linux hacking; it is aimed at informing network defenders on potential threats that can affect their networks.

Most (if not all) of the protocols we’ll cover in this post aren’t available out of the box, but must be configured in a specific way to achieve lateral movement. We will not provide guides to abusing the protocols covered in this post.

We hope to raise awareness of other protocols that may be configured in such a way that they can serve as a vulnerable underbelly that can be abused by attackers. A determined hacker can and will find and abuse the protocols covered in this post without us telling them about it — we want the blue team to be prepared for it.

To further aid defenders, we’ve teamed up with our Infection Monkey team. Infection Monkey is an open source automatic breach and attack platform that tests your network against many common lateral movement and network propagation techniques. 

The development team used the results of our research and incorporated them as a new exploit technique inside the tool. Defenders can use Infection Monkey to test their network against some of the remote execution techniques mentioned in this post.

[Note: This section is about the method we used to find interesting lateral movement targets. If you’re not interested in methodology and would rather jump straight into the action, feel free to skip to protocols that allow immediate code execution.]

Since we’re looking for lateral movement protocols and services, we can consider both the OS aspect and the network aspect when looking for potential candidates; namely, we can look for the most common processes in Linux machines, or at the most common listening ports. We shouldn’t neglect one in favor of the other since there can be different implementations of the same protocol (different process name, same port) or a single process with multiple or changing ports (like ephemeral ports in RPC).

When we looked at the top ports used in communication with Linux machines, we saw that SSH (port 22) dominated the list, but there were other promising candidates for investigation as well: FTP (port 21), SNMP (port 161), and Sun RPC (port 111). 

There are also a few ports that were handled by sshd (the SSH daemon process) even though they have nothing to do with SSH. We assume that those are used in SSH tunnels and are, therefore, outside our scope of investigation. 

Take, for example, ports 135 and 5985, used in Windows for RPC and WinRM, respectively. We don’t expect those ports on Linux machines, especially when sshd is listening on them. It is more likely that an SSH tunnel was opened on a Linux machine that is externally available to allow access to internal machines. Since SSH tunnels only redirect traffic to another recipient, they don’t matter much when considering lateral movement into the host of the tunnel.

Among our findings, two interesting processes popped out for consideration — xinetd and rpcbind. They’re not viable as lateral movement targets, as they don’t offer many capabilities; they’re mostly used for lookup operations to map communication and ports to other processes. Instead, we can use them to find other interesting services.

xinetd (and its predecessor, inetd) is used to control and manage daemons. Looking at the default list of daemons it manages, we can find rexec, as well as rlogin and rsh, all part of the Berkeley r-commands suite. We can also find various FTP daemons, VNC and Telnet.

rpcbind is the RPC portmapper process for Sun RPC. RPC servers register with the portmapper, and clients can query the portmapper to find the server’s ephemeral port. Unlike MS-RPC, Sun RPC uses program numbers to identify specific RPC servers, and those are registered with the Internet Assigned Numbers Authority (IANA). Looking at the registered programs, we can see some interesting names, such as rexec and NFS.

24% of tested Linux machines

Regardless of the built-in capabilities of SNMP, it is also a target for attackers, with some threat actors utilizing vulnerabilities in SNMP implementations in routers and IoT devices to breach networks. The abuse of SNMP has reached the point that the Cybersecurity & Infrastructure Security Agency (CISA) released an advisory about the protocol.

To help test against this threat, we’ve teamed up with our Infection Monkey team to develop an exploit plug-in for the SNMP remote EXTEND plug-in. Running Infection Monkey will allow you to see what this attack would look like within your environment and verify that your security posture is sufficient to rebuff the attack. The SNMP attack is available in the latest Infection Monkey release, v2.2.1.

10% of tested Linux environments

No, we’re not specifically talking about RDP, the Microsoft proprietary remote desktop protocol (but it’ll appear, worry not). There are other remote desktop protocols that can be run on Linux machines. They are much less common than in Windows environments, as they are meant to share graphical desktops and most Linux servers are installed without any desktop environment. 

However, we did see those protocols used in a few networks, so they made the list and are included here:

• The X Window System is a desktop window system available for Unix, and it can also listen for remote connections. It uses TCP ports 6000+ (it starts with port 6000, but the port number increases subsequently for each desktop server running).

• VNC is based on the Remote Framebuffer (RFB) protocol and uses TCP ports 5900+ (similarly to X, the port number increases with each desktop server running).

• Xrdp is an implementation of the Microsoft RDP protocol that can be used on non-Windows machines. As an implementation of RDP, it uses port 3389.

Some of the remote desktop protocols are more secure than others, but they all can potentially be abused by threat actors. There are also multiple implementations of the protocols in Linux, which is why we included port numbers here instead of program names.

4% of tested Linux environments

Much like SSH and rlogin, Telnet is also a protocol for remote console and control. It is also unsecure and unencrypted, similarly to rlogin, and vulnerable to interception or packet sniffing attacks. We’ve only seen it in approximately 4% of the networks we examined, but it means it is still in use and could affect your network. The protocol uses TCP port 23 or 2323.

1% of tested Linux environments

The Berkeley r-commands is a suite of programs that allow for remote operations across machines in the network. Originally developed as part of BSD, they have largely been superseded by SSH, mostly because of the security concerns of those protocols (no encryption and minimal to nonexistent authentication). 

Still, we’ve seen a few of the suite’s daemons here and there, so it’s too early to rule them out entirely. There are three daemons we would like to bring to the limelight:

1. rexec — provides remote command execution; uses TCP port 512

2. rlogin — provides remote login and console; uses TCP port 513

3. rsh — similar to rexec, but doesn’t require authentication; uses TCP port 514

Even if not directly allowing for remote control or execution, just having the ability to transfer files to the target machine can prove valuable for attack development. Let’s take a look, for example, at the common lateral movement technique (and tool) PsExec, even though it is Windows-based.

First, it copies its service binary to the target machine via SMB, and only then does it get the service to run by communicating with the service manager remotely. That’s why we think it’s important to also map the various ways that attacker tools and binaries can be placed on target machines. We’ve also theorized a few methods of abusing tool transfer to achieve remote execution, which we’ll discuss later in this post.

31% of tested Linux environments

The File Transfer Protocol (FTP) is one of the more classic protocols (it was the first application layer protocol taught in networking class). Used for file transfer, it is a text-based protocol which is unsecure, since it uses cleartext.

20% of tested Linux environments

18% of tested Linux environments

The Network File System (NFS) is another way to create file servers. It is built over Sun RPC (TCP port 111). There are many RPC functions we can look at, but we didn’t find an immediate way to get remote command execution through it.

16% of tested Linux environments

rsync is a utility for file transfer and synchronization between machines in the network. It can run as a service or a daemon, and can serve files over its dedicated protocol (TCP port 873), rsh or SSH.

We can discuss file transfer all we want, but it isn’t very useful unless the attackers can execute the transferred files somehow. Besides tricking the user into executing the file themselves, we’ve thought of two options to achieve execution — both require some sort of misconfiguration, or a (severe) loosening of security settings.

There are many legitimate locations in the Linux file system that can be used to install persistence, but for lateral movement we’d focus on /etc/cron.hourly. If an attacker can upload a file there, with execute permissions, it would simply get executed at the next round hour thus achieving the long-coveted lateral movement.

But, to do this, an attacker would require sudo or root permissions, which are not easy to achieve. Sadly, it is possible to configure file servers in an unsecure way, which would allow this exact scenario (see rsync, for example). Why would someone configure those services with so little security? Because it’s convenient and makes life easier for them. Please don’t be that someone: Protect yourself.

A much more plausible scenario, instead of access to /etc, would be remote access to a web root folder of an active web server. In that case, it should be possible to upload a custom web shell, and use it to execute remote commands. There are many examples of web shells available online, so attackers don’t even have to invent the wheel.

Another aspect that is becoming increasingly popular in recent years is containers. In our research, we’ve seen multiple instances of container programs listening and accepting connections, and it seems to also be allowed by design. If attackers can get access to a remote container manager, they can upload their own malicious image, and use it to propagate further inside the network.

Now that we’ve covered potential ways for attackers to get in machines, it is time to discuss how to keep them out.

As we already mentioned, none of the protocols we’ve discussed here come installed and configured with Linux out of the box. Someone needs to install them specifically. As such, the first order of business would be to have good visibility into what is running and communicating (or listening for communication) in the network — as Sun Tsu wrote, “If you know neither the enemy nor yourself, you will succumb in every battle.”

Once you’ve taken inventory of your network, and identified one of the services discussed here, the next step is to check the configuration of those services. For example, an up-to-date SNMP agent that is configured to use SNMPv3 with Kerberos authentication is perfectly fine. SNMPv2 with an easily guessed community string? Not so much.

Other protocols or services can perhaps be replaced with newer, more secure protocols, such as using SSH instead of the r-command suite or Telnet. Some protocols, like FTP or rsync, can also be encapsulated over SSH, for the additional benefit of the encryption SSH provides. It goes without saying: You’ll have to ensure that SSH is configured correctly as well, with PKI or strong passwords that aren’t easily crackable.