System and method for mitigating malware

Abstract

Particular embodiments described herein provide an electronic device that may be configured to receive script data, determine a checksum tree for the script data, compare each checksum of the checksum tree to one or more sub-tree checksums, and mitigate malware from the one or more sub-tree checksums. And assigning one or more classifications to the script data. In one example, the checksum tree is an abstract syntax tree.

Description

[0001] This application is a divisional application. The invention name of its parent application is “System and method for mitigating malware”. The application date of its parent application is February 2, 2016, and the application number of its parent application is: 201680024044.5.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Application No. 62 / 121,129, entitled “SYSTEM AND METHOD TO MITIGATE MALWARE,” filed in the U.S. Patent Office on February 26, 2015, and U.S. Non-Provisional Application No. 14 / 751,935, entitled “SYSTEM AND METHOD TOMITIGATE MALWARE,” filed in the U.S. Patent Office on June 26, 2015, which are incorporated herein by reference in their entireties. Technical Field

[0004] The present disclosure relates generally to the field of information security and, more particularly, to malware mitigation. Background Art

[0005] In today's society, the field of network security has become increasingly important. The Internet has enabled the interconnection of different computer networks around the world. In particular, the Internet provides a medium for exchanging data between different users connected to different computer networks via various types of client devices. Although the use of the Internet has transformed business and personal communications, it has also been used as a tool for malicious operators to gain unauthorized access to computers and computer networks and for the intentional or unintentional disclosure of sensitive information.

[0006] Malicious software ("malware") that infects a host computer may be able to perform any number of malicious actions, such as stealing sensitive information from an enterprise or individual associated with the host computer, spreading to other host computers, and / or assisting in distributed denial of service attacks, sending spam or malicious email from the host computer, etc. Thus, significant management challenges remain for protecting computers and computer networks from both malicious and unintentional exploitation of malicious software. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to provide a more complete understanding of the present disclosure and its features and advantages, reference is made to the following description read in conjunction with the accompanying drawings, wherein like reference numerals represent like parts, and wherein:

[0008] Figure 1 is a simplified block diagram of a communication system for mitigation of malware in a network environment in accordance with an embodiment of the present disclosure;

[0009] Figure 2 is a simplified block diagram of a detection module in a network environment according to an embodiment of the present disclosure;

[0010] Figure 3 is a simplified block diagram of a compiler module in a network environment according to an embodiment of the present disclosure;

[0011] Figure 4 is a simplified block diagram of a network detection module in a network environment according to an embodiment of the present disclosure;

[0012] Figure 5A is a simplified block diagram of a script according to an embodiment of the present disclosure;

[0013] Figure 5B is a simplified block diagram of another script according to an embodiment of the present disclosure;

[0014] Figure 5C is a simplified block diagram of an abstract syntax tree according to an embodiment of the present disclosure;

[0015] Figure 6 is a simplified flow chart illustrating potential operations that may be associated with embodiments of the present disclosure;

[0016] Figure 7 is a simplified flow chart illustrating potential operations that may be associated with embodiments of the present disclosure;

[0017] Figure 8 is a simplified flow chart illustrating potential operations that may be associated with embodiments of the present disclosure;

[0018] Fig. 9 is a simplified flow chart illustrating potential operations that may be associated with embodiments of the present disclosure;

[0019] Fig.10 is a block diagram illustrating an example computing system arranged in a point-to-point configuration in accordance with an embodiment of the present disclosure;

[0020] Fig.11 is a simplified block diagram associated with an example ARM ecosystem system-on-chip (SOC) of the present disclosure; and

[0021] Fig.12 is a block diagram illustrating an example processor core in accordance with an embodiment.

[0022] The figures of the drawings are not necessarily drawn to scale, as their dimensions may be varied considerably without departing from the scope of the present disclosure. DETAILED DESCRIPTION

[0023] Example Embodiments

[0024] Figure 1 1 is a simplified block diagram of a communication system 100 for mitigating malware in a network environment. The communication system 100 may include an electronic device 102, a security server 104, and a cloud service 106. The electronic device 102 may include a detection module 110, a tree generation module 112, a processor 114, and a memory 116a. The memory 116a may include a subtree checksum 118. The security server 104 may include a memory 116b, a compiler module 120, and a network detection module 122. The memory 116b may include a subtree checksum 118. The cloud service 106 may include a memory 116c, a compiler module 120, and a network detection module 122. The memory 116c may include a subtree checksum 118. A malicious device 126 may attempt to introduce malware to the electronic device 102. The malware may be in the form of a malicious script 128. The electronic device 102, the malicious device 126, the security server 104, and the cloud service 106 may be connected via a network 124. In one example, the malicious device 126 may be physically connected to the electronic device 102 (eg, via a universal serial bus (USB) type connection).

[0025] In an example embodiment, the communication system 100 can be configured to combat known malware threats and new malware variant threats (e.g., malicious scripts 128) from malicious devices 126 by using machine learning training to generate classification intelligence in the form of one or more checksum trees or abstract syntax trees (ASTs). Using the compiler module 120, the communication system 100 can determine a series of fuzzy checksums (e.g., subtree checksums 118) for each file (both malicious and safe) and track the overall prevalence of checksums on the checksum tree (e.g., AST created from script data). The tree generation module 112 can create a checksum tree for a script such as the malicious script 128. At runtime, using the detection module 110, the checksum tree can be interpreted and compared to checksums such as the subtree checksum 118. Any node or leaf of the checksum tree that matches a checksum in the subtree checksum 118 can be remembered and assigned a classification. The detection module 110 can be configured to perform statistical voting across various classifications that have occurred (e.g., identifying a series of matches that have occurred, such as there is a 90% probability that the file includes JS.Exploit.D, there is an 80% probability that the file includes JS.Exploit.Blacole.B, there is a 70% probability that the file includes JS.ExploitIFrame.A, etc.).

[0026] If the overall probability of detection is below a configurable threshold (e.g., below 90%), the detection module 110 may compute a more detailed checksum tree from the script data, serialize the checksum tree into a feature vector, and transmit the feature vector to the secure server 104 or cloud service 106, where a more comprehensive classification checksum tree may be created in the network detection module 122 and a more accurate classification decision of the script may occur. The term "feature vector" is intended to include a fixed-size list of attributes such as a checksum for each script. The detection module 110, compiler module 120, and network detection module 122 may be distributed across premise systems or network scanners (requiring high scanning performance and reasonably low memory footprint) and cloud services that may rely on more comprehensive and dedicated hardware to host significantly larger classification data. The supply of script data in feature vectors to the network detection module 122 allows the compiler module 120 to dynamically adjust and retrain the detection module 110 and the network detection module 122 at regular intervals. Data privacy is supported because only the vector of the irreversible fuzzy checksum is submitted to the cloud service 106 and the secure server 104, and the original file and any substrings thereof and its source URL do not need to be submitted.

[0027] Figure 1 The elements of the system may be coupled to each other via one or more interfaces using any suitable connection (wired or wireless) that provides a feasible path for network communication. Figure 1 Any one or more of these elements may be combined or removed from the architecture based on specific configuration needs. The communication system 100 may include a configuration capable of Transmission Control Protocol / Internet Protocol (TCP / IP) communications for transmission or reception of packets in a network. The communication system 100 may also operate in conjunction with User Datagram Protocol / IP (UDP / IP) or any other suitable protocol where appropriate and based on specific needs.

[0028] For purposes of illustrating certain example techniques of the communication system 100, it is important to understand the communications that may traverse the network environment.The following basic information may be considered as a basis from which the present disclosure may be properly interpreted.

[0029] Increased access to the Internet has had the unintended effect of increasing the reach of software programs that capture a user's personal information without the user's informed consent or damage a computer without the user's knowledge and informed consent. The term malware as used herein includes any type of software program that is designed to infiltrate, modify, alter, damage, or corrupt a computer system without the owner's informed consent, regardless of the software program's motivation and regardless of the consequences caused by the software program to the owner's device, system, network, or data.

[0030] Security systems are often used to try to detect the presence of malware. In some instances, security systems typically rely on detecting signatures in files being checked to determine whether a file is malware or contains malware. In some instances, security systems can use a checksum-based method to determine whether a file is malware. However, malware authors frequently change parts of malware files to avoid being detected by signature or checksum methods. New variants of known malware can be created by repackaging or compiling in short time intervals to circumvent signature-based or checksum-based detection and take advantage of delays in creating and distributing updated detection signatures or checksums. Various security systems attempt to offset the increased amount of new malware variants and samples by using more general and more heuristic detection. However, general detection suffers from the defect of requiring manual analysis of one or, in most cases, at least two malware variants in order to provide appropriate detection. In addition, heuristic detection suffers from the defect of false positives.

[0031] In addition, various security systems often rely on the use of software simulation. For example, in order to determine whether a script contains potentially dangerous behavior, a corresponding malware scanner can simulate the execution of the script in question within a safe, virtual simulation environment. This process can monitor what effect the executed script has on the simulation environment. For example, malicious Java scripts are often obfuscated, and only through simulation can the outer obfuscated shell of the script be removed to reveal the malicious content.

[0032] In order to emulate an environment such as a web browser, the system needs to emulate the functionality of the web browser being exposed to the script code running in the environment. Currently, this is done manually by malware researchers, (e.g., whenever a certain function is called by a known malware, the researcher developing detection for that malware family ensures that the emulation environment emulates that function). In addition to correct functional emulation, different variants and anti-emulation tricks implemented by malware must be accounted for, (e.g., by automatically generating script content using toolkits, by using random variable names, slightly changing the code using different deobfuscation keys, or changing the process flow, etc.).

[0033] Current approaches to manually authored functional emulation are reactive, error-prone, and expensive. Furthermore, full emulation of script content occurs at a high performance cost. What is needed is a system and method that uses checksums based on a generalized grammatical representation such as an AST to achieve active protection against new, zero-day malware variants without a separate reliance on emulation. It would be beneficial if regenerated or refactored variants of malware families or new malware that reuses components from previous malware families could be detected in a generic manner.

[0034] like Figure 1 The communication system for malware mitigation outlined in can address these problems (and others). Figure 1 In the communication system 100 of the present invention, in order to combat the malware threat and the new malware variant threat from the malicious device 126, the system can generate one or more standardized ASTs for the script content and calculate the checksum for the specified subtree of the generated AST. The standardized AST does not include script-specific content, such as variable or function names, and therefore the script-specific content does not affect the checksum calculation. By using this scheme, the system is able to detect malware based only on its structure and avoid full simulation, anti-simulation techniques, and negative performance impacts. The system can use machine learning training in the back end to generate the necessary classification intelligence. The system can determine a series of checksums for each specified subtree of the AST and track the overall prevalence on the entire malware training set and the prevalence on the clean training set. The system can then create a database of the most common checksums for each specified subtree (e.g., sub-number checksum 118). The accuracy of the checksum and analysis can be improved by specifying the "root" node (e.g., loop, function, if, etc.) of the additional subtree for which the checksum should be calculated. At runtime, the system can generate and traverse the AST for the script in question, calculate the checksum at the corresponding AST subtree, and compare the checksum against the checksum stored in the database. The corresponding AST subtree can depend on the trained database (e.g., the subtree arranged below a loop or function call node). Each checksum can be associated with a Bayesian score, and for each checksum match, the associated Bayesian score can be added to the overall malware probability.

[0035] The system can provide proactive protection by using a series of checksums that identify the closest relationship of new unknown malware to existing known malware variants and components. For example, a checksum calculated on malware variant M1 is likely to match a checksum calculated on a descendant malware variant M2, even if malware variant M1 has been extended with new code, code removed / changed, or regenerated (e.g., if created by exploiting a toolkit).

[0036] The ratio between the detection rate and the false positive rate can be configured as desired simply based on the number of checksums necessary to match on the analyzed script. For example, an aggressive detection can assign higher individual Bayesian scores to each checksum, so that fewer checksums need to be matched for a sample to be detected, while a more precise detection can assign lower scores to each checksum, requiring more matching checksums for detection. In addition, the associated Bayesian score can be defined individually for each checksum to reduce or increase the impact of a particular checksum on the overall probability of detection.

[0037] In some previous systems, the simulation environment had to be continuously expanded to be able to simulate the latest scripts. Each new or changed functionality provided by the scripting language itself or by the web browser needs to be added or adjusted in the simulation environment. When the current system analyzes the structure of the script content, the current system can be independent of the specific functional implementation. Classified content can be automatically trained by machine learning and can therefore be maintained relatively easily.

[0038] The classification for the system depends only on the checksums calculated for the AST and the corresponding Bayesian scores. As a result, the occupancy in memory and on storage can be kept very low. In addition, the occupancy in memory and on storage can be simply scaled by limiting fewer node types to calculate the checksum without changing the detection algorithm. The calculation and comparison of the checksums at the specified nodes in the AST and the AST have a much smaller impact on the overall performance than the full simulation of the script. Regarding memory occupancy, the performance ratio can be scaled by changing the number of checksums per AST. In addition, depending on the matching checksums, the system can allow the delivery of a list of malware family relationships, each with a relationship likelihood. That is, the system can return a list of relationship likelihoods (e.g., JS.Exploit.D": 90%, JS.Exploit.Blacole.B": 80%, JS.ExploitIFrame.A": 70%) instead of just returning a single detection name.

[0039] In addition, based on a reasonably sized (100,000+) collection of malware and benign file samples, classification data can be generated entirely through data mining and machine learning techniques without the need for manual rule creation. The system can use a training set of both known malicious and known benign script samples in the backend to generate the necessary classification intelligence. In one example, for each sample, the system can generate a standardized AST, determine a series of checksums on a specified subtree of the AST, and track the overall prevalence of any checksum on the complete training set. The resulting database should reflect those checksums that have been proven to be the most prevalent only in the malware collection.

[0040] At runtime, the system can generate a standardized AST representation for the script in question. A detection module (e.g., detection module 110) can traverse the tree and calculate a checksum for a specified subtree. The algorithm reuses the already calculated checksums of lower subtrees for subtrees located in higher levels of the tree to avoid recalculation. These checksums are then compared against entries in the trained database (subtree checksums 118). If the checksum matches the entry, the Bayesian score for the entry is added to the overall malware probability.

[0041] The process allows the creation of a checksum tree of fuzzy checksums to achieve active protection against new malware variants (or "zero-day" malware variants). Recompiled or repackaged variants of malware families or new malware that reuses components from previous malware families can be detected in a universal manner, thereby protecting users, including the first victim or "patient zero" of malware that may be sacrificed in traditional reactive schemes. The communication system 100 can be configured to help mitigate malware by using fuzzy checksums in the checksum tree to detect new or "zero-day" malware. "Fuzzy" means that the checksum not only matches the same portion of the data (from which the checksum was originally calculated), but the checksum also matches close relatives with a low or relatively low edit distance. As such, the process can be more accurate and file format agnostic than previous methods, in which the transformation of the code removes too much information and / or requires in-depth disassembly, simulation, and understanding of the malware. Malware detection can be scaled with respect to various aspects such as detection rate to error rate and memory usage to scan performance ratio, and each aspect can be controlled at runtime without algorithmic changes by changing the number of checksums used for each file, the positional deviation allowed in the checksum comparisons, and the percentage or score (e.g., a Bayesian score or some other similar type of score) assigned to each checksum match. Malware detection can include a series of fuzzy checksums that identify the closest relationship of new unknown malware to existing known malware variants and components. As a result, a checksum calculated on malware variant M1 is still likely to match on descendant M2 even if malware variant M1 is extended with new code, code is removed, recompiled or repackaged, etc.

[0042] Malware detection can work in a staged manner across multiple systems, such as performing a first "down-select" on a locally installed "on premise" network scanner, and then, upon initial matching, offloading detailed classification as feature vectors to a connected cloud service or server. Due to the fixed size of the feature vectors, it is relatively easy for the detection module to compute the feature vectors required for a thorough analysis through the network detection module in the cloud service (or security server). The detection module can send the feature vectors to the cloud service (or security server), and the checksums in the feature vectors can be compared against a larger checksum tree located in the cloud service (or security server). This allows the system to keep the data footprint on the local device (e.g., electronic device 102) small without sacrificing accuracy. Based on the size of the series of checksums necessary to detect malware, the ratio between the detection rate and the false positive rate can be configured as desired. For example, aggressive detection may require only four (4) checksum matches per script, while more accurate detection may require thirty-two (32) checksum matches, and so on.

[0043] In addition, the amount of CPU cycles required for calculating and comparing checksums is related to the size of the AST subtree. The size of the classification database does not have much impact on performance (except for a very small I / O-related part). This process can provide O (logn) performance characteristics, while traditional detection lists based on full-file hashing have O (n + log m) performance characteristics (e.g., file size * list size). The term "O (log n)" means that performance depends slightly on the size of the scanned file (especially, depending on the complexity of the script encoded in the file). Performance always remains more or less the same, with a slight indirect effect on performance by the file size. The term "O (n + log m)" means that performance depends on both the size of the scanned file (n represents the file size) and the size of the tree (which is log m). The term "m" representing the total amount of nodes in the tree and the performance of the lookup table is the logarithm of m because it is stored as a sorted tree (e.g., a "red-black" binary tree) rather than being stored as a sequential list.

[0044] The system may also allow for the delivery of a list of family relationships, each with a relationship likelihood. That is, instead of returning just a single detection name, the system may return a list such as "JS.Exploit.D": 90%, JS.Exploit.Blacole.B": 80%, and JS.ExploitIFrame.A": 70%. In one example, to determine the percentages, probability values ​​may be stored for each matching node in the checksum tree. The probability values ​​may be derived from the prevalence of checksums in a training set of malware and benign files compared to a clean training set. Additionally, based on a reasonably sized (100,000+) set of malware and benign file samples, classification data may be generated entirely through data mining and machine learning techniques. Therefore, there is no need for manual rule creation.

[0045] The communication system 100 can be configured to generate classification intelligence for the checksum tree using a training set of both known malicious and known benign file samples. From each sample, the communication system 100 can determine a series of fuzzy checksums and track the overall prevalence of any checksum over the complete training set. Using the training set, the communication system 100 can then generate a checksum tree that reflects a series of those checksums that have been shown to be most prevalent in both the malware set and the benign file set.

[0046] At runtime, the communication system 100 can be configured to interpret the checksum tree so that it originates from (one or more) root nodes, and for each node in the checksum tree, the checksum is compared with the checksum stored using the checksum tree node. The leaf nodes (or at least most of the leaf nodes) in the checksum tree have assigned class labels or classifications. The assigned classification specifies the most likely malware family name (e.g., JS.Exploit.D) or a benign label (e.g., CLEAN), and a matching likelihood (e.g., 0..100%) can be assigned based on one or more nodes that match the AST subtree checksum and how well the checksum matches the node. Remember any classifications reached by matching nodes, and perform voting across the various classifications to derive the most likely classification. In one example, a weighted combination of the various detections is used to create a probability sum. More specifically, a random forest classifier can be used with Bayesian voting across matching classification nodes.

[0047] Steering Figure 11, illustrating a communication system 100 according to an example embodiment. In general, the communication system 100 may be implemented in any type or topology of network. The network 124 represents a series of points or nodes of interconnected communication paths for receiving and transmitting information packets propagating through the communication system 100. The network 124 provides a communication interface between nodes and may be configured as any local area network (LAN), virtual local area network (VLAN), wide area network (WAN), wireless local area network (WLAN), metropolitan area network (MAN), intranet, extranet, virtual private network (VPN), and any other suitable architecture or system that facilitates communication in a network environment, or any suitable combination thereof, including wired and / or wireless communications.

[0048] In the communication system 100, network services including packets, frames, signals, data, etc. may be sent and received according to any suitable communication messaging protocol. Suitable communication messaging protocols may include multi-layer schemes such as the Open Systems Interconnection (OSI) model or any derivative or variation thereof (e.g., Transmission Control Protocol / Internet Protocol (TCP / IP), User Datagram Protocol / IP (UDP / IP)). In addition, radio signal communications over a cellular network may also be provided in the communication system 100. Suitable interfaces and infrastructure may be provided to enable communications with a cellular network.

[0049] The term "packet" as used herein refers to a data unit that can be routed between a source node and a destination node on a packet switching network. A packet includes a source network address and a destination network address. These network addresses can be Internet Protocol (IP) addresses in the TCP / IP messaging protocol. The term "data" as used herein refers to any type of binary, digital, voice, video, text or script data, or any type of source or target code, or any other suitable information in any suitable format that can be transmitted from one point to another in an electronic device and / or network. In addition, messages, requests, responses and inquiries are forms of network traffic, and therefore can include packets, frames, signals, data, etc.

[0050] In an example implementation, electronic device 102, secure server 104 and cloud service 106 are network elements, which are intended to cover network appliances, servers, routers, switches, gateways, bridges, load balancers, processors, modules or any other suitable equipment, components, elements or objects that can be operated to exchange information in a network environment. Network elements may include any suitable hardware, software, components, modules or objects that facilitate their operation, and suitable interfaces for receiving, transmitting and / or otherwise transmitting data or information in a network environment. This may include appropriate algorithms and communication protocols that allow effective exchange of data or information. Cloud service 106 is generally defined as the use of computing resources delivered as a service over a network such as the Internet. Typically, computing, storage and network resources are provided in a cloud infrastructure, thereby effectively transferring workload from a local network to a cloud network.

[0051] With regard to the internal structure associated with the communication system 100, each of the electronic device 102, the security server 104, and the cloud service 106 may include a memory element for storing information to be used in the operations outlined herein. Each of the electronic device 102, the security server 104, and the cloud service 106 may maintain information in any suitable memory element (e.g., random access memory (RAM), read-only memory (ROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), application-specific integrated circuit (ASIC), etc.), software, hardware, firmware, or any other suitable component, device, element, or object, where appropriate and based on specific needs. Any memory term discussed herein should be interpreted as being included within the broad term "memory element". Moreover, the information used, tracked, sent, or received in the communication system 100 may be provided in any database, register, queue, table, cache, control list, or other storage structure (all of which may be referenced at any suitable time frame). Any such storage option may also be included within the broad term "memory element" as used herein.

[0052] In certain example implementations, the functionality outlined herein may be implemented by logic encoded in one or more tangible media (e.g., embedded logic provided in an ASIC, digital signal processor (DSP) instructions, software (potentially including object code and source code) to be executed by a processor or other similar machine, etc.), which may include non-transitory computer-readable media. In some of these examples, a memory element may store data for the operations described herein. This includes the memory element being able to store software, logic, code, or processor instructions that are executed to implement the activities described herein.

[0053] In an example implementation, a network element of a communication system 100 such as an electronic device 102, a security server 104, and / or a cloud service 106 may include a software module (e.g., a detection module 110, a compiler module 120, and / or a network detection module 122) to implement or facilitate operations as outlined herein. These modules may be suitably combined in any appropriate manner, which may be based on a specific configuration and / or supply needs. In an example embodiment, such operations may be implemented by hardware implemented outside these elements or included in some other network device to implement the expected functions. In addition, a module may be implemented as software, hardware, firmware, or any suitable combination thereof. In order to implement operations as outlined herein, these elements may also include software (or reciprocating software) that can collaborate with other network elements.

[0054] In addition, each of the electronic device 102, the security server 104, and the cloud service 106 may include a processor capable of executing software or algorithms to perform activities as discussed herein. The processor may execute any type of instructions associated with data to implement the operations described in detail herein. In one example, the processor may transform an element or article (e.g., data) from one state or thing to another state or thing. In another example, the activities outlined herein may be implemented using fixed logic or programmable logic (e.g., software / computer instructions executed by a processor), and the elements identified herein may be some type of programmable processor, programmable digital logic (e.g., field programmable gate array (FPGA), EPROM, EEPROM) or an ASIC including digital logic, software, code, electronic instructions, or any suitable combination thereof. Any potential processing element, module, and machine described herein should be interpreted as being encompassed within the broad term "processor".

[0055] Electronic device 102 may be a network element and include, for example, a desktop computer, a laptop computer, a mobile device, a personal digital assistant, a smart phone, a tablet computer, or other similar device. Secure server 104 may be a network element such as a server or a virtual server and may be associated with a client, customer, endpoint, or end-user that wishes to initiate communications in communication system 100 via a network (e.g., network 124). The term "server" includes devices that are used to service requests from clients and / or perform certain computing tasks on behalf of clients within communication system 100. Although in Figure 1 Detection module 110, compiler module 120, and network detection module 122 are shown as separate modules, but this is for illustration purposes only. These modules can be combined or separated in any suitable configuration. In addition, these modules can be integrated into or distributed in cloud service 106 or security server 104 or in another network accessible by electronic device 102.

[0056] Steering Figure 2 , Figure 2 An example of a detection module 110 is illustrated. The detection module 110 may include a checksum module 130, a tree generation module 132, a classification module 134, an update module 136, and a configuration module 140. The checksum module 130 may be configured as a checksum calculator and a comparator. The checksum module 130 may use a series of fuzzy checksums to identify benign files, existing malware, and new unknown malware. Even if the variant malware has been extended with new code, code removed, recompiled, or repackaged, a checksum calculated on a malware variant M1 is still likely to match on a descendant M2.

[0057] The tree generation module 132 may be configured to generate a checksum tree from the script data. Each node in the checksum tree may reflect the logic in the script data that has been proven to be the most common in benign files or known malware files. In an example, the tree generation module 132 may be configured to generate an AST.

[0058] The classification module 134 can be configured as a classification queue and voter. The classification module 134 can create a list of family relationships, each family relationship having a relationship likelihood. That is, instead of returning just a single detection name (e.g., JS.Exploit.D), the classification module 134 can return a list such as "JS.Exploit.D: 90%, JS.Exploit.Blacole.B: 80%, and JS.ExploitIFrame.A: 70%, etc. The classification data can be generated entirely through data mining and machine learning techniques using existing known malware and benign script variants and components. The existing known malware and benign script variants and components can be a reasonably sized (100,000+) collection of malware and benign file samples. There is no need for manual rule creation.

[0059] The update module 136 may be configured to receive an updated version of the generated checksum tree for storage in the sub-checksum tree 118. The secure server 104 or cloud service 106 may be operable to update the sub-tree checksum 118 with a new checksum tree at some interval or when a new checksum tree is generated. In various embodiments, the update module 136 controls the updating of the sub-tree checksum 118 with a new checksum subtree from the compiler module 120 in the secure server 104 or in the cloud service 106.

[0060] Configuration module 140 can be configured to change the ratio between detection rate and false positive rate as desired. This ratio can be based on the size of a series of checksums necessary for matching on the file. For example, aggressive detection can require only 4 checksums to match each file, while more accurate detection can require matching 32 checksums, etc. The amount of CPU cycles required for calculating and comparing checksums is related to the size of the AST subtree. The size of the script and the size of the classification database (e.g., subtree checksum 118) will not affect performance, except for small I / O related parts. This provides an advantage because O (logn) performance characteristics can be provided, while traditional detection lists based on full file hashing have O (n + log m) performance characteristics (file size * list size).

[0061] Steering Figure 3 , Figure 3 An example of a compiler module 120 is illustrated. The compiler module 120 may include a tree generation module 132 and a tracking module 138. The tracking module 138 may be configured to track known and new malware and benign files. The tracking module 138 may also send a request to the tree generation module 132 for a new checksum tree to be generated for new malware and new benign files.

[0062] Steering Figure 4 , Figure 4 One example of a network detection module 122 is illustrated. The network detection module 122 may include a checksum module 130, a tree generation module 112, and a classification module 134. The network detection module 122 may perform a more detailed analysis on the script data.

[0063] Steering Figures 5A-5C , Figure 5A Script variant A 142 is illustrated, Figure 5B Script variant B 144 is illustrated, and Figure 5C An AST 146 is illustrated representing both script variant A 142 and script variant B 144. For example, a FOR node 148 of the AST 146 may represent the "for" code in the second line of script variant A 142 and script variant B 144.

[0064] ASSIGN node 150 may represent the "=" symbol in the third line of script variant A 142 and script variant B 144, which represents the assignment of a right-hand constant or expression to a left-hand variable. IDENTIFIER node 152 may represent the identifier "a" in the third line of script variant A 142 and the identifier "b" in the third line of script variant B 144. STRING node 154 may represent the string literal "this is akey" in the third line of script variant A 142 and the string literal "this is anotherkey" in the third line of script variant B 144. In this example, even though each line is slightly different, ASSIGN node 150, IDENTIFIER node 152, and STRING node 157 of AST 146 may represent the third line in script variant A 142 and script variant B 144.

[0065] Similarly, CALL node 156 may represent a call to function "abcdef" in line 4 of script variant A 142 and a call to function "decode" in line 4 of script variant B 144. IDENTIFIER node 152 may represent an identifier "a" used in the function call in line 4 of script variant A 142 and an identifier "b" used in the function call in line 4 of script variant B 144. By using a standardized AST (e.g., AST 146) to represent both script variant A 142 and script variant B 144, the standardized AST does not include script-specific content, such as actual variable or function names, nor constant values ​​(such as string literals), and thus script-specific content does not affect checksum calculations. By using this approach, the system is able to detect malware based solely on its structure and avoid full emulation, anti-emulation techniques, and negative performance impacts.

[0066] Steering Figure 6 , Figure 6 6 is an example flow diagram illustrating possible operations of flow 600 that may be associated with mitigating malware in accordance with an embodiment. In an embodiment, one or more operations of flow 600 may be performed by detection module 110 and tree generation module 112. At 602, a script is identified. At 604, an AST for the script is created. At 606, a checksum is compared to a subtree in the AST. For example, one or more checksums from subtree checksum 118 may be compared to a subtree in AST 146. At 608, the system determines whether the checksum matches the checksum of the subtree in the AST.

[0067] If the checksum matches the checksum of the checksum tree, the system determines whether the node of the checksum has a classification, as in 610. If the node of the checksum does not have a classification, the system determines whether the subtree has any children, as in 614. If the node of the checksum has a classification, the classification is stored, as in 612, and the system determines whether the subtree has any children, as in 614. If the subtree has children, the system returns to 606 and compares the checksum with another subtree in the AST. If the subtree does not have any children, the system determines whether each subtree in the AST has been analyzed, as in 618. This ensures that all subtrees of the AST are analyzed. For example, AST 146 can include 2, 5, 10 or any number of subtrees. If each subtree in the AST has been analyzed, the stored classifications (if any) are combined, as in 620. If each subtree in the AST has not yet been analyzed, the system returns to 606 and compares the checksum with the (new) subtree in the AST.

[0068] Returning to 608, if the checksum does not match the checksum of the subtree in the AST, the system determines whether the subtree has siblings, as in 616. For example, if Figure 5C As illustrated in , ASSIGN node 150, IDENTIFIER node 152 and STRING node 154 can be subtrees, and are the same generation of CALL node 156 and IDENTIFIER node 152, and the CALL node 156 and IDENTIFIER node 152 are another subtree. It is possible to have many same generations under the root node and any other node in the checksum tree, and this ensures that each same generation is analyzed. If the subtree has the same generation, then the checksum is compared with the subtree (same generation subtree) in the AST. If the subtree does not have the same generation, then the system determines whether each subtree in the AST has been analyzed, as in 618.

[0069] Steering Figure 7 , Figure 7700 may be associated with malware mitigation in accordance with an embodiment. In an embodiment, one or more operations of flow 700 may be performed by detection module 110 and tree generation module 112. A script is received at 702. At 704, an AST for the script is created. At 706, each subtree in the AST is compared with a known subtree checksum. At 708, an overall malware probability is determined. For example, detection module 110 may determine an overall malware probability for the script. At 710, the system determines whether the script requires further analysis. If the script requires further analysis, data related to the script is sent to a network element for further analysis, as in 712. For example, if the classification of the script has a probability of less than 90% that the script is malicious (or benign), a feature vector may be sent to security server 104 or cloud service 106 for further analysis using network detection module 122. If the script does not require further analysis, the process ends. For example, if the classification of a script has a greater than 90% probability that the script includes malware, then it is highly likely (greater than 90% probability) that the script contains malware and no further analysis is required.

[0070] Steering Figure 8 , Figure 8 800 that may be associated with mitigating malware in accordance with an embodiment. In an embodiment, one or more operations of flow 800 may be performed by detection module 110 and tree generation module 112. At 802, script data is received. At 804, an AST for the script is created. At 806, the AST is analyzed using a checksum. For example, the AST may be analyzed using subtree checksum 118. At 808, based on the analysis of the AST, a vector is created that is associated with the script data. At 810, the vector is sent to a device that will use the vector to classify the script data.

[0071] Steering Fig. 9 , Fig. 9 900 may be associated with mitigating malware in accordance with an embodiment. In an embodiment, one or more operations of flow 900 may be performed by detection module 110 and tree generation module 112. At 902, script data is received. The script data may relate to new malware or new benign files. At 904, characteristics of the script are determined. At 906, a fuzzy checksum for the script is determined. At 908, the checksum is sent to a device that will use the checksum to analyze the script data. For example, compiler module 120 may generate and transmit subtree checksum 118 to update module 136 in detection module 110.

[0072] Fig.10The diagram illustrates a computing system 1000 arranged in a point-to-point (PtP) configuration according to an embodiment. In particular, Fig.10 A system is shown in which processors, memory, and input / output devices are interconnected by a number of point-to-point interfaces. In general, one or more network elements of communication system 100 may be configured in the same or similar manner as computing system 1000.

[0073] like Fig.10 As illustrated in FIG. 1 , system 1000 may include several processors, of which only two processors 1070 and 1080 are shown for clarity. Although two processors 1070 and 1080 are shown, it is to be understood that embodiments of system 1000 may also include only one such processor. Processors 1070 and 1080 may each include a set of cores (i.e., processor cores 1074A and 1074B and processor cores 1084A and 1084B) to execute multiple threads of a program. The cores may be configured to perform the same functions as described above with reference to FIG. Figure 6-9 Each processor 1070, 1080 may include at least one shared cache 1071, 1081. The shared cache 1071, 1081 may store data (e.g., instructions) utilized by one or more components of the processors 1070, 1080, such as processor cores 1074 and 1084.

[0074] Each of the processors 1070 and 1080 may also include integrated memory controller logic (MC) 1072 and 1082 to communicate with the memory elements 1032 and 1034. The memory elements 1032 and / or 1034 may store various data used by the processors 1070 and 1080. In an alternative embodiment, the memory controller logic 1072 and 1082 may be discrete logic separate from the processors 1070 and 1080.

[0075] Processors 1070 and 1080 may be any type of processor and may exchange data via a point-to-point (PtP) interface 1050 using point-to-point interface circuits 1078 and 1088, respectively. Processors 1070 and 1080 may each exchange data with a chipset 1090 via respective point-to-point interfaces 1052 and 1054 using point-to-point interface circuits 1076, 1086, 1094, and 1098. Chipset 1090 may also exchange data with a high-performance graphics circuit 1038 via a high-performance graphics interface 1039 using interface circuit 1092, which may be a PtP interface circuit. In an alternative embodiment, Fig.10 Any or all of the PtP links illustrated in FIG. 5 may be implemented as a multi-point bus rather than as PtP links.

[0076] Chipset 1090 may communicate with bus 1020 via interface circuit 1096. Bus 1020 may have one or more devices communicating thereon, such as bus bridge 1018 and I / O devices 1016. Bus bridge 1018 may communicate with other devices, such as keyboard / mouse 1012 (or other input devices such as touch screen, trackball, etc.), communication device 1026 (such as a modem, network interface device, or other type of communication device that can communicate over computer network 1060), audio I / O device 1014, and / or data storage device 1028, via bus 1010. Data storage device 1028 may store code 1030, which may be executed by processors 1070 and / or 1080. In alternative embodiments, any portion of the bus architecture may be implemented using one or more PtP links.

[0077] Fig.10 The computer system depicted in is a schematic illustration of an embodiment of a computing system that can be used to implement the various embodiments discussed herein. It will be appreciated that Fig.10 The various components of the systems depicted in the present disclosure may be combined in a system-on-chip (SoC) architecture or in any other suitable configuration. For example, the embodiments disclosed herein may be incorporated into a system including mobile devices such as smart cell phones, tablet computers, personal digital assistants, portable gaming devices, etc. It will be appreciated that in at least some embodiments, these mobile devices may be provided with a SoC architecture.

[0078] Steering Fig.11 , Fig.11 is a simplified block diagram associated with an example ARM ecosystem SOC 1100 of the present disclosure. At least one example implementation of the present disclosure may include mitigation of malware features discussed herein and ARM components. For example, Fig.11 The example can be associated with any ARM core (e.g., A-9, A-15, etc.). In addition, the architecture can be any type of tablet, smartphone (including Android TM Phones, iPhones TM , iPad TM 、Google Nexus TM 、Microsoft Surface TM ), personal computers, servers, video processing components, laptop computers (including any type of notebook computer), Ultrabooks TM Part of the system, any type of touch-enabled input device, etc.

[0079] exist Fig.11In this example, the ARM ecosystem SOC 1100 may include multiple cores 1106-1107, an L2 cache control 1108, a bus interface unit 1109, an L2 cache 1110, a graphics processing unit (GPU) 1115, an interconnect 1102, a video codec 1120, and a liquid crystal display (LCD) I / F 1125, which may be associated with a mobile industry processor interface (MIPI) / high-definition multimedia interface (HDMI) link coupled to the LCD.

[0080] The ARM ecosystem SOC 1100 may also include a subscriber identity module (SIM) I / F 1130, a boot read-only memory (ROM) 1135, a synchronous dynamic random access memory (SDRAM) controller 1140, a flash memory controller 1145, a serial peripheral interface (SPI) host 1150, a suitable power control 1155, a dynamic RAM (DRAM) 1160, and a flash memory 1165. In addition, one or more example embodiments include one or more communication capabilities, interfaces, and features, such as Bluetooth. TM 1170 , 3G modem 1175 , global positioning system (GPS) 1180 , and examples of 802.11 Wi-Fi 1185 .

[0081] In operation, Fig.11 The example of can provide processing power, together with relatively low power consumption, to enable various types of computing (e.g., mobile computing, high-end digital home, servers, wireless infrastructure, etc.). In addition, such an architecture can enable any number of software applications (e.g., Android TM 、AdobeTM Flash TM Player, Java Platform Standard Edition (Java SE), JavaFX, Linux, Microsoft Windows Embedded, Symbian, and Ubuntu, among others). In at least one example embodiment, the core processor may implement an out-of-order superscalar pipeline with a coupled low-latency level 2 cache.

[0082] Fig.12 A processor core 1200 according to an embodiment is illustrated. The processor core 1200 may be a core for any type of processor such as a microprocessor, an embedded processor, a digital signal processor (DSP), a network processor, or other device that executes code. Fig.12 Only one processor core 1200 is shown in FIG. 1 , but the processor may alternatively include more than one Fig.12 For example, the processor core 1200 represents the processor core 1200 shown in FIG. Fig.10An example embodiment of processor cores 1074a, 1074b, 1084a, and 1084b is shown and described with reference to processors 1070 and 1080. Processor core 1200 may be a single-threaded core or, for at least one embodiment, processor core 1200 may be multi-threaded in that it may include more than one hardware thread context (or "logical processor") per core.

[0083] Fig.12 Also illustrated is a memory 1202 coupled to the processor core 1200 in accordance with an embodiment. The memory 1202 may be any of a variety of memories (including various layers of memory hierarchy) as known or otherwise available to those skilled in the art. The memory 1202 may include code 1204, which may be one or more instructions executed by the processor core 1200. The processor core 1200 may follow a program sequence of instructions indicated by the code 1204. Each instruction enters the front-end logic 1206 and is processed by one or more decoders 1208. The decoder may generate micro-operations such as fixed-width micro-operations as its output in a predetermined format, or may generate other instructions, micro-instructions, or control signals reflecting the original code instructions. The front-end logic 1206 also includes register renaming logic 1210 and scheduling logic 1212, which generally allocates resources and queues operations corresponding to instructions for execution.

[0084] The processor core 1200 may also include an execution logic 1214 having a set of execution units 1216-1 to 1216-N. Some embodiments may include several execution units dedicated to a specific function or set of functions. Other embodiments may include only one execution unit or only one execution unit capable of performing a specific function. The execution logic 1214 performs the operations specified by the code instructions.

[0085] After the operations specified by the code instructions are executed, the back-end logic 1218 can retire the instructions of the code 1204. In one embodiment, the processor core 1200 allows out-of-order execution but requires in-order retirement of instructions. The retirement logic 1220 can take various known forms (e.g., a reorder buffer, etc.). In this way, the processor core 1200 is converted during the execution of the code 1204, at least in terms of the output generated by the decoder, the hardware registers and tables utilized by the register renaming logic 1210, and any registers (not shown) modified by the execution logic 1214.

[0086] Despite Fig.12 Not shown in the figure, but the processor may include other components on the chip with the processor core 1200, see Fig.10 At least some of the other elements are shown and described herein. Fig.10As shown in FIG. 1 , a processor may include memory control logic with a processor core 1200. A processor may include I / O control logic and / or may include I / O control logic integrated with memory control logic.

[0087] It should be noted that, using the examples provided herein, the interaction can be described in terms of two, three or more network elements. However, this is made only for the purpose of clarity and example. In some cases, it may be easier to describe one or more functions of a given stream set by referring only to a limited number of network elements. It should be appreciated that the communication system 100 and its teachings are easily scalable and can accommodate a large number of components and more complex / delicate arrangements and configurations. Therefore, the examples provided should not limit the scope or inhibit the extensive teachings of the communication system 100 as potentially applied to countless other architectures.

[0088] It is also important to point out that the aforementioned flow chart (i.e., Figure 6-9 ) illustrate only some of the possible relevant scenarios and modes that may be performed by or within the communication system 100. Some of these operations may be deleted or removed, or may be substantially modified or altered, where appropriate, without departing from the scope of the present disclosure. In addition, several of these operations have been described as being performed simultaneously or in parallel with one or more additional operations. However, the timing of these operations may be substantially altered. The foregoing operational flows have been provided for purposes of example and discussion. A considerable degree of flexibility is provided by the communication system 100, as any suitable arrangement, chronology, configuration, and timing mechanisms may be provided without departing from the teachings of the present disclosure.

[0089] Although the present disclosure has been described in detail with reference to specific arrangements and configurations, these example configurations and arrangements may be significantly changed without departing from the scope of the present disclosure. Moreover, certain components may be combined, separated, eliminated, or added based on specific needs and implementations. In addition, although the communication system 100 has been described with reference to specific elements and operations that facilitate the communication process, these elements and operations may be replaced by any suitable architecture, protocol, and / or process that implements the intended functionality of the communication system 100.

[0090] Numerous other changes, substitutions, variations, alterations, and modifications may be ascertained by those skilled in the art, and it is intended that the present disclosure encompass all such changes, substitutions, variations, alterations, and modifications as fall within the scope of the appended claims. To assist the United States Patent and Trademark Office (USPTO), and further any reader of any patent granted with respect to this application, in interpreting the claims appended hereto, Applicant wishes to point out that Applicant: (a) does not intend any of the appended claims to invoke 35 U.S.C. 112(f) as it exists on the filing date unless the words “means for” or “step for” are specifically used in a particular claim; and (b) does not intend, by any statement in the specification, to limit the present disclosure in any manner not otherwise reflected in the appended claims.

[0091] Additional Notes and Examples

[0092] Example C1 is at least one machine-readable storage medium having one or more instructions that, when executed by at least one processor, cause the at least one machine-readable storage medium to receive script data, determine a checksum tree for the script data, compare each checksum of the checksum tree to one or more subtree checksums, and assign one or more classifications to the script data.

[0093] In Example C2, the subject matter of Example C1 can optionally include where a checksum tree is computed over the abstract syntax tree.

[0094] In Example C3, the subject matter of any of Examples C1-C2 can optionally include where each of the subtree checksums is a common malware or benign checksum.

[0095] In Example C4, the subject matter of any of Examples C1-C3 can optionally include where the classification is based on a subtree of the checksum tree matching a checksum in the subtree checksum.

[0096] In Example C5, the subject matter of any of Examples C1-C4 can optionally include assigning percentages to categories.

[0097] In Example C6, the subject matter of any of Examples C1-C5 can optionally include wherein one or more checksums of the checksum tree are fuzzy checksums.

[0098] In Example C7, the subject matter of any one of Examples C1-C6 can optionally include wherein the instructions, when executed by the at least one processor, further cause the at least one machine-readable storage medium to serialize the checksum tree into a feature vector.

[0099] In Example C8, the subject matter of any one of Examples C1-C6 can optionally include wherein the instructions, when executed by the at least one processor, further cause the at least one processor to transmit the feature vector to a network element for further analysis.

[0100] In example A1, an apparatus may include a tree generation module and a detection module. The tree generation module may be configured to receive script data and determine a checksum tree for the script data. The detection module may be configured to compare each checksum of the checksum tree with one or more subtree checksums and assign one or more classifications to the script data.

[0101] In Example A2, the subject matter of Example A1 can optionally include where a checksum tree is computed over the abstract syntax tree.

[0102] In Example A3, the subject matter of any of Examples A1-A2 can optionally include where each of the subtree checksums is a common malware or benign checksum.

[0103] In Example A4, the subject matter of any of Examples A1-A3 can optionally include where the classification is based on a subtree of the checksum tree matching a checksum in the subtree checksum.

[0104] In Example A5, the subject matter of any of Examples A1-A4 can optionally include assigning percentages to categories.

[0105] In Example A6, the subject matter of any of Examples A1-A5 can optionally include wherein one or more checksums of the checksum tree are fuzzy checksums.

[0106] In Example A7, the subject matter of any of Examples A1-A6 can optionally include wherein the detection module is further configured to serialize the checksum tree into a feature vector.

[0107] In Example A8, the subject matter of any one of Examples A1-A6 can optionally include wherein the detection module is further configured to transmit the feature vector to a network element for further analysis.

[0108] Example M1 is a method that includes receiving script data, determining a checksum tree for the script data, comparing each checksum of the checksum tree to one or more subtree checksums, and assigning one or more classifications to the script data.

[0109] In Example M2, the subject matter of Example M1 can optionally include where a checksum tree is computed over the abstract syntax tree.

[0110] In Example M3, the subject matter of any of Examples M1-M2 can optionally include where each of the subtree checksums is a common malware or benign checksum.

[0111] In Example M4, the subject matter of any of Examples M1-M3 can optionally include where the classification is based on a subtree of the checksum tree matching a checksum in the subtree checksum.

[0112] In Example M5, the subject matter of any of Examples M1-M4 can optionally include assigning percentages to categories.

[0113] In Example M6, the subject matter of any of Examples M1-M5 can optionally include wherein one or more checksums of the checksum tree are fuzzy checksums.

[0114] In Example M7, the subject matter of any of Examples M1-M6 can optionally include serializing the checksum tree into a feature vector and transmitting the feature vector to a network element for further analysis.

[0115] Example S1 is a system for mitigating malware, the system comprising a tree generation module and a detection module. The tree generation module can be configured to receive script data and determine a checksum tree for the script data. The detection module can be configured to compare each checksum of the checksum tree with one or more subtree checksums and assign one or more classifications to the script data.

[0116] In Example S2, the subject matter of Example S1 can optionally include where the classification is based on a subtree of the checksum tree matching a checksum in the subtree checksum.

[0117] Example X1 is a machine-readable storage medium including machine-readable instructions for implementing a method as in any of Examples M1-M7 or implementing an apparatus as in any of Examples A1-A8. Example Y1 is an apparatus including components for performing any of Example Methods M1-M7. In Example Y2, the subject matter of Example Y1 may optionally include components for performing the method including a processor and a memory. In Example Y3, the subject matter of Example Y2 may optionally include a memory including machine-readable instructions.

Claims

1. At least one non-transitory computer-readable medium comprising one or more instructions that, when executed by a processor, cause the processor to perform operations comprising: Receive script; creating an abstract syntax tree for the script by normalizing a plurality of lines of the script using at least one of a loop node, a call node, an if node, an assignment node, an identifier node, or a string node; as well as Based at least in part on a determination that a checksum of a subtree of the abstract syntax tree matches a predetermined subtree checksum of a predetermined tree, one or more classifications are assigned to the script.

2. At least one computer-readable medium according to claim 1, wherein: Percentages are assigned to the one or more categories.

3. The at least one computer-readable medium of claim 2, wherein the operations further comprise: serializing the abstract syntax tree into a feature vector based at least in part on a determination that the probability of detection is below a predetermined threshold; and The feature vector is transmitted to the network element.

4. The at least one computer-readable medium of claim 1, wherein the predetermined subtree checksum is a fuzzy checksum.

5. The at least one computer-readable medium of claim 1, the operations further comprising: The one or more classifications are stored in a memory, wherein an abstract syntax tree is computed without including script-specific content of the script, malware or benign classifications are assigned to predetermined subtree checksums, and the assigned classifications include possible malware family names or benign labels.

6. The at least one computer-readable medium of claim 1, the operations further comprising: The one or more classifications are voted on to determine a possible classification for the script.

7. A device, comprising: Memory; processor; The tree generation module is configured to: receiving the script at the processor, and creating an abstract syntax tree for the script by normalizing a plurality of lines of the script using at least one of a loop node, a call node, an if node, an assignment node, an identifier node, or a string node; as well as A detection module is configured to assign one or more classifications to the script based at least in part on a determination that a checksum of a subtree of the abstract syntax tree matches a predetermined subtree checksum of a predetermined tree.

8. The device according to claim 7, wherein: Percentages are assigned to the one or more categories.

9. The device according to claim 8, wherein: The detection module is further configured to, based at least in part on a determination that the probability of detection is below a predetermined threshold, serialize the abstract syntax tree into a feature vector and transmit the feature vector to a network element.

10. The apparatus of claim 7, wherein the predetermined subtree checksum is a fuzzy checksum.

11. The device according to claim 7, wherein: The one or more classifications are stored in the memory, the abstract syntax tree is calculated without including script-specific content of the script, a malware or benign classification is assigned to the predetermined subtree checksum, and the assigned classification includes a possible malware family name or a benign label.

12. The device according to claim 7, wherein: The detection module is further configured to vote on the one or more classifications to determine a possible classification of the script.

13. A method comprising: Receive script; creating an abstract syntax tree for the script by normalizing a plurality of lines of the script using at least one of a loop node, a call node, an if node, an assignment node, an identifier node, or a string node; as well as Based at least in part on a determination that a checksum of a subtree of the abstract syntax tree matches a predetermined subtree checksum of a predetermined tree, one or more classifications are assigned to the script.

14. The method according to claim 13, wherein: Percentages are assigned to the one or more categories.

15. The method according to claim 14, further comprising: serializing the abstract syntax tree into a feature vector based at least in part on a determination that the probability of detection is below a predetermined threshold; and The feature vector is transmitted to a network element. The method of claim 13 , wherein the predetermined subtree checksum is a fuzzy checksum.

17. The method according to claim 13, further comprising: The one or more classifications are stored in a memory, wherein an abstract syntax tree is computed without including script-specific content of the script, malware or benign classifications are assigned to the predetermined subtree checksums, and the assigned classifications include possible malware family names or benign labels.

18. The method according to claim 13, further comprising: The one or more classifications are voted on to determine a possible classification for the script.

19. A system for mitigating malware, the system comprising: Memory; Communication circuits; Hardware processor, configured as: Receive script; creating an abstract syntax tree for the script by normalizing a plurality of lines of the script using at least one of a loop node, a call node, an if node, an assignment node, an identifier node, or a string node; as well as Based at least in part on a determination that a checksum of a subtree of the abstract syntax tree matches a predetermined subtree checksum of a predetermined tree, one or more classifications are assigned to the script.

20. The system of claim 19, wherein: The one or more classifications are stored in the memory, the abstract syntax tree is calculated without including script-specific content of the script, a malware or benign classification is assigned to the predetermined subtree checksum, and the assigned classification includes a possible malware family name or a benign label.

Images