journal of la dns for massive-scale command and...

JOURNAL OF LATEX CLASS FILES, VOL. 6, NO. 1, JANUARY 2007 1

DNS for Massive-Scale Command and ControlKui Xu Member, IEEE , Patrick Butler, Sudip Saha, Danfeng (Daphne) Yao Member, IEEE

Abstract—Attackers, in particular botnet controllers, use stealthy messaging systems to set up large-scale command and control. Inorder to systematically understand the potential capability of attackers, we investigate the feasibility of using domain name service(DNS) as a stealthy botnet command-and-control channel. We describe and quantitatively analyze several techniques that can beused to effectively hide malicious DNS activities at the network level. Our experimental evaluation makes use of a two-month-long4.6GB campus network dataset and 1 million domain names obtained from alexa.com. We conclude that the DNS-based stealthycommand-and-control channel (in particular the codeword mode) can be very powerful for attackers, showing the need for furtherresearch by defenders in this direction. The statistical analysis of DNS payload as a countermeasure has practical limitations inhibitingits large-scale deployment.

Index Terms—Network security, DNS security, botnet detection, and command and control.

F

1 INTRODUCTION

Botnet command and control (C&C) channel refers tothe protocol used by bots and botmaster (i.e., botnetcontroller) to communicate to each other, e.g., for botsto receive new attack commands and updates frombotmaster, or to submit stolen data. A C&C channel for abotnet needs to be reliable, redundant, non-centralized,and easily disguised as legitimate traffic. Many botnetoperators used the Internet Relay Chat protocol (IRC)or HTTP servers to pass information. Botnet operatorsconstantly explore new stealthy communication mech-anisms to evade detection. HTTP-based command andcontrol is difficult to distinguish from legitimate Webtraffic. The feasibility of email as a stealthy botnet com-mand and control protocol was studied by researchersin [29]. In this paper, we systematically investigate thefeasibility of solely using Domain Name System (DNS)queries for botnet command and control. DNS providesa distributed infrastructure for storing, updating, anddisseminating data that conveniently fits the need fora large-scale command and control system. The HTTPprotocol is for the end-to-end communication between aclient and a server. In comparison, DNS provides notonly a means of communication between computers,but also systematic mechanisms for naming, locating,distributing, and caching resources with fault tolerance.These features of DNS may be utilized to fulfill a moreeffective command-and-control system than what HTTPservers may provide.

• Xu, Butler, and Saha are currently Ph.D. candidates at Virginia TechDepartment of Computer Science.

• Yao is with the Department of Computer Science, Virginia Tech, BlacksburgVA 24060.Email: see http://www.cs.vt.edu/user/yao

The preliminary version of this work appeared in the 9th InternationalConference on Applied Cryptography and Network Security (ACNS ’11),Lecture Notes in Computer Science 6715, pages 238-254 [2]. This work wassupported in part by National Science Foundation grants CNS-0831186,CAREER CNS-0953638, ARO grant STIR-450080, and NSF S2ERC.

The decentralized nature of domain name systems(DNS) with a series of redundant servers potentiallyprovides an effective channel for covert communicationof a large distributed system, including botnets. To playthe devil’s advocate, we focus on systematically ana-lyzing the feasibility of a pure DNS-based command-and-control 1. Such a study has never been reportedin the literature. Our C&C system is compatible withexisting DNS infrastructure without enlisting any Webor special-purpose servers. The DNS channel is aided bybeing a high traffic channel such that data can be easilyhidden. As virtually anyone can create and register theirown domain names (if available) and DNS servers, it isa system that can be easily infiltrated by hackers andbotnet operators.

DNS tunneling is a technique known for transmit-ting arbitrary data via DNS protocol, e.g., DNScat andDeNiSe. One application of DNS tunneling is to bypassfirewalls, as both inbound and outbound DNS con-nections are usually allowed by organizational firewallrules. Because DNS is often overlooked in current secu-rity measures, it offers a command-and-control channelthat is unimpeded. Because nearly all traffic requiresDNS to translate domain names to IP addresses andback, simple firewall rules cannot easily be created with-out harming legitimate traffic. Recently, Dietrich andcolleagues reported Feederbot that used DNS as acommunication channel for C&C traffic [5]. However,Feederbot fails to utilize any distributed storage andquery mechanisms offered by DNS. This botnet simplytunnels its command and control traffic by sending it inDNS format for the end-to-end communication betweenbots and the bot master. The domains used by them arenot registered and cannot be resolved.

While using DNS tunneling for command and controlhas been observed [13], it was still unclear how effec-

1. Other C&C protocols (e.g., HTTP) also involve DNS queries forname translation, but they do not use DNS for command and control.


tive and feasible to use DNS to maintain stealthy largebotnets. Specifically, three items to consider in order toevade detection for attackers are

1) Query activities. When and how frequent do botsissue DNS queries to pull updates from or submitdata to the bot master? How to modify the victim’soperating system to implement automatic querystrategies?

2) Domain names. What domain names to use for com-munication and how to synchronize the generationof new domain names between bots and the botmaster?

3) DNS payload. How to evade the detection throughdeep packet inspection by defenders on DNS pay-load?

Our work systematic addresses these questions usingsystem engineering, networking, and data mining tech-niques. Our technical contributions are summarized asfollows.• We describe techniques for hiding query activities,

including i) piggybacking query strategy – a bot blendsits (outbound) DNS queries with legitimate DNSqueries and ii) exponentially distributed query strategy– a bot probabilistically distributes DNS queriesso that inter-arrival times follow an exponentialdistribution. We demonstrate the ability for a botto send piggybacking DNS traffic through trafficsniffing in Linux.

• For automatic domain flux, where the domainnames used for communications in the botnet arechanged frequently and in a synchronized fashionacross all bots and their controllers, we describea practical automatic domain flux method withMarkov chain, and experimentally evaluate it with1 million domain names from alexa.com.

• Statistical methods can be used by defenders todetect anomalies in the content of DNS packets,through comparing the probability distributions ofnormal DNS traffic and tunneling traffic. We evalu-ate these methods as countermeasures and point outthe practical limitations that hinder the large-scaledeployment by defenders.

We perform comprehensive experiments to evaluatethe behaviors of proposed query strategies in termsof how quickly new commands are disseminated to alarge number of bots. Our analysis utilizes a 4.6GB two-month-long wireless network trace obtained from anorganization. We conclude that the DNS-based botnetcommand-and-control channel is feasible, powerful, anddifficult to detect and block.

Organization We describe the basic DNS tunnelingmechanisms in Section 2. We present new strategiesfor improving the stealth of DNS-based command andcontrol in Section 3. Automatic domain flux is discussedin Section 4. We describe a countermeasure that requiresexamining the content of DNS packets and performingstatistical analysis in Section 5. Related work is given in

Section 6. Conclusions and open problems are given inSection 7.

2 COMMUNICATION MODES

In this section, we describe protocols that pass mes-sages over the DNS between distributed entities, andillustrate the ease of setting up large-scale command-and-control via DNS. We describe two forms of com-munication modes: codeword mode and tunneled mode.Codeword communication allows one-way communicationfrom botmaster to a bot client, which is suitable forissuing attack commands. Tunneled communication allowsfor the transmitting of arbitrary data in both directionsbetween bot and botmaster, which may be used for bothissuing commands and collecting stolen data. The formeronly requires the ability to set a particular domain nameresponse, this could be done via any free DNS service,while the latter requires setting up an authoritativedomain server.

The controller of the botnet first needs to create adomain or subdomain, which is administered from aspecial DNS server. This DNS server waits for specialname lookups, which it then translates into incomingdata. The DNS server then responds with the appropri-ate data using the agreed-upon semantics. We assumethat the botnet controller (i.e., botmaster) has access tothe authoritative domain name server for some domainsor sub-domains. Bots across the Internet frequently re-ceive commands and updates from a botmaster andlaunch attacks accordingly, as well as submit stolen datato the botmaster. We give brief background informationon DNS records.

DNS Resources Records The DNS system allows aname server administrator to associate different types ofdata with either a fully qualified domain name or an IPaddress. To send a message to a bot, an adversary canstore data in any one of these types of records.• A record specifies an IP address for a given host

name.• CNAME and MX records can point to textual data

representing the alias or mailing host of a particularhost name.

• TXT records are designed to store arbitrary textualdata up to 255 characters.

• EDNS0 record allows storing up to a 1280 bytepayload [24]. EDNS0 was introduced in RFC261 inorder to extend the DNS protocol. When a capableserver or client encounters this field, it can decodethe packets, allowing several improvements to thebasic DNS protocol. These features include largerUDP packet size, a list of attribute value pairs, andseveral extra bytes for commonly used flags.

2.1 Codeword Mode

The codeword mode is a stealthy communication mech-anism. It requires a botnet operator to decide upon a


set of agreed upon codewords a priori. Each codewordrepresents a specific type of commands or attacks. Thecodeword appears in the DNS query as an innocenthostname, for example codeword.domain.com. Thishostname may be stored as any type of record (e.g.A, MX, CNAME). A request for an A or CNAME recordtends to be the most common and therefore a preferenceshould be given to these records types so that querieswould appear most like legitimate traffic. The clientqueries codeword.domain.com, and waits for a partic-ular value in the server’s response. Upon receiving thequery, the DNS server (controlled by the botnet operator)returns the pre-set response that contains commandinformation. If the codeword corresponds to denial-of-service (DoS) attacks, then the response may representa target of DoS attacks. If the codeword corresponds toupdate, the client may contact the IP address returnedfor updated code or other instructions.

It is important to note that the codeword can be chosenarbitrarily and does not need to correspond to a specifichost or service. The codeword method allows a stealthyone-way commanding system. It can effectively evadedetection approaches based on non-conforming packetsizes [13], i.e., DNS packets whose sizes are outside therange of [28, 300] bytes. Codewords may be arbitrarilygenerated, or may be common service names such aswww, mail, or ftp. In the latter case, packet statisticscannot be performed to find anomalies.

2.2 Tunneled ModeThe purpose of tunneled mode is to allow the two-waytransfer of arbitrary binary data between a server and aclient. This mode is referred to as tunneled mode, as onecan tunnel streaming data over this DNS communicationmethod.• Upstream communication is for a client to submit data

to a (malicious) domain server. The client submitsthe data as a CNAME query by i) encoding the datausing a base32 encoding, ii) using the encoded stringto construct a host name, and iii) send a CNAME DNSquery. An example is shown in Figure 1.

• Downstream communication is for the server to issuecommands to clients. Upon receiving the abovequery from the client on a hostname h, the serveri) encodes the response as base32 data, and ii)constructs and returns a CNAME record for h. Anexample is shown in Figure 1.

To prevent DNS caching from disrupting the commu-nications, the server may set a short time-to-live (TTL).This tunneling method gives an operator the most op-tions after implementation as the data stream can bearbitrary. Because of the arbitrary payload, the distri-bution of packet bytes may differ significantly fromconventionally DNS payload. We perform more analysisin Section 5.

DNS protocol does not allow the server to initiate aconnection with the client, the client needs to contin-ually pull updates from the server. Both the tunneled

• Upstream: Ask CNAME for:NBSWY3DPFQQHO33SNRSA000.domain.com

• Downstream: CNAME points to:NBUSYIDCN5ZXG000.domain.com3600CNAMENBSWY3DPFQQHO33SNRSA000.domain.com

Fig. 1. Example data packets sent to and from a server intunneled mode: To server: “hello, world”. From server: “hi,boss”. In this example, the domain server for domain.comis the malicious server and the response has one hourTTL.

mode and codeword mode require clients to frequentlypull updates from name servers by querying the cor-responding botnet’s domain. Straightforward queryingpatterns are easy to detect (e.g., periodically sendingDNS queries) and susceptible to simple aggregate anal-ysis, such as counting DNS queries for each uniquedomains and identifying domains with abnormally largequery volume at the host, local area network, or internetservice provider levels. We analyze several simple-yet-effective methods for bots to hide their DNS traffic inthe next section.

Were DNSSEC to become widespread it would pro-vide both an advantage to, as well as a disadvantage to, apotential attacker. In the attacker’s favor is the increasedusage of DNS over TCP and the extra packet size andreliability provided. In return, the attacker would loseeasy access to many protected name servers that mighthave otherwise been compromised. However, given thatan attacker can legally purchase their own domains andthat some DNS operators place their signing keys on theDNS itself, it is unclear how much protection DNSSECwould offer for stopping DNS based C&C channels.

3 QUERY STRATEGIES AND QUANTITATIVEEVALUATION

In this section, we play the devil’s advocate and de-scribe and experimentally evaluate new techniques forhiding DNS query activities on a host, in order todefeat anomaly detection that targets abnormal temporalpatterns. The proposed strategies are useful for boththe tunneling and codeword modes. We quantitativelyanalyze the detection countermeasures in Section 5.

3.1 Exponentially Distributed Query and Piggyback-ing QueryWe describe an exponentially distributed query strategyand a piggybacking query strategy, both can be used tohide bot activities while communicating with a botmas-ter in a timely fashion. In our experiments in Section 3.2,we provide an experimental evaluation on both querymethods.

Exponentially distributed query strategy The Poisson pro-cess is previously believed to be a suitable model for


representing stochastic processes where arrivals are in-dependent on each other, i.e., memoryless. In [23], client-side DNS request arrivals are modeled by Poisson pro-cesses with exponential random variables with differentrates λ (e.g., 2.63 queries/hour for www.google.com and0.78 queries/hour for www.cnn.com). In our exponen-tially distributed query strategy, a bot probabilisticallydistributes DNS queries so that their intervals followan exponential distribution with a parameterized arrivalrate λb. Because of the memoryless feature of the model,the bot does not need to store the previous communi-cation history. One simple way to implement this querystrategy is as follows.

1) The bot sends a DNS query;2) It computes an interval t by drawing from an expo-

nential distribution with parameter λb (hardcodedor dynamically generated);

3) The bot sleeps for t, and repeats from Step 1.There is a trade-off between being stealthy and com-

munication efficiency. We study a bot’s strategy in find-ing an optimal λb in Section 3.2, given the host-wideDNS query rates.

Piggybacking query strategy Many (legitimate) websitescontain content from multiple independent domainsdue to third-party content delivery, advertisements, orcontent mashup. Therefore, multiple DNS queries areusually issued by a host with temporal proximity. Thecomposition of domains is usually dynamic. The pig-gybacking query strategy leverages this fact. A botpassively listens on the host’s DNS traffic or name-translation related function calls and sends DNS querieswhen legitimate DNS queries are being made. Thus, thebot’s query is blended among a group of legitimate DNSqueries.

In the piggybacking query strategy, a bot’s communi-cation with the controller is constrained by the host’s ac-tivities. Therefore, we focus on analyzing its timeliness,in terms of the dissemination efficiency of new commandand data. We define time-to-communicate (TTC), minimumTTC , and maximum TTC. Minimum TTC is a thresh-old aiming to prevent a bot from sending queries toofrequently, whereas maximum TTC is a threshold forkeeping the liveliness of the communication between thebot and the bot master in case of an inactive host.

Definition 1: Time-to-communicate (TTC) is defined asthe time interval between two network connections(DNS queries in our setting) of a bot for retrievinginformation from or submitting data to the botmasterserver.

Definition 2: Minimum TTC (e.g., min-TTC) is thelower bound of time-to-communicate, whereas maxi-mum TTC (e.g., max-TTC) is the upper bound of time-to-communicate. Let t and t′ be the timestamps of twoadjacent DNS queries that the bot sends. Then, t and t′

need to satisfy the following constraints.

min-TTC ≤| t− t′ |≤ max-TTC

In other words, a bot does not send any DNS query, if thebot’s previous DNS query was sent within the minimumTTC. At time t, a bot needs to send a DNS query to checkfor update from the bot master, if the interval betweent and the time when the bot sends the previous DNSquery equals the maximum TTC. These two parametersput constraints on the bot’s query frequency.

In this piggybacking mode, bots need to know whena legitimate DNS query is made. There are differentapproaches for obtaining this information.

1) Traffic sniffing. Because DNS server runs on port53, an outgoing packet from the host (client) toa destination IP on port 53 is an indication ofan outbound DNS request. The bot may sniff thenetwork traffic to identify the right moment toissue its DNS queries. The bot may either directlyprogram with pcap library or call existing toolssuch as iftop (in Linux), which uses pcap. Thisapproach gives a cross-platform and system-widemonitoring solution, which covers the DNS queriesfrom any application.We have implemented this approach in Linux. Withthe pcap library, the traffic sniffing is relativelystraightforward to realize with a small piece ofcode. We attach the code to host machine’s networkdevices, which usually requires root privilege. Inthe code, function pcap findalldevs() returns allavailable network devices, pcap open live() opensa network device, and pcap loop() performs thetraffic sniffing. The program needs root privilegeto run. It filters all TCP and UDP packets, bothof which are possible protocols for carrying DNSrequests, and reports the timestamps whenever aDNS request is identified. It also distinguishes thebot’s own DNS query from legitimate ones, so thatpiggybacking is only performed on legitimate DNSqueries. This prototype demonstrates a feasibleway for our proposed piggybacking query strategy.

2) Process hooking. Another approach is to hook DNS-related function. In Linux, bots can watch thecalls for DNS-related APIs such as gethostbyname()function in libbind library. gethostbyname looks upall IP addresses associated with a host name andis implemented in the resolver library. One way ofhooking into the API function is for bots to registera .so file (shared library) to the LD PRELOADenvironmental variable, which may or may notrequire root. In the registered .so file, the target APIfunction is replaced by the attacker’s version whichcan notify the bot whenever this function is called.Similarly, in Windows [11] gives a solution, Detour,which has the ability to perform function intercep-tion and rewriting. Compared with traffic sniffingapproach above, this method is less desirable, asit is process-specific. The hooking is done in theprocess memory. The original shared library is notchanged, which is different from approach 3 below.


3) Rogue library. Alternatively, attackers may replacethe network related shared libraries in the OS withan instrumented version (requiring root), so thatthe shared library is changed permanently on thehard disk. The rogue library is loaded by anyapplication. It reports every DNS request to thebot. This approach is system wide, so the changeis once-and-for-all.

3.2 Experimental Evaluation

The goal of this evaluation is to understand how effectivethe aforementioned stealthy query strategies are. Specif-ically, how soon botmaster disseminates commands toall or most bots; and how soon stolen data is harvestedbots by botmaster? We do not allow bots to submit DNSqueries at will, in order to avoid detection. We only allowbots to either piggyback their queries with legitimateDNS queries from the victim host, or follow a specialinter-query distribution.

Our implementation uses the Python Modular DNSServer (pymds) and a specially designed plugin to re-spond to DNS requests. PyMDS implements the fullDNS protocol while allowing the user to implementa programmatic and dynamic backend to generate theDNS records returned. Instead of returning records froma static file, PyMDS allowed for the decoding of code-words and the creation of appropriate responses.

To evaluate the piggyback query strategy, our datasetis a two-month-long network trace obtained from auniversity and collected with the IPAudit tool. The tracecovered users from three departments and several re-search and education centers. (All machines were con-nected to the Internet wirelessly, i.e., there was no wiredconnection.) The raw dataset is 4.6GB. We identify andanalyze the DNS traffic on port 53 of remote destinations.For data preprocessing, we select the most active 200users from the our dataset by partitioning users bytheir (static) MAC address and sorting users by theirtraffic volume. We simulate the piggyback DNS-querystrategy by having a bot send outbound communicationwhenever a host issues a UDP datagram on remote hostport 53. Figure 2 shows the percentage of packets whoseTTC is above the given minimum TTC in a 10-hour-span.Three minimum TTC values are analyzed: 1, 30, and 60minutes.

Results in Figure 2 show that the piggybacking querystrategy is quite effective – at least 80% of bots are able tocommunicate with the botmaster within 2 hours. Clearly,there is a trade-off between minimum TTC and howsoon bots communicate with the headquarter. For anactive botnet where commands may change every day,minimum TTC may be set to 60 minutes.

Piggybacking case studies We select four hosts fromour dataset to simulate the piggybacking behaviors onthem and evaluate the mean time-to-communicate. Thefour hosts are the first, 50-th, 100-th, and 200-th mostactive hosts according to their total traffic volume during

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 2 4 6 8 10

Per

cent

Com

mun

icat

ed

Actual Time to Communicate (Hours)

1 Minute30 Minutes60 Minutes

Fig. 2. Cumulative density function on the percentage ofbots that have successfully sent at least one DNS queryby piggybacking after a time period (X-axis). Each linecorresponds to a different minimum TTC (1, 30, and 60minutes). The figure shows a 10-hour span.

Minimum Time to Communica.on (in hours)

Actual M

ean Time to Com

mun

icate (in

hou

rs)

Fig. 3. Case studies on the time-to-communicate for fourhosts with varying active traffic volume, given minimumTTC values shown on X-axis.

the 2-month period. Figure 3 plots how the mean TTCchanges with the minimum TTC in a piggybackingquery strategy, with the maximum TTC set to infinity.The results show that bot’s communication efficiency ishigher on more active hosts as expected. A maximumTTC (e.g., 48 hours) may be set to ensure periodiccommunication of the bot. Mean time-to-communicategrows with minimum TTC and is almost always greaterthan minimum TTC. The relationships for the studiedare shown in Figure 4.

For the exponentially distributed query strategy, our goalis to identify an optimal range for λb – bot’s query arrivalrate on a host. We analyze the difference between twodistributions: i) host-wide inter-arrival time for regularDNS queries with arrival rate λ, and ii) inter-arrival timefor the bot-mixed DNS queries, i.e., new arrival rate λ+λb, where λb is the bot’s query rate.

We use Kolmogorov-Smirnov (KS) test, which is suit-able for comparing unbinned distributions that are func-


Minimum Time to Communica.on (in hours)

Actual M

ean Time to Com

mun

icate (in

hou

rs)

Fig. 4. Mean TTC vs. minimum TTC for 200 hosts.

tions of a single independent variable as in our case [8].In our KS test, a higher p value ([0, 1]) represents ahigher resemblance between the normal and the bot-mixed distributions. To simulate the Poisson process, weuse two estimated λ values – high arrival rate of 131.5queries/hour and low arrival rate of 39 queries/hour –based on results from [23].

Intuitively, a higher legitimate DNS query rate makesit easier for a bot to blend in its traffic. Our results inFigure 5 and Figure 6 confirm the intuition. High rateλ = 131.5 is shown in Figure 5, and low rate λ = 39 inFigure 6, where each line represents a different amountof data collected: 10, 24, 48, and 100 hours. X-axis is thevarying λb value. The horizontal line represents a 5% cut-off threshold that may be used for detecting anomalies.

Our results show that longer traces make it easierfor defenders to discern data. Higher λ tolerates higherλb, allowing bots to communicate more often. Given ap value threshold, the KS test can be used to find asuitable λb. The experiments show that even when datais collected for long periods of time, such as 100 hours,it can be difficult to detect bots using a small λb. In thecase of less active hosts, λb can be come undetectable at4 requests per hour, and with more active hosts λb canbe as high as 10 requests per hour.

For the defender to run the KS test on DNS logs foranomaly detection as shown above, one may need tocollect logs from the suspicious host for a substantialamount of time (e.g., 100 hours). This procedure may beperformed periodically or as needed. The logs may bediscarded after the test. To save space, the informationto be logged by the defender can be represented as avector of timestamps when DNS queries are observed.

Summary The experiments suggest that both the piggy-backing and exponentially-distributed query strategiescan be effective in allowing the majority of bots tocommunicate in a reasonable time frame without beingdetected. The exponentially-distributed query strategygives the bot slightly more control over when to query.On the other hand, the optimal query rate λb dependson the host-wide query rate, which may change.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40 50

P-Va

lue

of K

S-Te

st

DNS Requests per Hour b

%5 Cutoff48 Hours

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40 50

P-Va

lue

of K

S-Te

st


%5 Cutoff10 Hours

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40 50

P-Va

lue

of K

S-Te

st


%5 Cutoff24 Hours

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40 50

P-Va

lue

of K

S-Te

st


%5 Cutoff100 Hours

(a) 10 hours (b) 24 hours

(c) 48 hours (d) 100 hours

Fig. 5. KS test results between queries with the arrivalrate of λ = 131.5 queries/hour and bot-mixed queries ofλ + λb (X-axis). Four runs of simulation lasting for 10,24, 48, and 100 hours are shown in (a), (b), (c), and (d),respectively.

(a) 10 hours (b) 24 hours

(c) 48 hours (d) 100 hours

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40 50

P-Va

lue

of K

S-Te

st


%5 Cutoff10 Hours

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0 10 20 30 40 50

P-Va

lue

of K

S-Te

st


%5 Cutoff24 Hours

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0 10 20 30 40 50

P-Va

lue

of K

S-Te

st


%5 Cutoff48 Hours

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40 50

P-Va

lue

of K

S-Te

st


%5 Cutoff100 Hours

Fig. 6. KS test results between queries with the arrivalrate of λ = 39 queries/hour and bot-mixed queries withλ + λb (X-axis). Four runs of simulation lasting for 10,24, 48, and 100 hours are shown in (a), (b), (c), and (d),respectively.

4 DOMAIN NAMES

Long-lived domain names are easy to manage andcheaper to maintain, however, they are susceptible toaggregate analysis. Domain flux refers to using short-lived domain names in botnet C&C [20]. Domain fluxtypically requires bots and botnet controller to indepen-dently derive new domain names periodically. In thenext section, we play the devil’s advocate and describemethods that a botnet controller may use to generatedomain names for domain flux. In Section 4.2, otherpractical issues including subdomain names and domainregistration are discussed.


4.1 Domain Name Generation With Markov Model

To have short-lived domains, a static approach is tohave a botmaster generate an ordered list of domainnames and pack the list in malware code for bot tolook up, which is similar to the use of a one-timepassword pad for authentication. However, there are twodisadvantages for this method: large storage and highcode-homogeneity – long lists of domain names sharedby all bot code making the code susceptible to signature-based malware detection. Having the botmaster sends toall bots the next domain name during the current epochis not an acceptable solution, because a communicationfailure may prevent the bots from learning the correctname for the next epoch.

One simple approach is for bots and their controllerto independently compute the hash value of an in-cremental counter and a shared secret at each epoch,i.e., H(counter‖secret), where H is a one-way collision-resistant hash function. For example, the bot and bot-master may share a secret, which is concatenated withthe current epoch, e.g., current date, to derive a hashvalue for short-lived domain names, e.g., H(s, current-date). The clocks on all bots and the bot master haveto be synchronized, especially when the epoch is short.This timestamp-based domain-generation algorithm wasobserved in several botnets such as Torpig [31] and Con-ficker worm [21], [22]. An alternative domain-generationmechanism is based on the Lamport one-time passwordauthentication scheme [15]. Technical issues associatedwith hash-based domain names such as domain length,collusion and unavailability of domain names can beeasily dealt with and are omitted.

We describe a useful technique that a botnet controllermay use for automatically generating realistic-lookingdomain names, which is more sophisticated than the pre-vious hash-chain based method. We utilize techniquesfor automatic text generation, such as the ones used bySCIgen [25].

In automatic text generation or in applications suchas finding genes similar to a pool of genes, MarkovChain models are often successfully used. Markov chainmodel makes use of the probabilities with which oneentity follows another. We use the same Markov chainmodel to model letter transitions in domain names. Weuse 1 million top visited domain names from alexa.comcollected on May 25, 2010 to generate the transitionprobabilities and thereby the Markov chain of 37 char-acters (26 alphabets, 10 digits, 1 hyphen - that occur indomain names). To make the length of the generateddomain names to be consistent with legitimate ones(in terms of their probability distributions), we takethe length from the legitimate length distribution. Thelength distribution of 1 million domain name is shownin Figure 7.

Given the Markov chain (MC) models and the lengthdistribution, new domain names can be generated. Weshow some of them along with some hash based domain

Fig. 7. Length distribution of 1 million legitimate domainnames, domain index on x axis, number of domains at yaxis.

names in Table 1. Hash based names look random,and have digits. MC-based names have English wordpatterns in the names.

Fig. 8. A Markov chain example for a simple model withfive characters in the alphabet - a,b,c,1,2.

Figure 4.1 shows a simple Markov chain(MC) for onlyfive characters – a, b, c, 1, and 2. Any generated domainname of a given length corresponds to a random walkof that length in this chain.

The domain generation has to be independent, con-sistent, and synchronized. These can be achieved in thisMC-based approach by using the same random numbergenerator and the same initial seed. Generators likelinear congruential generator may be used in this respect.The botmaster has to communicate with the bots thefollowing items:• the Markov probabilities for state transitions,• parameters for random number generator,• parameters for the initial seed and timing interval.We compute the cosine similarity between MC-based

domains and 5,000 legitimate domains. We also applythe same metric to new legitimate domains with respectto the same 5,000 domains, in order to compare the qual-ity of MC-based domain names. The cosine similarity is


# Markov chain based Hash based1 x-airnarienghy 93mp3com2 islegawhosh qqdgdcom3 cnewallonderc 58qqcomcn4 yasesaug juegos666com5 veadgeupot c8048com6 iga-ngakhodo yishu666info7 yarchma xinwen666com8 ialeparteb z6zzcom9 beatersashinehu nr33com10 iyerishopes 210766518811 nollanguilcw9xb wwwli

TABLE 1Comparison of domain names generated by hash

function (right) and Markov chain (left).

defined in the following manner. Each domain name isrepresented as a vector X = [X1X2...X37]

T of 37 features;the feature set includes 26 letters in the alphabet, 10digits and the character ’-’. The cosine similarity Sbetween two domain names A and B, represented asvectors, is defined as,

S(A,B) =

∑37i=1Ai ×Bi√∑37

i=1A2i ×

√∑37i=1B

2i

(1)

To compute the similarity of a particular domainname, DomX to the available 5000 legitimate domainnames DomL1, DomL2, ..., DomL5000, we take the aver-age of the individual cosine similarities between DomXand DomLi. We compare the quality of a MC based do-main name and a legitimate domain name with respectto their similarity to the list of 5000 most visited domainnames. The results are shown in Figure 9. We observethat the MC-based domains and legitimate domainshave comparable similarity values.

Fig. 9. Cosine similarities between the 5,000 most visiteddomains and 100 Markov chain generated domains (bluechecks) vs. 1,000 legitimate domains (red dots), respec-tively.

We also measure the cosine similarity for hash-baseddomain names. Figure 10 shows the distinction betweenMarkov chain generated names and hash generatednames. Clearly, MC generated names have a highersimilarity to legitimate domain names than their hashalternatives.

Fig. 10. Cosine Similarity to 5,000 most visited domainsfor 100 Markov chain generated domains (blue checks)vs. 100 hash generated domains (red dots), respectively.

Markov-chain based domain names achieve an aver-age cosine similarity of 0.138 which is very close to thesimilarity of legitimate names evaluated. This value ismuch higher than the similarity of 0.036 achieved byhash generated domains under the same experimentalcondition. This observation indicates that it is possibleto generate near-realistic looking domain names thatclosely follow legitimate byte distribution.

Detection approaches From a defender’s perspective,distinguishing bot-generated domains from legitimateones may not give accurate results, as indicated by theabove analysis. However, other approaches might bepotentially effective. Bots and botmaster need to share aset of parameters (e.g., state transition probabilities, ran-dom number generator), so that they can autonomouslygenerate domain names without communicating witheach other. Patterns in the shared data and code may beextracted and utilized to create signatures for detection.This predictability is a disadvantage of the Markov chainapproach.

4.2 Subdomains and Domain Registration

Botnets have been observed to use subdirectories forcommunication, e.g., www.example.com/products,www.example.com/home. However, for a DNS-tunneling based channel, subdirectory approach doesnot apply, as the botmaster does not run a Web serverand the communication is based solely on domain namesystems. Consider that botnets often use third-leveldomains instead of subdirectories, Dagon proposed touse the ratio between second-level domains (SLD) andthird-level domains (3LD) to identify botnet traffic [3].

When using short-lived domain names, the botmasterneeds to consider whether to use the generated string forsecond-level or third-level domain name. Using it as 3LDmakes it easy for botmaster to update the DNS recordsof a domain, which is static and long-lived. However,it may be detected by the ratio-based method men-tioned above. Using short-lived SLDs (e.g., 1a735009.com,635b5790.net,9e30f817.org) would likely render theratio-based detection ineffective. Its downside might bethat the SLD may not always be available, although


automatically generated domains may be less likely tocollide with existing domains.

From the attacker’s point of view, while generating re-alistic looking domain names, it is reasonable to generateonly the SLD’s and pick some TLD suitably or randomly.Compared to millions of SLD’s, the list of TLD’s is verysmall. However, the SLD and TLD names are not entirelyindependent; the character-pair distribution of the SLD’smay vary, particularly when the TLD includes countrycodes (ccTLD). For example, there are many words (inpinyin 2) from Chinese language in SLD’s with .cnTLD; the character-pair probabilistic distribution of theseSLD’s should be different from the general character-pairdistribution of SLD’s. The attacker can make use of thisdependency to generate more realistic looking domainnames. E.g., the attacker can construct an MC basedon Chinese character-pair distribution only to generateChinese word based SLD’s for .cn TLD, or an MC basedon Arabic character-pair distribution to generate SLD’sfor .om TLD (for Oman).

We expect botnet controllers to create and register thedomains to be used, which allows them to take advan-tage of the existing and decentralized DNS infrastructurefor scalability, fault tolerance, and storage 3. In orderto register a new second level domain associated witha top level domain (such as .com), a registrant (e.g.,a botnet controller) needs to apply to a domain nameregistrar and pay the (annual) fees. The botnet controllersmay specify their own IP addresses of authoritativename servers to host the domain’s resource records.This approach gives them the flexibility in managingthe command and control operations and customizingthe DNS traffic. There is monetary cost associated withregistering a new second level domain name. A botnetcontroller may create new third level domains (3LD)with a fixed SLD. Sites like dyndns.org make it easy tocreate lots of domains of the form x.dyndns.org. Fordefenders, it is difficult to block SLD domains such asdyndns.org because legitimate sites use them as well.

5 DEEP PACKET INSPECTION

In this section, we describe and experimentally evaluatea countermeasure against DNS-based stealthy messagingsystems that requires deep packet inspection and statis-tical analysis. Deep packet inspection examines packetpayload beyond the packet header. Specifically, we quan-titatively analyze the probability distributions of (bot’s)DNS-packet content.

We describe and evaluate a concrete countermeasureagainst stealthy DNS channels through statistically ana-lyzing traffic content. To compute the byte distributionin normal and tunneling traces, we use the Jensen-Shannon (JS) Divergence DJS , which is a common metricfor quantifying the difference between two probability

2. Pinyin is for entering Chinese characters into computers.3. In contrast, domains used by Feederbot cannot be resolved by

public resolvers [5], as they were not registered.

distributions P and Q, and is a commutative versionof Kullback-Leibler divergence of Q from P . A lowerDJS value means a higher similarity in two probabilitydistributions. The JS Divergence is particularly suited insituations where the random variable is discretized.

M =1

2(P +Q) (2)

DKL(P,Q) =

n∑i=0

pi logpiqi

(3)

DJS =1

2(DKL(P,M) +DKL(Q,M)) (4)

We experimentally compare DNS packet tracesrecorded on a host, specifically, on how different tun-neling packets are from legitimate ones in terms ofthe probability distribution of content. Such probabilitymeasures may be taken on a per-host or per subnet basis,however since a filter based on these methods must onlykeep an probability distribution of the bytes in a packet,no identifying information can be inferred. In this wayprivacy concerns can be kept at a minimum.

In the following tests, three normal DNS traces wererecorded and one tunneling DNS trace via tunneledmode was recorded. Each trace corresponds to an hour-long network activities on a host. Sizes of our traces are862KB for the tunneling trace, 823KB for normal trace 1,699KB for normal trace 2, and 153KB for normal trace 3.In addition, the tunnel trace contained 191 A queries and1433 TXT queries, while the normal trace 1 contained1750 A queries and no TXT queries, and normal trace 2contained 2417 A queries and no TXT queries. Tunnelingtrace contains encrypted Secure Shell (SSH) activities,i.e., SSH traffic through DNS tunneling. DNS or DNSSECdoes not provide query confidentiality, i.e., the DNSquery payload is not required to be encrypted.

When the entire packet including header is analyzed,we find that the divergence of normal traces (normal1 and normal 3) is large (not shown). To get a morestable comparison, we drop the UDP headers and onlyobserve the DNS payload. Figure 11 shows how theJensen-Shannon divergence changes as more tunnelingmessage carrying packets are mixed in. The X-axis is theratio of tunnel trace to normal trace 1.

Our results show that in our experiments a divergencethreshold of 0.015 can sufficiently distinguish normaltraces from mixed traces containing more than 30% botqueries. These results indicate that analyzing DNS pay-load as a countermeasure is more effective than analyz-ing the entire DNS datagram with JS divergence. WhileDNSSEC does not specifically require DNS over TCP, itis commonplace because DNSSEC adds to the length ofDNS packets and many deployed systems cannot handlethese larger UDP packets. Therefore the data collectionmust be done with consideration to the TCP protocol.The TCP protocol has a number of bytes that iterate andchange over each packet, so the defender must take extracare to only analyze the DNS payload and not the TCP


0

0.01

0.02

0.03

0.04

0.05

0.06

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Jens

en-S

hann

on D

iver

genc

e

Ratio of Tunneled Data to Normal Data

Normal1 v. Normal1+TunnelNormal1 v. Normal2Normal1 v. Normal3

Fig. 11. Divergence computed from the payload of UDPdatagrams. Horizontal lines represent the divergence ofnormal streams. The red line is the divergence of mixedtraces.

headers as well as the key authentication headers whichmay skew the distribution of the data.

However, there are practical issues and constraintswhen executing the statistical detection by defenders inlarge scale, besides the obvious storage and computationoverheads. For example, many legitimate applicationsuse DNS for storing non-IP data, such as public keysin the DomainKeys protocols [6], [7]. The anomaly de-tection analysis may result in false alarms.

Furthermore, traffic in our codeword mode describedin Section 2.1 is statistically indistinguishable from legit-imate DNS traffic. Thus, we conclude that DNS-basedbotnet command-and-control is both feasible and prac-tical.

6 RELATED WORK

Despite the fact that DNS tunneling is known for bypass-ing firewalls and encapsulating arbitrary data such asSSL traffic [9], [4], Exploring DNS protocol as a practicalcommand-and-control channel and identifying its limita-tions have not been scientifically studied. Various proof-of-concept botnet command and control systems viaunconventional media exist, such as via bluetooth [28]and social networks [14]. In comparison, our work isuseful beyond the specific DNS-based communicationchannel studied in two aspects.• We present new quantitative techniques and eval-

uation regarding the detection and constructionof general-purpose distributed stealthy communica-tion systems, including temporal strategies for mak-ing stealthy communication and statistical contentanalysis.

• We give a practical technique that is useful in do-main flux from the attacker’s perspective, namelyMarkov chain based domain name generation.

For DNS-based anomaly detection, Karasaridis etal described the use of the Kullback-Leibler distanceto measure byte distribution in DNS datagrams [13].

Dagon [3] proposed to quantify how anomalous thenumber of queries for each domain name during anhour in a day with Chebyshev’s inequality and distancemeasures previously used for examining anomalouspayloads. DNS-based anomaly detection approaches arepresented in [32] for detecting botnet C&C activities. Onemethod is to detect dynamic domain names whose queryrates are abnormally high or temporally concentratedusing outlier detection metrics such as Chebyshev’sinequality. Our work describes stealthy DNS behaviorswhose querying patterns are hard to distinguish withlegitimate domains, which make the counting baseddetection less effective.

Stone-Gross et al observed the use of domain flux inTorpig botnet [31], where new communication domainsare generated periodically and registered by the C&Cserver. Torpig bots communicated with the server overHTTP, after resolving the domain name. Patterns offast-flux botnets are measured and analyzed in [10].In comparison, we investigate the feasibility of solelyDNS-based command and control, without requiringany additional Web servers. The work in [35] utilizesmachine learning techniques to identify domain namesthat are algorithmically generated. Though it remainsunclear whether our MC-generated domain names canbe experimentally distinguished from legitimate domainnames by the techniques in [35], we conjecture thatthe MC-generated domains would be difficult to distin-guish from legitimate ones. The work in [1] describes15 features that can be used to detect anomalous DNStraffic in wide area networks, including IPs (e.g., a do-main mapped to multiple IPs across different countries),TTL values (e.g., short TTL), temporal features (e.g.,regularities in aggregated query patterns), and domainname features (similar to [35]). The stealth techniques onquery pattern and domain name generation described inthis work may help evade the machine learning baseddetection, showing the need for further research in thisdirection.

Our piggybacking DNS queries should not be con-fused with previously reported piggybacking methodsfor reducing DNS traffic. Those techniques usually takeadvantage of empty payload space in UDP datagrams.For example, renewal using piggyback method was pro-posed to piggyback cached DNS records to DNS queriesto refresh expired cached records [12]. Related domainsmay also be piggybacked in DNS queries [26], e.g., toinclude i.cnn.net in the DNS packet for www.cnn.com asthey are likely to be requested together by the browser.

Millen did pioneering work on covert-channel anal-ysis [16], [17], in particular in a system (host) environ-ment. Covert channel has been heavily analyzed in thecontext of traffic-analysis prevention [19] and routinganonymity [18]. Our work differs from them in that wefocus on designing practical covert channels across theInternet.

Our work is complementary to host-based malwaredetection and prevention solutions, such as the crypto-


graphic provenance verification technique [30], [33].

7 CONCLUSIONS AND OPEN PROBLEMS

We conducted a systematic study on the feasibility ofsolely using DNS queries for massive-scale stealthy com-munications among entities on the Internet. Our workshows that DNS – in particular the codeword modecombined with advanced querying strategies – can beused as an extremely effective stealthy command-and-control channel. To address the open problem raisedin [2] on how to algorithmically generate short-livedand realistic-looking domain names, we found that usingMarkov chain produces realistic-looking domain names.

Our work points out the potential severity of DNSabuse for massive-scale communications and the chal-lenges associated with its detection. Understanding thecapacity of botnets communication power helps iden-tify and eliminate nefarious attacks launched fromthem. DNS-based botnet command-and-control is morestealthy than application-based command-and-control(e.g., email [29] or social network [14]), and such a C&Csystem also benefits from the decentralization of DNS.Some of our anomaly detection analysis is useful beyondthe specific DNS tunneling problem studied.

We would like to point out the open research problemsrelated to DNS-based stealthy communication. Besidescommand and control, DNS tunneling may also beused for exfiltrating sensitive data by attackers includingrogue insiders. Payload inspection has been proposedfor detecting data leaks (e.g., privacy-preserving data-leak detection in large TCP segments [27]). How effec-tive these solutions are against leaks via small DNSqueries remains unclear. From defenders’ perspective,the approach of user-intention based anomaly detectionhas been demonstrated effective in detecting abnormalsystem events such as unauthorized file creation [34] andmalware-triggered outbound traffic [36]. Because DNSqueries are usually automatically issued by applicationsor the OS, the causal relations between user actions andDNS traffic may not be obvious. How to extend the user-intention based anomaly detection approach to identifyanomalous DNS traffic on a host is an open problem.

ACKNOWLEDGMENTS

The authors would like to thank anonymous reviewersfor their helpful comments.

REFERENCES

[1] L. Bilge, E. Kirda, C. Kruegel, and M. Balduzzi. Exposure: Findingmalicious domains using passive DNS analysis. In Proceedings ofthe 18th Annual Network and Distributed System Security Symposium(NDSS), February 2011.

[2] P. Butler, K. Xu, and D. Yao. Quantitatively analyzing stealthycommunication channels. In Proceedings of the 9th InternationalConference on Applied Cryptography and Network Security (ACNS’11), number 6715 in Lecture Notes in Computer Science (LNCS),pages 238–254, 2011.

[3] D. Dagon. Botnet detection and response, the network is theinfection, 2005. Domain Name System Operations Analysis andResearch Center Workshop.

[4] DeNiSe. http://c0re.23.nu/c0de/snap/DeNiSe-snap-20021026.tar.gz.

[5] C. J. Dietrich, C. Rossow, F. C. Freiling, H. Bos, M. van Steen, andN. Pohlmann. On botnets that use dns for command and control.In Proceedings of European Conference on Computer Network Defense,September 2011.

[6] Yahoo! Anti-Spam Resource Center - DomainKeys.http://antispam.yahoo.com/domainkeys, 2008. This is anelectronic document. Date retrieved: February 1, 2007.

[7] M. T. Goodrich, R. Tamassia, and D. Yao. Accredited DomainKeys:a service architecture for improved email validation. In Proceed-ings of the Conference on Email and Anti-Spam (CEAS ’05), July 2005.

[8] M. Hollander and D. A. Wolfe, editors. Nonparametric StatisticalMethods. Wiley-Interscience, second edition, 1999.

[9] M. V. Horenbeeck. DNS tunneling. http://www.daemon.be/maarten/dnstunnel.html.

[10] X. Hu, M. Knysz, and K. G. Shin. Measurement and analysisof global IP-usage patterns of fast-flux botnets. In Proceedings ofInternational Conference on Computer Communications (INFOCOM),2011.

[11] G. Hunt and D. Brubacher. Detours: Binary interception ofWin32 functions. In Proceedings of the Third USENIX Windows NTSymposium, 1999.

[12] B. Jang, D. Lee, K. Chon, and H. chul Kim. DNS resolution withrenewal using piggyback. Journal of Communications and Networks,11(4), August 2009.

[13] A. Karasaridis, K. S. Meier-Hellstern, and D. A. Hoeflin. Detectionof DNS anomalies using flow data analysis. In GLOBECOM. IEEE,2006.

[14] E. Kartaltepe, J. Morales, S. Xu, and R. Sandhu. Social network-based botnet command-and-control: Emerging threats and coun-termeasures. In Proceedings of Applied Cryptography and NetworkSecurity (ACNS), volume 6123 of Lecture Notes in Computer Science,pages 511–528. Springer, 2010.

[15] L. Lamport. Password authentication with insecure communica-tion. Communications of the ACM, 24(11):770–772, November 1981.

[16] J. K. Millen. Covert channel capacity. In IEEE Symposium onSecurity and Privacy, pages 60–66, 1987.

[17] J. K. Millen. 20 years of covert channel modeling and analysis.In IEEE Symposium on Security and Privacy, pages 113–114, 1999.

[18] I. Moskowitz, R. E. Newman, D. P. Crepeau, and A. R. Miller.Covert channels and anonymizing networks. In In Workshop onPrivacy in the Electronic Society (WPES 2003, pages 79–88. ACM,2003.

[19] R. E. Newman, I. S. Moskowitz, P. Syverson, and A. Serjantov.Metrics for traffic analysis prevention. In in Proceedings of PrivacyEnhancing Technologies Workshop (PET 2003, pages 48–65. Springer-Verlag, LNCS, 2003.

[20] G. Ollmann. Botnet communication topologies – understandingthe intricacies of botnet command-and-control. Available at http://www.damballa.com/.

[21] C. P. Pfleeger. Crypto: Not just for the defensive team. IEEESecurity & Privacy, 8(2):63–66, 2010.

[22] N. Provos and P. Mavrommatis. All your iframes point to us. InProceedings of USENIX Security Symposium, 2008.

[23] M. A. Rajab, F. Monrose, A. Terzis, and N. Provos. Peekingthrough the cloud: DNS-based estimation and its applications.In S. M. Bellovin, R. Gennaro, A. D. Keromytis, and M. Yung,editors, ACNS, volume 5037 of Lecture Notes in Computer Science,pages 21–38, 2008.

[24] Extension Mechanisms for DNS (EDNS0). RFC 2671. The InternetSociety. August, 1999. http://tools.ietf.org/html/rfc2671.

[25] SCIgen - an automatic CS paper generator. http://pdos.csail.mit.edu/scigen/.

[26] H. Shang and C. E. Wills. Piggybacking related domain namesto improve DNS performance. Comput. Netw., 50(11):1733–1748,2006.

[27] X. Shu and D. Yao. Data-leak detection as a service. In Proceed-ings of the 8th International Conference on Security and Privacy inCommunication Networks (SECURECOMM), September 2012.

[28] K. Singh, S. Sangal, N. Jain, P. Traynor, and W. Lee. Evaluatingbluetooth as a medium for botnet command and control. InProceedings of International Conference on Detection of Intrusions andMalware & Vulnerability Assessment (DIMVA), 2010.


[29] K. Singh, A. Srivastava, J. T. Giffin, and W. Lee. Evaluating email’sfeasibility for botnet command and control. In DSN, pages 376–385. IEEE Computer Society, 2008.

[30] D. Stefan, C. Wu, D. Yao, and G. Xu. Cryptographic provenanceverification for the integrity of keystrokes and outbound networktraffic. In Proceedings of the 8th International Conference on AppliedCryptography and Network Security (ACNS), June 2010.

[31] B. Stone-Gross, M. Cova, L. Cavallaro, B. Gilbert, M. Szydlowski,R. Kemmerer, C. Kruegel, and G. Vigna. Your botnet is mybotnet: Analysis of a botnet takeover. In Proceedings of the 16thACM Conference on Computer and Communications Security (CCS),November 2009.

[32] R. Villamarın-Salomon and J. C. Brustoloni. Identifying botnetsusing anomaly detection techniques applied to DNS traffic. InProceedings of the 5th IEEE Consumer Communications and Network-ing Conference (CCNC), 2008.

[33] K. Xu, H. Xiong, D. Stefan, C. Wu, and D. Yao. Data-provenanceverification for secure hosts. IEEE Transaction on Dependable andSecure Computing (TDSC), 9(2):173 – 183, March/April 2012.

[34] K. Xu, D. Yao, Q. Ma, and A. Crowell. Detecting infectiononset with behavior-based policies. In Proceedings of the FifthInternational Conference on Network and System Security (NSS),September 2011.

[35] S. Yadav, A. K. K. Reddy, A. N. Reddy, and S. Ranjan. Detectingalgorithmically generated malicious domain names. In Proceedingsof the 10th annual conference on Internet measurement, IMC ’10, pages48–61, New York, NY, USA, 2010. ACM.

[36] H. Zhang, W. Banick, D. Yao, and N. Ramakrishnan. Userintention-based traffic dependence analysis for anomaly detec-tion. In Proceedings of Workshop on Semantics and Security (WSCS),May 2012.

Kui Xu received the bachelor degree in com-puter science from the University of Science andTechnology of China. He is a PhD candidate inthe Department of Computer Science at VirginiaTech, Blacksburg. He is interested in cyber se-curity research. In particular, he focuses on uti-lizing user behavior information in strengtheningsecurity. Major research topics cover drive-by-download detection, user-activity-based authen-tication, DNS tunneling analysis, and personal-ized anomaly detection. He is a student member

of the IEEE.

Patrick Butler is a PhD candidate in the De-partment of Computer Science at Virginia Tech,Blacksburg. He received dual BS degrees inComputer Science and Physics from VirginiaTech in 2005. He is currently working in therealm of data mining, specifically temporal datamining. His other research interests includedistributed data storage, Linux kernel networkstack, and network security.

Sudip Saha received BS in Computer Scienceand Engineering from Bangladesh University ofEngineering and Technology (BUET) in 2006.He received MS in computer science from Uni-versity of Memphis in 2010. Currently he is pur-suing Ph.D. in computer science at Virginia Tech.His research interest lies in social and complexnetworks, game theory, and computer security.

Danfeng (Daphne) Yao is an assistant pro-fessor in the Department of Computer Scienceat Virginia Tech, Blacksburg. She received thePhD degree in computer science from BrownUniversity. Before joining Virginia Tech, she wasa tenure-track assistant professor in the Com-puter Science Department at Rutgers Univer-sity for two years. Her research interests arein network and information security, in partic-ular user-centric security and privacy, social-and human-behavior pattern recognition, insider

threats, data privacy, and applied cryptography. She received the USNational Science Foundation CAREER Award in 2010 for her work onhuman-behavior-driven malware detection. She won the Best StudentPaper Award at ICICS 2006 and the Award for Technological Innovationfrom Brown in 2006, both for her privacy-preserving identity manage-ment work, and the Best Paper Award at CollaborateCom 2010 forkeystroke security. In February 2012, she received the Outstanding NewAssistant Professor Award from VT. She is a member of the IEEE andthe IEEE Computer Society.

journal of la dns for massive-scale command and...

Documents