SECURITY WHITEPAPER

The Role of DNS in Botnet Command and Control (C&C)

DNS is powerful, ubiquitous and yet ignored by most organizations. Today, cybercriminals rely on DNS for rallying infected devices to join a botnet and to mitigate takedowns by authorities. In 2011, cybercriminals started covertly tunneling botnet communications over DNS traffic to mitigate detection by security solutions, despite security researchers widely publishing this threat in 2004!

QUESTION: What do you know about 101.cnc.com? ANSWER: Analyze logs... RESULT: Post-damage forensics

• Are any devices outside your network trying to resolve such domain hostnames through your network?

Stored on:

• DNS servers,

• Web servers, or

• Firewalls.

• Locates infected devices delegated to be proxies or name servers for botnet C&C.

• Are any devices within your network trying to resolve hostnames to that domain?

• Locates infected devices attempting to tunnel botnet C&C communications over DNS.

If you cannot answer the above questions, either because you don’t keep these logs, they’re not readily available, or you wouldn’t know how to analyze them, you’re likely blind to infected devices that have compromised your network by performing these botnet command and control (C&C) activities.

Botnet’s principal single point of failure and beacon to security researchers is its Internet-wide C&C architecture. From 2007-8, cybercriminals began building distributed or hybrid C&C topologies leveraging more advanced DNS-based C&C rallying mechanisms, such as third-party dynamic or its own distributed DNS services, to enable C&C communications to be redirected through its own distributed proxy service. Infected devices within insecure home or business networks host these services. DNS is used to add robustness and mobility to remove single points of failure within the architecture and provide anonymity for the cybercriminals running botnet C&C servers (see page 2). Fluxing domain names and/or the IP addresses in DNS records used by botnets makes them more difficult for the security community to take down or over.

Today, most botnets rely on a mix of P2P-, HTTP- or IRC-based protocols to communicate between bots and/or C&C servers. However, in late 2011, security researchers began publishing papers and blogs on botnets, such as “Morto”, “Feederbot” and “Katusha/Timestamper”, using a covert C&C communication method known as DNS tunneling to add stealth.1 DNS tunneling is not new; it existed since 1998 and the first implementation published by Slashdot in 2000. In 2004, Dan Kaminsky widely presented his implementation to tunnel arbitrary data over DNS to the security community, but lost their short-term attention as other exploited DNS vulnerabilities, such as DNS cache poisoning, became more prevalent. 2 Today, many popular DNS tunnels exist that are readily available for cybercriminals to

                                                                                                               1 http://bit.ly/Symantec_Morto, http://bit.ly/Dietrich_Feederbot, http://bit.ly/CHMag_Katusha 2 http://bit.ly/Kaminsky_DNStunneling

build botnets to bypass firewall filters or Web proxies.3 Ethical hackers have constructed a reverse shellcode exploit that could provide cybercriminals VPN and remote access into an insecure network using valid DNS syntax to avoid detection.4 Furthermore, with the future adoptions of DKIM, IPv6 and other extensions to the basic DNS protocol, big and complex packets within DNS traffic will become more common. Thereby assisting DNS-based botnet C&C communications to more easily and efficiently blend in since it’ll appear normal in DNS query streams (see page 2).

In the arms race between cybercriminal organizations and the security community, C&C techniques have become so robust, stealth and mobile that botnets are ubiquitous in both home and business networks despite so-called “next generation” security solutions’ best attempts to prevent all malware. The “defense-in-depth” strategy needs to migrate from adding prevention layers, to adding containment layers. DNS traffic is often examined after security incidents; for example, Google discovered the advanced and persistent “Aurora” botnet that breached its network by analyzing DNS logs after damage occurred. The most costly damage is no longer the lost time for IT to remediate infected devices, but the stolen data enclosing sensitive company or personal info for legal and regulatory bodies to resolve.

                                                                                                               3 http://bit.ly/NSTX_DNS, http://bit.ly/OzymanDNS, http://bit.ly/TCP-over-DNS, http://bit.ly/Iodine_DNS, http://bit.ly/Dns2tcp, http://bit.ly/DNScat, http://bit.ly/DeNiSe 4 http://bit.ly/Shellcode  

INFECTED DEVICE / INSECURE NETWORK

INFECTED DEVICE / SECURE NETWORK

UNINFECTED DEVICE / SECURE NETWORK

CONTAIN BOTNETS PREVENT MALWARE DETECT MALWARE

“DEFENSE-IN-DEPTH” STRATEGY MIGRATION

 

 

DNS-BASED RALLYING MECHANISMS HELP CYBERCRIMINALS STOP TAKEDOWNS BY REMOVING SINGLE POINTS OF FAILURE

! ! ! ! ! ! ! ! " ! " ! " ! " ! # ! # ! # ! # ! # ! # ! # !$ ! $ ! $ ! $ ! $ ! $ ! ! ! ! ! # ! # ! # ! # ! # ! # ! # ! # ! # ! # !

$ ! ! ! ! ! ! ! ! ! " ! " ! " ! " ! " ! " ! # ! # ! # ! # ! # ! # ! # ! # ! # ! # ! # ! # ! # ! # ! # !$ ! $ ! $ ! $ ! $ ! $ ! $ ! $ ! $ ! $ ! $ ! $ ! $ ! $ ! $ ! ! ! ! ! ! ! ! ! ! ! ! ! " ! " ! " ! " ! " ! " ! " ! # ! # ! # !

MALWARE (VIRUS, WORMS, TROJANS, ETC.) INFECTING DEVICES ARE ISOLATED

INFECTED DEVICES ARE CONNECTED TO FORM ROBOT NETWORKS (AKA. BOTNETS)

BOTNETS ARE UBIQITIOUS

1983

19

84

1985

19

86

1987

19

88

1989

19

90

1991

19

92

1993

19

94

1995

19

96

1997

1998

1999

2000

2001

2002

2003

2004

2005

2006

2007

2008

2009

2010

2011

2012

FUTU

RE

DNS IRC

HTTP P2P

Evolution of Botnet C&C IRC botnets pervasive

1st IRC-based botnet DNS tunneling

for cybercrime

Domain !ux

IP !ux (single) IP !ux (double) 1st fully DNS-

based botnets

1st HTTP-based botnets

1st prototype fully P2P-based botnet

DNS tunneling developed

Bots change host DNS settings IRC-based benign bot

IRC-based malicious bot

1st successful P2P-based botnets

1st hybrid P2P/HTTP-based botnets

1st Web site/service-based botnets

Web Services seed domain !ux crypto

DNS TUNNELING FOR COVERT C&C COMMUNICATIONS

NO PROXY

ONLY PORT 80/443

QUERY: where is 01010. cnc.tld?

QUERY: where is 11010. cnc.tld?

QUERY: where is 00110. cnc.tld?

RESPONSE: 00110.

cnc.tld is at 01110

RESPONSE: 01010.

cnc.tld is at 11011

RESPONSE: 11010.

cnc.tld is at 11100

LEAK DATA = 11010 + 01010

+ … 00110

11010 + 01010 + … 00110

= DATA STOLEN

01110 + 11011 + … 11100 = CONTROL

COMMAND = 01110 + 11011

+ … 11100

NO FILTER

ALLOW PORT 53

BASIC RESOLVERS

cnc.tld

NO SINKHOLE

C&C RALLYING MECHANISMS

QUERY: !ux.cnc.tld RESPONSE:

1.1.1.1

QUERY: HTTP GET RESPONSE:

C&C

1.1.1.1 2.2.2.2 ns1.cnc.tld ns2.cnc.tld

can be same bot

RESPONSE: 1.1.1.1

QUERY: !ux.cnc.tld

DYNAMIC & DISTRIBUTED

DNS SERVICES

DISTRIBUTED PROXY

SERVICES

QUERY: !ux.cnc.tld

DNS TRAFFIC REDIRECTED

HTTP TRAFFIC REDIRECTED

REFERRER: ns1.cnc.tld

DNS-BASED C&C COMMUNICATION HELPS AVOID DETECTION BY BLENDING IN

CENTRALIZED C&C TOPOLOGY

DISTRIBUTED C&C TOPOLOGY

HYBRID C&C TOPOLOGY*

(*one example)

 

 

The Past, Present and Future of Significant Botnet C&C Techniques

C&C Attributes Past Present Future

RALLYING MECHANISMS Centralized topology using static IP lists

Distributed or hybrid topology using domain flux and/or IP flux (via DNS records)

> Static Lists IP addresses Domain names and/or IP addresses

> Domain Flux > Seeding Predictable timestamp Dynamic content hidden on popular websites (e.g. Twitter trends) that can be customized in do-it-yourself kits

> Domain Flux > Crypto Static Frequently changing

> Domain Flux > Names Random characters Dictionary word combinations

> Domain Flux > Volume Hundreds of domains Tens of thousands of domains

> IP Flux > Records Single flux networks changing A resource records (first seen in the Storm/Peacomm botnets in 2007)

Double flux networks changing both A and NS resource records (first seen in the Asprov botnet in 2008)

> IP Flux > Service

Existing dynamic DNS services or “personalized” third-level domain (3LD) services. Alternatively, custom DNS servers on bulletproof hosts, which allows a cybercriminal to bypass the laws or contractual terms of service regulating Internet content and service use in its country of operation and are unlikely to cooperate with authorities.

As dynamic DNS services are taking a more aggressive stance against botnet abuse, and governments are cooperating quicker with the security community, cybercriminals are building their own distributed DNS services using multiple compromised hosts. Often these are initially bootstrapped via custom DNS servers on bulletproof hosts.

COMMUNICATION Centralized topology using IRC- or HTTP-based protocols

Distributed or hybrid topology using P2P-and/or HTTP-based protocols

Hybrid topology with protocol tunneling such as DNS traffic

> IRC > Client Common IRC client Cybercriminal’s custom IRC client

> HTTP > DIY Kits Paid do-it-yourself malware exploit kits (e.g. Mpack, ICEPack, Fiesta)

Paid or open-source do-it-yourself botnet kits (e.g. Zeus, SpyEye, TDSS)

> HTTP > Protocol Unencrypted Encrypted

> HTTP > Hosts Privately owned Web servers Public Web 2.0 services (e.g. Amazon Elastic Compute Cloud, Google App Engine) and social network sites (e.g. Twitter, Facebook, Google Groups)

> P2P > Port Non-standard port numbers used by P2P protocols

standard ports numbers used by common encrypted protocols (e.g. SSH, HTTPS)

> P2P > Protocol Unauthenticated Authenticated

> P2P > Discovery Centralized in cache servers Distribute hashed tables across the network

> DNS Not used Phone home, data exfiltration and/or bot instructions

Trickled, non-consecutive DNS queries over long time periods to further mitigate detection

 

 

C&C RALLYING MECHANISM DESCRIPTIONS

The rallying mechanism enables new bots to locate its peers or the C&C servers and join the botnet. While rallying can also be related to botnet recruitment and propagation, the following mechanisms are only for the purposes of networking the bots.

If the security community is 100% successful in shutting down or hijacking the rallying mechanisms, the botnet falls apart into a benign collection of discrete, unorganized infections. However, if even a few C&C servers remain alive, the botnet can adapt and reconfigure itself to be undetected or protected behind the virtual walls of international jurisdiction. Several movie analogies come to mind such as Terminator’s shape-shifting T-1000 series cyborg or Star Trek’s Borg collective; both these entities are very resilient unless the entire control mechanism is eliminated. Today, botnets use a hybrid of up to all three of the following techniques, where one may initiate the rallying, one maintains the rallying, and another backs up the rallying if the other one or two are disrupted. Static Lists

Early botnets primarily used hardcoded static lists of IP addresses or domain names. However, many firewalls can add an optional feed of known bad IP addresses to help mitigate this legacy technique and it is often not agile enough for today’s large botnet operations. While some compromised hosts will initially rely on static IPs to bootstrap communications with the botnet, they then switch to one of the following, more robust methods. For added mobility, cybercriminals used domain names with round-robin/multi-homing techniques to associate multiple IP addresses with a single DNS record or dynamic DNS services, but not abusing them via IP flux, which is described next. Domain Flux

The botnet uses cryptographically generated domain names by a Domain Generation Algorithm (DGA), which makes it more difficult for static reputation systems to maintain an accurate list of all possible C&C domains or for the security community to attempt to hijack the domain. Many cybercriminals register only a few of the possible generated domains at a time using dynamic DNS services. In limited recent cases such as the “Android bot”, URL Flux has been used, which is similar to domain flux in that the bot uses a list of usernames generated by a Username Generation Algorithm (UGA) from which it selects a username to visit on a Web 2.0 site.

IP Flux

Modern botnets primarily use one or more hard-coded domain names for DNS servers to resolve to many different IP addresses over a short span of time. This technique is also widely known as “Fast Flux” Service Networks (FFSN) as it’s also associated with spam and phishing attacks. However, the term “IP Flux” best describes the result of rapidly changing the location (i.e. IP address) to which the domain name of an Internet host (A) or authoritative name server (NS) resolves, caused by rapid and repeated changes to DNS records using very low time-to-live (TTL) cache settings. Relative to using IP lists, taking down malicious DNS records is often more difficult than compromised IP addresses because many records can be established for the same or many IP addresses.

These locations are actually a network of compromised hosts that act as front-end nodes to proxy DNS and C&C communication protocols to a group of backend C&C servers, commonly referred to as a “fast flux mothership” (see page 2). This second layer of abstraction further increases anonymity, security, high availability and load balancing of the botnet. It makes it nearly impossible to filter only by IP address, ASNs or geo-location and adds resiliency to takedown attempts as it shifts the centralizing agent of control from the C&C servers to the distributed DNS architecture. In many ways the idea is comparable to Content Delivery Networks (CDN). It has evolved and advanced since the The Honeynet Project Research Alliance first discovered its use.

The evolution for cybercriminals to use their own authoritative name servers has added greater robustness and mobility to IP Flux, and makes successful takedown more difficult for the security community. Alternatively, if the compromised devices are redirected to the cybercriminals own recursive DNS servers, bots are able to resolve domain names to different IP addresses relative to the rest of the Internet, so for example, if a security researcher or other network device tries to access the domain, it may appear to not exist. Also, it allows the bot to resolve well-known domain names (e.g. google.com) to C&C servers.

 

 

C&C COMMUNICATION DESCRIPTIONS Once the bots have joined the botnet, they regularly maintain communications to receive new commands, send back data to the C&C servers, such as sensitive company or personal information, or learn how to adapt itself in response to the security community’s efforts to disrupt or take down its operations. There are advantages and disadvantages as the following table explains.

Based on the communication topology, different push and pull control mechanisms will be used together with the communication protocol. Also, command authentication can be added to the communication protocol such as passwords or encryption certificates to help mitigate outsiders taking command over the botnet from the cybercriminals; especially with P2P-based protocols.

Centralized Topologies

All early botnets and still the majority of botnets today use centralized topologies via HTTP-based, IRC-based or other protocols because they are easier to setup and ensure that new commands are disseminated to large botnet populations quickly. However, centralized C&C servers are easier to detect and become a single point of failure for the botnet (see page 2).

Centralized Communications via IRC-based Protocols

Only one year after the IRC protocol was invented in 1988 programmers created the first bots to enable chat room (aka. channel) operators to log in, ensure the channel remained open, and to give them non-malicious control. At the turn of

the century, many first-generation cybercriminals were very familiar with IRC as a simple, synchronized and scalable means to chat between thousands of hosts so it was natural evolution to utilize it for the first C&C communications in 1999. Despite the advent of instant-messaging (IM) protocols such as ICQ, AIM, and MSN Messenger that gained popularity over IRC for the masses, many “old school” networking and security professionals still use IRC. In fact, the original C&C functionality of three evolved IRC-based bot families – Agobot, SDBot, and GTBot – still constitute a large percent of today’s botnet infections especially since some of the source code was published by its author, with occasional infections by variants of the DSNX, Q8, kaiten, and Perlbot IRC-based families. While almost the same in principal to IRC, there have been only a few botnets based on IM protocols due to the difficulty of creating individual IM accounts for each bot. Centralized Communications via HTTP-based Protocols

However, as the security community adapted to use network firewalls to block seldom used or unnecessary ports at the Internet gateway, cybercriminals realized that a more ubiquitous C&C protocol was needed to blend in with normal user traffic. Ports 80 and 443 used for unencrypted and encrypted Web traffic over HTTP/S is almost universally allowed through firewalls, and a few GET and POST requests used for C&C can easily be lost amongst the exponentially growing volume of legitimate Web traffic. HTTP-based botnets greatly accelerated with advances in do-it-yourself kits developed mainly by professional Russian cybercriminals to aspiring amateur cybercriminals, and in mid-2011 several botnet kits were leaked. Recently, public or social Web services have been gaining popularity as C&C hosts via obfuscated commands due to their added anonymity, openness and scalability. However, the security research community can also leverage this openness to quickly shut such botnets down. IDS/IPS solutions can often detect suspicious URI strings or nonstandard HTTP headers (e.g. Entity-Info, Magic-Number) used by botnets (e.g. Bredolab). Centralized Communications via Other Protocols

FTP isn‘t commonly seen in the wild; however, several phishing or banking Trojan horses regularly drops off stolen data to FTP servers. Some botnets use custom UDP-only protocols, which while easily blocked by business networks, often are able to bypass misconfigured firewalls.

Evolution Past Present

Topology Centralized Distributed or hybrid, yet many are still centralized

Protocols IRC or HTTP P2P

Setup Easy Hard

Detection Easy Hard

Communication Small delays Small to medium delays

Resiliency Bad Good

Anonymity Bad Good

Direction / Topology Centralized Distributed

Push IRC-based protocols DDoS & spam attacks

Pull HTTP-based protocols, IP Flux rallying mechanisms

P2P-based protocols

 

 

Distributed Topologies (via P2P-based protocols)

Peer-to-peer (P2P) communications were created to distribute file sharing (e.g. MP3s) amongst large populations. From 1999 to 2003, P2P topologies and protocols quickly evolved to add robustness, stealth and mobility from the recording industry’s and ISP’s attempts to disrupt communications and/or prosecute guilty individuals; exactly what cybercriminals also seek for their botnet C&C communications. Using structured P2P communications as a C&C topology was first envisioned as early as 2000, but the first botnets to use it appeared in 2003, the security research community began to publish its use in 2005, and it wasn’t until 2006 that they achieved some limited success. The bots are able to loosely communicate amongst its peers using the same or similar non-RFC TCP, UDP (used to bypass NAT situations) or encrypted ICMP protocols as many file sharing clients (see page 2). This topology offers the botnet better anonymity and resiliency without any single points of failure at the expense of higher setup overhead and communication latency. However, since the knowledge about participating peers is distributed throughout the botnet itself, which gives the security research community equal access to this information, cybercriminals evolved the standard P2P protocols to include proprietary authentications.

A future evolution for P2P-based botnet C&C would be to blend in with common encrypted P2P protocol traffic ubiquitously within business networks. Fortunately, only one protocol really exists today; Skype. Despite known malware instances using Skype plugins and its API, to the best of the security community’s knowledge, Skype-based botnets are still exclusively theoretical. In 2005, researchers presented an extremely distributed C&C topology using random, unstructured P2P communications broadcast to any other available peers. While one of the very first experimental P2P botnets in 2003 had used such a method, it was not successful, and no other botnets have since been reported to use this topology.

Overall, despite the advancements that cybercriminals have developed, some of the oldest botnet C&C communication techniques are still being used today due to their availability via open or leaked source code, or do-it-yourself kits. The table below provides a few data points published by the security community over the past few years.

Hybrid Topologies

Advanced hybrid, hierarchal C&C architectures combine the stealth from a few centralized C&C servers and robustness from distributed peers to prevent take down. For example, one group of bots act as servants since they behave as both clients and servers, which have static, non-private IP addresses and is accessible from the global Internet. The second group of bots only act as clients since they don’t accept incoming connections. The second group contains the remaining bots, including: (1) bots with dynamic IP addresses; (2) private IP addresses; or (3) bots behind firewalls such that they cannot be connected from the global Internet. Only servant bots are candidates in peer lists. Another example, is the Hierarchical Kademlia bot, which extends the base Kademlia bot. Each level in the hierarchy consists of a set of clusters or islands of bots. These clusters use Kademlia for intra-cluster communication. Each cluster has a super peer that is responsible for communicating with other super peers in the next level up in the hierarchy. The super peers thus facilitate inter-cluster communication (see page 2).

C&C Communications

Apr 2008 Arbor Networks

2008 Symantec

2009 Symantec

Q2 2010 Microsoft

2011 govcert.nl

Centralized / IRC 90% 44% 31% 38.2% 30%

Centralized / HTTP 4% 57% 69% 29.1%

70% Distributed / P2P 5% n/a n/a 2.3%

Other 1%` n/a n/a 30.5%

 

 

DNS-based Communications within Any Topology

Essentially, DNS records are abused to traffic data in and out of a network. Every type of record (NULL, TXT, SRV, MX, CNAME or A) can be used, but the speed of the connection differs by the amount of data that can be stored in a single record (see page 2).

The outbound phase starts with the bot on the compromised device requesting a response from the local host or network DNS server for a DNS query to [data].cnc-domain.tld. The data (base32-encoded) is split and placed in the third- and lower-level domain name labels of multiple queries. Since there will be no cached response on either local DNS server, the requests are forwarded to the ISP’s recursive DNS servers, which in turn will get responses from the cybercriminal’s authoritative name server.

For the inbound phase, TXT records can store the most data (base64-encoded) as typically suggested in DNS tunnel implementations up to 110 kbps, but may not be ideal for botnets to avoid detection by network devices since these are not common records. Unfortunately simply blocking TXT records as a defense method is insufficient, because it will break other protocols (e.g. SPF, DKIM) and alternative DNS records such as CNAME are common, and used in series, can still transmit detailed instructions for the compromised host to act on.

Alternatively, if two-way communication is not necessary, either the queries or responses can exclude the encoded outbound or inbound data, respectively. This would make the transfer more inconspicuous to avoid anomaly detection systems.

At present time, there are not many countermeasures cited by the security community that are “silver bullets” to detect DNS-based botnet C&C communications. While some larger, security-aware organizations could use techniques such as “split horizon” DNS to force internal hosts to send their DNS requests only through the network DNS server and then use statistical anomaly detection (aka. signatures) for this DNS traffic, there are unfortunately little to no readily-available signatures that are well tested to both guarantee protection and cause no false positives.

Notable Quote from Ed Skoudis, Founder of Counter Hack Challenges and SANS Fellow (Feb 2012) “Number of malware threats that receive instructions from attackers through DNS is expected to increase, and most companies are not currently scanning for such activity on their networks, security experts said at the RSA Conference 2012 on Tuesday. While most malware-generated traffic passing through most channels used for communicating with botnets (such as TCP, IRC, HTTP or Twitter feeds and Facebook walls) can be detected and blocked, it's not the case for DNS (Domain Name System) and attackers are taking advantage of that.” http://www.circleid.com/posts/malware_increasingly_uses_dns_as_command_and_control_channel/

 

 

Cloud-based Internet Security Trusted by millions around the world. The easiest way to prevent malware and phishing attacks, contain botnets, and make your Internet faster and more reliable.

OpenDNS, Inc. • www.opendns.com • 1.877.811.2367

Copyright © 2012 OpenDNS, Inc. All rights reserved worldwide. No part of this document may be reproduced by any means nor translated to any electronic medium without the written consent of OpenDNS, Inc. Information contained in this document is believed to be accurate and reliable, however, OpenDNS, Inc. assumes no responsibility for its use.

SWP-Botnets-V1-0612