pattern mining for future attacks€¦ · pattern mining for future attacks sandeep karanth...
TRANSCRIPT
Pattern Mining for Future Attacks
Sandeep KaranthMicrosoft Research India
Srivatsan LaxmanMicrosoft Research India
Prasad NaldurgMicrosoft Research India
VenkatesanMicrosoft Research India
J. LambertMicrosoft Corporation
Jinwook ShinMicrosoft Corporation
ABSTRACTMalware writers are constantly looking for new vulnerabil-ities in popular software applications to exploit for profit,and discovering such a flaw is literally equivalent to find-ing a gold mine. When a completely new vulnerability isfound, and turned into what are called Zero Day attacks,they can often be critical and lead to data loss or breach ofprivacy. Zero Day vulnerabilities, by their very nature arenotoriously hard to find, and the odds seem to be stacked infavour of the attacker. However, before a Zero Day attack isdiscovered, attackers stealthily test different payload deliv-ery methods and their obfuscated variants, in an attempt tooutsmart anti-malware protection, with varying degrees ofsuccess. Evidence of such failed attempts, if any, are avail-able on the victim machines, and the challenge is to discovertheir signatures before they can be turned into exploits. Ourgoal in this paper is to search for such vulnerabilities andstraighten the odds. We focus on Javascript files, and usinga combination of pattern mining and learning, effectivelyfind two new Zero Day vulnerabilities in Microsoft InternetExplorer, using code collected between June and November2009.
1. INTRODUCTIONConsider a malware-writer who wants to test a new vul-
nerability and turn it into an attack. In order to deliver theattack payload to a victim machine, the attacker could use apoorly validated Javascript form on a third-party web appli-cation, e.g., by using ”eval” in string input, and redirect thescripting engine to fetch and execute their code. Increas-ingly, Javascript is being exploited as a vehicle to mountreflected attacks (including XSS attacks) of this nature. Aspart of the attack, buffer overflow attempts, heap overflowattempts and heap sprays are inserted into the current exe-cution context, in the hope that they succeed in subvertingcontrol to execute attacker-inserted code. Attack payloadhas also been found in Javascript snippets in documents suchas Adobe PDF files. The SANS 2009 report lists exploita-
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.Copyright 20XX ACM X-XXXXX-XX-X/XX/XX ...$10.00.
tion of client-side vulnerabilities using vulnerable Internet-facing websites as the most important unmitigated cyberse-curity risk [16], forming over 60% of reported attacks, withweb-application vulnerabilities resulting in reflected attacksaccounting for over 80% of such vulnerabilities discovered.
Static analysis techniques [3, 10, 4, 9, 6] can identifyattack payload in many cases, when the code is availableahead of time. However, this is not a complete solutionfor web applications that include dynamic content, suchas context-sensitive advertisements. Imposing controls onhow and where dynamic code can be downloaded on a formmay be restrictive in practice, as only a small percentage ofthe downloaded code is malicious (0.06% based on our ownstudy, Section 4).
In order to mount a successful attack, a malware-writerwill need to prevent the detection of the attack payload byany protective software deployed on a victim (Note that theactual vulnerability itself will be new, and unknown to anysignature scanners). It is difficult in general for an attackerto write attack code that uses delivery methods that aresubstantially different from those that have worked in thepast. To work around this, a typical attacker uses a varietyof code-obfuscation techniques, such as introducing interme-diate variables to store string constants, removing literals,encryption etc., with varying degrees of success. Before asuccessful attack is developed, attackers may test a care-fully crafted version of the payload on a target configuration.This attempt may fail, but will leave the attack fingerprintsbehind on the victim machine. If these fingerprints can befound, they can provide valuable information about poten-tially dangerous zero-day vulnerabilities (ZDV), which areundisclosed to a software developer, for which no securitypatches or anti-malware protections are available. Based onour own observations, these events occur at extremely lowfrequencies, as attackers are careful about releasing themwidely before they work, and attackers may even wait formonths before the same vulnerability is tried again, using adifferent delivery mechanism.
Increasingly, malware writers are being hired by criminalorganizations with vested interests to indulge in targeted cy-bercrime [5]. In this market, ZDVs have a high premium,fetching upto $250000 in 2007 [12], and a consortium of in-dustry and researchers [13] are even attempting to legitimizethe disclosure of Zero Days with economic incentives. Highvalue ZDVs have the potential to cause significant damage,leading to data loss, data theft, data corruption and ma-nipulation and privacy breaches. As a leveraging tool for acyber criminal, they are only valuable as long as the par-
ticular vulnerability remains unpatched, and unknown toeverybody except the attackers. In this context, finding at-tempted ZDVs before they can be exploited becomes increas-ingly important.
As mentioned earlier, in practice, only a small percentageof downloaded Javascript is malicious. Further, maliciouspayload shares many common features with innocuous dy-namic code, and the challenge is to systematically separatethe two, and characterize and identify malicious Javascriptcode to find ZDVs. We approach this task with the intuitionthat it is possible to characterize the difference between ma-licious and benign Javascript. The difference may be small,but sophisticated statistical techniques can help magnify thisdifference and identify malicious payload with a high degreeof confidence.
To this end, we construct an alphabet of features or indica-tors (and some of their obfuscated variants) that correspondto Javascript codewords and functions that occur frequentlyonly in malicious payload, features that occur mostly in be-nign payload, and features that occur in both. Once wehave an alphabet, we estimate the co-occurrence statistics,i.e., the frequency of these features as patterns over thisalphabet. We use annotated data from a small sample ofknown malicious Javascript files, as well as a larger sampleof benign files, to learn a set of weights for these pattern-frequencies. With these weights, we develop a scoring tech-nique that discriminates malicious payload from benign ef-fectively, and prioritizes them based on their likelihoods ineach class. Using these patterns and weights, we test our al-gorithm on hundreds of thousands of unannotated Javascriptfiles collected over a period of 4 months, from heterogeneoussources, and score each of these reports accordingly.
Our main contribution is an automated prioritizationscheme for identifying malicious Javascripts. We developa scoring technique for Javascript that uses co-occurrencestatistics of features to assign a likelihood score to eachJavascript file. Our prioritizer ranks the output list ofJavascript files according to these scores; suspicious caseswith potential of being exploit-attempts on new ZDVs areassigned higher scores (and are pushed-up the ranked list).Our algorithm alleviates the massive manual effort requiredof security experts to detect ZDV exploit-attempts from alarge number of Javascript files (that pass through standardanti-malware signature scanners). For example, our algo-rithm surfaced a list of 384 new vulnerability candidatesthat were unknown to our anti-malware signature scanners,out of a total of 26932 code files. Importantly, we were ableto detect a new ZDV (unknown at the time of data collectionand testing, but disclosed subsequently) and an obfuscatedvariant of the ZDV; these were reported within the top 1%and 2% respectively of our prioritized reports. We demon-strate good precision and recall performance on annotateddata. Note that, when completely new attacks (using sub-stantially different payload delivery techniques) surface, weintroduce new features and retrain our model. The tech-niques developed in this paper have been incorporated in adiagnostic tool which is used on a day-to-day basis by secu-rity experts at Microsoft.
The rest of the paper is organized as follows: Section 2describes the characteristics of our dataset, with a specialemphasis on our selected features and presents our intuitionfor using co-occurrence statistics. In Section 3 we describeour method in detail, concentrating on both the training and
testing phases. In Section 4 we describe our data collectionand the results of applying our method to this dataset, alongwith a sensitivity study. Section 5 presents related research,followed by conclusions and future work in Section 6.
2. BACKGROUNDIn this section, we explain our intuiton for using the co-
occurence of features as a discriminatory basis for classifyingJavascript payload. We collect Javascript internet browserattack data, obtained from Microsoft customer reported in-cidents, submissions of malicious code and Windows errorreports, between July and November 2009. We start withhundreds of thousands of Javascript code samples, and applya filter to identify Javascript files that are interesting from asecurity perspective, using a list of code features or findings.These features are selected intuitively to represent: (i) a mixof commonly occuring actions in interesting Javascript code(both in benign and malicious), (ii) features that largely oc-cur only in benign code, and (iii) features that are largelyindicators of malicious attack payload. A Javascript ‘trans-action’ is a snippet of Javascript code that contains one ormore findings. Each transaction represents around 20 linesof Javascript code. After filtering, around 130000 transac-tions were collected in the period of July-November 2009.
The Javascript features are listed in Table 1. For example,in a typical heapspray attempt, an attacker is likely to usefeature 28 (a new array call to allocate memory, which is afeature of any Javascript which requires dynamic storage)along with features 20 and 14 (unescape to decode encodedstrings, and NOPs). Our choice for three kinds of features ismotivated by our observation that using only features thatoccur frequently in malicious code snippets leads to detec-tion of a lot of false positives, as benign code also containsmany of these features. Similarly, using only the subset offeatures in the malicious list that do not occur (or occur withlow frequencies) in the benign samples leads to substantiallymany false negatives, often all-together missing the ZDV at-tempts. A mix of features allows a more robust statisticalcharacterization of Javascript files. Table 2 shows a sub-set of 7 commonly occurring features in a Javascript attackthat tries to exploit three different known vulnerabities inthe Microsoft Internet Explorer browser, prior to October2009 (Source: National Vulnerability Database, CommonVulnerabilites and Exposures (CVE) with identifiers, CVE-2008-4844, CVE-2008-0015 and CVE-2009-0075). A codesnippet for this attack, with the some features highlightedis provided in Fig. 1.
Table 2 describes the marginal statistics of the selectedfeatures in malicious and benign code. Note that some ofthese features occur exclusively in malicious samples: fea-ture 14, which indicates injection of NOP-sled blocks, andfeature 17, which indicates shell code injection. However,both their frequencies are only about 60%; so if we restrictedour classifier to only these features we would miss around40% of the attacks. That said, whenever 14 and/or 17 oc-cur(s), the Javascript transaction should be given a highscore (marking it as highly suspicious). On the other hand,feature 23 (that indicates definiton of a Javascript class orfunction) and feature 18 (call to a substring function) bothhave comparable frequencies in malicious and benign sam-ples; hence they do not, by themselves, add much valuefor discriminating malicious cases from benign. Feature 28(which represent allocation of memory) and feature 20 (a
Id Feature Description Id Feature Description
1 document.write Write HTML 18 substr Extracts charactersexpression from a stringto document
2 evaluate Evaluates and/or 19 shellcode Shell codeexecutes a presencestring in JS string
3 push Add array 20 unescape Decode anelements encoded string
4 msDataSourceObject ActiveX object for 21 u0A0A u0A0A Injection ofMicrosoft web characters 0A0Acomponents
5 setTimeout Evaluates expression 22 CompressedPath Download pathafter timeout property on an
ActiveXObject
6 cloneNode Create object copy 23 function Function orclass definition
7 createElement Create HTML element 24 shellexecute Call Shell API
8 window Current Document 25 u0c0c u0c0c Injection ofobject characters 0c0c
9 getElementbyId Get an element 26 replace Replace a matchedfrom the substring withcurrent document a string
10 object Error JS exception 27 Collab.CollectEmailInfo Adobe Acrobatobject method for
for email details
11 u0b0c u0b0b Injection of 28 new Array Heap memorycharacter 0b0c0b0b allocation
12 CollectGarbage Call to garbage 29 u0b0c u0b0c Injection ofcollector characters 0b0c0b0c
13 SnapshotPath Snapshot path 30 LoadPage Load a HTMLproperty on expressionan ActiveXObject
14 u9090 u9090 NOP injection 31 createControlRange Create a controlcontainer
15 new ActivexObject Instantiate 32 Click JS click eventActiveX object
16 navigator.appversion Get browser version 33 appV̇iewerVersion Get Adobe AcrobatReader version
17 0x0c0c0c0c Injection of 0c0c0c 34 function packed JS packer function
Table 1: Javascript Features
Id Feature % Count in % Count in %malicious benign Differencesnippets snippets
14 u9090 u9090 61 0 6117 0x0c0c0c0c 58 0 5118 substr 95 88 720 unescape 85 45 4023 function 97 99 226 replace 64 87 2328 new array 89 48 41
Table 2: Marginal statistics of some selected fea-tures found in CVE- 2008-4844, CVE-2008-0015 andCVE-2009-0075.
call to decode an encoded string) both occur in large num-bers of malicious samples (> 85%) but also occur in closeto 50% of benign samples; hence, while these features havepotential as discriminators of malicious cases from benign,when used alone, they can lead to a substantial false positiverates. Similarly, feature 26, can be a useful discriminatoryfeature for benign code, but when used alone, it can resultin a high false negative rate.
The challenge is to build a classifier that can automati-cally select ‘interesting’ features to disambiguate maliciousscripts from benign ones. In this paper, we develop sta-tistical methods to identify significant ‘groups of features’in malicious and benign code-snippets. The essence of oursignificance test is to determine whether some groups of fea-tures occur with substantial statistical skew in the maliciousexamples as compared to the benign ones. Typically, theseskews are easier to detect in higher order-statistics than insingle (or marginal) feature statistics, and hence we use pat-
terns of frequently co-occuring features rather than individ-ual features. We illustrate this with an example. Table 3presents the co-occurence statistics of various combinationsof features 20 - unescape, 26 - replace, 28 - new array. Notethat the combination of features 20 and 28 is a stronger at-tack indicator (55% difference) than if they were consideredindividually (40−41% difference). Combined with other in-dicators of known heap sprays like nopsleds and shellcode,e.g., features 14 and 17, these become stronger indicatorsof malicious Javascripts. Using multiple features also buildsin robustness to new forms of obfuscation that may not bedirectly recognized by exact signature scanners. Further, acombination of all three features (20, 26, 28), for example,has a lower occurence in positive samples than any pair offeatures, highlighting the need for a weighted scoring tech-nique to automatically identify high-value indicators. In thispaper, we employ a scoring technique that converts the ob-served co-occurrence statistics into likelihood scores using adata set of annotated examples (marked benign or maliciousby a security expert).
As a final example, we examine a new zero-day vulnerabil-ity that surfaced on November 29th 2009 (CVE-2009-3672).The code for the vulnerability is given in Figure 2. This par-ticular attack can be encoded using features 18, 20, 23 and28. We show later in Section 4 that we were able to detectthis exploit using our method based on a weighted combi-nation of features. We explain our classification method indetail in Section 3 next.
3. METHODOur goal is to identify high-value malicious Javascript pay-
load from our collected samples and look for future attacksignatures. The overall approach consists of a training phaseand a ranking phase. In the training phase, we use a set of
Figure 1: Example of exploit code for three vulnerabilities CVE- 2008-4844, CVE-2008-0015 and CVE-2009-0075 (with some features highlighted).
Pattern Description % Count in % Count in %malicious snippets benign snippets Difference
20, 26, 28 unescape, replace, new array 49 23 2620, 26 unescape, replace 51 37 1420, 28 unescape, new array 83 28 5526, 28 replace, new array 54 40 14
Table 3: Co-occurrence (or higher-order) statistics of features found in CVE- 2008-4844, CVE-2008-0015 andCVE-2009-0075.
annotated transactions to learn a probabilistic model for thedata (Algorithm 1). In the ranking phase, we prioritize theunannotated transactions based on their likelihood scoreswith respect to the learnt model (Algorithm 2). This sec-tion presents details of the training and ranking phases inour method.
We begin with an overview of the general procedure. Forthe training phase, we are given annotated sets of positivetransactions (S+) and negative transactions (S−). As men-tioned earlier, each transaction corresponds to a set of find-ings in a snippet of Javascript code. It is is essentially a col-lection of items (or symbols) over a finite alphabet (say A).In our context, the alphabet A is the universal set of findingsor features which are identified as relevant for disambiguat-ing malicious scripts from benign ones. These features wereselected from our annotated samples statistically.
An itemset is a non-empty set of items, e.g., α =(A1. . . . , AN ), Ai ∈ A, i = 1, . . . , N denotes an N -itemsetor an itemset of size N . Given a collection of transactions(say D) the frequency of α in D is the number of transac-tions that contain (or support) α. Patterns whose frequency
exceeds a user-defined threshold are referred to as frequentitemsets. In our context, a frequent itemset is simply a groupof features that co-occur frequently in the Javascript snip-pets. The goal of the training phase is to estimate whichgroups of features correlate strongly in the positive exam-ples but are absent (or are weakly correlated) in the neg-ative examples, and vice versa. Based on these, we buildseparate probabilistic models for the positive and negativeexamples. During the ranking phase, we pass each test pointthrough these models, obtain likelihood scores for the point(under the positive and negative models) and calculate thecorresponding likelihood ratio (positive score over negativescore). We then rank the test points in decreasing order oflikelihood ratios.
The main steps in the training phase are listed in Algo-rithm 1. Input to the training phase are sets S+ and S−of positive and negative training transactions, along with auser-defined maximum size N of patterns to be considered.Typical values we use in our experiments are N = 5 orN = 6. The first steps (lines 1, 2, Algorithm 1) compute thefrequent itemsets for both data sets S+ and S−. The the task
Figure 2: Exploit code for ZDV CVE-2009-3672.
Algorithm 1 Training algorithm
Input: Data set of positive examples (S+), data set of neg-ative examples (S−), maximum size of patterns (N)
Output: Generative models Λ+ (for S+) and Λ− (for S−)1: Find the set (F+) of frequent itemsets in S+ of size N
or less, using a frequency threshold of|S+|2N
2: Find the set (F−) of frequent itemsets in S+ of size N
or less, using a frequency threshold of|S−|2N
3: Associate each αj in F+ ∪F− with an IGM Λαj (basedon Definition 1)
4: Keep only ‘significant’ patterns in F+ and F− (based onEq. 2)
5: Keep only ‘discriminating’ patterns in F+ and F− byremoving patterns common to both
6: Build a mixture (Λ+) of significant IGMs (Λαj , αj ∈F+) for S+ (using Eqs. 3–5)
7: Build a mixture (Λ−) of significant IGMs (Λαj , αj ∈F−) for S− (using Eqs. 3–5)
8: Output Λ+ and Λ−
of discovering all itemsets whose frequencies exceed a givenuser-defined frequency threshold is a well-studied problem indata mining called Frequent Itemsets Mining (FIM) [1]. Weuse a standard procedure known as the Apriori algorithm forobtaining frequent itemsets in the data [1]. We choose theFIM framework for computing co-occurences, over comput-ing joint probability estimates, as we do not want to makeany assumptions on the underlying distributions of the find-ings, and efficient algorithms are available to compute thesefrequencies.
For each pair (itemset, frequency), we need a way of de-ciding if it is a useful discrimininating statistic. We use asignificance test to decide whether an itemset is interestingor not, rejecting all patterns whose frequencies are below anoise threshold, which corresponds to the likelihood that the
pattern occurs no frequently than background noise. In or-der to fix this threshold, we associate each frequent itemsetdiscovered with a simple generative model called an ItemsetGenerating Model (or IGM) [7]. Using IGMs, we build aplausible generative model for the itemset frequencies thathas the following properties:
1. The probability of a transaction is high whenever thetransaction contains the itemset of interest.
2. Ordering of transaction frequencies is preserved underthe data likelihoods suggested by their correspondingIGMs.
Note that our IGM model may not be the best genera-tive model that fits the data, as we are only interested inthresholding itemsets whose frequencies are not statisticallysignificant.
The main utility of the itemset-IGM associations of [7] isa test of significance for frequent itemsets in the data basedon a likelihood ratio test involving IGMs. This is importantbecause we only want to use patterns that are ‘signficant’in the sense that they could not have appeared with sucha frequency by random chance. We present the details ofthe IGMs and this connection next. As mentioned earlier,IGM Λα for itemset α is one under which the probability ofa transaction T is high whenever T contains α. An ItemsetGenerating Model (or IGM) is specified by a pair, Λ = (α, θ),where α ⊆ A is an N -itemset, referred to as the “pattern” ofΛ, and θ ∈ [0, 1] is referred to as the “pattern probability”of Λ. The class of all IGMs, obtained by considering allpossible itemsets of size N (over A) and by considering allpossible pattern probability values θ ∈ [0, 1], is denoted byI. The probability of generating a transaction T under theIGM Λ is prescribed as follows:
P [T | Λ] = θzα(T )
(1− θ
2N − 1
)1−zα(T )(1
2M−N
)(1)
where, zα(·) indicates set containment: zα(T ) = 1, if α ⊆ T ,and zα(T ) = 0, otherwise; and M denotes the size of thealphabet A. Observe that even for moderate values of θ(namely, for θ > 1
2N) the above probability distribution
peaks at transactions that contain α, and the distributionis uniformly low everywhere else. The itemset-IGM associ-ation is defined as follows:
Definition 1. [7] Consider an N-itemset, α =(A1, . . . , AN ) (α ∈ 2A). Let fα denote the frequencyof α in the given database, D, of K transactions. Theitemset α is associated with the IGM, Λα = (α, θα), withθα = ( fα
K), if ( fα
K) > ( 1
2N), and with θα = 0 otherwise.
In line 3, Algorithm 1, we associate each frequent itemsetwith a corresponding IGM as per the above definition. Thisitemset-IGM association has several interesting properties[7]. First, the association under Definition 1 ensures that or-dering with respect to frequencies among N -itemsets over Ais preserved as ordering with respect data likelihoods amongIGMs in I. Further, if the most frequent itemset is ‘frequentenough’ then it is associated with an IGM which is a maxi-mum likelihood estimate for the data, over the full class, I,of IGMs. (We refer the reader to [7] for theoretical detailsof the model and its properties).
Using the IGM-itemset association, it is possible to con-struct a significance test based on the evidence of at leastone reasonable model (namely the IGM) over that of a uni-form random source. This is the next step in our trainingphase (line 4, Algorithm 1). For a given user-defined level εof the test, an itemset α of size N with frequency fα in adata set of K transactions, is declared significant if fα > Γwhere Γ is given by
Γ =K
2N+
√(K
2N
)(1− 1
2N
)Φ−1(1− ε) (2)
where, Φ−1(·) denotes inverse of the cumulative distributionfunction (cdf) of the standard normal random variable. Thisis a standard error characterization for the standard normalrandom variable. For typical values of size ε of the test,size K of the given transactions data set and size N of theitemsets under consideration, the above expression tends tobe dominated by K
2N, and so, in the absence of any other
information, we use this as the first threshold for significanceto try in our algorithm. If the eventual model obtained istoo weak (because of either too few or too many significantitemsets) we can always go back to the significance testingstep and tune the set of significant episodes by selecting anappropriate value of ε.
Note that while IGMs are useful to assess the statisticalsignificance of a given itemset, no single IGM can be usedas a reliable generative model for the whole data. This isbecause, a typical data set, D = {T1, . . . , TK}, would con-tain not one, but several, significant itemsets. Each of theseitemsets has an IGM associated with it as per Definition 1.We suppose that a mixture of such IGMs, rather than anysingle IGM, can be a good generative model for D. Similarideas were used in a the context of stream prediction usingfrequent episodes in [8].
The final step in our training phase is the estimation ofa mixture of IGMs for each data set S+ and S− (lines 6, 7,Algorithm 1). We can think of this step as a simple itera-tive procedure that assigns weights to the signficant patterns
found in the data. Let Fs = {α1, . . . , αJ} denote a set ofsignificant itemsets in the data, D. Let Λαj denote the IGMassociated with αj for j = 1, . . . , J . Each sequence, Ti ∈ D,is now assumed to be generated by a mixture of the IGMs,Λαj , j = 1, . . . , J . Denoting the mixture of EGHs by Λ, andassuming that the K transactions in D are independent, thelikelihood of D under the mixture model can be written asfollows:
P [D | Λ] =
K∏i=1
P [Ti | Λ]
=
K∏i=1
(J∑j=1
φjP [Ti | Λαj ]
)(3)
where φj , j = 1, . . . , J are the mixture coefficients of Λ (with
φj ∈ [0, 1] ∀j and∑Jj=1 φj = 1). Each EGH, Λαj , is fully
characterized by the significant itemset, αj , and its cor-responding pattern probability parameter, θαj (cf. Defini-tion 1). Consequently, the only unknowns in the expressionfor likelihood under the mixture model are the mixture coef-ficients, φj , j = 1, . . . , J . We use the Expectation Maximiza-tion (EM) algorithm [2], to estimate the mixture coefficientsof Λ from the data set, D. Any other reweighting techniquecan also work equally well.
Let Φg = {φg1, . . . , φgJ} denote the current guess for the
mixture coefficients being estimated. At the start of the EMprocedure, φg is initialized uniformly, i.e. we set φgj = 1
J∀j.
By regarding φgj as the prior probability corresponding to
the jth mixture component, Λαj , the posterior probability
for the lth mixture component, with respect to the ith trans-action, Ti ∈ D, can be written using Bayes’ Rule:
P [l | Ti,Φg] =φgl P [Ti | Λαl ]∑Jj=1 φ
gjP [Ti | Λαj ]
(4)
After computing P [l | Ti,Φg] for l = 1, . . . , J and i =1, . . . ,K, using the current guess, Φg, we obtain a revisedestimate, Φnew = {φnew1 , . . . , φnewJ }, for the mixture coef-ficients, using the following update rule. For l = 1, . . . , J ,compute:
φnewl =1
K
K∑i=1
P [l | Ti,Φg] (5)
The revised estimate, Φnew, is used as the ‘current guess’,Φg, in the next iteration, and the procedure (namely, thecomputation of Eq. (4) followed by that of Eq. (5)) is re-peated until convergence. We use the above procedure toestimate separate mixture models for S+ and S−. The re-sulting generative models, Λ+ and Λ−, are the final outputsof the training phase (line 8, Algorithm 1).
We now describe the ranking phase of our procedure. Themain steps in the ranking phase are listed in Algorithm 2.Inputs to the ranking phase are the generative models Λ+
and Λ− obtained from the training phase and the set D oftest transactions that need to be prioritized. The first stepis to compute, for each test transaction T ∈ D, the like-lihoods under the positive and negative generative models(lines 1-3, Algorithm 2). Then we compute the correspond-ing likelihood ratio (line 4, Algorithm 2). Finally, we sortthe test cases in decreasing order of likelihood ratios (line5, Algorithm 2). This sorted list is the final output of ourranking procedure (line 6, Algorithm 2).
Algorithm 2 Ranking algorithm
Input: SetD of test cases, learnt mixture models from train-ing phase (Λ+ and Λ−)
Output: Prioritized list of test cases (D)1: for each test case T ∈ D do2: Compute likelihood P [T | Λ+] of T in Λ+ (based on
Eq. (1) for Λ+)3: Compute likelihood P [T | Λ−] of T in Λ− (based on
Eq. (1) for Λ−)
4: Obtain the likelihood ratio for T :P [T | Λ+]
P [T | Λ−]
5: Sort test cases in D in descending order of likelihoodratios
6: Output sorted list D
Note that the final prioritized list bubbles transactionsthat have likelihood high scores from the positive model andlower scores from the negative model. Transactions whichare more similar to our annotated S− will appear in thebottom of the list, and transactions that do not have distin-guishing features will closer to the middle.
3.1 Output filtering and AnalysisAfter the ranking phase, we examine the Javascript files
corresponding to the top ranked transactions using our sig-nature scanners. This output filtering step removes anyknown vulnerabilities for consideration as potential ZDVs.We observe that our method is useful in characterizing ourtransactions as follows:
• After training, we can run our testing algorithm onthe training set itself, to validate if our learnt modelcan recall all annotated transactions accurately. If anyannotated transactions are classified otherwise (e.g.,S+ as S−), an expert can inspect them and check ifthe samples are internally consistent. This is useful tocheck the correctness of the training set.
• At the next level, after we run our prioritization andclassification algorithm on the test data, and run oursignature scanners and any other anti-malware pro-tection on the top results, the remaining top resultscan either be new ZDVs, or simply known signa-tures/attacks that are not in our database yet, andsuggest update our anti-malware signature database.Any ZDVs found will be extremely useful in any case.
Finally, as noted earlier, our results are sensitive to thechoice of findings exposed in our alphabet. A completelynew method of delivering a ZDV, which bears no statisticalsimilarities to any existing attack, will not be identified byour method. However, we expect to periodically update ourset of findings, in response to trends observed in incidentreports and advisories.
4. EVALUATIONIn this section we present results from applying our meth-
ods to sample IE attack data obtained from customer re-ported incidents, submissions of malicious code and win-dows error reports collected between July and November2009. We present the characteristics of the data observed,in Section 4.1, and describe our training and validation ex-periences in Section 4.2. We presents results on detectingZDVs in our test data in Section 4.3 and follow it up with
Data Date All Malicious Benign Avg. size ofSet Range ’09 cases cases cases transactions
Train Jul-Oct 13543 839 12704 11Test Aug-Nov 26932 453 26479 6
Table 4: Data characteristics
a discussion on the scope and limitations of our approach,and a comment on adversial manipulation in Section 4.4.
4.1 Data CharacteristicsThe characteristics of the data used in our evaluation are
listed in Table 4. The Train Data consists of 13500 snippetsof Javascript code, which were filtered from a larger set ofsamples collected between July and October 2009. Similarly,the Test Data, which contains 26932 snippets of Javascriptcode, was collected from August to November 2009. Notethat both data sets do not overlap, in the sense that, thecode snippets in the two sets are distinct. During the samplecollection phase, a custom Microsoft deobfuscator was usedto identify obfuscation attempts. Each dataset was filteredbased on a list of signatures of known cases. This gave usthe positive (malicious) and negative (benign) labels neededfor our evaluation. We extract the features for each snippetbased on the alphabet of Table 1, and construct appropriatetransactions of findings for each code snippet. The averagesize of transactions (i.e. the average number of findings persnippet) is also listed in Table 4.
The Test Data contains two snippets of Javascript thatcorrespond to two new exploit attempts of a previously un-known Zero Day Vulnerability in Microsoft Internet Ex-plorer – CVE-2009-3672. (See Section 2 for an exam-ple code snippet). These attempts first surfaced on 29,November 2009. Prior to this date, no signatures wereavailable for these attacks (i.e., our signature scanners la-belled them as benign). The CVE description for the ZeroDay Vulnerability can be found at http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3672 : Microsoft Inter-net Explorer 6 and 7 does not properly handle objects inmemory that (1) were not properly initialized or (2) aredeleted, which allows remote attackers to execute arbitrarycode via vectors involving a call to the getElementsByTag-Name method for the STYLE tag name, selection of the sin-gle element in the returned list, and a change to the outer-HTML property of this element, related to Cascading StyleSheets (CSS) and mshtml.dll, aka ”HTML Object MemoryCorruption Vulnerability.” We show later in this section thatour method was successful in detecting both the new exploitsas attacks.
4.2 Training and validationDuring the training phase, we used the Train Data
a;gorithm to learn the model. The maximum size of pat-terns was fixed at 5 and the number of iterations for theEM algorithm was fixed at 100. The first step in our evalua-tion is to validate the stability of the classifier learnt. This isa key step in the model-building phase since, based on justthe training data, we need to determine whether the trainingdata was sufficient for the choice of parameters used. Valida-tion involves randomly splitting the training set into 2 partsand using one part for learning the model, and the secondpart for evaluating performance under the learnt model. Weexpect that if the statistical estimation stabilizes, we should
0
0.2
0.4
0.6
0.8
1
0.2 0.4 0.6 0.8 1
Pre
cisi
on
Recall
50-50-a50-50-b50-50-c75-25-a75-25-b
Figure 3: Cross validation results: Precision v/s Re-call plots obtained by varying the classifier thresholdfor different splits of data into training and valida-tion sets.
get comparable results on different instances of random split-ting of training data.
In our validation experiments, we generate 3 instances ofrandom 2-way 50-50 splits and 2 instances of random 2-way75-25 splits of the Train Data (These are referred to as 50-50-a, 50-50-b, 50-50-c, 75-25-a, 75-25-b and 75-25-c in thefigures). In all the instances, the first parts (of size 50%or 75%) were used to train the corresponding models andthe second parts (of size 50% or 25%) were used for valida-tion. The cross-validation results are plotted in Fig. 3 in theform of precision v/s recall graphs. The different points ineach curve correspond to the use of different thresholds onthe likelihood ratios computed in line 4, Algorithm 2. Themain observation is that the precision v/s recall behaviorfor all the instances are very similar – 100% precision canbe achieved with a recall in the 65%-70% range. Then, asthe threshold is relaxed (reduced) the algorithm will reportmore and more code snippets as malicious, thereby descreas-ing the precision of the classifier decision. The interestingregion in the operating characteristics of Fig. 3 is at a pre-cision of 90% and a recall of 70%, at the knee of operatingcurve (inflexion point). Moving substantially away from thisknee would impact both precision and recall. Observe thatoperating points which achieve high precision (even if atthe cost of some recall) are more important than those thatachieve high recall (at the cost of precision). A high pre-cision ensures that security experts do not have too manysuspicious reports to analyze by-hand. Moreover, since be-nign cases far exceed malicious cases, a high recall result(at the cost of lower precision) is trivial and useless to thesecurity expert looking for new ZDV exploits. In view ofthis, our result of 90% precision at 70% recall is very effec-tive from the point-of-view of detecting new ZDV exploits.The important empirical result here is that such operatingpoints were available (and identifiable) in all the instanceswe tested.
Finally, we plot the operating characteristic of the classi-fier using all of the Train Data in Fig. 4 – 100% of the datawas used to learn the model and the same data was used forplotting the operating curve as well. The general behavioris similar to the plots in Fig. 3 (with marginally better pre-
0
0.2
0.4
0.6
0.8
1
0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 1
Pre
cisi
on
Recall
D C B
A
Operating Characteristics
Figure 4: Finding an operating point for the classi-fier
Operating # Malicious # Known ZDV-I ZDV-IIPoint Cases Issues based
Reported on Sigs
A 5991 (22%) 286 (1.0%)√ √
B 624 (2.3%) 240 (0.8%)√ √
C 614 (2.2%) 237 (0.8%)√
×D 560 (2.0%) 232 (0.8%)
√×
Table 5: Results for detection of Zero Day Vulnera-bilities in Test Data
cision since we are using all of the training data). We nowselect some suitable operating points for our classifier – inFig. 4, these points are marked A, B, C and D. We basi-cally pick 4 points in and around the ‘knee’ of the operatingcurve. Each operating point corresponds to a threshold tobe used for the likelihood ratios during testing, In partic-ular, the thresholds for operating point A was 1.59, for Bwas 2.31, for C was 3.02 and for D was 3.74. In the nextsubsection, we demonstrate the performance of our classifierat these four points.
4.3 Detecting Zero Day VulnerabilitiesTable 5 shows the results obtained on the test data. The
first column mentions the operating point. The second col-umn quotes the number of malicious cases reported for thecorresponding operating point. The third column quotesthe number of issues (amongst those reported) that wereregarded as known issues based on a list signatures. Thefourth and fifth columns indicate whether the algorithm de-tected the two instances of the ZDV exploit in the TestData. As can be seen from the table, the first attack scenario(ZDV-I) was detected at all the operating points, while thesecond scenario (ZDV-II) was only detected at A and B (butnot at C or D). In all cases except operating point A, thenumber of malicious cases reported is small (just around 2%of 26932 cases). This demonstrates that while the methoddoes not report too many points as malicious, the ZDV casesalmost always remain at the top of the output list (within 1and 2% at a reasonable operating point).
4.4 DiscussionIn the absence of ground truth, i.e., since we do not know
if our test data has more ZDVs in it until it is disclosed, wecannot claim to be complete. Nevertheless, every transac-tion that has a high rank according to our algorithm, andis not filtered out by our signature scanners has the poten-tial to be a ZDV and is worth further investigation. Therobustness results from our cross-validation experiments, aswell as the discovery of a real ZDV in our data underline theutility of our methods, and offer hope.
As we point out that our methods are sensitive to thechoice of the features in our alphabet, and in the mix offeatures used for classification. The features we selectedin our training dataset, all occur frequently in the ZDVsdisclosed on the ZDI page. In general, our alphabet willalso need to be updated when new methods of deliveringattack payload are discovered, and we will need to retrainour models periodically.
Finally we observe that our methods have robustnessbuilt-in, evidenced by the discovery of two slightly differ-ent attack payloads that contained our ZDV. An adversarywho uses a mix of obsfuscation techniques will have to workvery hard to evade complete detection.
5. RELATED WORKIn this section we present related research in the context of
data mining for security, and Javascript attack detection andprevention. Machine learning and data mining techniqueshave been applied to various security problems [11], includ-ing anomaly detection, intrusion detection, attack graphanalysis, and analyzing audit trails for root kits, etc. Acomprehensive discussion of these techniques and their ap-plications is beyond the scope of this paper. The techniqueswe use in this paper, including frequent itemset mining [1]and our generative models [7] were presented earlier, whilethe learning component, with the expectation maximization,was developed for this tool.
In terms of other related work, in Argos [14] the authorspresent an x86 emulator for capturing and fingerprinting dis-closed ZDVs, to provide accurate input to signature scan-ners. The Zero Day Initiative [13] maintains a current list ofknown ZDVs, which provides economic incentives to anyonereporting a new ZDV.
Researchers have studied a variety of static and semi-statictechniques to address the misuse of Javascript language fea-tures that are used to exploit client-side application vul-nerabilities, as well as mount attacks against web applica-tions. We highlight some recent research in this context. InBlueprint [9], the authors propose an enhanced parser thatneeds to be installed on both clients and servers, which usesannotations to communicate an application developers in-tention to a client browser, with regard to where dynamiccode can be downloaded. This effectively prevents unautho-rized download, and an integrity checking function validatesinput to prevent code downloads. However, this solutionrequires changes to both servers and clients.
There are also techniques that only require changes onthe client browsers. In their work on staged informationflows [3], the authors present a combined static-dynamictechnique that checks downloaded code against specifiedintegrity and confidentiality requirements, and generatesresidual checks that can be validated at runtime. Tech-
niques such as Gatekeeper [6] and [10] concentrate on smallersafer subsets of Javascript, rewriting code or adding wrap-pers, by analyzing malicious code on the victim machine. InNozzle [15], heapsprays in particular are identified using alightweight interpreter, and malicious and benign code areclassified by characterising valid and invalid opcodes. In [4],the authors attach labels on sensitive information and iden-tify malicious code that attempt to write, over-write or sendthese objects over a network, in browser extension code.
While many of these techniques are very effective in prac-tice, a barrier to their adoption is the need to change browseror server code, or install new software on the clients. Ourwork is complementary to these efforts, as we are looking forthe vulnerabilities that are being tested by the Javascriptpayload, and as long as unpatched machines exist, the at-tacks will continue. Further, Javascript is not the only ve-hicle for delivering ZDVs, e.g., corrupt video or image files,and Microsoft word macros can all carry attack payload, andour technique can be adopted to look for findings in thesefiles.
6. CONCLUSIONSDetecting Zero Day Vulnerabilities is a critical problem
that confronts security response teams on an everyday basis.Malware writers are on the constant look-out for exploits ofnew (previously unknown) vulnerabilities, exploits which aredesigned to trick standard signature-based malware detec-tion techniques. In this paper, we develop methods, whichhave the potential for detecting the new vulnerabilities evenbefore they are successfully exploited in the field. Our meth-ods are based on a rigorous statistical characterization ofpreviously known exploits. We use a combination of fre-quent pattern mining techniques from data mining and gen-erative model estimation techniques from machine learningto develop a statistical filter for detecting malicious payloadintended to exploit a new vulnerability. Our results demon-strate that our techniques are robust and are able to detecthigh-value ZDVs in real-world data sets. Although this pa-per primarily focusses on detecting ZDVs in Javascript pay-load, we expect that our methods are equally applicable inseveral other contexts including malicious audio and videofiles, Microsoft Word and Excel macro viruses, etc.
7. REFERENCES[1] R. Agrawal, T. Imielinski, and A. Swami. Mining
association rules between sets of items in largedatabases. In Proceedings of the ACM SIGMODConference on Management of Data, pages 207–216,May 1993.
[2] J. Bilmes. A gentle tutorial on the EM algorithm andits application to parameter estimation for gaussianmixture and hidden markov models. Technical ReportTR-97-021, International Computer Science Institute,Berkeley, California, Apr. 1997.
[3] R. Chugh, J. A. Meister, R. Jhala, and S. Lerner.Staged information flow for javascript. In PLDI ’09:Proceedings of the 2009 ACM SIGPLAN conferenceon Programming language design and implementation,New York, NY, USA, 2009. ACM.
[4] M. Dhawan and V. Ganapathy. Analyzing informationflow in javascript-based browser extensions. InACSAC’09: Proceedings of the 25th Annual Computer
Security Applications Conference, pages 382–391,Honolulu, Hawaii, USA, December 2009. IEEEComputer Society Press, Los Alamitos, California,USA. http://dx.doi.org/10.1109/ACSAC.2009.43.
[5] J. Franklin, V. Paxson, S. Savage, and A. Perrig. Aninquiry into the nature and causes of the wealth ofinternet miscreants. In CCS ’07: Proceedings of the14th ACM conference on Computer andcommunications security, pages 375–388, New York,NY, USA, 2007. ACM.
[6] S. Guarnieri and B. Livshits. Gatekeeper: Mostlystatic enforcement of security and reliability policiesfor javascript code. In Proceedings of the UsenixSecurity Symposium, Aug. 2009.
[7] S. Laxman, P. Naldurg, R. Sripada, andR. Venkatesan. Connections between mining frequentitemsets and learning generative models. InProceedings of the Seventh IEEE InternationalConference on Data Mining ICDM 2007, pages571–576, Omaha, Oct. 2007.
[8] S. Laxman, V. Tankasali, and R. White. Streamprediction using a generative model based on frequentepisodes in event sequences. In Proceedings of the 14thACM SIGKDD International Conference onKnowledge Discovery and Data Mining (KDD’08),pages 453–461, Las Vegas, Aug. 2008.
[9] M. T. Louw and V. N. Venkatakrishnan. Blueprint:Robust prevention of cross-site scripting attacks forexisting browsers. In IEEE Symposium on Securityand Privacy, pages 331–346. IEEE Computer Society,2009.
[10] S. Maffeis and A. Taly. Language-based isolation ofuntrusted javascript. In CSF ’09: Proceedings of the2009 22nd IEEE Computer Security FoundationsSymposium, pages 77–91, Washington, DC, USA,2009. IEEE Computer Society.
[11] M. A. Maloof. Machine Learning and Data Mining forComputer Security: Methods and Applications(Advanced Information and Knowledge Processing).Springer-Verlag New York, Inc., Secaucus, NJ, USA,2006.
[12] C. Miller. The legitimate vulnerability market: Insidethe secretive world of 0-day exploit sales. In In SixthWorkshop on the Economics of Information Security,2007.
[13] T. Point. The zero day initiative.
[14] G. Portokalidis, A. Slowinska, and H. Bos. Argos: anemulator for fingerprinting zero-day attacks foradvertised honeypots with automatic signaturegeneration. SIGOPS Oper. Syst. Rev., 40(4):15–27,2006.
[15] P. Ratanaworabhan, B. Livshits, and B. Zorn. Nozzle:A defense against heap-spraying code injectionattacks. In Proceedings of the Usenix SecuritySymposium, Aug. 2009.
[16] SANS. The top cyber security risks 2009, Sept. 2009.