Using SMB named pipes as a C2 channel

Intrusion detection systems are becoming increasingly more capable of detecting malicious activity on the corporate perimeter, local network environment and on individual hosts. Commonly, when attackers move laterally on a network, new hosts communicate out using HTTPS. However with security appliances doing SSL termination and reputation-based filtering, suddenly having a bunch of hosts talking to relatively untrusted domains can easily trigger alerts.

To get around this, a number of APT campaigns have set up a limited number of internal Command & Control (C&C) servers. All other implants communicate with these C&C servers who handle the outbound traffic.  If peer-to-peer communication between implants can be made to look innocuous then this greatly reduces the attacker’s footprint on the local network.

It’s just SMB

In any large corporate environment the network will be swimming in SMB traffic. This makes peer-to-peer SMB communication an excellent candidate to obfuscate malicious content. This technique has been used by a number of actors in the past, such as Duqu and more recently ProjectSauron. Additionally, the popular Red Team framework Cobalt Strike allows for beacons to communicate internally using SMB.

Invoke-SMBShell

To illustrate this technique I created a simple proof-of-concept SMB shell. The server component creates a NamedPipeServerStream and waits for a client to initiate a connection using a NamedPipeClientStream.

Initiating a connection is very straight forward. The screenshot below shows the sever component of the script creating a named pipe and waiting for a client connection.

Once ready, a client can connect to the named pipe using the client component of the script.

From a protocol perspective, the only thing that is visible on the network is SMB traffic as can be seen below. To protect the data in transit, AES-CBC is used (courtesy of the Empire framework).

Invoke-SMBShell has support for commands which return output as well as commands that do not and will return error messages in case erroneous commands have been received by the client.

Caveats

In its current state the script has a few limitations:

• The named pipe is not asynchronous so only one client can communicate with the server at any given time.
  
• The shell has no concept of long-running commands. All commands received are handed off as PowerShell jobs and the output is returned once the job completes.
  
• This proof of concept differs from our initial scenario where an internal host is used as a C&C sever, but should serve well to illustrate using SMB as a C2 channel.
  

Contact and Follow-Up

Ruben works in our Assurance team from our London office. See the contact page for ways to get in touch.