Check out the new USENIX Web site.

Revealing Botnet Membership Using DNSBL Counter-Intelligence

Anirudh Ramachandran, Nick Feamster and David Dagon
College of Computing, Georgia Institute of Technology
{avr, feamster, dagon}@cc.gatech.edu


Abstract:

Botnets—networks of (typically compromised) machines—are often used for nefarious activities (e.g., spam, click fraud, denial-of-service attacks, etc.). Identifying members of botnets could help stem these attacks, but passively detecting botnet membership (i.e., without disrupting the operation of the botnet) proves to be difficult. This paper studies the effectiveness of monitoring lookups to a DNS-based blackhole list (DNSBL) to expose botnet membership.

We perform counter-intelligence based on the insight that botmasters themselves perform DNSBL lookups to determine whether their spamming bots are blacklisted. Using heuristics to identify which DNSBL lookups are perpetrated by a botmaster performing such reconnaissance, we are able to compile a list of likely bots. This paper studies the prevalence of DNSBL reconnaissance observed at a mirror of a well-known blacklist for a 45-day period, identifies the means by which botmasters are performing reconnaissance, and suggests the possibility of using counter-intelligence to discover likely bots. We find that bots are performing reconnaissance on behalf of other bots. Based on this finding, we suggest counter-intelligence techniques that may be useful for early bot detection.

1  Introduction

Internet malice has evolved from pranks conceived and executed by amateur hackers to a global business involving significant monetary gains for the perpetrators [19]. Examples include: (1) unsolicited commercial email (“spam”), which threatens to render email useless by immensely decreasing the signal-to-noise ratio of traffic [17]; (2) denial of service attacks, which have become common [12], and (3) click fraud, whereby a group of attackers send bogus “clicks” for online advertisements that mimic legitimate request patterns, swindling advertisers out of large sums of money [4].

Botnets are a root cause of these problems [8], since they allow attackers to distribute tasks over thousands of hosts distributed across the Internet. A botnet is network of compromised hosts (“bots”) connected to the Internet under the control of a single entity (“botmaster”, “controller”, or command and control) [5]. The large cumulative bandwidth and relatively untraceable nature of spam from bots makes botnets an attractive choice for large-scale spamming. Previous work provides further background on botnets [5, 6].



If network operators and system administrators could reliably determine whether a host is a member of a botnet, they could take appropriate steps towards mitigating the attacks they perpetrate. Although previous work has described an active detection technique using DNS hijacking technique and social engineering [6], there are few efficient methods to passively detect and identify bots (i.e., without disrupting the operation of the botnet). Indeed, detecting botnets proves to be very challenging: a victim of a botnet attack can typically only observe the attack from a single network, from which point the attack traffic may closely resemble the traffic of legitimate users. Regrettably, the state-of-the-art in botnet identification is based on user complaints, localized honeypots and intrusion detection systems, or through the complex correlation of data collected through darknets [13].

We propose a set of techniques to identify botnets using passive analysis of DNS-based blackhole list (DNSBL) lookup traffic. Many Internet Service Providers (ISPs) and enterprise networks use DNSBLs to track IP addresses that originate spam, so that future emails sent from these IP addresses can be rejected. For the same reason, botmasters are known to sell “clean” bots (i.e., not listed in any DNSBL) at a premium. This paper addresses the possibility of performing counter-intelligence to help us discover identities of bots, based on the insight that botmasters themselves must perform “reconnaissance” lookups to determine their bots' blacklist status.

The contributions of this paper include:

1. Passive heuristics for counter-intelligence. We develop heuristics to distinguish DNSBL reconnaissance queries for a botnet from legitimate DNSBL traffic (either offline or in real-time), to identify likely bots. These heuristics are based on an enumeration of possible lookup techniques that botmasters are likely to use to perform reconnaissance, which we detail in Section 2. Unlike previous detection schemes, our techniques are covert and do not disrupt the botnet's activity.

2. Study of DNSBL reconnaissance techniques. We study the prevalence of DNSBL reconnaissance by analyzing logs from a mirror of a well-known blackhole list for a 45-day period from November 17, 2005 to December 31, 2005. Section 4 discusses the prevalence of the different types of reconnaissance techniques that we observed. Much to our surprise, we find that bots are performing reconnaissance on behalf of other (possibly newly infected) bots. Although some bots perform a large number of reconnaissance queries, it appears that much of the reconnaissance activity is spread across many bots each of which issue few queries, thus making detection more difficult.

3. Identification of new bots. We analyze DNSBL queries that are likely being performed by botmasters to identify “clean” bots. Such reconnaissance usually precedes the use of bots in an attack, suggesting the possibility that this DNSBL counter-intelligence can be used to bolster responses. Section 3 demonstrates the possibility of such early warning. To validate our detection scheme, we correlate the IP addresses of these likely bots with data collected at a botnet sinkhole (sinkholing technique explained in previous work [6]) over the same time period (this dataset has been used as “ground truth” for botnet membership in previous studies [6, 17]).


Figure 1: DNSBL-based Spam Mitigation Architecture.


4. DNSBL-based countermeasures. Our heuristics could be used to detect reconnaissance in real-time. This ability potentially allows for active countermeasures, such as returning misleading responses to reconnaissance lookups, as shown in Figure 1. We revisit this topic in Section 5.

2  Model of Reconnaissance Techniques

This section describes our model for DNSBL reconnaissance techniques (i.e., the techniques that botmasters may be using to determine whether bots have been blacklisted). Our goal in developing these models and heuristics is to distinguish DNSBL queries issued by botmasters from those performed by legitimate mail servers.1

2.1  Properties of Reconnaissance Queries

Our detection heuristics are based on the construction of a DNSBL query graph, where an edge in the graph from node A to node B indicates that node A has issued a query to a DNSBL to determine whether node B is listed. After constructing this graph, we develop detection heuristics based on the expected spatial and temporal characteristics of legitimate lookups versus reconnaissance-based lookups. These characteristics hold primarily in cases when members of the botnet are not performing queries on behalf of each other, a case that makes detecting reconnaissance more difficult, as we explain in Section 2.2.3. As we describe below, our detection heuristics exploit both spatial and temporal properties of the DNSBL query graph.

Property 1   A legitimate mail server will perform queries and be the object of queries. In contrast, hosts performing reconnaissance-based lookups will only perform queries; they will not be queried by other hosts.2


In other words, legitimate mail servers are likely to be queried by other mail servers that are receiving mail from that server. On the other hand, a host that is not itself being looked up by any other mail servers is, in all likelihood, not a mail server. We can use this observation to identify hosts that are likely performing reconnaissance: lookups from hosts that have a high out-degree in the DNSBL query graph (i.e., hosts that are performing many lookups) but have a low in-degree are likely unrelated to the delivery of legitimate mail. To quantify this effect, we define the lookup ratio, λ, of some node n as follows:
λn =
dn,out
dn,in


where dout is the number of distinct IP addresses that node n queries, and din is the number of distinct IP addresses that issue a query for node n.3 This metric is most effective when hosts performing reconnaissance are disjoint from hosts that are actually used to spam, which appears to the case today.However, as reconnaissance techniques become increasingly more sophisticated (as we describe in Section 2.2.3), this metric may become less useful. Still, we find that this metric proves to be quite useful in detecting many instances of DNSBL-based reconnaissance.

The temporal arrival pattern of queries at the DNSBL by hosts performing reconnaissance may differ from temporal characteristics of queries performed by legitimate hosts. We expect this to be the case because, whereas legitimate DNSBL lookups are driven by the arrival of actual email, reconnaissance queries will not reflect any realistic arrival patterns of actual email.

Property 2   A legitimate mail server's DNSBL lookups reflect actual arrival patterns of real email messages: legitimate lookups are typically driven automatically when emails arrive at the mail server and will thus arrive at a rate that mirrors the arrival rates of emails. Reconnaissance-based lookups, on the other hand, will not mirror the arrival patterns of legitimate email.


We may be able to exploit the fact that email traffic tends to be diurnal [9] to tease apart DNSBL lookups that are driven by actual mail arrival from those that are driven by reconnaissance. Discovering reconnaissance activity using this method is a topic for future work.

2.2  Reconnaissance Techniques

In this section, we describe three classes of DNSBL reconnaissance techniques that may be performed by botmasters: single-host, or third-party, reconnaissance; self-reconnaissance; and reconnaissance using other bots. For each case, we describe the basic mechanism, the heuristics that we can use to detect reconnaissance in each of these cases, and how each technique may complicate detection.

2.2.1  Third-party Reconnaissance

In third-party reconnaissance, a botmaster performs DNSBL lookups from a single host for a list of spamming bots; this host may be the command-and-control of the botnet, or it might be some other dedicated machine. In any case, we hypothesize that the machine performing the lookups in these cases is not likely to be a mail server. Single-host reconnaissance, if performed by a machine other than a mail server, is easily detected, because the node performing reconnaissance will have a high value of λn.

Once detected, single-host reconnaissance may provide useful information to aid us in revealing botnet membership. First, once we have identified a single host performing such lookups, the operator of the DNSBL can monitor the lookups issued by that host over time to track the identity of hosts that are likely bots. If the identity of this querying host is relatively static (i.e., if its IP address does not change over time, or if it changes slowly enough so that its movements can be tracked in real-time), the DNSBL operator could take active countermeasures, such as intentionally returning incorrect information about bots' status in the blacklist, a possibility we discuss in more detail in Section 5.

2.2.2  Self-Reconnaissance

Single-host reconnaissance is simple, but it is susceptible to detection. To remain more stealthy, and to distribute the workload of performing DNSBL reconnaissance, botmasters may begin to distribute these lookups across the botnet itself. A simple (albeit sub-optimal) way to distribute these queries is to have a bot perform reconnaissance on its own behalf (“self-reconnaissance”); in other words, each bot could issue a DNSBL query to itself (i.e., to determine whether it was listed) before sending spam to the victim.

In this case, identifying a reconnaissance-based DNSBL query is fairly straightforward, because, except in cases of misconfiguration, a legitimate mail server is unlikely to issue a DNSBL lookup for itself. Even though this technique has the advantage of distributing the load of reconnaissance across the botnet, we did not observe this technique being used in practice, likely because a self-query is a dead giveaway.

2.2.3  Distributed Reconnaissance

A more stealthy way to distribute the operation across the botnet is to have each bot perform reconnaissance on behalf of other bots either in the same botnet or in other botnets. For instance, note that Property 1 is unlikely to hold: in this case, the nodes performing reconnaissance will also be queried by other mail servers to which they send spam. As a result, these nodes are likely to have a high dn,in, unlike nodes performing single-host reconnaissance. Ultimately, detecting this type of reconnaissance activity may require mining temporal properties (e.g., Property 2).

Although using the botnet itself for DNSBL reconnaissance is more discreet than performing this reconnaissance from a single host, a network operator who positively identifies a small number of bots (e.g., starting with a small hit-list of known bots, probably by using a honeynet with known infected machines). As discussed in Section 4, if this seed list of bots performs queries for other hosts, it is likely that these machines are also bots.

We suspected that this mode of reconnaissance would be uncommon, possibly because of the complexity involved in implementing and operating such a system (e.g., keeping track of nodes in the looked-up botnet, disseminating this information to the querying nodes etc.). Much to our surprise, we did witness this behavior; we present these results in Section 4.

3  Data and Analysis

This section describes our data collection and analysis. We first describe our DNSBL dataset and its limitations. Then, we describe how this dataset is used to construct the DNSBL query graph described in Section 2.

3.1  Data Collection and Processing

Our study primarily involves two datasets collected from the same time period (November 17, 2005 to December 31, 2005): (1) the DNSBL query logs to a mirror of a large DNSBL, and (2) the logs of bot connections to a sinkhole for a Bobax botnet [2]. Unlike most botnets, the Bobax bot is designed solely for spamming [1], increasing the likelihood that a query for known Bobax host is the consequence of the querying mail server having received spam from that host.

To verify whether the scheme we propose is indeed able to discover additional bots, we compared the IP addresses in the DNSBL query graph against the IP addresses of spammers in a large spam corpus collected at a spam honeypot (the setup of this honeypot is described in our earlier work [17]).

3.2  Analysis and Detection

In this section, we describe how the DNSBL query graph is constructed. Definitions for the terminology used in our algorithm follow: (1) B, the set of IP addresses that attempted to connect to the Bobax sinkhole during the observation period (November 17, 2005–December 31, 2005); (2) querier, the IP address of the host that performs a given DNSBL query; (3) queried, the IP address of the host that is looked up in a DNSBL query; and (4) G, the DNSBL query graph constructed as a result of the algorithm.

The graph construction algorithm takes as input a set of DNSBL query logs (we use tcpdump for packet captures) and the set B and outputs a directed graph G. The algorithm, summarized in Figure 2, consists of two main steps: parsing and pruning. As the algorithm suggests, we prune DNSBL queries to only include edges which have at least one end (either querier or queried) present in the set B. Pruning is performed for efficiency reasons: the full DNSBL query logs mostly contain queries from legitimate mail servers. Using B to prune the complete query graph allows us to concentrate on a subgraph which has a higher percentage of reconnaissance lookups than the unpruned graph. We recognize that our analysis will overlook reconnaissance activity where both the querier or queried nodes are not members of B. To address this shortcoming, we perform a query graph extrapolation after the algorithm is run. In this step, we make a second pass over the DNSBL query logs and add edges if at least one of the endpoints of the edge (i.e., either querier or queried) is already present in the graph. Query graph extrapolation is repeated until no new edges are added to G.
ConstructGraph()
create empty directed graph G
/* Parsing */
for each DNSBL query:
    Identify querier and queried
    /* Pruning */
    if querier ∈ B or queried ∈ B then
         add querier and queried to G if they
            are not already members of G
         if there exists an edge E(querier, queried) ∈ G then
             increment the weight of E(querier,queried)
         else
             add E(querier,queried) to G with weight 1


Figure 2: Algorithm to construct a DNSBL query graph


We then compute λn for each node in the graph (Property 1), which allows us to identify nodes involved in reconnaissance techniques described in Section 2. Although the results in Section 4 suggest that some bots have large values of λn, techniques that use a large number bots to look each other up may be undetectable with this metric. We are developing techniques based on Property 2 to further improve our detection.

4  Preliminary Results

This section presents preliminary results using Property 1 to identify DNSBL reconnaissance activity on the observed DNSBL query graph. We emphasize that the reconnaissance being performed by bots is distinctly under the radar as far as total DNSBL traffic is concerned: the pruned traffic amounts to less than 1% of the total DNSBL traffic. In this section, we present two surprising results: First, botnets are being used to perform DNSBL reconnaissance on behalf of bots in other botnets, which has implications for botnet detection. Second, the distribution of these queries across bots suggests that some DNSBL reconnaissance activities may be detectable in real-time, which has implications for early detection and mitigation.

Attempts to validate our hypotheses from Section 2 resulted in some interesting discoveries, including the discovery of new bots. We initially expected that most DNSBL lookups would be third-party lookups, as described in Section 2.2.1, and that we would be able to validate the queried nodes as being known bots. Instead, we discovered the opposite: the nodes with the highest values of λn in the pruned graph were known bots, while the queried nodes in the graph were new, previously unknown bots. Further, using data from our spam sinkhole [17], we found that some of these nodes were Windows machines and confirmed spam originators. This finding suggests that, in general, it may be possible to start with a set of known bots and use the DNSBL graph to “bootstrap” the discovery of new bots.
Node # ASN of Node Out-degree known spammers
1 Everyone's Internet (AS 13749) 36,875 12
2 IQuest (AS 7332) 32,159 7
3 UUNet (AS 701) 31,682 5
4 UPC Broadband (AS 6830) 26,502 8
5 E-xpedient (AS 17054) 19,530 4


Table 1: AS numbers of hosts which have the highest out-degrees. The last column shows the number of hosts queried by this node that are known spammers (verified using logs from our spam sinkhole).


Table 1 shows five of the top queriers (i.e., high out-degree nodes), all of which are known bots from our Bobax trace. Even more interesting is the fact that a few IP addresses queried by these nodes actually sent spam to our spam honeypot. Moreover, nearly all of IP addresses that sent spam to our honeypot were not present in our list of known bots. Due to the fact that our honeypot only captures a small portion of the Internet's spam, the fraction of total reconnaissance queries that we can confirm as spamming bots is small. Still, we believe it strongly suggests evidence of a known bot performing DNSBL reconnaissance on a distinct (and possibly newly compromised) botnet.

Figure 3 shows the distribution of out-degrees for all querying nodes present in the pruned DNSBL query graph. The long tail also confirms that bots already have the capability to distribute these queries, which is cause for concern. Our view of DNSBL queries is narrow (most querying nodes are geographically close to the DNSBL mirror), so we expect that more vantage points of DNSBL lookups would reveal other prominent “players”. The fact that the prominent players in our analysis were also bots suggests that these nodes may also be obvious candidates for the mitigation techniques described in Section 5.


Figure 3: CDF of the distribution of out-degrees for querying IP addresses.




5  Countermeasures

In Section 4, we found that the known bots in our Bobax trace were not the targets of lookups, but instead were issuing lookups for other, possibly newly compromised bots. This finding suggests a possible technique that could be used for the discovery of new bots, even without an initial list of suspects: An initial set of suspect IP addresses could be constructed by establishing a spam trap, which according to both previous work [17] and the observations in this paper, appear to be largely bots. Alternatively, a suspect node could be detected simply by identifying nodes in the DNSBL query graph with a high value of λn. Beginning with this initial suspect list, an operator may be able to conclude that, not only are the nodes that this node is querying likely bots, but also the node itself is likely a bot. If there are other high-degree nodes also querying the same bots, a detection algorithm might be able to “walk” the DNSBL graph (e.g., from parent to parent) to discover multiple distinct botnets.

We believe that using such techniques to aggressively monitor botnet-based DNSBL reconnaissance may prove to be useful for mitigating spam: as noted in our previous work [17], most bots send a very low volume of spam to any single domain; thus, reporting a bot to blacklists after the spam is received may not be effective.

With the ability to distinguish reconnaissance queries from legitimate queries, a DNSBL operator might be able to mitigate spam more effectively. We speculate one possibility as follows: an operator could tune the behavior of the blackhole list server to mislead a botmaster, using a class of techniques we call reconnaissance poisoning. On one hand, the DNSBL could trick the botmaster into thinking that a particular bot was “clean” (i.e., unlisted) when in fact it was listed, which would induce the botmaster to unwittingly send spam from blacklisted machines. On the other hand, the DNSBL could also reply to a reconnaissance query with an indication that a host was listed, even though it was not listed, thereby discouraging a botmaster from using a machine that would likely be capable of successfully sending spam.

Of course, active countermeasures such as reconnaissance poisoning do run the risk of false positives: if we mistakenly attribute a legitimate DNSBL query to a reconnaissance-based query, we could mislead a legitimate mail server into either mistakenly accepting spam that would have otherwise been rejected or, more regrettably, rejecting legitimate email. Such techniques could also be defeated if the botmaster queries multiple blacklist providers that maintain independent lists. Investigating the extent to which our detection metrics are subject to false positives, as well as the extent to which these false positives interfere with a legitimate mail server's filtering techniques, is part of our ongoing work.

6  Related Work

Botnets have been in use as vehicles of cybercrime for quite some time, but studies on how they spread, and techniques to counter them, are relatively scarce. Previous research has traced the history of botnets [18, 21, 22] and common modes of botnet operation [5]. This section briefly discusses previous botnet detection techniques and previous research on DNSBL traffic analysis.

Previous work has identified bots by examining the communication protocols used by botnets (e.g., for “rallying”), most notably Internet Relay Chat (IRC) [7, 23]. Some have suggested the use of such protocols to identify and remediate botnets. For example, researchers have joined IRC-based botnets and enumerated victims using IRC commands [8]; others have used network traffic to identify IRC zombies [16]. Some researchers have identified bot victims by observing the unwanted traffic they generate, e.g., the RST storms or backscatter generated by DDoS attacks using forged source addresses [15].

Studies show that many botnets are IRC-based [5, 22], though other protocols are being used [14]. Attempts have been made to detect such botnets using misuse-detection or basic intrusion detection analysis [3, 10]. Dagon et al. used DNS redirection to monitor botnets [6]. In contrast, the detection techniques described in this paper are more discreet because they do not require direct communication with any component of the botnet.

Jung et al. found that 80% of spam sources in their analysis were listed in at least one of seven popular blacklists [11], which correlates well with our independent previous study [17]. To the best of our knowledge, this paper presents the first study that uses direct analysis of DNSBL logs to infer other types of network behavior.

7  Conclusion

This paper has developed techniques and heuristics for detecting DNSBL reconnaissance activity, whereby botmasters perform lookups against the DNSBL to determine whether their spamming bots have been blacklisted. We first developed heuristics for counter-intelligence based on several possible ways we figured reconnaissance was being performed. We then studied the prevalence of each of these reconnaissance techniques. Much to our surprise, we found that bots were in fact performing reconnaissance on IP addresses for bots in other botnets. Based on this finding, we have outlined possibilities for new botnet detection techniques using a traversal of the DNSBL query graph, and we have suggested techniques that DNSBL operators might use to more effectively stem the spam originating from botnets. We are investigating the effectiveness of these detection and mitigation techniques as part of our ongoing work.

Acknowledgments

We thank Randy Bush, Wenke Lee, and Merrick Furst for feedback on some of the ideas in this paper. This work is supported in part by NSF grant CCR-0133629 and Office of Naval Research grant N000140410735. The contents of this work are solely the responsibility of the authors and do not necessarily represent the official views of NSF or the U.S. Navy. Data used in this paper was obtained as part of an information disclosure granted by the Georgia Tech Research Corporation, ref. Record of Invention GTRC ID 3828. Please consult the authors regarding its citation or use.

Notes

1
DNSBL queries issued by mail servers are often performed by directly querying the DNSBL, rather than relying on a local resolver. For example, SpamAssassin [20] implements its own recursive DNS resolver. Hosts performing reconnaissance are also unlikely to query DNSBLs using local resolvers. Thus, in both cases, the querying IP address observed at the DNSBL correctly reflects the end-host performing the query.
2
This heuristic assumes that networks generally use the same host for both inbound and outbound mail servers. Although this configuration is common, some large networks separate the hosts responsible for inbound and outbound mail servers. In this case, queries from the inbound mail server might be misinterpreted as a reconnaissance attempt.
3
When dn,in is zero (which is commonly the case), we can simply consider λn to be a very large number.

References

[1]
Bobax trojan analysis. https://www.lurhq.com/bobax.html, March 2005.

[2]
Symantec Security Alert–W32.Bobax.D worm. https://www.sarc.com/avcenter/venc/data/w32.bobax.d.html.

[3]
D. Brumley. Tracking hackers on IRC. https://www.doomdead.com/texts/ircmirc/TrackingHackersonIRC.htm, 2003.

[4]
CNN Technology News. Expert: Botnets No. 1 emerging Internet threat. https://www.cnn.com/2006/TECH/internet/01/31/furst/, Jan. 2006.

[5]
E. Cooke, F. Jahanian, and D. McPherson. The Zombie Roundup: Understanding, Detecting and Disrupting Botnets. In Usenix Workshop on Steps to Reducing Unwanted Traffic on the Internet (SRUTI), June 2005.

[6]
D. Dagon, C. Zou, and W. Lee. Modeling botnet propagation using time zones. In Proceedings of the 13th Annual Network and Distributed System Security Symposium (NDSS '06), 2006.

[7]
S. Dietrich, N. Long, and D. Dittrich. Analyzing distributed denial of service attack tools: The shaft case. In Proceedings of the LISA 2000 System Administration Conference, December 2000.

[8]
F. C. Freiling, T. Holz, and G. Wicherski. Botnet tracking: Exploring a root-cause methodology to prevent distributed denial-of-service attacks. Technical Report ISSN-0935-3232, RWTH Aachen, April 2005.

[9]
L. H. Gomes, C. Cazita, J. Almeida, V. Almeida, and W. Meira. Characterizing a Spam Traffic. In Proc. ACM SIGCOMM Internet Measurement Conference, Taormina, Sicily, Italy, Oct. 2004.

[10]
C. Hanna. Using snort to detect rogue IRC bot programs. Technical report, October 2004.

[11]
J. Jung and E. Sit. An Empirical Study of Spam Traffic and the Use of DNS Black Lists. In Proc. ACM SIGCOMM Internet Measurement Conference, pages 370–375, Taormina, Sicily, Italy, Oct. 2004.

[12]
S. Kandula, D. Katabi, M. Jacob, and A. Berger. Botz-4-Sale: Surviving Organized DDoS Attacks That Mimic Flash Crowds. In Proc. 2nd Symposium on Networked Systems Design and Implementation (NSDI), Boston, MA, May 2005.

[13]
S. Krasser, G. Conti, J. Grizzard, J. Gribschaw, and H. Owen. Real-time and forensic network data analysis using animated and coordinated visualization. In Proceedings of the 6th IEEE Information Assurance Workshop, 2005.

[14]
B. Krebs. Bringing botnets outof the shadows. https://www.washingtonpost.com/wp-dyn/content/article/2006/03/21/AR2006032100279.html, 2006.

[15]
D. Moore, G. M. Voelker, and S. Savage. Inferring internet denial-of-service activity. In Proceedings of the 2001 USENIX Security Symposium, 2001.

[16]
S. Racine. Analysis of internet relay chat usage by ddos zombies. ftp://www.tik.ee.ethz.ch/pub/students/2003-2004-Wi/MA-2004-01.pdf, 2004.

[17]
A. Ramachandran and N. Feamster. Understanding the Network-Level Behavior of Spammers. In Proc. ACM SIGCOMM, Pisa, Italy, Sept. 2006.

[18]
P. Ramneek. Bots & Botnets: An Overview. https://www.giac.com/practical/GSEC/Ramneek_Puri_GSEC.pdf, 2003.

[19]
S. Schechter and M. Smith. Access for sale. In 2003 ACM Workshop on Rapid Malcode (WORM'03). ACM SIGSAC, October 2003.

[20]
SpamAssassin, 2005. https://www.spamassassin.org/.

[21]
SwatIt. Bots, drones, zombies, worms and other things that go bump in the night. https://swatit.org/bots/, 2004.

[22]
Virus Bulletin 2005 Paper on 'Bots and Botnets'. https://arachnid.homeip.net/papers/VB2005-Bots_and_Botnets-1.0.2.pdf.

[23]
Y. Zhang and V. Paxson. Detecting stepping stones. In Proceedings of the 9th USENIX Security Symposium, August 2000.