Detection and classification of exploit kits

Embodiments of the disclosure relate to the field of cyber security. More specifically, embodiments of the disclosure relate to a system for detecting anomalous, or more specifically, unwanted or malicious behavior associated with network traffic.

Over the last decade, malicious software has become a pervasive problem for Internet users as many networked resources include vulnerabilities that are subject to attack. For example, payloads downloaded while browsing the Internet may exploit these vulnerabilities by allowing a third-party to gain access to one or more areas within the network not typically accessible. For example, a third-party may exploit a software vulnerability to gain unauthorized access to email accounts and/or data files.

For instance, content (e.g., payloads within network traffic) received by a network device while loading an Internet web page may include an exploit kit, which may be understood as a self-contained framework designed to exploit known vulnerabilities and/or download and install additional malicious, anomalous or unwanted objects. Exploit kits, as well as the additional objects that may be downloaded, may attempt to acquire sensitive information, adversely influence, or attack normal operations of the network device or the entire enterprise network by taking advantage of a vulnerability in computer software.

For example, the user of a network device, e.g., a laptop, may activate (e.g., click on) a link while browsing the Internet. The link may open up a new window, or tab within the web browsing application, and redirect the user to an unwanted web page instead of loading the web page expected by the user. The redirect may perform additional actions that may include downloading and installing malicious, anomalous and unwanted payloads.

In current malware detection systems, exploit kit detection is based on a correlation of signatures of known exploit kits. However, in order to generate a signature for an exploit kit, the exploit kit necessarily must have been activated such that malicious, anomalous or unwanted behavior affected one or more network devices or the operation of the network itself. Therefore, current malware detection systems are unable to proactively detect exploit kits and prevent the download and activation thereof.

In some situations, a redirect, a hidden link on a web page or content that automatically downloads upon activation of a link, may enable a third-party to access one or more storage areas of the network device (e.g., contact list or password storage). As another example, through a redirect, a hidden link or automatically downloaded content, a third-party may gain access to the network to which the network device is connected (e.g., an enterprise network) through the network device without proper permissions. Stated generally, exploit kits and additional payloads downloaded in association with an exploit kit may affect the network device, an enterprise network to which the network device is connected, and/or other network devices connected to the enterprise network in a negative or anomalous manner.

Based on the shortcomings set forth above, current signature-based malware detection systems do not proactively detect exploit kits effectively in order to prevent the download thereof and/or the download of additional malicious, anomalous or unwanted payloads.

Embodiments of the invention are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:

FIG. 1 is an exemplary block diagram of an exploit kit detection system 110 .

FIG. 2 is an exemplary logic diagram of the exploit kit detection system 110 of FIG. 1 .

FIG. 3A is the first portion of a flowchart illustrating an exemplary method for detecting and/or classifying an exploit kit with the exploit kit detection system 110 of FIG. 1 .

FIG. 3B is the second portion of the flowchart of FIG. 3A illustrating an exemplary method for detecting and/or classifying an exploit kit with the exploit kit detection system 110 of FIG. 1 .

Various embodiments of the disclosure relate to a detection system that improves detection of exploit kits, particularly, exploit kits for which a signature has not previously been generated. Herein, an exploit kit may lead to infection of an endpoint device with malware, wherein “malware” may collectively refer to exploits that initiate malicious, anomalous or unwanted behaviors.

In one embodiment of the disclosure, the exploit kit detection system comprises one or more of an Abstract Syntax Tree (AST) generating and filtering logic, a correlation logic, a classification logic, an expert system and a dynamic analysis logic. The exploit kit detection system may capture network traffic addressed to one or more endpoint devices within a network (e.g., an enterprise network), parse HyperText Markup Language (HTML) source code within the network traffic, extract the JavaScript™ included within the HTML source code, generate an AST from the extracted JavaScript™ and filter the AST (e.g., the AST provides a standard form for the HTTP source code that is susceptible to analysis). The exploit kit detection system then correlates the filtered AST with ASTs of known exploit kits to determine whether a level of similarity (e.g., a score value based on a performed correlation, wherein the level of similarity may be represented as a percentage, which may be equal to or less than 100%) above a first threshold exists. When a correlation above the first threshold exists, the filtered AST is determined to be within a family of an exploit kit. Herein, it is advantageous to classify an AST that has at least a predetermined level of similarity (e.g., a percentage) with an AST of a known exploit kit as exploit kits may morph quickly. Therefore, as an exploit kit morphs, minor changes to the exploit kit do not prevent the exploit kit detection system from detecting and classifying the morphed exploit kit even though an exact AST has not yet been identified and stored for the exploit kit. Exploit kits that change, or morph, may be referred to as “polymorphic exploit kits.” The minor variations associated with a polymorphic exploit kit have previously made detection of versions of a polymorphic exploit kit for which a signature was not created very difficult. However, correlating the filtered AST with ASTs of known exploit kits enables the exploit kit detection system to account for the minor variations.

Additionally, the detected exploit kit may be used in future correlations with received network traffic. Therefore, the exploit kit detection system is able evolve automatically without the involvement of a network administrator.

Other embodiments may extract additional and/or alternative portions of the received network traffic. For example, an embedded object may be extracted from the HTML source code or from another portion of the received network traffic and analyzed with the exploit kit detection system. Another example may include the extraction of Flash components (e.g., graphics, text, animation, applications, etc.) from the HTML source code and analysis of the Flash components with the exploit detection kit system. Other HTML plug-ins may similarly be extracted, wherein a plug-in may be an application or applet design to extend the functionality of a web browser. Additionally, HTML is merely one example of one markup language used to create web pages. Therefore, alternative markup languages, such as eXtensible HyperText Markup Language (XHTML) may be extracted in place of, or in combination with, the HTML. Other programming languages, scripting languages and markup languages may be used (e.g., XML, Perl, Tcl, Python, PHP: Hypertext Preprocessor (PHP), etc.).

When the correlations do not reveal a level of similarity above the first threshold, the exploit kit detection system determines whether there is a level of similarity above a second threshold being lower than the first threshold. This second threshold signifies that the filtered AST includes some resemblance to a known exploit kit but the system does not have enough confidence to determine the network traffic includes an exploit kit without further analysis. Subsequently, the filtered AST is provided to an expert system which applies heuristic, probabilistic and/or machine learning algorithms to the filtered AST during analysis to further determine a likelihood of the filtered AST including an exploit kit and, if applicable, obtaining a context for dynamic processing. The context may include, but is not limited or restricted to, results of an n-gram analysis performed on the name of a file included within the received network traffic. Examples of heuristics that may aid in the determination of a score, as discussed below, include but are not limited or restricted to, the presence, or lack thereof, of: a redirection from a secured website (“HTTPS”) to an unsecured website (“HTTP”) or vice versa; a number of images above a predefined threshold; and/or POST requests for personal information.

When the expert system determines that a score for the filtered AST is above a third predefined threshold, the HTML source code associated with the filtered AST, the score and the context are provided to the dynamic analysis logic. When the expert system determines the score for the filtered AST is not above a third predefined threshold, the HTML source code associated with the filtered AST is provided to the dynamic analysis logic. The HTML source code is then processed within one or more VMs and monitoring logic monitors the processing for malicious, anomalous or unwanted behaviors. Such behaviors are recorded and upon completion of the processing (e.g., expiration of a predefined time or a certain number of actions have been performed), a score is determined that indicates whether the dynamic processing discovered an exploit kit. A user of an endpoint that was to receive the network traffic and/or a network administer may be alerted to the results of the processing via alert generated by a reporting logic. Such an alert may include various types of messages, which may include text messages and/or email messages, video or audio stream, or other types of information over a wired or wireless communication path. Additionally, when an exploit kit is determined to have been detected, a representation of the filtered AST may be stored for inclusion in future analyses of received network traffic.

As used herein, the transmission of data may take the form of transmission of electrical signals and/or electromagnetic radiation (e.g., radio waves, microwaves, ultraviolet (UV) waves, etc.).

I. Terminology

In the following description, certain terminology is used to describe features of the invention. For example, in certain situations, both terms “logic” and “engine” are representative of hardware, firmware and/or software that is configured to perform one or more functions. As hardware, logic (or engine) may include circuitry having data processing or storage functionality. Examples of such circuitry may include, but are not limited or restricted to a microprocessor, one or more processor cores, a programmable gate array, a microcontroller, a controller, an application specific integrated circuit, wireless receiver, transmitter and/or transceiver circuitry, semiconductor memory, or combinatorial logic.

Logic (or engine) may be software in the form of one or more software modules, such as executable code in the form of an executable application, an application programming interface (API), a subroutine, a function, a procedure, an applet, a servlet, a routine, source code, object code, a shared library/dynamic link library, or one or more instructions. These software modules may be stored in any type of a suitable non-transitory storage medium, or transitory storage medium (e.g., electrical, optical, acoustical or other form of propagated signals such as carrier waves, infrared signals, or digital signals). Examples of non-transitory storage medium may include, but are not limited or restricted to a programmable circuit; a semiconductor memory; non-persistent storage such as volatile memory (e.g., any type of random access memory “RAM”); persistent storage such as non-volatile memory (e.g., read-only memory “ROM”, power-backed RAM, flash memory, phase-change memory, etc.), a solid-state drive, hard disk drive, an optical disc drive, or a portable memory device. As firmware, the executable code is stored in persistent storage.

According to one embodiment, the term “malware” may be construed broadly as any code or activity that initiates a malicious attack and/or operations associated with anomalous or unwanted behavior. For instance, malware may correspond to a type of malicious computer code that executes an exploit to take advantage of a vulnerability, for example, to harm or co-opt operation of a network device or misappropriate, modify or delete data. In the alternative, malware may correspond to an exploit, namely information (e.g., executable code, data, command(s), etc.) that attempts to take advantage of a vulnerability in software and/or an action by a person gaining unauthorized access to one or more areas of a network device to cause the network device to experience undesirable or anomalous behaviors. The undesirable or anomalous behaviors may include a communication-based anomaly or an execution-based anomaly, which, for example, could (1) alter the functionality of an network device executing application software in an atypical manner (a file is opened by a first process where the file is configured to be opened by a second process and not the first process); (2) alter the functionality of the network device executing that application software without any malicious intent; and/or (3) provide unwanted functionality which may be generally acceptable in another context. Additionally, malware may be code that initiates unwanted behavior which may be, as one example, uploading a contact list from an endpoint device to cloud storage without receiving permission from the user.

The term “exploit kit” should be construed as a self-contained framework designed to exploit known vulnerabilities and/or download and install additional malicious, anomalous or unwanted objects. In particular, an exploit kit may comprise a plurality of scripts (e.g., written in PHP) that target specific vulnerabilities. These vulnerabilities are typically security holes in software applications such as Internet browsers (e.g., Internet Explorer, Google Chrome, Mozilla Firefox, etc.) or other software applications (e.g., Adobe PDF Reader, Adobe Flash Player, etc.). In some embodiments, an exploit kit will be downloaded onto an endpoint device after visiting a website. For example, upon activating a link (e.g., selecting to download data or merely clicking on an advertisement), the user may be redirected to various websites, which may also redirect the user to multiple servers. Upon encountering a compromised server, the exploit kit will be downloaded and run automatically such that malicious, anomalous or unwanted behavior results. For example, a plurality of popups may be generated, the user may be redirected again to various websites, or callbacks may be made to a server in an attempt to download payloads. Alternatively, an exploit kit may be downloaded with received network traffic, even from an uncompromised server, and attempt to create a communication line with a foreign server in order to download a payload. This action typically happens without the knowledge of the user and occurs automatically after the initial user interaction of visiting a particular website or activating a link. Exploit kits pose serious security threats as additional payloads downloaded as a result of the callback may attempt to steal sensitive information (e.g., credential information, financial information, etc.) or merely result in anomalous or unwanted behavior.

The term “processing” may include launching an application wherein launching should be interpreted as placing the application in an open state and simulating operations within the application. Processing may also include performing simulations of actions typical of human interactions with the application. For example, the application, “Google Chrome” may be processed such that the application is opened and actions such as visiting a website, scrolling the website page, and activating a link from the website are performed (e.g., the performance of simulated human interactions).

The term “network device” should be construed as any electronic device with the capability of connecting to a network, downloading and installing applications. Such a network may be a public network such as the Internet or a private network such as a wireless data telecommunication network, wide area network, a type of local area network (LAN), or a combination of networks. Examples of a network device may include, but are not limited or restricted to, a laptop, a mobile phone, a tablet, etc. Herein, the terms “network device,” “endpoint device,” and “mobile device” will be used interchangeably. The terms “mobile application” and “application” should be interpreted as software developed to run specifically on a mobile network device.

The term “malicious” may represent a probability (or level of confidence) that the object is associated with a malicious attack or known vulnerability. For instance, the probability may be based, at least in part, on (i) pattern matches; (ii) analyzed deviations in messaging practices or formats (e.g., out of order commands) set forth in applicable communication protocols (e.g., HTTP, TCP, etc.) and/or proprietary document specifications (e.g., Adobe® PDF document specification); (iii) analyzed header or payload parameters to determine compliance, (iv) attempts to communicate with external servers during dynamic processing, (v) attempts to access memory allocated to the application during dynamic processing, and/or other factors that may evidence unwanted or malicious activity.

Lastly, the terms “or” and “and/or” as used herein are to be interpreted as inclusive or meaning any one or any combination. Therefore, “A, B or C” or “A, B and/or C” mean “any of the following: A; B; C; A and B; A and C; B and C; A, B and C.” An exception to this definition will occur only when a combination of elements, functions, steps or acts are in some way inherently mutually exclusive.

The invention may be utilized for detecting exploit kits encountered as a result of browsing the Internet. As this invention is susceptible to embodiments of many different forms, it is intended that the present disclosure includes illustrative embodiments and general principles of the invention and is not intended to limit the invention to the specific embodiments shown and described.

II. General Architecture of an Exploit Kit Detection System

Referring to FIG. 1 , an exemplary block diagram of an exploit kit detection system 110 deployed within the network 100 is shown. In one embodiment, the network 100 may be an enterprise network that includes the exploit kit detection system 110 , a router 150 , an optional firewall 151 , a network switch 152 , and one or endpoint devices 153 . The network 100 may include a public network such as the Internet, a private network (e.g., a local area network “LAN”, wireless LAN, etc.), or a combination thereof. The router 150 serves to receive data, e.g., packets, transmitted via a wireless medium (e.g., a Wireless Local Area Network (WLAN) utilizing the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard) and/or a wired medium from the cloud computing services 160 and the endpoint devices 153 . As is known in the art, the router 150 may provide access to the Internet for devices connected to the network 110 .

In one embodiment, the network switch 152 may capture network traffic, make a copy of the network traffic, pass the network traffic to the appropriate endpoint device(s) 153 and pass the copy of the network traffic to the exploit kit detection system 110 . In a second embodiment, the network switch 152 may capture the network traffic and pass the network traffic to the exploit kit detection system 110 for processing prior to passing the network traffic to the appropriate endpoint device(s) 153 . In such an embodiment, the network traffic will only be passed to the appropriate endpoint device(s) 153 if the analysis of the network traffic does not indicate that the network traffic is associated with a malicious attack, anomalous or unwanted behavior, or, in particular, an exploit kit.

The exploit kit detection system 110 includes a communication interface 111 , a storage device 112 , an AST generating and filtering logic 113 , a correlation logic 114 , a classification logic 115 , an expert system 116 , a dynamic analysis logic 120 and a reporting logic 130 .

As shown, the exploit detection kit 110 is communicatively coupled with the cloud computing services 160 , the Internet and one or more endpoint devices 153 via the communication interface 111 , which directs at least a portion of the network traffic to the AST generating and filtering logic 113 . The AST generating and filtering logic 113 receives at least a portion of the received network traffic from the communication interface 111 and extracts the Javascript™ within HTML source code within the network traffic. The received network traffic may be in, for example, one or more packet capture files (PCAP files). Subsequently, the AST generating and filtering logic 113 generates an AST from the Javascript™. Finally, the AST generating and filtering logic 113 filters the AST, which may include, but is not limited or restricted to, removing hardcoded parameters or variables from the AST, determining and removing portions of the AST that are not accessible (e.g., dead code, typically construed as software code that does not affect the results of running the software code) and/or determining and removing infinite loops within the AST.

In one embodiment, the AST generating and filtering logic 113 may comprise a compiler. In a second embodiment, the AST generating and filtering logic 113 may comprise one or more software libraries (e.g., open source libraries).

The correlation logic 114 receives the filtered AST from the AST generating and filtering logic 113 and correlates the filtered AST with one or more entries in a database (e.g., the storage device 112 or a database stored within the cloud computing services 160 ). Each entry in the database represents an AST of a known exploit kit. The result of a correlation of the filtered AST and an entry in the database reveals a score indicating a prescribed score (e.g., a percentage, a numerical value, a weighted numerical value) that represents how similar the filtered AST is to the AST of the known exploit kit represented by the databasebase entry. In one embodiment, each database entry takes the form of a hash value (e.g., a MD5 hash value, a secure hash algorithm (SHA) hash value, etc.). In such an embodiment, the correlation logic 114 computes a hash value representing the filtered AST and performs the correlation of hash values. In other embodiments, other representations may be used in place of hash values. Additionally, the correlations between the filtered AST and the entries in the database may be of the entire filtered AST or may be of one or more portions of the filtered AST.

The correlation logic 114 subsequently analyzes the results of the correlations performed by the correlation logic to determine whether a correlation of the filtered AST and an entry within the database reveals a level of similarity above a first predetermined threshold (e.g., 60%, 70%, 80%, etc.). When there is a level of similarity above the first predetermined threshold, the correlation logic 114 passes information associated with the correlation to the classification logic 115 . The passed information may include the filtered AST, the entry within the database having a level of similarity above the first predetermined threshold with the filtered AST, and/or the score of the correlation. The classification logic 115 then acts to classify the filtered AST as part of the exploit kit family of the known exploit kit represented by the database entry.

Herein, the use of the correlation logic 114 to compare the filtered AST with ASTs of known exploit kits enables the exploit kit detection system 110 to proactively detect exploit kits. An exploit kit may change at a rapid pace such that a detected exploit kit may morph within a matter of days or weeks such that a strict use of signature matching will not be sufficient to detected the morphed version. Therefore, determining whether the filtered AST correlates with an AST of a known exploit kit to produce a level of similarity above a first predetermined threshold enables the exploit kit detection system 110 to, as discussed above, account for changes from a first version of the exploit kit to a second version. When the exploit kit morphs, it may maintain the same malicious, anomalous or unwanted effects. Therefore, the classification logic 115 classifies the santizied AST as a member of the exploit kit family of the exploit kit represented by the database entry. Furthermore, the classification logic 115 may create a new entry to be added to the database representing the exploit kit detected in the filtered AST. Therefore, the exploit kit detection system 110 continuously evolves as it detects variations in exploit kits.

When the correlation logic 114 determines that no correlation between the filtered AST and a database entry is above the first predetermined threshold, the correlation logic determines whether a correlation of the filtered AST and an entry within the database reveals a level of similarity above a second predetermined threshold being lower than the first predetermined threshold (e.g., 30%, 40%, 50%, etc.). When a level of similarity above the second predetermined threshold is present, information associated with the correlation, as discussed above, is passed to the expert system 116 .

The expert system 116 utilizes at least one of heuristic, probabilistic and/or machine learning algorithms to analyze the filtered AST for characteristics and/or attributes indicative of an exploit kit. Based on the results of the analysis, the score determination logic 118 of the expert system 116 determines a score indicative of the likelihood the filtered AST includes an exploit kit. For example, the AST analysis logic 113 may analyze the filtered AST for shell code patterns, No-Operation (NOOP) sleds, function calls known to be vulnerable, and/or perform an n-gram analysis on names of files received with the network traffic wherein the n-gram analysis results are correlated with known malicious class names (e.g., stored in the storage device 112 ).

Upon determination by the expert system that the AST is suspicious (e.g., a score for the AST generated by the expert system 116 signifying the likelihood the filtered AST includes an exploit kit is above a third predefined threshold), the HTML source code of the network traffic, the score and the context of the analysis are passed to the dynamic analysis logic 120 via the scheduler 119 . The scheduler 119 may configure one or more of VM 124 1 -VM 124 M (M≧1) with selected software profiles. For instance, the context of the analysis may be used to determine which software images (e.g., application(s)) and/or operating systems to be fetched from the storage device 123 for configuring operability of the VM 124 1 -VM 124 M .

Upon receiving information from the expert system 116 , the dynamic analysis logic 120 performs processing within one or more VMs (e.g., virtual processing) on the HTML source code represented by the filtered AST. Herein, the dynamic processing may occur within one or more virtual machine instances (VMs), which may be provisioned with a guest image associated with a prescribed software profile. Each guest image may include a software application and/or an operating system (OS). Each guest image may further include one or more monitors, namely software components that are configured to observe and capture run-time behavior of an object under analysis during processing within the virtual machine. During the dynamic processing, the network traffic is analyzed. In one embodiment, the monitoring logic 131 may record, inter alia, (i) the location from where the traffic originated (e.g., a trusted or an untrusted website), (ii) the location to where the traffic is being transmitted, and/or (iii) actions taken by received network traffic (e.g., attempts to access particular storage locations, install malware, open anomalous files, attempts to open additional Internet connections (e.g., TCP/IP connections), etc.

In one embodiment, the HTML source code is virtually processed in one or more of VM 124 1 -VM 124 M . The monitoring logic 121 monitors the processing such that any malicious, anomalous or unwanted behaviors, and any resulting actions, are recorded. In particular, the monitoring logic 121 may monitor processing of the HTML source code for anomalous traffic to be transmitted outside of the network 100 , e.g., callbacks to foreign and/or unknown servers. Callbacks to unknown servers may indicate, for example, an attempt by the HTML source code to download additional payloads which may include malware or software code that results in anomalous or unwanted behavior. Of course, additional malicious, anomalous or unwanted behaviors may be recorded by the monitoring logic 121 . In one embodiment, the storage device 123 or the storage device 112 may include predefined definitions and/or rules that indicate malicious, anomalous or unwanted behaviors the monitoring logic 121 is to record. These predefined definitions and/or rules may be continuously updated via software updates received via the cloud computing services 160 and/or via a network administrator (for example, using the Internet to transmit such).

Upon completion of the dynamic processing by the one or more VMs, the score determination logic 125 of the dynamic processing logic 120 determines a score for the HTML source code that indicates a level of suspiciousness for the HTML source code, which is attributed to the filtered AST. The determination of the risk level of the network traffic may be based on, inter alia, (i) the location from where the traffic originated (e.g., a known website compared to an unknown website), (ii) the location to where the traffic is being transmitted, and/or (iii) actions taken by received network traffic during processing (e.g., executable code contained in the network traffic attempts to execute a callback).

When the score indicates that the filtered AST is above a predetermined threshold level (e.g., a particular numerical score or within a predefined category such as “malicious”), the filtered AST, and optionally the dynamic results of the dynamic processing and the analysis of the expert system 116 , may be provided to a network administrator. In such a situation, when the network traffic represented by the filtered AST has not yet been provided to the endpoint device(s) 153 , the network traffic will not be provided to the endpoint device(s) 153 . In the situation in which the network traffic has been provided, an alert may be generated by the reporting logic 190 and transmitted to the endpoint device(s) 153 alerting the user of the inclusion of software the processing of which will result in malicious, anomalous or unwanted behaviors, and in particular, if the network traffic includes an exploit kit.

Furthermore, when the score of the filtered AST indicates the network traffic includes an exploit kit, the filtered AST along with, optionally, the results of the dynamic processing and/or the analysis performed by the expert system 116 may be passed to the classification logic 115 for the generation of a database entry detailing the exploit kit. Herein, the classification logic 115 may define a new exploit kit family or add the filtered AST to the exploit kit bearing the greatest similarity to the filtered AST.

When the score determined by the score determination logic 125 does not rise above a predetermined threshold (i.e., the HTML source code does not include an exploit kit or include software the processing of which results in malicious, anomalous or unwanted behaviors), the network traffic is passed to the endpoint device(s) 153 , if it had not previously been done.

The reporting logic 130 is adapted to receive information from the dynamic analysis logic 120 , the expert system 116 and the classification logic 115 and generate alerts that identify to a user of an endpoint device, network administrator or an expert network analyst the likelihood of inclusion of an exploit kit within received network traffic and, if applicable, the exploit kit family to which the detected exploit kit belongs. Other additional information regarding the exploit kit family may optionally be included in the alerts. For example, typical behaviors associated with the exploit kit family may be included.

Referring to FIG. 2 , an exemplary embodiment of a logical representation of the exploit kit detection system 110 of FIG. 1 is shown. The exploit kit detection system 110 includes one or more processors 200 that are coupled to communication interface logic 210 via a first transmission medium. Communication interface logic 210 enables communications with network devices via the Internet, the cloud computing services 160 and the one or more endpoint devices 153 . According to one embodiment of the disclosure, communication interface logic 210 may be implemented as a physical interface including one or more ports for wired connectors. Additionally, or in the alternative, communication interface logic 210 may be implemented with one or more radio units for supporting wireless communications with other electronic devices.

Processor(s) 200 is further coupled to persistent storage 230 via a second transmission medium. According to one embodiment of the disclosure, persistent storage 230 may include (a) the AST generating and filtering logic 113 ; (b) the correlation logic 114 ; (c) the classification logic 115 ; (d) the expert system 116 including the AST analysis logic 117 and the score determination logic 118 ; and (e) the dynamic analysis logic 120 including the monitoring logic 121 , one or more VMs 124 1 - 124 M and the VMM 122 . Of course, when implemented as hardware, one or more of these logic units could be implemented separately from each other.

Referring to FIGS. 3A and 3B , an exemplary method for detecting and classifying an exploit kit included in received network traffic using the exploit kit detection system 110 of FIG. 1 is shown. Each block illustrated in FIGS. 3A and 3B represents an operation performed in the method 300 of detecting and classifying an exploit kit included in received network traffic. Referring to FIG. 3A , network traffic is received by network 100 and captured by the network switch 152 . For example, the network traffic may be captured and sent to the exploit kit detection system 110 for processing prior to passing the network traffic to the endpoint devices 153 . Upon receipt of the network traffic, the AST generating and filtering logic 113 parses the network traffic (e.g., HTML source code) and extracts the JavaScript™ (block 301 ). At block 302 , the AST generating and filtering logic 113 generates an AST from the HTML source code. Additionally, the AST generating and filtering logic 113 filters the AST. As was discussed above, in one embodiment, filtering the AST code may refer to removing the hard-coded values within the AST.

At block 303 , the correlation logic 114 correlates a representation of the filtered AST with one or more entries within a database, wherein the each entry of the database represents a representation of an AST of a known exploit kit. At block 304 , a determination is made as to whether the correlation of block 303 resulted in a level of similarity above a first predetermined threshold between the representation of the filtered AST and an entry in the database. When a level of similarity above the first threshold occurred (yes at block 304 ), the filtered AST is classified as being part of the exploit kit family to which the exploit kit represented by the entry in database belongs.

When a level of similarity above the first threshold did not occur (no at block 304 ), a determination is made as to whether the correlation of block 303 resulted in a level of similarity above a second predetermined threshold between the representation of the filtered AST and an entry in the database. When a level of similarity above the second threshold did not occur (no at block 306 ), the filtered AST is determined to not include an exploit kit and the method 300 ends (block 307 ). When a level of similarity above the second threshold occurred (yes at block 306 ), the expert system analyzes the AST (block 308 in FIG. 3B ).

Referring now to FIG. 3B , as discussed above, the expert system analyses the AST by through the application of heuristic, probabilistic and machine learning algorithms (block 308 ). Upon completion of the analysis by the expert system (block 308 ), a determination is made as to whether the score of the AST exceeds a third predefined threshold (block 309 ). As discussed above, the third predefined threshold may indicate a level of suspiciousness of the AST. If the score of the AST analysis by the expert system exceeds the third predefined threshold (yes at block 309 ), the score, the context of the analysis and the HTML source code from the received network traffic are transmitted to the dynamic analysis logic (block 310 ). If the score of the AST analysis by the expert system does not exceed the predefined score (no at block 309 ), the HTML source code from the received network traffic are transmitted to the dynamic analysis logic (block 311 ).

At block 312 , the dynamic analysis logic processes the HTML source code in one or more VMs to determine whether the web content received and transmitted during processing of the HTML source code is malicious, anomalous or unwanted. For example, the monitoring logic within the dynamic analysis logic may monitor outgoing network traffic generated by the HTML source code looking for requests to automatically download additional payloads. In some instances, these payloads may be malicious software that is downloaded and installed into the system. Therefore, determining that HTML source code will attempt to download additional payloads on an endpoint device is advantageous and may assist in determining whether the HTML source code includes an exploit kit.

In the foregoing description, the invention is described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims.