Abstract:
An arrangement for scanning and patching injected malware code that is executing in otherwise legitimate processes running on a computer system is provided in which malware code is located in the memory of processes by extracting the start addresses of processes&#39; threads and then searching near these addresses. Additional blocks of code in memory that are invoked by the code identified by each start address are also identified and the blocks are then matched against scanning signatures associated with known malware threads. If the entire signature can be matched against a subset of the blocks, then the thread is determined to be infected. The infected thread is suspended and in-memory modifications are performed to patch the injected code to render it harmless. The thread can be resumed or terminated to disable the protection mechanisms of the malware without causing any harm to the process in which the thread is injected.

Description:
BACKGROUND 
       [0001]    Public networks such as the Internet are commonly used to allow businesses and consumers to access and share information from a variety of sources. However, security is often a concern when accessing the Internet because there is a threat of malicious software being downloaded from a website or received in an e-mail which may contain viruses, Trojan horses, or other malicious executable code (collectively referred to as “malware”) that may infect computers inside the business or home. 
         [0002]    An increasingly common technique used by malware authors is to create new threads of execution inside existing legitimate (i.e., trusted) processes running on a computer system. Known as code or process injection, the technique enables the new threads to protect and defend the rest of the malware installation by interfering with or recovering from any changes made by anti-malware products or tools. 
         [0003]    Unfortunately, it is difficult for existing anti-malware products to identify such threads of execution accurately because the malicious code could be anywhere in the memory address space of any running process and the memory is not uniquely linked to a specific thread. In addition, even if the malicious code is detected by the anti-malware product, the process cannot always be killed as a whole. For example, if the running process is a user application process, killing it will cause the user to lose unsaved data. If the running process is a critical system process, killing it would cause the operating system to immediately crash. 
         [0004]    This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above. 
       SUMMARY 
       [0005]    An arrangement for scanning and patching injected malware code that is executing in otherwise legitimate processes running on a computer system is provided in which malware code is located in the memory of processes by extracting the start addresses of processes&#39; threads and then searching near these addresses. Additional blocks of code in memory that are invoked by the code identified by each start address are also identified and the blocks are then matched against scanning signatures associated with known malware threads. If the entire signature can be matched against a subset of the blocks, then the thread is determined to be infected. The infected thread is suspended and in-memory modifications are performed to patch the injected code to render it harmless. Once modified, the thread can be resumed or terminated (as may be specified by the signature) to disable the protection mechanisms of the malware without causing any harm to the process in which the thread is injected. 
         [0006]    In an illustrative example, when a malware detection module in an anti-malware product detects an instance of malware that is known to inject threads, it invokes a thread scan by a thread scanning module by which threads associated with one or more named processes are matched to a subset of known malware thread signatures. By limiting the number of scanning targets and malware thread signatures against which they are matched, very effective scanning and patching may be realized without significantly impacting overall computer system performance. 
         [0007]    This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. 
     
    
     
       DESCRIPTION OF THE DRAWINGS 
         [0008]      FIG. 1  shows an illustrative computing environment in which consumer and corporate users share public network infrastructure such as the Internet, and access resources located on the public network; 
           [0009]      FIG. 2  is a flowchart of an overview of an illustrative method performed by the present thread scanning and patching to detect and disable injected malware; 
           [0010]      FIG. 3  shows an illustrative computer system that runs an anti-malware product which includes functionality supporting the present thread scanning and patching; 
           [0011]      FIG. 4  shows components used in an illustrative thread scanning module; and 
           [0012]      FIG. 5  is a flowchart of an illustrative method that is performed by a block detection component in the thread scanning module. 
       
    
    
       [0013]    Like reference numerals indicate like elements in the drawings. Elements are not drawn to scale unless otherwise indicated. 
       DETAILED DESCRIPTION 
       [0014]      FIG. 1  shows an illustrative computing environment  100  in which a number of consumer users  110   1, 2 . . . N  and business users  116   1, 2 . . . N  share common public network infrastructure  122  such as the Internet. Resources  126  like web servers, databases, FTP (file transfer protocol) sites, and other Internet-based or distributed computing-type applications or services, may typically be accessed by users  110  and  116  using personal computers (“PCs”), laptops, and other computing platforms, as representatively indicated by reference numerals  118  and  120 , respectively. In addition, file and data may be shared among users through such facilities as e-mail or peer-to-peer file sharing. 
         [0015]    While the Internet has been invaluable in enabling positive and productive computing experiences for many users, it unfortunately has been a transport mechanism by which malware such as computer viruses, worms, Trojan horses, and rootkits may be distributed to infect computer systems around the world. The term malware as used here is a collective noun that refers to viruses, worms, Trojan horses, rootkits, and other code that is intentionally designed to perform malicious tasks on a computer system. 
         [0016]    Once malware has reached a computer system over a transport mechanism, it will generally attempt to perform some malicious action, generally called a “payload.” Payloads can include, for example, providing backdoor (i.e., unauthorized) access to the computer system, corrupting or deleting data on the computer, stealing information, or halting network service through a denial of service (“DoS”) attack. 
         [0017]    The business users  116  typically are located in a corporate network (“corpnet”) that sits behind a firewall  130  that often provides, alone or in combination with other security products (not shown), protection against malware and other threats. Consumer users  110  often utilize locally running anti-malware products such as anti-virus programs, and may also receive some protection against malware from their Internet service provider (“ISP”). 
         [0018]    Unfortunately, many malware examples employ some kind of self-defense or protection mechanism to help reduce the likelihood of detection and/or removal by anti-malware products. For example, malware may use armor that attempts to foil an analysis of the malicious code. This may include detecting when a debugger is running and trying to prevent it from working correctly, or adding lots of meaningless code to make it difficult to determine the purpose of the malicious code. Malware may use a stealth technique to hide itself by intercepting requests for information and returning false data. Malware may also encrypt itself or its payload to prevent detection and data retrieval. 
         [0019]    Another technique called “process injection” has become increasingly popular among malware authors to conceal their code from anti-malware products or frustrate attempts to remove the malware. This technique involves injecting the malicious code into legitimate processes that are running on the computer. For example, a remote access Trojan horse may inject malicious code into a process used by a web browser application to avoid detection by a firewall (e.g., firewall  130 ) or the anti-malware product running on a PC. Not only will the malicious code be provided with Internet access, but the security applications running on the firewall or PC, which are often rule-based, will often not detect the malware, but only see the trusted Web browser application and associated processes. 
         [0020]    Malicious code can be injected, for example, by loading executable code such as a DLL (“Dynamically Linked Library”) into a running process&#39;s memory. Operating systems, such as the Microsoft Windows® operating system, commonly provide several different ways to call external functions in a DLL file. Another approach malware authors take is to use the Windows-provided API (application programming interface) for debugging. Typically, a new thread is created in the target process with the thread&#39;s start address in memory set to the address of the executable malicious code. It is noted that the term “thread” is used here in its conventional sense to mean a set of instructions in program code that performs operations within an address space. Threads typically can execute independently of each other. 
         [0021]    Even in cases where the injected malicious code can be detected, it can be often very difficult to remove, particularly when a system process has been impacted. One example of a critical system process in the Windows operating system is Winlogon. Terminating this process can often cause the computer system to immediately crash. This characteristic makes this process a popular target for malware authors. The author may configure the malware to create a custom thread in Winlogon to constantly monitor and then replace any files containing the malware code which are detected and deleted by anti-malware products. 
         [0022]    The present thread scanning and patching arrangement can disable injected malware code, including code that is injected into critical system processes. In an illustrative example, the thread scanning and patching is implemented using a software module in an anti-malware product.  FIG. 2  shows a flowchart for an overview of the techniques used to detect and disable injected malware code using the Winlogon example above. At  201 , the anti-malware product with the thread scanning and patching module uses a conventional computer hard disk based scanning technique (or other known technique) to detect malware running on the Winlogon process, for example, by comparing files on the hard disk against signatures of known malware. At  202 , a thread scan is triggered on the Winlogon system process. At  203 , a thread of malicious code is detected. At  204 , the code is modified to disable the constant monitoring by the malware. At  205 , the malware files can be deleted. At  206 , rebooting the computer system clears the remaining traces of the patched malware thread from Winlogon. 
         [0023]    Details of the thread scanning and patching technique are shown in  FIGS. 3-5  and described in the accompanying text. Turning now to  FIG. 3 , an illustrative computer system  300  is shown that supports an anti-malware product  305  that incorporates a malware detection and remediation module  312 , and a thread scanning module  320 . Computer system  300  is representative of a typical personal computer as used, for example, by a consumer user  110  or by a business user  116  as shown in  FIG. 1 . 
         [0024]    The malware detection and remediation module  312 , in this example, is arranged to apply any of a variety of known (i.e., “conventional”) techniques to detect malware on the computer system  300 , for example, by scanning files  326  on the computer system&#39;s hard disk drive  330  (or other storage medium such as a persistent or other non-volatile memory), and comparing data in the files  326  to signatures of known malware that are contained in a signature repository  335 . Other conventional malware detection techniques that may be utilized include, for example, solutions that monitor network traffic leaving the computer system  300 , or methodologies which employ memory-based scanning. 
         [0025]    The signature repository  335  is used to hold signatures used for detecting malware with conventional disk-based techniques, as well as for holding signatures of known malware threads, termed “thread scanning signatures.” In alternative implementations, the signatures used to support the malware detection techniques can be held separately from the thread scanning signatures. 
         [0026]    In most implementations of the present arrangement, signatures  335  will contain instructions to direct the malware detection and remediation module  312  to invoke a thread scan (using the thread scanning module  320 ) for only a subset of all known malware threads. Sometimes, therefore, only specific processes  341  identified by name will be subjected to thread scanning. By being selective with respect to both the thread scanning targets and the number of malware signatures being matched against, an effective solution to injected malware can be provided while maintaining the overall performance of the computer system  300 . 
         [0027]    Accordingly, when malware is detected for which thread scanning is utilized, the malware detection and remediation module  305  makes a call to the thread scanning module and will pass the process name and Thread Signature ID as parameters to the thread scanning module  320 . The thread scanning module  320  will locate threads  346  associated with the named processes in memory  350  in order to begin the thread scanning and patching technique. The details of the techniques used and the functional components of the thread scanning module are shown in  FIG. 4  and described in more detail below. 
         [0028]    As shown in  FIG. 4 , the thread scanning module  320  includes a thread enumeration component  410 , a block detection complement  420 , a block matching component  430 , and a thread remediation component  440 . 
         [0029]    The thread enumeration component  320  takes the process name as an input and locates candidate threads for scanning based on the process name. The thread enumeration component  320  relies upon operating system functionality to generate a list of running processes on the computer system  300 . The running process list is filtered by eliminating any process whose process name does not match the name received from the malware detection and remediation module  312 . 
         [0030]    Each process that remains after the filtering is identified by a Process ID. For each such process, the operating system is queried to generate a list of threads for that process where each thread is identified by a Thread ID. The thread enumeration component  320  then queries the operating system to obtain the start address of each thread&#39;s code in the process&#39;s memory. 
         [0031]    The thread enumeration component  410  forwards the thread list (Thread ID, Process ID, Entry Point) to the block detection component  420 . It is noted that the trailing asterisk notation used in  FIG. 4 , “(x)*” means “zero or more of (x)”. Thus, for example, the notation (Thread ID, Process ID, Entry Point)* means that the thread list produced by the thread enumeration component  410  includes zero or more entries, each entry containing all of Thread ID, Process ID, and Entry Point. 
         [0032]    The block detection module  420  uses the thread list (Thread ID, Process ID, Entry Point), and Thread Signature ID as inputs to analyze the machine code stored at a start address, and attempts to determine locations in memory where more code exists and the thread executes. The block detection component  420  then generates a list of detected blocks which is forwarded to the block matching component  430 , (where each block in the list is identified by Block Address) to which blocks in a given signature can be matched against. The list is in the form (Thread ID, Process ID, Block Address*)* which means that there are zero or more entries in the block list where each entry contains a Thread ID, a Process ID, and zero or more Block addresses. 
         [0033]    More specifically, for each thread, the block detection module  420  accesses the memory space of the process to which the thread belongs. As shown in  FIG. 5 , at  501 , a queue of memory addresses is formed where the start point address thread is the initial entry. At  502 , the first address in the memory queue is removed. At  503 , if the address is inside a block on the block list, then the step at  501  is repeated. 
         [0034]    At  504 , the machine code of the address in the memory address queue is examined. At  505 , if the machine code jumps to new addresses in the memory, then those new addresses are added to the memory address queue. At  506 , when the end of the block of code is found, then the block is added to the block list. 
         [0035]    The steps  501 - 506  are iterated so long as there are entries in the memory address queue, as indicated at  507 , and the size of the block list is smaller than a predefined limit, as indicated at  508 . This limit will typically be selected to meet the needs of a particular implementation as more resources in the computer system  300  will typically be consumed as the size of the block list increases. 
         [0036]    Returning again to  FIG. 4 , block matching component  430  takes the detected block list (Thread ID, Process ID, Block Address*)* and Thread Signature ID as inputs. Each block is attempted to be matched against a set of blocks in a thread scanning signature in signatures  335 . If all the blocks in the given thread scanning signature are matched, then the thread is determined to be infected with malicious code. 
         [0037]    More specifically, each thread signature in the signature repository  335  defines the partial contents of multiple blocks of memory. To declare a thread as infected, every partial block in the thread scanning signature must be matched against one of the blocks identified by the block detection component  420 . However, as only the thread scanning signatures explicitly identified by the Thread Signature ID (that is passed as a parameter to the thread scanning module  320 ) are used for the matching, resources in the computer system  300  can generally be used efficiently. 
         [0038]    As indicated by arrow  435 , threads that match any thread scanning signatures are passed back, by Thread ID and Malware Name, to the malware detection and remediation module  312  or other system or sub-system running on the computer system  300 , for example, to be reported by the anti-malware product to an end-user, or system administrator. A list of matched blocks for any detected thread and malware name (Thread ID, Malware Name, Matched Blocks*)* is reported to the thread remediation component  440 . The matching thread scanning signatures from repository  335  are also passed as shown in  FIG. 4 . 
         [0039]    The thread remediation component  440  takes the identity of the malware thread and the list of matched blocks as inputs. Each thread reported to the remediation component  440  is suspended. The matching thread scanning signature, which is typically arranged to contain patch instructions, is then examined. The patch instructions reference specific locations within the blocks and provide new values for the memory in these locations. The new values are written to the specified locations so that the process memory associated with the infected thread is modified. 
         [0040]    Once modified, the thread may either be resumed or terminated, depending on the instructions in the thread scanning signature. A report may then be forwarded by Thread ID, Malware Name and Result (e.g., resumed, terminated), as indicated by arrow  442  to the malware detection and remediation module  312  or other system or sub-system running on the computer system  300 . 
         [0041]    Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.