Command-and-control servers, also called C&C or C2, are used by attackers to maintain communications with compromised systems within a target network. The terms "command" and "control" are often bandied about without a clear understanding, even among some security professionals, of how these communications techniques work to govern malware.
Half of the 315 security professionals surveyed about malware at organizations with more than 1,000 employees were "not very familiar" or "not at all familiar" with command-and-control communications techniques, according to Enterprise Strategy Group research. The knowledge gap widened based on their organization's security resources, from 24% of those with advanced security programs to 48% with average resources, and 82% with basic cybersecurity.
As the name implies, command-and-control servers issue commands and controls to compromised systems (often Internet-connected computers of home users that then form zombie armies known as botnets). These communications can be as simple as maintaining a timed beacon or "heartbeat" so that the operators running the attack can keep an inventory of the systems they have compromised within the target network or use them for more malicious actions, such as remote control or data exfiltration. While the command-and-control server is used to control the system on the inside of the target organization, it is usually the compromised host that initiates the communication from inside the network to a command-and-control server on the public Internet.
Malware enters the enterprise through a number of channels. Today's perimeter network defenses are only as good as the firewalls and their virus and IDS signatures, which prove ineffective for unknown exploits.
The typical method for a malware infection is through email phishing attempts. This technique tricks the victim into opening an attachment or linking to a malicious website, which has an embedded payload. The payload then uses a system vulnerability to silently and swiftly compromise the computer. The specific methods used depend on the operating system or the application that opens the attachment.
Most organizations only allow known and approved traffic into their networks, but are liberal in what they allow out to the Internet. Programmers who write malware build it assuming that the target organization has restrictions in place to prevent inbound connections through its firewalls. They also write malicious code to evade antivirus and antimalware programs, so many targeted infections are successful at compromising computers.
When the malware or agent is dropped on the target computer as an email attachment or drive-by link, and executed, it will load a malicious program to begin its operations. The infection happens in a series of general stages, as shown in Figure 1.
Typically, this program is unpacked within the operating kernel as a device driver to maintain persistence on the system and evade detection. Upon execution, the malware code sends a beacon out to the command-and-control servers to look for its next instruction set. Most malware is pre-programmed with an autonomous command to attempt to set up a communications channel that originates from the target machine. The "phone book" is written into the malicious code and can contain hundreds of fully qualified domain names and IP addresses that the malware will cycle through as it beacons out to the command-and-control network.
If the target's network has liberal outbound or egress firewall rules, the malware will establish a communication channel with the command-and-control server.
While command-and-control is the sixth phase out of the seven identified in the Cyber Kill Chain, in many instances, it is the primary objective of malware infections.
Simple malware communicates using an Internet Relay Channel. The malware initiates the communication and sends a ready state and waits for a response from the command-and-control server, sending out timed beacons to keep the session alive. When the attackers receive the beacon, they can then change or otherwise manipulate the instructions for the malware. To keep the initial malware small, many malware payloads perform the beacon upon initial execution and wait for the response before completing any other operations. Some malware will perform a series of instructions and operations, and only beacon out to the command-and-control network upon successful completion of that operation.
As organizations have implemented tighter controls on traffic sent out of their networks, malware operators have had to change their communications channels. The maturity of malware communications reflects -- and is in direct response to -- strong egress rules and other detection methods. Because many companies still allow unfiltered access over known ports used for HTTP, HTTPS, FTP and secure shell (SSH), malware operators have adjusted their methods to tunnel their communications over these ports.
Advanced malware may even use SSL certificates, encrypt the communications and make the traffic masquerade as Web traffic. Once the communications channel is established, the command-and-control server will instruct the malware to download additional rootkits and remote access tools on the compromised host. The attackers will attempt to move laterally within a target network to infect additional hosts to ensure that if one system is identified as infected, they can still maintain access. These newly infected systems also begin to "call home" by sending beacons to the command-and-control servers. This pattern continues as the attackers perform reconnaissance on the targeted systems, establishing a shadow network within the enterprise infrastructure.
While command-and-control is the sixth phase out of the seven identified in the Cyber Kill Chain, it is a critical component in attackers' success and, in many instances, the primary objective of malware infections. The five phases before it in the Cyber Kill Chain (Figure 2) are preparatory steps to the delivery of the command-and-control malware. Remote access Trojans, such as ShadyRAT, IOC and others are examples of remote administrative toolkits used for interactive command and control. Not all malware packages are as full-featured as RATs.
Much of what is considered malware today is defined by the communications of the compromised host with the command-and-control network. The network signatures -- used by intrusion detection and prevention technology, firewalls and breech detection systems -- are able to identify known communications of the compromised host, if this information is augmented with current malware indicators. Out-of-the-box antivirus and malware signatures often fail to identify current indicators of compromise (IOCs) -- usually IP addresses or DNS names of the hosts affiliated with the communications of an infected system. Checking this information against current lists of command-and-control networks is one way to verify if a network has been compromised. Command-and-control operators often route their communications through multiple hosts and use dynamic DNS registrations to further hide their actions -- and keep their systems highly available.
Several indicators can be identified through analysis of potential malware in a sandbox or live environment. The analysis can be performed using freely available tools, such as Cuckoo Sandbox, or by capturing the traffic from the infected system using TCPDump or Wireshark. A lot of command-and-control programs communicate using direct-to-IP-address HTTP requests. Direct-to-IP requests use a website's IP address, rather than DNS, to resolve a name to an IP address. Most users and applications do not use the IP addresses of Internet sites -- it's easier to use host names or URLs that will allow the IP address to be changed as needed. These connections may not be malicious by themselves, so other IOCs are needed.
One popular command-and-control communications technique is to use publicly available DNS servers rather than the systems inside a private network. Advanced-persistent-threat actors try to use public DNS services to avoid logging within the private network and risk detection.
Another widely used technique to avoid detection is to leverage dynamic DNS hosting sites. With this method, the infected hosts behave more like humans at the computer, because there are fewer direct to IP address requests. And the infected systems can use any available DNS services, including private ones inside the network. The use of dynamic DNS is the most stealthy and difficult to catch without other IOCs.
Spotting an infected host's communications requires an understanding of how enterprise systems operate under normal conditions. Identification of a malicious program involves system- and network-level analysis to determine how the malware communicates and which program on the system is generating the suspicious traffic.
Isolating a "suspect" computer to capture and analyze its network behavior, and correlating that information with logs from DNS and proxy systems, can be extremely useful. When someone isn't logged onto the computer and generating traffic through email and Web browsing, it should generate a relatively small amount of traffic. Noisy applications can be identified, evaluated and terminated to begin isolating system processes and the communication that is generated. For instance, connection attempts to external DNS servers or over nonstandard ports through a firewall signal suspicious traffic that might indicate an infection. Cutting off these communications is the step to remediate an infection from a command-and-control network. Each infected system needs to be cleaned and updated to prevent future infections.
Plan of action
Security teams can effectively stop a malware intrusion if they focus on disrupting communications with command-and-control nodes. It's unrealistic to attempt to prevent the malware from gaining a foothold in an enterprise because users will inevitably click on an email attachment or link, causing an infection. And signature-based tools, such as antivirus and malware detection, are not effective half the time. Security resources should focus on stopping malware from communicating with the command-and-control server, effectively breaking the kill chain. To accomplish this, all enterprises should adhere to basic security practices:
- First, configure strong egress firewall rules that limit everything but Web traffic outside of the enterprise. This will stop automated beaconing over nonstandard ports and protocols, such as dynamic DNS. Modern malware uses Web ports to communicate back to command-and-control locations.
- Web traffic should be proxied with only traffic to categorized websites allowed, and access to unknown sites blocked. The proxy should stop self-signed SSL certificate traffic. This should disrupt Tor and other encrypted communications channels. Required business tools such as FTP, telnet or SSH should be moved to the network edge as DMZ-type services.
- Ideally, the enterprise has access to current threat intelligence that provides data on known command-and-control IOCs. This intel can be purchased as a service from vendors in a raw data dump format, or as a data feed to an enterprise-level security system. The information is always changing, so establish a way to consume the current data. Exercise caution when selecting a product. All security vendors promote their services as effective, but the quality and currency of the threat intelligence is the key consideration.
- The enterprise needs to be able to trigger alerts on suspicious traffic or IOCs. This can be done by establishing alerts in a security information and event management platform or, depending on the technology, from the administrative console of a tool. Many of the bad guys work in vastly different time , so develop a 24x7x365 response for systems and network administrators during off hours. Attackers also target organizations on holidays and weekends.
By breaking the communications channel to the command-and-control server, and having visibility of suspicious traffic, an enterprise can go a long way toward stopping the most advanced malware.
Adam Rice is the CISO at Alliant Techsystems (ATK). An InfoSec professional with 17 years of experience, he has served as CSO of a global telecommunications company; general manager and vice president of a managed security services business; director in several network consulting companies; and is a retired U.S. Army noncommissioned officer. He is also a regular contributor to several information security publications.
James Ringold is a senior enterprise security architect at ATK, who has worked in the aerospace and defense, electronic discovery and investigations and retail industries, performing technical evaluations and building information security programs in various stages. The former security operations manager and incident responder has focused on countermeasures and controls to detect and mitigate cyber intrusions throughout his 17-year professional career.