Ghost turns Zombie: Exploring the Life Cycle of Web-based Malware
Michalis Polychronakis∗ Panayiotis Mavrommatis† Niels Provos†
Abstract detecting drive-by downloads on billions of web pages. While the web provides information and services that en- In a drive-by download attack, a malicious web page ex- rich our lives in many ways, it has also become the pri- ploits a vulnerability in a web browser, media player, or mary vehicle for delivering malware. Once infected with other client software to install and run malware on the web-based malware, an unsuspecting user’s machine is unsuspecting visitor’s computer. By loading suspicious converted into a productive member of the Internet un- web pages with a web browser inside a virtual machine, derground. In this work, we explore the life cycle of web- we found several million web pages capable of compro- based malware by employing light-weight responders to mising vulnerable computer systems. capture the network profile of infected machines. Our While prior research has tried to understand the behav- results indicate that web-based malware provides a cor- ior of individual malware binaries, little work has been nerstone for large scale electronic fraud. It is used to done to understand the network-level behavior of a large exfiltrate address books of compromised machines cre- population of computer systems infected with a diverse ating databases of hundred millions of email addresses, set of web-based malware. To better understand this is- to form spamming botnets responsible for a significant sue, we instrumented our virtual machines with light- fraction of spam currently seen on the Internet, and also weight responders to capture and respond to any network to steal login credentials that can be directly monetized payloads sent to the Internet by malware installed as a or leveraged to turn more web servers into malware de- result of a successful drive-by download attack. Our re- livery vectors. sponders are capable of emulating HTTP, IRC, SMTP We support our findings by providing a broad overview and FTP sessions. For any protocols not directly emu- of the post-infection network behavior of web-based mal- lated, we also built a generic responder that captures all ware, as well as in-depth examinations of the botnets and other payloads. leaked information we found during the course of our Over the course of two months, we collected over study. 448, 000 responder sessions. We subsequently analyzed these sessions, looking at overall trends and perform- ing several in-depth case studies. Our analysis organizes 1 Introduction malware’s behavior into three categories: propagation, data exfiltration and remote control. We show how these A thriving Internet underground [6] has grown up in the aspects taken together provide a compelling perspective past several years, employing the hundreds of thousands on the life cycle of web-based malware. The observed of malware infected commodity PCs to provide an infras- malware activities range from capturing email addresses tructure for conducting a wide range of criminal enter- from compromised machines, to joining infected systems prises. Such activities range from carrying out electronic into botnets responsible for operating large-scale spam fraud through phishing, to sending out billions of spam campaigns. email messages. Furthermore, the botnets created by web-based mal- In previous work, we examined how vulnerable com- ware are not only controlled via traditional mechanisms puter systems become infected with malware simply by such as IRC, but often employ other protocols such as browsing the web [10, 11]. Our analysis was based on HTTP. Our in-depth examinations turned up a variety of ∗FORTH-ICS, Greece, email: [email protected] interesting trends, including rich data exfiltration activity †Google Inc., email: {panayiotis,niels}@google.com and the use of custom protocols for command and con-
W e b C o n t e n t
B r o w s e r H T T P r o x y W e b
p
M a c h i n e L e a r n i n g S c o r i n g
G
M a l w a r e e n e r i c
r o c e s s ( e s ) R e s o n d e r
p p
M a c h i n e
C a n d i d a t e U R L s
l e a r n i n g
V i r t u a l M a c h i n e
t r a i n i n g
S
M T P , IR C ,
F T P
V e r i fi c a t i o n
R e s o n d e r s
p
D a n g e r o u s U R L s Figure 2: Network flow in the verification component. Outgoing connections to known ports are forwarded di- rectly to the corresponding responder or the HTTP proxy. Figure 1: Overall system architecture. Using ma- All other connections are handled by the generic respon- chine learning techniques, suspicious URLs are selected der, which can potentially identify and hand off connec- among billions of web pages for verification in a virtual tions that use any of the emulated protocols to the appro- machine. priate responder.
trol communication. We believe these results provide the “distribution” sites, suspicious HTML elements, or the first large scale empirical look at web-based malware. presence of code obfuscation. The combination of these The remainder of the paper is organized as follows. In features is scored by a model trained on a specialized the next section, we provide a brief overview of our mal- machine-learning system [3]. URLs with a high score ware analysis and collection architecture. In Section 3, are considered potentially malicious, and are submitted we investigate the life-cycle of web-based malware based to the verification component for further analysis. The on broad trends in our data, and discuss in-depth case URLs that are verified to be malicious are then exported studies of botnets and data exfiltration activities. Finally, to Google Web Search and, via the Google Safe Brows- we discuss related work in Section 4 and conclude in ing API [1], to other clients. The verification results are Section 5. also used to retrain the machine learning model. To verify if a candidate URL is indeed malicious, 2 System Architecture we have deployed a network of client honeypots based on virtual machines running Windows and Internet Ex- We build upon a scalable system developed with the goal plorer. To start the verification of a URL, we load it with of detecting harmful URLs on the web. In this section, Internet Explorer, which is configured to use a web proxy we describe our extensions to this system to collect and running outside the VM. The proxy records all HTTP analyze malicious network activity occurring after infec- requests and scans all HTTP responses using several tion. To provide context for our research, we first give a anti-virus engines. New processes, file system changes, brief overview of the overall system described in depth in and registry modifications are monitored from within the prior work [10]. This is followed by a detailed descrip- VM. Upon infection, we typically find abnormal activ- tion of the light-weight responders which allow us to au- ity in all of the monitored areas. A combination of these tomatically capture the network-level activity of drive-by signals is used to decide whether the URL is malicious downloads. or not.
2.1 Overview 2.2 Responders Our system consists of an efficient first-pass filter fol- To better understand the purpose and effects of web mal- lowed by a verification component. Figure 1 provides an ware, we extended the verification component with light- overview of the system components and their interaction. weight responders, which provide fabricated responses The first-pass filter is essentially a mapreduce [5] over for commonly used protocols such as SMTP, FTP and billions of web documents. For each web page, we ex- IRC. Upon infection of the virtual machine, any traffic to tract several features, including links to known malware standard ports is forwarded to the appropriate handler, as shown in Figure 2: web traffic is handled by the HTTP components, report stolen information and credentials, proxy, port 25 traffic is redirected to the SMTP respon- or attempt to propagate further. der, and so on. In the following, we provide a large-scale analysis of Since malware may communicate over non-standard post-infection malware activity as observed by our light- ports or using custom protocols, all outgoing traffic to- weight responders. We aim to provide insight into what wards any port other than the standard ports of the emu- happens after a vulnerable system gets infected as a re- lated services is redirected to a generic responder. The sult of visiting a malicious URL, and how it interacts purpose of the generic responder is twofold: i) to hand with the Internet. We do not study malware in isolation, off connections over non-standard ports that use one of but as it behaves after compromising a typical user’s sys- the emulated protocols to the appropriate responder, and tem running as a virtual machine. For example, in most ii) to elicit further information about the malware from drive-by downloads, multiple malware components are connections to non-emulated services, or connections being installed at the same time.1 that use unknown protocols. Our network-level analysis of malware, i.e., malware’s Upon receiving a connection, the generic responder at- interaction with other hosts and our responders, is orga- tempts to heuristically identify the application-level pro- nized into three categories: propagation, data exfiltration tocol used. For client-initiated protocols, in which the and remote control. As we explore the post-infection ac- client first sends a message to the server (e.g., HTTP, tivity, we show how these behaviors taken together pro- IRC), the generic responder can determine which service vide revealing insights into the life cycle of web-based it should emulate by looking in the client’s message for malware. known protocol keywords and structure. For protocols in which the server initiates the dialog by sending a message to the client (e.g., SMTP, FTP), 3.1 Data Set the responder acts as follows: after it accepts a connec- Our analysis covers a two-month period, from January tion, if no data is received within a few seconds, the re- 17, 2008 to March 25, 2008. During this period, our vir- sponder assumes that the client is waiting for a message tual machines analyzed URLs from 5, 756, 000 unique from the server. In that case, the responder blindly ini- hostnames—we report on unique hostnames instead of tiates the dialog by sending a generic welcome banner unique URLs, as URLs from the same host usually in- message. Depending on the client’s response, the generic stall the same set of malware. There were 307, 000 host- responder can identify the actual protocol being used and names serving at least one harmful URL, while 152, 700 hand off the connection to the appropriate emulated ser- of these sites (49%) had URLs that resulted in HTTP vice. As discussed in Section 3, the generic responder requests initiated from processes other than the web successfully identified many HTTP and IRC connections browser. About 18, 000 sites (5%) had URLs that trig- over non-standard ports and handled them appropriately. gered responder sessions. The generic responder is useful even if the malware Across all URLs, the total number of responder ses- uses unsupported or unknown protocols. Without the sions with transmitted data exceeded 448, 000. There responder, we would observe just a connection attempt, were many more cases where malware made network with no transmitted data. However, by accepting all TCP connections without transmitting any data. For example, connections to any port, the generic responder can po- we observed connections to popular SMTP servers with- tentially elicit the first application-level message sent by out actual data transmission. We speculate that these are the malware, which may provide useful insight about the attempts to test the victim’s firewall configuration or In- intended activity. Indeed, as discussed in the following ternet connectivity. section, the generic responder captured several sessions of custom malware communication protocols over arbi- trary ports. 3.2 Network Characteristics We begin our analysis by providing high-level statistics 3 Life Cycle of Web-based Malware about the overall post-infection network activity of the analyzed URLs. Once web-based malware infects a computer, it often in- Figure 3 presents the destination port distribution of teracts with other hosts on the Internet to either report in- all outgoing connections from the virtual machine upon formation about the compromised system, or to receive infection. For each port, we report the number of unique instructions for further actions. For example, a newly 1We hypothesize the existence of malware that relies on the installa- infected computer is likely to become part of a botnet. tion of multiple components for becoming fully functional. Its purpose Web-based malware may also download other malware might not be discovered by analyzing individual binaries in isolation. es iial,w on awr omnctn with on communicating servers malware IRC found we Similarly, bers. euss sn ehooissc sPPadJSP, and PHP as communication flexible such implement can technologies authors POST malware Using or con- GET HTTP either the are requests. of in ports Most shown non-standard to is respectively. nections 6, number and port 5 destination Figures the to according ewtesdHT oncin to connections HTTP witnessed we rfcls biu.Freape nadto oport to addition in example, For the of obvious. purpose less the traffic making for probably non- — over are ports protocols standard standard numbers as well port for as destination reasons protocols custom in Potential diversity increased number. consider-the port without destination the inspection, ing payload classification The using made was connections. outgoing observed the post- malware’s behavior. of network nature infection obscure and indica- diverse is the and of tion contacted sys- of were total the A ports which destination URLs. different for multiple analyze names in- to host happened URL This tem from one port. bias that least any to at data removes found transmitted that we malware which stalling on names host (excluding malware HTTP/80). by used protocols Network 4: Figure than related less activity to with (ex- ports clarity, connections For outgoing HTTP/80). of cluding distribution Port 3: Figure Number of unique hostnames h xc itiuino TPadICconnections IRC and HTTP of distribution exact The iue4sostentokpooo itiuinof distribution protocol network the shows 4 Figure 10 10 10 2 3 4 10
21 22 25 SMB 37 82
50 83 85 111
nqehs ae aebe omitted. been have names host unique 135 44 139 443 445 ifrn ports. different 666
NETBIOS 808 1010 1207 1433 1800 1900
Destination Port 1935 2000 2007 2008 2014 2703
other 3014 3128 3460 3603
HTTP (nonstd) 4099 63 5588 6666 6667 SMTP te otnum- port other 7000
IRC 7070 MSSQL FTP
DCOM 7777 8000 8001 8008 8088 8181 8526 8888 9598 9898 416
80 31666 45221 60000 , in etndt o-tnadprs o ifrn HTTP different methods. for request ports, non-standard connec- to HTTP destined of tions distribution port Destination 5: Figure hr ftecnetos orsodn othe to corresponding connections, the one the of About support third tunnels. that constructing proxies for open method probably CONNECT for which probes also to We requests correspond CONNECT hosts. some infected re- witnessed the and from updates information or trieving commands sending for mechanisms contacted ports server malware. web-based IRC by of distribution The 6: Figure tdwt xlisaantWnosadMcootSQL Microsoft respectively. and servers, Windows against exploits associ- with commonly ated also are (MSSQL) 135 1433 and Ports (DCOM) vulnerabilities. Windows exploiting often are to which related (SMB), 445 and were (NETBIOS) connections 139 sig- ports the to of a half common observed About using we protocols. connections Windows 4, network further of Figure to number in Internet, nificant shown the As or LAN sys- same propagate. vulnerable the other for in scan either to tems, malware is of host activities a infecting network upon common most the of One Propagation and Discovery 3.3 oyi iue4 sdls oua rukonprotocols unknown or popular to less used 4, Figure in gory Number of unique hostnames sorrsodr onteuaeteepooos we protocols, these emulate not do responders our As 317 Number of unique hostnames 10 10 2 3 10 10 0 2 10 0
79 ifrn etnto ports. destination different 83 85 110 88 1000 89 90 1111 99 1299 666 1728 720 808 1820 856 1980 880 1989 999 1010 2008 1024 2569 1111 3029 1207 1234 3169 1850 3240 2007 2008 3525 2111 3670 2368 3921 3030 3032 3935 3128 IRC serverport 5853 Destination Port 3300 6660 3400 3700 6661 4099 6662 4309 6665 4424 4538 6667 5100 6668 5588 6669 5608 5977 6789 6948 7000 7000 7182 7012 7777 7045 7878 7531 8000 8001 7575 8008 7613 8015 7777 8016 8019 8001 8082 8040 8088 8181 other 8492 8282 9173 8526 9283 8888 8889 9667 8899 9669 9000 9999 9200 GET POST CONNECT cate- 9996 13786 10327 20733 17201 23574 19888 27000 65520 60000 observed only the first protocol packet.2 The majority of jan that uses the MAC address (here sanitized) of the in- probes were to IP addresses on the same network with fected computer as an identifier for retrieving targeted the virtual machine, which implies that most malware updates: first scan neighboring computers, either for vulnerable GET /geturl.php?version=1.1.2&fid=7493&mac=00-00-00-00- services or network shares with unrestricted access. 00-00&lversion=&wversion=&day=0&name=dodolook&recent=0 HTTP/1.1 Accept: */* 3.4 Reporting home User-Agent: Mozilla/4.0 (compatible; ) Host: loader.51edm.net:1207 Part of the malware life cycle consists of notifying its au- Cache-Control: no-cache thor upon successful installation. This activity accounted We also found malware utilizing custom communica- for the majority of the emails captured by our SMTP re- tion protocols for reporting home. In some cases, the sponders. Table 1 shows the most common email sub- malware reported successful infections using a custom jects we observed. The subjects of the captured emails XML-like format. Specifically, the captured connections signify this type of activity quite clearly: XP Hacked, of this particular protocol were destined to 129 remote or Installation Report. The email bodies usually contain hosts using 29 different destination ports. Two examples further information about the victim’s host, such as its IP of the transmitted data3 are shown below: address, access credentials, and the port numbers of any installed back doors. HGZ5.
1
Subject #Messages The leaked information includes the IP address, OS XP Hacked 390 version, country, and other machine properties. We ob- ProRat [...] 162 served several different instances in the above format Vip Passw0rds 98 with only slight variations in the field types and order. Log file from ... 82 Installation report 76 Another example of custom infection notification, ob- Perfect Keylogger [...] 47 served only on port 6346, looked as follows: Installation on XP succeeded 12 E g y S p y KeyLogger [...] 12 105|OnConnect|United States|SYSTEM|XP - SYSTEM INFECTADO 6 |0.0.0.0|Not Detected|4.0.4 (BAZ) Mais 1: XP 3 |United States|OnConnect| AVSXP 3 C-h-e-c-k-i-n-g:XP 2 In this case, different fields are separated using pipe ...:Noticia quentinha de:... XP 2 characters. There were also cases in which most of the contents of the captured stream consisted of binary data, Table 1: Top malware email subjects. with some interspersed ASCII strings representing ma- chine information. SMTP Server # Messages yahoo.com 436 3.5 Data Exfiltration google.com 118 tvm.com.tr 98 Moving from reporting successful installations to exfil- aol.com 82 hotmail.com 19 trating more sensitive information is the next logical step outblaze.com 8 in the malware life cycle. Many responder sessions con- globo.com 6 tained signs of data exfiltration, including browser his- tory files and stored passwords, usually captured by key- Table 2: Top second-level domains of the SMTP servers board loggers or browser hooks. As one of the email employed by malware. subjects — Vip Passw0rds — indicates, SMTP is one method of achieving this goal. We observed several The HTTP protocol is also frequently used to inform emails sending back stored passwords from the compro- malware authors about infections. The following exam- mised machine. ple shows a GET request made by the DoDoLook tro- 3Non-printable characters are represented as dots, and some of the 2We plan on emulating more protocols as part of future work. information was masked. The large number of POST requests in Figure 5 sug- IRCServer #Sessions gests that HTTP is also employed for sending sensitive irc.dal.net 109 undernet.irc.justedge.net 43 information back to data collection servers. Moreover, 72.9.146.134.tailormadeservers.com 40 almost all of the observed FTP sessions corresponded oslo.no.eu.undernet.org 35 to uploads of harvested data. The malware connected 42.32.1343.static.theplanet.com 14 dns2.labinahost.com 10 to our FTP responder, supplying a login and password, undernet.xs4all.nl 7 and started uploading data. We were able to analyze the irc2.saunalahti.fi 7 stolen information by accessing some of the FTP servers Tampa.FL.US.Undernet.org 6 that were still operational using the malware’s creden- primescratchcards.com 6 w0rm.UnionIRC.Net 6 tials. In the following, we give a few examples of the types Table 3: Top IRC servers used by malware. of information we found. Some of the servers func- tioned as drop boxes for exfiltrated email addresses from users’ address books, organized in separate files accord- 3.6.1 IRC Botnets ing to the name of the computer from which they were Internet Relay Chat provides the basis for the most com- harvested. One server had 4, 729 files containing more monly studied type of C&C communication. By join- than 250, 000 addresses, all dated within two days of our ing a predefined channel, each bot can receive commands inspection. This indicates that the server’s administra- from its author and send back collected information. We tors collect and remove the information regularly. How- observed IRC sessions to 90 servers, utilizing 1587 dif- ever, it also means that malware authors have a supply of ferent nicknames in 95 channels. Table 3 presents the valid email addresses and even their social context read- most frequently contacted IRC servers. As we can see ily available. from Figure 6, most of the IRC sessions use servers More sensitive information was found in extensive bound to well-known IRC ports, although there is a con- logs periodically uploaded by malware, containing the siderable number of IRC connections to non-standard victim’s IP address, DNS server, gateway, MAC address, ports. username, as well as the URL and intercepted form and We observed that some malware families use seem- password fields of any HTTP request made by the user’s ingly regular nicknames and channels on public and machine. We analyzed over 250 MB of logs from a single sometimes popular IRC servers. This saves the burden server, extracting user names and passwords of 500 users of running a dedicated IRC server, while at the same for over 250 unique sites, including myspace.com, time offers some degree of concealment among legiti- yahoo.com, live.com, google.com as well as mate users. On the other hand, we found cases using many online banking sites.4 Banking credentials can artificial nicknames, e.g., [0]USA|XP[P]152102 or be monetized easily, while even the recently introduced Inject-2l087876, that are usually unique to the in- two-factor authentication that relies on secure cookies fected host, and sometimes provide further information, cannot provide complete protection, since the adversary such as the victim’s IP address and OS. may decide to steal the cookie file, too. On the other hand, credentials to web content management systems can be used to turn more web servers into malware in- 3.6.2 HTTP Botnets fection vectors. Among the HTTP-based botnets we observed, a case of particular interest involved a botnet that was used for or- 3.6 Joining Botnets chestrating large-scale spam campaigns. Each bot peri- odically downloaded ZIP-archives with instructions on Self propagation, reporting, and data exfiltration are dis- participating in spam campaigns using HTTP requests concerting, but a more troubling aspect of malware lies like the following: in its ability to connect a compromised system to a net- GET /g/FA3521-9EE5C0-69ED87 HTTP/1.1 work of bots that can be collectively controlled by a sin- Host: 208.72.169.153 gle entity. Command and control channels can be imple- X-Flags: 0 X-TM: 34 mented using either well-known application-level proto- [...] cols, such as HTTP and IRC, or through custom com- munication mechanisms. In the following, we give an Each response contained a ZIP-archive containing overview of the different botnets we encountered. nine files with detailed instructions on how to partic- ipate in the spam campaign: 000 data22 - a list 4We reported the stolen credentials to Security Science who col- laborate with the FTC and FBI as well as banks to protect customers of domains and their authoritative name severs used whose credentials were exfiltrated. to form the sender’s email address, 001 ncommall
o
p l a d
Email Domain Frequency u
s s o o k
a d d r e b i s s
v u l n e r a b l e e m a l a d d r e
P C s o i o
l l e c t n
yahoo.com 28899 c
sbcglobal.net 14417
s
e b b a e d m a l w a r e
yahoo.co.uk 8939 w
i i o
n f e c t n
s o i o
a m c n fi g u r a t n
shaw.ca 8321 p
i s s s
e m a l a d d r e e
s
v u l n e r a b l e p a m
C s C & C
hotmail.com 6985 P
e b u g
korea.com 6041 d
i o i o
n f r m a t n
e b
yahoo.co.jp 5215 w
o o o k i s
p l a d c e
striker.ottawa.on.ca 4415 u
i
o i s s o s
v u l n e r a b l e c r e d e n t a l
l g n p a w r d
P C s o i o
l l e c t n web.de 4276 c
yahoo.co.in 4200
s
b a r t e r / e l l
o o i s
c m p r m e
s o i s
t l e n c r e d e n t a l
s s
e b e r v e r Table 4: Top domains out of 700, 000 email addresses w collected from a spam-sending botnet. Figure 7: An overview of the malware life cycle based - a list of common first names used as part of the on observations from light-weight responders. sender’s email address, 002 otkogo r - a list of pos- sible “from” names related to the subject of the spam ducting large-scale electronic fraud. campaign, 003 subj rep - a list of possible email sub- Stolen address books are used to create databases con- jects, 004 outlook - the template of the spam email, taining hundred millions of email addresses. This infor- config - a configuration file that instructs the bot how mation, together with the computational resources pro- to construct emails from the data files, how many emails vided by the compromised machines, is currently being to sent in total, and how many connections are allowed at used for sending a significant fraction of the email spam a given time, message - the message body of the spam currently encountered on the Internet. With access to lo- campaign, mlist - a list of email addresses to which to gin credentials, the malware can potentially gain access send the spam, and mxdata - a binary file containing in- to web servers which can be turned into additional mal- formation about the mail-exchange servers for the email ware delivery vectors. From this point of view, the life addresses in mlist. cycle of web-based malware may be self perpetuating. We downloaded about 700 such ZIP-files, amount- ing to approximately 700, 000 different email addresses. Table 4 shows the most frequently occurring email do- 4 Related Work mains. We reported our findings to another researcher5 who provided us with a set of 250 million email ad- Virtual machines, virtual honeypots, and lightweight re- dresses captured from the same botnet in only 24 hours. sponders have been used by several researchers to cap- We noticed that the most frequent domains captured by ture and better understand attacks [2, 9, 12, 14]. Pang us within an hour did not completely overlap with the et al. [8] used active responders emulating protocols as- larger data set. This indicates that the email addresses sociated with commonly exploited services to elicit at- are not handed out at random. tack payloads from darkspace traffic. Our light-weight As part of infecting the system, the malware at- responders are similar in that they respond to network tempted to install a malicious kernel driver named connections initiated by adversaries, in our case malware ntio922.sys but failed. To help the malware authors running inside a virtual machine. However, we use them debug their software, the installer attempted to upload a to analyze the post-infection behavior of malware, rather small memory dump file containing a stack trace in case than to capture new attacks. of a failed driver installation. To us, this indicates a high- Our previous work [10,11] analyzed the maliciousness level of sophistication on part of the malware authors. of a large collection of web pages. Although we pro- vided some details on the prevalence of malware, we did not give any insights on the network activities of mal- 3.7 Summary ware once installed on a system. While there is already Taking a step back, we outline how these individual significant research on malware analysis [4, 7, 15], our pieces might fit into a much larger puzzle. Figure 7 analysis focuses on a large collection of web-based mal- shows what we deem to be the life cycle of web-based ware and provides insights into the activities of currently malware. The malware is seeded to millions of users deployed malware. Our approach is much less sophis- from compromised web servers that infect new visitors. ticated than analysis systems that employ whole-system The infected PCs are transformed into a platform for con- emulation and information flow tracking, nonetheless us- ing a very simple approach based on light-weight respon- 5The researcher prefers to remain anonymous. ders provides interesting insights when applied to a large collection of malware. CWSandbox uses a similar ap- References proach [13] but unlike our system it hooks the malware [1] Google Safe Browsing API. http://code.google.com/ and emulates protocols inside the virtual machine. apis/safebrowsing/. [2] K. G. Anagnostakis, S. Sidiroglou, P. Akritidis, K. Xinidis, E. Markatos, and A. D. Keromytis. Detecting Targeted Attacks 5 Conclusion Using Shadow Honeypots. August 2005. [3] J. Bem, G. Harik, J. Levenberg, N. Shazeer, and S. Tong. Large Although malware analysis has developed into its own scale machine learning and methods. US Patent: 7222127. research area, resulting in increasingly sophisticated [4] M. Christodorescu, S. Jha, S. Seshia, D. Song, and R. Bryant. analysis techniques, we showed that simple approaches Semantics-aware malware detection. Security and Privacy, 2005 IEEE Symposium on, pages 32–46, 2005. motivated by low-interaction honeypots can yield a sur- [5] J. Dean and S. Ghemawat. Mapreduce: Simplified data process- prising amount of information on malware’s activities. ing on large clusters. In Proceedings of the Sixth Symposium on We explored the life cycle of web-based malware by em- Operating System Design and Implementation, Dec 2004. ploying light-weight responders to capture the network [6] J. Franklin, V. Paxson, A. Perrig, and S. Savage. An Inquiry into profile of infected machines. Our responders are capable the Nature and Causes of the Wealth of Internet Miscreants. In of emulating protocols such FTP, HTTP, IRC and SMTP Proceedings of the ACM Conference on Computer and Commu- as well as capturing payloads from any protocols not di- nications Security (CCS), October 2007. rectly emulated. [7] A. Moser, C. Kruegel, and E. Kirda. Exploring multiple execution paths for malware analysis. Proc. IEEE Symposium on Security We supported our findings by analyzing more than and Privacy, pages 231–245, 2007. 448 000 , responder sessions collected over a period of [8] R. Pang, V. Yegneswaran, P. Barford, V. Paxson, and L. Peterson. two months. Our analysis divided malware’s behavior in Characteristics of Internet background radiation. In Proceedings three different categories: propagation, data exfiltration of the 6th ACM SIGCOMM Conference on Internet Measurement and remote control. Our in-depth investigation of these (IMC), pages 27–40, 2004. areas allowed us to explore several different aspects of [9] N. Provos. A virtual honeypot framework. In Proceedings of the malware’s life-cycle. 12th USENIX Security Symposium, pages 1–14, August 2004. Besides notifying adversaries about compromised sys- [10] N. Provos, P. Mavrommatis, M. A. Rajab, and F. Monrose. All Your iFrames Point To Us. Technical Report provos- tems and exfiltrating sensitive data, web-based malware 2008a, Google Inc, 2008. http://research.google. often joins compromised hosts into botnets. These bot- com/archive/provos-2008a.pdf. nets make use of traditional C&C communication via [11] N. Provos, D. McNamee, P. Mavrommatis, K. Wang, and IRC, but are also using other protocols such as HTTP N. Modadugu. The ghost in the browser analysis of web-based to establish communication to a C&C server. One of the malware. In Proceedings of the First Workshop on Hot Topics in Understanding Botnets (HotBots), 2007. botnets we analyzed is currently responsible for a signif- icant fraction of spam on the Internet and demonstrated [12] M. A. Rajab, J. Zarfoss, F. Monrose, and A. Terzis. A Multi- faceted Approach to Understanding the Botnet Phenomenon. In surprising sophistication, even going as far as providing Proceedings of ACM SIGCOMM/USENIX Internet Measurement malware developers memory dumps of failed installa- Conference (IMC), pages 41–52, Oct., 2006. tions. [13] C. Willems, T. Holz, and F. Freiling. Toward Automated Dy- In future work, we plan on extending the protocol em- namic Malware Analysis Using CWSandbox. Security & Privacy ulation to more services and hope to increase our under- Magazine, IEEE, 5(2):32–39, 2007. standing of currently unclassified network communica- [14] V. Yegneswaran, P. Barford, and D. Plonka. On the Design and Use of Internet Sinks for Network Abuse Monitoring. In Pro- tion. Furthermore, the light-weight responders may pro- ceedings of the 7th International Symposium on Recent Advances vide additional signals for determining whether a URL In Intrusion Detection (RAID), September 2004. is indeed malicious, especially for cases where the pro- [15] H. Yin, D. Song, M. Egele, C. Kruegel, and E. Kirda. Panorama: cess activity and malware scanning provide insufficient Capturing System-wide Information Flow for Malware Detection information. and Analysis. In Proceedings of the 14th ACM Conference of Computer and Communication Security, October 2007.
Acknowledgments
The work of Michalis Polychronakis was supported in part by the project CyberScope, funded by the Greek General Sec- retariat for Research and Technology under contract number PENED 03ED440. M. Polychronakis is also with the Univer- sity of Crete. We would like to thank Oliver Fisher, Fabian Monrose, Moheeb Rajab, and the anonymous reviewers for their valuable feedback.