Botnet C&C servers issue commands in many ways
Recently I discussed botnets and the way they represent an ongoing and evolving threat to corporate IT security. This time I’ll be discussing the problem at its source — command and control (C&C) server detection — and the best practices available to help companies deal with it.
Lately, botnet creators and admins (“herders”) have become more sophisticated about how C&C commands are issued to malware-compromised workstations, but the most basic system works like this:
- One command and control server
- The C&C server communicates with a theoretically infinite botnet via IRC (Internet Relay Chat) commands
- The Command and control network then carries out scheduled activity (denial of service attacks, data theft, identity theft, etc.)
C&C structures are evolving, command & control server detection must evolve too
That list above looks simple, right? Well, today, botnet commands most often emerge from multiple servers, and take many forms — some, remarkably subtle. This of course makes command and control server detection remarkably difficult. Command and control malware activity routinely takes hidden forms such as:
- Tor network traffic. The Tor browser utilizes a special network of worldwide servers to deliver exceptionally private browsing that’s very hard to trace to its original source. Unfortunately, that same design makes botnet commands hard to trace.
- Peer to peer (P2P) services. Thanks to the distributed nature of P2P, commands are distributed globally, in unpredictable ways, by an ever-changing network.
- Social media. A public Facebook page or Twitter feed can be used to issue botnet commands — and that kind of traffic can be very hard to distinguish from genuine traffic.
- Domain generation algorithms. Today, herders use specialized algorithms to distribute botnet traffic so that it’s coming from random domains, effectively disguising the source.
- Multi-level command and control servers. Sometimes herders issue commands to server A, which issues them to server B, which issues them to the botnet. Even if server B is somehow blocked, A will keep working and can send them to a new server, C – mimicking the way scalable, highly stable enterprise software is architected.
Combine your tactics for command and control server detection
What to do? There’s no single best way to perform command and control server detection and handle botnets, but a combination of tactics can prove effective. Among others, I recommend:
- Track suspicious network activity. Beyond simply blocking IRC, admins can look for dubious outbound connection attempts in a much broader sense, and create/update service blacklists to deal with suspicious cases. Example: If a thousand users are all suddenly following a particular Twitter feed, and that feed’s content obviously isn’t meant for a human audience, that’s a clear sign of botnet activity.
- Tweak firewalls and intrusion prevention/detection (IPS/IDS) systems in context-specific ways. Many times, it’s possible to mitigate the problem for a given class of endpoint by limiting network access to the tasks/ports that are directly relevant to that endpoint. For instance, given a DNS server, you might consider blocking everything except UDP and TCP port 53. Also, for certain freeware IDS solutions such as Snort, there are downloadable rules that can help you automatically detect and block dubious activity on IRC and other ports, no matter where it originates on the network.
- Harden workstations against the initial malware infection that creates a bot. In addition to maintaining and upgrading basic antivirus solutions, administrators can run system integrity checks, minimize root privileges, and install client-side firewalls (especially effective if they support outbound packet rules, not just inbound). The fewer compromised machines you have, the less you need to worry about command and control server detection itself.
- Try to break down the malware code to see how it works. Not all IT professionals can do this, but even knowing and applying the basics can yield good results. For instance, it’s sometimes possible to find command and control server detection information by disassembling the compiled code or even just by using a sector analysis tool that converts hexadecimal to ASCII. (However, since herders are increasingly turning to integrated encryption, don’t expect this to work in every case.)
The idea should be to treat each of these approaches as a tool, and combine the tools as needed to yield a customized strategy that matches your local context and security requirements.
After command and control server detection, how to take them down
This, of course, is the best possible fix, but it’s no easy feat. Actually bringing down command and control networks, wherever they exist, will almost always require collaborating with law enforcement professionals to take action on a case-by-case basis. And it is extremely difficult to take down an entire command and control server list. Examples include:
- Working with a provider to remove/clean problematic servers or even confiscate specific physical hosts
- Revoking domain name service for exceptionally problematic domains
- Taking an entire hosting provider offline (this has happened in notorious cases such as McColo, a San Jose provider)
The bottom line is that while command and control server detection is hard and getting harder by the day, there are many steps IT professionals can take to mitigate and even eliminate the problem — up to and including getting law enforcement involved, if sufficient forensic evidence is provided.
Summary: Focus on your network activity, not command and control server detection
For the typical security professional, taking down a command and control server infrastructure is nearly impossible, and your time is honestly better spent elsewhere. Rely on trusted security solution providers to assist you in blacklisting known command and control networks with frequent updates to their command and control server list, and automating detection of suspicious activity inside your firewall. This frees you up to focus on preventing command & control malware infections and ensuring your endpoints are not being used in an attack on your infrastructure or on someone else’s.
