System and method for detecting exploits involving shellcode - Patents.com

Abstract

A method for detecting exploits involving shellcode is disclosed. Memory blocks are monitored during dynamic analysis of a sample to identify memory blocks containing suspect shellcode. The memory blocks are dumped into memory to identify candidate shellcode entry points associated with the suspect shellcode. Based on the candidate shellcode entry points, the suspect shellcode is executed to determine whether the suspect shellcode is malicious. A verdict is generated for the sample based on a result of executing the suspect shellcode.

Description

[Background technology]

[0001] Malware is a general term commonly used to refer to malicious software (e.g., including a variety of hostile, intrusive, and / or otherwise unwanted software). Malware can be in the form of code, scripts, active content, and / or other software. Examples of malware uses include disrupting computer and / or network operations, stealing confidential information (e.g., confidential information such as identity, financial, and / or intellectual property related information), and / or gaining access to private / private computer systems and / or computer networks. Malware can be in the form of code, scripts, active content, and / or other software. As technologies are developed to aid in the detection and mitigation of malware, nefarious authors find ways to circumvent such efforts. Thus, there is a continuing need for improvements to techniques for identifying and mitigating malware. [Brief description of the drawings]

[0002] Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings. [Figure 1] FIG. 1 illustrates an example of an environment in which malicious applications are detected and prevented from causing harm. [Figure 2A] FIG. 2A shows an example of a data appliance. [Figure 2B] FIG. 2B is a functional diagram of the logical components of one embodiment of a data appliance. [Diagram 3] FIG. 3 illustrates one example of logical components that may be included in a system for analyzing a sample. [Figure 4]FIG. 4 illustrates one embodiment of an environment for analyzing malware samples. [Diagram 5] FIG. 5 illustrates one embodiment of a process for detecting exploits that involve shellcode. [Figure 6] FIG. 6 illustrates one embodiment of a process for monitoring memory blocks during dynamic analysis of a sample. [Figure 7] FIG. 7 illustrates another embodiment of a process for monitoring memory blocks during dynamic analysis of a sample. [Figure 8] FIG. 8 illustrates one embodiment of a process for dumping a memory block in a memory. [Figure 9] FIG. 9 illustrates one embodiment of a process for executing suspect shellcode. [Figure 10] FIG. 10 illustrates one embodiment of a process for executing suspect shellcode using a CPU emulator. [Figure 11] FIG. 11 illustrates one embodiment of a process for executing suspect shellcode using a full system emulator. [Figure 12] FIG. 12 illustrates one embodiment of a process for detecting exploits involving shellcode. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0003] The present invention can be implemented in numerous 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 instructions stored on a memory, and / or a processor configured to execute instructions stored and / or provided by a memory coupled to the processor. These implementations, or any other form the present invention may take, may be referred to herein as techniques. In general, the order of steps of a disclosed process may be modified within the scope of the present invention. Unless otherwise specified, components such as a processor or memory described as configured to perform a task may be implemented as general-purpose components temporarily configured to perform the task at a given time, or as specific components manufactured to perform 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.

[0004] A detailed description of one or more embodiments of the present invention is provided below along with accompanying drawings that illustrate the principles of the invention. While the present invention will be described in connection with such embodiments, 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 encompasses numerous alternatives, modifications, and equivalents. Numerous specific details are set forth in the following description to provide a thorough understanding of the present invention. These details are provided for the purpose of example, and the present invention may be practiced according to the claims without some or all of these specific details. For the sake of clarity, technical material known in the art related to the present invention has not been described in detail so as not to unnecessarily obscure the present invention.

[0005] Typically, exploits use memory attribute modification functions to bypass operating system mitigation and execute malicious shellcode (fragments of binary data) on the victim's computer. Existing exploit detection techniques work only in certain scenarios, each with its own limitations. Before executing the malicious shellcode, the shellcode is placed into the target process memory as legal data. For example, in a browser exploit, an attacker uses JavaScript to build an exploit, and the shellcode is written into the browser process by the browser's JavaScript engine as a typical JavaScript object (e.g., a string or an array) and stored in the legal heap, where it exists as data (it does not exist as code and cannot be executed). The exploit then triggers the vulnerability and takes control of the instruction pointer register (IP register). In modern operating systems (e.g., Windows, MacOS, Linux, etc.), Data Execution Prevention (DEP) prevents shellcode from executing in memory by marking memory as non-executable. However, exploits can bypass DEP and allow shellcode to execute.

[0006] Typically, exploits bypass DEP by calling memory attribute modification functions. The exploit uses return-oriented programming (ROP) gadgets to build ROP chains, calling memory attribute modification functions (e.g., VirtualAlloc and VirtualProtect in Windows, and mmap and mprotect in MacOS and Linux) to mark the memory containing the shellcode as read|write|execute (RWE), and then execute the shellcode. Typically, exploits have the same privilege as a vulnerable application or vulnerable software process, such as a browser renderer process.

[0007] In some embodiments, a system / method / computer program product for detecting exploits involving shellcode includes monitoring memory blocks during dynamic analysis of a sample, identifying memory blocks containing suspect shellcode, dumping the memory blocks to memory, identifying candidate shellcode entry points associated with the suspect shellcode, executing the suspect shellcode based on the candidate shellcode entry points, determining whether the suspect shellcode is malicious, and generating a verdict for the sample based on a result of executing the suspect shellcode.

[0008] In some embodiments, monitoring memory blocks during dynamic analysis of the sample to identify memory blocks containing suspect shellcode includes hooking a memory attribute modification function associated with a memory block to determine whether the memory attribute modification function has been invoked and whether corresponding parameters have been provided to the memory attribute modification function, and in response to determining that the memory attribute modification function has been invoked and the corresponding parameters have been provided to the memory attribute modification function, determining that the memory block contains suspect shellcode.

[0009] In some embodiments, monitoring memory blocks during dynamic analysis of the sample to identify memory blocks containing suspect shellcode includes performing an offline scan of process memory to determine whether the memory blocks have particular memory attributes, and in response to determining that the memory blocks have the particular memory attributes, determining that the memory blocks contain the suspect shellcode.

[0010] In some embodiments, dumping the memory block to memory and identifying candidate shellcode entry points associated with the suspect shellcode includes identifying a specific assembly code pattern or a specific data structure in the memory block containing the suspect shellcode, and determining the candidate shellcode entry points based on the specific assembly code pattern or the specific data structure.

[0011] In some embodiments, executing the suspect shellcode includes executing the suspect shellcode using a CPU emulator based on the candidate shellcode entry points, and executing the suspect shellcode using a full-system emulator based on the candidate shellcode entry points.

[0012] In some embodiments, executing the suspect shellcode using the CPU emulator includes emulating execution of the suspect shellcode using the CPU emulator, determining whether assembly instructions associated with the emulated execution of the suspect shellcode match a predefined shellcode pattern, and determining that the suspect shellcode is malicious in response to a determination that assembly instructions associated with the emulated execution of the suspect shellcode match a predefined shellcode pattern.

[0013] In some embodiments, executing the suspect shellcode using the full-system emulator includes executing the suspect shellcode in the memory in an operating system executing in the full-system emulator, monitoring hooked application programming interface (API) functions to determine whether the suspect shellcode calls a hooked API function, and in response to determining that the suspect shellcode calls the hooked API function, determining that the suspect shellcode is malicious.

[0014] In some embodiments, the system / method / computer program product further includes generating a signature for the sample of malware in response to determining that the determination indicates that the sample is malicious.

[0015] In some embodiments, the system / method / computer program product further includes, in response to determining that the determination indicates that the sample is malicious, generating a signature for the sample of malware and delivering the signature to a firewall.

[0016] I. Overview

[0017] A firewall generally allows authorized communications to pass through the firewall while protecting the network from unauthorized access. A firewall is typically a device, a set of devices, or software running 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 smartphone, or other type of network-enabled device). Firewalls can also be integrated or run as software applications on various types of devices or security devices, such as computer servers, gateways, network / routing devices (e.g., network routers), or data appliances (e.g., security appliances, or other types of special purpose devices), and in some implementations, certain operations can be implemented in special purpose hardware, such as ASICs or FPGAs. do.

[0018] A firewall typically denies or allows network transmissions based on a set of rules. These sets of rules 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 a protected device. A firewall can also filter outbound traffic by applying a set of rules or policies (e.g., allow, block, monitor, notify, or log, and / or other actions that may be specified in a firewall rule or firewall policy, which may be triggered based on various criteria, as described herein). A firewall can also filter local network (e.g., intranet) traffic by applying a set of rules or policies as well.

[0019] Security devices (e.g., security appliances, security gateways, security services, and / or other security devices) may perform various security operations (e.g., firewalls, anti-malware, intrusion prevention / detection, proxies, and / or other security functions), network functions (e.g., routing, quality of service (QoS), workload balancing of network-related resources, and / or other network functions), and / or other security and / or network-related functions. For example, routing may be performed based on source information (e.g., IP addresses and ports), destination information (e.g., IP addresses and ports), and protocol information.

[0020] Basic packet filtering firewalls filter network communication traffic by inspecting each individual packet sent across a network (e.g., a packet filtering firewall or first generation firewall, which is a stateless packet filtering firewall). Stateless packet filtering firewalls typically inspect the individual packets themselves and then 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).

[0021] Application firewalls can also perform application layer filtering (e.g., using an application layer filtering firewall, or a second generation firewall that functions 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 the Hypertext Transfer Protocol (HTTP), Domain Name System (DNS) requests, file transfers using the 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 on standard ports (e.g., unauthorized / out-of-policy protocols that attempt to sneak through by using a non-standard port for that protocol can generally be identified using an application firewall).

[0022] Stateful firewalls can also perform stateful-based packet inspection, where each packet is inspected in the context of the set of packets associated with its network outgoing packet flow. This firewall technique is commonly referred to as stateful packet inspection, because it keeps a record of all connections that pass through the firewall and can determine whether a packet is the start of a new connection, part of an existing connection, or an invalid packet. For example, the state of a connection can itself be one of the criteria that triggers a rule in a policy.

[0023] Advanced or next-generation firewalls can perform stateless and stateful packet filtering and application layer filtering, as described above. Next-generation firewalls can also perform additional firewall technologies. For example, certain new firewalls, often referred to as advanced or next-generation firewalls, can also identify users and content. In particular, certain next-generation firewalls have expanded the list of applications that they can automatically identify to thousands of applications. Examples of such next-generation firewalls are commercially available from Palo Alto Networks (e.g., Palo Alto Networks PA series firewalls). For example, Palo Alto Networks next-generation firewalls use a variety of identification technologies to enable enterprises and service providers to identify and control applications, users, and content - not just ports, IP addresses, and packets. Various identification techniques are Application-ID (App-ID) for precise application identification, User-ID (User-ID) for user identification (e.g., User ID), Content-ID (Content-ID) for real-time content scanning (e.g., to control web surfing and limit data and file transfer), and Device-ID (e.g., for identifying IoT device types). These identification techniques allow enterprises to safely enable application usage using business-relevant concepts instead of following the traditional approach provided by traditional port-blocking firewalls.Additionally, special-purpose hardware for next-generation firewalls (e.g., implemented as dedicated devices) generally provides higher performance levels for application inspection than software running on general-purpose hardware (e.g., security appliances from Palo Alto Networks, Inc., which utilize dedicated, function-specific processing that is tightly integrated with a single-pass software engine to maximize network throughput while minimizing latency, for Palo Alto Networks' PA Series Next-Generation Firewalls).

[0024] Advanced or next-generation firewalls can also be implemented using virtualized firewalls. An example of such a next-generation firewall is available from Palo Alto Networks (which runs on VMware® ESXi). TM and NSX TM , Citrix(R)Netscaler SDX TM It supports a variety of commercial virtualization environments, including Kubernetes, KVM / OpenStack (Centos / RHEL, Ubuntu®), and Amazon Web Services (AWS). For example, the virtualized firewall can support similar or identical next-generation firewall and advanced threat prevention capabilities available in physical form factor devices, allowing enterprises to safely enable the influx of applications to private, public, and hybrid cloud computing environments. Automation capabilities such as VM monitoring, dynamic address groups, and REST-based APIs enable enterprises to dynamically monitor VM changes and update security policies with that context, thereby eliminating policy lag that can occur when VMs change.

[0025] II. Example Environment

[0026] FIG. 1 illustrates one example of an environment in which malicious applications (“malware”) are detected and prevented from causing harm. As described in more detail below, malware classifications may be shared and / or refined in various ways among various entities included in the environment illustrated in FIG. 1 (e.g., as performed by security platform 122). Using techniques described herein, devices, such as endpoint client devices 104-110, may then be protected from such malware.

[0027] The term "application" is used throughout this specification to collectively refer to programs, program bundles, manifests, packages, etc., regardless of format / platform. An "application" (also referred to herein as a "sample") may be a standalone file (e.g., a calculator application having the file name "calculator.apk" or "calculator.exe") and may also be a separate component of another application (e.g., a mobile advertising SDK or library embedded within a calculator application).

[0028] "Malware" as used herein refers to applications that engage in behaviors, covert or not (and illegal or not), that a user would not / would not approve of if fully informed, including but not limited to Trojan horses, viruses, rootkits, spyware, hacking tools, keyloggers, etc. One example of malware is a desktop application that collects and reports the end user's location to a remote server (but does not provide the user with location-based services, such as mapping services). Another example of malware is a malicious Android application package .apk (APK) file that appears to be a free game to the end user, but stealthily sends SMS premium messages (e.g., costing $10 each), increasing the end user's phone bill. Another example of malware is the Apple iOS flashlight application that stealthily collects a user's contacts and sends them to spammers. Other forms of malware can also be detected / thwarted using the techniques described herein (e.g., ransomware).

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

[0030] Data appliance 102 is configured to enforce 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 those governing traffic shaping, quality of service, and traffic routing. Other examples of policies include security policies, such as those requiring scanning for threats in incoming (and / or outgoing) email attachments, website content, files exchanged via instant messaging programs, and / or other file transfers. In some embodiments, data appliance 102 is also configured to enforce policies with respect to traffic remaining within enterprise network 140.

[0031] One embodiment of a data appliance is shown in FIG. 2A. The illustrated example 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 storage 210 (such as one or more hard disks or solid-state units). In various embodiments, the data appliance 102 stores (either in the RAM 204, the storage 210, and / or other suitable locations) information used to monitor the enterprise network 110 and to implement the disclosed techniques. Examples of such information include application identifiers, content identifiers, user identifiers, requested URLs, IP address mappings, policies and other configuration information, signatures, hostname / URL categorization information, malware profiles, machine learning models, IoT device classification information, and the like. 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 208 configured to perform matching, operate as a network processor, and / or perform other tasks.

[0032] The functionality described herein as being 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 or executed as software on a general purpose computer, computer server, gateway, and / or network / routing device. In some embodiments, at least some of the services described as being provided by data appliance 102 are instead (or in addition) provided to a client device (e.g., client device 104 or client device 110) by software executing at the client device.

[0033] Whenever the data appliance 102 is described as performing a task, a single component, a subset of the components, or all of the components of the data appliance 102 may cooperate to perform the task. Similarly, whenever a component of the data appliance 102 is described as performing a task, the subcomponent may perform the task and / or the component may perform the task 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 adapted accordingly. Similarly, additional logical components / features may be included in embodiments of the data appliance 102, as applicable. One example of a component included in the data appliance 102 in various embodiments is an application identification engine configured to identify applications (e.g., using various application signatures to identify applications based on packet flow analysis). For example, the application identification engine may determine the type of traffic the session involves, such as web browsing-social networking, web browsing-news, SSH, etc.

[0034] 2B is a functional diagram of logical components according to one embodiment of a data appliance. The example shown is a representation of logical components that may be included in data appliance 102 in various embodiments. Unless otherwise specified, the various logical components of data appliance 102 may generally be implemented in a variety of ways, including as a set of one or more scripts (e.g., written in Java, python, etc., where applicable).

[0035] As shown, 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 interaction, such as by providing a user interface for setting policies and displaying log data. The data plane is responsible for data management, such as by performing packet and session processing.

[0036] The network processor 236 is configured to receive packets from a client device, such as the client device 108, and provide them to the data plane 234 for processing. The flow module 238 creates a new session flow whenever it identifies a packet as part of a new session. Subsequent packets are identified as belonging to the session based on the flow lookup. If applicable, SSL decryption is applied by the SSL decryption engine 240. Otherwise, processing by the SSL decryption engine 240 is omitted. The decryption engine 240 helps the data appliance 102 inspect and control SSL / TLS and SSH encrypted traffic, and thus helps 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 a decryption policy (e.g., one that specifies which sessions to decrypt), a decryption profile can be assigned to control various options of the session controlled by the policy, for example, the use of a particular cipher suite and encryption protocol version can be required.

[0037] The application identification (APP-ID) engine 242 is configured to determine the type of traffic the session involves. As an example, the application identification engine 242 may recognize a GET request in the received data and conclude that the session requires an HTTP decoder. In some cases, such as during a web browsing session, the identified application may change and such changes may be noted by the data appliance 102. For example, a user may first browse a corporate Wiki (classified as “Web Browsing-Productivity” based on the visited URLs) and then browse a social networking site (classified as “Web Browsing-Social Networking” based on the visited URLs). Different types of protocols have corresponding decoders 244.

[0038] Based on the determination made by the application identification engine 242, the packets are sent by the threat engine 244 to the appropriate decoder 244, 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 packets. If necessary, the SSL encryption engine 246 can re-encrypt the decrypted data. The packets are forwarded using a forwarding module 248 for forwarding (e.g., to a destination).

[0039] 2B, a policy 252 is also received and stored in the management plane 232. The policy 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, to subscriber / IP flows based on various extracted parameters / information from the 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).

[0040] III. Security Platform

[0041] Returning to Figure 1, assume that a malicious individual (using system 120) has created malware 130. The malicious individual wants a client device, such as client device 104, to run a copy of malware 130, compromising the client device and causing the client device to become a bot in a botnet. The compromised client device can then be instructed to perform a task (e.g., cryptocurrency mining or participating in a denial of service attack) and to report information to an external entity, such as command and control (C&C) server 150, as well as receive instructions from C&C server 150, if applicable.

[0042] Assume that the data appliance 102 intercepts an email sent (e.g., by the system 120) to a user “Alice,” operating a client device 104. A copy of malware 130 is attached to the message by the system 120. In an alternative, but similar scenario, the data appliance 102 may intercept an attempted download of malware 130 (e.g., from a website) by the client device 104. In either scenario, the data appliance 102 determines whether a signature of the file (e.g., the email attachment or website download of malware 130) is present on the data appliance 102. If present, the signature can indicate that the file is known to be safe (e.g., whitelisted) and can also indicate that the file is known to be malicious (e.g., blacklisted).

[0043] In various embodiments, the data appliance 102 is configured to operate in cooperation with the security platform 122. As one example, the security platform 122 can provide the data appliance 102 with a set of signatures of known malicious files (e.g., as part of a subscription). If a signature for the malware 130 is included in the set (e.g., an MD5 hash of the malware 130), the data appliance 102 can accordingly prevent transmission of the malware 130 to the client device 104 (e.g., by detecting that an MD5 hash of an email attachment sent to the client device 104 matches the MD5 hash of the malware 130). The security platform 122 can also provide the data appliance 102 with a list of known malicious domains and / or IP addresses, enabling the data appliance 102 to block traffic between the enterprise network 140 and the C&C server 150 (e.g., if the C&C server 150 is known to be malicious). The list of malicious domains (and / or IP addresses) can 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 the C&C server 150, such an attempt is a strong indicator that the client 104 has been compromised by malware (and corrective action should be taken accordingly, such as quarantining the client device 104 from communicating with other nodes in the enterprise network 140).

[0044] In various embodiments, various actions may be taken by the data appliance 102 if an attachment signature is not found. As a first example, the data appliance 102 may be 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). A drawback of this approach is that many legitimate attachments may be unnecessarily blocked as potential malware when they are in fact benign. As a second example, the data appliance 102 may be 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). A drawback of this approach is that newly created malware (not previously seen by the platform 122) is not prevented from causing harm.

[0045] As a third example, the data appliance 102 is 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 classify it if not. Various actions can be taken by the data appliance 102 while the analysis by the security platform 122 of the attachment (for which a signature does not yet exist) is being performed. As a first example, the data appliance 102 can prevent the email (and the attachment) from being delivered to Alice until a response is received from the security platform 122. Assuming that it takes approximately 15 minutes for the platform 122 to fully analyze the sample, this means that the incoming message to Alice will be delayed by 15 minutes. In this example, since the attachment is malicious, such a delay will not negatively impact Alice. In an alternative example, assume that someone sends Alice a time-sensitive message with a benign attachment for which no signature exists. Delaying the delivery of the message to Alice by 15 minutes is likely deemed unacceptable (e.g., by Alice). An alternative approach is to perform at least some real-time analysis on the attachment on the data appliance 102 (e.g., while waiting for a verdict from platform 122). The data appliance 102 can take initial action if it can independently determine whether the attachment is malicious or benign (e.g., block or allow delivery to Alice) and, if applicable, adjust / take additional action once a verdict is received from security platform 122.

[0046] Security platform 122 stores a copy of the received sample in storage device 142 and analysis is initiated (or scheduled, if applicable). One example of storage 142 is an Apache Hadoop cluster (HDFS). The results of the analysis (and additional information about the application) are stored in database 146. If the application is determined to be malicious, the data appliance may be configured to automatically block file downloads based on the analysis results. Additionally, signatures for the malware may be generated 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.

[0047] In various embodiments, security platform 122 comprises one or more dedicated, off-the-shelf hardware servers (e.g., having multi-core processors, 32G+ RAM, gigabit network interface adapters, and hard drives) running a typical server-class operating system (e.g., Linux). Security platform 122 may be implemented across a scalable infrastructure including multiple such servers, solid-state drives, and / or other applicable high performance hardware. Security platform 122 may comprise several distributed components, including components provided by one or more third parties. For example, some or all of security platform 122 may be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3). Additionally, similar to data appliance 102, whenever security platform 122 is referred to as performing a task, such as storing data or processing data, it should be understood that a subcomponent or subcomponents of security platform 122 may cooperate (individually or in cooperation with third party components) to perform that task. As one example, in various embodiments, security platform 122 cooperates with one or more virtual machine (VM) servers, such as VM server 124, to perform static and dynamic analysis.

[0048] One example of a virtual machine server is a physical machine that includes commercially available server-class hardware (e.g., multi-core processor, 32+ gigabytes of RAM, and one or more gigabit network interface adapters) running open source and / or commercially available virtualization software, such as Linux Kernel based Virtual Machine (KVM), VMware ESXi, Citrix XenServer, and Microsoft Hyper-V. Custom virtualization software can also be used and / or the functionality of the commercially available virtualization software can be extended as needed (e.g., as provided by a hypervisor) to support various functions described herein. Furthermore, the virtual machine server may be under the control of the same entity that manages the security platform 122, but may also be provided by a third party. As one example, the virtual machine server may rely on EC2, and the remainder 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 for emulating client devices. The virtual machines may run various operating systems and / or versions thereof. Observed behavior resulting from running an application within a virtual machine is logged and analyzed (e.g., for indications that the application is malicious). In some embodiments, the log analysis is performed by a VM server (e.g., VM server 124). In other embodiments, the analysis is performed, at least in part, by other components of security platform 122, such as coordinator 144.

[0049] In various embodiments, the security platform 122 makes the results of the analysis of the samples available to the data appliance 102 as part of the subscription via a list of signatures (and / or other identifiers). For example, the security platform 122 can periodically (e.g., daily, hourly, or some other interval and / or based on events configured by one or more policies) send a content package identifying malware apps. One exemplary content package includes a list of identified malware apps with information such as the package name, a hash value to uniquely identify the app, and a malware name (and / or malware family name) for each identified malware app. The subscription can cover analysis of only those files intercepted by the data appliance 102 and sent by the data appliance 102 to the security platform 122, and can also cover signatures of 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)).

[0050] In various embodiments, security platform 122 is configured to provide security services to various entities in addition to (or instead of, if applicable) the operator of data appliance 102. For example, other enterprises with their respective enterprise networks 114 and 116 and their 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) providing 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, the owner of client device 110 may install software on client device 110 that communicates with security platform 122 (e.g., to receive content packages from security platform 122, use the received content packages to check attachments according to the techniques described herein, and then send applications to security platform 122 for analysis).

[0051] IV. Analyzing Samples Using Static and Dynamic Analysis

[0052] 3 illustrates one example of logical components that may be included in a system for analyzing a sample. Analysis system 300 may be implemented using a single device. For example, the functionality of analysis system 300 may be implemented in malware analysis module 112 embedded in data appliance 102. Analysis system 300 may also be implemented collectively across multiple separate devices. For example, the functionality of analysis system 300 may be provided by security platform 122 or as a separate device disposed in network 140 and in communication with data appliance 102 (including various applicable components described herein as provided by security platform 122, e.g., virtual machine server 124).

[0053] In various embodiments, analysis system 300 utilizes a list, database, or other collection of known good content and / or known bad content (collectively shown in FIG. 3 as collection 314). Collection 314 may be obtained in various 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 include: URLs, domain names, and / or IP addresses of known malicious servers; URLs, domain names, and / or IP addresses of known safe 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 good applications; signatures, hashes, and / or other identifiers of known malicious files (e.g., Android exploit files); signatures, hashes, and / or other identifiers of known good libraries; and signatures, hashes, and / or other identifiers of known malicious libraries.

[0054] A. Ingestion

[0055] In various embodiments, when a new sample is received for analysis (e.g., there is no existing signature associated with the sample in the analysis system 300), it is added to the queue 302. As shown in FIG. 3, an application 130 is received by the system 300 and added to the queue 302.

[0056] B.Static Analysis

[0057] The coordinator 304 monitors the queue 302, and when resources (e.g., static analysis workers) become available, the coordinator 304 fetches samples from the queue 302 for processing (e.g., fetches copies of malware 130). In particular, the coordinator first provides (305) the samples to a static analysis engine 306 for static analysis. In some embodiments, one or more static analysis engines are included within 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).

[0058] The static analysis engine obtains general information about the sample and includes it (along with heuristic and other information, if applicable) in a static analysis report 308. The report may be generated by the static analysis engine or by the coordinator 304 (or by another suitable component), which may be configured to receive information from the static analysis engine 306. In some embodiments, the collected information is stored in the database record of the sample (e.g., in the database 316) instead of or in addition to a separate static analysis report 308 being generated (i.e., portions of the database record form the report 308). In some embodiments, the static analysis engine also forms a verdict about the application (e.g., “safe”, “suspicious”, or “malicious”). As one example, the verdict may be “malicious” if any “malicious” static features are present in the application (e.g., the application contains hard links to known malicious domains). As another example, points may be assigned to each of the features (e.g., based on severity, if any, based on how reliable the features are for predicting malicious intent, etc.) and a verdict may be assigned by the static analysis engine 306 (or the coordinator 304, if applicable) based on the number of points associated with the static analysis result.

[0059] C.Dynamic Analysis

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

[0061] Each dynamic analysis worker manages a virtual machine instance. In some embodiments, the results of the static analysis (e.g., performed by static analysis engine 306), whether in report form (308) and / or stored in database 316 or otherwise, are provided as input to dynamic analysis engine 310. For example, static analysis report information can be used to help select / customize / configure the virtual machine instance used by dynamic analysis engine 310 (e.g., Microsoft Windows 7 SP2 vs. Microsoft Windows 10 Enterprise, or iOS 11.0 vs. iOS 12.0). When multiple virtual machine instances run simultaneously, a single dynamic analysis engine can manage all of the instances, or multiple dynamic analysis engines can be used, if applicable (e.g., each managing its own virtual machine instance). During the dynamic portion of the analysis, actions taken by the application (including network activity) are analyzed, as described in more detail below.

[0062] In various embodiments, static analysis of the sample, if applicable, is omitted or performed by a separate entity. As one example, traditional static and / or dynamic analysis may be performed on the file by a first entity. Once a given file is determined (e.g., by a first entity) to be malicious, the file may be provided to a second entity (e.g., an operator of security platform 122) for additional analysis (e.g., by dynamic analysis engine 310), particularly with respect to malware use in network activity.

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

[0064] Similar to the static analysis engine, the dynamic analysis engine stores the results of its analysis in a database 316 in a record associated with the application being tested (and / or includes the results in a report 312, if applicable). In some embodiments, the dynamic analysis engine also forms a verdict (e.g., “safe”, “suspicious”, or “malicious”) regarding the application. As one example, the verdict may be “malicious” even if a single “malicious” action was taken by the application (e.g., an attempt was made to contact a known malicious domain, or an attempt to exfiltrate sensitive information was observed). As another example, points may be assigned for the actions taken (e.g., based on severity, if any, based on how reliable the action is to predict maliciousness, etc.). A verdict may then be assigned by the dynamic analysis engine 310 (or by the coordinator 304, if applicable) based on the number of points associated with the dynamic analysis results. In some embodiments, the final verdict associated with the sample is made (e.g., by the coordinator 304) based on a combination of the reports 308 and 312.

[0065] V. Simulation of User Interactions for Malware Analysis

[0066] Malware authors are using increasingly sophisticated techniques when crafting their malware to avoid detection by security analysis systems. One such technique is to have the malware attempt to determine whether it is running in a virtual machine environment, and if so, refrain from executing or otherwise engaging in malicious activity. By doing so, the security analysis system may erroneously conclude that the malware sample is benign because it is not observed by the security analysis system to engage in malicious behavior during dynamic analysis. As described in more detail below, in various embodiments, the platform 122 and / or the data appliance 102, or one or more other components as applicable, utilize techniques to help thwart detection by malware samples running in a virtualized environment, if applicable. By preventing a malware sample from determining that it is running in a virtualized environment, the malware sample is more likely to engage in malicious behavior while running in a virtualized environment, thereby increasing the likelihood of successfully detecting the sample as malicious.

[0067] One way that malware can determine if it is running in a virtual machine environment is by looking for indicia that it is being manipulated / executed by a guest operating system. As an example, in a typical virtualization environment, a sample to be tested (e.g., sample 130) may 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") is automatically executed by the guest operating system at startup and either launches the sample directly (e.g., by a dynamic analysis helper tool) or causes the sample to be launched. Because the malware sample and the dynamic analysis helper script / tool ​​are all collocated within the user space of the guest OS, the presence of the dynamic analysis script / tool ​​on the guest OS is visible to the malware, as is the information that the malware was started by a script (or tool) and / or that the malware was renamed. Additionally, the dynamic analysis helper tool may utilize OS API calls (e.g., to instruct the operating system to take various actions, such as keyboard input). The dynamic analysis helper tool's use of those API calls may be observed by malware. If a running sample determines that it is running in a virtualized environment, it may refrain from engaging in malicious actions and avoid being flagged as malicious by the dynamic analysis system.

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

[0069] 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 knows when such OS API calls are used and can therefore detect such interactions being generated automatically by the dynamic analysis system instead of being performed by a human end user. Thus, malicious documents may require more complex symptoms of human usage that are not amenable to scripting (e.g., scrolling down four pages using the mouse, performing a certain number of mouse clicks, etc.) before exhibiting malicious behavior.

[0070] A. Exemplary Environment

[0071] Figure 4 illustrates one embodiment of an environment for analyzing malware samples. Environment 400 is an example of one of the components that may be included in system 300 (e.g., as dynamic analysis engine 310). In the example illustrated in Figure 4, 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) of the appropriate type for the sample to be analyzed (e.g., 64-bit Windows 7 SP2 or MacOS X) and, if applicable, various pre-installed applications (e.g., Microsoft Office, Adobe Acrobat, Mozilla Firefox, Safari, etc.).

[0072] As mentioned above, when performing dynamic analysis in a virtualized environment, one approach is to launch the sample 410 via a script or tool running within the guest OS 408. For example, a helper tool installed in the guest OS 408 can rely on Windows APIs to detect message boxes and new items on the desktop, perform keyboard presses and moves, etc. However, as mentioned above, one drawback of this approach is that it allows malware to detect that it is running / operating in the guest OS 408, and causes the malware to refrain from exhibiting malicious behavior to avoid detection.

[0073] 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. In particular, and as described in more detail below, framebuffer 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 without making guest OS API calls, as an end user would. Because guest OS API calls are not used to simulate human activity, the malware sample (410) cannot detect that it is running in a virtualized environment, and therefore does not hide its malicious behavior during analysis.

[0074] VI. Analysis of Malware Samples

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

[0076] Some of the limitations of traditional dynamic analysis of samples to determine whether a sample is malicious include that when detecting sensitive API function calls via hooking techniques, there may be only a small number of sensitive API function calls, such as CreateProcess and URLDownloadToFile in Windows operating systems, that are useful in detecting malware. Typically, applications such as browsers, Adobe Reader, Microsoft Office, never call one of the small number of sensitive API function calls, so a sample that calls the small number of sensitive API function calls may be determined to be malicious. Meanwhile, there are many other API function calls (e.g., LoadLibrary, CreateThread, etc.) that are also used legitimately by the application itself. In some scenarios, LoadLibrary is associated with malware, and in some scenarios, LoadLibrary is used by the application itself for legitimate behavior. Determining which API function calls correspond to legitimate behavior and which API function calls correspond to malicious behavior is not easily determined, and thus traditional dynamic analysis is limited in its effectiveness.

[0077] In this application, before executing the shellcode, the exploit marks the memory containing the shellcode as read|write|execute (RWE) using memory attribute modification functions to bypass DEP mitigation. Examples of memory attribute modification functions include VirtualAlloc and VirtualProtect in Windows operating systems. Other operating systems, such as MacOS, Linux, etc., have their own corresponding specific memory attribute modification functions (e.g., mmap and mprotect).

[0078] Figure 5 illustrates one embodiment of a process for detecting exploits involving shellcode. In some embodiments, process 500 is performed using environment 400 of Figure 4 and includes the following:

[0079] At 510, the environment monitors memory blocks during dynamic analysis of the sample to identify memory blocks containing suspect shellcode.

[0080] For PDF files, the environment can use Adobe Acrobat or Adobe Reader to identify suspicious shellcode, for Word, Excel, and PowerPoint documents, the environment can use MS Office to identify suspicious shellcode, and for HTML or JavaScript files, the environment can use Chrome or another browser to identify suspicious shellcode.

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

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

[0083] In some embodiments, after a memory attribute change function is identified, the environment determines whether a corresponding parameter for the memory attribute change function grants execute permission (RWE) to the memory block, and if the corresponding parameter does not grant execute permission to the memory block (e.g., removes execute permission or grants only write permission), the environment ignores the memory block.

[0084] In a second technique, the environment can perform an offline scanning process of memory to determine whether a memory block has its memory attribute set to RWE. If the memory block has its memory attribute set to RWE, the environment can flag the memory block as containing suspected shellcode.

[0085] When an offline scan of process memory is performed, the environment analyzes the process memory via a memory dump (either after the sample is executed or at a different time during execution) and the dumped process memory is analyzed offline to identify memory that has memory attributes as RWE and then marks that memory as containing suspect shellcode. In other words, the memory blocks associated with the marked memory were allowed to execute during the execution of the sample.

[0086] At 520, the environment dumps memory blocks in memory and identifies candidate shellcode entry points associated with the suspect shellcode.

[0087] After identifying memory blocks containing suspect shellcode, the environment can input the memory blocks containing suspect shellcode into a shellcode filter to identify candidate shellcode entry points. The shellcode filter includes a list of regular expressions. The regular expressions can be related to shellcode characteristics such as data structure access (Process Environment Block (PEB) access / Thread Environment Block (TEB) access), GETPC technique (putting the current instruction register (IP) address into an assigned register for further shellcode self-decoding or decryption using a combination of assembly instructions "call" and "pop", GETPC with "call reg, pop reg", and GETPC with "fnstenv", using the float assembly instruction characteristic to push the current instruction register (IP) address onto a stack for further shellcode self-decoding or decryption), no-operation (NOP) instructions typically used by shellcode as shellcode entry points, etc.

[0088] In some embodiments, the shellcode entry point is identified based on a regular expression, for example, the shellcode entry point starts at or near a PEB / TEB access instruction, a GETPC instruction, a function call instruction, a NOP instruction, etc.

[0089] In one aspect, if the shellcode is encrypted or encoded to avoid static analysis, the encoded shellcode first calls a GETPC instruction, such as "call reg;pop reg" or "fnstenv", to get the current instruction register (IP) address for decrypting or decoding the shellcode. In another aspect, the shellcode includes a nop instruction at the beginning of the sample and transitions smoothly to the malicious shellcode after the end of the nop instruction.

[0090] At 530, the environment executes the suspect shellcode based on the candidate shellcode entry points to determine whether the suspect shellcode is malicious.

[0091] In some embodiments, the environment executes the suspect shellcode in a CPU emulator to obtain an input binary, and then executes the input binary in a full-system emulator. In some embodiments, the environment executes the suspect shellcode in a CPU emulator, and then executes the suspect shellcode in a full-system emulator. In some embodiments, the environment executes the suspect shellcode only in the CPU emulator. In some embodiments, the CPU emulator is Unicorn or Qiling. In some embodiments, the environment identifies assembly instruction level shellcode patterns (e.g., GETPC instructions, self-decode, PEB / TEB access, etc.) to detect shellcode in the input suspect shellcode in the CPU emulator. Typically, shellcode has fixed patterns, fixed characteristics, and / or fixed behavior. By detecting the shellcode, exploits can be detected. In some embodiments, the environment can generate a verdict when the suspect shellcode is executed only in the CPU emulator to obtain faster detection results (e.g., shortest sample processing time).

[0092] In some embodiments, the full-system emulator is QEMU and is capable of running an operating system to provide full-system emulation. In some embodiments, the environment executes suspect shellcode in memory within the operating system running in the full-system emulator and simultaneously monitors API function calls that invoke the shellcode to detect the shellcode from the suspect shellcode input. In some embodiments, the environment determines that the suspect shellcode is malicious if the monitored API function calls are detected during full-system emulation and / or if an assembly instruction level shellcode pattern is triggered during CPU emulation.

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

[0094] At 540, the environment generates a verdict for the sample based on the results of executing the suspect shellcode.

[0095] In some embodiments, if the suspect shellcode is determined to be malicious, the sample is determined to be an exploit, hi some embodiments, after the sample is determined to be malicious, the environment generates a signature for the malware sample.

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

[0097] Process 500 provided at least the following advantages: Suspect shellcode is segmented from RWE memory during dynamic analysis of a sample and located using a shellcode filter to identify candidate shellcode entry points; Process 500 can identify exploits using any API function call instead of only a few sensitive API function calls; Process 500 can utilize a CPU emulator and a full system emulator; 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.); Process 500 can potentially identify zero day exploits.

[0098] In some embodiments, CPU emulation is performed before full system emulation is performed because CPU emulation is faster and utilizes fewer resources than full system emulation. That way, when full system emulation is not required, process 500 can run faster and utilize fewer system resources.

[0099] 6 shows one embodiment of a process for monitoring memory blocks during dynamic analysis of a sample. In some embodiments, process 600 is an implementation of act 510 of FIG. 5 and includes the following:

[0100] At 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.

[0101] At 620, the environment determines that the memory block contains suspect shellcode if the change memory attributes function is called and corresponding parameters are provided to the change memory attributes function.

[0102] 7 shows another embodiment of a process for monitoring memory blocks during dynamic analysis of a sample. In some embodiments, process 700 is an implementation of operation 510 of FIG. 5 and includes the following:

[0103] At 710, after the process associated with the memory block is allowed to execute, the environment performs an offline scan of the process memory to determine whether the memory block has a particular memory attribute.

[0104] At 720, in response to determining that the memory block has the particular memory attribute, the environment determines that the memory block contains suspect shellcode.

[0105] 8 shows one embodiment of a process for dumping memory blocks in a memory. In some embodiments, process 800 is an implementation of act 520 of FIG. 5 and includes the following:

[0106] At 810, the environment identifies specific assembly code patterns or specific data structures in memory blocks that contain suspect shellcode.

[0107] At 820, the environment determines candidate shellcode entry points based on particular assembly code patterns or particular data structures.

[0108] 9 shows one embodiment of a process for executing suspect shellcode. In some embodiments, process 900 is an implementation of act 530 of FIG. 5 and includes the following:

[0109] At 910, the environment executes the suspect shellcode using a CPU emulator based on the candidate shellcode entry points.

[0110] In some embodiments, the input binary is obtained after the suspect shellcode is executed using a CPU emulator.

[0111] At 920, the environment executes the suspect shellcode using a full system emulator based on the candidate shellcode entry points.

[0112] In some embodiments, the input binary obtained from the CPU emulator is executed using a full-system emulator.

[0113] 10 shows one embodiment of a process for executing suspect shellcode using a CPU emulator. In some embodiments, process 1000 is an implementation of act 910 of FIG. 9 and includes the following:

[0114] At 1010, the environment emulates execution of the suspect shellcode using a CPU emulator.

[0115] At 1020, the environment determines whether the assembly instructions associated with the emulated execution of the suspect shellcode match a predefined shellcode pattern.

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

[0117] 11 shows one embodiment of a process for executing suspect shellcode using a full system emulator. In some embodiments, process 1100 is an implementation of act 920 of FIG. 9 and includes the following:

[0118] At 1110, the environment executes the suspect shellcode in memory within the operating system running in the full-system emulator based on the candidate shellcode entry points.

[0119] At 1120, the environment monitors the hooked application programming interface (API) functions to determine whether the suspect shellcode calls the hooked API functions. In some embodiments, the environment hooks one or more API functions during full system emulation.

[0120] At 1130, in response to determining that the suspect shellcode calls the hooked API function, the environment determines that the suspect shellcode is malicious.

[0121] FIG. 12 illustrates one embodiment of a process for detecting exploits involving shellcode.

[0122] In this example, a sample (an exploit for CVE-2015-5119) is analyzed in a monitored environment where memory attribute changing functions are monitored during dynamic analysis of the sample to identify memory blocks associated with the memory attribute changing functions. In this example, only one memory block containing the suspect shellcode is identified.

[0123] Memory blocks containing suspected shellcode are identified by hooking a memory attribute modification function that is called with RWE as a parameter, or by performing an offline scan of the process memory after the sample is executed (or at various points during execution) and analyzing the RWE memory attributes of the process memory to identify memory blocks containing suspected shellcode. After memory blocks containing suspected shellcode are identified, the memory blocks are dumped.

[0124] The dumped memory block containing the suspect shellcode is analyzed for a list of regular expressions (e.g., PEB / TEB access, GETPC technique, call function, NOP, etc.). In this example, there were two matches ((1) a call function pattern, and (2) a TEB access pattern), and one candidate entry point associated with each of the two matches was also identified.

[0125] The suspected shellcode based on the candidate entry points associated with each of the two matches is then executed.

[0126] The identified suspect shellcode and the candidate entry points associated with the match are fed into a CPU emulator. Assembly instruction level shellcode patterns are identified from the emulated assembly instructions in the CPU emulator to detect the shellcode in the suspect shellcode. In this example, TEB access, PEB access, and PEB Ldr access are identified. The input suspect shellcode may then be executed in memory in an operating system running a full-system emulator. Here, API function calls are monitored to detect the shellcode in the input suspect shellcode. In this example, API function calls, namely, GetProcAddress(LdrGetProcedureAddress) and CreateThreadEx, are identified. In this example, any monitored API function calls identified may be treated as evidence to identify the input suspect shellcode as malicious shellcode. The output of each emulator is a decision whether the sample is exploitative (malicious), and the decision is determined based on the execution results from the CPU emulator and / or the full-system emulator.

[0127] 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 of implementing the invention. The disclosed embodiments are illustrative and not restrictive.

Claims

1. 1. A system including a processor and a memory, The processor, Monitor memory blocks during dynamic analysis of a sample to identify memory blocks that contain suspicious shellcode, dumping the memory blocks into memory to identify candidate shellcode entry points associated with the suspect shellcode; Executing the suspect shellcode based on the candidate shellcode entry points to determine whether the suspect shellcode is malicious; and generating a verdict regarding the sample based on a result of executing the suspect shellcode; It is structured as follows: the memory is coupled to the processor and configured to provide instructions to the processor; system.

2. Monitoring memory blocks during dynamic analysis of the sample to identify memory blocks containing suspect shellcode includes: hooking a memory attribute change function associated with the memory block to determine whether the memory attribute change function has been invoked and whether corresponding parameters have been provided to the memory attribute change function; and determining that the memory block contains suspect shellcode in response to determining that the memory attribute modification function has been invoked and the corresponding parameters have been provided to the memory attribute modification function; The system of claim 1 , comprising:

3. Monitoring memory blocks during dynamic analysis of the sample to identify memory blocks containing suspect shellcode includes: performing an offline scan of the process memory to determine whether the memory block has a particular memory attribute; and determining that the memory block contains the suspected shellcode in response to determining that the memory block has the particular memory attribute; The system of claim 1 , comprising:

4. Dumping the memory blocks to memory to identify candidate shellcode entry points associated with the suspect shellcode includes: Identifying specific assembly code patterns or specific data structures in the memory block containing the suspect shellcode; and determining the candidate shellcode entry points based on the particular assembly code pattern or the particular data structure; The system of claim 1 , comprising:

5. executing the suspicious shellcode executing the suspect shellcode using a CPU emulator based on the candidate shellcode entry points; and executing the suspect shellcode using a full system emulator based on the candidate shellcode entry points; The system of claim 1 , comprising:

6. Utilizing the CPU emulator to execute the suspect shellcode, emulating the execution of the suspect shellcode using the CPU emulator; determining whether assembly instructions associated with the emulated execution of the suspect shellcode match a predefined shellcode pattern; and determining that the suspect shellcode is malicious in response to determining that assembly instructions associated with the emulated execution of the suspect shellcode match a predefined shellcode pattern; The system of claim 5 , comprising:

7. executing the suspect shellcode using the full system emulator; executing the suspect shellcode in the memory within an operating system executing in the full system emulator; monitoring hooked application programming interface (API) functions to determine if the suspect shellcode calls a hooked API function; and in response to determining that the suspect shellcode calls the hooked API function, determining that the suspect shellcode is malicious; The system of claim 5 , comprising:

8. The processor further comprises: generating a signature for the sample of malware in response to determining that the determination indicates that the sample is malicious; The system of claim 1 , configured as follows:

9. The processor further comprises: in response to determining that the determination indicates that the sample is malicious, generating a signature for the sample of malware and delivering the signature to a firewall; The system of claim 1 , configured as follows:

10. using a processor to monitor memory blocks during dynamic analysis of the sample to identify memory blocks containing suspect shellcode; using the processor to dump the memory blocks into memory and identify candidate shellcode entry points associated with the suspect shellcode; executing the suspect shellcode based on the candidate shellcode entry points to determine whether the suspect shellcode is malicious; and generating a verdict regarding the sample based on a result of executing the suspect shellcode using the processor; A method comprising:

11. The step of executing the suspicious shellcode includes: executing the suspect shellcode using a CPU emulator based on the candidate shellcode entry points; executing the suspect shellcode using a full system emulator based on the candidate shellcode entry points; The method of claim 10, comprising:

12. The step of executing the suspect shellcode using a CPU emulator includes: emulating execution of the suspect shellcode using the CPU emulator; determining whether assembly instructions associated with the emulated execution of the suspect shellcode match a predefined shellcode pattern; determining that the suspect shellcode is malicious in response to determining that assembly instructions associated with the emulated execution of the suspect shellcode match a predefined shellcode pattern; The method of claim 11 , comprising:

13. executing the suspect shellcode using the full system emulator, executing the suspect shellcode in the memory within an operating system executing in the full system emulator; monitoring hooked application programming interface (API) functions to determine whether the suspect shellcode calls a hooked API function; determining that the suspect shellcode is malicious in response to determining that the suspect shellcode calls the hooked API function; The method of claim 11 , comprising:

14. The method further comprises: generating a signature for the sample of malware in response to the determination that the test indicates the sample is malicious; The method of claim 10, comprising:

15. The method further comprises: in response to determining that the determination indicates that the sample is malicious; generating a signature for said sample of malware; delivering the signature to a firewall; The method of claim 10, comprising:

16. A computer program stored on a non-transitory computer readable medium, the computer program comprising computer instructions: The instructions, when executed, cause the computer to: monitoring memory blocks during dynamic analysis of the sample to identify memory blocks containing suspect shellcode; dumping the memory blocks into memory and identifying candidate shellcode entry points associated with the suspect shellcode; executing the suspect shellcode based on the candidate shellcode entry points to determine whether the suspect shellcode is malicious; and generating a verdict regarding the sample based on a result of executing the suspect shellcode; A computer program that causes the

Images