Botnets have become the most serious threats to the Internet security. Many cyber- crimes are botnet related. Measuring and understanding the botnet will help us gain more insight to the botnet phenomenon, and further help us design better detection and prevention systems.
0 10 20 30 40 50 60 # of DIPs/SIP Count of sources 1 3 5 7 9 12 15 18 21 24 27 30 33 39
Fig. 16.The distribution of number of destinations a source touched of the event on TCP port 2967 on 2006-11-27, which corresponding to a backdoor shell.
In this book chapter, we proposed a general framework to extract botnet global scanning events. Based on one year honeynet traffic from a large research institution we studied the six different botnet scanning characteristics. We found botnets al- though mainly from a small number of ASes but indeed spread out all over the world from totally 2860 ASes. There are two different botnet arrival/departure patterns: all together and gradually. We conjecture this is related to different scan strategies. We also found the scan arrivals are linear in time and inter-arrival time follows a expo- nential distribution, which might imply the scans are random scanning and the scan range is much larger than the detection sensor.
References
1. M. Bailey et al. The Internet motion sensor: A distributed blackhole monitoring system. InProc. of NDSS, 2005.
2. James Binkley and Suresh Singh. An algorithm for anomaly-based botnet detection. In Proceedings of Steps to Reducing Unwanted Traffic on the Internet Workshop (SRUTI ’06), 2006.
3. E. Cooke, F. Jahanian, and D. McPherson. The zombie roundup: Understanding, detect-
ing, and disrupting botnets. InProceedings of USENIX Workshop on Steps to Reducing
Unwanted Traffic on the Internet, July 2005.
4. W. Cui et al. GQ: Realizing a system to catch worms in a quarter million places. Technical Report TR-06-004, ICSI, 2006.
5. D. Dagon, C. Zou, and W. Lee. Modeling botnet propagation using time zones. InPro-
ceedings of the 13th Network and Distributed System Security Symposium (NDSS’06), 2006.
6. Neil Daswani, Michael Stoppelman, the Google Click Quality, and Inc Security Teams,
Google. The anatomy of Clickbot.A. InUSENIX First Workshop on Hot Topics in Un-
derstanding Botnets (HotBots), 2007.
7. Julian Grizzard, Vikram Sharma, Chris Nunnery, Brent ByungHoon Kang, and David
Dagon. Peer-to-peer botnets: Overview and case study. InUSENIX First Workshop on
Hot Topics in Understanding Botnets (HotBots), 2007.
8. Christopher W. Hanna. Using snort to detect rogue irc bot programs, Oct
2004.http://www.giac.org/certified_professionals/practicals/
gsec/4095.php.
9. J. Kannan et al. Semi-automated discovery of application session structure. InProc. of
ACM IMC, 2006.
10. R. Pang et al. Characteristics of Internet background radiation. InProc. of ACM IMC,
2004.
11. V. Paxson. Bro: A system for detecting network intruders in real-time. Computer Net-
works, 31, 1999.
12. The Honeynet Project and Research Alliance. Know your enemy: Tracking botnets.
http://honeynet.org/papers/bots, March 2005.
13. N. Provos. A virtual honeypot framework. InProc. of USENIX Security, 2004.
14. Niels Provos, Dean McNamee, Panayiotis Mavrommatis, Ke Wang, and Nagendra
Modadugu. The ghost in the browser: Analysis of web-based malware. In USENIX
First Workshop on Hot Topics in Understanding Botnets (HotBots), 2007.
15. Moheeb A. Rajab, Jay Zarfoss, Fabian Monrose, and Andreas Terzis. A multifaceted
approach to understanding the botnet phenomenon. InProc. of ACM/USENIX IMC, 2006.
16. Anirudh Ramachandran and Nick Feamster. Understanding the network-level behavior
of spammers. InProceedings of ACM SIGCOMM ’06, September 2006.
17. Anirudh Ramachandran, Nick Feamster, and David Dagon. Revealing botnet member-
ship using DNSBL counter-intelligence. InProceedings of Steps to Reducing Unwanted
Traffic on the Internet Workshop (SRUTI ’06), 2006.
18. M. Vrable et al. Scalability, fidelity, and containment in the potemkin virtual honeyfarm. InProc. of SOSP, 2005.
19. V. Yegneswaran, Paul Barford, and Vern Paxson. Using honeynets for Internet situational
awareness. InIn Proc. of ACM Hotnets IV, 2005.
20. V. Yegneswaran et al. On the design and use of Internet sinks for network abuse monitor-
ing. InProc. of RAID, 2004.
21. Michal Zalewski. the new p0f.http://lcamtuf.coredump.cx/p0f.shtml.
22. Cliff C. Zou et al. Monitoring and early warning for Internet worms. InProf. of ACM
Elizabeth Stinson and John C. Mitchell
Department of Computer Science, Stanford University, Stanford, CA 94305
{stinson,mitchell}@cs.stanford.edu
Summary. A botnet is a collection of bots, each generally running on a compromised system and responding to commands over a “command-and-control” overlay network. We investigate observable differences in the behavior of bots and benign programs, focusing on the way that bots respond to data received over the network. Our experimental platform monitors execu- tion of an arbitrary Win32 binary, considering data received over the network to be tainted, applying library-call-level taint propagation, and checking for tainted arguments to selected system calls. As a way of further distinguishing locally-initiated from remotely-initiated ac- tions, we capture and propagate “cleanliness” of local user input (as received via the keyboard or mouse). Testing indicates behavioral separation of major bot families (ago, DSNX, evil, G-SyS, sd, Spy) from benign programs with low error rate.
Key words: host-based, behavior-based, detection, taint, interposition, system call
1 Introduction
Botnets have been instrumental in distributed denial of service attacks, click fraud, phishing, malware distribution, manipulation of online polls and games, and identity theft [2, 17, 18, 24, 27, 30]. As much as 70% of all spam may be transmitted through botnets [4] and as many as1
4of all computers may be participants in a botnet [34]. A
bot master (or “botherder”) directs the activities of a botnet by issuing commands that are transmitted over a command-and-control (C&C) overlay network. Some previous network-based botnet detection efforts have attempted to exploit this ongoing C&C behavior or its side effects [3, 6, 24]. Our work investigates the potential for host- based behavioral bot detection. In particular, we test the hypothesis that the behavior of installed bots can be characterized in a way that distinguishes malicious bots from innocuous processes. We are not aware of any prior studies of this topic.
Each participating bot independently executes each command received over the C&C network. A bot command takes some number of parameters (possibly zero) – each of a particular type – in some fixed order. For example, many bots provide a web-download command, which commonly takes two parameters; the first is a URL that identifies a remote resource (typically a file) that should be downloaded, and the
second is the file path on the host system at which to store the downloaded data. A botnet constitutes aremotely programmable platformwith the set of commands it supports forming its API.
Many parameterized bot commands are implemented by invoking operating sys- tem services on the host system. For example, the web-download command connects to a target over the network, requests some data from that target, and creates a file on the host system; all of these actions (connect, network send and receive, and file creation) are performed via execution of system calls. Typically, a command’s parameters provide information used in the system call invocation. For example,
theconnectsystem call takes an IP address argument, which identifies the target
host with which a connection should be established. Implementations of the web- download command obtain that target host IP from the given URL parameter. Thus, execution of many parameterized commands causes system call invocations on argu- ments obtained from those parameters.
In this chapter, we test the experimental hypothesis that the remote control of bots through parameterized commands separates bot behavior from normal execution of innocuous programs. We postulate that a process exhibits external or remote con- trol when it uses data received from the network (an untrusted source) in a system call argument (a trusted sink). We test our hypothesis via a prototype implemen- tation, BotSwat, designed for the environment in which the vast majority of bots operate: home users’ PCs running Windows XP or 2000 [24]. BotSwat can monitor execution of an arbitrary Win32 binary and interposes on the run-time library calls (including system calls) made by a process. We consider data received over the net- work to be tainted and track tainted data as it propagates via dynamic library calls to other memory regions. We identify execution of parameterized bot commands when tainted arguments are supplied to selectgate functions, which are system calls used in malicious bot activity.
Our experimental results suggest that the presence of network packet contents in selected system call arguments is an effective indicator for malicious Win32 bots, including tested variants of agobot, DSNXbot, evilbot, G-SySbot, sdbot, and Spybot. Bots from these families constitute 98.2% of malicious bots seen in the wild [17]. While these bots may implement commands in significantly different ways, similar- ities in the way they respond to external control allow a single approach to identify them. Additionally, the thousands of variants of each such family generally differ in ways that will not affect our ability to detect them; this is in contrast to tradi- tional anti-malware signature scanners which may require a distinct signature for each variant [35]. Moreover, our generic approach does not rely on a particular C&C communication protocol (e.g., Internet Relay Chat (IRC)) or botnet topology (e.g., centralized).
Since our prototype implementation only has visibility into memory-copying calls made via a Dynamically Linked Library (DLL), we introduce strategies to coun- teract the effects ofout-of-bandmemory copies – those which occur outside of the interposition mechanism. In particular, we performcontent-based tainting, which considers a memory region tainted if its contents are identical to a known tainted string. We also introducesubstring-based tainting, whereby a region will be con-
sidered tainted if its contents are a substring of any data received by the monitored process over the network. These strategies are applied upon calls by a monitored process intotaint propagation functions, which are DLL functions used to copy or convert the contents of memory. Applying these strategies allows us to effectively identify bot behavior even when all of the bot’s calls to memory-copying functions are out-of-band, which may occur if the bot statically links in C library functions.
Since BotSwat uses library-call-level taint propagation, bots could apply out- of-band encryption functions (e.g., XOR) to network data and consequently defeat detection by the prototype implementation. This is a limitation of our current test- ing platform rather than a deficiency in the characterization of bot remote-control behavior. Our testing of versions of agobot, which encrypt C&C communications via dynamic calls to the OpenSSL library, indicates that remote control behavior can still be identified (even when communications are encrypted), given visibility into the cryptographic function calls. Current botnet C&C communications tend to be unencrypted [18].
While both bots and benign programs may create files, interact with the network, and execute programs, we are able to separate bot behavior from that of benign pro- grams by distinguishing between remotely-initiated and locally-initiated actions. We tested applications typical to the target environment (home-user PCs) which exhibit extensive network interaction. Early testing revealed that a benign program may use some tainted value in a system call argument as a result of local user input. For exam- ple, when a user downloads a webpage via a browser then clicks on a hypertext link therein, the browser will consequently request the content stored at the linked URL. In so doing, the browser will invoke system calls (e.g.,connect,send) on tainted arguments (the URL). If user input were not tracked, this sequence of events would look similar to bot execution of the web download command. To account for this phenomenon in our experimental assessment, we designed and implemented a user- input module that identifies data values resulting from local user input as received via the keyboard or mouse. Theseclean stringsare used to identify instances of local control. Our testing of eight benign programs over a variety of activities common to those applications resulted in eight total flagged behaviors (five different) whereas testing six bots resulted in a total of 202 flagged behaviors (18 different).
In Sect. 2, we provide background information on bots. Section 3 describes our experimental method, and Sect. 4 details our prototype implementation. Our exper- imental results are given in Sect. 5. We discuss the potential for and challenges to applying our findings for real-time host-based bot detection in Sect. 6. Section 7 describes related work and Sect. 8 provides concluding remarks.