JP6668390B2 - Malware mitigation - Google Patents

Description

[Cross-reference to related application]
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 herein by reference in its entirety. Incorporated in the specification.

  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 has enabled the 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 communications and personal communications, it has also resulted in malicious operators gaining unauthorized access to computers and computer networks, and the intentional or carelessness of confidential information. , As a means of disclosure.

  Malicious software ("malware") that infects a host computer can steal confidential information from a company or individual associated with the host computer, propagate to other host computers, and / or provide distributed denial of service It may be possible to perform any number of malicious actions, such as assisting an attack, sending spam or malicious emails from a host computer. Thus, significant management challenges remain to protect computers and computer networks from malicious and inadvertent exploits by malicious software.

  To provide a more complete 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 indicate like parts.

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

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

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

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

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

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

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

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

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

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

  The drawings are not necessarily drawn to scale as their dimensions may vary without departing significantly 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. Communication system 100a may include electronic device 102a, cloud service 104, and server 106. Electronic device 102a may include a processor 110, a memory 112, an operating system 114, a sandbox 116, and a security module 118. Security module 118 may include a malware detection module 120, a malware mitigation module 122, and a malware pattern behavior 124. Malware detection module 120 may include analysis log 126. 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 may each communicate using a 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. Communication system 100b may include electronic device 102b, cloud service 104, and server 106. Electronic device 102b may include processor 110, memory 112, operating system 114, security module 118, and recovery environment 136. Electronic device 102b, cloud service 104, and server 106 may each communicate using 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. Communication system 100c may include an electronic device 102c, a cloud service 104, and a server 106. 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. Electronic device 102c, cloud service 104, and server 106 may each communicate using network 108.

  In an exemplary embodiment, communication systems 100a-100c may be configured to study the behavior of malicious applications in detail. Knowledge of the behavior of the malicious application may thus identify the infected electronic device and repair or mitigate the effects of malware on the electronic device 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 the malware sample to repair an infected machine that is infected by the malware sample. Repair or mitigation may include using an iterative multi-stage approach. In one example, the recovery environment may 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 may be used for malware detection and repair of malware-infected machines. Using dynamic analysis of malware samples may enable the ability to detect and remediate malware that cannot be detected by traditional anti-virus software. In addition, malware can be repaired without having to reimage the infected electronic device, and can prevent some loss of data, typically resulting from reimaging.

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

  It is important to understand the communications that may traverse the network environment in order to demonstrate the techniques of the particular example of the communication systems 100a-100c. The following basic information may be considered as grounds on which the present disclosure can be adequately explained.

  Most attempts to repair an electronic device infected with malware by reformatting the entire hard disk and reimaging the electronic device. This is an inconvenient process that not only renders the electronic device unproductive, but also causes data loss on the electronic device by deleting data that has not been backed up prior to reimaging. Currently, reimaging is one of the few, reliable malware removal techniques, as malware uses various techniques to evade detection and remediation. With current 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 if 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.

  Communication systems for malware mitigation, such as those outlined in FIGS. 1A-1C, may solve these (and other) challenges. Communication systems 100a-100c may be configured to analyze suspected malware samples using behavior analysis techniques. For example, pattern behavior generation module 132 may be configured to analyze suspected malware samples using behavior analysis techniques. The techniques may include the use of one or more combinations 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 may be configured to generate a malware pattern behavior of the malware based on the analysis (eg, malware pattern behavior 124). Malware pattern behavior may include various evasion and obfuscation techniques used by malware when captured by analysis. Malware pattern behavior may be indicative of a particular malware sample behavior.

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

  Multiple elements of sample behavior, family behavior, and generic malware behavior may be combined into malware detection module 120 and compared to analysis log 126 to identify 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 collect relevant environmental details, file system and registry information, as well as indicators of infection and evasion in the electronic device. , Family behavior, and generic malware behavior may be combined in malware mitigation module 122. A feedback loop to the malware mitigation module 122 may be used to analyze the results of the detection task to generate more specific tasks for detecting and remediating infections 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.

  The tasks may be performed on different platforms to reduce the malware's ability to evade detection. For example, the task may be executed in a live operating system, which may be infected with malware, which may interfere with the accuracy of the detection or mitigation task. The tasks may be performed in a recovery environment 136 (eg, a Windows® recovery environment (RE)) that makes the detection and mitigation tasks less likely to be infected by malware that may interfere. The tasks may be performed using a secondary operating system 138 on the electronic device. The secondary operating system can be pushed on the electronic device with 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 FIG. 1A to FIG. 1C, communication systems 100a-100c according to an exemplary embodiment are shown. In general, communication systems 100a-100c may be implemented in any type or topology of network. Network 108 represents a series of interconnected communication path points or nodes that receive and transmit packets of information that propagate through communication systems 100a-100c. Network 108 provides a communication interface between the nodes, and includes 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 networked environment, or any suitable combination thereof, wired and / or wireless It can be configured to include communication.

  In the communication systems 100a-100c, network traffic, including packets, frames, signals, data, etc., may be sent and received by any suitable communication messaging protocol. Suitable communication messaging protocols are 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)), etc. In addition, wireless signaling over a cellular network may also be provided in communication systems 100a-100c. Suitable interfaces and infrastructure may 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 may be Internet Protocol (IP) addresses in the TCP / IP messaging protocol. As used herein, the term "data" refers to any type of binary, numeric, audio, video, in any suitable format that can be communicated from one point to another in electronic devices and / or networks. Refers to text or script data, or any kind of source or object code, or any other suitable information. In addition, messages, requests, responses, and queries are forms of network traffic and, therefore, may comprise packets, frames, signals, data, and so on.

  In an exemplary implementation, the electronic devices 102a-102c, the cloud service 104, and the server 106 are network elements, which are network devices, servers, routers, switches, operable to exchange information in a network environment. It is intended to include a gateway, bridge, load balancer, processor, module, or any other suitable device, component, element, or object. Network elements receive, transmit, and / or otherwise communicate data or information in any suitable hardware, software, component, module, or object, and network environment that facilitates their operation. May include a suitable interface to do so. This may include appropriate algorithms and communication protocols that allow for efficient exchange of data or information.

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

  In certain example implementations, the functions outlined herein may include logic encoded on one or more tangible media that may include non-transitory computer readable media (eg, embedded logic provided in 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 element is May store data used for the operations described herein, which may include software, logic, code, or processor instructions that are executed to perform the activities described herein. Includes storable memory elements.

  In an exemplary implementation, network elements of the communication systems 100a-100c, such as the electronic devices 102a-102c, the cloud service 104, and the server 106, implement software modules (e.g., 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, which may be based on the particular configuration and / or provisioning needs. In an exemplary embodiment, such operations may be performed by hardware, implemented outside of those elements, or included in some other network device that implements the intended functionality. Further, a module may be implemented as software, hardware, firmware, or any suitable combination thereof. These elements may also include software (or reciprocating software) that may work with other network elements to effectuate operation, as outlined herein.

  Additionally, 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. A processor may execute any type of instructions associated with data to achieve the operations detailed herein. In one example, a processor may convert an element or an item (eg, data) from one state or thing to another state or thing. In another example, the activities outlined herein may be implemented by fixed or programmable logic (eg, software / computer instructions executed by a processor) and elements identified herein. Can be any type of programmable processor, including digital logic, software, code, electronic instructions, or any suitable combination thereof, programmable digital logic (eg, field programmable gate array (FPGA), EPROM, EEPROM) ) Or an ASIC. Any potential processing elements, modules, and machines described herein should be construed as being encompassed within the broad term "processor."

  Electronic devices 102a-102c may be network elements, including, for example, desktop computers, laptop computers, mobile devices, personal digital assistants, smartphones, tablets, or other similar devices. Cloud service 104 is configured to provide cloud services to electronic devices 102a-102c. Cloud services may be generally defined as the use of computing resources provided as a service across a network such as the Internet. Typically, compute, storage, and network resources are provided in the cloud infrastructure, effectively shifting workload from the local network to the cloud network. The server 106 may be a network element such as a server or virtual server, and may include clients, customers, endpoints, Or it may be associated with an end user. The term "server" includes devices used to fulfill the needs of clients in communication systems 100a-100c and / or perform some computational tasks on behalf of clients. Although security module 118 is shown in FIGS. 1A-1C as being located on electronic devices 102a-102c, respectively, this is for illustrative purposes only. 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 a communication system 100a-100c for malware mitigation, according to one embodiment of the present disclosure. The pattern behavior generation module 132 may use 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. May be configured. The analyzed samples 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 a particular malware sample behavior. The family behavior 142 may be generated from a family of malware associated with or containing the analyzed sample.

  Since malware can use various techniques to evade detection, various combinations of techniques are used to analyze a sample and detect if it is in fact malicious. For example, pattern matching may be used to identify well-known samples, and the same findings may indicate what changes the samples make to the system and what evasion techniques malware uses. Can be used to identify. Similarly, a global reputation of the sample, based on input from a global database, can be used to identify malware behavior.

  Program emulation may be used to run a malware sample in an emulated environment, study the environment for changes made by the malware sample, and identify evasion techniques used by the malware. For example, if the Windows (registered trademark) API hook mechanism is used to hide malware from a list of operation processes, information of the same behavior is recorded and used as an evasion 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 will only be 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 the code used by the evasion technique can be identified and made part of the pattern behavior generation module 132.

  Dynamic analysis may be used by the pattern behavior generation module 132 to study changes made to the live virtual machine after running 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 the knowledge that the malware is actually executed on the machine, and by analyzing various system artifacts similar to operational processes or loaded modules from that point of view. . For example, if the malware is malwareSample. exe, and if that process is not visible in the list of active processes on the system, the process is used as an evasion technique, in which the malware hides the process in which it is running.

  After the sample has been analyzed, reports / artifacts for the analysis of the malware at different stages may be generated. The report can be analyzed and a set of behavioral logs can be generated. The logs analyze indicators of malware behavior from different stages of analysis and combine it with the complete behavior analysis log. The analysis log is a sample behavior artifact (eg, sample behavior 140) that may be used by 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 specified in sample behavior artifacts. It can also be ascertained whether the malware generates a hidden file, whether the malware behaves like a rootkit, or whether the process of the malware can be enumerated.

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

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

  Identification of generic or common malware-like behavior may involve determining behavior parameters that are common with known malware and that are rarely exhibited by benign software. This involves identifying common patterns, similar to the formation of certain registry entries, the installation of unsigned or unverified binaries in the startup folder, and so on. For example, unsigned programs that are present in the startup folder, especially if they do not have a corresponding entry in the list of installed programs, or the binaries of such components are verified If not signed by the publisher, it is generally known to be malicious. Malware detection module 120 and the like to look for such binaries in the system and compare their checksums to known malware or family behaviors to identify potential infections and thus remediate 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 a portion of a communication system 100a-100c for malware mitigation according to one embodiment of the present disclosure. Security module 118 may be configured to cause malware pattern behavior 124 to communicate with malware detection module 120. Malware detection module 120 may compile various indicators of malware behavior (eg, sample behavior 140, family behavior 142, generic malware behavior 144, etc.) to identify whether electronic devices 102a-102c are infected. If configured and, if infected, malware mitigation module 122 may be used to remediate electronic devices 102a-102c from infection. In one example, the malware mitigation module 122 can analyze all indicators and generate a task to identify indicators of infection at the electronic devices 102a-102c. Based on the particular sample behavior, family behavior and generic behavior (eg, sample behavior 140, family behavior 142, and generic malware behavior 144), a malware infection was likely to have occurred previously and the machine had not restarted In an execution environment that may be, the task can be performed. 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, as the malware may have destroyed the operating system to hide indicators of its existence Can be Since some other indicators are available in the operating system's live memory and will be lost upon machine restart, 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, tasks may be performed from an environment that resides in a write-protected disk image file that resides in an operating system. This can help to recover OS files in case of infection, which is corruption of operating system files. The same environment can be used to bypass the malware detection evasion ability, remove the boot persistence of the malware sample and release the machine from infection.

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

  The results of performing the detection and mitigation tasks may be fed back to malware mitigation module 122 via feedback loop 146. Malware mitigation module 122 may determine the next action based on an analysis of the results from the task. In another example, malware detection module 120 may analyze the results of the task. 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 may be created to be performed. If the result indicates no infection, the malware mitigation module 122 may perform another check in another environment and decide to generate the 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 may be executed again and again to completely release the electronic device from infection. For example, the malware detection module 120 determines that a malware sample was found that infects the file system and registry, but that 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 a 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 a malware sample is found, a task may be created to look for a particular folder. Upon finding a particular folder, a task may be created to calculate the md5 of all files in the folder. From the 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 modified to run the program on machine startup. If a suspicious program recorded as a startup program is found, a task may be created that looks for an executable file associated with the program, and that the md5 of the malware sample is in a known bad md5 checksum. Can be found. A task may be created that deletes this malware sample and registry entry and reboots the machine in the Live Windows OS to look for mutex-like in-memory indicators and events. Finally, after a number of iterations, the malware mitigation module 122 may determine whether the machine has been completely free from a particular malware sample.

  Turning to FIG. 4, FIG. 4 is an exemplary flowchart illustrating possible operations of a 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, the actions performed by the malware are observed and changes to the system are recorded. For example, pattern behavior generation module 132 may observe operations performed by malware and generate 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 have determined that malware has altered or altered the electronic device 102a. At 504, malware is identified. For example, malware may be identified using the analysis log 126. The analysis log 126 may be generated by the malware detection module 120 by logging changes of the electronic device 102a. At 506, malware pattern behavior is determined. At 508, a reverse malware behavior action is determined. For example, a reverse malware behavior operation 128 is determined. At 510, a reverse malware behavior action is performed that undoes the changes made by the malware to the system. For example, the malware mitigation module 122 may perform a reverse malware behavior operation 128 that undoes changes made to the electronic device 102a by malware.

  FIG. 6 illustrates a computing system 600 arranged in a point-to-point (PtP) configuration, according to one embodiment. In particular, FIG. 6 illustrates a system in which a processor, memory, and input / output devices are interconnected by multiple point-to-point interfaces. Generally, 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 several processors, of which only two, 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 the program. The core may be configured to execute the 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 caches 671, 681 may store data (eg, instructions) used 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, memory controller logic 672 and 682 may be discrete logic, independent of 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 separate 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 PtP links shown in FIG. 6 may be implemented as a multi-drop bus instead of a PtP link.

  Chipset 690 may communicate with bus 620 via interface circuit 696. Bus 620 may have one or more devices communicating therethrough, such as a bus bridge 618 and an I / O device 616. Via bus 610, bus bridge 618 may communicate via 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). (Eg, other types of communication devices), audio I / O devices 614, and / or data storage devices 628. Data storage device 628 may store code 630, which may be executed by processor 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 may 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-a-chip (SoC) architecture, or any other suitable configuration. For example, the embodiments disclosed herein can be incorporated into a system that includes 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, at least in 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 example implementation of the present disclosure may include a malware mitigation feature and an ARM component described herein. 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 (R) phone, iPhone (R)), iPad (R), Google Nexus (R), Microsoft Surface (R), 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, and the like.

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

  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 interface (SPI) master. 750, suitable power control 755, dynamic RAM (DRAM) 760, and flash 765 may also be included. Additionally, one or more exemplary embodiments may include one or more communication features, interfaces, and Bluetooth® 770, 3G modem 775, Global Positioning System (GPS) 780, and 802.11 Wi- It may include functions such as the example of Fi785.

  In operation, the example of FIG. 7 may provide processing capabilities with relatively low power consumption enabling various types of computing (eg, mobile computing, high-end digital homes, servers, wireless infrastructure, etc.). . In addition, such an architecture is compatible with any number of software applications (e.g., Android (R), Adobe (R) Flash (R) players, Java (R) Platform Standard Edition (Java (R)). SE), Java (R) FX, Linux (R), Microsoft Windows (R) Embedded, Symbian, and Ubuntu). In at least one exemplary embodiment, a 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. 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, a processor may alternatively include more than one of the processor cores 800 shown in FIG. For example, processor core 800 illustrates one exemplary embodiment of processor cores 674a, 674b, 684a, and 684b shown and described with reference to processors 670 and 680 of FIG. Processor core 800 may be a single-threaded core, or, for at least one embodiment, processor core 800 may include more than one hardware thread context (or "logical processor") per core. , Multi-threaded.

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

  Processor core 800 may also include execution logic 814 having a set of execution units 816-1 through 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, back-end logic 818 may retire the instruction in code 804. In one embodiment, the processor core 800 enables 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, processor core 800 may include, at least, aspects of the output generated by the decoder, the hardware registers and tables utilized by register renaming logic 810, and any registers (not shown) rewritten by execution logic 814. Is converted during 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, a processor may include memory control logic with a 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 with the examples provided herein, the interaction may be described in terms of two, three, or more network elements. However, this is done for clarity and illustration purposes 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 scalable and can accommodate a large number of components, as well as more complex / sophisticated arrangements and configurations. Accordingly, the examples provided should not limit the scope or block the broad teachings of communication systems 100a-100c as potentially applying to countless other architectures.

  The operations in the foregoing flow diagrams (ie, FIGS. 4 and 5) show only some of the possible correlating scenarios and patterns that may be performed by or within 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 changed without departing from the scope of the present disclosure. In addition, many of these operations have been described as being performed concurrently or in parallel with one or more additional operations. However, the timing of these operations can vary significantly. The foregoing operational flow has been provided for purposes of illustration and description. Considerable flexibility is provided by communication systems 100a-100c in that any suitable arrangement, timeline, 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 specific arrangements and configurations, these example configurations and arrangements may be significantly modified without departing from the scope of the present disclosure. Further, certain components may be combined, separated, removed, or added based on particular needs and implementations. In addition, while communication systems 100a-100c are shown with reference to certain elements and operations that facilitate communication processing, these elements and operations may be any elements that implement the intended functions of communication systems 100a-100c. Preferred architecture, protocol, and / or process.

  Numerous other changes, substitutions, variations, alterations, and modifications may be made to those skilled in the art, and the present disclosure is intended to cover such alterations, substitutions, variations, and modifications falling within the scope of the appended claims. , And all modifications are intended. To assist the U.S. Patent and Trademark Office (USPTO) and, in addition, any reader of any patents issued in connection with this application, in interpreting the claims appended hereto, We wish to note the following: (A) Applicant states that any appended claims shall exist on the filing date of this specification unless the language “means for” or “step for” is specifically used in the particular claim. There is no intent to invoke section 112, sixth paragraph of the US Patent Act. (B) Applicant is not intended to limit the disclosure in any way, by any statement herein, unless reflected by the appended claims.

[Other notes and examples]
Example C1, when executed by at least one processor, causes at least one processor to enable execution of malware in the system, record changes to the system caused by execution of the malware, One or more instructions that cause a detection task to be generated for detection, the detection task comprising at least one machine-readable storage having instructions based at least in part on a change to the system caused by execution of the malware. Medium.

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

  In Example C3, the subject matter of any one of Examples C1-C2 is to cause the at least one processor to further identify a malware family associated with malware when the instructions are executed by the at least one processor; May include family behavior, and the detection task may optionally include being partially based on family behavior.

  In Example C4, the subject matter of any one of Examples C1-C3 may 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, when the instructions are executed by at least one processor, the at least one processor is further provided with an infected electronic device using the generated detection task. Optionally, identifying a device and generating a mitigation task to mitigate a change in an infected electronic device caused by malware may be included.

  In Example C6, the subject matter of any one of Examples C1-C5 may optionally include that a mitigation task is performed in a recovery environment.

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

  In Example C8, the subject matter of any one of Examples C1-C7 may optionally include the secondary operating system being pushed as a boot disk on the infected electronic device.

  In example A1, the apparatus may include a pattern behavior generation module, which enables execution of malware in the system, records changes to the system caused by execution of the malware, and detects malware in the electronic device. And generating a detection task for the system, wherein the detection task is based at least in part on a change to the system caused by the execution of the malware.

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

  In example A3, the subject matter of any one of examples A1-A2 may optionally include that the pattern behavior generation module is further configured to identify a malware family associated with the malware, wherein the malware family comprises: Including a family behavior, the detection task is based in part on the family behavior.

  In example A4, the subject matter of any one of examples A1-A3 may optionally include that the detection task is based in part on generic malware behavior.

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

  In Example A6, the subject matter of any one of Examples A1-A5 may optionally include that a mitigation task is performed in a recovery environment.

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

  In Example A8, the subject matter of any one of Examples A1-A7 may optionally include the secondary operating system being pushed as a boot disk on the infected electronic device.

  Example M1 is to enable execution of malware in the system, record changes to the system caused by the execution of malware, and create a detection task for detection of malware in the electronic device; The detecting task is a method that includes, at least in part, generating based on changes to the system caused by execution of the 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. May be included.

  In Example M3, the subject of any one of Examples M1-M2 is to identify a malware family associated with the malware, wherein the malware family includes a family behavior and the detection task is based in part on the family behavior. , May optionally include identifying.

  In example M4, the subject matter of any one of examples M1-M3 may optionally include that the detection task is based in part on generic malware behavior.

  In Example M5, the subject of any one of Examples M1-M4 is to use the generated detection task to identify an infected electronic device and to cause a change to the infected electronic device caused by malware. And generating a mitigation task may optionally be included.

  In example M6, the subject matter of any one of examples M1-M5 may optionally include that the mitigation task is performed in a recovery environment.

  In example M7, the subject matter of any one 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 remediation from malware, the system including a pattern behavior generation module and a security module, wherein the pattern behavior generation module enables execution of malware in the system and is caused by execution of the malware. Configured to record a change to the system that has been detected and generate a detection task for detecting malware in the 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. The security module is configured to use the generated detection task to identify the infected electronic device and generate a mitigation task to mitigate 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 the malware. May be included.

  Example X1 is a machine-readable storage medium including machine-readable instructions for implementing a method or for implementing an apparatus, as set forth 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 matter of Example Y1 may optionally include a means for performing the method, including a processor and a memory. In Example Y3, the subject matter of Example Y2 may optionally include a memory containing machine readable instructions.

Claims (20)

At least one processor,
Indicator der behavior malware is, the procedure based on the malware pattern behavior, including changes to the server caused by the execution of the malware at the server, generates the detection task for the detection of the malware in an electronic device,
Using the generated detection task to identify an infection of the electronic device;
Generating a mitigation task to mitigate changes to the infected electronic device caused by the malware;
A computer program for executing
The computer program, wherein the mitigation task is performed in a recovery environment or with a secondary operating system on the infected electronic device.   The computer program according to claim 1, wherein the detection task is generated based on one or more of pattern matching, global reputation analysis, program emulation, static analysis, and dynamic analysis of the malware.   The computer program according to claim 1, wherein the malware pattern behavior includes a family behavior, and the detection task is partially based on the family behavior.   4. The computer program according to claim 1, wherein the detection task is based in part on generic malware behavior.   5. The computer program according to claim 1, wherein the secondary operating system is pushed as a boot disk on the infected electronic device. 6. Executing the mitigation task in the recovery environment and the secondary operating system, and obtaining a result indicating that the electronic device is not infected in each of the recovery environment and the secondary operating system. The computer program according to any one of claims 1 to 5, wherein an execution result in the electronic device is fed back to the electronic device by a feedback loop until the electronic device is clean. An electronic device that Ru equipped with a security module,
The security module includes:
Indicator der behavior malware is, based on the malware pattern behavior, including changes to the server caused by the execution of the malware at the server, it generates the detection task for the detection of the malware in the electronic device,
Using the generated detection task to identify an infection of the electronic device;
Generating a mitigation task to mitigate changes to the infected electronic device caused by the malware;
The electronic device, wherein the mitigation task is performed in a recovery environment or with a secondary operating system on the infected electronic device . The electronic device of claim 7, wherein the detection task is generated based on one or more of pattern matching, global reputation analysis, program emulation, static analysis, and dynamic analysis of the malware. The electronic device according to claim 7, wherein the malware pattern behavior includes a family behavior, and the detection task is based in part on the family behavior. The electronic device according to any one of claims 7 to 9, wherein the detection task is based in part on generic malware behavior. 11. The electronic device according to any one of claims 7 to 10, wherein the secondary operating system is pushed as a boot disk on the infected electronic device . Executing the mitigation task in the recovery environment and the secondary operating system, and obtaining a result indicating that the electronic device is not infected in each of the recovery environment and the secondary operating system. the execution result in the electronic device, the feedback loop, said electronic device until clean, the fed back to the electronic device, an electronic device according to any one of claims 7 11. At least one processor, an indicator der malware behavior is, based on the malware pattern behavior, including changes to the server caused by the execution of the malware at the server, the detection task for the detection of the malware in electronic devices Steps to generate,
The at least one processor using the generated detection task to identify an infection of the electronic device;
The at least one processor generating a mitigation task to mitigate changes to the infected electronic device caused by the malware;
With
The method wherein the mitigation task is performed in a recovery environment or with a secondary operating system on the infected electronic device. Executing malware on the system;
Recording changes to the system caused by the execution of the malware;
Generating a detection task for detection of the malware on an electronic device, wherein the detection task is based at least in part on the changes in the system caused by the execution of the malware;
Using the generated detection task to identify an infection of the electronic device;
Generating a mitigation task to mitigate changes to the infected electronic device caused by the malware;
The method wherein the mitigation task is performed in a recovery environment or with a secondary operating system on the infected electronic device.   15. The method of claim 14, wherein the detection task is generated based on 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 wherein the detection task is based in part on the family behavior.
A method according to claim 14 or claim 15.   17. The method according to any one of claims 14 to 16, wherein the detection task is based in part on generic malware behavior.   The method according to any one of claims 14 to 17, wherein a result of performing the detection task or the mitigation task on the electronic device is fed back to the electronic device by a feedback loop until the electronic device is clean. Method. A system for repairing from malware, said system comprising:
A pattern behavior generation module,
A security module,
With
The pattern behavior generation module includes:
Enable the execution of malware in the system,
Recording changes to the system caused by the execution of the malware;
The security module includes:
Generating a detection task for detection of the malware on 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;
Using the generated detection task to identify an infection of the electronic device;
Generating a mitigation task to mitigate changes to the infected electronic device caused by the malware;
The system wherein the mitigation task is performed in a recovery environment or with a secondary operating system on the infected electronic device.   20. The system of claim 19, wherein the detection task is generated based on one or more of pattern matching, global reputation analysis, program emulation, static analysis, and dynamic analysis of the malware.

Images