Uncovering Covert Command-and-Control Channels

By Eric KnappAs the line between securely hosted and controlled enterprise applications and cloud-based applications continues to blur, there’s more “legitimate” traffic between corporate networks and the Internet than ever before. This opens up new vectors for attack by hackers and cybercriminals as more traffic types are allowed through corporate firewalls.  


As the line between securely hosted and controlled enterprise applications and cloud-based applications continues to blur, there’s more “legitimate” traffic between corporate networks and the Internet than ever before. This opens up new vectors for attack by hackers and cybercriminals as more traffic types are allowed through corporate firewalls.  
The result is an increase in diversity of covert command and control channels, which hide inside legitimate traffic in order to bypass perimeter security. These C&C channels, used by malware ranging from simple spambots to more sophisticated rootkits, vary in the maliciousness of their intent from casual hacking all the way to advanced persistent threats (APT) and industrial espionage.

How can you detect these covert conduits, and what do you do if you find one?  There’s no easy way, but there are proven methods that help. The first is to fully understand what is really going on in your network, so that you can best utilize security automation and event analysis tools. What often prevents this is a lack of deep understanding about how enterprise systems actually behave, and then incorporating that baseline information into the tools that are available for use in threat detection.

Start with what’s already in place: If you have a firewall, scrutinize its access policies. Rather than allowing “any to any” connections for popular services such as email and HTTP, start with a “deny all” philosophy and implement whitelists so that unknown or unnecessary devices will be excluded by default. This will make it more difficult to take advantage of web-enabled printers and other such devices during an attack. It will also narrow inbound attack vectors from “any” to a known list of network devices, which in turn allows you to better implement more focused security monitoring.

That second point is key, because if you want to detect covert communications—without performing host-by-host memory analysis in search of resident malware—you need to search for the communications as they occur, and that requires

a much more robust analysis of your network traffic, including full application layer monitoring of your “legitimate” network traffic.

Abnormal activity, such as web traffic originating from non-HTTP servers, is a clear indication, but even this simple example requires the need for three things that can be difficult to obtain. First, you need to understand your baseline, which in this case is which servers are indeed HTTP servers and how they typically behave. Second, you need a way to detect the abnormal behavior by analyzing the network traffic against that baseline. Finally, you need a way to deeply inspect that traffic to learn what it really is. The second step can be accomplished by looking at application flows for port 80, but the last step requires the use of a full application inspection tool.  You can’t rely on the packet headers anymore, because the covert activity is masquerading as HTTP traffic, and it’s using port 80 as a shield. That shield will allow it to pass easily through your firewall undetected.  Unless you decode the application session to see what’s happening inside, it will remain successfully hidden.

Once this level of monitoring is in place, the data can be used by security analysis tools with a much higher degree of success. Using event correlation, it is now possible to look for patterns of activity that could indicate a threat. Now that we’re inspecting the contents of application sessions, we can now detect some very complex behavior. In the diagram “Stages of Threat Detection Using Correlation” above, we see how basic event correlation can be used to determine the certainty and severity of an application-layer threat (in this case, a covert spambot operating over HTTP).

Instead of using the simplistic correlation rules of the last decade, which might indicate that “multiple failed logins followed by a successful login is a brute force attack,” we can create new “content aware” rules that can indicate “suspected inbound malware followed by abnormal application activity,” or even tiered correlation that looks for windows systems events, account changes, atypical connection attempts to internal resources, or other such activity that—on their own— would trigger massive amounts of false positives, but when taken as a whole can finally elevate our threat detection capability to where it needs to be.

But only by understanding our networks, our assets, and our applications—and by monitoring them fully within the context of clearly defined polices, can event correlation ascertain which application sessions are legitimate, and which ones could be potential covert communication channels in and out of your enterprise.

Eric Knapp is the director of critical infrastructure market at NitroSecurity.

Suggested articles