Command-and-control (C&C) servers are the machines attackers use to maintain communication with the compromised systems in a target network. These servers issue commands to the compromised systems, ranging from a simple “Are you (still) there?” request to data exfiltration instructions and full remote control commands. The type of C&C traffic entirely depends on the malware and the attacker’s objective.

Although a C&C server is used to control the compromised systems, it’s usually the compromised system that will contact the C&C from inside the victim’s network and then wait for further instructions. This is because most modern networks have a very strict inbound filtering policy, making it impossible for attackers to directly contact the compromised machines from an external network.

What Causes C&C Traffic?

Simply put, compromised machines drive C&C traffic. The majority of the machine is compromised by malspam, or malware delivered via spam. This malware is hidden in legitimate-looking PDF or Microsoft Office documents. The victim opens the document and then unknowingly facilitates the installation of the malware. A user who falls victim to malspam is often not even aware that abnormal activity is taking place.

Once installed, the malware sends out a beacon informing the attackers that it has been successfully deployed. After this, the malware can sit idle on the system and regularly check in with the C&C servers for further instructions.

The set of C&C servers can be built into the malware configuration section. From an attacker’s perspective, this is not always very reliable because this type of infrastructure can be brought down or blocked more easily. That’s why malware sometimes makes use of a domain generation algorithm (DGA) to define which C&C server it must contact. A complex algorithm makes it more difficult for defenders to block access to the C&C servers, which is why detecting the DGA-generated domains can be challenging. A good first step is to paste the domain name into a service like Cymon, which will quickly analyze it and determine whether it is suspicious.

Using Network Time Protocols (NTP)

Timestamps are an important element during incident response. They tell us exactly when something happened and serve as reference points for building a timeline of an incident.

If your logs are not time-synced, you’ll have to take into account the different time skews when tying together log elements from a variety of sources. Not having your systems synced to a central time-server will make building the timeline based on the C&C communication much more difficult, prone to errors and resource-consuming.

Leveraging Log Services

Most malware will use a Domain Name System (DNS) to resolve a C&C server address. The log files of your internal DNS server are a crucial source of information. Make sure they contain the client queries and, ideally, the answer that was returned. Not all malware will make use of DNS to reach the C&C servers; sometimes it will reach out directly via an IP address. Note that DNS traffic itself can also be used as a communication channel.

Corporate environments often require that users’ web traffic goes through a filtering proxy. The web proxy logs are also helpful for detecting and analyzing C&Cs. Security teams can spot traffic related to already-known attack campaigns by using threat intelligence feeds. Most proxies will also support block lists based on these feeds.

Not all C&C communication has to be web-based; it can also happen via email. Although email logs rarely contain the full conversation, the metadata can be helpful. Verify with your legal department under what conditions storage and access to this information is allowed.

Firewall logs can shed light on other forms of C&C communication via internet relay chat (IRC) or peer to peer (P2P) exchange, for example. This traffic will be blocked in most corporate environments, but seeing an outgoing connection attempt might be enough to tip off an investigation.

Netflow records contain information that allow you to spot C&C traffic among large sets of network flows. Similarly, as with the firewall logs, it might not always give you all the required traffic details (e.g., payload), but one of the advantages is that it can also track internal flows. This is useful to detect an internal connection proxy that is used as a relay to reach external C&C servers.

If you have the infrastructure for recording full packet captures, this can be a very useful resource for hunting for C&Cs. Make sure the packet data is indexed and easily searchable. The searches can be based on the information previously found via the firewall logs or netflow records.

Obviously, log information coming from your security devices as an intrusion detection system (IDS) or internet provider security (IPS) serves as another good source of information to find C&Cs or other intrusive software.

Last but not least are the logs from your endpoint protection or filtering solution.

What Are the Different Types of C&C Communication?

There are many different types of command-and-control traffic. Let’s take a closer look at four of the most common.

Beacon

A beacon is sent when a host has just been compromised; this is essentially the malware “calling home” to the attacker. A beacon is also sent as a sort of heartbeat to inform the attackers that the host is alive. This can happen at regular intervals or as a result of a system event, such as a reboot.

Command

The answer from the C&C to a beacon can be a command that needs to be executed by the compromised host. The execution of this command can be done instantaneously or queued for later processing. Some commands also give a somewhat interactive remote shell to the attacker on the compromised machine.

Exfiltration

An exfiltration is the answer from the client to the command execution request from the server. The answer can be sent immediately after the request, at regular intervals — as part of the beacon, for example — or at a dedicated time. The payload of the client response can be the result of a command or the exfiltration of documents or emails stored on the system.

Connectivity Check

A connectivity check is used to verify that the host still has internet connectivity. This check can happen at regular intervals — such as before a beacon — and when it fails, the malware can retry or alter its configuration. In some cases, it will automatically remove itself from the system. It can even go so far as to wipe the entire system. The connectivity check can be done to the attackers’ infrastructure or to nonmalicious infrastructure, such as public DNSs or web servers. This makes it harder to detect.

Depending on the environment where it has been deployed, the malware can use different stages of C&C traffic, apply fallback communication channels or use multiband communication, meaning it splits communication between different protocols.

How to Decode C&C Communication

Before you can start decoding C&C communication, you need to collect traffic. This can be time-consuming and, in many cases, will only return limited results. In addition, a lot of the traffic will be encoded (or enclosed in an encrypted channel), making analysis even more difficult. To add to the complexity, if you don’t know what exactly is in the traffic, you have no way of determining whether the malware is simply sending out a beacon or exfiltrating confidential company documents. By the time you have fully analyzed the traffic, the attackers may have already achieved their objectives and left the environment.

In some cases, you should still attempt to understand what’s in the traffic, but you’ll have to weigh the benefits of spending time on the analysis and accepting the risk against immediately containing the incident. One alternative might be to deceive the malware by redirecting the traffic to a honeypot while containing the incident at the same time.

There are also modular Python frameworks that can assist you with decoding the traffic, such as Dshell, developed by the U.S. Army Research Laboratory, and ChopShop, developed by MITRE. Although these tools are great for rapidly decoding traffic, they only provide the basics for working with C&C traffic. Another approach would be to analyze the malware that caused the traffic. This requires basic malware reverse engineering capabilities.

Before you can start analyzing a sample, you must first obtain a sample from a compromised host. Regardless, you should build a list of compromised hosts based on the initial detection of the C&Cs and pivot through the indicators when shifting from analysis to the containment phase of incident response.

Using Threat Intelligence to Detect C&C Traffic

You can detect C&C traffic in your log sources by using threat intelligence that is either produced by your own team or that you receive via threat sharing groups. This intelligence will contain, among other information, the indicators and patterns that you should look for in the logs. A very practical approach would be to verify the presence of these indicators in your proxy, DNS or other log sources.

Another approach is to create statistics on the information in your log sources and search for anomalies and temporal correlations. Things to look for include:

• Direct IP connections, typically for malware that doesn’t make use of DNS;
• Web requests with an unusual HTTP protocol version;
• User agents that are not commonly used in your organization. Do not blindly trust user agent information, however, since this can easily be crafted;
• Excessive size or a repeating pattern in the size of HTTP requests;
• Persistent connections to HTTP servers on the internet, even outside regular office hours;
• Repeated requests for the same web resource, possibly on different domains, with a similar parameter format;
• Requests to a social network site outside regular office hours. Attackers can encode their commands textually in a page on a social network and present them like legitimate messages;
• Alerts on DNS queries for domains that have only recently been registered;
• DNS responses that have a very low time to live (TTL);
• Repeated requests for domains belonging to a dynamic DNS service or requests for URL shortener domains;
• Statistics for DNS queries on the full qualified domain name (FQDN), focusing on the second-level domain. Be aware that this can also generate lots of false positives due to content delivery networks (CDNs);
• Netflow statistics for workstations that establish a high number of connections or flows; and
• Firewall log entries indicating outbound IRC or P2P traffic.

Detecting C&C traffic can be a complex problem to tackle if you don’t have proper log collection and correlation tools. Once you have those, you can start using the results from your own analysis and the information received from peers to hunt down previously undetected malware incidents based on C&C traffic and indicators.