Automatic detection of unknown packaging program

Abstract

Techniques for automatically detecting unknown packed programs are disclosed. In some embodiments, a system / process / computer program product for automatically detecting unknown packagers includes receiving a plurality of samples for malware packager detection analysis; executing a packing program filter to determine whether each of the plurality of samples is packed; simulating each sample in the packed samples to extract a plurality of features; and clustering the packed samples based on the extracted features.

Description

Background Art

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

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

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

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

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

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

[0007] Figure 4A Illustrated are portions of an example embodiment of a packer detector for automatically detecting unknown packers in accordance with some embodiments.

[0008] Figure 4B Illustrated are portions of an example embodiment of an inline packer detector for automatically detecting unknown packers in accordance with some embodiments.

[0009] Figure 5A and Figure 5B An example packer cluster determined based on experimental results for automatic detection of unknown packers according to some embodiments is illustrated.

[0010] Figure 6 is a flow diagram of a process for automatically detecting unknown packers according to some embodiments.

[0011] Figure 7is a flow diagram of an inline process for automatically detecting unknown packers, according to some embodiments. DETAILED DESCRIPTION

[0012] 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 a processor configured to execute instructions, the instructions being stored on and / or provided by a memory coupled to the processor. In this specification, these embodiments or any other form that the present invention may take may be referred to as techniques. In general, the order of the steps of the disclosed processes may be changed within the scope of the present invention. Unless otherwise stated, a component described as being configured to perform a task (such as a processor or memory) may be implemented as a general component temporarily configured to perform a task at a given time or as a specific component manufactured to perform a 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).

[0013] Provided below are detailed descriptions of one or more embodiments of the invention and accompanying drawings that illustrate the principles of the invention. The invention is described in conjunction with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims, and the invention encompasses numerous alternatives, modifications, and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for illustrative purposes, and the invention can be practiced according to the claims without some or all of these specific details. For the sake of clarity, technical materials known in the technical field related to the invention are not described in detail to avoid unnecessarily obscuring the invention.

[0014] Firewalls generally protect networks from unauthorized access while allowing authorized communications to pass through the firewall. A firewall is typically a device, a group of devices, or software executed on a device that provides firewall functionality for network access. For example, a firewall can be integrated into an operating system of a device (e.g., a computer, a smart phone, or other type of device capable of network communication). Firewalls can also be integrated into various types of devices or executed as one or more software applications on these devices, such as computer servers, gateways, network / routing devices (e.g., network routers), and data devices (e.g., security devices or other types of dedicated devices), and in various embodiments, certain operations can be implemented in dedicated hardware (such as ASICs or FPGAs).

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

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

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

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

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

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

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

[0022] Overview of techniques for automatically detecting unknown packers

[0023] Packers are often used by people who generate malware as a mechanism to avoid malware detection by anti-malware security solutions. The generation of malware variants is also facilitated by such automated packers.

[0024] However, existing anti-malware security solutions are unable to efficiently and effectively detect unknown / custom packers in the wild. For example, existing signature-based detection solutions (e.g., for more information on signature-based techniques, such as creating YARA rules based on code, see, e.g., https: / / www.binarydefense.com / creating-yara-rules-based-on-code / ) and machine learning-implemented detection solutions are generally unable to automatically detect such unknown and / or new custom packers.

[0025] Therefore, what is needed is an anti-malware security solution that can effectively and automatically detect such unknown and / or new custom packers.

[0026] Thus, new and improved techniques for automatically detecting unknown packers are disclosed.

[0027] In some embodiments, a system / process / computer program product for automatically detecting unknown packers includes: receiving multiple samples for malware packer detection analysis; executing a packer filter to determine whether each of the multiple samples is packed; simulating each of the packed samples to extract multiple features; and clustering the packed samples based on the extracted features.

[0028] For example, the plurality of features may include at least one or more of: an opcode feature, a file format feature, and an application programming interface (API) feature, such as further described below with respect to various embodiments.

[0029] In some embodiments, a system / process / computer program product for automatically detecting unknown packers includes: receiving a sample for inline malware packer detection analysis; executing a packer filter to determine whether to pack the sample; comparing with a cluster of known packers to determine whether the sample is associated with a known malware packer; and performing a response action based on the malware packer determination.

[0030] For example, the disclosed technology provides a new approach for malware detection to solve the technically challenging packer problem. Specifically, the disclosed technology provides an automated solution for discovering and identifying such new and / or customized packers, which is based on the observation that the same packer stub at the beginning of the entry point will include similar concepts / flows of unpacking routines (e.g., packers can be identified and grouped based on their unpacking flow and API calls), as will be further described below.

[0031] More specifically, with respect to various embodiments further described below, a new packer filter is disclosed that can automatically and efficiently detect packaged samples (e.g., malware samples). In addition, machine learning, domain knowledge, and simulators can be used to automatically identify and group packers with similar unpacking routines. Test results confirm that the disclosed technology can accurately identify such new unknown packers that other methods cannot identify. In addition, the disclosed technology resists random / junk instructions (e.g., inserting random / junk instructions into such packers is often used as a pattern avoidance mechanism by malware writers) that would otherwise avoid detection by existing traditional signature methods, as will be further described below.

[0032] The disclosed techniques for automatically detecting unknown packers reduce the labor-intensive workload compared to existing traditional signature methods, which require malware analysts to spend a lot of time and effort manually analyzing packers in order to try to detect and generate new signatures for previously unknown packers. Traditionally, malware analysts need to find such new / custom packers, group / classify the packers, and manually create new signatures for the packers.

[0033] Furthermore, as similarly discussed above, the disclosed techniques for automatically detecting unknown packers are generally superior to existing traditional signature detection methods because malware writers circumvent signature-based detection methods by using junk instruction / pattern evasion methods that can avoid detection by such signatures. Furthermore, such junk instruction / pattern evasion methods are expensive for security solutions to detect because they result in hash changes that may require additional / re-analysis of previously identified packers of known malware.

[0034] Further, packer information correlation as described further below can extend the base facts beyond multiple scans and VirusTotal (e.g., VirusTotal, founded in 2004, is a free online service that analyzes files and URLs for viruses, worms, Trojans, and other kinds of malicious content, see https: / / www.virustotal.com). For example, if a sample is not available on VirusTotal, but has the same custom unpacking routine associated with a malware family, it can be determined that they are highly related.

[0035] Thus, in accordance with some embodiments, new and improved security solutions are disclosed that facilitate automatic detection of unknown packers using a security platform (e.g., a firewall (FW) / next-generation firewall (NGFW), a network sensor acting on behalf of a firewall, or another (virtual) device / component that can implement security policies using the disclosed techniques, including, for example, Palo Alto Networks' PA Series Next-Generation Firewalls, Palo Alto Networks' VM Series Virtualized Next-Generation Firewalls, and CN Series Container Next-Generation Firewalls and / or other commercially available virtual-based or container-based firewalls that can be similarly implemented and configured to perform the disclosed techniques).

[0036] These and other embodiments and examples for automatically detecting unknown packers are described further below.

[0037] Example system architecture for automatic detection of unknown packers

[0038] Thus, in some embodiments, the disclosed technology includes providing a security platform (e.g., security function(s) / platform(s) that may be implemented using a firewall (FW) / next-generation firewall (NGFW), a network sensor acting on behalf of a firewall, or another (virtual) device / component that may implement security policies using the disclosed technology, such as PANOS executed on a virtual / physical NGFW solution commercially available from Palo Alto Networks, Inc., or another security platform / NFGW, including, for example, Palo Alto Networks' PA Series Next-Generation Firewalls, Palo Alto Networks' VM Series Virtualized Next-Generation Firewalls, and CN Series Container Next-Generation Firewalls and / or other commercially available virtual-based or container-based firewalls that may be similarly implemented and configured to perform the disclosed technology), the security platform being configured to provide DPI capabilities (e.g., including stateful inspection) for, for example, applying the disclosed technology for automatically detecting unknown packers, as further described below.

[0039] Figure 1 An example of an environment in which malicious applications ("malware") are detected and prevented from causing damage is illustrated. As will be described in more detail below, malware classification (e.g., by security platform 122) may be performed in Figure 1 The various entities included in the illustrated environment are shared and / or improved in various ways. Also, using the techniques described herein, devices (such as endpoint client devices 104 to 110) can be protected from such malware (e.g., including malware associated with previously unknown / custom packagers).

[0040] As used herein, "malware" refers to an application that engages in behavior that the user does not approve of / would not approve of if fully informed, whether secret or not (and illegal or not). Examples of malware include ransomware, Trojans, viruses, rootkits, spyware, hacker tools, etc. An example of malware is a desktop / mobile application that encrypts data stored by a user (e.g., ransomware). Another example of malware is a desktop / mobile application that collects and reports to a remote server the activities of an end user and / or various information associated with the user (e.g., spyware). Other forms of malware (e.g., keyloggers) can also be detected and / or thwarted using improved and automated packager detection techniques, as will be further described herein.

[0041] The term "packer" is used throughout this specification to refer to what is also commonly referred to as a "runtime packer", which is also known as a "self-extracting archive". Thus, when a "pack file" is executed, a packer can be used to provide software that unpacks itself in memory. This approach is sometimes also referred to as "executable compression". Although this type of compression was originally developed to make files smaller for distribution and storage, it is now often used by malware writers (e.g., hackers) to conceal malware (e.g., in an attempt to evade analysis and detection by existing security solutions).

[0042] Packers (e.g., malware packers) are now commonly used by malware writers (e.g., hackers) to avoid detection by existing security solutions (e.g., for more information on how malware packers use various tricks to avoid analysis and detection by existing security solutions, see, e.g., https: / / www.mcafee.com / blogs / enterprise / malware-packers-use-tricks-avoid-analysis-detection / ). Specifically, malware packers are tools that can be used to mask malware (e.g., in an attempt to hide / obfuscate malicious files / payloads from detection by existing security solutions). More specifically, packers can encrypt, compress, and / or simply change the format of malicious files / payloads to make them look like some other content in an attempt to avoid malware analysis and detection by existing security solutions.

[0043] There are many existing commercially available packers. Attackers / hackers can use such existing commercially available packers to pack their malware files / payloads, but hackers often modify or customize these packers, making it technically more challenging for security solutions to detect their packed malware.

[0044] Given that packers are commonly used by hackers, detection of packers can be used by security solutions to detect malware, as well as identify and classify / group malware based on the associated packers.

[0045] However, as discussed further herein, as new and / or custom packers become more common and more sophisticated, and often evade detection by existing packer detection methods (including signature-based packer detection and static machine learning-related packer detection methods), automated detection of packer activity is becoming an increasing technical challenge.

[0046] The techniques described herein can be used in conjunction with a variety of platforms (e.g., servers, computing devices, virtual / container environments, desktops, mobile devices, gaming platforms, embedded systems, etc.) and / or for automated detection of a variety of forms of packagers (e.g., new and / or custom packagers, etc.). Figure 1 In the example environment shown, client devices 104-108 are a laptop computer, a desktop computer, and a tablet computer (respectively) that reside within an enterprise network 140. Client device 110 is a laptop computer that resides outside of enterprise network 140.

[0047] Data device 102 is configured to enforce policies regarding communications between client devices (such as client devices 104 and 106) and nodes outside of enterprise network 140 (e.g., reachable via external network 118). Examples of such policies include policies that control traffic shaping, quality of service, and traffic routing. Other examples of policies include security policies, such as policies that require 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 device 102 is also configured to enforce policies regarding traffic that resides within enterprise network 140.

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

[0049] The functions described herein as being performed by data device 102 may be provided / implemented in a variety of ways. For example, data device 102 may be a dedicated device or a group of devices. The functions provided by data device 102 may also be integrated into 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 device 102 are provided to a client device (e.g., client device 104 or client device 110) instead of (or in addition to) being provided to the client device by software executed on the client device.

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

[0051] Figure 2B 1 is a functional diagram of the logical components of an embodiment of a data device. In various embodiments, the examples shown are representations of logical components that may be included in the data device 102. Unless otherwise specified, the various logical components of the data device 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., as applicable).

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

[0053] 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. When the flow module 238 identifies a packet as part of a new session, it creates a new session flow. Subsequent packets will be identified as belonging to the session based on the flow lookup. If applicable, SSL decryption is applied by the SSL decryption engine 240. Otherwise, the processing performed by the SSL decryption engine 240 is omitted. The decryption engine 240 can help the data device 102 to inspect and control SSL / TLS and SSH encrypted traffic, and thus help stop threats that may otherwise be hidden in 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 classification, traffic source, traffic destination, user, user group, and port. In addition to decryption policies (e.g., specifying which sessions to decrypt), decryption profiles can also be assigned to control various options for sessions controlled by the policy. For example, it may be required to use a specific cipher suite and encryption protocol version.

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

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

[0056] Also like Figure 2BAs shown, policies 252 are received and stored in the management plane 232. Policies may include one or more rules that may be specified using domains and / or host / server names, and the rules may apply one or more signatures or other matching criteria or intuitions, such as for enforcing security policies on subscribers / IP flows based on various extracted parameters / information from monitored session traffic flows. Example policies may include packer / malware detection policies using disclosed techniques for unknown / custom packers. An interface (I / F) communicator 250 is provided for management communications (e.g., via (REST) ​​APIs, messaging or network protocol communications, or other communication mechanisms).

[0057] Secure Platform

[0058] Back to Figure 1 , assume that a malicious individual (using system 120) creates malware 130 using a custom packer (e.g., the malware can be delivered to a user's endpoint device via a hacked website when the user visits / browses the hacked website or via a phishing attack, etc.). The malicious individual hopes that a client device (such as client device 104) will execute a copy of malware 130 to unpack the malware executable / payload, thereby hacking the client device and, for example, causing the client device to become a bot in a botnet. The hacked client device can then be instructed to perform tasks (e.g., cryptocurrency mining or engaging in a denial of service attack), as applicable, and report information to and receive instructions from an external entity (e.g., command and control (C&C) server 150).

[0059] Assume that the data appliance 102 intercepts (e.g., via the system 120) an email sent to a user "Alice" operating a client device 104. In this example, Alice receives the email and clicks on a link to a phishing / compromised website, which may cause Alice's client device 104 to attempt to download malware 130. However, in this example, the data appliance 102 may execute the disclosed techniques for automated detection of unknown / custom packers and block access to the packed malware content from Alice's client device 104, and thereby preempt and prevent any such downloading of malware 130 to Alice's client device 104. As will be further described below, the data appliance 102 executes the disclosed techniques for automated detection of unknown / custom packers, such as described further below, to detect and block such malware 130 from compromising Alice's client device 104.

[0060] In various embodiments, the data device 102 is configured to work in conjunction with the security platform 122. As an example, the security platform 122 may provide a set of signatures for known malicious files to the data device 102 (e.g., as part of a subscription). If the signature for the malware 130 is included in the set (e.g., the MD5 hash of the malware 130), the data device 102 may accordingly prevent the malware 130 from being transmitted to the client device 104 (e.g., by detecting that the MD5 hash of the email attachment sent to the client device 104 matches the MD5 hash of the malware 130). The security platform 122 may also provide the data device 102 with a list of known malicious domains and / or IP addresses, allowing the data device 102 to block traffic between the enterprise network 140 and the C&C server 150 (e.g., in the case where the C&C server 150 is known to be malicious). The list of malicious domains (and / or IP addresses) may also help the data device 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 indication that client 104 has been compromised by malware (and remedial measures should be taken accordingly, such as isolating client device 104 from communicating with other nodes within enterprise network 140).

[0061] As will be described in more detail below, the security platform 122 may also receive a copy of the malware 130 from the data device 102 to perform cloud-based security analysis for performing automated detection of unknown / custom packers, and malware determinations may be sent back to the data device 102 for enforcing security policies to protect Alice's client device 104 from execution of the malware 130 (e.g., blocking the malware 130 from accessing the client device 104).

[0062] Further, the security platform 122 may also provide other types of information to the data device 102 (e.g., as part of a subscription), such as a set of information for performing the disclosed techniques for automated detection of unknown / custom packers, which the data device 102 may use to perform inline analysis of such malware files, as will be further described below.

[0063] In various embodiments, if the signature of the attachment is not found, the data device 102 can take a variety of actions. As a first example, the data device 102 can achieve fail-safety by blocking the transmission of any attachment that is not whitelisted as benign (e.g., does not match the signature of a known good file). The disadvantage of this approach is that there may be many legitimate attachments that are unnecessarily blocked as potential malware, when in fact they are benign. As a second example, the data device 102 can cause a failure hazard by allowing the transmission of any attachment that is not blacklisted as malicious (e.g., does not match the signature of a known bad file). The disadvantage of this approach is that it will not be possible to prevent newly created malware (not previously seen by the platform 122) from causing damage. As a third example, the data device 102 can be configured to provide a file (e.g., malware 130) to the security platform 122 for static / dynamic analysis to determine whether it is malicious and / or otherwise classify it.

[0064] Security platform 122 stores a copy of the received sample in storage device 142 and starts (or schedules, if applicable) analysis. An example of storage device 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 device can be configured to automatically block the file download based on the analysis results. Further, a signature can be generated for the malware and distributed (e.g., to data devices, such as data devices 102, 136, and 148) to automatically block future file transfer requests to download files determined to be malicious.

[0065] In various embodiments, the security platform 122 includes one or more dedicated commercially available hardware servers (e.g., with (one or more) multi-core processors, 32G+ of RAM, (one or more) Gigabit network interface adapters, and (one or more) hard drives) that run typical server-class operating systems (e.g., Linux). The security platform 122 can be implemented across a scalable infrastructure that includes multiple such servers, solid-state drives, and / or other applicable high-performance hardware. The security platform 122 can include several distributed components, including components provided by one or more third parties. For example, part or all of the security platform 122 can be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3). Further, as with the data device 102, whenever the 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 multiple subcomponents of the security platform 122 (whether alone or in cooperation with third-party components) can cooperate to perform the task. As an example, the security platform 122 can optionally cooperate with one or more virtual machine (VM) servers (such as VM server 124) to perform static / dynamic analysis.

[0066] An example of a virtual machine server is a physical machine that includes commercially available server-class hardware (e.g., a multi-core processor, 32+ gigabytes of RAM, and one or more gigabit network interface adapters) that runs commercially available virtualization software, such as VMware ESXi, Citrix XenServer, or Microsoft Hyper-V. In some embodiments, the virtual machine server is omitted. Further, the virtual machine server can be under the control of the same entity that manages the security platform 122, but can also be provided by a third party. As an example, the virtual machine server can rely on EC2, where the rest of the security platform 122 is provided by dedicated hardware owned and under the control of the operator of the security platform 122. VM server 124 is configured to provide one or more virtual machines 126 to 128 for emulating client devices. The virtual machine can execute a variety of operating systems and / or versions thereof. Observed behavior generated by executing an application in a virtual machine is recorded and analyzed (e.g., an indication that the application is malicious). In some embodiments, 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 the security platform 122 , such as the orchestrator 144 .

[0067] In various embodiments, as part of the subscription, the security platform 122 makes the results of its analysis of the sample available to the data device 102 via a list of signatures (and / or other identifiers). For example, the security platform 122 may periodically send content packages that identify malware files, including automated detection for unknown / custom packers, etc. (e.g., daily, hourly, or some other interval, and / or based on events configured by one or more policies). An example content package includes a packet detector 154 and / or other information (e.g., a packer detection model), such as described further below. A subscription may cover analysis of only those files that are intercepted by the data device 102 and sent to the security platform 122 by the data device 102, and may also cover signatures of malware known to the security platform 122. As will be described in more detail below, the platform 122 may also use the packer detection model generated by using the model builder 152 and the packer detector 154 to make other types of information available for automated detection of unknown / custom packers (e.g., as will be described further below, such as information about Figure 4A and Figure 4B ), which is performed using the disclosed automated custom / unknown packer detection techniques, which can help the data device 102 detect and perform inline blocking of malware created using such custom / unknown packers.

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

[0069] Analyze samples using static / dynamic analysis

[0070] Figure 3An example of logical components that may be included in a system for analyzing a sample is illustrated. 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 incorporated into data device 102. Analysis system 300 may also be implemented across multiple different devices. For example, the functionality of analysis system 300 may be provided by security platform 122.

[0071] In various embodiments, the analysis system 300 may use a list, database, or other collection of known safe content and / or known objectionable content (in Figure 3 100 and / or 106). The information included in set 314 is collectively shown as set 314 in the examples. Set 314 can be obtained in a variety of ways, including via a subscription service (e.g., provided by a third party) and / or as a result of other processing (e.g., performed by data device 102 and / or security platform 122). Examples of information included in set 314 are: URLs, domain names, and / or IP addresses of known malicious servers; URLs, domain names, and / or IP addresses of known secure servers; URLs, domain names, and / or IP addresses of known command and control (C&C) domains; signatures, hashes, and / or other identifiers of known malicious applications; signatures, hashes, and / or other identifiers of known secure applications; signatures, hashes, and / or other identifiers of known malicious files (e.g., OS development files); signatures, hashes, and / or other identifiers of known secure libraries; and signatures, hashes, and / or other identifiers of known malicious libraries.

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

[0073] Coordinator 304 monitors queue 302, and when resources (e.g., static analysis workers) become available, coordinator 304 obtains samples from queue 302 for processing (e.g., obtaining a copy of malware 130). In particular, coordinator 304 first provides samples to static analysis engine 306 for static analysis. In some embodiments, one or more static analysis engines are included in analysis system 300, where 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 static analysis engine 306).

[0074] The static analysis engine obtains general information about the sample and includes it (as well as heuristics and other information, as applicable) in a static analysis report 308. The report can be created by the static analysis engine or the coordinator 304 (or by another appropriate component), and the coordinator 304 can be configured to receive information from the static analysis engine 306. As an example, static analysis of malware can include performing a signature-based analysis. In some embodiments, the collected information is stored in a database record for the sample (e.g., in the database 316) instead of or in addition to a separate static analysis report 308 being created (i.e., a portion of the database record forms the report 308). In some embodiments, the static analysis engine also forms a verdict about the application (e.g., "safe", "suspicious", or "malicious"). As an example, the verdict can be "malicious" even if there is a "malicious" static feature in the application (e.g., the application includes a hard link to a known malicious domain). As another example, points can be assigned to each feature (e.g., based on the severity of the finding; based on the reliability of the feature in predicting malicious behavior; etc.), and a verdict can be assigned by static analysis engine 306 (or orchestrator 304, if applicable) based on the number of points associated with the static analysis results.

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

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

[0077] In various embodiments, static analysis of the sample is omitted or performed by a separate entity, as applicable. As an example, conventional static and / or dynamic analysis can be performed on a file by a first entity. Once a determination is made (e.g., by a first entity) that a given file is malicious, the file can be provided to a second entity (e.g., an operator of security platform 122) specifically for additional analysis regarding malware use of network activity (e.g., by dynamic analysis engine 310).

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

[0079] As with the static analysis engine, the dynamic analysis engine stores the results of its analysis in a database 316 in a record associated with the application being tested (and / or includes the results in a report 312, as applicable). In some embodiments, the dynamic analysis engine also forms a verdict (e.g., "safe," "suspicious," or "malicious") about the application. As an example, a verdict may be "malicious" even if the application takes a "malicious" action (e.g., observed attempting to contact a known malicious domain or attempting to leak sensitive information). As another example, points may be assigned to the actions taken (e.g., based on the severity of the finding; based on the reliability of the action predicting maliciousness; etc.), and a verdict may be assigned by the dynamic analysis engine 310 (or 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 based on a combination of the report 308 and the report 312 (e.g., by the coordinator 304).

[0080] Automatically detect unknown packers

[0081] Figure 4AThe diagram illustrates a portion of an example embodiment of a packer detector for automatically detecting unknown packers according to some embodiments. As discussed similarly above, in various embodiments, the security platform 122 includes a packer detector 154. The packer detector includes a packer filter 410 that performs various operations to determine whether a given sample input 402 is a packing sample, as will be further described below. Then, the sample determined to be a packing sample is provided to a simulator 420. The simulator performs various operations to extract predetermined features from the packing sample, as will be further described below. Then, the extracted features of the packing sample are provided to a cluster generator 430. The cluster generator performs clustering operations using the extracted features to generate multiple clusters of the packing sample, as will be further described below. For example, packing samples with similar features are generally associated with a given cluster, as will be further described below. Each of these components can be implemented with Python and / or a high-level programming language, and various open source or publicly available components are used, such as will be further described below.

[0082] Referring to the packer filter 410, the packer filter includes an entropy calculator component 412. Generally, the packer filter reduces the number of samples for further analysis by identifying samples from a set of input samples (402) that are packing samples and / or possible packing samples (e.g., the packer filtering operation can improve clustering quality by reducing false negatives and reduce the amount of processing for feature extraction and clustering operations, so that further analysis is performed only on (possible) packing samples). The entropy calculator performs entropy calculations based on the content of binary code in the samples. If the result of the entropy calculation exceeds a threshold entropy (e.g., in an example implementation, if the entropy is above 7, then it can be confidently determined that it is a packed sample, see, e.g., https: / / www.semanticscholar.org / paper / Using-Entropy-Analysis-to-Find-Encrypted-and-Packed-Lyda-Hamrock / 86bf19a53e70d346d2105e4a3bcd9a588b943dcd / figure / 0), then the result is used as a factor in determining that the sample is likely to be a packed sample (e.g., packers generally increase the entropy associated with the content of the sample by using compression, obfuscation, and / or other techniques to pack samples). There are various existing libraries in Python for determining entropy calculations for content, such as files / samples (e.g., an example Python library implementation for performing entropy calculations is publicly available at https: / / gist.github.com / jaradc / eeddf20932c0347928d0da5a09298147).

[0083] Referring to the packer filter 410, the packer filter also includes an import table check component 414. The abnormal import table component can be implemented as a set of intuitive inferences to determine whether an import table associated with, for example, a Microsoft Windows PE file is abnormal. The determination of the abnormal import table is used as another factor to determine that the sample may be a packed sample (e.g., a packed sample is generally more likely to not have properties typically associated with an unpacked Microsoft Windows PE file). As an example, an import table that imports a zero library can be considered abnormal (e.g., suspicious and may be associated with packed malware).

[0084] In an example implementation of heuristics / rules for the import table checking component 414, the following heuristics may be used to identify suspicious Windows PE files / formats and / or anomalous import tables of Microsoft Windows PE files.

[0085] pe_sa_last_exec_sect: The last section of the PE has execution permission.

[0086] Pe_sa_first_write_sect: The first section of PE has write permission.

[0087] pe_sa_abnl_ep_addr: Unusual entry point address, for example: outside the file.

[0088] pe_sa_abnl_IAT: Anomalous import table format. This is an example of heuristics / rules for detecting anomalous import tables.

[0089] pe_sa_abnl_sect_entropy: Entropy anomaly of section.

[0090] pe_sa_ol_entropy: Calculates the entropy of superposition as ML features.

[0091] pe_sa_zero_size_sect: Counts the number of zero-size sections as ML features.

[0092] pe_sa_mem_wx_sect: Counts the number of sections with write / execute attribute as an ML feature.

[0093] pe_sa_err_delay_imp_dir: Whether there was an error during the parsing of delayed import directories into ML features. This is another example of heuristics / rules for detecting anomalous import tables.

[0094] pe_sa_err_imp_dir: Whether there was an error during the parsing of the import directory. This is another example of a heuristic / rule for detecting anomalous import tables.

[0095] pe_sa_err_parsing_imp_table: Whether there was an error during the parsing of the lazy import table. This is another example of a heuristic / rule for detecting anomalous import tables.

[0096] Referring to the packer filter 410, the packer filter also includes an overlay check component 416. The overlay check component determines whether the sample includes an overlay and whether the overlay is suspicious / likely to be associated with a malicious packer. An overlay generally refers to data at the end of a Windows PE file and is not defined by the file header. Three example features for checking for overlays include the following: (1) the presence of an overlay; (2) the size of the overlay (e.g., to determine whether the overlay size is abnormally large or small); and (3) the entropy of the overlay (e.g., an overlay entropy below 4 is plain text; an overlay entropy between 4 and 5 is executable; an overlay entropy between 6 and 7 is packed code; and an overlay entropy greater than 7 is encrypted data).

[0097] Referring to simulator 420, the simulator component provides an instrumented environment for simulating the first N instructions (e.g., the first 100 instructions, 500 instructions, 1000 instructions, etc.) at the entry point of a given sample comprising executable code (e.g., a Microsoft Windows PE file or other executable file format that can be similarly simulated). In an example experiment (e.g., as described below with respect to Figure 5A and Figure 5B As described above, the simulator component is configured to simulate the first 100 instructions at the entry point of a Microsoft Windows PE sample file. The simulation environment is instrumented to monitor the activities associated with the sample during simulation in order to extract various types of features that can then be used to cluster the packaged samples, as will now be described below.

[0098] Referring to simulator 420, the simulator includes an opcode feature component 422. The opcode feature component generates a feature vector for a predetermined opcode. In an example implementation of an opcode feature component for analyzing a Microsoft Windows PE file, a set of 112 different opcodes are selected as features, and the remaining opcodes are grouped into a single feature (e.g., there are approximately 1,500 opcodes in an x86 computing platform, and a subset of 112 opcodes is selected based on a simulation analysis of 9 common malware packer families, where these 112 opcodes are most commonly observed during the simulation of these 9 common malware packer families, and the remaining opcodes are simply counted as an all-inclusive "other opcode" feature value in the opcode feature vector). Thus, the opcode feature vector includes a count of each of these predetermined opcodes observed during the above-mentioned simulation analysis (e.g., no operation (NOP) instructions can be removed from such simulation analysis). These opcode features can then be used during a clustering operation (430).

[0099] A list of example opcode signatures for an x86 computing platform (eg, opcodes observed when executed during simulation analysis) is provided below.

[0100] instr_list=['adc',

[0101] 'add',

[0102] 'and',

[0103] 'bnd ret',

[0104] 'bsf',

[0105] 'bsr',

[0106] 'bswap',

[0107] 'bt',

[0108] 'btr',

[0109] 'bts',

[0110] 'call',

[0111] 'cbw',

[0112] 'clc',

[0113] 'cld',

[0114] 'cmc',

[0115] 'cmova','cmp',

[0116] 'cpuid','cwde','dec',

[0117] 'div',

[0118] 'enter','fadd',

[0119] 'fild',

[0120] 'fistp',

[0121] 'fld',

[0122] 'fldcw','fnclex','fninit','fnop','fnstcw','fstp',

[0123] 'fsub',

[0124] 'imul','inc',

[0125] 'int3',

[0126] 'ja',

[0127] 'jae',

[0128] 'jb',

[0129] 'jbe',

[0130] 'yes',

[0131] 'jg',

[0132] 'jge',

[0133] 'jl',

[0134] 'light',

[0135] 'jmp',

[0136] 'which',

[0137] 'who',

[0138] jnp,

[0139] jns,

[0140] 'five',

[0141] 'jp',

[0142] ‘jrcxz’,

[0143] 'js',

[0144] 'war',

[0145] 'word',

[0146] 'leave',

[0147] add lock,

[0148] lock cmpxchg,

[0149] lodsb,

[0150] loadsd,

[0151] loop,

[0152] mov,

[0153] movapd,

[0154] movsb,

[0155] movsd,

[0156] 'movsx',

[0157] movsxd,

[0158] 'movzx',

[0159] 'neg',

[0160] 'nop',#<--this should be removed'not',

[0161] 'or',

[0162] 'pop',

[0163] 'popfq',

[0164] 'push',

[0165] 'pushf',

[0166] 'pushfq',

[0167] 'rcl',

[0168] 'rcr',

[0169] 'rep movsb',

[0170] 'rep movsd',

[0171] 'rep stosd',

[0172] 'ret',

[0173] 'rol',

[0174] 'ror',

[0175] 'sal',

[0176] 'sar',

[0177] 'sbb',

[0178] 'scasb',

[0179] 'seta',

[0180] 'setbe',

[0181] 'sete',

[0182] 'set',

[0183] 'setne',

[0184] 'shl',

[0185] 'shld',

[0186] 'shr',

[0187] 'shrd',

[0188] 'sidt',

[0189] 'sldt',

[0190] 'stc',

[0191] 'stosb',

[0192] 'stosd',

[0193] 'str',

[0194] 'sub',

[0195] 'test',

[0196] 'verr',

[0197] 'wait',

[0198] 'xchg',

[0199] 'xor']

[0200] Referring to simulator 420, the simulator also includes a PE format feature component 424. The PE format feature component extracts various predetermined features associated with Microsoft Windows PE files determined during simulator analysis of the sample. These PE format features can then be used during clustering operations (430). Examples of PE format features include features related to the PE format structure, entropy, entry points, and size of the format (e.g., pe_sa_last_exec_sect, pe_sa_first_write_sect, pe_sa_abnl_ep_addr, pe_sa_abnl_sect_entropy, pe_sa_zero_size_sect, and pe_sa_mem_wx_sect).

[0201] Referring to simulator 420, the simulator also includes an API signature component 426. The API signature component extracts various predetermined APIs that are called during simulator analysis of the sample (e.g., API calls that are generally associated with virtual memory attacks, etc.). These API signatures can then be used during clustering operations (430). In an example embodiment, the simulator can be implemented using a publicly available binary simulation framework, such as available at https: / / github.com / qilingframework / qiling.

[0202] A list of example APIs (eg, API characteristics) for an x86 computing platform (eg, APIs observed when called during simulation analysis) is provided below.

[0203] 'CharNextA'

[0204] 'CharNextW'

[0205] 'CreateDirectoryA'

[0206] 'CreateFileA'

[0207] 'CreateWindowExA'

[0208] 'DecodePointer'

[0209] 'EncodePointer'

[0210] 'EnterCriticalSection'

[0211] 'ExitProcess'

[0212] 'FlsAlloc'

[0213] 'FlsSetValue'

[0214] 'GetCPInfo'

[0215] 'GetCommandLineA'

[0216] 'GetCommandLineW'

[0217] 'GetCurrentProcessId'

[0218] 'GetCurrentThreadId'

[0219] 'GetEnvironmentVariableA'

[0220] 'GetKeyboardType'

[0221] 'GetLastError'

[0222] 'GetLocaleInfoA'

[0223] 'GetMessageA'

[0224] 'GetModuleFileNameA'

[0225] 'GetModuleHandleA'

[0226] 'GetModuleHandleW'

[0227] 'GetProcAddress'

[0228] 'GetProcessHeap'

[0229] 'GetStartupInfoA'

[0230] 'GetStartupInfoW'

[0231] 'GetSystemDirectoryA'

[0232] 'GetSystemDirectoryW'

[0233] 'GetSystemTimeAsFileTime'

[0234] 'GetTempPathA'

[0235] 'GetThreadLocale'

[0236] 'GetTickCount'

[0237] 'GetVersion'

[0238] 'GetVersionExA'

[0239] 'GetVersionExW'

[0240] 'GetWindowsDirectoryA'

[0241] 'HeapAlloc'

[0242] 'HeapCreate'

[0243] 'HeapFree'

[0244] 'HeapSetInformation'

[0245] 'HeapSize'

[0246] 'InitCommonControls'

[0247] 'InitCommonControlsEx'

[0248] 'InitializeCriticalSection'

[0249] 'InitializeCriticalSectionAndSpinCount''InitializeCriticalSectionEx'

[0250] 'InterlockedCompareExchange'

[0251] 'InterlockedExchange'

[0252] 'InterlockedIncrement'

[0253] 'IsBadReadPtr'

[0254] 'IsDBCSLeadByte'

[0255] 'IsProcessorFeaturePresent'

[0256] 'LeaveCriticalSection'

[0257] 'LoadCursorA'

[0258] 'LoadIconA'

[0259] 'LoadLibraryA'

[0260] 'LoadLibraryExA'

[0261] 'LoadLibraryExW'

[0262] 'LoadLibraryW'

[0263] 'LocalAlloc'

[0264] 'MessageBoxA'

[0265] 'OleInitialize'

[0266] 'QueryPerformanceCounter'

[0267] 'RegOpenKeyExA'

[0268] 'RegisterClassExA'

[0269] 'SHGetFileInfoA'

[0270] 'SHGetFileInfoW'

[0271] 'SetDefaultDllDirectories'

[0272] 'SetDllDirectoryW'

[0273] 'SetErrorMode'

[0274] 'SetThreadLocale'

[0275] 'SetUnhandledExceptionFilter'

[0276] 'ShowWindow'

[0277] 'ThunRTMain'

[0278] 'TlsAlloc'

[0279] 'TlsGetValue'

[0280] 'TlsSetValue'

[0281] 'UpdateWindow'

[0282] 'VerSetConditionMask'

[0283] 'VerifyVersionInfoA'

[0284] 'VirtualAlloc'

[0285] 'VirtualProtect'

[0286] 'WSAStartup'

[0287] '_EH_prolog'

[0288] '__getmainargs'

[0289] '__p__commode'

[0290] '__p__fmode'

[0291] '__set_app_type'

[0292] '_controlfp'

[0293] '_initterm'

[0294] '_ismbblead'

[0295] '_lock'

[0296] '_lopen'

[0297] 'lstrcpyA'

[0298] 'lstrcpynA'

[0299] 'lstrcpynW'

[0300] 'malloc'

[0301] 'wsprintfA'

[0302] Referring to the cluster generator 430, the cluster generator component receives features extracted from the simulator 420 during simulation analysis. The cluster generator utilizes the features to cluster the packaged samples into families, such as Figure 4A As shown. In an example embodiment, density-based spatial clustering of applications with noise (DBScan) can be used to cluster the packaged samples based on the feature distance perspective (e.g., publicly / commercially available implementations of DBScan can be used, such as available at https: / / scikit-learn.org / stable / , see also https: / / scikit-learn.org / stable / modules / generated / sklearn.cluster.DBSCAN.html, and / or another clustering algorithm can be similarly used to cluster the packaged samples based on the extracted features, such as k-means clustering, mean shift clustering, HDBSCAN clustering, etc.).

[0303] In an experiment based on a sample input set of approximately 10,000 PE files, approximately 5,900 of these samples were determined to be (likely) packed using the packer filter. Clustering of the 5,900 (likely) packed samples based on their extracted features was performed using DBScan and generated 53 distinct packer clusters. It should be noted that the results also include previously unknown / custom packers that have not been previously identified by security vendors (e.g., not included in VirusTotal or other vendor data for known packers). Furthermore, in-depth analysis of these packer clusters revealed interesting common and unique features associated with the relevant packers analyzed during this experiment.

[0304] Thus, the generated clustering operation output providing these resulting packer clusters can then be further analyzed to automatically extract unique signatures to effectively and efficiently identify each packer family (e.g., because such packer families typically have interesting and unique characteristics). These signatures can then be used to provide malware detection using the data device (102) and / or the cloud-based security service (122).

[0305] Furthermore, the above-described techniques for automatically detecting unknown packers can be similarly implemented to provide new inline malware packer detection solutions, such as the following. Figure 4B as described.

[0306] Figure 4B 4 illustrates a portion of an example embodiment of an inline packer detector for automatically detecting unknown packers in accordance with some embodiments. In an example implementation, the inline packer detector 450 is implemented as a component of the malware analysis module 112 and is executed on the data device 102 (e.g., as Figure 1 shown).

[0307] Reference Figure 4B , new sample input 452 is received at the inline packetizer detector. The new sample is analyzed using packet filter 410, which can be as described above with respect to Figure 4A The implementation is similarly described. If the sample is determined to be (likely) packed, then the sample is further analyzed using the known packer cluster checker 460 (eg, if the sample is not determined to be (likely) packed, then no further analysis is performed using the inline packer detector).

[0308] Referring to the known packer cluster checker 460, the known packer cluster checker may receive periodic clustering data results from the security platform 122 (e.g., using the packer detector 154, such as described above with respect to Figure 1 and Figure 4A similarly described).

[0309] If the known packer cluster checker determines that the sample matches an existing known packer cluster, the resulting output is then sent to a cloud security solution (e.g., such as Figure 1For example, the cloud security solution may utilize the result output to provide further analysis and further update the known packer cluster dataset, which may then be periodically distributed to an inline packer detection solution, such as implemented on the data device 102 (e.g., a data device having an inline packer detector component and a subscription to receive periodically updated known packer cluster information from the cloud security solution).

[0310] If the known packager cluster checker determines that the sample does not match an existing known packager cluster, then the sample is provided to the simulator 430, which may be as described above with respect to Figure 4A The features extracted during the simulation analysis are stored for clustering, as shown in 480. The stored features can be used to perform further clustering (e.g., performed locally using the data device 102 and / or provided to a cloud security solution for execution using the security platform 122, such as described above with respect to Figure 1 and Figure 4A The updated clustering results may then be utilized to determine whether the sample is associated with a known packer cluster.

[0311] The inline packer detector can generate a malware packer ruling (450) based on the results of the sample processed using the inline packer detector. The data device (102) can then perform an action based on a policy (e.g., a security policy) in response to the malware packer ruling. For example, the data device can be configured to block access and / or storage of the sample (e.g., prevent an endpoint device from receiving, storing, opening, and / or executing the sample) if the sample is determined to be associated with a known malware packer. Other example actions can include logging the sample determined to be associated with a known malware packer, blocking / discarding the sample, alerting an endpoint user and / or network / security administrator that the sample is determined to be associated with a known malware packer, isolating the endpoint device associated with the sample, identifying a source IP address, URL, etc. associated with the sample as malicious (or potentially malicious), and / or various other actions that can also be performed based on a policy.

[0312] Thus, the disclosed techniques for automatically detecting unknown packers can be implemented to be performed using inline malware detection, such as on a data device 102 (e.g., and / or on endpoints, such as client devices 104, 106, and 108, using a security agent executing on the protected endpoints), and can also be performed as a cloud-based security service, such as using a security platform 122, as described herein.

[0313] Various example use cases for automatically detecting unknown packers will now be described.

[0314] Example use case for automatic detection of unknown packagers

[0315] Figure 5A and Figure 5B An example packer cluster determined based on experimental results for automatic detection of unknown packers according to some embodiments is illustrated.

[0316] Reference Figure 5A , based on the experimental results, a mysterious encrypted packer cluster for automatically detecting unknown packers is discovered. As shown, the malware packer performs various malicious operations, such as shown in 502, presents an unpacking process as shown in 504 (e.g., a similar unpacking process is displayed at the beginning), and displays various behaviors summarized as 506 (e.g., using similar junk instruction tricks, such as NOP instructions and meaningless call and jump (jmp) operations). The malware packer has not been previously identified by existing security solutions for detecting malware (e.g., VirusTotal has not previously identified the malware packer, and there is no existing packer signature for the previously unknown malware packer).

[0317] Reference Figure 5B , based on the experimental results, a Themida variant packer cluster for automatically detecting unknown packers is discovered. As shown, the malware packer performs various malicious operations, such as shown at 552, uses the same anti-debugging mechanism at the beginning, as shown at 554 (e.g., includes the same call graph at the beginning, and uses Int3 operations to capture debuggers), and exhibits various behaviors as summarized at 556. The malware packer has not been previously identified by existing security solutions for detecting malware (e.g., VirusTotal has not previously identified the malware packer, and there is no existing packer signature for the previously unknown malware packer).

[0318] Additional example procedures for the disclosed technique for automatically detecting unknown packers will now be described.

[0319] Example procedure for automatically detecting unknown packers

[0320] Figure 6 is a flow chart of a process for automatically detecting unknown packagers according to some embodiments. Figure 6 The illustrated process 600 is performed by a security platform and techniques similar to those described above, including the security platform and techniques described above with respect to Figures 1 to 4B In one embodiment, process 600 is performed by Figure 1 The data device 102 described above Figure 1 The described security platform 122 (e.g., as a cloud-based security service), virtual appliances (e.g., Palo Alto Networks' VM Series virtualized next-generation firewalls, CN Series container next-generation firewalls, and / or other commercially available virtual-based or container-based firewalls that can be similarly implemented and configured to perform the disclosed techniques), SDN security solutions, cloud security solutions services, and / or combinations or hybrid implementations of the foregoing items described herein.

[0321] At 602, samples are received for performing malware packer detection analysis. For example, the data device 102 and / or the security device 122 may receive one or more input samples for performing malware packer detection analysis, as described above with respect to Figures 1 to 4B Similar to what is described.

[0322] At 604, a packer filter is executed to determine whether each sample is packed. For example, the packer filter can be executed using the entropy calculator component 412, the import table check component 414, and / or the overlay check component 416 of the packer filter 410, as described above with respect to Figure 4A and Figure 4B Similar to what is described.

[0323] At 606, a simulator is executed to simulate each packaged sample. For example, the simulator may be executed to extract various features for clustering based on the extracted features, as described above with respect to Figure 4A and Figure 4B Similar to what is described.

[0324] At 608, the packaged samples are clustered based on the extracted features. For example, a cluster generator can be used to cluster the packaged samples based on the extracted features, as described above with respect to Figure 4A and Figure 4B Also as similarly described above, the newly identified malware packer (e.g., and / or malware packer family) can then be further analyzed for generating, for example, a new signature for automatically detecting such newly identified malware packer (e.g., and / or malware packer family).

[0325] Figure 7 is a flow chart of an inline process for automatically detecting unknown packagers according to some embodiments. Figure 7 The illustrated process 700 is performed by a security platform and techniques similar to those described above, including the above with respect to Figures 1 to 4B In one embodiment, process 700 is performed as described above with respect to Figure 1 The data device 102 described above Figure 1 The described security platform 122 (e.g., as a cloud-based security service), virtual appliances (e.g., Palo Alto Networks' VM Series virtualized next-generation firewalls, CN Series container next-generation firewalls, and / or other commercially available virtual-based or container-based firewalls that can be similarly implemented and configured to perform the disclosed techniques), SDN security solutions, cloud security services, and / or combinations or hybrid implementations of the foregoing items described herein.

[0326] At 702, samples are received for performing inline malware packer detection analysis. For example, data device 102 (e.g., and / or security device 122, as such inline malware packer detection analysis may similarly be performed by a cloud security service) may receive one or more samples for performing inline malware packer detection analysis, as described above with respect to Figures 1 to 4B Similar to what is described.

[0327] At 704, a packer filter is executed to determine whether each sample is packed. For example, the packer filter can be executed using the entropy calculator component 412, the import table check component 414, and / or the overlay check component 416 of the packer filter 410, as described above with respect to Figure 4A and Figure 4B Similar to what is described.

[0328] At 706, the packing sample is compared to a known malware packer cluster to determine whether the sample is associated with a known malware packer. For example, the known malware packer cluster comparison may be performed using the known packer cluster checker 460, as described above with respect to Figure 4B Similar to what is described.

[0329] At 708, a response action based on the malware packer determination is performed. Figure 4B Similarly described, malware packers may be detected based on the verdict / result of an inline packer detection analysis. In an example embodiment, an inline packer detector may be based on using an inline packer detector (e.g., Figure 4B The data device (102) can then, in response to the malware packer determination, detect the malware packer based on a policy (e.g., a malware packer policy, which can be stored in a file such as a database). Figure 2BFor example, a data device may be configured to block access to and / or storage of a sample (e.g., prevent an endpoint device from receiving, storing, opening, and / or executing the sample) if the sample is determined to be associated with a known malware packer, block / discard the sample, alert an endpoint user and / or network / security administrator that the sample is determined to be associated with a known malware packer, isolate an endpoint device associated with the sample, identify a source IP address, URL, etc. associated with the sample as malicious (or potentially malicious), and / or various other actions that may also be performed based on a policy.

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

Claims

1. A system comprising: A processor configured to: Receive multiple samples for malware packer detection analysis; executing a packer filter to determine whether each sample in the plurality of samples is packed; simulating each sample of the plurality of samples to extract a plurality of features; as well as Clustering the packaged samples based on the extracted features; as well as A memory is coupled to the processor and configured to provide instructions to the processor.

2. The system of claim 1, wherein one or more samples of the plurality of samples comprise Microsoft Windows PE files.

3. The system of claim 1, wherein the plurality of features comprises an opcode feature. The system of claim 1 , wherein the plurality of characteristics comprises file format characteristics.

5. The system of claim 1, wherein the plurality of features comprises application programming interface (API) features.

6. The system of claim 1, wherein the plurality of features comprises at least two of: an opcode feature, a file format feature, and an application programming interface (API) feature.

7. The system of claim 1, wherein the plurality of features comprises opcode features, file format features, and application programming interface (API) features.

8. The system of claim 1, wherein detecting previously unknown malware packers is performed using a security platform of a cloud service.

9. A method comprising: Receive multiple samples for malware packer detection analysis; executing a packer filter to determine whether each sample in the plurality of samples is packed; simulating each sample of the plurality of samples to extract a plurality of features; as well as The packaged samples are clustered based on the extracted features.

10. The method of claim 9, wherein one or more samples of the plurality of samples comprise Microsoft Windows PE files. The method of claim 9 , wherein the plurality of features comprises an opcode feature.

12. The method of claim 9, wherein the plurality of characteristics comprises file format characteristics.

13. The method of claim 9, wherein the plurality of features comprises application programming interface (API) features.

14. The method of claim 9, wherein the plurality of features comprises at least two of: an opcode feature, a file format feature, and an application programming interface (API) feature.

15. The method of claim 9, wherein the plurality of features include opcode features, file format features, and application programming interface (API) features.

16. The method of claim 9, wherein detecting previously unknown malware packers is performed using a security platform of a cloud service.

17. A computer program product embodied as a non-transitory computer readable medium and comprising computer instructions for: Receive multiple samples for malware packer detection analysis; executing a packer filter to determine whether each sample in the plurality of samples is packed; simulating each sample of the plurality of samples to extract a plurality of features; as well as The packaged samples are clustered based on the extracted features.

18. The computer program product of claim 17, wherein one or more samples of the plurality of samples comprise Microsoft Windows PE files.

19. The computer program product of claim 17, wherein the plurality of features comprises at least one or more of: an opcode feature, a file format feature, and an application programming interface (API) feature.

20. The computer program product of claim 17, wherein detecting previously unknown malware packers is performed using a security platform of a cloud service.

21. A system comprising: A processor configured to: Receive samples for inline malware packer detection analysis; executing a packer filter to determine whether the sample is packed; Comparing with known packer clusters to determine if the sample is associated with a known malware packer; as well as Execute response actions based on malware packer determination; as well as A memory is coupled to the processor and configured to provide instructions to the processor.

Images