System and method for detecting vulnerability exploits involving shellcode

Abstract

Detection of vulnerability exploits including shellcode is disclosed. Memory blocks are monitored during dynamic analysis of a sample to identify memory blocks including suspicious shellcode. The memory blocks are dumped in memory to identify candidate shellcode entry points associated with the suspicious shellcode. The suspicious shellcode is executed based on the candidate shellcode entry points to determine whether the suspicious shellcode is malicious. A judgment about the sample is generated based on the result of executing the suspicious shellcode.

Description

Background Art

[0001] Malware is a general term that is often used to refer to malicious software (e.g., including a variety of hostile, invasive, and / or otherwise unwanted software). Malware can be in the form of code, scripts, active content, and / or other software. Example uses of malware include disrupting computer and / or network operations, stealing proprietary information (e.g., confidential information, such as identity, financial, and / or intellectual property related information), and / or gaining access to private / proprietary computer systems and / or computer networks. As technologies are developed to help detect and mitigate malware, nefarious authors have found ways to circumvent such efforts. Therefore, there is a continuing need for improved technologies for identifying and mitigating malware. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various embodiments of the invention are disclosed in the following detailed description and accompanying drawings.

[0003] Figure 1 An example of an environment in which malicious applications are detected and prevented from causing harm is illustrated.

[0004] Figure 2A An embodiment of a data appliance is illustrated.

[0005] Figure 2B is a functional diagram of the logical components in an embodiment of a data appliance.

[0006] Figure 3 Examples of logical components that may be included in a system for analyzing a sample are illustrated.

[0007] Figure 4 An embodiment of an environment for analyzing malware samples is illustrated.

[0008] Figure 5 An embodiment of a process for detecting an exploit that includes shellcode is illustrated.

[0009] Figure 6 An embodiment of a process for monitoring a memory block during dynamic analysis of a sample is illustrated.

[0010] Figure 7

[0013] Another embodiment of a process for monitoring memory blocks during dynamic analysis of a sample is illustrated.

[0011] Figure 8 An embodiment of a process for dumping a memory block in memory is illustrated.

[0012] Fig. 9An embodiment of a process for executing suspicious shellcode is illustrated.

[0013] Fig.10 An embodiment of a process for executing suspicious shellcode using a CPU emulator is illustrated.

[0014] Fig.11 An embodiment of a process for executing suspicious shellcode using a full-system emulator is illustrated.

[0015] Fig.12 An example of a process for detecting a vulnerability exploit that includes shellcode is illustrated. DETAILED DESCRIPTION

[0016] The present invention may be implemented in a variety of ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer-readable storage medium; and / or a processor, such as a processor configured to execute instructions stored on and / or provided by a memory coupled to the processor. In this specification, these implementations or any other form that the present invention may take may be referred to as techniques. In general, within the scope of the present invention, the order of the steps of the disclosed processes may be changed. Unless otherwise stated, components such as processors or memories described as being configured to perform tasks may be implemented as general components that are temporarily configured to perform tasks at a given time, or are manufactured to perform specific components of the task. As used herein, the term "processor" refers to one or more devices, circuits, and / or processing cores configured to process data such as computer program instructions.

[0017] The following provides a detailed description of one or more embodiments of the present invention together with the accompanying drawings that illustrate the principles of the present invention. The present invention is described in conjunction with such embodiments, but the present invention is not limited to any embodiment. The scope of the present invention is limited only by the claims and the present invention includes many alternatives, modifications and equivalents. In order to provide a thorough understanding of the present invention, many specific details are set forth in the following description. These details are provided for the purpose of example and the present invention can be practiced according to the claims without some or all of these specific details. For the sake of clarity, technical materials known in the technical field related to the present invention are not described in detail, so that the present invention is unnecessarily obscured.

[0018] Typically, the vulnerability exploit uses a memory attribute change function to bypass the operating system mitigation to execute malicious shell code (a snippet of binary data) in the victim's computer. Existing vulnerability exploit detection technology only works in specific scenarios, each of which has its own limitations. Before executing the malicious shell code, the shell code is placed in the target process memory as legal data. For example, in a browser vulnerability exploit, an attacker uses JavaScript to construct an exploit, and the shell code is written into the browser process as a typical JavaScript object (e.g., a string or array) by the browser's JavaScript engine and stored in a legal heap, where the legal heap exists as data (not as code and cannot be executed). Subsequently, the vulnerability exploit triggers the vulnerability and controls the instruction pointer register (IP register). In modern operating systems (such as Windows, MacOS, Linux, etc.), data execution prevention (DEP) prevents shell code from being executed in memory by marking the memory as non-executable. However, the vulnerability exploit bypasses DEP and has executed shell code.

[0019] Typically, the exploit bypasses DEP by calling memory attribute change functions. The exploit can use a return-oriented programming (ROP) gadget to construct a ROP chain to call memory attribute change functions (e.g., VirtualAlloc and VirtualProtect on Windows, and mmap and mprotect for MacOS and Linux) to mark the memory containing the shell code as read|write|execute (RWE), and then execute the shell code. Typically, the exploit has the same permissions as a vulnerable application or a vulnerable software process such as a browser renderer process.

[0020] In some embodiments, a system / method / computer program product for detecting vulnerability exploits including shellcode includes monitoring memory blocks during dynamic analysis of a sample to identify memory blocks including suspicious shellcode; dumping the memory blocks into a memory to identify candidate shellcode entry points associated with the suspicious shellcode; based on the candidate shellcode entry points, executing the suspicious shellcode to determine whether the suspicious shellcode is malicious; and generating a verdict about the sample based on the result of executing the suspicious shellcode.

[0021] In some embodiments, monitoring memory blocks during dynamic analysis of samples to identify memory blocks that include suspicious shellcode includes hooking a memory attribute change function associated with the memory block to determine whether the memory attribute change function has been called and whether corresponding parameters have been provided to the memory attribute change function; and in response to a determination that the memory attribute change function has been called and the corresponding parameters have been provided to the memory attribute change function, determining that the memory block includes the suspicious shellcode.

[0022] In some embodiments, monitoring memory blocks during dynamic analysis of a sample to identify memory blocks that include suspicious shellcode includes performing an offline scan of a process memory to determine whether the memory blocks have specific memory attributes; and in response to a determination that the memory blocks have the specific memory attributes, determining that the memory blocks include suspicious shellcode.

[0023] In some embodiments, dumping a memory block in memory to identify a candidate shell code entry point associated with the suspicious shell code includes identifying a specific assembly code pattern or a specific data structure in the memory block including the suspicious shell code; and determining the candidate shell code entry point based on the specific assembly code pattern or the specific data structure.

[0024] In some embodiments, the execution of the suspicious shell code includes executing the suspicious shell code using a CPU emulator based on the candidate shell code entry point; and executing the suspicious shell code using a full system emulator based on the candidate shell code entry point.

[0025] In some embodiments, executing suspicious shell code using a CPU emulator includes simulating the execution of the suspicious shell code using the CPU emulator; determining whether assembly instructions associated with the simulated execution of the suspicious shell code match a predetermined shell code pattern; and determining that the suspicious shell code is malicious in response to a determination that the assembly instructions associated with the simulated execution of the suspicious shell code match the predetermined shell code pattern.

[0026] In some embodiments, executing suspicious shell code using a full-system emulator includes executing the suspicious shell code in a memory inside an operating system running in the full-system emulator; monitoring hooked application programming interface (API) functions to determine whether the suspicious shell code calls the hooked API function; and determining that the suspicious shell code is malicious in response to a determination that the suspicious shell code calls the hooked API function.

[0027] In some embodiments, the system / method / computer program product further comprises generating a signature for the malware sample in response to a determination of the verdict indicating that the sample is malicious.

[0028] In some embodiments, the system / method / computer program product further comprises, in response to a determination that the judgment indicates that the sample is malicious: generating a signature for the malware sample; and distributing the signature to a firewall.

[0029] I. Overview

[0030] A firewall generally protects a network from unauthorized access while allowing authorized communications to pass through the firewall. A firewall is generally a device, a set of devices, or software executed on a device that provides firewall functionality for network access. For example, a firewall can be integrated into the operating system of a device (e.g., a computer, a smart phone, or other type of device with network communication capabilities). A firewall can also be integrated into or executed as one or more software applications on various types of devices, such as computer servers, gateways, network / routing devices (e.g., network routers), and data appliances (e.g., security appliances or other types of specialized devices), and in various implementations, certain operations can be implemented in specialized hardware such as ASICs or FPGAs.

[0031] Firewalls typically deny or allow network transmissions based on a set of rules. These rule sets are often referred to as policies (e.g., network policies or network security policies). For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted external traffic from reaching the protected device. A firewall can also filter outbound traffic by applying a set of rules or policies (e.g., allowing, blocking, monitoring, notifying, or logging, and / or other actions can be specified in firewall rules or firewall policies, such as described herein, which can be triggered based on various criteria). A firewall can also filter local network (e.g., intranet) traffic by similarly applying a set of rules or policies.

[0032] Security devices (e.g., security appliances, security gateways, security services, and / or other security devices) may include various security functions (e.g., firewalls, anti-malware, intrusion prevention / detection, data loss prevention (DLP), and / or other security functions), networking functions (e.g., routing, quality of service (QoS), workload balancing of network-related resources, and / or other networking functions), and / or other functions. For example, routing functions may be based on source information (e.g., IP address and port), destination information (e.g., IP address and port), and protocol information.

[0033] Basic packet filtering firewalls filter network communication traffic by inspecting individual packets transmitted on the network (e.g., packet filtering firewalls or first generation firewalls, which are stateless packet filtering firewalls). Stateless packet filtering firewalls typically inspect the individual packets themselves and apply rules based on the inspected packets (e.g., using a combination of the packet's source and destination address information, protocol information, and port numbers).

[0034] Application firewalls can also perform application layer filtering (e.g., application layer filtering firewalls or second generation firewalls, which work at the application level of the TCP / IP stack). Application layer filtering firewalls or application firewalls can generally identify certain applications and protocols (e.g., web browsing using Hypertext Transfer Protocol (HTTP), Domain Name System (DNS) requests, file transfers using File Transfer Protocol (FTP), and various other types of applications and other protocols such as Telnet, DHCP, TCP, UDP, and TFTP (GSS). For example, an application firewall can block unauthorized protocols that attempt to communicate over standard ports (e.g., unauthorized / out of policy protocols that attempt to sneak through using non-standard ports for the protocol can generally be identified using an application firewall).

[0035] A stateful firewall can also perform state-based packet inspection, where each packet is inspected within the context of a series of packets associated with the packet stream transmitted by the network. This firewall technology is often referred to as stateful packet inspection because it maintains a record of all connections passing through the firewall and is able to determine whether a packet is the beginning of a new connection, part of an existing connection, or an invalid packet. For example, the state of the connection itself can be one of the criteria for triggering a rule within a policy.

[0036] As discussed above, advanced or next-generation firewalls can perform stateless and stateful packet filtering and application layer filtering. Next-generation firewalls can also perform additional firewall technologies. For example, some newer firewalls, sometimes referred to as advanced or next-generation firewalls, can also identify users and content (e.g., next-generation firewalls). In particular, some next-generation firewalls are expanding the list of applications that these firewalls can automatically identify to thousands of applications. Examples of such next-generation firewalls are commercially available from Palo Alto Networks, Inc. (e.g., Palo Alto Networks' PA series firewalls). For example, Palo Alto Networks' next-generation firewalls enable enterprises to use a variety of identification technologies to identify and control applications, users, and content—not just ports, IP addresses, and packets, such as the following: APP-ID for accurate application identification, User-ID for user identification (e.g., by user or user group), and Content-ID for real-time content scanning (e.g., controlling web surfing and limiting data and file transfers). These identification technologies allow enterprises to safely enable application use using business-related concepts, rather than following the traditional methods provided by traditional port blocking firewalls. Moreover, dedicated hardware for next-generation firewalls (e.g., implemented as a dedicated appliance) generally provides higher performance levels for application inspection than software executed on general-purpose hardware (e.g., such as security appliances provided by Palo Alto Networks, Inc., which use dedicated, function-specific processing that is tightly integrated with a single-pass software engine to maximize network throughput and minimize latency).

[0037] Advanced or next-generation firewalls may also be implemented using virtualized firewalls. Examples of such next-generation firewalls are commercially available from Palo Alto Networks, Inc. (e.g., Palo Alto Networks' VM-series firewalls, which support a variety of commercial virtualization environments, including, for example, ESXi TM and NSX TM , NetScaler SDX TM , KVM / OpenStack (Centos / RHEL, ) and Amazon Web Services (AWS). For example, the virtualized firewall can support similar or identical next-generation firewall and advanced threat prevention features available in a physical form factor appliance, allowing enterprises to securely enable applications to flow into and across their private, public and hybrid cloud computing environments. Automation features such as VM monitoring, dynamic address groups and REST-based APIs allow enterprises to proactively monitor VM changes, dynamically feed that context into security policies, eliminating policy lags that can occur when VMs change.

[0038] II. Sample Environment

[0039] Figure 1 An example of an environment in which malicious applications ("malware") are detected and prevented from causing harm is illustrated. As will be described in more detail below, malware classification (e.g., as made by security platform 122) may be performed in Figure 1 The environments shown in FIG. 1 and FIG. 2 are variously shared and / or refined between the various entities included in the environments shown in FIG. 1 and FIG. 3 . Also, using the techniques described herein, devices such as endpoint client devices 104 - 110 may be protected from such malware.

[0040] The term "application" is used throughout the specification to collectively refer to a program, a bundle of programs, a manifest, a package, etc. that is independent of form / platform. An "application" (also referred to as a "sample" herein) can be a standalone file (e.g., a calculator application with a file name "calculator.apk" or "calculator.exe") and can also be an independent component of another application (e.g., a mobile advertising SDK or library embedded in a calculator application).

[0041] As used herein, "malware" refers to an application that participates in an action, whether secretly (and whether illegal or not), and the user does not approve it / will not approve it in full knowledge. Examples of malware include Trojans, viruses, root kits (rootkits), spyware, hacker tools, keyboard loggers, etc. An example of malware is a desktop application that collects and reports the location of the end user to a remote server (but does not provide location-based services, such as map services, to the user). Another example of malware is a malicious Android application package .apk (APK) file, which appears to the end user as a free game, but secretly sends SMS premium messages (e.g., each costs $10), thereby rapidly increasing the end user's phone bill. Another example of malware is an Apple iOS flashlight application, which secretly collects the user's contacts and sends those contacts to spammers (spammers). Other forms of malware (such as ransomware) can also be detected / thwarted using the technology described herein.

[0042] The techniques described herein can be used in conjunction with a variety of platforms (e.g., desktops, mobile devices, gaming platforms, embedded systems, etc.) and / or a variety of types of applications (e.g., Android apk files, iOS applications, Windows PE files, Adobe Acrobat PDF files, etc.) across a variety of CPU architectures. Figure 1 In the example environment shown in , client devices 104-108 (respectively) are a laptop computer, a desktop computer, and a tablet device that reside within an enterprise network 140. Client device 110 is a laptop computer that resides outside of enterprise network 140.

[0043] Data appliance 102 is configured to implement policies regarding communications between client devices such as client devices 104 and 106 and nodes external to enterprise network 140 (e.g., reachable via external network 118). Examples of such policies include policies governing traffic shaping, quality of service, and traffic routing. Other examples of policies include security policies, such as policies requiring scanning for threats in incoming (and / or outgoing) email attachments, web site content, files exchanged via instant messaging programs, and / or other file transfers. In some embodiments, data appliance 102 is also configured to implement policies regarding traffic that resides within enterprise network 140.

[0044] An embodiment of the data device is Figure 2A. The example shown is a representation of the physical components included in the data appliance 102 in various embodiments. Specifically, the data appliance 102 includes a high-performance multi-core central processing unit (CPU) 202 and a random access memory (RAM) 204. The data appliance 102 also includes a storage device 210 (such as one or more hard disks or solid-state storage units). In various embodiments, the data appliance 102 stores (whether in RAM 204, storage device 210 and / or other appropriate locations) information used in monitoring the enterprise network 140 and implementing the disclosed technology. Examples of such information include application identifiers, content identifiers, user identifiers, requested URLs, IP address mappings, policies and other configuration information, signatures, host name / URL classification information, malware profiles, and machine learning models. The data appliance 102 may also include one or more optional hardware accelerators. For example, the data appliance 102 may include a cryptographic engine 206 configured to perform encryption and decryption operations, and one or more field programmable gate arrays (FPGAs) 208 configured to perform matching, act as a network processor, and / or perform other tasks.

[0045] The functionality described herein as performed by data appliance 102 may be provided / implemented in a variety of ways. For example, data appliance 102 may be a dedicated device or set of devices. The functionality provided by data appliance 102 may also be integrated into a general-purpose computer, computer server, gateway, and / or network / routing device, or executed as software thereon. In some embodiments, at least some of the services described as being provided by data appliance 102 are alternatively (or additionally) provided to a client device (e.g., client device 104 or client device 110) by software executed on the client device.

[0046] Whenever the data appliance 102 is described as performing a task, a single component, a subset of components, or all components of the data appliance 102 may collaborate to perform the task. Similarly, whenever a component of the data appliance 102 is described as performing a task, a subcomponent may perform the task and / or the component may perform the task in conjunction with other components. In various embodiments, portions of the data appliance 102 are provided by one or more third parties. Depending on factors such as the amount of computing resources available to the data appliance 102, various logical components and / or features of the data appliance 102 may be omitted, and the techniques described herein are adapted accordingly. Similarly, additional logical components / features may be included in the embodiments of the data appliance 102, as applicable. In various embodiments, an example of a component included in the data appliance 102 is an application identification engine, which is configured to identify an application (e.g., using various application signatures for identifying an application based on packet flow analysis). For example, an application identification engine may determine what traffic type a session involves, such as Web browsing-social networking; Web browsing-news; SSH; and the like.

[0047] Figure 2B 102 is a functional diagram of the logical components of an embodiment of a data appliance. The examples shown are representations of the logical components that may be included in the data appliance 102 in various embodiments. Unless otherwise specified, the various logical components of the data appliance 102 are generally implementable in a variety of ways, including as a collection of one or more scripts (e.g., written in Java, python, etc., where applicable).

[0048] As shown, the data appliance 102 includes a firewall and includes a management plane 232 and a data plane 234. The management plane is responsible for managing user interactions, such as by providing a user interface for configuring policies and viewing log data. The data plane is responsible for managing data, such as by performing packet processing and session processing.

[0049] The network processor 236 is configured to receive packets from client devices such as the client device 108 and provide them to the data plane 234 for processing. Whenever the flow module 238 identifies a packet as part of a new session, it creates a new session flow. Based on the flow lookup, subsequent packets will be identified as belonging to the session. If applicable, SSL decryption is applied by the SSL decryption engine 240. Otherwise, the processing of the SSL decryption engine 240 is omitted. The decryption engine 240 can help the data appliance 102 inspect and control SSL / TLS and SSH encrypted traffic and thus help stop threats that may otherwise remain hidden in the encrypted traffic. The decryption engine 240 can also help prevent sensitive content from leaving the enterprise network 140. Decryption can be selectively controlled (e.g., enabled or disabled) based on parameters such as: URL category, traffic source, traffic destination, user, user group, and port. In addition to decryption policies (e.g., specifying which sessions to decrypt), decryption profiles can also be assigned to control various options for policy-controlled sessions. For example, the use of specific cipher suites and encryption protocol versions can be required.

[0050] The application identification (APP-ID) engine 242 is configured to determine what type of traffic the session involves. As an example, the application identification engine 242 can identify a GET request in the received data and infer that the session requires an HTTP decoder. In some cases, such as a web browsing session, the identified application can change, and such a change will be noticed by the data appliance 102. For example, a user may initially browse to a company wiki (classified as "Web Browsing - Productivity" based on the URL visited), and then subsequently browse to a social networking site (classified as "Web Browsing - Social Networking" based on the URL visited). Different types of protocols have corresponding decoders.

[0051] Based on the determination made by the application identification engine 242, the threat engine 244 sends the packet to the appropriate decoder, which is configured to assemble the packets (which may be received out of order) into the correct order, perform tokenization, and extract the information. The threat engine 244 also performs signature matching to determine what should happen to the packet. The SSL encryption engine 246 can re-encrypt the decrypted data as needed. The forwarding module 248 is used to forward the packet for transmission (e.g., to a destination).

[0052] Still like Figure 2BAs shown in , policies 252 are received and stored in the management plane 232. The policies may include one or more rules, which may be specified using domain names and / or host / server names, and the rules may apply one or more signatures or other matching criteria or heuristics, such as for security policy enforcement for subscribers / IP flows based on various parameters / information extracted from monitored session traffic flows. An interface (I / F) communicator 250 is provided for management communications (e.g., via (REST) ​​APIs, messages or network protocol communications, or other communication mechanisms).

[0053] III. Security Platform

[0054] Back to Figure 1 , assume that a malicious individual (using system 120) has created malware 130. The malicious individual hopes that a client device, such as client device 104, will execute a copy of malware 130, compromising the client device and, for example, causing the client device to become a bot in a botnet. The compromised client device may then be instructed to perform tasks (e.g., cryptocurrency mining, or engaging in a denial of service attack) and report information to an external entity, such as a command and control (C&C) server 150, and, where applicable, receive instructions from the C&C server 150.

[0055] Assume that data appliance 102 has intercepted (e.g., by system 120) an email sent to user "Alice" operating client device 104. System 120 has attached a copy of malware 130 to the message. As an alternative but similar scenario, data appliance 102 may intercept an attempt by client device 104 to download malware 130 (e.g., from a website). In either scenario, data appliance 102 determines whether a signature for a file (e.g., an email attachment or website download of malware 130) is present on data appliance 102. The signature, if present, may indicate that the file is known to be safe (e.g., whitelisted) and may also indicate that the file is known to be malicious (e.g., blacklisted).

[0056] In various embodiments, the data appliance 102 is configured to work in conjunction with the security platform 122. As an example, the security platform 122 may provide the data appliance 102 with a collection of signatures of known malicious files (e.g., as part of a subscription). If the signature of the malware 130 is included in the collection (e.g., an MD5 hash of the malware 130), the data appliance 102 may accordingly prevent the transmission of the malware 130 to the client device 104 (e.g., by detecting that the MD5 hash of the email attachment sent to the client device 104 matches the MD5 hash of the malware 130). The security platform 122 may also provide the data appliance 102 with a list of known malicious domains and / or IP addresses, thereby allowing the data appliance 102 to block traffic between the enterprise network 140 and the C&C server 150 (e.g., where the C&C server 150 is known to be malicious). The list of malicious domains (and / or IP addresses) may also help the data appliance 102 determine when one of its nodes has been compromised. For example, if a client device 104 attempts to contact a C&C server 150, such an attempt is a strong indicator that the client 104 has been compromised by malware (and remedial action should be taken accordingly, such as isolating the client device 104 from communicating with other nodes within the enterprise network 140).

[0057] In various embodiments, if the signature of the attachment is not found, the data appliance 102 can take a variety of actions. As a first example, the data appliance 102 can fail-safe by blocking the transmission of any attachment that is not whitelisted as benign (e.g., does not match the signature of a known good file). The disadvantage of this method is that there may be many legitimate attachments that are unnecessarily blocked as potential malware when they are actually benign. As a second example, the data appliance 102 can fail-danger by allowing the transmission of any attachment that is not blacklisted as malicious (e.g., does not match the signature of a known bad file). The disadvantage of this method is that newly created (unprecedented) malware that the platform 122 has not seen before will not be prevented from causing harm.

[0058] As a third example, the data appliance 102 may be configured to provide a file (e.g., malware 130) to the security platform 122 for static / dynamic analysis to determine whether it is malicious and / or otherwise classify it. When the security platform 122 performs analysis on an attachment (whose signature no longer exists), the data appliance 102 may take a variety of actions. As a first example, the data appliance 102 may prevent an email (and attachment) from being delivered to Alice until a response is received from the security platform 122. Assuming that the platform 122 spends nearly 15 minutes to thoroughly analyze the sample, this means that incoming messages to Alice will be delayed by 15 minutes. In this example, since the attachment is malicious, such a delay will not have a negative impact on Alice. In an alternative example, assuming that someone has sent a time-sensitive message with a benign attachment to Alice, the signature of the time-sensitive message also does not exist. Delaying the delivery of a message to Alice by 15 minutes will likely be considered unacceptable (e.g., by Alice). An alternative approach would be to perform at least some real-time analysis of the attachment on data appliance 102 (e.g., while awaiting a verdict from platform 122). If data appliance 102 can independently determine whether the attachment is malicious or benign, it can take an initial action (e.g., block or allow delivery to Alice), and once a verdict is received from security platform 122, can adjust / take additional actions if applicable.

[0059] Security platform 122 stores a copy of the received sample in storage device 142 and begins analysis (or schedules analysis where applicable). An example of storage device 142 is an Apache Hadoop cluster (HDFS). The results of the analysis (and additional information related to the application) are stored in database 146. In the event that the application is determined to be malicious, the data appliance can be configured to automatically block the file download based on the analysis results. In addition, signatures can be generated for malware and distributed (e.g., to data appliances such as data appliances 102, 136, and 148) to automatically block future file transfer requests to download files determined to be malicious.

[0060] In various embodiments, the security platform 122 includes one or more dedicated commercially available hardware servers (e.g., with (one or more) multi-core processors, 32G+ of RAM, (one or more) gigabit network interface adapters, and (one or more) hard drives) running a typical server-class operating system (e.g., Linux). The security platform 122 can be implemented across a scalable infrastructure including multiple such servers, solid-state drives, and / or other applicable high-performance hardware. The security platform 122 may include several distributed components, including components provided by one or more third parties. For example, part or all of the security platform 122 may be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3). In addition, as with the data appliance 102, whenever the security platform 122 is referred to as performing a task such as storing data or processing data, it will be understood that a subcomponent or multiple subcomponents of the security platform 122 (whether alone or in collaboration with third-party components) may collaborate to perform the task. As an example, in various embodiments, the security platform 122 collaborates with one or more virtual machine (VM) servers such as VM server 124 to perform static / dynamic analysis.

[0061] An example of a virtual machine server is a physical machine that includes commercially available server-class hardware (e.g., multi-core processors, 32+ gigabytes of RAM, and one or more gigabyte network interface adapters) running open source and / or commercially available virtualization software such as Linux kernel-based virtual machines (KVM), VMware ESXi, Citrix XenServer, and Microsoft Hyper-V. Customized virtualization software and / or the functionality of commercially available virtualization software extended as needed can also be used to support the various functionalities described herein (e.g., as provided by a hypervisor). In addition, the virtual machine server can be under the control of the same entity that manages the security platform 122, but can also be provided by a third party. As an example, the virtual machine server can rely on EC2, where the rest of the security platform 122 is provided by dedicated hardware owned and under the control of the operator of the security platform 122. The VM server 124 is configured to provide one or more virtual machines 126-128 to emulate client devices. The virtual machine can execute a variety of operating systems and / or versions thereof. Logs are recorded and analyzed for observed behavior (e.g., indications that the application is malicious) from executing applications in virtual machines. In some embodiments, the log analysis is performed by a VM server (eg, VM server 124). In other embodiments, the analysis is performed at least in part by other components of security platform 122, such as orchestrator 144.

[0062] In various embodiments, the security platform 122 makes its sample analysis results available to the data appliance 102 via a list of signatures (and / or other identifiers) as part of a subscription. For example, the security platform 122 may periodically send content packages that identify malware applications (e.g., daily, hourly, or some other interval, and / or based on events configured by one or more policies). An example content package includes a list of identified malware applications with information such as the package name, a hash value for uniquely identifying the application, and the malware name (and / or malware family name) for each identified malware application. The subscription may cover analysis of just those files that are intercepted by the data appliance 102 and sent to the security platform 122 by the data appliance 102, and may also cover signatures for all malware known to the security platform 122 (or a subset thereof, such as only mobile malware, but not other forms of malware (e.g., PDF malware)).

[0063] In various embodiments, security platform 122 is configured to provide security services to a variety of entities in addition to (or, where applicable, in lieu of) the operator of data appliance 102. For example, other enterprises with their own respective enterprise networks 114 and 116 and their own respective data appliances 136 and 148 may contract with the operator of security platform 122. Other types of entities may also utilize the services of security platform 122. For example, an Internet service provider (ISP) that provides Internet service to client device 110 may contract with security platform 122 to analyze applications that client device 110 attempts to download. As another example, an owner of client device 110 may install software on client device 110 that communicates with security platform 122 (e.g., receives content packages from security platform 122, uses the received content packages to inspect attachments according to the techniques described herein, and transmits applications to security platform 122 for analysis).

[0064] IV. Analyze the sample using static / dynamic analysis

[0065] Figure 3 Examples of logical components that may be included in a system for analyzing samples are illustrated. Analysis system 300 may be implemented using a single device. For example, the functionality of analysis system 300 may be implemented in a malware analysis module 112 incorporated into data appliance 102. Analysis system 300 may also be implemented across multiple different devices. For example, the functionality of analysis system 300 may be provided by security platform 122, or provided as a separate device located within network 140 and communicating with data appliance 102 (e.g., including various applicable components described herein as provided by security platform 122, such as virtual machine server 124).

[0066] In various embodiments, the analysis system 300 utilizes a list, database, or other collection (in Figure 3 102 and / or security platform 122). Collection 314 may be obtained in a variety of ways, including via a subscription service (e.g., provided by a third party) and / or as a result of other processing (e.g., performed by data appliance 102 and / or security platform 122). Examples of information included in collection 314 are: URLs, domain names, and / or IP addresses of known malicious servers; URLs, domain names, and / or IP addresses of known secure servers; URLs, domain names, and / or IP addresses of known command and control (C&C) domains; signatures, hashes, and / or other identifiers of known malicious applications; signatures, hashes, and / or other identifiers of known secure applications; signatures, hashes, and / or other identifiers of known malicious files (e.g., Android exploit files); signatures, hashes, and / or other identifiers of known secure libraries; and signatures, hashes, and / or other identifiers of known malicious libraries.

[0067] A. Ingestion

[0068] In various embodiments, when a new sample is received for analysis (e.g., an existing signature associated with the sample does not exist in the analysis system 300), it is added to the queue 302. Figure 3 As shown in , system 300 receives application 130 and adds it to queue 302 .

[0069] B. Static Analysis

[0070] A coordinator 304 monitors the queue 302, and when resources (e.g., static analysis workers) become available, the coordinator 304 takes samples from the queue 302 for processing (e.g., taking a copy of the malware 130). In particular, the coordinator 304 first provides samples to the static analysis engine 306 for static analysis. In some embodiments, one or more static analysis engines are included in the analysis system 300, where the analysis system 300 is a single device. In other embodiments, static analysis is performed by a separate static analysis server that includes multiple workers (i.e., multiple instances of the static analysis engine 306).

[0071] The static analysis engine obtains general information about the sample and includes it (along with heuristic information and other information, where applicable) in a static analysis report 308. The report may be created by the static analysis engine, or by the coordinator 304 (or another appropriate component), which may be configured to receive information from the static analysis engine 306. In some embodiments, the collected information is stored in a database record for the sample (e.g., in a database 316), instead of or in addition to creating a separate static analysis report 308 (i.e., forming part of the database record of the report 308). In some embodiments, the static analysis engine also forms a verdict about the application (e.g., "safe", "suspicious", or "malicious"). As an example, if there is even one "malicious" static feature in the application (e.g., the application includes a hard link to a known malicious domain), the verdict may be "malicious". As another example, each feature can be assigned points (e.g., based on severity if found; based on how reliable the feature is for predicting maliciousness; etc.) and a judgment can be assigned by the static analysis engine 306 (or the coordinator 304, where applicable) based on the number of points associated with the static analysis results.

[0072] C. Dynamic Analysis

[0073] Once the static analysis is complete, the coordinator 304 locates an available dynamic analysis engine 310 to perform dynamic analysis on the application. As with the static analysis engine 306, the analysis system 300 may directly include one or more dynamic analysis engines. In other embodiments, the dynamic analysis is performed by a separate dynamic analysis server that includes multiple workers (i.e., multiple instances of the dynamic analysis engine 310).

[0074] Each dynamic analysis worker manages a virtual machine instance. In some embodiments, the results of the static analysis (e.g., performed by the static analysis engine 306), whether in the form of a report (308) and / or as stored in a database 316, or stored in other ways, are provided as input to the dynamic analysis engine 310. For example, the static analysis report information can be used to help select / customize / configure the virtual machine instance used by the dynamic analysis engine 310 (e.g., Microsoft Windows 7SP 2 vs. Microsoft Windows 10Enterprise, or iOS11.0 vs. iOS12.0). In the case of multiple virtual machine instances executing simultaneously, a single dynamic analysis engine can manage all instances, or multiple dynamic analysis engines can be used (e.g., each of which manages its own virtual machine instance). As will be explained in more detail below, during the dynamic portion of the analysis, the actions taken by the analysis application (including network activity) are analyzed.

[0075] In various embodiments, static analysis of samples is omitted or performed by a separate entity, where applicable. As an example, a first entity may perform traditional static and / or dynamic analysis on a file. Once a given file is determined to be malicious (e.g., by a first entity), the file may be provided to a second entity (e.g., an operator of security platform 122) specifically for additional analysis (e.g., by dynamic analysis engine 310) regarding the malware's use of network activity.

[0076] The environment used by the analysis system 300 is instrumented / hooked so that behaviors observed while the application is executing are logged as they occur (e.g., using a custom kernel that supports hooking and logcat). Network traffic associated with the emulator is also captured (e.g., using pcap). The log / network data can be stored as temporary files on the analysis system 300, and can also be stored more permanently (e.g., using HDFS or another appropriate storage technology or combination of technologies such as MongoDB). The dynamic analysis engine (or another appropriate component) can compare the connections made by the sample to a list of domains, IP addresses, etc. (314) and determine whether the sample has communicated (or attempted to communicate) with a malicious entity.

[0077] As with the static analysis engine, the dynamic analysis engine stores the results of its analysis in a database 316 in a record associated with the tested application (and / or includes the results in a report 312, where applicable). In some embodiments, the dynamic analysis engine also forms a judgment about the application (e.g., "safe," "suspicious," or "malicious"). As an example, if the application takes even one "malicious" action (e.g., an attempt is made to contact a known malicious domain, or an attempt is observed to leak sensitive information), the judgment may be "malicious." As another example, points may be assigned to the actions taken (e.g., if found, based on severity; based on how reliable the action is for predicting maliciousness; etc.) and the judgment may be assigned by the dynamic analysis engine 310 (or the coordinator 304, where applicable) based on the number of points associated with the dynamic analysis results. In some embodiments, a final judgment associated with the sample is made based on a combination of the report 308 and the report 312 (e.g., by the coordinator 304).

[0078] V. Simulating User Interactions for Malware Analysis

[0079] Malware authors are using increasingly sophisticated techniques when crafting their malware so that it evades detection by security analysis systems. One such technique is for the malware to attempt to determine whether it is being executed in a virtual machine environment, and if so, to refrain from execution or otherwise not engage in malicious activity. By doing so, the security analysis system may erroneously conclude that the malware sample is benign because it was not observed by the security analysis system to engage in malicious behavior during dynamic analysis. As will be described in more detail below, in various embodiments, the platform 122 and / or data appliance 102 or other one or more components utilize techniques, where applicable, to help thwart malware samples from detecting that they are being executed in a virtualized environment. By preventing malware samples from determining that they are being executed in a virtualized environment, successful detection of the sample as malicious is more likely to occur because the malware sample will be more likely to engage in malicious behavior when executed in a virtualized environment.

[0080] One way malware can determine whether it is executed in a virtual machine environment is by looking for a marker that it is being manipulated / executed by a guest operating system. As an example, in a typical virtualized environment, a sample to be tested (e.g., sample 130) can be renamed (e.g., from its original name as observed by data appliance 102) to a default name, such as "sample.exe". A script (e.g., "autoexec.bat") will be automatically executed by the guest operating system at startup, and directly start or cause the startup of the sample (e.g., by a dynamic analysis assistant tool). Since the malware sample and the dynamic analysis helper script / tool ​​are all located side by side in the user space of the guest OS, the presence of the dynamic analysis script / tool ​​on the guest OS will be visible to the malware, and information such as the malware being started by a script (or tool) and / or the malware having been renamed will also be visible to the malware. In addition, the dynamic analysis assistant tool can make use of OS API calls (e.g., instructing the operating system to take various actions such as keyboard input). Malware can observe the use of those API calls by the dynamic analysis assistant tool. If the execution sample determines that it is being executed in a virtualized environment, it can refrain from participating in malicious actions and avoid being marked as malicious by the dynamic analysis system.

[0081] Another way malware can determine whether it is executing in a virtual machine environment is by looking for signs that a human is interacting with the system on which the malware is executing. If a human does not appear to be interacting with the system, the malware may refrain from engaging in malicious actions. As an example, a malicious document may engage in malicious behavior only after a certain set of actions have been taken within the word processing application used to launch the malicious document (e.g., scrolling down four pages with a mouse, or performing a certain number of mouse clicks). As another example, a malicious spreadsheet that includes multiple worksheets may refrain from taking malicious actions until each worksheet has been clicked with a mouse.

[0082] Some virtualized dynamic analysis environments may attempt to replicate user behavior through scripting / hooking (e.g., using guest OS API calls to press keyboard keys or move mouse positions). However, increasingly sophisticated malware is aware of when such OS API calls are used and can therefore detect that such interactions are automatically generated by the dynamic analysis system, rather than by a human end user. As such, malicious documents may require more complex human-use markers that are not amenable to scripting before exhibiting malicious behavior (e.g., using the mouse to scroll down four pages, performing a certain number of mouse clicks, etc.).

[0083] A. Sample Environment

[0084] Figure 4 An embodiment of an environment for analyzing malware samples is illustrated. Environment 400 is an example of components that may be included in system 300 (eg, as dynamic analysis engine 310). Figure 4 In the example shown in , a dynamic analyzer host OS (404), such as Ubuntu for x86_64, runs on appropriate hardware (402), such as Intel x86 or x86_64 based hardware. A hypervisor (406) runs a virtual machine with a guest OS (408) appropriate for the type of sample being analyzed (e.g., 64-bit Windows 7 SP 2 or MacOS X) and various applications pre-installed where applicable (e.g., Microsoft Office, Adobe Acrobat, Mozilla Firefox, Safari, etc.).

[0085] As previously mentioned, when performing dynamic analysis in a virtualized environment, one approach is to launch the sample 410 via a script or tool that executes within the guest OS 408. For example, a helper tool installed on the guest OS 408 may rely on the Windows API to detect new items and message boxes on the desktop, perform keyboard presses and movements, etc. However, as mentioned above, one drawback of this approach is that it may allow malware to detect that it is being executed in / manipulated by the guest OS 408 and cause it to refrain from exhibiting malicious behavior to evade detection.

[0086] An alternative approach (used by various embodiments of the security platform 122, malware analysis module 112, sample analysis system 300, etc.) does not rely on the guest OS to simulate user actions, but instead uses the hypervisor 406. Specifically, and as will be described in more detail below, frame buffer data stored by the graphics card is directly accessed by the hypervisor to generate screenshots of the virtualized system's desktop for analysis, and device drivers such as the mouse device driver are hooked so that the hypervisor can directly move the virtualized mouse as an end user would do, without making guest OS API calls. Since guest OS API calls are not used to simulate human activity, the malware sample (410) will not be able to detect that it is running in a virtualized environment and therefore will not hide its malicious behavior during analysis.

[0087] VI. Analyzing the malware samples

[0088] Typically, during static analysis, malware is detected by determining whether a sample's signature matches a pattern associated with known malware. However, some limitations of conventional static analysis for determining whether a sample is a malicious exploit include new exploit code that can be easily obfuscated. For example, a browser exploit can be obfuscated using JavaScript to avoid detection by static analysis.

[0089] Some limitations of conventional dynamic analysis of samples to determine whether a sample is malicious include that when sensitive API function calls are detected via hooking techniques, there may be only a small amount of sensitive API function calls, such as CreateProcess and URLDownloadToFile in the Windows operating system, which are useful in detecting malware. Typically, applications such as browsers, AdobeReader, Microsoft Office never call one of the small amount of sensitive API function calls, so samples that call a small amount of sensitive API function calls can be determined to be malicious. On the other hand, there are many other API function calls (e.g., LoadLibrary, CreateThread, etc.) that are also legally used by the application itself. In some scenarios, LoadLibrary is associated with malware, and in some scenarios, the application itself uses LoadLibrary for legal behavior. It is not easy to determine which API function calls correspond to legal behavior and which API function calls correspond to malicious behavior, so conventional dynamic analysis is limited in its effectiveness.

[0090] In this application, before executing the shell code, the vulnerability exploit uses a memory attribute change function to mark the memory including the shell code as read|write|execute (RWE) to bypass DEP mitigation. Examples of memory attribute change functions include: VirtualAlloc and VirtualProtect in Windows operating systems. Other operating systems such as MacOS, Linux, etc. will have their own corresponding specific memory attribute change functions (e.g., mmap and mprotect).

[0091] Figure 5 An embodiment of a process for detecting a vulnerability exploit including shell code is illustrated. In some embodiments, process 500 uses Figure 4 The environment 400 is executed and includes:

[0092] At 510, the environment monitors memory blocks during dynamic analysis of a sample to identify memory blocks that include suspicious shellcode.

[0093] For PDF files, the environment may use Adobe Acrobat or Adobe Reader to identify suspicious shell code; for Word documents, Excel documents, and PowerPoint documents, the environment may use MS Office to identify suspicious shell code; and for HTML files or JavaScript files, the environment may use Chrome or another browser to identify suspicious shell code.

[0094] In some embodiments, the memory block is associated with a heap.

[0095] In a first technique, the environment may hook memory attribute changing functions, such as VirtualAlloc and VirtualProtect in Windows operating systems, and if the memory attribute changing function is called for a memory block, the environment may mark the memory block as a suspicious shellcode.

[0096] In some embodiments, after identifying the memory attribute change function, the environment determines whether the corresponding parameters for the memory attribute change function grant the memory block execute permission (RWE), and if the corresponding parameters do not grant the memory block execute permission (e.g., remove the execute permission or only grant write permission), the environment ignores the memory block.

[0097] In a second technique, the environment can perform an offline scanning process of the memory to determine whether the memory block has its memory attribute set to RWE. In the case where the memory block has its memory attribute set to RWE, the environment can mark the memory block as including suspicious shell code.

[0098] In the case of performing an offline scan of process memory, the environment analyzes the process memory via a memory dump (either after the sample is executed or at a different time during the execution), and the dumped process memory is parsed offline to identify memory with a memory attribute as RWE and then mark the memory as including suspicious shellcode. In other words, during the sample execution, the memory blocks associated with the marked memory are granted execution permissions.

[0099] At 520, the environment dumps memory blocks in memory to identify candidate shellcode entry points associated with the suspicious shellcode.

[0100] After identification comprises the memory block of suspicious shell code, environment can be input the memory block comprising suspicious shell code into shell code filter to identify candidate shell code entry point.Shell code filter comprises the list of regular expression.Regular expression can be relevant to shell code characteristic, described shell code characteristic such as for example data structure access (process environment block (PEB) access / thread environment block (TEB) access), GETPC technology (GETPC with "callreg, pop reg", it uses the combination of assembly instruction "call" and "pop" to put current instruction register (IP) address into the register of appointment, for further shell code self-decoding or decryption, and GETPC with "fnstenv", it uses floating point assembly instruction characteristic to push current instruction register (IP) address into stack, for further shell code self-decoding or decryption)), usually by shell code as the no operation (NOP) instruction of shell code entry point etc.

[0101] In some embodiments, the shell code entry point is identified based on a regular expression. For example, the shell code entry point starts from or near a PEB / TEB access instruction, a GETPC instruction, a function call instruction, a NOP instruction, etc.

[0102] As one aspect, in the case where the shell code is encrypted or encoded to evade static analysis, the encoded shell code will first call a GETPC instruction such as "call reg; pop reg" or "fnstenv" to obtain the current instruction register (IP) address for shell code decryption or decoding. As another aspect, the shell code includes a nop instruction at the beginning of the sample to smoothly transition to the malicious shell code after the nop instruction ends.

[0103] At 530, the environment executes the suspicious shellcode based on the candidate shellcode entry point to determine whether the suspicious shellcode is malicious.

[0104] In some embodiments, the environment executes suspicious shell code in the CPU emulator and obtains input binary and executes input binary in the full system emulator. In some embodiments, the environment executes suspicious shell code in the CPU emulator and executes suspicious shell code in the full system emulator. In some embodiments, the environment executes suspicious shell code only in the CPU emulator. In some embodiments, the CPU emulator is Unicorn or Qiling. In some embodiments, the environment identifies the assembly instruction level shell code mode (e.g., GETPC instruction, self-decoding, PEB / TEB access, etc.) to detect the shell code in the input suspicious shell code in the CPU simulator. Typically, the shell code has a fixed pattern, fixed characteristics and / or fixed behavior. By detecting the shell code, vulnerability exploits can be detected. In some embodiments, in order to obtain faster detection results (e.g., the lowest sample processing time), if the suspicious shell code is only executed in the CPU emulator, the environment can generate a judgment.

[0105] In some embodiments, the full-system emulator is QEMU, which can run an operating system to provide full-system emulation. In some embodiments, the environment executes suspicious shell code in a memory inside the operating system running in the full-system emulator, and simultaneously monitors API function calls called by the shell code to detect shell code from input suspicious shell code. In some embodiments, the environment determines that the suspicious shell code is malicious when a monitored API function call is detected during full-system emulation and / or when an assembly instruction-level shell code mode is triggered during CPU emulation.

[0106] In some embodiments, the two emulations complement each other because the CPU emulation is performed for efficiency and then, if necessary, the full system emulation is performed.

[0107] At 540, the environment generates a verdict about the sample based on the results of executing the suspicious shellcode.

[0108] In some embodiments, in the case where the suspicious shell code is determined to be malicious, the sample is determined to be a vulnerability exploit. In some embodiments, after the sample is determined to be malicious, the environment generates a signature for the malware sample.

[0109] In some embodiments, after a sample is determined to be malicious, the environment generates a signature for the malware sample and distributes the signature to the firewall.

[0110] Process 500 provides at least the following benefits: during dynamic analysis of a sample, suspicious shellcode is split from RWE memory and located using shellcode filters to identify candidate shellcode entry points; process 500 can identify vulnerability exploits using any API function call rather than just a small number of sensitive API function calls; process 500 can utilize CPU emulators and full-system emulators; process 500 has a very low false positive rate; process 500 can work with many applications (e.g., browsers, Office, Acrobat, etc.), many operating systems (e.g., Windows, MacOS, Linux, etc.), and many platforms (e.g., x86 / x64, ARM, ARM64, etc.); and process 500 can potentially identify zero-day vulnerability exploits.

[0111] In some embodiments, CPU simulation is performed before full system simulation because CPU simulation is faster and uses fewer resources than full system simulation, so process 500 can be performed faster and use fewer system resources if full system simulation is not needed.

[0112] Figure 6 An embodiment of a process for monitoring a memory block during dynamic analysis of a sample is illustrated. In some embodiments, process 600 is Figure 5 The implementation of operation 510 includes:

[0113] In 610 , the environment hooks a memory attribute change function associated with the memory block to determine whether the memory attribute change function has been called and whether corresponding parameters have been provided to the memory attribute change function.

[0114] At 620, having called the memory attribute change function and provided the corresponding parameters to the memory attribute change function, the environment determines that the memory block includes suspicious shellcode.

[0115] Figure 7 Another embodiment of a process for monitoring a memory block during dynamic analysis of a sample is illustrated. In some embodiments, process 700 is Figure 5 The implementation of operation 510 includes:

[0116] At 710, after allowing the process associated with the memory block to run, the environment performs an offline scan of the process memory to determine whether the memory block has a particular memory attribute.

[0117] At 720, in response to a determination that the block of memory has a particular memory attribute, the environment determines that the block of memory includes suspicious shellcode.

[0118] Figure 8An embodiment of a process for dumping a memory block in a memory is illustrated. In some embodiments, process 800 is Figure 5 The implementation of operation 520 includes:

[0119] At 810, the environment identifies a specific assembly code pattern or a specific data structure in a memory block that includes suspicious shellcode.

[0120] At 820 , the environment determines candidate shellcode entry points based on a specific assembly code pattern or a specific data structure.

[0121] Fig. 9 An embodiment of a process for executing suspicious shell code is illustrated. In some embodiments, process 900 is Figure 5 The implementation of operation 530 includes:

[0122] At 910, the environment executes the suspicious shellcode using the CPU emulator based on the candidate shellcode entry point.

[0123] In some embodiments, after executing the suspicious shell code using the CPU emulator, an input binary is obtained.

[0124] At 920, the environment executes the suspicious shellcode using a full system emulator based on the candidate shellcode entry point.

[0125] In some embodiments, an input binary obtained from a CPU emulator is executed using a full system emulator.

[0126] Fig.10 An embodiment of a process for executing suspicious shell code using a CPU emulator is illustrated. In some embodiments, process 1000 is Fig. 9 The implementation of operation 910 includes:

[0127] At 1010, the environment emulates execution of the suspicious shell code using a CPU emulator.

[0128] At 1020, the environment determines whether assembly instructions associated with the simulated execution of the suspicious shellcode match a predetermined shellcode pattern.

[0129] At 1030, the environment determines that the suspicious shellcode is malicious if the assembly instructions associated with the emulated execution of the suspicious shellcode match a predetermined shellcode pattern.

[0130] Fig.11 An embodiment of a process for executing suspicious shell code using a full system emulator is illustrated. In some embodiments, process 1100 is Fig. 9 The implementation of operation 920 includes:

[0131] At 1110, the environment executes the suspicious shellcode in memory inside the operating system running in the full system emulator based on the candidate shellcode entry point.

[0132] In 1120, the environment monitors hooked application programming interface (API) functions to determine whether the suspicious shell code calls the hooked API function. In some embodiments, the environment hooks one or more API functions during full system emulation.

[0133] In 1130, in response to a determination that the suspicious shell code calls the hooked API function, the environment determines that the suspicious shell code is malicious.

[0134] Fig.12 An example of a process for detecting a vulnerability exploit that includes shellcode is illustrated.

[0135] In the example, a sample (CVE-2015-5119 vulnerability exploit) is analyzed in a monitored environment, wherein a memory attribute change function is monitored during dynamic analysis of the sample to identify a memory block associated with the memory attribute change function. In this example, only one memory block including suspicious shell code is identified.

[0136] Memory blocks including suspicious shellcode are identified by hooking a memory attribute change function that is called with RWE as a parameter, or by performing an offline scan of the process memory after the sample has executed (or at a different point during execution) and analyzing the RWE memory attributes of the process memory to identify memory blocks including suspicious shellcode. After the memory blocks including suspicious shellcode are identified, the memory blocks are dumped.

[0137] Dumped memory blocks including suspicious shellcode are analyzed for a list of regular expressions (e.g., PEB / TEB access, GETPC technique, calling function, NOP, etc.) In the example, there are two matches ((1) calling function pattern, and (2) TEB access pattern), and one candidate entry point associated with each of the two matches is also identified.

[0138] Suspicious shellcode based on the candidate entry points associated with each of the two matches is then executed.

[0139] The identified suspicious shell code and the candidate entry points associated with the match are fed into the CPU emulator. The assembly instruction-level shell code pattern is identified from the simulated assembly instructions in the CPU emulator to detect the shell code in the suspicious shell code. In this example, TEB access, PEB access, and PEB Ldr access are identified. Subsequently, the input suspicious shell code can be executed in the memory in the operating system running the full-system emulator, where API function calls are monitored to detect the shell code in the input suspicious shell code. In the example, the API function calls: GetProcAddress (LdrGetProcedureAddress) and CreateThreadEx are identified. In this example, any monitored API function calls identified can be regarded as evidence that the input suspicious shell code is identified as malicious shell code. The output of each emulator is a judgment on whether the sample is a vulnerability exploit (malicious), and the judgment is determined based on the execution results from the CPU emulator and / or the full-system emulator.

[0140] Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways to implement the invention. The disclosed embodiments are illustrative and not restrictive.

Claims

1. A system comprising: The processor is configured as: monitoring memory blocks during dynamic analysis of the sample to identify memory blocks including suspicious shellcode; dumping memory blocks in memory to identify candidate shellcode entry points associated with the suspected shellcode; Based on the candidate shell code entry point, executing the suspicious shell code to determine whether the suspicious shell code is malicious; as well as Generating a judgment about the sample based on the results of executing the suspicious shell code; as well as The memory is coupled to the processor and configured to provide instructions to the processor.

2. The system according to claim 1, wherein: Monitoring memory blocks during dynamic analysis of a sample to identify memory blocks containing suspicious shellcode includes: hooking a memory attribute change function associated with the memory block to determine whether the memory attribute change function has been called and whether corresponding parameters have been provided to the memory attribute change function; and Responsive to a determination that a memory attribute change function has been called and corresponding parameters have been provided to the memory attribute change function, it is determined that the memory block includes suspicious shellcode.

3. The system according to claim 1, wherein: Monitoring memory blocks during dynamic analysis of a sample to identify memory blocks containing suspicious shellcode includes: performing an offline scan of process memory to determine whether a block of memory has a specific memory attribute; and Responsive to a determination that the memory block has a particular memory attribute, it is determined that the memory block includes suspicious shell code.

4. The system according to claim 1, wherein: Dumping memory blocks in memory to identify candidate shellcode entry points associated with suspicious shellcodes includes: identifying a specific assembly code pattern or a specific data structure in a memory block that includes suspected shellcode; and Candidate shellcode entry points are determined based on specific assembly code patterns or specific data structures.

5. The system according to claim 1, wherein: Suspicious shellcode execution includes: Based on the candidate shell code entry point, executing the suspected shell code using the CPU emulator; and Based on the candidate shellcode entry point, the suspected shellcode is executed using a full system emulator.

6. The system according to claim 5, wherein: Suspicious shellcode execution using CPU emulator includes: Use a CPU emulator to simulate the execution of suspicious shell code; determining whether assembly instructions associated with the simulated execution of the suspected shellcode match a predetermined shellcode pattern; and Responsive to a determination that assembly instructions associated with the simulated execution of the suspicious shellcode match a predetermined shellcode pattern, the suspicious shellcode is determined to be malicious.

7. The system according to claim 5, wherein: Execution of suspicious shellcode using a full system emulator includes: executing suspicious shellcode in memory inside an operating system running in a full-system emulator; monitoring hooked application programming interface (API) functions to determine whether the suspicious shell code calls the hooked API functions; and In response to a determination that the suspicious shell code calls the hooked API function, the suspicious shell code is determined to be malicious.

8. The system according to claim 1, wherein: The processor is further configured to: Responsive to a determination that the critique indicates the sample is malicious, a signature for the malware sample is generated.

9. The system according to claim 1, wherein: The processor is further configured to: In response to a determination that the assessment indicates the sample is malicious: generating signatures for malware samples; and Distribute the signature to the firewalls.

10. A method comprising: monitoring memory blocks during analysis of the sample to identify memory blocks including suspicious shellcode using a processor; dumping memory blocks in memory using a processor to identify candidate shellcode entry points associated with the suspected shellcode; executing the suspected shell code to determine whether the suspected shell code is malicious based on the candidate shell code entry point, using the processor; as well as Using a processor, a verdict is generated regarding the sample based on a result of executing the suspicious shellcode.

11. The method according to claim 10, wherein: Suspicious shell code execution includes: Based on the candidate shell code entry point, executing the suspected shell code using the CPU emulator; and Based on the candidate shellcode entry point, the suspected shellcode is executed using a full system emulator.

12. The method according to claim 11, wherein: Suspicious shellcode execution using CPU emulator includes: Use a CPU emulator to simulate the execution of suspicious shell code; determining whether assembly instructions associated with the simulated execution of the suspected shellcode match a predetermined shellcode pattern; and Responsive to a determination that assembly instructions associated with the simulated execution of the suspicious shellcode match a predetermined shellcode pattern, the suspicious shellcode is determined to be malicious.

13. The method according to claim 11, wherein: Execution of suspicious shellcode using a full system emulator includes: executing suspicious shellcode in memory inside an operating system running in a full-system emulator; monitoring hooked application programming interface (API) functions to determine whether the suspicious shell code calls the hooked API functions; and In response to a determination that the suspicious shell code calls the hooked API function, the suspicious shell code is determined to be malicious.

14. The method according to claim 10, further comprising: Responsive to a determination that the critique indicates the sample is malicious, a signature for the malware sample is generated.

15. The method according to claim 10, further comprising: In response to a determination that the assessment indicates the sample is malicious: Generate signatures for malware samples; as well as Distribute the signature to the firewalls.

16. A computer program product embodied in a non-transitory computer readable medium and comprising computer instructions for: monitoring memory blocks during analysis of the sample to identify memory blocks including suspicious shellcode; dumping memory blocks in memory to identify candidate shellcode entry points associated with the suspected shellcode; executing the suspicious shell code based on the candidate shell code entry point to determine whether the suspicious shell code is malicious; as well as A verdict about the sample is generated based on the results of executing the suspicious shell code.

Images