April 28, 2020
This is the first in a series of posts covering the basic principles of Command and Control (C2), with practical applications and examples through PowerShell Empire.
At the most basic level there are three components to C2 infrastructures: server, agent, and C2 traffic. The server, or attacker system, runs the platform or framework which manages the orchestration of the various C2 components. Agents are the malicious processes which run on compromised hosts and perform actions on those hosts and the network. The server and agent then communicate between each other and form the C2 traffic. This is a gross oversimplification of most C2 infrastructures, but it establishes a baseline for what forms a command and control channel.
C2 traffic flows either from server to agent, or agent to server. Depending on the direction of the initial connection it gets classified as either bind or reverse. When the attacking server makes the initial connection it’s a bind connection, and when the agent reaches back to the server it’s a reverse connection.
On its face, this might seem like an insignificant distinction to make. That’s not the case! For a bind connection to be successful, the compromised host needs to be accessible to the attacker system. Generally, this doesn’t happen unless the attacker is on the same network as the compromised host. In most cases a reverse connection is more likely to be successful. Outbound connection rules are almost always more permissive than inbound connections, so it’s much more likely for the compromised host to be able to access the C2 server. Once the compromised host initiates a connection, the server can respond to it directly. This leads to a majority of C2 channels being created with reverse connections, and the examples we’ll go over in PowerShell Empire in later posts will be reverse connections.
Another defining characteristic of command and control channels is the type of traffic they use to communicate. Essentially any networking protocol you can control can be leveraged for C2 communications, but some are much more popular than others.
This is probably the most common protocol for use with command and control channels, and there are a number of good reasons for this. First, it’s easy to blend in with the tons of other HTTP traffic going in and out of organizations. Also, it’s a very familiar protocol so creating custom traffic profiles is relatively simple. There are any number of ways you can customize HTTP traffic to carry C2 communications.
Connections over DNS are a bit more complicated, but they also have some distinct advantages. In a DNS C2 channel, the compromised host makes a DNS query to its default DNS server. This could be an internal server, or something like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1. This server won’t know the address of the resource requested by the compromised host and will forward that request to the resource’s authoritative DNS server: the attacker system. The attacker then responds with an IP or DNS TXT data which contains the commands for the compromised host to run. These are forwarded through the compromised host’s default DNS and eventually back to the agent.
This type of C2 channel is particularly effective because all the C2 traffic initially routes to a known, trusted server. This will often allow easy egress out of a corporate network and makes the traffic hard to detect.
SMB pipes over port 445 can make excellent C2 channels, especially on internal networks. Servers use SMB for a lot of generic communication (after all, it’s the Server Message Block). This means that SMB pipes are really common, and it can be hard to distinguish benign, everyday use from C2 traffic. An important note about SMB based C2 channels is that they are bind connections. An SMB named pipe is created on the compromised host and the attacker box reaches out and establishing a connection with that pipe.
While defined protocols are great and allow us a lot of creativity in evading detection and firewalls, sometimes a simple TCP or UDP connection over an arbitrary port is all we need. Frameworks like Metasploit will commonly default to a generic TCP connection over port 4444. This can be a good place to start if you’re learning a new framework or new to command and control.
Having a solid foundation in the technologies you use as a security professional is really important. If you don’t understand what your tools are doing, it increases the inherent risks that come with penetration testing. The details we’ve covered are far from exhaustive, and command and control channels and frameworks can get really complicated. However, hopefully this has given you enough of an understanding of the basics to make you more effective when using the actual frameworks. Keep an eye out for the next post in the series where we’ll dive into PowerShell Empire and apply these principles to interact with compromised hosts.
.svg)
