Identifying .NET Malware with “Unmanaged Imphash”

Abstract

The present application discloses a method, system, and computer system for detecting malicious files. The method includes receiving a sample including a .NET file, obtaining an import API function name based at least in part on a .NET header of the .NET file, determining a hash of a list of unmanaged import API function names, and determining whether the sample is malware based at least in part on the hash of the list of unmanaged import API function names.

Description

Background Art

[0001] Malicious individuals attempt to compromise computer systems in a variety of ways. As an example, such individuals may embed or otherwise include malicious software ("malware") in an email attachment and transmit or cause the malware to be transmitted to an unsuspecting user. When executed, the malware damages the victim's computer. Some types of malware instruct the compromised computer to communicate with a remote host. For example, malware can turn a compromised computer into a "bot" in a "botnet," receiving instructions from and / or reporting data to a command and control (C&C) server under the control of the malicious individual. One way to mitigate the damage caused by malware is for security companies (or other appropriate entities) to attempt to identify the malware and prevent it from reaching / executing on end-user computers. Another approach is to attempt to prevent the compromised computer from communicating with the C&C server. Unfortunately, malware authors are using increasingly sophisticated techniques to obfuscate the workings of their software. As an example, some types of malware use Domain Name System (DNS) queries to exfiltrate data. Therefore, there is a continuous need for improved technologies to detect malware and prevent its harm. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0003] Figure 1 is a block diagram of an environment in which malicious files are detected or suspected, according to various embodiments.

[0004] Figure 2 is a block diagram of a system for detecting malicious files according to various embodiments.

[0005] Figure 3A is an illustration of the ImplMap table of the .NET header of a sample .NET file.

[0006] Figure 3B is an illustration of the ModuleRef table of a sample .NET file.

[0007] Figure 3C is an illustration of the ImplMap table of the .NET header of a sample .NET file.

[0008] Figure 3D is a diagram of the MethodDef table of a sample .NET file.

[0009] Figure 3E is an illustration of the ModuleRef table of a sample .NET file.

[0010] Figure 3F is an illustration of the import table of a sample .NET file.

[0011] Figure 3G is a diagram of the MethodDef table of a sample .NET file.

[0012] Figure 4 is a flow chart of a method for detecting malicious files according to various embodiments.

[0013] Figure 5 is a flow chart of a method for determining whether a file is malicious, according to various embodiments.

[0014] Figure 6 is a flow chart of a method for detecting malicious files according to various embodiments.

[0015] Figure 7A is a flow chart of a method for detecting malicious files according to various embodiments.

[0016] Figure 7B is a flow chart of a method for detecting malicious files according to various embodiments.

[0017] Figure 8 is a flow chart of a method for detecting malicious files according to various embodiments.

[0018] Figure 9 is a flow chart of a method for detecting malicious files according to various embodiments.

[0019] Figure 10 is a flow chart of a method for detecting malicious files according to various embodiments.

[0020] Figure 11 is a flow chart of a method for detecting malicious files according to various embodiments. DETAILED DESCRIPTION

[0021] The present invention can be implemented in many ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer-readable storage medium; and / or a processor, such as a processor configured to execute instructions stored on and / or provided by a memory coupled to the processor. In this specification, these embodiments or any other form that the invention may take may be referred to as techniques. In general, the order of 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 that is 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 that are configured to process data (such as computer program instructions).

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

[0023] As used herein, a security entity is a network node (e.g., a device) that implements one or more security policies with respect to information such as network traffic, files, etc. As an example, a security entity may be a firewall. As another example, a security entity may be implemented as a router, a switch, a DNS resolver, a computer, a tablet, a laptop, a smartphone, etc. Various other devices may be implemented as security entities. As another example, a security entity may be implemented as an application running on a device, such as an anti-malware application.

[0024] As used herein, malware refers to an application that engages in behavior, whether covertly or not (and whether or not illegal), that the user would not / would not approve of if fully aware of it. Examples of malware include Trojan horses, viruses, hacking programs, spyware, hacking tools, keyloggers, and the like. One example of malware is a desktop application that collects the end user's location and reports it to a remote server (but does not provide the user with location-based services, such as mapping services). Another example of malware is a malicious Android application package (.apk) file that appears to the end user as a free game but secretly sends SMS premium messages (e.g., each costing $10), thereby increasing the end user's phone bill. Another example of malware is an Apple iOS flashlight application that secretly collects the user's contacts and sends those contacts to spammers. The techniques described herein can also be used to detect / thwart other forms of malware (e.g., ransomware). Furthermore, while the malware signatures described herein are generated for malicious applications, the techniques described herein can also be used in various embodiments to generate profiles for other types of applications (e.g., adware profiles, commodity software profiles, etc.).

[0025] As used herein, unmanaged code or unmanaged functions refers to imported Win32 API functions, rather than regular .NET code, which is referred to as "managed code." For example, such unmanaged code or unmanaged functions are generally not reflected / included in the PE header of a .NET file; rather, such unmanaged code or unmanaged functions are imported via the .NET header of the .NET file.

[0026] According to the related art, a machine learning model is used to identify malware. The machine learning model according to the related art is trained / developed using a portable executable (PE) structure based on features such as imports, headers, and sections. The machine learning model uses such imports, headers, and sections to distinguish between malware and benign files. However, the PE file structure of files based on the Microsoft Windows PE installer looks very similar between malicious files and benign files. Therefore, using the PE file structure of the Microsoft Windows PE installer to detect malware is not very reliable because it is extremely difficult to distinguish between malicious files and benign files based on such a PE file structure. For example, using the PE file structure to detect malicious files of the Microsoft Windows PE installer file will result in a higher false positive rate and a poor detection rate. An example of a Microsoft Windows PE installer file used for benign purposes is the Microsoft Windows Nullsoft Scriptable InstallSystem (NSIS) installer, which is commonly used by legitimate products and corporate environments. Every machine learning model trained to analyze the PE structure to distinguish between malicious Microsoft Windows PE installer files and benign Microsoft Windows PE installer files will not be able to accurately detect malicious files.

[0027] A system, method, and / or apparatus for detecting malicious files is disclosed. The system includes one or more processors and a memory coupled to the one or more processors and configured to provide instructions to the one or more processors. The one or more processors are configured to receive a sample including a .NET file, obtain an import API function name based at least in part on a .NET header of the .NET file, determine a hash of a list of unmanaged import API function names, and determine whether the sample is malware based at least in part on the hash of the list of unmanaged import API function names.

[0028] According to various embodiments, a system for detecting malicious files is implemented by one or more servers. The one or more servers can provide services to one or more clients and / or security entities. For example, the one or more servers detect malicious files or determine / evaluate whether a file is malicious and provide an indication of whether the file is malicious to one or more clients and / or security entities. In response to a determination that a file is malicious and / or in conjunction with an update to a mapping of files to indications of whether files are malicious (e.g., an update to a blacklist that includes (one or more) identifiers associated with (one or more) malicious files), the one or more servers provide an indication that the file is malicious to the security entity. As another example, the one or more servers determine whether a file is malicious in response to a request from a client or security entity for use in evaluating whether the file is malicious, and the one or more servers provide the results of such a determination.

[0029] According to various embodiments, a system for detecting malicious files is implemented by a security entity. For example, the system for detecting malicious files is implemented by a firewall. As another example, the system for detecting malicious files is implemented by an application, such as an anti-malware application running on a device (e.g., a computer, laptop, mobile phone, etc.). According to various embodiments, the security entity receives a .NET file, obtains a .NET header from the .NET file, and determines whether the .NET file is malicious based at least in part on the .NET header of the .NET file. In response to determining that the .NET file is malicious, the security entity applies one or more security policies to the .NET file. In response to determining that the .NET file is not malicious (e.g., the .NET file is benign), the security entity processes the .NET file as non-malicious traffic. In some embodiments, the security entity determines whether the file is malicious based at least in part on determining (e.g., obtaining) an import API function name based at least in part on the .NET header of the .NET file, determining (e.g., calculating) a hash of a list of unmanaged import API function names, and determining whether the hash of the list of unmanaged import API function names corresponding to the .NET file matches a hash associated with a file deemed malicious. For example, the security entity performs a lookup against a mapping of hashes (e.g., hashes of unmanaged imported API function names) to malicious files to determine whether the mapping includes a matching hash (e.g., the mapping includes a record of a file where the hash of the unmanaged imported API function name matches the calculated hash of the .NET file).

[0030] Portable executable (PE) files are typically encoded to import functions from external libraries in order to interact with various OS components. Related art methods for detecting malware use import sequences, hashing them to obtain a hash value, and comparing the hash value to a list of known blocks called "import table hashes" (imphash). Related art methods for detecting malware imports obtain imported API function names and corresponding library names from the analyzed file's PE header. However, determining API function names and corresponding library names based on the PE header and using these to detect malware is not ideal for .NET files, as nearly all .NET PE files have similar import tables. As an example, most .NET assemblies have a single import function in the PE header called "_CorExeMain" (EXE) or "_CorDllMain" (DLL). Generally speaking, only a small fraction of .NET assemblies have more imports in the PE header. Such .NET files are typically created using Visual C++ and the C++ / CLI extension. The import functions included in the PE header are generally determined by the .NET compiler and are not affected by the code itself. This behavior occurs because .NET code is not compiled into native assembly, but rather into an intermediate language or intermediate bytecode (MSIL), which is then executed by the .NET runtime.

[0031] Therefore, using imported functions extracted from the PE header of a .NET file does not provide accurate detection of malware. However, various .NET malware families still need to interact directly with the win32 API, such as injecting code into other processes. Such code can be injected into other processes from .NET, but the win32 functions that do so will not be reflected in the import table of the PE header of the .NET file. Instead, code injection functions are generally composed (or imported) via the .NET header of the .NET file. The .NET header is a header included in the .NET file (for example, in addition to the PE header). For example, the .NET header is different / has differences from the PE header of the .NET file. The .NET file includes both the PE header and the .NET header. The .NET header generally includes data streams and tables, which include various information related to the .NET assembly. One such data stream included in the .NET header is called "#Strings" and includes a list of strings used in the file. The list included in the #Strings stream also includes the name (one or more) of any unmanaged win32API functions used. Additionally, one of the tables included in the .NET header is called "ImplMap" and includes various information about any imported unmanaged functions.

[0032] Various embodiments parse the .NET header of a .NET file, extract unmanaged imports (e.g., unmanaged functions, libraries, etc.) from one or more fields in the .NET header, and determine whether the .NET file is malicious based at least in part on the extracted unmanaged imports. In some embodiments, the system determines a list of unmanaged imports corresponding to the .NET file (e.g., extracted from (one or more) fields in the .NET header) and determines (e.g., calculates) a hash of the unmanaged import list. The hash of the unmanaged import list can be determined based on a predefined hash function. Examples of hash functions include a SHA-256 hash function, an MD5 hash function, a SHA-1 hash function, and the like. Various other hash functions can be implemented. As used herein, unmanaged imphash refers to a value obtained by determining a hash of an unmanaged import list (e.g., unmanaged imports extracted from (one or more) fields in the .NET header).

[0033] According to various embodiments, information included in the .NET header of a .NET file is used in conjunction with determining whether a file is malicious. In some embodiments, the system uses information included in the ImplMap table and information included in the strings of the "#Strings" data stream to determine a set of unmanaged function <-> library name pairs. The system can determine a list of unmanaged imported functions associated with the .NET file (e.g., imported via the .NET header). In some embodiments, the system determines a hash of the list associated with the unmanaged imported functions of the .NET file. For example, the system determines an unmanaged Imphash corresponding to the .NET file. The unmanaged Imphash can be used to determine whether a file is malicious. For example, the system can query a list of files considered malicious (e.g., a blacklist) to determine whether the list includes a record whose unmanaged Imphash matches the unmanaged Imphash determined for the .NET file.

[0034] According to various embodiments, a system analyzes a .NET file in a sandbox environment. For example, the system parses the .NET file within the sandbox environment and extracts information from the .NET header. The system can be implemented by a virtual machine (VM) operating in the sandbox environment.

[0035] In some embodiments, the system receives data from a third-party service such as ) receives historical information related to the maliciousness of files (e.g., a historical data set of malicious files and a historical data set of benign files). The third-party service can provide a set of files that are considered malicious and a set of files that are considered benign. As an example, the third-party service can analyze the file and provide an indication of whether the file is malicious or benign and / or a score indicating the likelihood that the file is malicious. The third-party service can provide an unmanaged Imphash corresponding to the files included in the historical data set (e.g., a blacklist of files, a whitelist of files, etc.), or the list can include an indication of whether the historical unmanaged Imphash is malicious. The system can receive updates from the third-party service (e.g., at predefined intervals, when updates are available, etc.), such as benign or malicious files with new identifications, corrections to previous misclassifications, etc. In some embodiments, whether the files in the historical data set correspond to an indication of a social score (such as a community-based score or rating (e.g., a reputation score)) indicating that the file is malicious or is likely to be malicious.

[0036] According to various embodiments, a security entity and / or a network node (e.g., a client, a device, etc.) processes a file based at least in part on an indication that the file is malicious and / or that the file matches a file indicated as malicious. In response to receiving an indication that a file (e.g., a sample is malicious), the security network and / or the network node may update a mapping of the file to an indication of whether the corresponding file is malicious and / or a blacklist of files. In some embodiments, the security entity and / or the network node receives a signature associated with a file (e.g., a sample considered to be malicious), and the security entity and / or the network node stores the signature of the file for use in conjunction with detecting whether a file, such as obtained via a network service, is malicious (e.g., based at least in part on comparing a signature generated for the file with signatures of files included in a file blacklist). As an example, the signature may be a hash. In some embodiments, the signature of a file is an unmanaged Imphash corresponding to such a file.

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

[0038] 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.

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

[0040] Application firewalls can also perform application layer filtering (e.g., application layer filtering firewalls or second generation firewalls, which work at the application layer 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 be transmitted over standard ports (e.g., an application firewall can generally be used to identify unauthorized / out-of-policy protocols that attempt to sneak through using non-standard ports for that protocol).

[0041] A stateful firewall can also perform stateful packet inspection, where each packet is examined within the context of a series of packets associated with the packet flow being transmitted by the network. This firewall technique is generally referred to as stateful packet inspection because it maintains a record of all connections passing through the firewall and can 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 a connection itself can be one of the criteria for triggering a rule within a policy.

[0042] Advanced or next-generation firewalls can perform stateless and stateful packet filtering as well as application layer filtering, as discussed above. Next-generation firewalls can also perform additional firewall technologies. For example, certain newer firewalls, sometimes referred to as advanced or next-generation firewalls, can also identify users and content (e.g., next-generation firewalls). In particular, certain 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 (e.g., Palo Alto Networks' PA Series firewalls). For example, Palo Alto Networks' next-generation firewalls enable enterprises to use a variety of identification technologies to identify and control applications, users, and content, rather than just ports, IP addresses, and packets, such as the following: APP-ID for accurate application identification, User ID for user identification (e.g., by user or user group), and Content ID for real-time content scanning (e.g., controlling web surfing and limiting data and file transfers). These identification technologies allow enterprises to securely enable application usage using business-relevant concepts, rather than following the traditional approach provided by traditional port-blocking firewalls. Furthermore, specialized hardware for next-generation firewalls (e.g., implemented as dedicated appliances) generally provides higher performance levels for application inspection than software executed on general-purpose hardware (e.g., such as the security appliances offered by Palo Alto Networks, which use dedicated function-specific processing tightly integrated with a single-pass software engine to maximize network throughput while minimizing latency).

[0043] Advanced or next generation firewalls can also be implemented using virtualized firewalls. Examples of such next generation firewalls are commercially available from Palo Alto Networks (e.g., Palo Alto Networks' VM-Series firewalls, which support a variety of commercial virtualization environments, including, for example, ESXi TM and NSX TM 、 NetScaler SDX TM , KVM / OpenStack (Centos / RHEL, ) and Amazon Web Services (AWS). For example, virtualized firewalls can support similar or identical next-generation firewall and advanced threat prevention features available in physical form factor appliances, allowing enterprises to securely enable applications flowing 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 to dynamically feed that context into security policies, eliminating policy lag that can occur when VMs change.

[0044] The system improves detection of malicious files. Furthermore, the system further improves the handling of network traffic by preventing malicious files from crossing a network (such as between nodes within a network) (or improving prevention thereof) or preventing malicious files from entering the network. The system identifies .NET files that are considered malicious or potentially malicious, such as based on the .NET file's .NET header. Related art detection techniques using the structure of a file's PE header may be insufficient / inaccurate for files with similar structures / profiles between malicious and benign files. Furthermore, because .NET files are compiled into an intermediate language, classifying files as malicious / benign using machine learning classifiers or manually written YARA rules can be difficult. YARA is a tool designed to (but not limited to) assist malware researchers in identifying and classifying malware samples. YARA rules are used to classify and identify malware samples by creating descriptions of malware families based on text or binary patterns. Furthermore, the system can provide accurate and low-latency updates to security entities (e.g., endpoints, firewalls, etc.) to enforce one or more security policies (e.g., pre-defined and / or customer-specific security policies) with respect to traffic that includes malicious files (e.g., malicious .NET files). Thus, the system prevents malicious traffic (eg, files) from spreading to nodes within the network.

[0045] Figure 1 is a block diagram of an environment in which malicious files are detected or suspected according to various embodiments. In the illustrated example, client devices 104 to 108 are a laptop, desktop computer, and tablet (respectively) residing in an enterprise network 110 (belonging to "Acme Company"). Data appliance 102 is configured to implement policies (e.g., security policies) regarding communications between client devices (such as client devices 104 and 106) and nodes outside of enterprise network 110 (e.g., reachable via external network 118). Examples of such policies include policies that manage traffic shaping, quality of service, and traffic routing. Other examples of policies include security policies, such as security 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 appliance 102 is also configured to implement policies with respect to traffic residing within (or entering) enterprise network 110.

[0046] The techniques described herein can be used in conjunction with various platforms (e.g., desktop computers, mobile devices, gaming platforms, embedded systems, etc.) and / or various types of applications (e.g., Android .apk files, iOS applications, Windows PE files, Adobe Acrobat PDF files, Microsoft Windows PE installers, etc.). Figure 1In the example environment shown in FIG, client devices 104 through 108 are a laptop computer, a desktop computer, and a tablet (respectively) residing within enterprise network 140. Client device 120 is a laptop computer residing outside enterprise network 110.

[0047] The data appliance 102 can be configured to work in conjunction with a remote security platform 140. The security platform 140 can provide various services, including performing static and dynamic analysis on malware samples, providing signature lists of known malicious files to a data appliance (such as the data appliance 102) as part of a subscription, detecting malicious files (e.g., on-demand detection, or based on periodic updates of mappings of files to indications of whether the files are malicious or benign), providing a probability that a file is malicious or benign, providing / updating a whitelist of files that are considered benign, providing / updating files that are considered malicious, identifying malicious domains, detecting malicious files, predicting whether a file is malicious, and providing an indication that a file is malicious (or benign). In various embodiments, the analysis results (and additional information related to applications, domains, etc.) are stored in a database 160. In various embodiments, the security platform 140 includes one or more dedicated commercially available hardware servers (e.g., having (one or more) multi-core processors, 32G+ of RAM, (one or more) gigabit network interface adapters, and (one or more) hard drives) running a typical server-class operating system (e.g., Linux). The security platform 140 can be implemented across a scalable infrastructure including multiple such servers, solid-state drives, and / or other applicable high-performance hardware. The security platform 140 can include several distributed components, including components provided by one or more third parties. For example, part or all of the security platform 140 can be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3). Further, as with the data appliance 102, whenever the security platform 140 is referred to as performing a task such as storing data or processing data, it is understood that a subcomponent or multiple subcomponents of the security platform 140 (whether alone or in conjunction with third-party components) can collaborate to perform the task. As an example, the security platform 140 can optionally perform static / dynamic analysis in conjunction with one or more virtual machine (VM) servers. An example of a VM 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 commercially available virtualization software such as VMware ESXi, Citrix XenServer, or Microsoft Hyper-V. In some embodiments, the VM server is omitted. Furthermore, the virtual machine server may be under the control of the same entity that manages security platform 140, but may also be provided by a third party. As an example, the virtual machine server may rely on EC2, where the rest of security platform 140 is provided by dedicated hardware owned and under the control of the operator of security platform 140.

[0048] According to various embodiments, the security platform 140 includes a DNS tunneling detector 138 and / or a malicious file detector 170. The malicious file detector 170 is used in conjunction with determining whether a file (e.g., a .NET file) is malicious. In response to receiving a sample, the malicious file detector 170 analyzes the file and determines whether the file is malicious. For example, the malicious file detector 170 determines whether the unmanaged imphash corresponding to the analyzed file matches a file included in a historical dataset (e.g., a list of files considered malicious, a list of files considered benign, etc.). In some embodiments, the malicious file detector 170 receives a sample including a .NET file, obtains imported API function names based at least in part on a .NET header of the .NET file, determines a hash of the list of unmanaged imported API function names (the unmanaged imphash), and determines whether the sample is malware based at least in part on the hash of the list of unmanaged imported API function names. In some embodiments, the malicious file detector 170 includes one or more of a .NET file parser 172, an unmanaged function extractor 174, a prediction engine 176, and / or a cache 178.

[0049] The .NET file parser 172 is used in conjunction with obtaining information related to a sample (such as a .NET file). In some embodiments, the .NET file parser 172 obtains a .NET header and / or information from a .NET header of a .NET file. The .NET file parser 172 obtains one or more data streams included in the .NET header and / or one or more tables included in (or referenced by) the .NET header. For example, the .NET file parser 172 obtains a #Strings stream included in the .NET header. As another example, the .NET file parser 172 obtains an ImplMap from a .NET file (e.g., from a .NET header). In some embodiments, the .NET file parser 172 determines a set of imported functions (e.g., imported API function names) that are imported into the .NET file.

[0050] The unmanaged function extractor 174 is used in conjunction with determining (e.g., obtaining) a set of unmanaged imported functions imported into a .NET file. For example, the unmanaged function extractor 174 determines the set of unmanaged imported functions based on the set of imported functions (e.g., imported API function names) imported into the .NET file. According to various embodiments, the unmanaged function extractor 174 uses information included in (or referenced by) the .NET header to determine unmanaged code or unmanaged functions (e.g., unmanaged functions and corresponding libraries). In some embodiments, the unmanaged function extractor 174 determines a set of used unmanaged Win32 API functions imported into the .NET file. The unmanaged function extractor 174 provides the set of unmanaged imported functions (or names of unmanaged functions) and / or corresponding libraries imported into the .NET file to the prediction engine 176.

[0051] The prediction engine 176 is used to determine whether a file (e.g., a .NET file) is malicious. The prediction engine 176 uses information included in the .NET header in conjunction with determining whether the corresponding .NET file is malicious. For example, the prediction engine 176 obtains the unmanaged import functions (or the names of the unmanaged functions) and / or the set of corresponding libraries imported into the .NET file from the unmanaged function extractor 174. In some embodiments, the prediction engine 176 determines a hash (e.g., a hash value) of the unmanaged import functions (or the names of the unmanaged functions) and / or the set of corresponding libraries imported into the .NET file. For example, the prediction engine 176 calculates the unmanaged Imphash corresponding to the .NET file. The prediction engine 176 determines a list of the unmanaged import functions (or the names of the unmanaged functions) and / or the set of corresponding libraries imported into the .NET file, and determines a hash of such a list. The list of the set of unmanaged import functions and / or corresponding libraries is determined according to a predetermined order. For example, the ordering of the unmanaged imported functions and / or corresponding libraries corresponds to the order in which the unmanaged functions are included in the elements of the .NET header (e.g., the order in which the unmanaged functions are included in the #Strings stream and / or table included in or referenced by the .NET table). Various other orders in which the unmanaged functions are added to the list (or the list is arranged) can be implemented. The prediction engine 176 formats the list and / or unmanaged functions (e.g., unmanaged function names and / or corresponding libraries) according to a predetermined format. Examples of the predetermined format include (i) lowercase alphanumeric strings, (ii) removal of file extensions, (iii) removal of library extensions (e.g., removal of .dll from the corresponding library name), (iv) appending the unmanaged function name and the corresponding library, and (v) use of a predefined separator between the unmanaged function name and the corresponding library. In some embodiments, the prediction engine 176 appends the function name (e.g., the unmanaged function name) to the corresponding library and separates the function name from the corresponding library by a dot or period (e.g., "."). In response to determining the string by appending the function name and library (eg, with a predefined separator, such as “.”), the prediction engine 176 adds such an entry to the list of the set of unmanaged imported functions and / or corresponding libraries.

[0052] According to various embodiments, prediction engine 176 determines a hash relative to a list of unmanaged import functions and / or corresponding libraries. Various hash functions may be used in conjunction with determining the hash. Examples of hash functions include a SHA-256 hash function, an MD5 hash function, a SHA-1 hash function, and the like. Various other hash functions may be implemented. Prediction engine 176 uses the hash function to determine the unmanaged import hash corresponding to the .NET file.

[0053] According to various embodiments, the prediction engine 176 uses information obtained from the .NET header of the .NET file to determine whether the .NET file is malicious. In some embodiments, the prediction engine 176 uses an unmanaged imphash corresponding to the .NET file in conjunction with determining whether the .NET file is malicious. As an example, in response to determining the unmanaged imphash corresponding to the .NET file, the prediction engine 176 determines whether the unmanaged imphash matches the unmanaged imphash of a file that is considered malicious. As an example, in response to determining the unmanaged imphash corresponding to the .NET file, the prediction engine 176 determines whether the unmanaged imphash matches the unmanaged imphash of a file that is considered benign. In some embodiments, the malicious file detector 170 (e.g., the prediction engine 176) determines whether information related to a particular file (e.g., the unmanaged imphash corresponding to the analyzed .NET file) is included in a data set of historical files and historical information associated with a historical data set that indicates whether the particular file is malicious (e.g., a third-party service such as VirusTotal). TM In response to determining that information related to a particular file is not included in or available in the dataset of historical files and historical information, malicious file detector 170 may deem the file to be benign (e.g., deem the file to be not malicious). Examples of historical information associated with historical files indicating whether a particular file is malicious correspond to (VT) score. If the VT score of a particular file is greater than 0, the particular file is considered malicious by the third-party service. In some embodiments, the historical information associated with the historical file indicating whether the particular file is malicious corresponds to a social score indicating that the file is malicious or is likely to be malicious, such as a community-based score or rating (e.g., a reputation score). The historical information (e.g., from a third-party service, a community-based score, etc.) indicates whether other vendors or cybersecurity organizations consider the particular file to be malicious.

[0054] In some embodiments, malicious file detector 170 (e.g., prediction engine 176) determines that a received file is newly analyzed (e.g., the file is not in historical information / datasets, is not on a whitelist or blacklist, etc.). In response to security platform 140 receiving a file from a security entity (e.g., a firewall) or an endpoint within the network, malicious file detector 170 (e.g., script extractor module 172) can detect that the file is newly analyzed. For example, malicious file detector 170 determines that the file is newly analyzed concurrently with the security platform 140 or malicious file detector 170 receiving the file. As another example, malicious file detector 170 (e.g., prediction engine 176) determines that a file is newly analyzed based on a predefined schedule (e.g., daily, weekly, monthly, etc.), such as in conjunction with a batch process. In response to determining that a file has been received that has not been analyzed with respect to whether such a file is malicious (e.g., the system does not include historical information with respect to such a file), malicious file detector 170 determines whether to use a .NET header associated with the file in conjunction with determining whether the file is malicious (e.g., such as in response to determining that the file is a .NET file), and malicious file detector 170 uses a .NET file parser to parse and / or extract information related to the .NET file from the .NET header of the .NET file, etc. In some embodiments, .NET file parser 172 extracts information from the .NET header in a sandbox environment of the system.

[0055] According to various embodiments, in response to the prediction engine 176 determining that a file is malicious, the system sends an indication that the file is malicious to a security entity (or endpoint, such as a client). For example, the malicious file detector 170 sends an indication that the file is malicious to a security entity (e.g., a firewall) or a network node (e.g., a client). The indication that the file is malicious can correspond to an update to a blacklist of files (e.g., corresponding to malicious files) such as if the file is considered malicious or an update to a whitelist of files (e.g., corresponding to non-malicious files) such as if the file is considered benign. In some embodiments, in conjunction with the indication that the file is malicious or benign, the malicious file detector 170 sends a hash or signature corresponding to the file. The security entity or endpoint can calculate a hash or signature for the file and perform a lookup (e.g., query a whitelist and / or blacklist) for a mapping of the hash / signature to an indication of whether the file is malicious / benign. In some embodiments, the hash or signature uniquely identifies the file.

[0056] Cache 178 stores information related to files. In some embodiments, cache 178 stores a mapping of an indication of whether a file is malicious (or potentially malicious) to a specific file, or a mapping of an indication of whether a file is malicious (or potentially malicious) to a hash or signature corresponding to the file. Cache 178 can store additional information related to a file collection, such as script information for files in the file collection, hashes or signatures corresponding to files in the file collection, other unique identifiers corresponding to files in the file collection, executable files called by the files, Bitcoin wallets called by the files, pointers included in the files, etc.

[0057] Return to Figure 1 , assume that a malicious individual (using system 120) has created malware 130. The malicious individual hopes that a client device (such as client device 104) will execute a copy of malware 130, thereby compromising the client device and causing the client device to become a bot in a botnet. The compromised client device can then be instructed to perform tasks (e.g., cryptocurrency mining or engaging in a denial of service attack) and / or report information to an external entity (e.g., associated with such tasks, exfiltrating sensitive corporate data, etc.), such as a command and control (C&C) server 150, and receive instructions from the C&C server 150 (if applicable).

[0058] Although malware 130 may attempt to cause a compromised client device to communicate directly with C&C server 150 (e.g., by causing the client to send an email to C&C server 150), such an overt communication attempt may be marked as suspicious / harmful and blocked (e.g., by data appliance 102). Malware authors are increasingly using a technique referred to herein as DNS tunneling, rather than allowing such direct communication to occur. DNS is a protocol that converts human-friendly URLs (such as paloaltonetworks.com) into machine-friendly IP addresses (such as 199.167.52.137). DNS tunneling utilizes the DNS protocol to tunnel malware and other data through a client-server model. In an example attachment, a malicious file (e.g., malware) is sent as an attachment to a message such as an email or instant message. After selecting the attachment, the malware program can be installed at the client device. In an example attack, the attacker registers a domain, such as badsite.com. The domain name server points to the attacker's server, where the tunneling malware program is installed. The attacker infects the computer. Because DNS requests are traditionally allowed to move in and out of security appliances, infected computers are allowed to send queries to a DNS resolver (e.g., to kj32hkjqfeuo32ylhkjshdflu23.badsite.com, where the subdomain portion of the query encodes information for consumption by the C&C server). A DNS resolver is a server that relays requests for IP addresses to root and top-level domain servers. The DNS resolver routes the query to the attacker's C&C server, which has a tunneling program installed. A connection is now established between the victim and the attacker through the DNS resolver. This tunnel can be used to exfiltrate data or for other malicious purposes.

[0059] Detecting and preventing DNS tunneling attacks is difficult for a variety of reasons. Many legitimate services (e.g., content delivery networks, web hosting companies, etc.) legitimately use the subdomain portion of a domain name to encode information to help support the use of those legitimate services. The encoding patterns used by such legitimate services can vary significantly between providers, and benign subdomains may be visually indistinguishable from malicious subdomains. A second reason is that, unlike other fields (e.g., computer research), which have large amounts of both known benign training data and known malicious training data, the training data for DNS queries is heavily skewed (e.g., there are millions of examples of benign root domains and very few malicious examples). Despite this difficulty, and using the techniques described herein, malicious domains can be efficiently and proactively detected (e.g., shortly after domain registration), and security policies can be implemented with respect to malicious files within or entering a network to block such malicious files or otherwise warn users or administrators of the malicious files (e.g., sending notifications, providing prompts to users, etc.).

[0060] Figure 1 The environment shown in FIG1 includes three Domain Name System (DNS) servers (122-126). As shown, DNS server 122 is under the control of ACME (for use by computing assets located within network 110), while DNS server 124 is publicly accessible (and can also be used by computing assets located within network 110 and other devices such as those located within other networks (e.g., networks 114 and 116)). DNS server 126 is publicly accessible but is under the control of the malicious operator of C&C server 150. Enterprise DNS server 122 is configured to resolve enterprise domain names into IP addresses and is further configured to communicate with one or more external DNS servers (e.g., DNS servers 124 and 126) to resolve domain names (if applicable).

[0061] As mentioned above, in order to connect to a legitimate domain (e.g., www.example.com, depicted as site 128), a client device (such as client device 104) will need to resolve the domain into a corresponding Internet Protocol (IP) address. One way such resolution can occur is for client device 104 to forward a request to DNS servers 122 and / or 124 to resolve the domain. In response to receiving a valid IP address for the requested domain name, client device 104 can use the IP address to connect to website 128. Similarly, in order to connect to malicious C&C server 150, client device 104 will need to resolve the domain "kj32hkjqfeuo32ylhkjshdflu23.badsite.com" into a corresponding Internet Protocol (IP) address. In this example, malicious DNS server 126 is authoritative for *.badsite.com, and client device 104's request will be forwarded (e.g.) to DNS server 126 for resolution, ultimately allowing C&C server 150 to receive data from client device 104.

[0062] The data appliance 102 is configured to implement policies regarding communications between client devices (such as client devices 104 and 106) and nodes outside the enterprise network 140 (e.g., reachable via external network 118). Examples of such policies include policies governing traffic shaping, quality of service, and traffic routing. Other examples of policies include security policies, such as security policies 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, the data appliance 102 is also configured to implement policies with respect to traffic residing within the enterprise network 140.

[0063] In various embodiments, the data appliance 102 includes a DNS module 134 configured to facilitate determining whether a client device (e.g., client devices 104-108) is attempting to engage in malicious DNS tunneling, and / or to prevent (e.g., by client devices 104-108) connecting to a malicious DNS server. The DNS module 134 may be integrated into the appliance 102 (e.g., Figure 1 ), and in various embodiments can also operate as a standalone appliance. Figure 1Like the other components shown in , the DNS module 134 can be provided by the same entity that provides the appliance 102 (or security platform 140), and can also be provided by a third party (e.g., a third party different from the provider of the appliance 102 or security platform 140). Further, in addition to preventing connections to malicious DNS servers, the DNS module 134 can also take other actions, such as personalized logging of tunneling attempts made by clients (indicating that a given client is compromised and should be quarantined or otherwise investigated by an administrator).

[0064] In various embodiments, when a client device (e.g., client device 104) attempts to resolve a domain, DNS module 134 uses the domain as a query to security platform 140. This query can be performed concurrently with the resolution of the domain (e.g., concurrently with requests sent to DNS servers 122, 124, and / or 126 and security platform 140). As one example, DNS module 134 can send a query (e.g., in JSON format) to front end 142 of security platform 140 via a REST API. Using a process described in more detail below, security platform 140 will determine (e.g., using DNS tunneling detector 138) whether the queried domain indicates a malicious DNS tunneling attempt and provide a result back to DNS module 134 (e.g., "Malicious DNS Tunneling" or "Not Tunneling").

[0065] In various embodiments, when a client device (e.g., client device 104) attempts to open a file, such as an attachment via email, received via instant messaging, or otherwise exchanged over a network, or when the client device receives such a file, the DNS module 134 uses the file (or a calculated hash or signature or other unique identifier, etc.) as a query to the security platform 140. This query can be performed concurrently with the receipt of the file, or in response to a request from a user to scan the file. As an example, the data appliance 102 can send a query (e.g., in JSON format) to the front end 142 of the security platform 140 via a REST API. Using the process described in more detail below, the security platform 140 will determine (e.g., using the malicious file detector 170) whether the queried file is a malicious file (or is likely to be a malicious file) and provide the result back to the DNS module 134 (e.g., "malicious DNS tunneling" or "non-tunneling").

[0066] In various embodiments, the DNS tunneling detector 138 (whether implemented on the security platform 140, on the data appliance 102, or on some other appropriate location / combination of locations) uses a two-pronged approach in identifying malicious DNS tunneling. The first approach uses an anomaly detector 146 (e.g., implemented using python) to build a real-time profile set of DNS traffic for a root domain (156). The second approach uses signature generation and matching (also referred to herein as similarity detection, and implemented, for example, using Go). The two approaches are complementary. The anomaly detector serves as a general detector that can identify previously unknown tunneling traffic. However, the anomaly detector may need to observe multiple DNS queries before making a detection. To block the first DNS tunneling packet, the similarity detector 144 complements the anomaly detector 146 and extracts a signature from the detected tunneling traffic that can be used to identify situations where an attacker has registered a new malicious tunneling root domain, but has done so using tools / malware similar to the detected root domain.

[0067] When the data appliance 102 receives DNS queries (e.g., from the DNS module 134), the data appliance 102 provides them to the security platform 140, which performs both anomaly detection and similarity detection, respectively. In various embodiments, if either detector flags a domain, then the domain (e.g., provided in a query received by the security platform 140) is classified as a malicious DNS tunneling root domain.

[0068] The DNS tunneling detector 138 maintains a set of fully qualified domain names (FQDNs) per appliance (from which it receives data), grouped by their root domain (in Figure 1 156). (Although grouping by root domain is generally described in the specification, it is understood that the techniques described herein can be extended to any level of domains.) In various embodiments, information about received queries for a given domain is retained in the profile for a fixed amount of time (e.g., a sliding time window of ten minutes).

[0069] As an example, DNS query information received from data appliance 102 for various foo.com sites is grouped (into a domain profile for the root domain foo.com) as: G(foo.com) = [mail.foo.com, coolstuff.foo.com, domain1234.foo.com]. A second root domain would have a second profile with similar applicable information (e.g., G(baddomain.com) = [lskjdf23r.baddomain.com, kj235hdssd233.baddomain.com]. Each root domain (e.g., foo.com or baddomain.com) is modeled using a set of characteristics unique to malicious DNS tunneling, such that even though benign DNS patterns vary (e.g., k2jh3i8y35.legitimatesite.com, xxx888222000444.otherlegitimatesite.com), they are highly unlikely to be misclassified as malicious tunneling. The following are example features that may be extracted (eg, into a feature vector) as features for a given group of domains (ie, a shared root domain).

[0070] In some embodiments, the malicious file detector 170 provides an indication of whether a file is malicious to a security entity such as the data appliance 102. For example, in response to determining that the file is malicious, the malicious file detector 170 sends an indication that the file is malicious to the data appliance 102, and the data appliance may then implement one or more security policies based at least in part on the indication that the file is malicious. The one or more security policies may include isolating the file, deleting the file, warning or prompting the user of the maliciousness of the file before the user opens / executes the file, and the like. As another example, in response to determining that the file is malicious, the malicious file detector 170 provides the security entity with an update to a mapping of a file (or a hash, signature, unmanaged Imphash, or other unique identifier corresponding to the file) to an indication of whether the corresponding file is malicious or an update to a blacklist of malicious files (e.g., identifying file domains) or a whitelist of benign files (e.g., identifying files that are not considered malicious).

[0071] Figure 2 is a block diagram of a system for detecting malicious files according to various embodiments. According to various embodiments, system 200 is a system that combines Figure 1 In various embodiments, the system 200 is implemented as a malicious file detector 170. Figure 4 The process of 400 Figure 5 The process of 500 Figure 6 The process of 600 Figure 7A The process of 700 Figure 7B The process of 750 Figure 8 The process of 800 Figure 9 The process of 900 Figure 10 Course 1000 and / or Figure 11 The system 200 may be implemented in one or more servers, security entities such as firewalls, and / or endpoints.

[0072] System 200 can be implemented by one or more devices (such as servers). System 200 can be implemented at various locations on a network. In some embodiments, system 200 implements Figure 1 The malicious file detector 170 of the system 100 is provided. As an example, the system 200 is deployed as a service, such as a network service (e.g., the system 200 determines whether a file is malicious and provides such determination as a service). The service can be provided by one or more servers (e.g., the system 200 or the malicious file detector is deployed on a remote server, which monitors or receives files transmitted within or outside the network, such as via email attachments, instant messages, etc., and determines whether the files are malicious, and sends / pushes notifications or updates related to the files, such as an indication of whether the files are malicious). As another example, the malicious file detector is deployed on a firewall.

[0073] In the illustrated example, the system 200 implements one or more modules in conjunction with predicting whether a file (e.g., a newly received file) is malicious, determining the likelihood that the file is malicious, and / or providing a notification or indication of whether the file is malicious. The system 200 includes a communication interface 205, one or more processors 210, a storage device 215, and / or a memory 220. The one or more processors 210 include one or more of a communication module 225, a .NET header extraction module 230, an unmanaged function extraction module 235, a list generation module 240, a prediction module 245, and / or a notification module 250.

[0074] In some embodiments, the system 200 includes a communication module 225. The system 200 uses the communication module 225 to communicate with various nodes or endpoints (e.g., client terminals, firewalls, DNS resolvers, data appliances, other security entities, etc.) or user systems such as administrator systems. For example, the communication module 225 provides information to be transmitted to the communication interface 205. As another example, the communication interface 205 provides information received by the system 200 to the communication module 225. The communication module 225 is configured to receive files to be analyzed, such as from network endpoints or nodes such as security entities (e.g., firewalls). The communication module 225 is configured to query (one or more) third-party services (e.g., services that expose information about files, such as third-party ratings or file malice assessments, community-based ratings, assessments, or reputations related to files, blacklists of files, and / or whitelists of files, etc.) for information related to the files. For example, the system 200 uses the communication module 225 to query (one or more) third-party services. The communication module 225 is configured to receive one or more settings or configurations from the administrator. Examples of one or more settings or configurations include configuration of a process for determining whether a file is malicious, configuration of the process for determining whether a file is malicious, according to which information of a .NET file is to be organized / arranged in order to determine the format of an unmanaged imphash for a .NET file, a hash function used in conjunction with determining the unmanaged imphash for a file, information related to a whitelist of domains (e.g., domains that are not considered suspicious and for which services or attachments are permitted), and information related to a blacklist of domains (e.g., domains that are considered suspicious and for which services or attachments are restricted).

[0075] In some embodiments, the system 200 includes a .NET header extraction module 230. The system 200 uses the .NET header extraction module 230 in conjunction with determining whether to extract information related to a header of a file (e.g., from a header) and extracting information about the file (e.g., for analysis of whether the file is malicious). In some embodiments, the .NET header extraction module 230 receives a file to be analyzed, such as a file included as an attachment to an email, an instant message, or otherwise transmitted across a network or within or outside a network. In response to determining that the file is a .NET file, the .NET header extraction module 230 determines to perform extraction of information related to the header of the file. As an example, based on receiving an indication that the file corresponds to a .NET file, the .NET header extraction module 230 determines that the file is a .NET file. As another example, based at least in part on a determination that the file includes a .NET header, the .NET header extraction module 230 determines that the file is a .NET file. As another example, .NET header extraction module 230 determines that the file is a .NET file based at least in part on determining that a directory entry in the PE header has a non-zero value (e.g., system 200 examines the binary structure of the file and determines whether the value in the optional header value includes a non-zero value / position, and if so, determines that the file is a .NET file). As another example, .NET header extraction module 230 determines that the file is a .NET file based at least in part on examining whether the file imports a "_CorExeMain" or "_CorDllMain" function.

[0076] In some embodiments, the .NET header extraction module 230 obtains a .NET header and / or information from a .NET header of a .NET file. In response to determining that the file is a .NET file, the .NET header extraction module 230 obtains information related to the file's header (e.g., from the header). In some embodiments, the .NET header extraction module 230 determines the .NET header and obtains imported functions imported (or referenced) by the .NET header. For example, the .NET header extraction module 230 obtains imported API function names based at least in part on the .NET header of the .NET file. The .NET header extraction module 230 obtains one or more data streams included in the .NET header and / or one or more tables included in (or referenced by) the .NET header. For example, the .NET header extraction module 230 obtains a #Strings stream included in the .NET header. As another example, the .NET header extraction module 230 obtains an ImplMap from a .NET file (e.g., from a .NET header). The ImplMap may include various information about any imported unmanaged functions of the .NET file. In some embodiments, the .NET header extraction module 230 determines a set of imported functions (eg, imported API function names) that are imported into the .NET file.

[0077] According to various embodiments, in response to receiving a file to be analyzed to determine whether the file is malicious, system 200 places the file in a sandbox to be analyzed. In some embodiments, .NET header extraction module 230 extracts information related to (e.g., from) the header of the file. As an example, .NET header extraction module 230 extracts header information from a .NET header and / or a PE header of a .NET file in a sandbox. For example, system 200 invokes a sandbox for analysis of a particular file. As another example, system 200 utilizes a common sandbox for analysis of various files.

[0078] In some embodiments, system 200 includes an unmanaged function extraction module 235. System 200 uses unmanaged function extraction module 235 to determine (e.g., obtain) a set of unmanaged functions included in or referenced by a .NET file, such as a list of unmanaged functions imported via a .NET header in the .NET file. For example, unmanaged function extraction module 235 determines a set of unmanaged imported functions based on a set of imported functions (e.g., imported API function names) imported into the .NET file. According to various embodiments, unmanaged function extraction module 235 uses information included in (or referenced by) the .NET header to determine unmanaged code or unmanaged functions (e.g., unmanaged functions and corresponding libraries). In some embodiments, unmanaged function extraction module 235 determines a set of used unmanaged Win32 API functions imported into the .NET file. Unmanaged function extraction module 235 provides the set of unmanaged imported functions (or unmanaged function names) and / or corresponding libraries imported into the .NET file to list generation module 240 and / or prediction module 245.

[0079] In some embodiments, system 200 includes a list generation module 240. System 200 uses list generation module 240 to generate a list of unmanaged functions and / or corresponding libraries. In some embodiments, system 200 uses list generation module 240 to format a collection of unmanaged imported functions (or names of unmanaged functions) and / or corresponding libraries to be imported into a .NET file. List generation module 240 formats the list and / or unmanaged functions (e.g., unmanaged function names and / or corresponding libraries) according to a predetermined format. Examples of the predetermined format include (i) lowercase alphanumeric strings, (ii) removal of file extensions, (iii) removal of library extensions (e.g., removal of .dll from corresponding library names), (iv) appending unmanaged function names and corresponding libraries, and (v) use of a predefined separator between unmanaged function names and corresponding libraries. In some embodiments, list generation module 240 appends the function name (e.g., unmanaged function name) to the corresponding library and separates the function name from the corresponding library with a dot or period (e.g., "."). In response to determining the string by appending the function name and library (e.g., using a predefined separator, such as "."), list generation module 240 adds such an entry to the list of the set of unmanaged imported functions and / or corresponding libraries. According to various embodiments, in response to determining that no additional unmanaged functions and / or corresponding libraries are to be added to the list, list generation module 240 provides the list to prediction module 245.

[0080] In some embodiments, system 200 includes a prediction module 245. System 200 uses prediction module 245 to predict whether a file is malicious, or to predict the likelihood that a file is malicious. According to various embodiments, prediction module 245 determines whether a file is malicious based at least in part on information included in (or referenced by) a .NET header of the file. For example, prediction module 245 determines an unmanaged imphash corresponding to the file and determines whether the file is malicious based at least in part on the unmanaged imphash.

[0081] According to various embodiments, prediction module 245 determines a hash relative to the list of unmanaged import functions and / or corresponding libraries. Various hash functions may be used in conjunction with determining the hash. Examples of hash functions include SHA-256, MD5, SHA-1, and the like. Various other hash functions may be implemented. Prediction module 245 uses the hash function to determine the unmanaged import hash corresponding to the .NET file.

[0082] According to various embodiments, the prediction module 245 uses information obtained from the .NET header of the .NET file to determine whether the .NET file is malicious. In some embodiments, the prediction module 245 uses an unmanaged imphash corresponding to the .NET file in conjunction with determining whether the .NET file is malicious. As an example, in response to determining the unmanaged imphash corresponding to the .NET file, the prediction module 245 determines whether the unmanaged imphash matches an unmanaged imphash for a file that is considered malicious. As an example, in response to determining the unmanaged imphash corresponding to the .NET file, the prediction module 245 determines whether the unmanaged imphash matches an unmanaged imphash for a file that is considered benign. In some embodiments, the prediction module 245 determines whether information related to a particular file (e.g., an unmanaged imphash corresponding to the analyzed .NET file) is included in a dataset of historical files and historical information associated with a historical dataset that indicates whether the particular file is malicious (e.g., a third-party service such as VirusTotal). TM In response to determining that information related to a particular file is not included in or available in the dataset of historical files and historical information, prediction module 245 may deem the file to be benign (e.g., deem the file to be not malicious). Examples of historical information associated with historical files indicating whether a particular file is malicious correspond to (VT) score. If the VT score of a particular file is greater than 0, the particular file is considered malicious by the third-party service. In some embodiments, the historical information associated with the historical file indicating whether the particular file is malicious corresponds to a social score indicating that the file is malicious or is likely to be malicious, such as a community-based score or rating (e.g., a reputation score). The historical information (e.g., from a third-party service, a community-based score, etc.) indicates whether other vendors or cybersecurity organizations consider the particular file to be malicious.

[0083] The system 200 can determine (e.g., calculate) a hash or signature (e.g., an unmanaged imphash) corresponding to the file and perform a lookup against historical information (e.g., a whitelist, a blacklist, etc.). In some embodiments, the prediction module 245 corresponds to or is similar to the prediction engine 176. The system 200 (e.g., the prediction module 245) can query a third party (e.g., a third-party service) via the communication interface 205 for historical information related to the file (or a set of files or hashes / signatures of files previously deemed malicious or benign). The system 200 (e.g., the prediction module 245) can query the third party at predetermined intervals (e.g., a customer-specified interval, etc.). As an example, the prediction module 245 can query the third party daily (or daily during the work week) for registration information of newly analyzed files.

[0084] In some embodiments, the system 200 includes a notification module 250. The system 200 uses the notification module 250 to provide an indication of whether a file is malicious. For example, the notification module 250 obtains an indication of whether a file is malicious (or the likelihood that a file is malicious) from the prediction module 245, and provides an indication of whether the file is malicious to one or more security entities and / or one or more endpoints. As another example, the notification module 250 provides updates to a whitelist of files and / or a blacklist of files to one or more security entities (e.g., a firewall), nodes, or endpoints (e.g., a client terminal). According to various embodiments, the notification module 250 obtains a hash, signature, or other unique identifier associated with a file (e.g., an unmanaged Imphash corresponding to the file), and provides an indication of whether the file is malicious in combination with the hash, signature, or other unique identifier associated with the file.

[0085] According to various embodiments, the hash of the file corresponds to a hash using a predetermined hash function (e.g., an unmanaged Imphash using an MD5 hash function, an MD5 hash of the file, etc.). The security entity or endpoint can calculate a hash of a received file (e.g., a file attachment, etc.). The security entity or endpoint can determine whether the calculated hash corresponding to the file is included in a set, such as a whitelist of benign files and / or a blacklist of malicious files, etc. If the signature of the malware (e.g., the hash of the received file) is included in a set of signatures for malicious files (e.g., a blacklist of malicious files), the security entity or endpoint can prevent the malware from being transmitted to the endpoint (e.g., a client device) and / or prevent the malware from being opened or executed accordingly.

[0086] According to various embodiments, storage 215 includes one or more of file system data 260, hash data 262, and / or cache data 264. Storage 215 includes shared storage (eg, a network storage system) and / or database data and / or user activity data.

[0087] In some embodiments, file system data 260 includes a database, such as one or more data sets (e.g., one or more data sets of files and / or file attributes, mappings of indicators of maliciousness to files or hashes of files, unmanaged imphash, signatures, or other unique identifiers, mappings of indicators of benign files to files or hashes of files, signatures, or other unique identifiers, etc.). File system data 260 includes data such as historical information related to files (e.g., the maliciousness of files), a whitelist of files considered safe (e.g., not suspicious), a blacklist of files considered suspicious or malicious (e.g., files whose likelihood of being malicious is considered to exceed a predetermined / preset likelihood threshold), information associated with suspicious or malicious files, and the like.

[0088] Hash data 262 includes data associated with one or more files, such as hash values associated with one or more files. In some embodiments, hash data 262 includes an unmanaged imphash of a file (such as a file analyzed by system 200 to determine whether such a file is malicious) or a historical data set previously evaluated for maliciousness, such as by a third party. Hash data 262 includes a mapping of hash values (unmanaged imphash) to indications of maliciousness (e.g., corresponding indications of maliciousness or benignness, etc.). In some embodiments, hash data 262 includes relationships and associations between files or information associated with a file (e.g., scripts, attributes such as bytes, structures, etc.) and indications or likelihood that the file is malicious or benign. For example, hash data 262 includes a mapping of hash values (unmanaged imphash) to indications of maliciousness (e.g., corresponding indications of maliciousness or benignness, etc.).

[0089] Cache data 264 includes information related to a prediction of whether a file is malicious. As an example, prediction cache data 264 stores an indication of whether one or more files are malicious.

[0090] According to various embodiments, the memory 220 includes execution application data 270. The execution application data 270 includes data obtained or used in conjunction with an execution application (such as an application that performs a hash function or an application that extracts information from a file). In an embodiment, the application includes one or more applications that perform one or more of receiving and / or executing queries or tasks, generating reports and / or configurations in response to the executed queries or tasks, and / or providing information to a user in response to the queries or tasks. Other applications include any other suitable applications (e.g., index maintenance applications, communication applications, machine learning model applications, applications for detecting suspicious traffic, document preparation applications, report preparation applications, user interface applications, data analysis applications, anomaly detection applications, user authentication applications, security policy management / update applications, etc.).

[0091] Figure 3A is an illustration of the ImplMap table in the .NET header of a sample .NET file. Figure 3A The table 300 shown in FIG. 1 provides an ImplMap table for a 32-bit DLL sample. In some embodiments, the ImplMap table for the sample is obtained by inputting the 32-bit DLL sample into a debugger and / or a .NET assembly editor. An example of such a debugger and / or .NET assembly editor is dnSpy. Various other debuggers and / or .NET assembly editors may be implemented.

[0092] According to various embodiments, the system determines an index into the #Strings stream based at least in part on the ImplMap table. In some embodiments, the index into the #Strings stream corresponds to the ImportName table. The #Strings stream generally corresponds to an array of null-terminated strings where most of a .NET file's strings reside. The system uses a column labeled ImportName to determine an index into the #Strings stream. The name of a function can be determined using the index value from the ImportName column. In table 300, the name of the function corresponding to the value of ImportName is provided in the Information column.

[0093] In response to determining the index value according to the ImportName and / or function name of the imported function, the system determines the library name (e.g., DLL) of the corresponding library. In some embodiments, the system determines the library (e.g., library name) based at least in part on a ModuleRef table of a .NET file.

[0094] Figure 3B is an illustration of the ModuleRef table of a sample .NET file. Figure 3B The table 310 shown in FIG. Figure 3A Table 300 shows the ModuleRef table of the analyzed 32-bit DLL sample. In some embodiments, the ModuleRef table of the sample is obtained by inputting the 32-bit DLL sample into a debugger and / or a .NET assembly editor.

[0095] According to various embodiments, the system uses the index value of the ImportName field (e.g., column) from the ImplMap table as an index to determine the corresponding library (e.g., library name). The system uses the index value as a lookup in the Name column of table 310. For example, the Name column is an index into the #Strings stream. The Information column of the ModuleRef table includes an indication of the field. For example, the library name corresponding to the index value 0x18F3 in the Name column is kernel32.dll.

[0096] In conjunction with determining the unmanaged imphash corresponding to the .NET file, the system determines a list of unmanaged functions. The list of unmanaged functions is generated using a predetermined format or syntax. For example, the system obtains the library name corresponding to the imported function and removes the extension. The system determines whether the library has a ".dll" extension, and if so, the system removes the extension. As another example, the system formats the function name and the library name to convert any uppercase letters to lowercase letters. In some embodiments, the system builds a string that corresponds to a combination of the function name of the imported function (e.g., an unmanaged imported function) and the library name corresponding to the imported function. For example, the system builds the string in a manner that appends the library name to the function name, and a predefined delimiter (e.g., ".") is included between the library name and the function name. According to various embodiments, the system determines the string according to the format: <libraryname> . <functionname>The system then adds the string to a list of unmanaged imported functions (such as the list that identifies the unmanaged Imphash).

[0097] Use with Figure 3A Form 300 and Figure 3B In the example sample corresponding to Table 310, the list of library-function name pairs is: kernel32.createprocess, kernel32.getthreadcontext, kernel32.wow64getthreadcontext, kernel32.setthreadcontext, kernel32.wow64setthreadcontext, kernel32.readprocessmemory, kernel32.writeprocessmemory, ntdll.ntunmapviewofsection, kernel32.virtualallocex, kernel32.resumethread, kernel32.loadlibrary, kernel32.getprocaddress. The entries in the list can be separated by a predetermined delimiter, such as a comma, a semicolon, a colon, etc.

[0098] According to various embodiments, in response to determining a list of unmanaged imported functions for a .NET file, the system performs a hash of the list using a predetermined hash function (e.g., MD5, SHA1, SHA-256, etc.). Figure 3A Form 300 and Figure 3B The unmanaged imphash of the unmanaged imported function list of the sample analyzed in Table 310 is (using SHA-256 as the hash function): 4b386faf53783c4fd17de6c043fd31374302a4455456b4af3d78abd74c865ff8.

[0099] Figure 3C is an illustration of the ImplMap table in the .NET header of a sample .NET file. Figure 3C Table 320, shown in FIG, provides an ImplMap table for a 32-bit EXE sample. The 32-bit EXE is created using the Visual C++ compiler and the C++ / CLI extension. In some embodiments, the ImplMap table for the sample is obtained by inputting a 32-bit DLL sample into a debugger and / or a .NET assembly editor. An example of such a debugger and / or .NET assembly editor is dnSpy. Various other debuggers and / or .NET assembly editors may be implemented.

[0100] like Figure 3C As shown in FIG, the first three rows of table 320 have values included in the information column. Therefore, for the first three rows, a combination of Figure 3A Form 300 and Figure 3B The process of determining the function name and the corresponding library name (eg, determining the library-function name pair) is described in Table 310 of FIG. Figure 3C The remaining rows of the ImplMap table have null values or 0. Null or zero entries may be generated in the remaining rows because the corresponding functions are not used by the sample author, but are part of the runtime methods used internally by C++ / CLI. In some embodiments, the system determines the function name and library name based on the MethodDef table of the file. For example, the system uses the value included in the MethodForward column of the ImplMap table (e.g., Table 320) as an index into the MethodDef table. As an example, the MemberForward value is called the encoding index in the MethodDef table (e.g., the encoding index is defined in the .NET specification ECMA-335).

[0101] According to various embodiments, the system Figure 3C The remaining rows of the MethodForward column of the ImplMap table are obtained, the values obtained from the MethodForward rows are decoded, and the decoded values are used as indexes into the MethodDef table. For example, the value of row 4 from the MemberForward column is 0x99, which is decoded to correspond to 76. Therefore, 76 is used as an index value to determine information from the MethodDef table.

[0102] Figure 3D is a diagram of the MethodDef table of a sample .NET file. Figure 3D The table 330 shown in FIG. Figure 3C The MethodDef table of the sample analyzed in Table 320. In some embodiments, the MethodDef table of the sample is obtained by inputting the sample into a debugger and / or a .NET assembly editor.

[0103] Using the index value obtained from the MethodForward column of the ImplMap, the system determines the index of the #Strings stream. For example, the system uses the index value obtained from the MethodForward column of the ImplMap as a lookup in the Name column of the MethodDef table. The index value in the Name column corresponding to index 76 from the MethodForward column is 0x1831. As shown in Table 330, the Information column of the MethodDef table indicates that the function name is _amsg_exit.

[0104] Figure 3E is an illustration of the ModuleRef table of a sample .NET file. Figure 3E The table 340 shown in FIG. Figure 3C The ModuleRef table of the sample analyzed in Table 320. In some embodiments, the ModuleRef table of the sample is obtained by inputting the sample into a debugger and / or a .NET assembly editor.

[0105] According to various embodiments, the system determines the library name in response to determining the function name (e.g., the function name obtained from the MethodDef table). For example, the system determines the library name in the ImplMap table (e.g., Figure 3C In response to performing a lookup in the ModuleRef table (e.g., Table 340) using the index value 2 (e.g., from the ImportScope column of the ImplMap table), the system determines that the value in the Name column is also 0. Therefore, the system determines that the ModuleRef does not provide an indication of a library name.

[0106] According to various embodiments, in response to determining that ModuleRef does not provide an indication of the library name corresponding to the function, the system determines to use the function name retrieved from the MethodDef table and parses the import table in the PE header. The import table in the PE header includes all statically used functions of the file and the corresponding library names (DLLs) where the statically used functions reside. For example, the system uses a PE header parser to parse the import table in the PE header. An example of a PE header parser is pefile (e.g., an open source project called pefile), which is a PE header parser coded in Python. In some embodiments, the system performs a 1:1 comparison of the function name obtained from the MethodDef table and the function in the import table of the PE header. As an example, a file written in C++ (such as mixed assembly) can use so-called decorated names as function names in the import table. The process of creating these names is called name mangling. Such decorated function names are automatically created by the C++ compiler for each C++ function, except when the function is defined as extern "C".

[0107] Figure 3F is an illustration of the import table of a sample .NET file. Figure 3F In the example shown in , table 350 is an import table included in the PE header of a .NET file.

[0108] Figure 3G is an illustration of a MethodDef table for an example .NET file. In the example shown, table 360 is the MethodDef table for the .NET file. In some embodiments, in response to the system determining that a function name obtained from the MethodDef table matches a function name in an import table included in the PE header, the system obtains the corresponding library name from the import table. According to various embodiments, the system performs a lookup for matching function names between the MethodDef table and the import table included in the PE header to obtain the corresponding library name.

[0109] In conjunction with determining the unmanaged imphash corresponding to the .NET file, the system determines a list of unmanaged functions. The list of unmanaged functions is generated using a predetermined format or syntax. For example, the system obtains the library name corresponding to the imported function and removes the extension. The system determines whether the library has a ".dll" extension, and if so, the system removes the extension. As another example, the system formats the function name and the library name to convert any uppercase letters to lowercase letters. In some embodiments, the system builds a string that corresponds to a combination of the function name of the imported function (e.g., an unmanaged imported function) and the library name corresponding to the imported function. For example, the system builds the string in a manner that appends the library name to the function name, and a predefined delimiter (e.g., ".") is included between the library name and the function name. According to various embodiments, the system determines the string according to the format: <libraryname> . <functionname>The system then adds the string to a list of unmanaged imported functions (such as the list that identifies the unmanaged Imphash).

[0110] Use with Figure 3A Form 300 and Figure 3B In the example sample corresponding to Table 310, the list of library-function name pairs is: ntdll.zwallocatevirtualmemory, ntdll.zwfreevirtualmemory, ntdll.ldrgetprocedureaddress, msvcr80._amsg_exit, kernel32.sleep, . <crtimplementationdetails>.throwmoduleloadexception、. <crtimplementationdetails>.throwmoduleload exception、. <crtimplementationdetails>.dodlllanguagesupportvalidation、. <crtimplementationdetails>.thrownestedmoduleloadexception、.<crtimple mentationdetails>.registermoduleuninitializer、. <crtimplementationdetails>.docallbackindefaultdomain, msvcr80._cexit, msvcr80._encode_pointer, msvcr80._decode_pointer, msvcr80._encoded_null, msvcr80.__frameunwindfilter. The entries in the list can be separated by a predetermined delimiter, such as a comma, semicolon, colon, etc. Library-function pairs. <crtimplementationdetails>.ThrowModuleLoadException is included twice because the function is a so-called overloaded function. Such functions have the same name but differ in the type or number of parameters or the return value. Therefore, these are different functions.

[0111] According to various embodiments, in response to determining a list of unmanaged imported functions for a .NET file, the system performs a hash of the list using a predetermined hash function (e.g., MD5, SHA1, SHA-256, etc.). Figure 3A Form 300 and Figure 3B The unmanaged Imphash of the unmanaged imported function list of the sample analyzed in Table 310 is (using SHA-256 as the hash function): cd2f27b642a85c3f0c10db4e887d504d3b4c0882f9264994367c0c9b4ea7a537.

[0112] In some embodiments, the system transforms or formats a list according to a predefined format. For example, a list of library <-> function (<-> mappingflags) name pairs is transformed into a comma-delimited string. The system creates a comma-delimited string from a single list item (library <-> function pair). In response to transforming / creating the comma-delimited string from a single list item, the system determines (e.g., calculates a hash) relative to such string.

[0113] Figure 4 is a flow chart of a method for detecting malicious files according to various embodiments. In some embodiments, process 400 is at least partially performed by Figure 1 system 100 and / or Figure 2 In some embodiments, process 400 may be implemented by system 200. In some embodiments, process 400 may be implemented by one or more servers, such as in conjunction with providing a service to a network (e.g., a security entity and / or a network endpoint, such as a client device). In some embodiments, process 400 may be implemented by a security entity (e.g., a firewall), such as in conjunction with enforcing a security policy with respect to files transmitted across a network or within or outside a network. In some embodiments, process 400 may be implemented by a client device (e.g., a laptop, a smartphone, a personal computer, etc.), such as in conjunction with executing or opening a file (e.g., an email attachment).

[0114] At 410, a sample is received. In some embodiments, the system receives a sample (e.g., a .NET file) from a security entity (e.g., a firewall), an endpoint (e.g., a client device), or the like. For example, in response to determining that the file is attached to a communication such as an email or instant message, the security entity or endpoint provides (e.g., sends) the file to the system. The sample can be received in conjunction with a request to determine whether the file is malicious.

[0115] In the case where process 400 is implemented by a security entity, the sample can be received, such as in conjunction with routing traffic to an applicable network endpoint (e.g., a firewall obtains a sample from an email attachment to an email directed to a client device). In the case where process 400 is implemented by a client device, the sample can be received by an application or layer that monitors incoming / outgoing information. For example, a process (e.g., an application, an operating system process, etc.) can run in the background to monitor and obtain email attachments, files exchanged via instant messaging programs, etc.

[0116] At 420, the imported API function name is obtained using the sample's .NET header. In some embodiments, in response to receiving a sample and / or a request to evaluate whether a sample (e.g., a .NET file) is malicious, the system parses the sample to obtain information related to (e.g., included in) the sample's .NET header.

[0117] According to various embodiments, the system determines a .NET header and obtains imported functions imported (or referenced) by the .NET header. For example, the system obtains imported API function names based at least in part on the .NET header of the .NET file. The system obtains one or more data streams included in the .NET header and / or one or more tables included in (or referenced by) the .NET header. For example, the system obtains a #Strings stream included in the .NET header. As another example, the system obtains an ImplMap from a .NET file (e.g., from a .NET header). The ImplMap may include various information about any imported unmanaged functions of the .NET file. In some embodiments, the system determines a set of imported functions (e.g., imported API function names) imported into the .NET file.

[0118] In some embodiments, the system determines (e.g., obtains) a set of unmanaged functions included in or referenced by a .NET file, such as a list of unmanaged functions imported via a .NET header of the .NET file. For example, the system determines a set of unmanaged imported functions based on a set of imported functions (e.g., imported API function names) imported into the .NET file. The system uses information included in (or referenced by) the .NET header to determine unmanaged code or unmanaged functions (e.g., unmanaged functions and corresponding libraries). In some embodiments, the system determines a set of used unmanaged Win32 API functions imported into the .NET file.

[0119] At 430, a hash of the list of unmanaged imported API function names is determined. In some embodiments, in response to obtaining the imported API function names, the system determines (e.g., calculates) a hash of the list of unmanaged imported API function names. For example, the system calculates the unmanaged Imphash corresponding to the .NET file.

[0120] In conjunction with determining the hash of the list of unmanaged imported API function names, the system determines a list of unmanaged imported functions (or the names of unmanaged functions) and / or corresponding libraries that are imported into the .NET file, and determines the hash of such a list. The list of the collection of unmanaged imported functions and / or corresponding libraries is determined according to a predetermined order. For example, the ordering of the unmanaged imported functions and / or corresponding libraries corresponds to the order in which the unmanaged functions are included in the elements of the .NET header (e.g., the order in which the unmanaged functions are included in the #Strings stream and / or table included in or referenced by the .NET table). Various other orders in which unmanaged functions are added to the list (or the list is arranged) can be implemented. The system formats the list and / or unmanaged functions (e.g., unmanaged function names and / or corresponding libraries) according to a predetermined format or syntax. Examples of the predetermined format include (i) a lowercase alphanumeric string, (ii) removal of a file extension, (iii) removal of a library extension (e.g., removal of .dll from a corresponding library name), (iv) appending an unmanaged function name and a corresponding library, and (v) use of a predefined separator between the unmanaged function name and the corresponding library. In some embodiments, the system appends the function name (e.g., the unmanaged function name) to the corresponding library and separates the function name from the corresponding library by a dot or period (e.g., "."). In response to determining a string by appending the function name and library (e.g., using a predefined separator, such as ","), the system adds such an entry to a list of a set of unmanaged imported functions and / or corresponding libraries.

[0121] According to various embodiments, the system determines a hash relative to a list of unmanaged imported functions and / or corresponding libraries. Various hash functions may be used in conjunction with determining the hash. Examples of hash functions include a SHA-256 hash function, an MD5 hash function, a SHA-1 hash function, and the like. Various other hash functions may be implemented. The system uses the hash function to determine an unmanaged import corresponding to a .NET file.

[0122] At 440, a determination is made as to whether the sample is malicious. In some embodiments, in response to determining a hash of the list of unmanaged imported API function names, the system uses the hash (eg, Unmanaged Imphash) in conjunction with determining whether the sample is malicious.

[0123] In some embodiments, the system uses an unmanaged imphash corresponding to a .NET file in conjunction with determining whether a .NET file is malicious. As an example, in response to determining the unmanaged imphash corresponding to the .NET file, the system determines whether the unmanaged imphash matches the unmanaged imphash of a file that is considered malicious. If the unmanaged imphash of a sample (e.g., an analyzed file) matches the unmanaged imphash of a malicious file in a historical data set (e.g., a record included in a malicious file blacklist), the system deems the sample to be malicious. As an example, in response to determining the unmanaged imphash corresponding to a .NET file, the system determines whether the unmanaged imphash matches the unmanaged imphash of a file that is considered benign. If the unmanaged imphash of a sample (e.g., an analyzed file) matches the unmanaged imphash of a benign file in a historical data set (e.g., a record included in a benign file whitelist), the system deems the sample to be benign. In some embodiments, the system determines whether information related to a particular file (e.g., an unmanaged imphash corresponding to the analyzed .NET file) is included in a data set of historical files and historical information associated with a historical data set that indicates whether the particular file is malicious (e.g., a third-party service such as VirusTotal). TM As an example, in response to determining that information related to a particular file is not included in or available in a dataset of historical files and historical information, the system deems the file to be benign (e.g., deems the file to be not malicious). Examples of historical information associated with historical files indicating whether a particular file is malicious correspond to (VT) score. If the VT score of a particular file is greater than 0, the particular file is considered malicious by the third-party service. In some embodiments, the historical information associated with the historical file indicating whether the particular file is malicious corresponds to a social score indicating that the file is malicious or is likely to be malicious, such as a community-based score or rating (e.g., a reputation score). The historical information (e.g., from a third-party service, a community-based score, etc.) indicates whether other vendors or cybersecurity organizations consider the particular file to be malicious.

[0124] In response to determining at 440 that the sample is malicious, process 400 continues to 450 where an indication that the sample is malicious is provided.

[0125] In response to determining at 440 that the sample is malicious, process 400 proceeds to 450, where an indication that the sample is malicious is provided. For example, the indication that the sample is malicious can be provided to the component from which the sample was received. As an example, the system provides the indication that the sample is malicious to a security entity. As another example, the system provides the indication that the sample is malicious to a client device. As an example, the security entity provides the indication that the sample is malicious to the client device. In some embodiments, the indication that the sample is malicious is provided to a user, such as a user of the client device and / or a network administrator.

[0126] According to various embodiments, in response to receiving an indication that a sample is malicious, proactive measures may be performed. The proactive measures may be performed in accordance with (e.g., based at least in part on) one or more security policies. As an example, the one or more security policies may be preset by a network administrator, a client (e.g., an organization / company) providing a service for malicious file detection, or the like. Examples of proactive measures that may be performed include: isolating a file (e.g., quarantining a file), deleting a file, prompting a user to warn the user that a malicious file has been detected, providing a prompt to the user when a device attempts to open or execute a file, blocking the transfer of a file, updating a malicious file blacklist (e.g., a mapping of a file's hash to an indication that the file is malicious), or the like.

[0127] In response to determining at 440 that the sample is not malicious, process 400 proceeds to 460. In some embodiments, in response to determining that the sample is not malicious, a mapping of files (or hashes / signatures of files) to indications that the files are not malicious is updated. For example, a benign file whitelist is updated to include the sample or a hash, signature, or other unique identifier associated with the sample.

[0128] At 460, a determination is made as to whether process 400 is complete. In some embodiments, in response to a determination that no further samples are to be analyzed (e.g., no further predictions are needed for the file), an administrator indicates that process 400 is to be paused or stopped, etc., to determine that process 400 is to be completed. In response to a determination that process 400 is complete, process 400 ends. In response to a determination that process 400 is not complete, process 400 returns to 410.

[0129] Figure 5 is a flow chart of a method for determining whether a file is malicious according to various embodiments. In some embodiments, process 500 is at least partially performed by Figure 1 system 100 and / or Figure 2 In some embodiments, process 500 may be implemented by system 200. In some embodiments, process 500 may be implemented by one or more servers, such as in conjunction with providing a service to a network (e.g., a security entity and / or a network endpoint, such as a client device). In some embodiments, process 500 may be implemented by a security entity (e.g., a firewall), such as in conjunction with enforcing a security policy with respect to files transmitted across a network or within or outside a network. In some embodiments, process 500 may be implemented by a client device (e.g., a laptop, a smartphone, a personal computer, etc.), such as in conjunction with executing or opening a file (e.g., an email attachment).

[0130] According to various embodiments, Figure 4 The process 440 of the process 400 is combined with the calling process 500 .

[0131] At 510, a hash of the list is obtained. In some embodiments, the system obtains (e.g., receives, determines, etc.) an unmanaged Imphash. For example, the system receives a hash of a list of unmanaged imported API function names.

[0132] At 520, hashing is used in conjunction with query mapping. In response to receiving the hash of the list (e.g., unmanaged imphash), the system performs a lookup against a historical dataset of malicious and / or benign files. For example, the historical dataset includes an association between the unmanaged imphash and an indication of whether the corresponding file is malicious or benign.

[0133] In some embodiments, the system uses an unmanaged imphash corresponding to a .NET file in conjunction with determining whether a .NET file is malicious. As an example, in response to determining the unmanaged imphash corresponding to the .NET file, the system determines whether the unmanaged imphash matches an unmanaged imphash for a file that is considered malicious. As an example, in response to determining the unmanaged imphash corresponding to the .NET file, the system determines whether the unmanaged imphash matches an unmanaged imphash for a file that is considered benign. In some embodiments, the system determines whether information related to a particular file (e.g., an unmanaged imphash corresponding to the analyzed .NET file) is included in a data set of historical files and historical information associated with a historical data set that indicates whether the particular file is malicious (e.g., a third-party service such as VirusTotal). TM As an example, in response to determining that information related to a particular file is not included in or available in a dataset of historical files and historical information, the system deems the file to be benign (e.g., deems the file to be not malicious). Examples of historical information associated with historical files indicating whether a particular file is malicious correspond to (VT) score. If the VT score of a particular file is greater than 0, the particular file is considered malicious by the third-party service. In some embodiments, the historical information associated with the historical file indicating whether the particular file is malicious corresponds to a social score indicating that the file is malicious or is likely to be malicious, such as a community-based score or rating (e.g., a reputation score). The historical information (e.g., from a third-party service, a community-based score, etc.) indicates whether other vendors or cybersecurity organizations consider the particular file to be malicious.

[0134] At 530 , a determination is made as to whether the mapping indicates that the hash corresponds to a malicious file.

[0135] In response to determining at 530 that the mapping indicates that the hash corresponds to a malicious file, process 500 continues to 530 where the sample is determined to be malicious.

[0136] In response to determining at 530 that the mapping indicates that the hash does not correspond to a malicious file, process 500 proceeds to 550 where the sample is determined to be non-malicious. In some embodiments, in response to determining that the hash-to-file mapping does not include an indication that the hash is mapped to a malicious file, the system determines that the sample is benign. As an example, the system determines that the hash is not included in the mapping of hashes to malicious files. As another example, the system determines that the mapping does not include a record that is mapped to a malicious file (or an indication of a malicious file).

[0137] If the unmanaged imphash of a sample (eg, an analyzed file) matches the unmanaged imphash of a malicious file in a historical dataset (eg, a record included in a malicious file blacklist), the system considers the sample to be malicious.

[0138] If the unmanaged imphash of the sample (e.g., the analyzed file) matches the unmanaged imphash of a benign file in a historical dataset (e.g., a record included in a whitelist of benign files), the system deems the sample to be benign. In some embodiments, the system deems the file to be benign (e.g., deems the file to be non-malicious) in response to determining that information related to the particular file is not included in or available in a dataset of historical files and historical information.

[0139] At 560, a maliciousness result is provided. In some embodiments, the system provides an indication that the hash corresponds to a malicious file. For example, the system provides an indication that the file corresponding to the hash is malicious.

[0140] At 570, a determination is made as to whether process 500 is complete. In some embodiments, in response to a determination that no further hashes are to be analyzed (e.g., no further prediction of the file is needed), an administrator indicates that process 500 is to be paused or stopped, etc., to determine that process 500 is complete. In response to determining that process 500 is complete, process 500 ends. In response to determining that process 500 is not complete, process 500 returns to 510.

[0141] Figure 6 is a flow chart of a method for detecting malicious files according to various embodiments. In some embodiments, process 600 is performed at least in part by Figure 1 system 100 and / or Figure 2 In some embodiments, process 600 may be implemented by one or more servers, such as in conjunction with providing a service to a network (e.g., a security entity and / or a network endpoint, such as a client device). In some embodiments, process 600 may be implemented by a security entity (e.g., a firewall), such as in conjunction with enforcing a security policy with respect to files transmitted across a network or within or outside a network. In some embodiments, process 600 may be implemented by a client device (e.g., a laptop, a smartphone, a personal computer, etc.), such as in conjunction with executing or opening a file (e.g., an email attachment).

[0142] At 602, a sample is received.

[0143] At 604, a .NET assembly corresponding to the sample is obtained. In some embodiments, the sample is compressed (e.g., in a ZIP format, etc.), and the .NET assembly is extracted from the compressed file. In some embodiments, obtaining the .NET assembly includes determining that the sample is a .NET file.

[0144] At 606 , a determination is made as to whether the .NET assembly includes a ModuleRef table. In response to determining that the .NET assembly does not include a ModuleRef table, process 600 ends. Conversely, in response to determining that the .NET assembly includes a ModuleRef table, process 600 proceeds to 608 .

[0145] At 608 , a determination is made as to whether the .NET assembly includes an ImplMap table. In response to determining that the .NET assembly does not include an ImplMap table, process 600 ends. Conversely, in response to determining that the .NET assembly includes an ImplMap table, process 600 continues to 610 .

[0146] At 610, the ImportName value is obtained. In some embodiments, the system obtains the ImportName value from the ImportName column of the ImplMap table. For example, the system obtains the ImportName value from the applicable row (e.g., the selected row) of the ImportName column. In some embodiments, the system iterates over the rows of ImportName to obtain the value of each applicable row of the ImportName column.

[0147] At 612 , it is determined whether the ImportName value obtained at 610 is equal to 0. In response to determining that the ImportName value obtained at 610 is equal to 0, process 600 proceeds to 626 . In response to determining that the ImportName value obtained at 610 is not equal to 0, process 600 proceeds to 614 .

[0148] At 614, the function name is obtained from the #Strings stream. In some embodiments, the system obtains the function name from the #Strings stream of the .NET assembly using the selected line.

[0149] At 616, a value is obtained from the ImportScope column. In some embodiments, the system obtains the value from the ImportScope column of the ImplMap table. The system obtains the ImplMap table using the .NET header (e.g., the .NET header includes the ImplMap table). The value in the ImportScope column is obtained from the selected row (e.g., the row of the ImplMap table from which the ImportName value is obtained and / or the row of the Information column from which the #Strings flow information is obtained). In some embodiments, the value from the ImportScope column is used as an index in conjunction with performing a lookup in the ModuleRef table (e.g., for the name of the corresponding library).

[0150] At 618, the ImportScope value is used as an index into a row in the ModuleRef table to obtain a value. In some embodiments, the system uses a .NET header to obtain the ModuleRef table (e.g., the .NET header includes the ModuleRef table). The system uses the value obtained from the ImportScope column as an index to perform a lookup in the ModuleRef table. For example, the system uses the value obtained from the ImportScope column to determine the row of the ModuleRef table from which the system is to obtain a value from the Name column. In some embodiments, the value obtained from the Name column of the ModuleRef table is used as an index into the #Strings stream.

[0151] At 620, the library name is obtained from the #Strings stream. In some embodiments, the system obtains the #Strings stream using a .NET header (eg, the .NET header includes the #Strings stream). The system performs a lookup in the #Strings stream using the value obtained from the name column as an index.

[0152] At 624, the string corresponding to the library name-function name pair is added to the list. For example, the library name-function name pair is added to the list of unmanaged imported functions. In some embodiments, the system generates the string according to a predetermined format or syntax.

[0153] At 626, a determination is made as to whether the .NET assembly includes a MethodDef table. In response to determining that the .NET assembly does not include a MethodDef table, process 600 proceeds to 634, where the system deems the .NET header to have an empty function name. Conversely, in response to determining that the .NET assembly includes a MethodDef table, process 600 proceeds to 628.

[0154] At 628, a value is obtained from the MemberForwarded column of the ImplMap table. The system obtains the ImplMap table using the .NET header (e.g., the .NET header includes the ImplMap table). The value in the MemberForwarded column is obtained from the selected row (e.g., the row of the ImplMap table from which the MemberForwarded value is obtained). In some embodiments, the value from the MemberForwarded column is used as an index in conjunction with performing a lookup in the ModuleRef table (e.g., for the name of the corresponding library).

[0155] At 630, the MemberForwarded value is used as an index into a row in the ModuleRef table to obtain the value. In some embodiments, the system uses the .NET header to obtain the ModuleRef table (e.g., the .NET header includes the ModuleRef table). The system uses the value obtained from the MemberForwarded column as an index to perform a lookup in the ModuleRef table. For example, the system uses the value obtained from the Name column to determine the row of the ModuleRef table from which the system will obtain the value from the #Strings stream.

[0156] At 632, the function name is obtained from the #Strings stream. In some embodiments, the system obtains the #Strings stream using the .NET header (e.g., the .NET header includes the #Strings stream). The system performs a lookup in the #Strings stream using the value obtained from the name column in the ModuleRef table as an index.

[0157] At 636, a determination is performed whether the PE header has an import table. In some embodiments, the system determines whether the PE header includes an import table in conjunction with determining a library name corresponding to a function name (eg, a function name obtained from a #Strings stream).

[0158] In response to determining at 636 that the PE header does not have an import table, process 600 proceeds to 638, where the system assumes that the library name is an empty library name. Conversely, in response to determining at 636 that the PE header has an import table, process 600 proceeds to 640, where the library name corresponding to the function name is obtained. In some embodiments, the system parses the import table to obtain the library name corresponding to the function name. In response to obtaining the library name, process 600 proceeds to 624.

[0159] After adding the function name and corresponding library name to the list at 624 , process 600 continues to 642 .

[0160] At 642, a determination is made as to whether the population (e.g., generation) of the list is complete. In some embodiments, in response to determining that no further imported functions and / or corresponding libraries are to be added to the list (e.g., no further imported functions are included in or referenced in the .NET header), an administrator instructs process 600 to be paused or stopped, etc., the population / generation of the list is determined to be complete. In response to determining at 642 that no further imported functions and / or corresponding libraries are to be added to the list, process 600 proceeds to 644, where the system determines (e.g., calculates) a hash of the list (e.g., a list of unmanaged imported functions). In response to determining that process 600 is not complete, process 600 returns to 602. In some embodiments, in response to calculating the hash (e.g., the unmanaged Imphash), the system determines whether the sample is malicious based at least in part on the unmanaged Imphash. For example, in response to calculating the hash, calling Figure 5 Process 500.

[0161] In some embodiments, the system calls Figure 7A Process 700 or Figure 7B The process 750 determines the hash of the list.

[0162] Figure 7A is a flow chart of a method for detecting malicious files according to various embodiments. In some embodiments, process 700 is performed at least in part by Figure 1 system 100 and / or Figure 2 In some embodiments, process 600 may be implemented by one or more servers, such as in conjunction with providing a service to a network (e.g., a security entity and / or a network endpoint, such as a client device). In some embodiments, process 700 may be implemented by a security entity (e.g., a firewall), such as in conjunction with enforcing a security policy with respect to files transmitted across a network or within or outside a network. In some embodiments, process 700 may be implemented by a client device (e.g., a laptop, a smartphone, a personal computer, etc.), such as in conjunction with executing or opening a file (e.g., an email attachment).

[0163] At 702, library names and / or function names are obtained. In some embodiments, the function names and corresponding library names are obtained using .NET headers, such as in conjunction with generating a list of unmanaged imported functions.

[0164] At 704, a determination is performed as to whether the library name has a file extension. In response to determining at 704 that the library name has a file extension, process 700 proceeds to 706 where the file extension is removed. In response to determining at 704 that the library name does not have a file extension, process 700 proceeds to 708.

[0165] At 708, format the function name and library name. In some embodiments, the system formats the library name-function name pair according to a predetermined format or syntax. As another example, the system formats the function name and library name to convert any uppercase letters to lowercase letters.

[0166] At 710, the function name and the library name are combined. In some embodiments, the system constructs a string corresponding to a combination of the function name of the imported function (e.g., an unmanaged imported function) and the library name corresponding to the imported function. For example, the system constructs the string by appending the library name to the function name, and a predefined separator (e.g., ".") is included between the library name and the function name. According to various embodiments, the system determines the string according to the format: <libraryname> . <functionname>The system then adds the string to a list of unmanaged imported functions (such as the list that identifies the unmanaged Imphash).

[0167] According to various embodiments, various formats or syntaxes may be implemented in conjunction with the system combining function names and library names. Examples of predetermined formats include (i) lowercase alphanumeric strings, (ii) removal of file extensions, (iii) removal of library extensions (e.g., removing .dll from corresponding library names), (iv) appending unmanaged function names and corresponding libraries, and (v) use of a predefined separator between unmanaged function names and corresponding libraries, (vi) combining library names and function names to determine the order of the strings (e.g., <libraryname> . <functionname>or <functionname> . <libraryname>In some embodiments, the system appends the function name (e.g., the unmanaged function name) to the corresponding library and separates the function name from the corresponding library by a dot or period (e.g., "". In response to determining a string by appending the function name and library (e.g., using a predefined separator, such as "), the system adds such an entry to the list of the set of unmanaged imported functions and / or corresponding libraries. Various other predefined formats / syntaxes can be implemented.

[0168] At 712 , the combination of the function name and library name is added to a list of unmanaged imported functions.

[0169] At 714, a determination is made as to whether there are more functions to be added to the list. For example, the system determines whether there are more unmanaged import functions to be added to the list of unmanaged import functions for the file. In response to determining at 714 that no further functions are to be added to the list, process 700 proceeds to 716. In response to determining that additional functions are to be added to the list, process 700 returns to 702.

[0170] At 716, a hash is calculated relative to the list. According to various embodiments, the system determines a hash relative to the list of unmanaged imported functions and / or corresponding libraries. Various hash functions can be used in conjunction with determining the hash. Examples of hash functions include a SHA-256 hash function, an MD5 hash function, a SHA-1 hash function, and the like. Various other hash functions can be implemented. The system uses the hash function to determine the unmanaged import hash corresponding to the .NET file.

[0171] In some embodiments, the system transforms or formats the list according to a predefined format. For example, a list of library <-> function (<-> mappingflags) name pairs is transformed into a comma-delimited string. According to such an example, instead of computing a hash on the following table

[0172] kernel32.createprocess

[0173] kernel32.getthreadcontext

[0174] kernel32.wow64getthreadcontext

[0175] kernel32.setthreadcontext

[0176] kernel32.wow64setthreadcontext

[0177] kernel32.readprocessmemory

[0178] The system creates a comma-delimited string using a single list item (library <-> function pair): "kernel32.createprocess,kernel32.getthreadcontext,kernel32.wow64getthreadcontext,kernel32.setthreadcontext,kernel32.wow64setthreadcontext,kernel32.readprocessmemory,..." In response to transforming / creating the comma-delimited string using a single list item, the system determines (e.g., calculates a hash) relative to such a string.

[0179] At 718, the hash is provided. In some embodiments, the system provides the hash to another system or module, such as in conjunction with determining whether the file is malicious by such a system or module. For example, the hash is provided in response to calling process 700.

[0180] At 720, a determination is made as to whether process 700 is complete. In some embodiments, process 700 is determined to be complete in response to a determination that no further hashes are to be calculated (e.g., no further predictions of the file are needed), an administrator indicating that process 700 is to be paused or stopped, or the like. In response to determining that process 700 is complete, process 700 ends. In response to determining that process 700 is not complete, process 700 returns to 702.

[0181] Figure 7B is a flow chart of a method for detecting malicious files according to various embodiments.

[0182] In some embodiments, process 700 is performed at least in part by Figure 1 system 100 and / or Figure 2 In some embodiments, process 600 may be implemented by one or more servers, such as in conjunction with providing a service to a network (e.g., a security entity and / or a network endpoint, such as a client device). In some embodiments, process 700 may be implemented by a security entity (e.g., a firewall), such as in conjunction with enforcing a security policy with respect to files transmitted across a network or within or outside a network. In some embodiments, process 700 may be implemented by a client device (e.g., a laptop, a smartphone, a personal computer, etc.), such as in conjunction with executing or opening a file (e.g., an email attachment).

[0183] According to various embodiments, Figure 7A Compared to 700, 750 is stricter because 750 includes additional information about unmanaged functions (such as information about how the author defined the unmanaged functions in the code). As an example, the final hash of 750 may also be stricter and may be less prone to false positives. However, the disadvantage is that the final hash of 750 may hit fewer malware samples than the final hash of 700.

[0184] At 752, library names and / or function names are obtained. In some embodiments, function names and corresponding library names are obtained using .NET headers, such as in conjunction with generating a list of unmanaged imported functions.

[0185] At 754, a determination is made as to whether the library name has a file extension. In response to determining at 754 that the library name has a file extension, process 750 proceeds to 756 where the file extension is removed. In response to determining at 754 that the library name does not have a file extension, process 700 proceeds to 760.

[0186] At 758, format the function name and library name. In some embodiments, the system formats the library name-function name pair according to a predetermined format or syntax. As another example, the system formats the function name and library name to convert any uppercase letters to lowercase letters.

[0187] At 760, a MappingFlags value is obtained. In some embodiments, the system obtains the MappingFlags value from the ImplMap table. For example, the system obtains the MappingFlags value from the row in the ImplMap table corresponding to the function. The MappingFlags value includes P / Invoke attributes.

[0188] At 762, the MappingFlags value, the function name, and the library name are combined. In some embodiments, the system constructs a string that corresponds to the combination of the MappingFlags value, the function name of the imported function (e.g., an unmanaged imported function), and the library name corresponding to the imported function. For example, the system constructs the string by appending the MappingFlags value and the library name to the function name, and a predefined separator (e.g., ".") is included between the library name and the function name. According to various embodiments, the system determines the string according to the format: <libraryname> . <functionname> . <mappingflags>The system then adds the string to a list of unmanaged imported functions (such as the list that identifies the unmanaged Imphash).

[0189] According to various embodiments, various formats or syntaxes may be implemented in conjunction with the system combining function names and library names. Examples of predetermined formats include (i) lowercase alphanumeric strings, (ii) removal of file extensions, (iii) removal of library extensions (e.g., removing .dll from corresponding library names), (iv) appending unmanaged function names and corresponding libraries, and (v) use of a predefined separator between unmanaged function names and corresponding libraries, (vi) combining library names and function names to determine the order of the strings (e.g., <libraryname> . <functionname> . <mappingflags> 、 <functionname> . <libraryname> . <mappingflags>In some embodiments, the system appends the function name (e.g., unmanaged function name) to the corresponding library and separates the function name from the corresponding library by a dot or period (e.g., "". In response to determining a string by appending the function name and library (e.g., using a predefined separator such as "", the system adds such an entry to the list of the set of unmanaged imported functions and / or corresponding libraries. Various other predefined formats / syntaxes can be implemented.

[0190] At 764, the combination of the function name and library name is added to the list of unmanaged imported functions.

[0191] At 766, a determination is made as to whether there are more functions to be added to the list. For example, the system determines whether there are more unmanaged import functions to be added to the list of unmanaged import functions for the file. In response to determining at 766 that no further functions are to be added to the list, process 750 proceeds to 752. In response to determining that additional functions are to be added to the list, process 750 returns to 752.

[0192] At 768, a hash is calculated relative to the list. According to various embodiments, the system determines a hash relative to the list of unmanaged imported functions and / or corresponding libraries. Various hash functions can be used in conjunction with determining the hash. Examples of hash functions include a SHA-256 hash function, an MD5 hash function, a SHA-1 hash function, and the like. Various other hash functions can be implemented. The system uses the hash function to determine the unmanaged import hash corresponding to the .NET file.

[0193] In some embodiments, the system transforms or formats the list according to a predefined format. For example, a list of library <-> function (<-> mappingflags) name pairs is transformed into a comma-delimited string. According to such an example, instead of computing a hash on the following list

[0194] kernel32.createprocess

[0195] kernel32.getthreadcontext

[0196] kernel32.wow64getthreadcontext

[0197] kernel32.setthreadcontext

[0198] kernel32.wow64setthreadcontext

[0199] kernel32.readprocessmemory

[0200] The system creates a comma-delimited string using a single list item (library <-> function pair): "kernel32.createprocess,kernel32.getthreadcontext,kernel32.wow64getthreadcontext,kernel32.setthreadcontext,kernel32.wow64setthreadcontext,kernel32.readprocessmemory,..." In response to transforming / creating the comma-delimited string using a single list item, the system determines (e.g., calculates a hash) relative to such a string.

[0201] At 770, the hash is provided. In some embodiments, the system provides the hash to another system or module, such as in conjunction with determining whether the file is malicious by such a system or module. For example, the hash is provided in response to calling process 750.

[0202] At 772, a determination is made as to whether process 750 is complete. In some embodiments, process 750 is complete in response to a determination that no further hashes are to be calculated (e.g., no further predictions of the file are needed), an administrator indicating that process 750 is to be paused or stopped, or the like. In response to determining that process 750 is complete, process 750 ends. In response to determining that process 750 is not complete, process 750 returns to 752.

[0203] Figure 8 is a flow chart of a method for detecting malicious files according to various embodiments. In some embodiments, process 800 is at least partially performed by Figure 1 system 100 and / or Figure 2 In some embodiments, process 800 may be implemented by one or more servers, such as in conjunction with providing a service to a network (e.g., a security entity and / or a network endpoint, such as a client device). In some embodiments, process 800 may be implemented by a security entity (e.g., a firewall), such as in conjunction with enforcing a security policy with respect to files transmitted across a network or within or outside a network. In some embodiments, process 800 may be implemented by a client device (e.g., a laptop, a smartphone, a personal computer, etc.), such as in conjunction with executing or opening a file (e.g., an email attachment).

[0204] At 810, an indication that the sample is malicious is received. In some embodiments, the system receives the indication that the sample is malicious and the sample or a hash, signature, or other unique identifier associated with the sample. For example, the system can receive the indication that the sample is malicious from a service, such as a security or malware service. The system can receive the indication that the sample is malicious from one or more servers.

[0205] According to various embodiments, an indication that a sample is malicious is received in conjunction with an update to a previously identified set of malicious files. For example, the system receives the indication that the sample is malicious as an update to a malicious file blacklist.

[0206] At 820, an association of the sample with an indication that the sample is malicious is stored. In response to receiving the indication that the sample is malicious, the system stores the indication that the sample is malicious in association with the sample or an identifier corresponding to the sample to facilitate a lookup (e.g., a local lookup) of whether a subsequently received file is malicious. In some embodiments, the identifier corresponding to the sample stored in association with the indication that the sample is malicious comprises a hash of the file (or portion of the file), a signature of the file (or portion of the file), or another unique identifier associated with the file. In some embodiments, storing the sample in association with the indication of whether the sample is malicious comprises storing an unmanaged imphash of a .NET file in association with the indication of whether the sample is malicious.

[0207] At 830, traffic is received. The system can obtain traffic, such as in conjunction with routing traffic within / across a network or mediating traffic in and out of a network (such as a firewall) or monitoring email traffic or instant messaging traffic.

[0208] At 840, a determination is performed as to whether the transaction includes a malicious file. In some embodiments, the system obtains the file from the received transaction. For example, the system identifies the file as an attachment to an email, identifies the file as being exchanged between two client devices via an instant messaging program or another file exchange program, etc. In response to obtaining the file from the transaction, the system determines whether the file corresponds to a file included in a previously identified set of malicious files (such as a malicious file blacklist). In response to determining that the file is included in a set of files on the malicious file blacklist, the system determines that the file is malicious (e.g., the system may further determine that the transaction includes a malicious file).

[0209] In some embodiments, the system determines whether the file corresponds to a file included in a previously identified set of benign files (such as a benign file whitelist). In response to determining that the file is included in the set of files on the benign file whitelist, the system determines that the file is not malicious (e.g., the system may further determine that the file includes a malicious file).

[0210] According to various embodiments, in response to determining that the file is not included in a previously identified set of malicious files (e.g., a malicious file blacklist) or a previously identified set of benign files (e.g., a benign file whitelist), the system deems the file not malicious (e.g., benign).

[0211] According to various embodiments, in response to determining that a file is not included in a previously identified set of malicious files (e.g., a malicious file blacklist) or a previously identified set of benign files (e.g., a benign file whitelist), the system queries a malicious file detector to determine whether the file is malicious. For example, the system may quarantine the file until the system receives a response from the malicious file detector regarding whether the file is malicious. The malicious file detector may perform the evaluation of whether the file is malicious, such as concurrently with the system's processing of transactions (e.g., in real time with queries from the system). The malicious file detector may correspond to Figure 1 system 100 and / or Figure 2 The malicious file detector 170 of the system 200.

[0212] In some embodiments, the system determines whether a file is included in a previously identified set of malicious files or a previously identified set of benign files by computing a hash or determining a signature or other unique identifier associated with the file and performing a search in the previously identified set of malicious files or the previously identified set of benign files for files that match the hash, signature, or other unique identifier. Various hashing techniques can be implemented. According to various embodiments, determining whether a file is included in a previously identified set of malicious files or a previously identified set of benign files includes determining an unmanaged imphash corresponding to the file and determining whether the unmanaged imphash is included in a historical dataset (e.g., a dataset that includes previous determinations of maliciousness).

[0213] In response to determining at 840 that the traffic does not include a malicious file, process 800 proceeds to 850 where the file is processed as non-malicious traffic / information.

[0214] In response to determining at 840 that the traffic does not include a malicious file, process 800 proceeds to 860 where the file is processed as malicious traffic / information. The system may process malicious traffic / information based at least in part on one or more policies, such as one or more security entities.

[0215] According to various embodiments, the processing of file malicious traffic / information may include executing proactive measures. The proactive measures may be executed in accordance with (e.g., based at least in part on) one or more security policies. As an example, one or more security policies may be preset by a network administrator, a client (e.g., an organization / company) providing a service for malicious file detection, or the like. Examples of proactive measures that may be executed include: isolating a file (e.g., quarantining a file), deleting a file, prompting a user to warn the user that a malicious file has been detected, providing a prompt to the user when a device attempts to open or execute a file, blocking the transfer of a file, updating a malicious file blacklist (e.g., a mapping of a file's hash to an indication that the file is malicious), or the like.

[0216] At 870, a determination is made as to whether process 800 is complete. In some embodiments, in response to a determination that no further samples are to be analyzed (e.g., no further predictions are needed for the file), an administrator instructs that process 800 be paused or stopped, etc., to determine that process 800 is complete. In response to determining that process 800 is complete, process 800 ends. In response to determining that process 800 is not complete, process 800 returns to 810.

[0217] Figure 9 is a flow chart of a method for detecting malicious files according to various embodiments. In some embodiments, process 900 is at least partially performed by Figure 1 system 100 and / or Figure 2 In some embodiments, the process 900 may be implemented by a security entity (e.g., a firewall) and / or an anti-malware application running on a client system, such as in conjunction with enforcing security policies with respect to files transmitted across a network or within or outside a network. In some embodiments, the process 900 may be implemented by a client device (e.g., a laptop, a smartphone, a personal computer, etc.), such as in conjunction with executing or opening a file (e.g., an email attachment).

[0218] At 910, a file is obtained from a service. The system may obtain the service, such as in conjunction with routing traffic within or across a network, mediating traffic in and out of a network (such as a firewall), or monitoring email traffic or instant messaging traffic. In some embodiments, the system obtains the file from a received service. For example, the system identifies the file as an attachment to an email, identifies the file as being exchanged between two client devices via an instant messaging program or other file exchange program, etc.

[0219] At 920, a signature corresponding to the file is determined. In some embodiments, the system calculates a hash or determines a signature or other unique identifier associated with the file. Various hashing techniques can be implemented. For example, the hashing technique can be determining (e.g., calculating) an MD5 hash of the file. In some embodiments, determining the signature corresponding to the file includes calculating an unmanaged Imphash of the .NET file.

[0220] At 930, the dataset of malicious sample signatures is queried to determine whether the signature corresponding to the file matches a signature from the malicious sample. In some embodiments, the system performs a lookup in the dataset of malicious sample signatures for files that match a hash, signature, or other unique identifier. The dataset of malicious sample signatures can be stored locally at the system or remotely on a storage system accessible to the system.

[0221] According to various embodiments, determining whether a file is included in a previously identified set of malicious files or a previously identified set of benign files includes determining an unmanaged imphash corresponding to the file and determining whether the unmanaged imphash is included in a historical dataset (e.g., a dataset that includes previous determinations of maliciousness).

[0222] At 940, a determination is made as to whether the file is malicious based at least in part on whether the signature of the file matches the signature of the malicious sample. In some embodiments, the system determines whether the dataset of malicious signatures includes a record that matches the signature of the file obtained from the business. In response to determining that the historical dataset includes an indication that the file corresponding to the unmanaged imphash is malicious (e.g., the unmanaged imphash is included in the field blacklist), the system deems the file obtained from the business at 910 to be malicious.

[0223] At 950, the file is processed based on whether the file is malicious. In some embodiments, in response to determining that the file is malicious, the system applies one or more security policies to the file. In some embodiments, in response to determining that the file is not malicious, the system processes the file as benign (e.g., processes the file as normal business).

[0224] At 960, a determination is made as to whether process 900 is complete. In some embodiments, in response to a determination that no further samples are to be analyzed (e.g., no further predictions are needed for the file), an administrator instructs that process 900 be paused or stopped, etc., to determine that process 900 is complete. In response to a determination that process 900 is complete, process 900 ends. In response to a determination that process 900 is not complete, process 900 returns to 910.

[0225] Figure 10 is a flow chart of a method for detecting malicious files according to various embodiments. In some embodiments, process 1000 is at least partially performed by Figure 1 system 100 and / or Figure 2 In some embodiments, the process 1000 may be implemented by a security entity (e.g., a firewall) and / or an anti-malware application running on a client system, such as in conjunction with enforcing security policies with respect to files transmitted across a network or within or outside a network. In some embodiments, the process 1000 may be implemented by a client device (e.g., a laptop, a smartphone, a personal computer, etc.), such as in conjunction with executing or opening a file (e.g., an email attachment).

[0226] Traffic is received at 1010. The system may obtain traffic, such as in conjunction with routing traffic within / across a network or mediating traffic in and out of a network (such as a firewall) or monitoring email traffic or instant messaging traffic.

[0227] At 1020, the file is obtained from the service. In some embodiments, the system obtains the file from the received service. For example, the system identifies the file as an attachment to an email, identifies the file as being exchanged between two client devices via an instant messaging program or other file exchange program, etc.

[0228] At 1030, the import API function name is obtained using the .NET header of the file. In some embodiments, 1030 corresponds to or is similar to Figure 4 420 of the process 400.

[0229] At 1040, unmanaged functions are determined. In some embodiments, the system determines the set of unmanaged functions based on the imported API function names obtained using the .NET header of the file. For example, the system determines which of the imported API functions corresponds to the unmanaged function. As an example, at least a portion of process 600 may be invoked in conjunction with determining the unmanaged function.

[0230] At 1050, a determination is made as to whether the file is malicious. In some embodiments, the system determines whether the file is malicious based at least in part on unmanaged managed functions (e.g., such as a collection of unmanaged functions imported into the file via a .NET header). In some embodiments, 1050 corresponds to or is similar to Figure 4 440 of process 400. In some embodiments, Figure 5 The process 500 is performed in conjunction with 1050.

[0231] In response to determining at 1050 that the file is malicious, process 1000 proceeds to 1060 where one or more security policies are applied relative to the file. In some embodiments, 1060 corresponds to or is similar to Figure 8 860 of process 800. Thereafter, process 1000 proceeds to 1070.

[0232] In response to determining at 1050 that the file is not malicious, process 1000 proceeds to 1070 where the file is processed as non-malicious traffic. In some embodiments, 1070 corresponds to or is similar to Figure 8 The process of 800 to 850.

[0233] At 1080, a determination is made as to whether process 1000 is complete. In some embodiments, process 1000 is determined to be complete in response to a determination that no further samples are to be analyzed (e.g., no further predictions are needed for the file), no further transactions are to be analyzed, an administrator indicates that process 1000 is to be paused or stopped, etc. In response to determining that process 1000 is complete, process 1000 ends. In response to determining that process 1000 is not complete, process 1000 returns to 1010.

[0234] Figure 11 is a flow chart of a method for detecting malicious files according to various embodiments. In some embodiments, process 1100 is at least partially performed by Figure 1 system 100 and / or Figure 2 In some embodiments, the process 1100 may be implemented by a security entity (e.g., a firewall) and / or an anti-malware application running on a client system, such as in conjunction with enforcing security policies with respect to files transmitted across a network or within or outside a network. In some embodiments, the process 1100 may be implemented by a client device (e.g., a laptop, a smartphone, a personal computer, etc.), such as in conjunction with executing or opening a file (e.g., an email attachment).

[0235] At 1110, traffic is received. In some embodiments, 1110 corresponds to or is similar to Figure 10 The process of 1000 of 1010.

[0236] At 1120, a file is obtained from the business. In some embodiments, 1120 corresponds to or is similar to Figure 10 The process of 1000 to 1020.

[0237] At 1130, the import API function name is obtained using the .NET header of the file. In some embodiments, 1130 corresponds to or is similar to Figure 10 Process 1000 of 1030.

[0238] At 1140, a hash of the list of unmanaged imported API function names is determined. In some embodiments, the system determines the unmanaged functions based at least in part on the imported API function names (e.g., via the file's .NET header). In some embodiments, the system determines a set of unmanaged functions based on the imported API function names obtained using the file's .NET header, determines a list of unmanaged functions, and determines the hash based at least in part on the list. As an example, the list includes unmanaged function names corresponding to the set of unmanaged functions.

[0239] At 1150, the hash-to-file mapping is queried. In some embodiments, the system queries the hash-to-file mapping based at least in part on the hash of the list of unmanaged imported API function names. For example, the system performs a query relative to the hash-to-file mapping to determine whether the mapping includes the hash of the list of unmanaged imported API function names (e.g., to determine whether the mapping includes a record corresponding to the determined / calculated hash). In some embodiments, 1150 corresponds to or is similar to Figure 8 Process 800, 840 and / or Figure 9 Process 900 of 930.

[0240] At 1160, a determination is made as to whether the file is malicious. In some embodiments, 1160 corresponds to or is similar to Figure 10 The process of 1000 to 1050.

[0241] In response to determining at 1160 that the file is malicious, process 1100 proceeds to 1170 where one or more security policies are applied relative to the file. In some embodiments, 1170 corresponds to or is similar to Figure 8 860 of process 800. Thereafter, process 1100 proceeds to 1190.

[0242] In response to determining at 1160 that the file is not malicious, process 1100 proceeds to 1180 where the file is processed as non-malicious traffic. In some embodiments, 1180 corresponds to or is similar to Figure 8 The process of 800 to 850.

[0243] At 1190, a determination is made as to whether process 1100 is complete. In some embodiments, process 1100 is determined to be complete in response to a determination that no further samples are to be analyzed (e.g., no further predictions are needed for the file), no further transactions are to be analyzed, an administrator indicates that process 1100 is to be paused or stopped, etc. In response to determining that process 1100 is complete, process 1100 ends. In response to determining that process 1100 is not complete, process 1100 returns to 1110.

[0244] Various examples of the embodiments described herein are described in conjunction with flow charts. Although the examples may include certain steps performed in a specific order, according to various embodiments, the various steps may be performed in various orders and / or the various steps may be combined into a single step or performed in parallel.

[0245] Although the foregoing embodiments have been described in detail for the purpose of clarity of understanding, the present invention is not limited to the details provided. There are many alternative ways to implement the present invention. The disclosed embodiments are illustrative rather than restrictive.< / mappingflags> < / libraryname> < / functionname> < / mappingflags> < / functionname> < / libraryname> < / mappingflags> < / functionname> < / libraryname> < / libraryname> < / functionname> < / functionname> < / libraryname> < / functionname> < / libraryname> < / crtimplementationdetails> < / crtimplementationdetails> < / crtimplementationdetails> < / crtimplementationdetails> < / crtimplementationdetails> < / crtimplementationdetails> < / functionname> < / libraryname> < / functionname> < / libraryname>

Claims

1. A system comprising: One or more processors configured to: receiving a sample comprising a .NET file, wherein the .NET file comprises (i) a PE header comprising a set of managed import API functions, and (ii) a .NET header comprising a set of unmanaged import API functions; obtaining unmanaged import API function names of a second set of unmanaged import API functions based at least in part on a .NET header of the .NET file; A hash that determines the list of unmanaged imported API function names; as well as determining whether the sample is malware based at least in part on a hash of the list of unmanaged imported API function names; as well as A memory is coupled to the one or more processors and configured to provide instructions to the one or more processors.

2. The system according to claim 1, wherein obtaining the import API function name comprises: Parse the .NET header of a .NET file; as well as Extracts imported API function names from parsed .NET headers. 3 . The system of claim 2 , wherein the import API function name is extracted from a parsed .NET header based at least in part on an index table. 4 . The system of claim 3 , wherein the index table comprises an ImplMap table that indicates a set of unmanaged methods imported in conjunction with execution of a .NET file.

5. The system of claim 2, wherein the imported API function names are extracted from a parsed .NET header based at least in part on a MethodDef table.

6. The system of claim 1 , wherein determining a hash of the list of unmanaged imported API function names comprises: determining an unmanaged set of imported API functions based at least in part on the imported API function names obtained based on the .NET header; as well as A hash of the list of unmanaged imported API function names is generated based at least in part on a predetermined hash function.

7. The system of claim 6, wherein the predetermined hash function comprises at least one of a SHA-256 hash algorithm, an MD5 hash algorithm, and a SHA-1 hash algorithm.

8. The system of claim 1 , wherein the one or more processors are further configured to: Sending samples to a security entity is an indication of malicious intent.

9. The system of claim 8, wherein sending an indication to the security entity that the sample is malicious comprises: A blacklist of files considered malicious is updated, the blacklist being updated to include an identifier corresponding to the sample.

10. The system according to claim 8 or 9, wherein the security entity corresponds to a firewall.

11. The system of claim 1 , wherein determining whether a sample is malware based at least in part on a hash of the list of unmanaged imported API function names is executed in a sandbox environment.

12. The system of claim 1, wherein the determining whether the sample is malware based at least in part on a hash of the list of unmanaged imported API function names is performed at a security entity.

13. The system of claim 1, wherein the import API function name is obtained based at least in part on a value corresponding to an ImportName field.

14. The system of claim 13, wherein in response to determining that the value corresponding to the ImportName field is not equal to 0, obtaining the import API function name comprises determining a set of one or more library names based at least in part on a #Strings stream of the .NET file.

15. The system of claim 13 , wherein in response to determining that the value corresponding to the ImportName field is equal to 0, obtaining the import API function name comprises: Get the value from the row of the MethodDef table; obtaining a function name from a #Strings stream based at least in part on a value from a row of a MethodDef table; Determine whether the PE header of a .NET file includes an import table; as well as In response to determining that the PE header of the .NET file does not include an import table, a library name corresponding to the function name is determined based at least in part on the import table.

16. The system of claim 15, wherein determining a library name corresponding to a function name based at least in part on the import table comprises parsing the import table to obtain the library name from the corresponding function name.

17. The system of claim 1, wherein the one or more processors are further configured to: Make sure that library names corresponding to unmanaged functions do not have a file extension; determining a string based at least in part on the library name and the unmanaged function; and Adds a string to the list of unmanaged imported API function names.

18. The system of claim 17, wherein the string is determined by ensuring that the library name and the name of the unmanaged function do not include uppercase letters and appending the name of the unmanaged function to the library name with a predefined separator included between the name of the unmanaged function and the library name.

19. The system of claim 1, wherein: The list of unmanaged imported API function names includes, for each unmanaged imported API function, a pair of: (a) an indication of the unmanaged API function name and (b) an indication of the corresponding library name; The hashed list of unmanaged imported API function names consists of: generating a string representing a list of unmanaged imported API function names based at least in part on the indication of the unmanaged API function name and the indication of corresponding library names of the plurality of unmanaged API functions; and Computes a hash based on a string representing a list of unmanaged imported API function names.

20. A method comprising: receiving a sample comprising a .NET file, wherein the .NET file comprises (i) a PE header comprising a set of managed import API functions, and (ii) a .NET header comprising a set of unmanaged import API functions; obtaining unmanaged import API function names of a second set of unmanaged import API functions based at least in part on a .NET header of the .NET file; A hash that determines the list of unmanaged imported API function names; as well as A determination is made whether the sample is malware based at least in part on a hash of the list of unmanaged imported API function names.

21. A computer program product embodied in a non-transitory computer-readable medium and comprising computer instructions for: receiving a sample comprising a .NET file, wherein the .NET file comprises (i) a PE header comprising a set of managed import API functions, and (ii) a .NET header comprising a set of unmanaged import API functions; obtaining unmanaged import API function names of a second set of unmanaged import API functions based at least in part on a .NET header of the .NET file; A hash that determines the list of unmanaged imported API function names; as well as A determination is made whether the sample is malware based at least in part on a hash of the list of unmanaged imported API function names.

Images