Systems and methods for detecting exploits involving shellcode

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 use include disrupting computer and / or network operations, stealing confidential information (e.g., sensitive 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 these efforts. Thus, there is a continuing need for improvements to techniques for identifying and mitigating malware. [Brief explanation of the drawings]

[0002] Various embodiments of the present invention are disclosed in the following detailed description and accompanying drawings. [Figure 1] FIG. 1 shows 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. [Figure 3] FIG. 3 shows 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. [Figure 5] FIG. 5 illustrates one embodiment of a process for detecting exploits that include 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 memory blocks in 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 that include shellcode. DETAILED DESCRIPTION OF THE INVENTION

[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 in disclosed processes may be varied 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 figures 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 purposes 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 mitigations and execute malicious shellcode (fragments of binary data) on the victim's computer. Existing exploit detection techniques only work in specific 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 construct the 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, which exists as data (not 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 the 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 executes the shellcode. Typically, the exploit has the same privileges as the 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 results of executing the suspect shellcode.

[0008] In some embodiments, monitoring memory blocks during dynamic analysis of the sample to identify memory blocks containing suspected 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 suspected shellcode.

[0009] In some embodiments, monitoring memory blocks during dynamic analysis of the sample to identify memory blocks containing suspected 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 suspected 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 determining that assembly instructions associated with the emulated execution of the suspect shellcode match a predefined shellcode pattern.

[0013] In some embodiments, executing the suspected shellcode using the full-system emulator includes executing the suspected 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 suspected shellcode calls a hooked API function, and determining that the suspected shellcode is malicious in response to determining that the suspected shellcode calls the hooked API function.

[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, set of devices, or software running on devices 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 an ASIC or FPGA. do.

[0018] Firewalls typically deny or allow 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 similarly applying a set of rules or policies.

[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 individual packets sent over the network (e.g., stateless packet filtering firewalls, or first-generation firewalls). 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 within the context of the set of packets associated with its network outbound packet flow. This firewall technique is commonly referred to as stateful packet inspection because it keeps a record of all connections passing 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 implement additional firewall technologies. For example, certain newer 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., the Palo Alto Networks PA Series firewalls). For example, Palo Alto Networks next-generation firewalls use various 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 technologies include 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 restrict data and file transfers), and Device ID (e.g., for identifying IoT device types). These identification technologies allow enterprises to securely 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 minimize latency while maximizing network throughput, as in the case of 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 commercially available from Palo Alto Networks (Palo Alto Networks firewalls are deployed on VMware® ESXi). TM and NSX TM , Citrix® Netscaler SDX TM It supports a variety of commercial virtualization environments, including 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 a REST-based API allow 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 shown 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 with the file name "calculator.apk" or "calculator.exe"), and may also be an independent component of another application (e.g., a mobile advertising SDK or library embedded within a calculator application).

[0028] As used herein, “malware” refers to applications that engage in behavior, covert or not (and illegal or not), that a user would not / would not approve of if fully informed. Examples of malware include Trojan horses, viruses, rootkits, spyware, hacking tools, keyloggers, etc. One example of malware is a desktop application that collects and reports an end user's location to a remote server (but does not provide the user with location-based services, such as a mapping service). 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 contact information and sends them to spammers. Other forms of malware may 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 Figure 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 outside enterprise network 140 (e.g., those 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 regarding 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 a data appliance 102, in various embodiments. Specifically, the data appliance 102 includes a high-performance multi-core central processing unit (CPU) 202 and 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 RAM 204, storage 210, and / or other suitable locations) information used to monitor the enterprise network 110 and implement the disclosed techniques. Examples of such information include application identifiers, content identifiers, user identifiers, requested URLs, IP address mappings, policy and other configuration information, signatures, hostname / URL categorization information, malware profiles, machine learning models, IoT device classification information, etc. 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, act 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 with 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 on the client device.

[0033] 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 cooperate 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 may be 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 a 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, and the data plane is responsible for data management, such as by performing packet processing and session handling.

[0036] 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. 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 skipped. The decryption engine 240 helps the data appliance 102 inspect and control SSL / TLS and SSH encrypted traffic and, therefore, helps stop threats that might otherwise remain hidden within 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 be assigned to control various options of the sessions controlled by the policy, for example, requiring the use of specific cipher suites and encryption protocol versions.

[0037] The application identification (APP-ID) engine 242 is configured to determine the type of traffic a session involves. As one 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 company wiki (categorized as "Web Browsing-Productivity" based on the URLs visited) and then browse a social networking site (categorized as "Web Browsing-Social Networking" based on the URLs visited). 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 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 can include one or more rules, which can be specified using domain names and / or host / server names, and the rules can 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 it 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, and, if applicable, receive instructions from C&C server 150.

[0042] Assume that data appliance 102 intercepts an email sent (e.g., by system 120) to user “Alice,” operating client device 104. A copy of malware 130 has been attached to the message by system 120. In an alternative but similar scenario, data appliance 102 may intercept an attempted download of malware 130 by client device 104 (e.g., from a website). In either scenario, data appliance 102 determines whether a signature of the file (e.g., email attachment or website download of malware 130) is present on 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 may 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 malware 130 is included in the set (e.g., an MD5 hash of the malware 130), the data appliance 102 may accordingly prevent transmission of the malware 130 to the client device 104 (e.g., by detecting that the MD5 hash of an 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, 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 data appliance 102 determine when one of its nodes has been compromised. For example, if client device 104 attempts to contact C&C server 150, such an attempt is a strong indicator that client 104 has been compromised by malware (and corrective action should be taken accordingly, such as quarantining client device 104 from communicating with other nodes in 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 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 actually benign. As a second example, the data appliance 102 may 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, data appliance 102 is configured to provide a file (e.g., malware 130) to security platform 122 for static / dynamic analysis to determine whether it is malicious and / or classify it if not. While security platform 122 is analyzing the attachment (for which a signature does not yet exist), various actions can be taken by data appliance 102. As a first example, data appliance 102 can prevent the email (and attachment) from being delivered to Alice until a response is received from security platform 122. Assuming that platform 122 takes approximately 15 minutes to fully analyze the sample, this means that the incoming message to Alice will be delayed by 15 minutes. In this example, the attachment is malicious, so such a delay does not negatively impact Alice. In an alternative example, assume that someone sends Alice a time-sensitive message with a benign attachment that also does not have a signature. Delaying delivery of the message to Alice by 15 minutes is likely considered 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 awaiting a verdict from platform 122). If the data appliance 102 can independently determine whether the attachment is malicious or benign, it can take initial action (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 can be configured to automatically block file downloads based on the analysis results. Additionally, signatures for the malware can 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 works in conjunction 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 including commercially available server-class hardware (e.g., a 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 commercially available virtualization software can be extended as needed (e.g., as provided by a hypervisor) to support the various functions described herein. Furthermore, the virtual machine server may be under the control of the same entity that manages security platform 122, but may also be provided by a third party. As one example, the virtual machine server may rely on EC2, while the remainder of security platform 122 is provided by dedicated hardware owned and under the control of the operator of security platform 122. VM server 124 is configured to provide one or more virtual machines 126-128 for emulating client devices. The virtual machines can 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, security platform 122 makes the results of its analysis of samples available to data appliance 102 as part of a subscription via a list of signatures (and / or other identifiers). For example, security platform 122 can periodically (e.g., daily, hourly, or at 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 the malware name (and / or malware family name) of each identified malware app. A subscription can cover analysis of only those files intercepted by and sent by data appliance 102 to security platform 122, and can also cover signatures of all malware known to 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, if applicable, instead of) the operator of data appliance 102. For example, other businesses 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) 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 in accordance with the techniques described herein, and then send applications to security platform 122 for analysis).

[0051] IV. Analyzing the Sample 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 located within 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 can 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 good 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 Figure 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 as 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) 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 sample's database record (e.g., in 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 generates a verdict about the application (e.g., "safe," "suspicious," or "malicious"). As one example, if the application has at least one "malicious" static feature (e.g., the application contains a hard link to a known malicious domain), the verdict may be "malicious." As another example, points may be assigned to each of the features (e.g., based on severity, if found, based on how reliable the feature is for predicting malicious intent, etc.), and a verdict may be assigned by the static analysis engine 306 (or 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, 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 directly include one or more dynamic analysis engines. 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 format (308) and / or stored in database 316 or otherwise, are provided as input to dynamic analysis engine 310. For example, static analysis report information may 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 may manage all of the instances, or, if applicable, multiple dynamic analysis engines may be used (e.g., each managing its own virtual machine instance). As described in more detail below, during the dynamic portion of the analysis, actions taken by the application (including network activity) are analyzed.

[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 to be malicious (e.g., by the first entity), the file may be provided to a second entity (e.g., an operator of the security platform 122) for additional analysis (e.g., by the dynamic analysis engine 310), particularly regarding the use of malware 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, or may 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 a list (314) of domains, IP addresses, etc., and determine whether the sample communicated (or attempted to communicate) with a malicious entity.

[0064] Like the static analysis engine, the dynamic analysis engine stores the results of its analysis in database 316 in a record associated with the application being tested (and / or includes the results in report 312, if applicable). In some embodiments, the dynamic analysis engine also forms a verdict (e.g., “safe,” “suspicious,” or “malicious”) about 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 to the actions taken (e.g., based on severity, if found, how reliable the action is to predict maliciousness, etc.). A verdict may then be assigned by dynamic analysis engine 310 (or coordinator 304, if applicable) based on the number of points associated with the dynamic analysis results. In some embodiments, the final verdict associated with a sample is made (e.g., by coordinator 304) based on a combination of report 308 and report 312.

[0065] V. User Interaction Simulation 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 not 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 applicable components, 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 malware can determine whether 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 to a default name, such as "sample.exe" (e.g., from its original name as observed by data appliance 102). A script (e.g., "autoexec.bat") is automatically executed by the guest operating system at startup and either launches the sample directly or causes the sample to be launched (e.g., by a dynamic analysis helper tool). 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 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 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 are 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 is 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 predetermined number of mouse clicks, etc.) before exhibiting malicious behavior.

[0070] A. Example 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 shown 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 being analyzed (e.g., 64-bit Windows 7 SP2 or Mac OS 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 movements, 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, causing the malware to refrain from exhibiting malicious behavior to avoid detection.

[0073] An alternative approach (such as that 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 to allow the hypervisor to move the virtualized mouse directly 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. Malware Sample Analysis

[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 detection by static analysis.

[0076] Some limitations of traditional dynamic analysis of samples to determine whether a sample is malicious include the fact 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, and Microsoft Office never call one of the small number of sensitive API function calls, so a sample that calls a 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, thus limiting the effectiveness of traditional dynamic analysis.

[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 shows 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:

[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 suspected shellcode, for Word, Excel, and PowerPoint documents, the environment can use MS Office to identify suspected shellcode, and for HTML or JavaScript files, the environment can use Chrome or another browser to identify suspected 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 on 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 offline scanning of process memory is performed, the environment analyzes the process memory via 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, memory blocks associated with marked memory were given permission 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 techniques (using a combination of the assembly instructions "call" and "pop" to put the current instruction register (IP) address into an assigned register for further shellcode self-decoding or decryption; 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 the 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 obtain the current instruction register (IP) address for decryption or decoding of 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 suspected shellcode based on the candidate shellcode entry points to determine whether the suspected shellcode is malicious.

[0091] In some embodiments, the environment executes suspected 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 suspected shellcode in a CPU emulator and then executes the suspected shellcode in the full-system emulator. In some embodiments, the environment executes suspected 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-decoding, PEB / TEB access, etc.) to detect shellcode in the input suspected shellcode in the CPU emulator. Typically, shellcode has fixed patterns, fixed characteristics, and / or fixed behavior. Detecting shellcode can detect exploits. In some embodiments, to obtain faster detection results (e.g., shortest sample processing time), the environment can generate a verdict when suspected shellcode is executed only in the CPU emulator.

[0092] In some embodiments, the full-system emulator is QEMU and can run an operating system to provide full-system emulation. In some embodiments, the environment executes suspected 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 suspected shellcode input. In some embodiments, the environment determines that the suspected shellcode is malicious if a monitored API function call is 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 full system emulation is performed if necessary, so the two emulations are complementary to 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 suspected shellcode is determined to be malicious, the sample is determined to be an exploit. In some embodiments, after the sample is determined to be malicious, the environment generates a signature for the malware sample.

[0096] In some embodiments, after a 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: Suspicious shellcode was segmented from RWE memory during dynamic analysis of the sample and located using a shellcode filter to identify candidate shellcode entry points; Process 500 could identify exploits using any API function call instead of only a few sensitive API function calls; Process 500 could utilize CPU emulators and full system emulators; Process 500 had a very low false positive rate; Process 500 could 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 could 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:

[0100] At 610, the environment hooks the 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, if the change memory attributes function is called and the corresponding parameters are provided to the change memory attributes function, the environment determines that the memory block contains suspect shellcode.

[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 act 510 of FIG. 5 and includes:

[0103] At 710, after the process associated with the memory block is allowed to run, 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 illustrates one embodiment of a process for dumping memory blocks in 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 specific assembly code patterns or specific data structures.

[0108] 9 illustrates 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:

[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:

[0114] At 1010, the environment emulates the 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 predetermined shellcode pattern.

[0116] At 1030, if the assembly instructions associated with the emulated execution of the suspect shellcode match a predetermined 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:

[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 suspected 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 invokes 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 that include shellcode.

[0122] In this example, a sample (an exploit for CVE-2015-5119) is analyzed in a monitored environment where memory attribute modification functions are monitored during dynamic analysis of the sample to identify memory blocks associated with the memory attribute modification 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) call function pattern and (2) 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 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 shellcode in the suspect shellcode. In this example, TEB access, PEB access, and PEB Ldr access are identified. The input suspect shellcode can then be executed in memory in an operating system running a full-system emulator. Here, API function calls are monitored to detect 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 can be treated as evidence to identify the input suspect shellcode as malicious. The output of each emulator is a determination of whether the sample is exploitable (malicious), and the determination 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 present invention is not limited to the details provided. There are many alternative ways of implementing the present invention. The disclosed embodiments are illustrative and not restrictive.

Claims

1. 1. A system including a processor and a memory, The processor: Monitoring memory blocks during dynamic analysis of the sample to identify memory blocks containing suspect shellcode, and monitoring memory blocks during dynamic analysis of the sample to identify memory blocks containing suspect shellcode may include: 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 shell code in response to determining that the memory block has the particular memory attribute; 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 a 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, wherein the corresponding parameters include read | write | execute (RWE); and determining that the memory block contains suspect shellcode in response to determining that the memory attribute change function has been invoked and the corresponding parameters have been provided to the memory attribute change function; The system of claim 1 , comprising:

3. 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:

4. Executing the suspicious shellcode comprises: 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:

5. executing the suspect shellcode using the CPU emulator, 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 determining that assembly instructions associated with the emulated execution of the suspect shellcode match a predefined shellcode pattern; The system of claim 4 , comprising:

6. executing the suspect shellcode using the full system emulator; Executing the suspect shellcode in the memory within the operating system running in the full system emulator; monitoring hooked application programming interface (API) functions to determine whether the suspect shellcode calls a hooked API function; and responsive to determining that the suspect shellcode invokes the hooked API function, determining that the suspect shellcode is malicious; The system of claim 4 , comprising:

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

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

9. 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 block 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; Including, 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; Including, method.

10. The step of 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; 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; 10. The method of claim 9, comprising:

11. executing the suspect shellcode using the full system emulator, executing the suspect shellcode in the memory within an operating system running 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 invokes the hooked API function; 10. The method of claim 9, comprising:

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

13. 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; 10. The method of claim 9, comprising:

14. A computer program stored on a non-transitory computer-readable medium, the computer program comprising computer instructions; When executed, the instructions cause the computer to: monitoring memory blocks during dynamic analysis of the sample to identify memory blocks containing suspect shellcode; and monitoring memory blocks during dynamic analysis of the sample to identify memory blocks containing suspect shellcode, the 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; and dumping the memory block 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 performs the above.

Images