Selective assessment of maliciousness of software code executed in the address space of a trusted process

System and method for detection of malicious code injected into processes associated with known programs. Execution of processes in a computer system is monitored. From among the processes being monitored, only certain processes are selected for tracking. For each of the processes selected, function calls made by threads of the process are tracked. From among the tracked function calls, only those function calls which are critical function calls are identified. For each identified critical function call, program instructions that caused the critical function call are subjected to analysis to assess their maliciousness.

PRIOR APPLICATIONS

This application claims priority to Russian Federation Patent Application No. 2013119285, filed Apr. 26, 2013, and incorporated by reference herein.

FIELD OF THE INVENTION

The invention relates generally to information processing and communications technologies and, more particularly, to computer security apparatus and methods for assessing whether a piece of code (i.e. program instructions), configured to be executed in the address space of a trusted process, contains malicious code.

BACKGROUND OF THE INVENTION

With the expansion of the application fields for computer devices, the number of various malicious programs is also growing, such as network worms, trojan programs and computer viruses. Generally, the purpose of malicious programs is to gain control over a computer system, in order to perform such actions as, for example, theft of confidential information.

One of the approaches used to detect malicious programs involves analyzing the behavior of applications. This approach is based on the interception of functions called by an application and on their subsequent study. The study discovers various suspicious actions, such as an attempt to access system files by a non-trusted process (for example, a process launched from a file which appeared in the system relatively recently).

Conventional approaches of this type for detecting malicious programs tend to have one substantial deficiency. This deficiency is due to the fact that the malicious code, using, for example, program or operating system vulnerabilities, can be implemented in the address space of a trusted process in order to create threads or in order to be launched among the existing process's threads, which will be executed on behalf and at the privilege level of that process. In this case, the attempt to access the system files, initiated by the malicious code and discussed above as an example, will not be considered suspicious because it will be executed on behalf of a trusted process. The malicious programs that use the above-described infection pattern are known in the field as exploits.

An example of a trusted process, on behalf of which a malicious code can be executed, is svchost.exe—a process in the Microsoft Windows® operating system family, for services loaded from dynamic libraries. In an operating system, several copies of this process can be launched for each of the services registered in a special partition of the system registry. If a malicious program succeeds in registering as such a service, then the malicious program code will be executed in the address space of one of the svchost.exe processes.

A browser process can be considered as another example of a trusted process traditionally exploited by malicious programs. A malicious code located on a page visited by the user can be automatically downloaded and launched in the address space of the browser process if vulnerabilities exist.

A number of solutions intended to detect a malicious code that uses the above-discussed infection pattern have been proposed.

For example, in one approach, as disclosed in U.S. Pat. No. 7,228,563 when a critical function (for example, a new process creation function) is called, the address of the code which calls for that function in the memory is determined. If the calling code is not located in the memory area where executable code storage is allowed, the call for the function is deemed suspicious and is forcefully terminated. The non-executable memory area can be, in particular, an area of the dynamically allocated memory (a heap) in the virtual address space of a process. This area is used to place data objects dynamically created by a process in the memory allocated for the process. Since the above-mentioned area contains data, the presence of an executable code in this area is non-typical and is deemed suspicious.

Another approach, as disclosed in U.S. Pat. No. 8,230,499, is intended to detect a malicious code executed in the address space of a browser process. At the interception of a download function (for example, UrlDownloadToFileA, UrlDownloadToFileW, UrlDownloadToCacheFileA, and UrlDownloadToCacheFileW), the return address of the called function is determined; if the return address is located in a heap, the download is prohibited.

It should be noted that, when the above-mentioned approaches are used, the malicious code will not be detected if it is located in the executable area of an address space. Also, verification of the calls for critical functions for all processes without exceptions is a resource-consuming task and can result in “freezing” of the applications being run by the user.

A need therefore exists for a solution that overcomes deficiencies such as those discussed above, while providing effective and efficient detection of malicious code.

SUMMARY OF THE INVENTION

One aspect of the invention is directed to a system for detection of malicious code injected into processes associated with known programs. The system includes a computing device comprising a plurality of computing resources including computing hardware and an operating system executing on the computing hardware, and a plurality of programs interfaced with the computing resources and executable as processes having one or more threads. A set of instructions are executable by the computing hardware and stored in a non-transitory storage medium. When executed, they cause the computing hardware to implement a set of modules. Among the modules is a process monitor module that detects active processes being executed on the computing hardware. A process selection module selects, from among the processes being monitored by the process monitor module, only those processes which are susceptible processes, the process selection module selecting the susceptible processes based on predefined process selection criteria. A function call tracking module tracks function calls made by threads of each of the susceptible processes selected by the process selection module. A critical function call interception module that identifies, from among the tracked function calls, only those function calls which are critical function calls. The critical function call interception module identifies the critical function calls based on critical function determination criteria. An analysis module identifies, for each identified critical function call, program instructions that caused that critical function call, and assess maliciousness of the program instructions based on a set of analysis criteria.

In another aspect of the invention, a method is provided for detection of malicious code injected into processes associated with known programs. The method includes:monitoring execution of processes on the computing hardware;selecting, from among the processes being monitored, only those processes which are susceptible processes, wherein the selecting is based on predefined process selection criteria;for each of the susceptible processes selected, tracking function calls made by threads of the process;identifying, from among the tracked function calls, only those function calls which are critical function calls, wherein the identifying of the critical function calls is based on critical function determination criteria;for each identified critical function call, identifying program instructions that caused the critical function call; andassessing maliciousness of the program instructions based on predefined assessment criteria.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A process may be considered as a container of resources which are required to execute program's code. A process has a virtual address space, a sample structural diagram of which is illustrated inFIG. 1. Into the virtual address space of a process100, an executable file is projected, from which the process is loaded (in the example being discussed, it is the file iexplore.exe of the Internet Explorer web browser), as well as the dynamic-link libraries (DLLs) related to it. Also, the address space of the process stores data structures, such as a stack and a heap, which will be discussed below in more detail. Each process contains at least one thread. A thread uses system resources (for example, files, system registry keys, synchronization objects) and the address space of the process. The execution of a program code occurs via the process threads.

The examples illustrated inFIGS. 1B and 1Cillustrate the difference between a sequence of the calls made on behalf of a process not containing an exploit and the sequence of the calls made on behalf of the same process containing an exploit. As can be seen from the example shown inFIG. 1C, at a certain stage, control is transferred to an executable code located in a heap. All subsequent calls will be made by the exploit on behalf of the exemplary process, iexplore.exe, in order to implement the malicious functionality. According to the approaches according to certain aspects of the invention, the transfer of control to an executable code located in a heap represents a criterion indicative of maliciousness of the code. Therefore, the use of approaches described herein will facilitate the timely detection of a malicious piece of code and prevent the realization of its malicious functionality.

FIG. 2is a structural diagram illustrating a system architecture for assessing the maliciousness of a piece of code executed in the address space of a trusted process. A list of processes210executed at an arbitrary moment in an operating system includes, typically, several dozen (or possibly more) processes, depending on the number of launched applications. It should be noted thatFIG. 2shows a simplified example of a list of processes being executed. The same principles will apply to a larger and more diverse set of processes.

Analyzing each and every process for the presence of malicious code is a resource-consuming task, the execution of which can result in perceived slow operation of the computer system or the non-responsiveness, i.e., “freezing” of applications at various stages of their operation. In order to solve the above-mentioned problem, one aspect of the present invention involves selectively targeting the analysis at processes which are determined to be susceptible processes, i.e., those processes for which the presence of a malicious code in the address space is deemed most likely.

Accordingly, an arrangement of modules, which will be described in greater detail below, are provided. The term module as used herein means a real-world device, component, or arrangement of components implemented using hardware, such as by an application specific integrated circuit (ASIC) or field-programmable gate array (FPGA), for example, or as a combination of hardware and software, such as by a microprocessor system and a set of program instructions that adapt the module to implement the particular functionality, which (while being executed) transform the microprocessor system into a special-purpose device. A module can also be implemented as a combination of the two, with certain functions facilitated by hardware alone, and other functions facilitated by a combination of hardware and software. In certain implementations, at least a portion, and in some cases, all, of a module can be executed on the processor(s) of one or more computers (e.g., cluster nodes) that execute an operating system, system programs, and application programs, including cluster computing operations, while also implementing the module using multitasking, multithreading, distributed (e.g., cloud) processing where appropriate, or other such techniques. Accordingly, each module can be realized in a variety of suitable configurations, and should generally not be limited to any particular implementation exemplified herein, unless such limitations are expressly called out.

Processes being executed on the computing hardware are monitored by process monitor module220. In one approach, process monitor module220detects the launching of a process and creates a pointer to the address space of that process, or provides some other suitable indication of every process being executed in the operating system. Process monitor module220includes process selection module225, which classifies a process as either worth analyzing, or not worth analyzing, on the basis of certain characteristics. Those processes that are worth analyzing are generally processed which are more susceptible to the insertion of malware. In a related embodiment, the process selection criteria for detecting and selecting susceptible processes is stored in a process selection criteria database230. Examples of such characteristics will be discussed below.

As it was noted above, the infiltration of a malicious code in the address space of a process can be performed by exploiting a vulnerability in an application. This is why, in a specific embodiment of this invention, the fact that a process belongs to a known vulnerable application represents a characteristic of a susceptible process.

In another specific embodiment of the invention, a characteristic of a susceptible process can be represented by the fact that the process belongs to an application which establishes network connections (for example, a Web browser), because applications of this type are most often exploited by malicious programs.

In addition, the capability provided in an application for creation of child processes (for example, processes for downloading and installing updates, processes for new tabs in various browser versions) can be used by a malicious program to implement the malicious functionality. Therefore, another characteristic of a susceptible process can be represented by the fact that the process belongs to an application which has the capability to create child processes.

Other characteristics of a susceptible process can be: the fact that the process belongs to a popular application (usually, the more popular is the application, the more actively offenders look for its vulnerabilities in order to exploit it), and the fact that the process belongs to an application whose size exceeds a set value (usually, the larger is the application, the more vulnerabilities it has).

Another characteristic of a susceptible process can be the fact that the process belongs to an application which was launched without using a file manager. A file manager (for example, Windows Explorer) implements a graphical user interface for working with an operating system (launch of applications, work with files and the system registry, etc.). Therefore, the launch of an application without the use of a file manager means that the application was not launched on the user's initiative, which is a suspicious circumstance.

Having detected susceptible processes in the system, the process selection module225transmits the identifiers of those processes to the critical function call interception module245. The critical function call interception module245is intended to intercept the calls for critical functions among the calls for all functions performed by each susceptible process, which are tracked by function call tracking module240. In this embodiment, a critical function is a function associated with malicious code being executed in the address space of a susceptible process. In general, in order to implement its functionality, a piece of malicious code must create a new process or a new thread. Therefore, in one embodiment, the function of creating a new process (CreateProcess) and the functions of creating a new thread (CreateThread/CreateRemoteThread) will be deemed critical.

Other examples of critical functions can exist for certain types of susceptible processes. For example, if a process belonging to an application whose functionality does not involve creation of executable files (for example, Adobe Reader) performs an executable file writing function (e.g., WriteFile), such function will be critical as well.

The information on which functions called by a susceptible process should be deemed critical is received by the critical function call interception module245from the critical functions database250.

If a critical function has been intercepted by the critical function call interception module245among the calls for all the functions performed by a susceptible process, the information about the call for such function, together with the identifier of the process which made the call, are transmitted to the analysis module260. The analysis module260performs the analysis of the received call stack in order to identify the executable code that initiated the call for that function. The procedure for analyzing a call stack will be discussed below in more detail. Upon identification of the address of the executable code which initiated the call for the critical function, the analysis module260assesses the maliciousness of the code, based on a number of criteria, information about which is stored in the criteria database270.

Depending on the embodiment of the invention, the criteria for assessing the maliciousness of a piece of code can include:the fact that the executable code is located in a heap;the fact that the code contains instructions typical for exploits (for example, instructions used by an exploit to determine its address. For x86 architecture processors, such instructions may take the following form, for instance: call $+5; pop <reg>);the fact that the code contains characteristics of a position-independent code. The presence of such characteristics is typical for exploits because a position-independent code can be implemented in any memory area of the exploited program. Work with the Structured Exception Handling (SEH) mechanism and analysis of the export of libraries can be examples of such characteristics;the fact that the code contains operation codes (opcodes) typical for data alignment;the fact that the code contains encoded hashes from function names.

In a specific embodiment for this invention, the assessment of the maliciousness of the code that initiated a call for the new process creation function (CreateProcess) is made based on the facts and circumstances surrounding the receipt of the file. The following are examples of the criteria for assessing the suspiciousness of the file being launched:the source from which the file is received. The fact that the file was received, for example, from a malicious website can mean that the code being executed is malicious. In this case, the database270can store a list of such sources;the fact that the user was involved in the download of the file. Offenders often use the so-called “drive-by download” technology, when the launch of a malicious object on a user computer follows its automatic download from a website visited by the user. In this case, the download and the launch of the malicious object do not require the user to take any actions or to confirm his/her consent. For this reason, a file downloaded without direct participation of the user will be deemed suspicious, just like the code loaded from such file;the amount of time passed from the moment the file is assembled to the moment it appears on the user's computer. The specifics of the creation of exploits require that as little time as possible passes from the moment the offender discovers a vulnerability in software to the moment a malicious code exploiting that vulnerability is launched on the user's computer; (otherwise the software manufacturer can make a correction to the vulnerability, which will make a successful attack less likely). For this reason, in order to accelerate the attack, the malicious files that use vulnerabilities are usually not tested. Therefore, for the malicious files, the amount of time passed from the moment of assembly to the moment of appearance on the user's computer is substantially shorter than for the safe files.

The assessment of the maliciousness of a piece of code based on the above criteria can be made via the analysis module260, using such devices as fuzzy logic or artificial neural networks. After the assessment, a decision is made on the maliciousness of the executable code. In a specific embodiment for this invention, after the assessment of the maliciousness, the information is transmitted to an antivirus system installed on the user's computer, for further verification.

FIG. 3is a diagram illustrating the use of a function call stack according to one embodiment. A function call stack is a data structure organized using the LIFO principle (“last in—first out”). A stack300stores information for returning control from subprograms to a program (or to a subprogram, in case of nested or recursive calls). The example presented inFIG. 3shows that, during the execution of the code, a call occurs for the function F1, which has the parameters p1, p2 and p3. The actual call for the function is preceded by the transmission of its parameters to the stack, which may be performed in reverse order—from parameter p3 to parameter p1. Also, in response to calling of function F1, the address for return from this function is pushed to the stack; this is the memory address of the instruction immediately following the function call instruction. If required, a memory area for local variables of the F1 function is also allocated in the stack. Similar actions are performed at subsequent calls for function F2 with parameter p1 and for function F3 with parameters p1 and p2. The stack element that stores information on one copy of a function is referred to as a stack frame. As can be seen from the diagram, by analyzing function return addresses, beginning from the last stack frame, it is possible to find the address of the code which initiated the call for any of the functions.

If, for example, function F3 is found to be a critical function, the call for which was made on behalf of a susceptible process, the module260, when analyzing the call stack300, will initially verify the code located at the return address for that function. If, as a result of the verification, the code is not deemed malicious, then the analysis module260can sequentially verify the code copies at the function return addresses whose calls in the stack preceded the call for the F3 function.

FIG. 4shows the operation algorithm of a system for assessing the maliciousness of a piece of code executed in the address space of a trusted process. At Stage410, the process monitor module220monitors the processes launched in the operating system. When the process is launched, at420, the process selection module225determines whether the launched process has any characteristics of a susceptible process, information on such characteristics being stored in the process selection criteria database230. If the launched process has any characteristics of a susceptible process, function call tracking module240tracks function calls made by the process at422. For each called function, at426, critical function call interception module245tests whether that called function is a critical function. In the affirmative case, at430, critical function call interception module245intercepts the calls for critical functions among the calls for all functions performed by the process. The information on which of the functions called by the susceptible process should be considered as critical is stored in the critical functions database250.

After the interception of a call for a critical function, the analysis module260, at440, analyzes the call stack in order to identify the executable code that initiated the call for the function. After that, the analysis module260, at450, assesses the maliciousness of the executable code based on the criteria information on which is stored in the database270. Based on the results of the assessment at460, the analysis module260makes a decision on the maliciousness of the executable code.

FIG. 5is a diagram illustrating in greater detail a computer system1on which aspects of the invention as described herein may be implemented according to various embodiments. The computer system1may include a computing device such as a personal computer2. The personal computer2includes one or more processing units4, a system memory6, a video interface8, an output peripheral interface10, a network interface12, a user input interface14, removable16and non-removable18memory interfaces and a system bus or high-speed communications channel20coupling the various components. In various embodiments, the processing units4may have multiple logical cores that are able to process information stored on computer readable media such as the system memory6or memory attached to the removable16and non-removable18memory interfaces18. The computer2system memory6may include non-volatile memory such as Read Only Memory (ROM)22or volatile memory such as Random Access Memory (RAM)24. The ROM22may include a basic input/output system (BIOS)26to help communicate with the other portion of the computer2. The RAM24may store portions of various software applications such as the operating system28, application programs30and other program modules32. Further, the RAM24may store other information such as program or application data34. In various embodiments, the RAM24stores information that requires low-latencies and efficient access, such as programs and data being manipulated or operated on. In various embodiments RAM24comprises Double Data Rate (DDR) memory, Error Correcting memory (ECC) or other memory technologies with varying latencies and configurations such as RAMBUS or DDR2 and DDR3. In this way, in various embodiments, the system memory6may store the input data store, access credential data store, operating memory data store, instruction set data store, analysis result data store and the operating memory data store. Further, in various embodiments, the processing units4may be configured to execute instructions that limit access to the aforementioned data stores by requiring access credential before access to the information is granted.

The removable16and non-removable18memory interfaces may couple the computer2to disk drives36such as SSD or rotational disk drives. These disk drives36may provide further storage for various software applications such as the operating system38, application programs40and other program modules42. Further, the disk drives36may store other information such as program or application data44. In various embodiments, the disk drives36store information that doesn't require the same low-latencies as in other storage mediums. Further, the operating system38, application program40data, program modules42and program or application data44may be the same information as that stored in the RAM24in various embodiments mentioned above or it may be different data potentially derivative of the RAM24stored data.

Further, the removable non-volatile memory interface16may couple the computer2to magnetic portable disk drives46that utilize magnetic media such as the floppy disk48, Iomega® Zip or Jazz, or optical disk drives50that utilize optical media52for storage of computer readable media such as Blu-Ray®, DVD-R/RW, CD-R/RW and other similar formats. Still other embodiments utilize SSD or rotational disks housed in portable enclosures to increase the capacity of removable memory.

The computer2may utilize the network interface12to communicate with one or more remote computers56over a local area network (LAN)58or a wide area network (WAN)60. The network interface12may utilize a Network Interface Card (NIC) or other interface such as a modem62to enable communication. The modem62may enable communication over telephone lines, coaxial, fiber optic, powerline, or wirelessly. The remote computer56may contain a similar hardware and software configuration or may have a memory64that contains remote application programs66that may provide additional computer readable instructions to the computer2. In various embodiments, the remote computer memory64can be utilized to store information such as identified file information that may be later downloaded to local system memory6. Further, in various embodiments the remote computer56may be an application server, an administrative server, client computers, or a network appliance.

A user may enter information to the computer2using input devices connected to the user input interface14such as a mouse68and keyboard70. Additionally, the input device may be a trackpad, fingerprint scanner, joystick, barcode scanner, media scanner or the like. The video interface8may provide visual information to a display such as a monitor72. The video interface8may be an embedded interface or it may be a discrete interface. Further, the computer may utilize a plurality of video interfaces8, network interfaces12and removable16and non-removable18interfaces in order to increase the flexibility in operation of the computer2. Further, various embodiments utilize several monitors72and several video interfaces8to vary the performance and capabilities of the computer2. Other computer interfaces may be included in computer2such as the output peripheral interface10. This interface may be coupled to a printer74or speakers76or other peripherals to provide additional functionality to the computer2.

Various alternative configurations and implementations of the computer are within the spirit of the invention. These variations may include, without limitation, additional interfaces coupled to the system bus20such as universal serial bus (USB), printer port, game port, PCI bus, PCI Express or integrations of the various components described above into chipset components such as the northbridge or southbridge. For example, in various embodiments, the processing unit4may include an embedded memory controller (not shown) to enable more efficient transfer of data from the system memory6than the system bus20may provide.

The embodiments above are intended to be illustrative and not limiting. Additional embodiments are within the claims. In addition, although aspects of the present invention have been described with reference to particular embodiments, those skilled in the art will recognize that changes can be made in form and detail without departing from the spirit and scope of the invention, as defined by the claims.

Persons of ordinary skill in the relevant arts will recognize that the invention may comprise fewer features than illustrated in any individual embodiment described above. The embodiments described herein are not meant to be an exhaustive presentation of the ways in which the various features of the invention may be combined. Accordingly, the embodiments are not mutually exclusive combinations of features; rather, the invention may comprise a combination of different individual features selected from different individual embodiments, as understood by persons of ordinary skill in the art.

Any incorporation by reference of documents above is limited such that no subject matter is incorporated that is contrary to the explicit disclosure herein. Any incorporation by reference of documents above is further limited such that no claims that are included in the documents are incorporated by reference into the claims of the present application. The claims of any of the documents are, however, incorporated as part of the disclosure herein, unless specifically excluded. Any incorporation by reference of documents above is yet further limited such that any definitions provided in the documents are not incorporated by reference herein unless expressly included herein.