JP2018524720A - Malware mitigation - Google Patents

Abstract

Certain embodiments described herein enable execution of malware in the system, record changes to the system caused by the execution of malware, and generate detection tasks for detection of malware in electronic devices. The detection task is based at least in part on changes to the system caused by the execution of malware. The detection task can be used to identify infected electronic devices and to generate mitigation tasks that mitigate changes to infected electronic devices caused by malware.

Description

[Cross-reference to related applications]
This application claims the benefit and priority of Indian Patent Application No. 3247 / CHE / 2015, filed June 27, 2015, entitled “Malware Mitigation,” which is incorporated by reference in its entirety. Incorporated in the description.

  The present disclosure relates generally to the field of information security, and more specifically to malware mitigation.

  In today's society, the field of network security is becoming increasingly important. The Internet allows interconnection of different computer networks around the world. In particular, the Internet provides a medium for exchanging data between different users connected to different computer networks via various types of client devices. While the use of the Internet has changed corporate and personal communications, it also allows malicious operators to gain unauthorized access to computers and computer networks, and the intentional or carelessness of sensitive information Used as a means for disclosure.

  Malicious software ("malware") that infects host computers steals sensitive information from companies or individuals associated with the host computer, propagates to other host computers, and / or distributed denial of service It may be possible to perform any number of malicious actions, such as assisting an attack, sending spam or malicious email from a host computer. Thus, significant management challenges remain to protect computers and computer networks from malicious and inadvertent exploits by malicious software.

  In order to provide a more thorough understanding of the present disclosure, as well as its features and advantages, reference is made to the following description used in conjunction with the accompanying drawings. Like reference numerals represent like parts.

1 is a simplified block diagram of a communication system for malware mitigation according to one embodiment of the present disclosure. FIG.

1 is a simplified block diagram of a communication system for malware mitigation according to one embodiment of the present disclosure. FIG.

1 is a simplified block diagram of a communication system for malware mitigation according to one embodiment of the present disclosure. FIG.

1 is a simplified block diagram of a portion of a communication system for malware mitigation according to one embodiment of the present disclosure. FIG.

1 is a simplified diagram of exemplary details of a communication system for malware mitigation, according to one embodiment of the present disclosure. FIG.

6 is a simplified flowchart illustrating potential operations that may be associated with a communication system according to one embodiment.

6 is a simplified flowchart illustrating potential operations that may be associated with a communication system according to one embodiment.

1 is a block diagram illustrating an example computing system arranged in a point-to-point configuration according to one embodiment. FIG.

2 is a simplified block diagram associated with an exemplary ARM ecosystem system on chip (SoC) of the present disclosure. FIG.

FIG. 3 is a block diagram illustrating an exemplary processor core according to one embodiment.

  The drawings are not necessarily drawn to scale because their dimensions may vary without significantly departing from the scope of the present disclosure.

Exemplary Embodiment
FIG. 1A is a simplified block diagram of a communication system 100a for malware mitigation according to one embodiment of the present disclosure. The communication system 100a may include an electronic device 102a, a cloud service 104, and a server 106. The electronic device 102a may include a processor 110, a memory 112, an operating system 114, a sandbox 116, and a security module 118. The security module 118 may include a malware detection module 120, a malware mitigation module 122, and a malware pattern behavior 124. The malware detection module 120 may include an analysis log 126. The malware mitigation module 122 may include a reverse malware behavior operation 128. Cloud service 104 and server 106 may each include a network security module 130. The network security module 130 may include a pattern behavior generation module 132 and a malware pattern behavior 124. The electronic device 102a, the cloud service 104, and the server 106 can each communicate using the network 108.

  Turning to FIG. 1B, FIG. 1B is a simplified block diagram of a communication system 100b for malware mitigation, according to one embodiment of the present disclosure. The communication system 100b may include an electronic device 102b, a cloud service 104, and a server 106. The electronic device 102b may include a processor 110, memory 112, operating system 114, security module 118, and recovery environment 136. The electronic device 102b, the cloud service 104, and the server 106 can each communicate using the network 108.

  Turning to FIG. 1C, FIG. 1C is a simplified block diagram of a communication system 100c for malware mitigation according to one embodiment of the present disclosure. The communication system 100c may include an electronic device 102c, a cloud service 104, and a server 106. The electronic device 102c may include a processor 110, a memory 112, an operating system 114, a security module 118, and a secondary operating system 138. The electronic device 102c, the cloud service 104, and the server 106 can each communicate using the network 108.

  In the exemplary embodiment, communication systems 100a-100c may be configured to study the behavior of malicious applications in detail. Knowledge of malicious application behavior thus identifies infected electronic devices and repairs or mitigates the effects of malware on the electronic devices without having to re-image the electronic device Can be used. For example, the communication systems 100a-100c may be configured to use dynamic analysis of malware samples to repair infected machines that are infected by malware samples. Repair or mitigation can include using an iterative multi-stage approach. In one example, the recovery environment can be used to bypass evasion techniques used by malware during mitigation. In another example, behavioral knowledge about malware, behavioral knowledge about the family of malware to which the malware belongs, and sample and generic malware behavior can be used for malware detection and repair of malware-infected machines. Using dynamic analysis of malware samples can enable the ability to detect and repair from malware that cannot be detected by conventional antivirus software. In addition, malware can be repaired without the need to reimage infected electronic devices, and can prevent some loss of data, typically resulting from reimages.

  The elements of FIGS. 1A-1C may be coupled together through one or more interfaces using any suitable (wired or wireless) connection, which is a viable path for network (eg, network 108) communication. I will provide a. In addition, any one or more of these multiple elements of FIGS. 1A-1C may be combined or removed from the architecture based on the needs of a particular configuration. Each of the communication systems 100a-100c may include a configuration capable of Transmission Control Protocol / Internet Protocol (TCP / IP) communication for sending or receiving packets in the network. The communication systems 100a-100c may also operate with user datagram protocol / IP (UDP / IP) or any other suitable protocol as needed and based on specific needs.

  It is important to understand communications that can traverse the network environment for the purpose of illustrating the technology of a particular example of the communication systems 100a-100c. The following basic information can be considered as the basis by which this disclosure can be adequately explained.

  Most attempts to repair malware-infected electronic devices by reformatting the entire hard disk and reimaging the electronic device. This is an inconvenient process that not only makes the electronic device unproductive, but also causes data loss on the electronic device by deleting data that has not been backed up prior to reimage. Currently, re-image is one of very few reliable malware removal techniques because malware uses various techniques to avoid detection and repair. With currently popular detection technologies, it is not only difficult to repair from the presence of malicious files on infected electronic devices, but it is also very difficult to identify whether a host is infected in the first place. is there. What is needed is a system and method that can mitigate or repair malware on an infected electronic device without having to reimage the electronic device.

  A communication system for malware mitigation, as outlined in FIGS. 1A-1C, can solve these (and other) issues. The communication systems 100a-100c may be configured to analyze the suspected malware sample using behavior analysis techniques. For example, the pattern behavior generation module 132 may be configured to analyze a suspected malware sample using behavior analysis techniques. The technique may include the use of a combination of one or more of pattern matching, global reputation, program emulation, static analysis, dynamic analysis, or some other behavior analysis technique. Once the suspected malware sample has been analyzed, the system can be configured to generate a malware pattern behavior (eg, malware pattern behavior 124) of the malware based on the analysis. Malware pattern behavior may include various evasion and obfuscation techniques used by malware when captured by analysis. Malware pattern behavior can be an indicator of specific malware sample behavior.

  Based on the sample behavior, typical malware family behavioral knowledge can be used to identify the malware family associated with the sample behavior. As a result of research and analysis of known and new malware families, a set of behavior patterns that are unique to the identified malware family can be generated as family behavior. Most malware takes a behavioral pattern that is not exhibited by bona fide or benign software. As a result of the investigation and analysis, a set of behavior patterns generally indicated by malware may be created as generic malware behavior. Specific malware sample behavior, family behavior, and generic malware behavior may be combined into malware pattern behavior 124.

  Multiple elements of sample behavior, family behavior, and generic malware behavior can be combined into the malware detection module 120 and compared to the analysis log 126 to identify the malware. The analysis log 126 may be a log of activity on the system suspected of being infected with malware. In addition, sample behavior to generate detection tasks that can be configured to be performed to collect relevant environmental details, file system and registry information, and indicators of infection and avoidance in electronic devices. Multiple elements of family behavior and generic malware behavior may be combined in the malware mitigation module 122. A feedback loop to the malware mitigation module 122 can be used to analyze the results of the detection task to generate further specific tasks for detection and remediation of infection on the infected electronic device. The results of these tasks can be fed back to the malware mitigation module 122, which can generate additional tasks for execution. This sequence of operations may be repeated until the malware mitigation module 122 determines that the electronic device is clean from infections manifested by sample behavior and family behavior.

  Tasks can be executed on different platforms to reduce the ability to avoid detection of malware. For example, a task can be executed within a live operating system, which can be infected with malware and can interfere with the accuracy of detection or mitigation tasks. The task may be executed in a recovery environment 136 (eg, Windows® Recovery Environment (RE)) that is less likely to be infected by malware that can interfere with detection and mitigation tasks. The task may be performed using a secondary operating system 138 on the electronic device. The secondary operating system can be pushed on the electronic device using a file that can be mounted as a boot disk. Malware is most unlikely to interfere with mitigation tasks performed on secondary operating systems.

  Turning to the infrastructure of FIGS. 1A-1C, communication systems 100a-100c according to an exemplary embodiment are shown. In general, the communication systems 100a-100c may be implemented in a network of any type or topology. Network 108 represents a series of points or nodes of interconnected communication paths that receive and transmit packets of information that propagate through communication systems 100a-100c. The network 108 provides a communication interface between nodes, and can be any local area network (LAN), virtual local area network (VLAN), wide area network (WAN), wireless local area network (WLAN), metropolitan area network (MAN). ), Intranet, extranet, virtual private network (VPN), and any other suitable architecture or system that facilitates communication in a network environment, or any suitable combination thereof, wired and / or wireless It can be configured to include communications.

  In the communication systems 100a-100c, network traffic including packets, frames, signals, data, etc. may be transmitted and received via any suitable communication messaging protocol. A suitable communication messaging protocol is the Open Systems Interconnection (OSI) model, or any derivative or variant thereof (eg, Transmission Control Protocol / Internet Protocol (TCP / IP), User Datagram Protocol / IP (UDP) / IP)), and the like. In addition, wireless signaling over cellular networks may also be provided in communication systems 100a-100c. Suitable interfaces and infrastructure can be provided to enable communication with the cellular network.

  As used herein, the term “packet” refers to a unit of data that can be routed between a source node and a destination node on a packet-switched network. The packet includes a source network address and a destination network address. These network addresses can be Internet Protocol (IP) addresses in the TCP / IP messaging protocol. The term “data” as used herein refers to any type of binary, numeric, audio, video, in any suitable format that can be communicated from one point to another in an electronic device and / or network. Refers to text or script data, or any type of source or object code, or any other suitable information. In addition, messages, requests, responses, and queries are in the form of network traffic and may thus comprise packets, frames, signals, data, and the like.

  In an exemplary implementation, electronic devices 102a-102c, cloud service 104, and server 106 are network elements that are operable to exchange information in a network environment, such as network equipment, servers, routers, switches, It is intended to encompass gateways, bridges, load balancers, processors, modules, or any other suitable device, component, element or object. The network elements receive, transmit, and / or otherwise communicate any suitable hardware, software, component, module, or object that facilitates their operation and data or information in a network environment. A suitable interface may be included. This may include appropriate algorithms and communication protocols that allow for effective exchange of data or information.

  With respect to internal structures associated with communication systems 100a-100c, each of electronic devices 102a-102c, cloud service 104, and server 106 includes a plurality of memory elements for storing information used in the operations outlined herein. Can be included. Each of electronic devices 102a-102c, cloud service 104 and server 106 may be any suitable memory element (eg, random access memory (RAM), read only memory (ROM), erasable programmable ROM (EPROM), electrical erasure). Programmable ROM (EEPROM), application specific integrated circuit (ASIC), etc.), software, hardware, firmware, or any other suitable component, device as required and based on specific needs , Elements, or objects can hold information. Any memory item described herein is to be interpreted as encompassed within the broad term “memory element”. Further, information used, tracked, transmitted, or received in communication systems 100a-100c may be provided in any database, register, queue, table, cache, control list, or other storage structure, such as All can be referenced in any suitable time frame. Any such storage option may also be included within the broad term “memory element” as used herein.

  In certain exemplary implementations, the functions outlined herein are logic encoded in one or more tangible media that may include non-transitory computer-readable media (eg, embedded logic provided to an ASIC, It may be implemented by digital signal processor (DSP) instructions, software (potentially including object code and source code) executed by a processor or other similar machine, etc. In some of these examples, the memory elements are May store data used for the operations described herein, including software, logic, code, or processor instructions that are executed to perform the activities described herein. Contains storable memory elements.

  In an exemplary implementation, network elements of communication system 100a-100c, such as electronic devices 102a-102c, cloud service 104, and server 106, implement software modules (e.g., that implement or facilitate operations outlined herein) (e.g. Security module 118, malware detection module 120, malware mitigation module 122, network security module 130, and pattern behavior generation module module 132). These modules may be suitably combined in any suitable manner that may be based on specific configurations and / or provisioning needs. In exemplary embodiments, such operations may be performed by hardware, implemented outside of those elements, or included in some other network device that implements the intended function. Further, the modules may be implemented as software, hardware, firmware, or any suitable combination thereof. These elements may also include software (or reciprocating software) that can collaborate with other network elements to implement operations, as outlined herein.

  In addition, each of electronic devices 102a-102c, cloud service 104, and server 106 may include a processor capable of executing software or algorithms that may perform activities as described herein. The processor may execute any type of instructions associated with the data so as to implement the operations detailed herein. In one example, the processor may convert an element or article (eg, data) from one state or thing to another. In another example, the activities outlined herein may be implemented by fixed logic or programmable logic (eg, software / computer instructions executed by a processor) and are identified herein. Is any type of programmable processor, programmable digital logic (eg, Field Programmable Gate Array (FPGA), EPROM, EEPROM, including digital logic, software, code, electronic instructions, or any suitable combination thereof) ), Or ASIC. Any potential processing elements, modules and machines described herein are to be construed as encompassed within the broad term “processor”.

  The electronic devices 102a-102c can be network elements and include, for example, desktop computers, laptop computers, mobile devices, personal digital assistants, smartphones, tablets, or other similar devices. The cloud service 104 is configured to provide cloud services to the electronic devices 102a-102c. A cloud service can generally be defined as the use of computing resources supplied as a service across a network such as the Internet. Typically, compute, storage, and network resources are provided in the cloud infrastructure, effectively shifting the workload from the local network to the cloud network. Server 106 may be a network element such as a server or a virtual server, such as a client, customer, endpoint, that wishes to initiate communication in communication systems 100a-100c via some network (eg, network 108). Or it can be associated with an end user. The term “server” includes devices used to fulfill client requests in communication systems 100a-100c and / or to perform some computational tasks on behalf of clients. Although security module 118 is shown in FIGS. 1A-1C as being located in electronic devices 102a-102c, respectively, this is for illustrative purposes only. The security modules 118 may be combined or separated in any suitable configuration. Further, security module 118 may be integrated with or distributed within another network accessible by electronic devices 102a-102c, such as cloud service 104 or server 106.

  Turning to FIG. 2, FIG. 2 is a simplified block diagram of portions of communication systems 100a-100c for malware mitigation, according to one embodiment of the present disclosure. The pattern behavior generation module 132 uses one or more combinations of pattern matching, global reputation, static analysis, dynamic analysis, program emulation, or some other behavior analysis technique to analyze a sample or application. Can be configured. The analyzed sample can be generalized and used to generate malware pattern behavior 124. Malware pattern behavior 124 may include sample behavior 140 and family behavior 142. Sample behavior 140 may include specific malware sample behavior. Family behavior 142 may be generated from a family of malware associated with or including the analyzed sample.

  Since malware can use different techniques to avoid detection, a combination of different techniques is used to analyze the sample and detect if it is actually malicious. For example, pattern matching can be used to identify well-known samples, and the same insights show what changes the sample will make to the system and what evasion techniques the malware uses. Can be used to identify. Similarly, a sample global reputation based on input from a global database can be used to identify malware behavior.

  Program emulation can be used to run a malware sample in an emulated environment, study that environment for changes made by the malware sample, and identify evasion techniques used by the malware. For example, when the Windows (registered trademark) API hook mechanism is used to hide malware from the list of operation processes, the same behavior information is recorded and used as an avoidance technique.

  Static analysis is another way in which the pattern behavior generation module 132 can identify malware behavior. The technique uses a pre-known pattern of assembly instructions to identify specific behavior in the malware executable image. Malware executables may be encrypted or obfuscated and only decrypted if the malware sample is actually running on the machine. In such a case, the malware can be executed on the machine and the static analysis is performed on the extracted content. The pattern of code used by the avoidance technique can be identified and made part of the pattern behavior generation module 132.

  Dynamic analysis can be used by the pattern behavior generation module 132 to study changes made to the live virtual machine after executing the malware sample. Different techniques similar to API hooks can be used to detect changes made to the system by malware. Various evasion techniques can be identified by using knowledge that the malware is actually executed on the machine and by analyzing various system artifacts similar to the operating process or loaded module from that perspective . For example, the malware is malwareSample. If a process called exe is started and the process is not visible in the list of operating processes on the system, the process is used as an evasion technique where the malware hides the process in which the malware is running.

  After the sample is analyzed, reports / artifacts about the analysis of the malware at different stages can be generated. The report can be analyzed and a set of behavioral logs generated. Logs analyze indicators of malware behavior from different stages of analysis and combine it with a full behavior analysis log. The analysis log is a sample behavior artifact (eg, sample behavior 140) that may be used by the malware mitigation module 122.

  Examples of multiple elements of “sample behavior” may include file names, registry entries, and kernel objects (similar to mutex) generated by malware. Avoidance techniques can also be manifested in the sample behavior artifact. It can also be ascertained whether the malware generates hidden files, whether the malware behaves like a rootkit, or whether the malware processes can be enumerated.

  The sample behavior log may analyze and match the behavior of known malware families to identify a particular malware sample family. A database of malware family behaviors 150 may be maintained for this purpose. Once a family is identified, common behavior indicators for all members of this particular malware family can be collected from a database of malware family behaviors 150 and a family behavior 142 for the malware sample can be generated.

  An example of family behavior may include information about polymorphic malware behavior. Some malware may generate a file in the user's AppData folder. When run in different instances, the same sample randomizes the file name to generate a file with a different name, and therefore the malware cannot be identified by the file generated by that malware. In such cases, malware can be identified by a pattern of commonality in randomized behavior. For example, some malware may generate files in the same subfolder within the AppData folder with different names but using the same md5 hash. If a property that produces a file with a different name but the same md5 checksum can be attributed to all samples of the malware family, this property can be used as an indicator to identify infection of all samples of that family. Such information consisting of family-specific behavior is provided to the malware detection module 120 and the malware mitigation module 122, which may use this information to generate detection / mitigation tasks. For example, for a family sample that renames a file but keeps the folder name and md5 checksum the same, an identification task can be generated to look for a specific md5 in a specific folder in the electronic device.

  Identification of generic or common malware-like behavior can include determining behavior parameters that are common to known malware and rarely exhibited by benign software. This includes identifying common patterns, such as the creation of specific registry entries, the installation of unsigned or unverified binaries into a startup folder, and the like. For example, unsigned programs that exist in the startup folder, especially if they do not have a corresponding entry in the list of installed programs, or binaries for such components are verified. It is generally known to be malicious if it was not signed by a publisher. Malware detection module 120 and so as to look for such binaries from within the system and compare their checksums with known malware or family behaviors to identify and thus repair potential infections. Malware mitigation module 122 may generate a detection task (eg, analysis log 126) and a mitigation task (eg, reverse malware behavior operation 128).

  Turning to FIG. 3, FIG. 3 is a simplified diagram of portions of communication systems 100a-100c for malware mitigation according to one embodiment of the present disclosure. Security module 118 may be configured to communicate malware pattern behavior 124 with malware detection module 120. The malware detection module 120 compiles various indicators of malware behavior (eg, sample behavior 140, family behavior 142, generic malware behavior 144, etc.) to identify whether the electronic devices 102a-102c are infected. If configured and infected, the malware mitigation module 122 can be used to repair the electronic devices 102a-102c from infection. In one example, the malware mitigation module 122 may analyze all indicators and generate a task to identify infection indicators in the electronic devices 102a-102c. Based on specific sample behavior, family behavior, and generic behavior (eg, sample behavior 140, family behavior 142, and generic malware behavior 144), a malware infection probably occurred before and no machine restart occurred In an execution environment that may be the task can be executed. Malware may infect the machine's memory, registry, and file system. Some indicators of infection, similar to file system and registry changes made by malware, are difficult to find in this environment because malware may have corrupted the operating system to hide its presence indicator It can be. Since some other indicators are available in the operating system's live memory and will be lost when the machine is restarted, they can only be found in this environment. These include mutexes, events, API hooks, etc. installed on the electronic devices 102a-102c.

  In another example, the task may be performed from an environment executing from a write protected disk image file residing in the operating system. This can be useful for recovering the OS file in case of an infection of operating system file corruption. The same environment can be used to bypass the malware detection avoidance capability, remove the boot persistence of the malware sample, and free the machine from infection.

  For malware that avoids detection in Windows® RE, the only way to identify and repair or mitigate the malware is to boot the machine into a secondary OS and repeat through the machine's files NTFS driver Can be used to look for indicators of file system-based infection. Selection of a secondary OS that supports iteration through the NTFS file system can help detect and delete evasive file system artifacts. Tasks that match behavior indicators from specific sample, family, and generic malware behavior can be generated. A detection task may be generated to look for a specific registry key if a sample that creates a registry entry is found, such as, for example, launching an executable program as part of a Windows startup process.

  The results of detection and mitigation task execution may be fed back to malware mitigation module 122 via feedback loop 146. The malware mitigation module 122 may determine the next action based on the analysis of the results from the task. In another example, the malware detection module 120 may analyze the task results. If the result indicates that the electronic device is infected, the malware mitigation module 122 executes in one of the three environments described above (eg, sandbox 116, recovery environment 136, or secondary operating system 138). A mitigation task to be done can be generated. If the result indicates that there is no infection, the malware mitigation module 122 may check again in another environment and decide to generate a task accordingly. Similarly, if the malware mitigation module 122 can confirm that there is no indication of any known infection, the malware mitigation module 122 may declare the electronic device to be clean or benign.

  The feedback loop 146 can be performed iteratively again to completely remove the electronic device from infection. For example, the malware detection module 120 determines that a malware sample that infects the file system and registry is found, but the family behavior indicates that the file name and md5 are randomized from one instance to another. If so, the malware mitigation module 122 may generate a task to look for malware samples in the live environment. If the malware sample is not found, the malware mitigation module 122 may regenerate a task to look for the malware sample in the recovery environment. If no evidence of the malware sample is found, a task can be generated to look for a specific folder. When a particular folder is found, a task can be generated that calculates the md5 of all files in the folder. From a known bad md5 checksum of a particular family, if no md5 match is found, a task may be created that looks for a registry entry that has been modified to run the program on machine startup. If a suspicious program recorded as a startup program is found, a task can be generated that looks for an executable file associated with the program, and the md5 of the malware sample is within a known bad md5 checksum Can be found. A task can be generated that deletes this malware sample and registry entry and reboots the machine in a live Windows OS to look for in-memory indicators and events similar to mutex. Finally, after the results of several iterations, the malware mitigation module 122 may determine whether the machine has been completely released from a particular malware sample.

  Turning to FIG. 4, FIG. 4 is an exemplary flowchart illustrating possible operations of the flow 400 that may be associated with malware mitigation, according to one embodiment. In one embodiment, one or more operations of flow 400 may be performed by security module 118, malware detection module 120, malware mitigation module 122, network security module 130, and pattern behavior generation module 132. At 402, the malware is enabled. At 404, actions performed by the malware are observed and changes to the system are recorded. For example, the pattern behavior generation module 132 may observe the operations performed by the malware and generate the malware pattern behavior 124. At 406, an undo action is generated that reverses changes to the system caused by the malware.

  Turning to FIG. 5, FIG. 5 is an exemplary flowchart illustrating possible operations of the flow 500 that may be associated with malware mitigation according to one embodiment. In one embodiment, one or more operations of flow 500 may be performed by security module 118, malware detection module 120, malware mitigation module 122, network security module 130, and pattern behavior generation module 132. At 502, the malware has changed the system. For example, the malware detection module 120 may determine that the malware has changed or altered the electronic device 102a. At 504, malware is identified. For example, the analysis log 126 can be used to identify malware. The analysis log 126 may be generated by the malware detection module 120 by logging a change in the electronic device 102a. At 506, malware pattern behavior is determined. At 508, reverse malware behavior behavior is determined. For example, a reverse malware behavior operation 128 is determined. At 510, a reverse malware behavior operation is performed that undoes the changes that the malware made to the system. For example, the malware mitigation module 122 may perform a reverse malware behavior operation 128 that undoes changes made by the malware to the electronic device 102a.

  FIG. 6 illustrates a computing system 600 arranged in a point-to-point (PtP) configuration, according to one embodiment. In particular, FIG. 6 shows a system in which a processor, memory, and input / output devices are interconnected by multiple point-to-point interfaces. In general, one or more of the network elements of communication systems 100a-100c may be configured in the same or similar manner as computing system 600.

  As shown in FIG. 6, system 600 may include a number of processors, of which only two of processors 670 and 680 are shown for clarity. While two processors 670 and 680 are shown, it should be understood that embodiments of the system 600 may also include only one such processor. Processors 670 and 680 may each include a set of cores (ie, processor cores 674A and 674B, and processor cores 684A and 684B) to execute multiple threads of a program. The core may be configured to execute instruction code in a manner similar to that described above with reference to FIGS. 1A-5. Each processor 670, 680 may include at least one shared cache 671, 681. Shared cache 671, 681 may store data (eg, instructions) utilized by one or more components of processors 670, 680, such as processor cores 674 and 684.

  Processors 670 and 680 may also include integrated memory controller logic (MC) 672 and 682, respectively, for communicating with memory elements 632 and 634. Memory elements 632 and / or 634 may store various data used by processors 670 and 680. In an alternative embodiment, the memory controller logic 672 and 682 may be discrete logic independent of the processors 670 and 680.

  Processors 670 and 680 may be any type of processor and may exchange data via point-to-point (PtP) interface 650 using point-to-point interface circuits 678 and 688, respectively. Processors 670 and 680 may each exchange data with chipset 690 via individual point-to-point interfaces 652 and 654 using point-to-point interface circuits 676, 686, 694 and 698, respectively. Chipset 690 may also exchange data with high performance graphics circuit 638 via high performance graphics interface 639 using interface circuit 692 which may be a PtP interface circuit. In alternative embodiments, any or all of the illustrated PtP links of FIG. 6 may be implemented as a multidrop bus rather than a PtP link.

  Chipset 690 may communicate with bus 620 via interface circuit 696. Bus 620 may have one or more devices communicating therewith, such as bus bridge 618 and I / O device 616. Via bus 610, bus bridge 618 may communicate through keyboard / mouse 612 (or other input device such as a touch screen, trackball, etc.), communication device 626 (modem, network interface device, or computer network 660). Other types of communication devices), audio I / O devices 614, and / or data storage devices 628 may communicate with other devices. Data storage device 628 may store code 630 that may be executed by processors 670 and / or 680. In alternative embodiments, any part of the bus architecture may be implemented with one or more PtP links.

  The computer system illustrated in FIG. 6 is a schematic illustration of an embodiment of a computing system that can be utilized to implement the various embodiments described herein. It will be appreciated that the various components of the system illustrated in FIG. 6 may be combined in a system on chip (SoC) architecture, or any other suitable configuration. For example, the embodiments disclosed herein may be incorporated into systems that include mobile devices, such as smart cellular phones, tablet computers, personal digital assistants, portable gaming devices, and the like. It will be appreciated that these mobile devices may comprise a SoC architecture in at least some embodiments.

  Turning to FIG. 7, FIG. 7 is a simplified block diagram associated with an exemplary ARM ecosystem SoC 700 of the present disclosure. At least one exemplary implementation of the present disclosure may include the malware mitigation features described herein, and an ARM component. For example, the example of FIG. 7 may be associated with any ARM core (eg, A-7, A-15, etc.). In addition, the architecture can be any type of tablet, smartphone (including Android® phone, iPhone®), iPad®, Google Nexus®, Microsoft Surface®, personal It can be part of a computer, server, video processing component, laptop computer (including any type of notebook), Ultrabook® system, any type of touch-enabled input device, etc.

  In this example of FIG. 7, the ARM ecosystem SoC 700 is associated with a plurality of mobile industry processor interface (MIPI) / high definition multimedia interface (HDMI) links that couple to a liquid crystal display (LCD). A core 706-907, an L2 cache control 708, a bus interface unit 709, an L2 cache 710, a graphics processing unit (GPU) 715, an interconnect 702, a video codec 720, and an LCD I / F 725 may be included.

  The ARM ecosystem SoC 700 includes a subscriber identification module (SIM) I / F 730, a boot read only memory (ROM) 735, a synchronous dynamic random access memory (SDRAM) controller 740, a flash controller 745, and a serial peripheral device interface (SPI) master. 750, suitable power control 755, dynamic RAM (DRAM) 760, and flash 765 may also be included. In addition, one or more exemplary embodiments include one or more communication functions, interfaces, and Bluetooth (R) 770, 3G modem 775, Global Positioning System (GPS) 780, and 802.11 Wi- A function such as the example of Fi785 may be included.

  In operation, the example of FIG. 7 may provide processing capabilities with relatively low power consumption that enables various types of computing (eg, mobile computing, high-end digital homes, servers, wireless infrastructure, etc.). . In addition, such an architecture can include any number of software applications (e.g., Android (R), Adobe (R) Flash (R) player, Java (R) Platform Standard Edition (Java (R)). SE), Java® FX, Linux®, Microsoft Windows® Embedded, Symbian, and Ubuntu, etc.). In at least one exemplary embodiment, the core processor may implement an out-of-order superscalar pipeline with a combined low latency level 2 cache.

  FIG. 8 illustrates a processor core 800 according to one embodiment. The processor core 800 may be a core for any type of processor, such as a microprocessor, embedded processor, digital signal processor (DSP), network processor, or other device that executes code. Although only one processor core 800 is shown in FIG. 8, the processor may alternatively include more than one of the processor cores 800 shown in FIG. For example, the processor core 800 represents one exemplary embodiment of the processor cores 674a, 674b, 684a and 684b shown and described with reference to the processors 670 and 680 of FIG. The processor core 800 may be a single thread core or, for at least one embodiment, the processor core 800 may include more than one hardware thread context (or “logical processor”) per core. Can be multi-threaded.

  FIG. 8 also illustrates memory 802 coupled to processor core 800 according to one embodiment. The memory 802 can be any of a wide variety of memories (including various layers of the memory hierarchy) as is known or otherwise available to those skilled in the art. Memory 802 may include code 804 that may be one or more instructions executed by processor core 800. The processor core 800 may follow the program sequence of instructions indicated by code 804. Each instruction enters the front end logic 806 and is processed by one or more decoders 808. The decoder may generate as its output a micro-operation, such as a fixed-width micro-operation in a predefined format, or other instruction, micro-instruction, or control signal that reflects the original code instruction . The front-end logic 806 also includes register renaming logic 810 and scheduling logic 812, which generally allocates resources and queues operations corresponding to instructions for execution.

  The processor core 800 may also include execution logic 814 having a set of execution units 816-1 to 816-N. Some embodiments may include multiple execution units dedicated to a particular function or set of functions. Other embodiments may include only one execution unit or one execution unit that may perform a particular function. Execution logic 814 performs the operation specified by the code instruction.

  After completing the execution of the operation specified by the code instruction, the back-end logic 818 may retire the code 804 instruction. In one embodiment, the processor core 800 allows for out-of-order execution but requires in-order retirement of instructions. Retirement logic 820 may take various known forms (eg, a reorder buffer or the like). In this aspect, the processor core 800 is in view of at least the output generated by the decoder, the hardware registers and tables utilized by the register renaming logic 810, and any registers (not shown) rewritten by the execution logic 814. Are converted during the execution of the code 804.

  Although not shown in FIG. 8, the processor may include other elements on a chip having a processor core 800, at least some of which are shown and described herein with reference to FIG. For example, as shown in FIG. 6, the processor may include memory control logic along with the processor core 800. The processor may include I / O control logic and / or may include I / O control logic integrated with memory control logic.

  Note that, along with the examples provided herein, the interaction can be described in terms of two, three, or more network elements. However, this is done for purposes of clarity and illustration only. In certain cases, referring to a limited number of network elements may make it easier to explain one or more of the functions of a given set of flows. It should be understood that the communication systems 100a-100c and their teachings are easily extensible and can accommodate multiple components and more complex / sophisticated arrangements and configurations. Accordingly, the examples provided should not limit the scope or preclude the broad teaching of communication systems 100a-100c as potentially applied to a myriad of other architectures.

  The operations in the foregoing flow diagrams (ie, FIGS. 4 and 5) show only some of the possible correlated scenarios and patterns that can be performed by or in the communication systems 100a-100c. It is also important to keep in mind. Some of these operations may be deleted or removed as needed, or these operations may be significantly rewritten or modified without departing from the scope of the present disclosure. In addition, many of these operations have been described as being performed concurrently with or in parallel with one or more additional operations. However, the timing of these operations can be changed significantly. The foregoing operational flow is provided for purposes of illustration and description. Considerable flexibility is provided by the communication systems 100a-100c in that any suitable arrangement, time series, configuration, and timing mechanism may be provided without departing from the teachings of the present disclosure.

  Although the present disclosure has been described in detail with reference to particular arrangements and configurations, these exemplary configurations and arrangements can be varied significantly without departing from the scope of the present disclosure. Further, specific components can be combined, separated, removed, or added based on specific needs and implementations. In addition, although the communication systems 100a-100c are shown with reference to specific elements and operations that facilitate communication processing, these elements and operations are optional that implement the intended functions of the communication systems 100a-100c. May be replaced by any suitable architecture, protocol, and / or process.

  Numerous other changes, substitutions, variations, changes, and modifications may be ascertained by those skilled in the art, and the disclosure is intended to cover such changes, substitutions, variations, changes within the scope of the appended claims , And all modifications are intended to be covered. In assisting any reader of the United States Patent and Trademark Office (USPTO) and, in addition, any patent issued with respect to the present application, in interpreting the claims appended hereto, I would like to note the following: (A) Applicant shall note that any claim attached shall be present on the date of filing of this specification, unless the word “means for” or “step for” is specifically used in that particular claim. There is no intent to invoke 35 USC 112, sixth paragraph. (B) Applicants are not intended to limit the present disclosure in any way whatsoever, provided that they are not reflected in the appended claims.

[Other notes and examples]
Example C1, when executed by at least one processor, causes at least one processor to execute malware in the system, records changes to the system caused by the execution of malware, One or more instructions that generate a detection task for detection, wherein the detection task is at least partially machine-readable storage having instructions based on changes to the system caused by execution of malware It is a medium.

  In Example C2, the subject of Example C1 is that the detection task is optionally generated using one or more of pattern matching, global reputation analysis, program emulation, static analysis, and dynamic analysis of malware. Can be included.

  In Example C3, the subject matter of any one of Examples C1-C2 is that if the instruction is executed by at least one processor, the at least one processor further identifies a malware family associated with the malware, and the malware family Can optionally include family behavior and the detection task can be based in part on family behavior.

  In Example C4, the subject matter of any one of Examples C1-C3 can optionally include that the detection task is based in part on generic malware behavior.

  In Example C5, the subject matter of any one of Examples C1-C4 is that if the instruction is executed by at least one processor, the at least one processor is further used to detect the infected electronic Optionally, identifying the device and generating a mitigation task that mitigates the change of the infected electronic device caused by malware may be included.

  In Example C6, any one of the subjects of Examples C1-C5 can optionally include the mitigation task being performed in a recovery environment.

  In Example C7, any one of the subjects of Examples C1-C6 can optionally include that the mitigation task is performed using a secondary operating system on the infected electronic device.

  In Example C8, any one of the subjects of Examples C1-C7 can optionally include a secondary operating system being pushed as a boot disk onto the infected electronic device.

  In Example A1, the apparatus may include a pattern behavior generation module that enables execution of malware in the system, records changes to the system caused by the execution of malware, and detects malware in the electronic device. Configured to generate a detection task for, based at least in part on changes to the system caused by the execution of malware.

  In Example A2, the subject of Example A1 is that the detection task is optionally generated using one or more of pattern matching, global reputation analysis, program emulation, static analysis, and dynamic analysis of malware. Can be included.

  In Example A3, the subject matter of any one of Examples A1-A2 can optionally include that the pattern behavior generation module is further configured to further identify a malware family associated with the malware, Includes family behavior, and the detection task is based in part on family behavior.

  In Example A4, any one of the subjects of Examples A1-A3 may optionally include that the detection task is based in part on generic malware behavior.

  In Example A5, the subject matter of any one of Examples A1-A4 is that the pattern behavior generation module is further configured to communicate the detection task to the security module, and the security module uses the generated detection task. , May optionally include configuring the mitigation task to identify the infected electronic device and mitigate changes to the infected electronic device caused by malware.

  In Example A6, any one of the subjects of Examples A1-A5 can optionally include the mitigation task being performed in a recovery environment.

  In Example A7, any one of the subjects of Examples A1-A6 can optionally include that the mitigation task is performed using a secondary operating system on the infected electronic device.

  In Example A8, any one of the subjects of Examples A1-A7 can optionally include a secondary operating system being pushed as a boot disk onto the infected electronic device.

  Example M1 is enabling the execution of malware in the system, recording changes to the system caused by the execution of malware, and generating a detection task for detection of malware in an electronic device; The detection task is a method that includes generating, at least in part, based on changes to the system caused by execution of malware.

  In Example M2, the subject of Example M1 is that the detection task is optionally generated using one or more of pattern matching, global reputation analysis, program emulation, static analysis, and dynamic analysis of malware. Can be included.

  In Example M3, the subject matter of any one of Examples M1-M2 is to identify the malware family associated with the malware, where the malware family includes the family behavior and the detection task is based in part on the family behavior Optionally identifying.

  In Example M4, any one of the subjects of Examples M1-M3 may optionally include that the detection task is based in part on generic malware behavior.

  In Example M5, any one of the subjects of Examples M1-M4 uses the generated detection task to identify the infected electronic device and changes to the infected electronic device caused by malware And optionally generating a mitigation task.

  In Example M6, any one of the subjects of Examples M1-M5 can optionally include the mitigation task being performed in a recovery environment.

  In Example M7, any one of the subjects of Examples M1-M6 may optionally include that the mitigation task is performed using a secondary operating system on the infected electronic device.

  Example S1 is a system for repairing from malware, the system includes a pattern behavior generation module and a security module, which allows the execution of malware in the system and is caused by the execution of malware The system is recorded to generate detection tasks for malware detection on electronic devices, the detection tasks based at least in part on changes to the system caused by malware execution, The security module is configured to identify an infected electronic device using the generated detection task and generate a mitigation task that mitigates changes to the infected electronic device caused by malware.

  In Example S2, the subject of Example S1 is that the detection task is optionally generated using one or more of pattern matching, global reputation analysis, program emulation, static analysis, and dynamic analysis of malware. Can be included.

  Example X1 is a machine-readable storage medium comprising machine-readable instructions for implementing a method or for realizing an apparatus, as shown in any one of Examples A1-A8 or M1-M7 It is. Example Y1 is an apparatus that includes means for performing any of the example methods M1-M7. In Example Y2, the subject of Example Y1 may optionally include means including a processor and a memory for performing the method. In Example Y3, the subject of Example Y2 can optionally include a memory that includes machine-readable instructions.

Claims (25)

At least one processor,
Procedures that allow the system to run malware,
Recording the changes to the system caused by the execution of the malware;
A procedure for generating a detection task for detection of the malware in an electronic device, wherein the detection task is based at least in part on the change to the system caused by the execution of the malware;
A computer program for executing   The computer program according to claim 1, wherein the detection task is generated using one or more of pattern matching, global reputation analysis, program emulation, static analysis, and dynamic analysis of the malware. The at least one processor;
3. A procedure for identifying a malware family associated with the malware, wherein the malware family includes a family behavior, and wherein the detection task is further based on the family behavior to further execute a procedure. A computer program described in 1.   The computer program according to claim 1, wherein the detection task is based in part on generic malware behavior. The at least one processor;
Using the generated detection task to identify an infected electronic device;
Generating a mitigation task to mitigate the change to the infected electronic device caused by the malware;
The computer program according to any one of claims 1 to 4, wherein the computer program is further executed.
  The computer program product of claim 5, wherein the mitigation task is executed in a recovery environment.   The computer program according to claim 5 or 6, wherein the mitigation task is performed using a secondary operating system on the infected electronic device.   The computer program product of claim 7, wherein the secondary operating system is pushed as a boot disk onto the infected electronic device. It has a pattern behavior generation module,
The pattern behavior generation module includes:
Allowing malware to run in the system,
Record changes to the system caused by the execution of the malware;
Generating a detection task for detection of the malware in an electronic device, the detection task based at least in part on the change to the system caused by the execution of the malware;
apparatus.   The apparatus of claim 9, wherein the detection task is generated using one or more of pattern matching, global reputation analysis, program emulation, static analysis, and dynamic analysis of the malware. The pattern behavior generation module further includes:
The apparatus according to claim 9 or 10, wherein a malware family associated with the malware is identified, the malware family includes a family behavior, and the detection task is based in part on the family behavior.   12. The apparatus according to any one of claims 9 to 11, wherein the detection task is based in part on generic malware behavior. The pattern behavior generation module further includes:
Communicating the detection task to a security module, the security module
Using the generated detection task to identify infected electronic devices;
13. Apparatus according to any one of claims 9 to 12, which generates a mitigation task that mitigates the change to the infected electronic device caused by the malware.   The apparatus of claim 13, wherein the mitigation task is performed in a recovery environment.   15. The apparatus according to claim 13 or 14, wherein the mitigation task is performed using a secondary operating system on the infected electronic device.   The apparatus of claim 15, wherein the secondary operating system is pushed as a boot disk onto the infected electronic device. Executing malware in the system;
Recording changes to the system caused by the execution of the malware;
Generating a detection task for detection of the malware in an electronic device, the detection task based at least in part on the change in the system caused by the execution of the malware; Including methods.   The method of claim 17, wherein the detection task is generated using one or more of pattern matching, global reputation analysis, program emulation, static analysis, and dynamic analysis of the malware. Identifying a malware family associated with the malware, wherein the malware family includes a family behavior, and the detection task is further based in part on the family behavior;
The method according to claim 17 or 18.   20. A method as claimed in any one of claims 17 to 19, wherein the detection task is based in part on generic malware behavior. Identifying an infected electronic device using the generated detection task;
Generating a mitigation task to mitigate the change to the infected electronic device caused by the malware;
21. The method according to any one of claims 17 to 20, further comprising:   The method of claim 21, wherein the mitigation task is performed in a recovery environment.   23. The method of claim 21 or 22, wherein the mitigation task is performed using a secondary operating system on the infected electronic device. A system for repairing from malware, the system comprising:
A pattern behavior generation module;
A security module;
With
The pattern behavior generation module includes:
Allowing malware to run in the system,
Record changes to the system caused by the execution of the malware;
Generating a detection task for detection of the malware in an electronic device, the detection task based at least in part on the change to the system caused by the execution of the malware;
The security module is
Using the generated detection task to identify infected electronic devices;
A system that generates a mitigation task that mitigates the change to the infected electronic device caused by the malware.   25. The system of claim 24, wherein the detection task is generated using one or more of pattern matching, global reputation analysis, program emulation, static analysis, and dynamic analysis of the malware.

Images