System, apparatus and method for classifying a file as malicious using static scanning

Description

1. FIELD

Embodiments of the disclosure relate to the field of network security. More specifically, one embodiment of the disclosure relates to a system, apparatus and method for performing static scanning of contents within a file to uncover exploits that are application version specific and/or are associated with non-executable files.

2. GENERAL BACKGROUND

Over the last decade, malicious software (malware) has become a pervasive problem for Internet users. In some situations, malware is an exploit, in the form of a program or other file, which is embedded within downloadable content and designed to adversely influence or attack normal operations of a computer. Examples of different types of exploits may include bots, computer viruses, worms, Trojan horses, spyware, adware, or any other programming that operates within an electronic device (e.g. computer, tablet, smartphone, server, router, wearable technology, or other types of electronics with data processing capability) without permission by the user or an administrator.

For instance, exploits may be present in one or more files infected through any of a variety of attack vectors, where the files are part of network traffic. For instance, as an illustrative example, a file may include an exploit that executes only upon detecting execution of a certain version of an application (e.g. exploit inserted into JavaScript® code that is set to execute only upon detecting Adobe® Reader™ version 9). As another illustrative example, an exploit may be placed within a non-executable file (e.g. JPEG® file), where the exploit is carried into the electronic device undetected by malware detection software. Hence, without a multi-tier static scanning scheme as described below, these types of exploits may not be detected.

BRIEF DESCRIPTION OF THE DRAWINGS

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 a communication system deploying a plurality of malware content detection (MCD) systems with the framework for static scanning for malware.

FIG. 2 is a detailed exemplary block diagram of logic associated with one of the MCD systems of FIG. 1.

FIG. 3 is an exemplary block diagram of a flowchart illustrating multi-tier static scanning of content by logic within an electronic device within the communication system of FIG. 1.

FIG. 4 is an exemplary block diagram of a flowchart illustrating details of the multi-tier static scan analyses set forth in FIG. 3.

FIG. 5 is an exemplary block diagram of a flowchart partially illustrating operations for static scanning of PDF files in accordance with the multi-tier static scanning analyses of FIG. 4.

FIG. 6 is an exemplary block diagram of a flowchart partially illustrating operations for static scanning of Flash files in accordance with the multi-tier static scanning operations of FIG. 4.

DETAILED DESCRIPTION

Various embodiments of the disclosure relate to static framework within an electronic device having network connectivity, such as a malware content detection (MCD) system for example, and a corresponding method for statically scanning one or more objects within a file. More specifically, the static framework is configured to deconstruct a file for analysis if a first static scan is unsuccessful in detecting the potential presence of malware. Such deconstruction of the file may comprise decompression, disassembly (e.g. convert executable code into a readable form such as converting object code into assembly language or JavaScript® code), decompilation (e.g. converting executable code into pseudo or native code, converting Flash code into action script code, converting JAVA® Archive “JAR” files into JAVA® files, etc.) and/or other de-obfuscation (e.g. decoding, extracting, decrypting, unpacking, removing any protection mechanisms, or conducting other operations to gain code-level access to embedded objects within the file as code can be assembly code, pseudo code, native code such as “C” or Java used by a developer to build the file or software component in the file). The results of the disassembly and/or decompilation may produce a result substantially similar to the original code (e.g. high percentage of similarity such as greater than about 90%).

After deconstructing the file, one or more static scanning analysis operations may be conducted to determine whether one or more objects within the file may include malware. Two types of static scanning operations include heuristic checks and/or deterministic checks. Herein, the heuristic and/or deterministic checks are generally referred to as “malware checks”.

The heuristic checks are static scanning operations conducted to determine the degree of correlation between objects within the file, where the presence or absence of such objects may denote potential malicious activity and the presence of malware. Such scanning comprises rule-based data analysis. For example, a deconstructed Flash file may provide the names of different functions within the file (e.g. “WebConnect( )”) and identify one or more parameters passed to that function (e.g. “www.XYZ.com”). A rule adapted to control network connectivity may identify the “WebConnect” pattern as an HTTP request and passed parameters. Where the passed parameter is not a specific parameter (e.g., www.ABC.com) or a known malicious pattern, a malicious event is detected, namely there is a reasonable likelihood that the Flash file has become infected with malware.

The deterministic checks are static scanning operations conducted to determine whether any of the object(s) within or associated with the file includes information that is correlated to (or matches) one or more “malware identifiers”, which may include, but are not limited or restricted to exploit patterns, names of vulnerable functions that are known to be susceptible to exploits, and/or malicious patterns (e.g. shell code patterns, Return Oriented Programming “ROP” patterns, heap spray patterns, etc.).

If a deconstructed object still does not provide sufficient accessibility to its code-level structure for static scanning, then the static framework conducts an emulation process to emulate file operations undertaken during processing of that object. In particular, such emulation utilizes Application Programming Interface (API) hooking for controlling what values are input to the object during emulation (e.g. specific version numbers or other return parameters). The information exchanged during the “hooking” operations as well as output data from the object under analysis are statically scanned for malware identifiers. In some embodiments, the scanning may also be conducted against any other behaviors of the deconstructed object observed during the emulation. These static scanning operations supplement dynamic, virtual machine based (VM-based) malware detection.

Exemplary operations of the static framework are described below. Once the file is extracted (e.g., file duplicated from network traffic and received by an electronic device with the static framework), the type of the file is determined. Based upon the file type, static deconstruction logic supporting that file type is invoked. The static deconstruction logic ensures that, as needed during static scanning, the file is decompressed, disassembled, decompiled, and/or de-obfuscated. Decompression, disassembly, decompilation, and/or de-obfuscation of the file is conducted to provide code-level access to embedded objects within the file, and one or more malware checks may be conducted on these objects in efforts to detect known attack types (e.g. malware exploits; malicious patterns such as shell code, heap spray and/or ROP patterns, patterns to indicate the file is a malicious downloader, etc.).

If any of the embedded objects is still inaccessible after operations by the static deconstruction logic, then the static framework invokes emulation logic. The emulation logic is configured to emulate operations associated with the processing of a particular object in context with an emulated computer application. As an optional feature, emulation logic may provide the list of functions and other features on which malware checks can be applied. The malware checks are not limited to shell code detection, ROP detection, detection, suspicious function calls, patterns to indicate that the file is a malicious downloader, or the like.

According to one embodiment of the disclosure, the static analysis and dynamic analysis performed by scanning engine 170 and analysis engine 190 of FIG. 1 may be performed in sequence in which results of the static analysis may be utilized by a subsequent analysis (e.g., dynamic analysis) to improve the efficiency and accuracy of the subsequent analysis. Alternatively, of course, the static analysis may be conducted concurrently with the dynamic analysis in the same electronic device. In other embodiments, the static analysis (or portions thereof) can take place in the cloud and the results of the static analysis can be shared with the dynamic analysis in the virtual machine (VM). Furthermore, it is contemplated that, when network traffic is received by a network interface device for malware detection, dispatch logic (not shown) may be employed to determine which of the static and dynamic analysis should be performed first, where the dispatch logic is user configurable. For certain types of content (e.g., a Portable Document Format “PDF” file, a Dynamic-Linked Library “DLL”, a Flash file, etc.), a static analysis may be performed first and a dynamic analysis may be performed thereafter.

According to one embodiment of the disclosure, in addition to generating a static score (or indicator) that identifies the likelihood of the presence of malware within the analyzed file, scanning engine 170 may further generate information concerning the analyzed file, such as the file type, an operating system and its version of the application in which the file is intended to be executed, and the like. Such content-related information may be utilized by another analysis module to perform a subsequent static analysis specifically tailored to the content in question or may be used during subsequent dynamic analysis.

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 is not limited or restricted to a microprocessor, one or more processor cores, a programmable gate array, a microcontroller, 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 load 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.

The term “object” generally refers to one or more software components embedded in or otherwise associated with an executable or non-executable file (e.g. dynamic link library “DLL” or any other resource for storing information), where the software component has a capability of being executed alone or with other software components associated with the same or different files. An example of a type of software component may include, but is not limited or restricted to a function or routine (e.g. a series of code instructions to perform a particular operation), parameters utilized by with the function, or the like. A file having an object that is suspected of including malware may be classified as “malicious”.

Herein, there are different degrees of maliciousness. Where there is a first level of likelihood of an object being infected with malware, the file may be classified with a lower “malicious” grade (sometimes referred to as “suspicious”), which may be represented by a score corresponding to the likelihood of malware being present in the file and/or object (e.g., score of 3 out of 10). Where there is a second level of likelihood of an object being infected with malware, the file may be classified with a higher “malicious” grade, normally represented by a higher score (e.g., score of 8 out of 10).

It is contemplated that the file may be transmitted as part of one or more messages associated with network traffic, where each message(s) may be in the form of a packet, a frame, an Asynchronous Transfer Mode “ATM” cell, a data flow (e.g. a group of related messages), or any other series of bits having a prescribed format. For example, the file may be part of network traffic transmitted using a Hypertext Transfer Protocol (HTTP), Hypertext Markup Language (HTML) protocol, or may be transmitted in a manner suitable for display on a Web browser software application.

Another illustrative example is that the file may be transmitted using a particular protocol including, but not limited to an email protocol such as Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POPS), or Internet Message Access Protocol (IMAP4). Furthermore, the file may be part of an Instant Message, which may be transmitted using Session Initiation Protocol (SIP) or Extensible Messaging and Presence Protocol (XMPP) for example. Yet another illustrative example is that the file may be transferred using a data transfer protocol such as File Transfer Protocol (FTP) for subsequent storage on a file share, Hypertext Transfer (HTTP) protocol and/or Server Message Block (SMB) protocol.

The terms “malware” is directed to software that produces an undesired behavior upon execution, where the behavior is deemed to be “undesired” based on customer-specific rules, manufacturer-based rules, or any other type of rules formulated by public opinion or a particular governmental or commercial entity. This undesired behavior may include a communication-based anomaly or an execution-based anomaly that would (1) alter the functionality of an electronic device executing application software in a malicious manner; (2) alter the functionality of an electronic device executing that application software without any malicious intent; and/or (3) provide an unwanted functionality which may be generally acceptable in another context.

The term “transmission medium” is a communication path between two or more systems (e.g. any electronic devices with data processing functionality such as, for example, a security appliance, server, mainframe, computer, netbook, tablet, smart phone, router, switch, bridge or brouter). The communication path may include wired and/or wireless segments. Examples of wired and/or wireless segments include electrical wiring, optical fiber, cable, bus trace, or a wireless channel using infrared, radio frequency (RF), or any other wired/wireless signaling mechanism.

The term “computerized” generally represents that any corresponding operations are conducted by hardware in combination with software and/or firmware. Also, the term “compare” generally means determining if a match or a certain level of correlation is achieved between two items where one of the items may include the content of a files or a particular identifier.

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.

As this invention is susceptible to embodiments of many different forms, it is intended that the present disclosure is to be considered as an example of the principles of the invention and not intended to limit the invention to the specific embodiments shown and described.

II. General Architecture

Referring to FIG. 1, an exemplary block diagram of a communication system 100 deploying a plurality of malware content detection (MCD) systems 110₁-110_N (N>1, e.g. N=3) communicatively coupled to a management system 120 via a network 125 is shown. In general, management system 120 is adapted to manage MCD systems 110₁-110_N. For instance, management system 120 may be adapted to cause one or more malware identifiers, each of which being information representative of prior detected malware, to be shared among some or all of the MCD systems 110₁-110_N for use in malware checks. Such sharing may be conducted automatically or manually uploaded by an administrator. Also, such sharing may be conducted freely among the MCD systems 110₁-110_N or subject to a subscription basis.

Herein, according to the embodiment illustrated in FIG. 1, a first MCD system 110₁ is an electronic device that is adapted to analyze information associated with network traffic routed over a communication network 130 between at least one server device 140 and at least one client device 150. More specifically, the first MCD system 110₁ is configured to conduct static analysis of information (e.g., a file that is part of message(s) transmitted via the network traffic) received via communication network 130 and, where applicable, classify the file with different “malicious” scores. A file may be classified with a first level (e.g. “suspicious”—assigned a score less than or equal to a first threshold) when at least one characteristic identified during static scanning operations conducted on the file indicates a certain level of probability that the file includes malware. Similarly, the file may be classified with a second level (e.g. “malicious”—assigned a score greater than or equal to a second threshold greater than the first threshold) when at least one characteristic observed during static scanning operations conducted on the file indicates a certain greater level of probability that the file includes malware.

In particular, according to one embodiment of the disclosure, static scanning is conducted by static framework 175 within the first MCD system 110₁, where the static framework 175 may be part of a scanning engine 170 for example. The static framework 175 is configured to conduct a first static scanning operation on a duplicated file extracted from the network traffic, and if no malware is detected, to further deconstruct the duplicated file to recover embedded objects. The file may be deconstructed by performing decompression, disassembly, decompilation, and/or other de-obfuscation operations thereon.

Thereafter, malware checks are conducted by the static framework 175 on one or more embedded objects within the file in order to potentially classify the file “malicious,” depending on whether any object within the file is determined to have at least one characteristic associated with malware. In the event that, after deconstruction, an object is still inaccessible for static scanning, the static framework 175 is configured to emulate processing of the object under analysis within the context of simulated operations of an application associated with execution of the file. In other words, during emulation, both information exchanged with the object and information output from the object are analyzed to determine if such information has a certain level of correlation with one or more malware identifiers. The level of correlation (e.g., exact pattern match to matching a majority of the pattern) may be non-modifiable or may be adjustably set by an administrator.

The communication network 130 may include a public computer network such as the Internet, in which case an optional firewall 155 (represented by dashed lines) may be interposed between communication network 130 and client device 150. Alternatively, the communication network 130 may be a private computer network such as a wireless telecommunication network, wide area network, or local area network, or a combination of networks.

The first MCD system 110₁ is shown as being coupled with the communication network 130 (behind the firewall 155) via a network interface 160. The network interface 160 operates as a data capturing device (referred to as a “tap” or “network tap”) that is configured to receive data traffic propagating to/from the client device 150 and provide content from the data traffic to the first MCD system 110₁.

In general, the network interface 160 receives and duplicates the content that is received from and provided to client device 150 normally without an appreciable decline in performance by the server device 140, the client device 150, or the communication network 130. The network interface 160 may duplicate any portion of the content, for example, one or more files that are part of a data flow or part of the payload contained within certain data packets, or the like.

In some embodiments, the network interface 160 may capture metadata from network traffic intended for client device 150. This metadata may be used, at least in part, to deconstruct a corresponding file. For instance, the metadata may include keys that can be used to de-obfuscate the file.

It is contemplated that, for any embodiments where the first MCD system 110₁ is implemented as an dedicated appliance or a dedicated computer system, the network interface 160 may include an assembly integrated into the appliance or computer system that includes network ports, network interface card and related logic (not shown) for connecting to the communication network 130 to non-disruptively “tap” data traffic propagating through firewall 155 and provide a copy of the data traffic to the scanning engine 170. In other embodiments, the network interface 160 can be integrated into an intermediary device in the communication path (e.g., firewall 155, router, switch or other network device) or can be a standalone component, such as an appropriate commercially available network tap. In virtual environments, a virtual tap (vTAP) can be used to duplicate files from virtual networks.

Referring still to FIG. 1, first MCD system 110₁ may include a scanning engine 170, a heuristics database 175, a scheduler 180, a storage device 185, an analysis engine 190 and a reporting module 195. In some embodiments, the network interface 160 may be contained within the first MCD system 110₁. Also, scanning engine 170, scheduler 180 and/or analysis engine 190 may be software modules executed by a processor that receives one or more files and performs a multi-tier static scan analysis on objects within the file(s), which may involve accessing one or more non-transitory storage mediums operating as database 175, storage device 185 and/or reporting module 195. In some embodiments, the scanning engine 170 may be one or more software modules at least partially forming static framework 175, where such software modules are executed by a processor. The scheduler 180 and the analysis engine 190 may be one or more software modules executed by the same or a different processor, where these different processors are possibly located at geographically remote locations, located within the same processor package (e.g. different processor cores) and/or communicatively coupled for example via a network.

In general, the scanning engine 170 performs static scanning of a file to determine whether objects within the file may include exploits (e.g. portions of content that may be exploited by malware), vulnerable functions, and/or malicious patterns (e.g. shell code patterns, ROP patterns, heap spray patterns, patterns to detect a malicious downloader, etc.). More specifically, as illustrated in FIG. 1, the scanning engine 170 receives a duplicated copy of one or more files associated with network traffic received from the network interface 160 and statically scans the content of the file(s) for malware identifiers. In other words, the scanning engine 170 performs a first static scan by comparing the contents of each file with malware and/or correlation between identifiers to determine an existence of malware which can be, but is not limited to exploit patterns, names of vulnerable functions, shell code patterns, heap spray patterns, etc. Alternatively, in in-line deployments, the network interface 160 may provide the original (rather than a duplicate) of the portion of content to the scanning engine 170 for malware analysis. While the balance of this specification may refer to the duplicate, this alternative embodiment may serve to implement the concepts later described herein.

If the comparison reveals a correlation between the contents of the file and one or more malware identifiers (hereinafter referred to as a “match”), which denotes a malicious event, the scanning engine 170 determines whether the corresponding file is “malicious” and assigns a score to the file. The malware checks applied by the scanning engine 170 may be based on data and/or rules stored in the heuristics database 175. Also, the scanning engine 170 may examine portions of the image associated with the one or more files without executing or opening such file(s).

If no malicious event is initially detected, the scanning engine 170 may further deconstruct the duplicated file to recover one or more embedded objects within the file. The deconstruction operations may include, but are not limited or restricted to decompression, disassembly, decompilation and/or other de-obfuscation of the file to obtain code-level access to the embedded object(s) within the file using for example de-obfuscation transformation techniques known to those of ordinary skill in the art. Thereafter, malware checks are conducted on the object(s) in order to determine if any of these objects may include exploits, vulnerable function calls, and/or malicious patterns, patterns to detect malicious downloaders, etc. As one illustrative embodiment, this may involve static scanning of code associated with the object for malware identifiers such as one or more malware exploit patterns, function patterns, and/or malicious patterns that are associated with malware.

Upon detecting a match, the scanning engine 170 may assign a score (e.g., an indicator of the likelihood of the analyzed file including malware) to the analyzed file. This may be performed in some embodiments by assigning a score to individual objects associated with a file, and then mathematically combining the object-level scores to obtain an overall score for the file. Thereafter, the file and score are routed from the scanning engine to the analysis engine 190 for use in further analysis to confirm the presence of malware within the file.

However, in the event that an object associated with the deconstructed file is still inaccessible for static scanning (e.g., code-level access of that object is still unavailable), the scanning engine 170 conducts emulation operations, where the processing of this object is emulated and an output associated with such emulation may be statically scanned to determine if portions of the output match any of the pre-stored malware identifiers. The emulation may be conducted in, for example, a “light weight” run-time environment for dynamic analysis. The run-time environment is described as “light weight” because it does not actually run applications that normally are used in processing files. The run-time environment may be provided with an emulated application selected based on the specific content being processed, however. For example, a PDF file may expect an Adobe® Reader™ application, and therefore, for emulation, the MCD system 110₁ relies on an emulator to present certain simulated or virtualized features/responses associated with that application as expected by the file being analyzed. The MCD system 110₁ then monitors behavior of the file within the emulator, for example, by intercepting or “hooking” any and all API calls, and comparing the hooked API calls with those expected of similar files when processed. Any unexpected API calls are regarded as anomalies that may indicate the file is malicious. The file is then assigned a score based on the presence or absence of such anomalies, and, in some embodiments, the type of the API call and/or other characteristics of the observed anomalies.

After static scanning, the file may be presented to the analysis engine 190 for more in-depth dynamic analysis using virtual machine technology for processing of the file in a more complete run-time environment in which one or more applications are executed (not just emulated). The ensuing processing may be conducted for a period of time that is either fixed or variable, and may be set manually by an administrator or automatically by the MCD system 110₁, for example, based on the type of file, queue length of files to be analyzed, or other analysis parameters. For this purpose, the scanning engine 170 communicates with the scheduler 180.

The scheduler 180 may retrieve and configure a virtual machine (VM) to mimic the pertinent performance characteristics of the client device 150. In one example, the scheduler 180 may be adapted to configure the characteristics of the VM to mimic only those features of the client device 150 that are affected by the data traffic copied by the network interface 160. The scheduler 180 may determine the features of the client device 150 that are affected by the content by receiving and analyzing the network traffic from the network interface 160. Such features of the client device 150 may include ports that are to receive the content, certain device drivers that are to respond to the content, and any other devices coupled to or contained within the client device 150 that can respond to the content.

In another embodiment of the disclosure, the scanning engine 170 may determine the features of the client device 150 that are affected by the network traffic by receiving and analyzing the content from the network interface 160. The scanning engine 170 may then transmit the features of the client device to the scheduler 180 and/or analysis engine 190.

The analysis engine 190 is adapted to execute one or more VMs to simulate the receipt and/or execution of different “malicious” objects within a file under analysis (analyzed file) within a run-time environment as expected by the type of file, as noted above. The run-time environment may be one selected to mimic one that is prevalently provided by client devices, or, in alternative embodiments, one that can be provided by the client device 150 in particular. Furthermore, the analysis engine 190 analyzes the effects of such content upon the run-time environment, such as the client device 150. Such effects may include unusual network transmissions, unusual changes in performance, and the like. This detection process is referred to as a dynamic malicious content detection.

The analysis engine 190 may flag the malicious content as malware according to the observed behavior of the VM. The reporting module 195 may issue alerts indicating the presence of malware, and using pointers and other reference information to identify what message(s) (e.g. packet(s)) may contain malware. Additionally, the server device 140 may be added to a list of malicious network content providers, and future network transmissions originating from the server device 140 may be blocked from reaching their intended destinations, e.g., by firewall 155.

Of course, in lieu of or in addition to static scanning operations being conducted by MCD systems 110₁-110_N, it is contemplated that cloud computing services 135 may be implemented to perform such static scanning: deconstruct a file for static scanning; conduct static scans on one or more objects within the deconstructed file(s); and/or perform emulation on any of these objects, as described herein. In accordance with this embodiment, MCD system 1101 may be adapted to establish secured communications with cloud computing services 135 for exchanging information.

Referring now to FIG. 2, an exemplary block diagram of logic associated with MCD system 110₁ is shown. MCD system 110₁ comprises one or more processors 200 that are coupled to communication interface logic 210 via a first transmission medium 220. Communication interface logic 210 enables communications with other MCD systems 110₂-110_N and management system 120 of FIG. 1. 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 200 is further coupled to persistent storage 230 via transmission medium 225. According to one embodiment of the disclosure, persistent storage 230 may include scanning engine 170, which comprises malware check logic 250, static deconstruction logic 260 and emulation logic 270. Of course, when implemented as hardware, logic 250, 260 and/or 270 would be implemented separately from persistent memory 230.

Malware check logic 250 comprises one or more software modules to conduct static scanning of content within a file to determine whether such content includes malware identifiers, such as information associated with known malware exploits. The malware check logic 250 may conduct, in some embodiments, a malware signature matching operation. As an example, malware check logic 250 may be initially invoked to conduct static scanning of content in the file, which includes conducting pattern comparison operations (e.g. bitwise comparison, byte-wise comparison, etc.) between accessible file content and malware identifiers associated with known exploit patterns, vulnerable functions and malicious patterns obtained from data store 290.

Subsequently, after failing to detect any malicious events and deconstructing the file as described herein, the malware check logic 250 may conduct a secondary static scan in which content within objects associated with the deconstructed file (e.g., code associated with one or more embedded objects within the file that is accessible after deconstructing of the file) is compared to the malware identifiers.

Static deconstruction logic 260 comprises one or more software modules that are invoked to deconstruct a file, namely perform decompression, disassembly, decompilation and/or de-obfuscation operations on the analyzed file. Such file deconstruction is to provide the malware check logic 250 with code-level (e.g., code can be pseudo code, assembly code or the native code in which the file was coded by the developer of the file) access to one or more objects within the analyzed file for subsequent static scanning operations as described above.

Emulation logic 270 (emulator) comprises one or more software modules that are invoked when the malware check logic 250 still fails to have code-level access for a targeted object within the analyzed file. Emulation logic 270 is configured to emulate operations of the object and, perhaps in combination with malware check logic 250, monitor for anomalous behavior. The monitoring may be accomplished by “hooking” certain functions associated with that object (e.g., one or more APIs, etc.) as described above, and controlling what data is specifically returned in response to corresponding function calls (e.g., force return of an application version number different than its actual number). After receipt of the returned data, operations by the object are monitored. For instance, the output from the object may be analyzed by the malware check logic 250 to determine if a portion of the output matches any of the malware identifiers. In some embodiments, the emulation logic 270 and/or the malware check logic 250 may access data store 290 for purposes of retrieving, from an API call repository, expected API calls typical of the type of file being processed, and may store “hooked” API calls therein for later reference.

Continuing the above example, in order to convey findings, processor(s) 200 may invoke GUI logic 280, which provides one or more screen displays for conveying a more detailed summary of malicious files being detected by MCD system 110₁. In some embodiments, the MCD system 110₁ may also contain remediation logic (not shown) to initiate remediation of identified malware and recovery from the identified exploit.

III. Exemplary Embodiments of Static Scanning

Referring to FIG. 3, an exemplary diagram of a flowchart illustrating multi-tier static scanning of content (e.g., analyzed file) is shown. Herein, a first static scan is conducted to determine if content within an analyzed file has a certain level of correlation with (generally referred to as “matches”) malware identifiers directed to predefined malware exploit patterns, vulnerable function calls, and/or malicious patterns such as shell code patterns, ROP patterns, heap spray patterns, or the like (block 300). If a malicious event is detected, it is contemplated that a score that identifies the likelihood of the presence of malware within the analyzed file may be produced and provided for use in subsequent VM-based analysis of the file (blocks 310, 380 and 390).

In the event that no malicious event is detected, the analyzed file is deconstructed (e.g., decompress, disassemble, decompile and/or de-obfuscate code within the analyzed file) to improve accessibility of one or more objects within the analyzed file. Then, a second static scan of the content of one of the deconstructed objects is conducted. According to one embodiment of the disclosure, the content of the object(s) is compared to at least a subset of the malware identifiers (block 320). If a match is detected to denote that a malicious event has been detected, a score that identifies the likelihood of the presence of malware within the deconstructed file may be produced and provided for subsequent VM-based analysis of the file (blocks 330, 380 and 390).

In the event that no malicious event is again detected, a third static scan is conducted after emulated processing of the object within the context of simulated operations associated with a targeted application (block 340). For example, when the file is a PDF file, the targeted application may be a certain version of an Adobe® Reader™ application and the emulation simulates operations that may occur if the Adobe® Reader application were actually or virtually being executed. One reason for such emulation is to detect malware exploits that are executed only upon detecting a certain version of the targeted application. If a malicious event is detected, a score that identifies the likelihood of the presence of malware within the analyzed file may be produced and provided for subsequent VM-based analysis of the content (blocks 350, 380 and 390).

If the malicious event is not detected, however, a determination is made as to whether further static analyses are to be conducted within the emulated environment for another version of the targeted application (block 360). Herein, the static analysis is associated with simulated operations of the targeted application, not operations associated with the targeted application being executed. This determination may be automatic, where all known versions of the targeted application are checked, or such determination may be manually set by an administrator to conduct checks only for certain versions of the targeted application. If further static scanning is to be conducted, processing of the file is emulated for a different version of the targeted application (block 370). If no further static scanning is to be conducted, the analyzed file (or portions of the analyzed file) is provided to analysis engine 190 of FIG. 1 for VM-based analysis.

Referring to FIG. 4, an exemplary diagram of a flowchart illustrating the multi-tier static scan analysis of FIG. 3 is shown. Herein, one or more files from network traffic routed over the communication network 130 of FIG. 1 are duplicated and provided to an electronic device (e.g., MCD system 110₁ of FIG. 1) that is adapted to perform the multi-tier static scan analysis (block 400). After the type of file has been determined, a first static scan analysis is conducted.

The first static scan analysis comprises statically scanning the content within the analyzed file. According to one embodiment of the disclosure, the content is compared to one or more pre-stored malware identifiers, which are associated with potential or known malware exploits (block 410). If a malicious event is detected, as an optional feature, a score that identifies the likelihood of the presence of malware within the analyzed file may be produced and assigned to the file prior to subsequent VM-based analysis of the content to confirm the presence of malware (blocks 420, 490 and 499).

In the event that no malicious event is detected, a second static scan analysis is conducted where the analyzed file undergoes deconstruction (e.g., decompress, disassemble, decompilation and/or de-obfuscate) to uncover one or more objects within the file and gain code-level access to these object(s) (block 430). Thereafter, these objects are statically scanned by subsequently comparing the contents to at least a subset of the pre-stored malware identifiers (block 440). If a malicious event is detected, a score that identifies the likelihood of the presence of malware within the deconstructed file may be produced and provided for subsequent VM-based analysis of the file (blocks 450, 490 and 499).

In the event that no malicious event is again detected, a third static scan analysis is conducted to emulate processing of the analyzed file by running emulation logic to simulate processing of the object(s) in order to determine if the analyzed file includes malware (block 460). Upon statically scanning the output from the emulation logic 270 (FIG. 2) for pre-stored malware identifiers, and if a match is determined thereby uncovering malicious activity, a score that identifies the likelihood of the presence of malware within the analyzed file may be produced and provided for subsequent VM-based analysis of the content (blocks 470, 480, 490 and 499). If the malicious event is not detected, the file (or particular object(s)) is provided for VM-based analysis (block 499).

It is contemplated that, during emulation, a determination may be made as to whether further static scanning is to be conducted on another version of the targeted application (block 495). If further static scanning is to be conducted, a different version of the targeted application is selected and processing of the file is emulated for that different version of the targeted application (block 497). If no further static scanning is to be conducted, the analyzed file (or portions of the analyzed file) is provided to analysis engine 190 of FIG. 1 for VM-based analysis (block 499).

In general, one inventive aspect is directed to a multi-tier static analysis that comprises deconstruction of the analyzed file and/or emulated processing of the analyzed file with results of the same being provided to the analysis engine 190 for subsequent VM-based analysis. This multi-tier static analysis is configured to improve accuracy and efficiency in malware analysis. As alternative embodiments, it is contemplated that any or all of the above-described static scan analyses may be conducted concurrently.

In some embodiments, based on a combination of the respective scores resulting from the static scans exceeding a threshold, the analyzed file may be classified as malicious, non-malicious, or, possibly, in need of further analysis, e.g., in VM-based analysis before classification may be made. It can be understood that, even if classified as a result of the static analysis, the file may be subjected to VM-based analysis to further identify characteristics and behaviors for use in later deterministic checks, for identifier comparison, for blocking, for remediation and for confirmation of static analysis results.

IV. Illustrative Static Scanning of PDF Files

Referring to FIG. 5, an exemplary diagram of a flowchart partially illustrating operations for static scan analysis of PDF files is shown. Herein, one or more PDF files from network traffic routed over the communication network 130 of FIG. 1 is duplicated and provided to an electronic device (e.g., MCD system 110₁ of FIG. 1) that is adapted to perform the multi-tier static scan analysis (block 500). After the “PDF” type has been determined, static scanning of the content of the PDF file is conducted, which may involve a pattern comparison or comparison of correlation of patterns between content within the analyzed file and one or more pre-stored malware identifiers and/or correlation logic to identify the file as malicious (block 510). If a malicious event is detected, the file (or one or more objects within the file) is provided for subsequent VM-based analysis to confirm the presence of malware (blocks 520 and 580). It is contemplated that, as an optional feature, a score that identifies the likelihood of the presence of malware within the analyzed file may be produced and assigned to the file (or the particular object under analysis).

If no malicious event is detected, the JavaScript® code is extracted from the PDF file. After extraction, the JavaScript® code is statically scanned for malware (block 530). Such static scanning may involve comparing portions of the code to certain malware identifiers. These malware identifiers may include known malware exploit patterns, vulnerable functions, and/or malicious patterns (e.g. shell code patterns, ROP patterns, heap spray patterns, etc.) and/or it may include correlation between the patterns in a file to determine malicious patterns which can be but not limited to shell code patterns, patterns to identify malicious downloader, etc. If a malicious event is detected, the file (along with the extracted JavaScript® code) is provided for subsequent VM-based analysis to confirm the presence of the malware exploit (blocks 540 and 580). Again, as an optional feature, a score that identifies the likelihood of the presence of malware within the file having the analyzed JavaScript® code may be produced and assigned accordingly.

In the event that no malicious event is detected, such as when the JavaScript® code itself is obfuscated, emulation of the JavaScript® code is conducted (block 550). During emulation, some of the functions (e.g. string evaluation functions, version check functions, timeout functions, vulnerable functions, etc.) associated with the JavaScript® code may be hooked. As a result, in response to a call to an Adobe® Reader™ application by any of these hooked functions for example, the emulation logic returns selected values in response to such calls. The returned values may allow for malware checks to be conducted on multiple versions of the emulated Adobe® Reader™ application.

For instance, as an illustrative example, in addition to providing a version number in case of emulation, the general processing of certain calls, such as Sleep calls for example, are disrupted by emulation. Basically, software “hooks” are applied to an API call responsible for making a Sleep call, and once this API is called, the MCD system 110₁ provides selected values in response to the hooked Sleep call and monitors resulting outputs.

Also, in the event that the PDF file is dependent upon a particular version of Adobe® Reader™ application and this version number is returned, an output of the emulator will identify a code path associated with anomalous behavior that may be used to identify the JavaScript® code as malicious through a static scanning operation of the output or the data exchanged with the hooked functions. As a result, the hooking results in completing the emulated processing along with the output are used for classification of the file and/or JavaScript® code object as malicious.

If a malicious event is detected, the emulation logic routes the uncovered exploit name obtained from management system 120 (see FIG. 1), score, and version number of the Adobe® Reader™ application to the analysis engine for VM-based analysis (blocks 560-570). However, if a malicious event is still not detected, the file (or particular object(s)) is simply provided to the analysis engine for subsequent VM-based analysis (block 580).

V. Illustrative Static Scanning of Flash Files

Referring to FIG. 6, an exemplary diagram of a flowchart partially illustrating operations for static scan analysis of Flash files is shown. Herein, one or more Flash files from network traffic routed over the communication network 130 of FIG. 1 are duplicated and provided to an electronic device (e.g., MCD system 110₁ of FIG. 1) that is adapted to perform the multi-tier static scan analysis (block 600). After the file is determined to be a “Flash” file, static scanning of content within the Flash file is conducted, which may include pattern comparison between one or more malware identifiers associated with potential or known malware attacks and content within the Flash file (block 610). If malicious event is detected, the Flash file (or one or more objects within the Flash file) is provided for subsequent VM-based analysis to confirm the presence of malware (blocks 620 and 690). It is contemplated that, as an optional feature, a score that identifies the likelihood of the presence of malware within the analyzed file may be produced and assigned to the particular Flash file (or object(s) associated with the Flash file).

If no malicious event is detected, the static deconstruction logic for Flash file types is invoked, which causes deconstruction of the Flash file (block 630). For instance, according to one embodiment of the disclosure, the Flash file may undergo decompression to detect embedded executable files. In combination with or in lieu of decompression, the deconstruction logic may disassemble and/or decompile the Flash file.

Thereafter, static scanning is conducted on the deconstructed file in order to detect the presence of malware (block 640). Such static scanning may involve comparing portions of the decompressed and/or disassembled Flash file to certain malware identifiers such as files with particular file extensions. If a malicious event is detected, the Flash file is provided for subsequent VM-based analysis to confirm the presence of the malware (blocks 650 and 690). Again, as an optional feature, a score that identifies the likelihood of the presence of malware within the Flash file may be produced and assigned accordingly.

In the event that no malicious event is detected, such as when portions of the Flash file are obfuscated (e.g., an embedded executable is encrypted), emulation of the Flash file is conducted where the Flash file code is processed (block 660). During emulation, for example, malware checks may be conducted which can be but are not limited to determining the presence of various malware exploits, such as embedded JavaScript® code or other embedded executables, or malicious HTTP requests. Also, certain functions associated with an uncovered JavaScript® code may be hooked. An output of the emulation logic is placed within a text (.txt) file, which undergoes a static scan for comparison and/or correlations between the patterns with malware identifiers, which can be but are not limited to exploit patterns, names of vulnerable functions, malicious patterns, or the like (block 670).

If a malicious event is detected, the emulation logic submits the Flash file to the analysis engine for further VM-based analysis (block 680). However, if the malicious event is still not detected, the Flash file (or particular object(s) within the Flash file) may be provided to the analysis engine for further VM-based analysis (block 690).

Accordingly, embodiments of the invention may perform one or more static scans to determine whether a file has malicious characteristics and/or behaviors. After each, the file may be declared malicious based on observed characteristics and/or behaviors and the resulting malware score. In some embodiments, following static scanning, the file may be submitted for more in-depth VM-based analysis. After a first static scan, if the file is not classified as malicious based on the score, the file may be deconstructed to provide access during a second static scan to objects embedded in or otherwise associated with the file whose access could not be had during the first static scan. After the second static scan, if the file is still not classified a malicious based the score, the file is submitted for emulation and then subjected to a third static scan. Of course, at any step during this process, if the malware score is sufficiently low, the file may be classified as non-malicious and analysis may be terminated. In some embodiments, termination does not occur, however, prior to VM-based testing regardless of the value of the score for reasons discussed hereinabove.

As briefly described above, each of the static scan analyses (or portions thereof) and the virtual execution environment may be conducted within the enterprise network and/or externally through cloud services. For instance, as illustrative examples, the static scans, file deconstruction and emulation may be performed at the enterprise network. Alternatively, the static scans and file deconstruction may be performed at the enterprise network, but emulation is conducted in the cloud. As another alternative, the static scans and the emulation may be performed at the enterprise network while the file deconstruction is conducted in the cloud. As yet another alternative, the file deconstruction and/or emulation may be performed at the enterprise network, but the static scans may be conducted in the cloud. As yet other alternatives, the first, second and/or third static scan analyses may be performed at either the enterprise network or the cloud, e.g. first and second static scan analyses may be performed at the enterprise network while the third static scan analysis is performed in the cloud. For all of these illustrative examples, virtual execution may be conducted in the enterprise network (e.g. by the MCD system) or may be conducted in the cloud.

It is further contemplated that the same general logic and operations as described for Flash files are applicable to JAVA® Archive (JAR) files. For instance, a JAR file is decompiled into JAVA® code on which checks are applied to determine if a file is malicious.

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.