Method and apparatus for discovering malignancy of computer program
A computer program and malicious technology, applied in computer security devices, calculations, instruments, etc., can solve problems such as difficult to identify hidden virus programs, and achieve the effect of accurate and efficient discovery
Active Publication Date: 2009-01-21
BEIJING RISING NETWORK SECURITY TECH CO LTD
0 Cites 64 Cited by
AI-Extracted Technical Summary
Problems solved by technology
In this case, it is difficult to identify this kind of concealed v...
 Thus, the process set proposed by the present invention not only embodies the relationship between processes, but also includes the internal relationship of related processes in historical actions. All these information will help to conduct correlation analysis on the monitored actions, so as to discover malicious behaviors in a timely and accurate manner.
 Step S213 is an optional step, and its purpose is to determine whether the newly created process is suspicious through filtering, that is, whether a process set needs to be established for it. Its specific filtering process is shown in FIG. 3 . As shown in FIG. 3 , first, the submodule 200 obtains the full path information of the executable file corresponding to the newly created process (step S2131 ). Afterwards, it is judged whether the full path of the executable file exists in an external safety program list (step S2133). The safety program list includes the file information of the safety programs whose identities have been confirmed by the system or the user, and the safety program list can be edited according to actual conditions, such as expansion and deletion. If the judgment result of step S2133 is yes, it indicates that the current newly created process is safe and does not need to be monitored, so it is filtered out (step S2138). Otherwise, continue to judge whether the executable file is a system file (step S2135), if yes, go to step S2138. If it is not a system file, continue to judge whether the executable file is in the list of security programs that need to be filtered out by default (step S2137), if it is, then go to step S2138, o...
The invention provides a method and a device for discovering malicious behaviors of computer programs. The behavior characteristics of vicious procedures are analyzed through using the method and the device which are provided by the invention and through using concepts of a process set which is monitored. The method for discovering the malicious behaviors of the computer programs which is provided by the invention comprises: monitoring actions which are executed by the computer programs, searching the process set which is related with the actions which are monitored in a process set library which is monitored, wherein the process set at least comprises information of at least one suspicious process which is related mutually on the creating relation, and judging whether the actions which are monitored belong to the malicious behaviors or not through association analysis according to the information which is recorded in the process set which is searched out if the process set which is related with the actions which are monitored is searched out.
Computer security arrangements
Computer programMalignancy +1
- Experimental program(1)
 The method and apparatus for discovering malicious behaviors of computer programs proposed by the present invention will be described in detail below in conjunction with specific embodiments. For ease of understanding, in the following embodiments, only the Windows operating system is used as an example for description. However, those skilled in the art can understand that the idea and spirit of the present invention can also be applied to other computer systems, not limited to the Windows operating system.
 Like the aforementioned "grey pigeon" program, today's viruses or spyware no longer attack computers in a single process, but perform malicious actions in the process of creating and/or ending multiple processes, so that they It is easier to fool the monitoring of anti-virus software.
 In addition, through the analysis of many computer virus programs and spyware today, it can also be found that malicious programs may be composed of some basic malicious behavior elements. Now not only a complete malicious program may involve multiple processes, but the Implementations may also involve more than one process. The following exemplarily lists some malicious behavior elements abstracted through analysis, but the present invention is not limited thereto.
 Release virus file: refers to a process that directly creates (modifies a normal file into) a computer virus that has been recognized by an anti-virus engine. When a virus file is generated on a local computer, its direct creator has a high probability of being a virus releaser or downloader.
 Self-replication: Refers to a process that directly or indirectly creates a copy. This copy may be directly created by the malicious program A, or may be copied by the malicious program A by calling other security programs, such as the SHELL program.
 Self-modification self-replication: refers to a process that creates or modifies an application, and the code area where the entry point of the modified application is located is the same as the code area where the entry point of the corresponding program file of the process is located, for example, "Panda Burning Incense "Virus.
 Release program file; refers to a process that directly releases a program file that is not a copy of the current process. The program file can be an executable file (EXE) or a dynamic link library (DLL).
 Starting a self-releasing program: refers to a process directly or indirectly running a program file, which may be created by the process or a process related to the process. For example, malicious program A releases program B, and calls SHELL to start program B.
 Establishing a self-starting association: refers to a process directly or indirectly establishing or modifying a self-starting item (such as a startup item in the registry), so that the program file of the process or related program files can be automatically started by the system. Here, the process program that creates the self-starting item may be malicious program A, or services.exe that already exists in the system.
 Install self-release service: refers to a process that directly or indirectly installs a system service. For example, malicious program A releases several executable files and registers these executable files as services.
 Loading self-release driver: refers to a process that directly or indirectly loads a driver that is directly or indirectly created by the loading process. For example: the malicious program A releases the driver program B, registers the driver program B as a service startup method, and loads the driver program B by the existing process services.exe in the system.
 End process: refers to a process directly or indirectly terminates another normal process. Similarly, the initiator of ending the process may be the malicious program A, or the malicious program A calls the process ending tool provided by the operating system (for example, Taskkill.exe in the Windows system).
 Creating a remote thread: refers to a process that directly or indirectly creates a remote thread in the space of other processes to invade other processes in this way.
Simulated input (keyboard and mouse, etc.): refers to a process that directly or indirectly performs simulated input to the windows of other processes, for example, continuously sending QQ messages.
 Send WINDOWS message: It means that a process sends Windows message WM_GETTEXT directly or indirectly to the windows of other processes in order to obtain the window content.
 Hook of self-release program: Refers to a process hooking a global message hook, and the dynamic link library corresponding to the message hook is directly or indirectly created by the process. For example: the malicious process A releases the dynamic link library B with the hook processing function and the program C that mounts the global hook, and runs the program C, and the program C uses the hook processing function in the dynamic link library B as a parameter to mount the global hook.
 Based on the several malicious behavior elements summarized above, it is not difficult to see that each of these behavior elements may involve multiple related processes created successively. In this case, it is difficult to accurately identify these malicious behaviors by intercepting actions in individual processes.
 For this reason, the present invention proposes the concept of a monitored process set. For the sake of brevity, the "monitored process set" is referred to as "process set" hereinafter, but the process set mentioned in this article refers to the process set monitored by the protection software.
 According to an embodiment of the present invention, each process set contains information of one or more suspicious processes that are related to each other in a creation relationship. Taking the above-mentioned malicious behavior of "terminating the process" as an example, assuming that the malicious process A.exe is already in a process set α, the process A.exe calls the tool Taskkill.exe provided by the operating system to end another normal process, that is, establishes A child process Taskkill.exe. At this time, there is a direct relationship between the parent process A.exe and the child process Taskkill.exe, and the two have jointly completed the behavior of "deliberately terminating other processes". Therefore, according to the principles of the present invention, the subprocess Taskkill.exe will also be included in the process set α. It can be seen that the process set α logically embodies the common behavior of one or more related suspicious processes contained therein. The logical association provided by the collection of processes is very beneficial for identifying malicious behaviors.
 According to the embodiment of the present invention, the process set proposed by the present invention logically divides each related process in the system. Each process set includes the identifier (process ID) of the suspicious process stored therein and the information of the program file corresponding to the process, such as the full path information of the program file (PE file). In addition, since some malicious behaviors can only be discovered by tracing historical data, such as the file information released by the parent process, the process collection according to the present invention can also save the historical records of the actions of each process in the collection. For example, the history may include child process IDs created, files created, files modified, and so on. However, the present invention is not limited thereto. According to needs, the history record may also include other various information, such as the action of accessing the network and so on.
 Therefore, the process set proposed by the present invention not only embodies the association relationship between processes, but also includes the internal relationship of related processes in historical actions. All these information will help to conduct correlation analysis on the monitored actions, so as to discover malicious behaviors in a timely and accurate manner.
 The following will take several malicious behaviors listed above as examples, combined with specific examples of malicious programs, to describe in detail the application of the concept of process set proposed by the present invention in correlation analysis of monitored actions.
 figure 1 A general block diagram of an apparatus for discovering malicious behaviors of computer programs according to an embodiment of the present invention is shown.
 like figure 1 As shown, first the monitoring module 100 of the computer protection software monitors the actions of each program, and sends corresponding action notifications to the monitored actions, for example, process creation/end notification, virus detection engine virus detection notification, file operation notification, registry Operation notifications, system API call notifications, etc. Then, according to the notification about the monitored action, each processing sub-module executes a corresponding sub-process in response to each notification. These processing submodules include process set maintenance submodule 200, virus scanning engine notification processing submodule 400, file operation notification processing submodule 500, registry operation notification processing submodule 600, system call action notification processing submodule 700, and process creation Notification processing sub-module 800 .
 According to an embodiment of the present invention, when each process is created/terminated, the process collection proposed by the present invention is maintained, for example, creating or canceling a process collection, adding or deleting process information in an existing collection, and the like. The specific process performed by the process collection maintenance sub-module 200 will be referred to below figure 2 and 3 Detailed Description.
 For notifications of actions (such as file operations, system call notifications) that occur during the running of each process, each corresponding submodule (400-800) will first search in the process collection library whether there is an action related to the notification A collection of processes, for example, a collection containing action initiators or a collection containing action object information (such as operated files) in history records. If the corresponding process set is found in the set library, then according to the relevant information provided by the process set, combined with the characteristics of the above-mentioned abstracted malicious behaviors, the correlation analysis of each action is carried out, so as to identify each malicious behavior. The specific processes performed by these sub-modules will be combined below Figure 4-8 Detailed Description.
 figure 2 It shows the process of creating/maintaining the set of processes according to the present invention when the process is created/terminated. Here we still take the "grey pigeon" program mentioned above as an example for description.
 see figure 2 , after receiving the process creation/termination notification (step S201), the sub-module 200 first obtains the process ID of the newly created or terminated process and its parent process ID. Then, it is judged whether the received notification indicates process creation (step S203). If yes, go to step S211 to create a process set and/or add a new process; otherwise, go to step S222 to delete an ended process or cancel an empty process set.
 It is assumed here that when the "grey pigeon" program A.exe is created, the monitoring module sends a process creation action notification. At this point, in step S221, search the existing process set database according to the obtained parent process ID to determine whether there is a process set corresponding to the parent process. The "grey pigeon" program A.exe is created for the first time, and its parent process is a safe process and has not been monitored. Therefore, the judgment result of step S221 is No, and the flow proceeds to the filtering step S213.
 Step S213 is an optional step, and its purpose is to determine whether the newly created process is suspicious through filtering, that is, whether a process set needs to be established for it. Its specific filtering process is in image 3 shown in . like image 3 As shown, first, the sub-module 200 obtains the full path information of the executable file corresponding to the newly created process (step S2131). Afterwards, it is judged whether the full path of the executable file exists in an external safety program list (step S2133). The safety program list includes the file information of the safety programs whose identities have been confirmed by the system or the user, and the safety program list can be edited according to actual conditions, such as expansion and deletion. If the judgment result of step S2133 is yes, it indicates that the current newly created process is safe and does not need to be monitored, so it is filtered out (step S2138). Otherwise, continue to judge whether the executable file is a system file (step S2135), if yes, go to step S2138. If it is not a system file, continue to judge whether the executable file is in the list of security programs that need to be filtered out by default (step S2137), if it is, then go to step S2138, otherwise go to step S2139 to determine that the process is suspicious, and you need to create a file for it collection of processes. As mentioned above, the filtering step S213 can avoid creating unnecessary process sets by filtering out some security programs, thereby speeding up the behavior analysis speed of the protection software. The process filtering step can also adopt other methods, for example, using some rules for determining security programs and so on. In some special cases, this filtering step can also be omitted.
 Here, after filtering, the "grey pigeon" program A.exe is neither in the safe list, nor is it a system file or a default security program, then the filtering step determines that the process A.exe is a suspicious process, and a corresponding process set needs to be created. Therefore, the process proceeds to step S215 to create a new process set α, and set the first related process in the set α as the process ID of A.exe, and the relevant file is set as the full path information c of the PE file of A.exe: \A.exe, after which this collection maintenance ends.
 If the process set where the parent process is located is found in step S211, go to step S217. For example, the monitoring module 100 monitors that the "grey pigeon" program A.exe starts its own copy wservices.exe file copied in the system directory, that is, monitors a process creation action. At this time, the parent process A.exe of wservices.exe is already in the process set α, and the flow goes to step S217. In step S217, write the process ID of wservices.exe in the historical process list of collection α, as the second relevant process of this collection, store the file information c of this second relevant process in the historical process list simultaneously: \windows\wservices.exe, after that, this collection maintenance ends.
 If it is determined in step S203 that it is a notification of the end of the process, for example, it is monitored that the "grey pigeon" program A.exe exits after starting wservices.exe, then the process goes to step S222. In step S222, it is still first determined whether there is a process set corresponding to the parent process of the terminated process. For the "grey pigeon" program A.exe, there is no process set where the parent process exists. Therefore, the flow proceeds to step S224, and it is further judged whether there is a process set where the terminated process exists, and if the judgment result is otherwise, the processing ends. Here, through judgment, the process set α where A.exe is located is found. Then, the currently terminated process A.exe is deleted from the set α (step S226). After the process is deleted, it is judged whether there is any suspicious process in the set α (step S228), if not, the set α is revoked or destroyed (step S229). In the example of Gray Pigeon, when A.exe exits, wservices.exe is still running, so the judgment result of step S228 is negative, and the process ends.
 see above in conjunction figure 2 and 3 According to the description of , the process collection can be established at the beginning of suspicious process creation, and the relevant information in the collection can be updated continuously with the creation and termination of related processes. Thus, the process set can provide valuable inter-process association information to the processing sub-module notified by other actions. At the same time, other action notification processing flows can also write the actions or data that occurred in their respective processes into the history records in the process set, so as to increase the amount of associated information.
 The following will refer to Figure 4-8 The specific application of the process set proposed by the present invention in each action notification sub-module is described respectively.
 Figure 4 It shows the processing procedure of the virus checking engine notification processing sub-module. The following is combined with a Trojan horse program to describe Figure 4 process shown.
Assume that a known virus Trojan horse A will release a known virus dynamic link library B during operation. Since both the Trojan horse program A and the dynamic link library B are known virus files, they can be accurately identified through traditional feature code scanning. However, Trojan horse program A is easy to mutate and camouflage (for example, by means of packing, encryption, PEPatch, feature modification, etc.), traditional feature code scanning cannot find Trojan horse program A' after camouflage, and dynamic link library B generally does not camouflage. Can be found by antivirus engines.
 In the above Trojan horse example, it is assumed that the disguised Trojan horse program A' runs and releases the dynamic link library B, and then the virus detection engine finds the dynamic link library B through virus signature scanning, and sends a virus detection notification. Now, the submodule 400 receives the virus notification, and first obtains the virus file found, i.e. the full path of the dynamic link library B (step S420), and then searches in all process collections maintained by the submodule 200 to find the virus file containing There is a process set of the virus file (step S430). Now, because the Trojan horse program A' is running, the submodule 200 has established a process set S for it when A' was created, and the history of the set S includes the file created by A'—the dynamic link library B. Thus, in step S430, the process set S containing the virus file—the dynamic link library B can be found. Based on this judgment, it can be determined that the virus file is released by the process A' in the process set S, that is, it is determined to release the virus file behavior (step S440), thereby successfully finding the disguised Trojan horse program A'.
 like Figure 4 The shown virus scanning engine notification processing sub-flow combines the traditional real-time monitoring of files based on feature code scanning with the analysis of malicious behavior characteristics based on process collection proposed by the present invention. This processing not only utilizes the existing and accurate virus scanning technology very effectively, but also fully utilizes the association links between processes and files provided by the process set. Therefore, this processing can discover malicious behaviors more quickly and accurately, and at the same time help to discover more derivatives of computer viruses.
 Figure 5 The processing procedure of the file operation notification processing sub-module 500 is shown. Next, the "Panda Burning Incense" virus will be used as an example to describe the whole process of file operation notification processing. The "Panda Burning Incense" virus is a worm that infects normal executable files. Specifically, the "Panda Burning Incense" virus replaces the original executable program with its own code, then appends the original program to its own code, and uses the program icon of the original program as its own program icon in order to confuse users and hide itself. This behavior can be abstracted as the aforementioned "self-modifying self-replication".
 In actual operation, after the main program Panda.exe of the "Panda Burning Incense" virus is started, the executable file E.exe will be modified as described above, that is, the file modification action will be performed and monitored by the monitoring module 100 . like Figure 5 As shown, after receiving the file operation notification of creating or modifying a file, the sub-module 500 first obtains the process ID of the initiator of the current file operation action, that is, the process ID of Panda.exe (step S510 ). Then, according to the obtained process ID, search the collection where the current process Panda.exe is located in all process collections (step S520). If not found, it indicates that the current process is safe, and the file operations it performs are also credible, and thus this processing ends. In this example, it is assumed that the sub-module 200 has established a process set β for Panda.exe at the beginning of its creation, so the process goes to step S530. In step S530, the information of the created/modified file E.exe is inserted into the history record of the searched process set β, so as to record the historical actions of the monitored process. Here, if the storage space of the collective history file is full or the insertion fails (not shown in the figure), the processing is directly ended (step S580).
 Then, the sub-module S500 judges whether the created/modified file is an executable file (step S541) or an autorun file (step 543). If it is the automatic running file Autorun.inf, then judge whether the historical records of the process set β that is searched include the files recorded in the Autorun.inf (step S545), that is, judge whether the historical files are associated in the automatic running program . If yes, it indicates that the process set has realized the behavior of "self-starting association" (step S570), otherwise it indicates that the file operation is safe, and the process ends (step S580).
 In the example of "Panda Burning Incense", the modified file E.exe is an executable file, and the process goes to step S551. In step S551, continue to judge whether the program file of the current process has been created. If not, it indicates that the current process may be a system file invoked by a virus. At this time, it is necessary to compare the created/modified file with the content of each file of the same type in the process set where the current process is located, and obtain a matching result (step S552). In the example of "Panda Burning Incense", after the judgment of step S551, the current process Panda.exe is also a created program file, so the process goes to step S553, and the created/modified file is compared with the program file content corresponding to the current process Compare and get matching results.
 The matching performed in steps S552 and S553 not only matches the entire content of the file, but also matches the code area alone. In this way, it is possible to detect the virus "Panda Burning Incense". Taking the PE file format under the Windows system as an example, the specific steps to perform code region matching between two program files are as follows:
 Analyze the structure of the PE file and obtain the program entry points of the two program files;
 Analyze the section table (Section Table) of the PE file, and find the sections (Section) where the entry points of the two programs are located;
 Compare section information (section size) within sections;
 Obtain the content of the section where the entry points of the two programs are located, and perform a binary comparison. If they are the same, the two programs are considered to have the same code area.
 After the matching in steps S552 and S553, three matching results can be obtained, the file content is completely the same, only the code area is the same, and the files are different. Subsequently, the sub-module S500 performs identification according to the matching result of step S552 or S553. If the matching result is not the same, it is determined to be a self-releasing file behavior (step S558). If the matching result is exactly the same (step S554), it is determined that it is a self-replicating behavior (step S556). In the "Panda Burning Incense" example, the matching result is that only the codes are identical (step S555), then it is determined to be a self-modifying self-replicating behavior (step S557). Furthermore, on the basis of the determination results of steps S556-558, it can be further judged whether the created/modified file is in the "startup" directory (step S560), if it is in the startup directory, it can be further determined as a self-startup association behavior (step S570).
 exist Figure 5 In the sub-process shown, the file operations performed by the process are recorded in the history records of the corresponding process set for use in subsequent correlation analysis. At the same time, by comparing the files operated by the current process with the same type of historical files recorded in the process collection, it can be found whether the behavior of the current process is a malicious behavior. Here, the process collection provides the interrelationship of files among the monitored processes, thus adopting Figure 5 The shown method can improve the accuracy and recognition speed of malicious behavior recognition.
 Image 6 It shows the processing flow of the registry operation processing sub-module. Here, an example of virus A is used to illustrate the processing procedure of the sub-module 600 . Suppose, after virus A starts, it releases a malicious program file B.exe, and then adds program B to the self-starting item by modifying the registry, so that program B can start by itself. According to the processing of the aforementioned process set maintenance sub-module, when the process of the virus A is created, the sub-module 200 creates a process set γ for the virus A. Moreover, according to the processing of the file operation notification sub-module, the program B released by the virus A will also be recorded in the set γ as a historical file. Then, when the virus A modifies the registry, the monitoring module can monitor this action and issue a registry operation notification.
 like Image 6 As shown, after receiving the registry operation notification, the sub-module 600 first obtains the registry path to be operated (step S610). Then, judge whether it is a system service key according to the registry path (step S620). If not, it may be a registry modification action initiated by the virus program itself, and the flow goes to step S632. If yes, it may be to start a system service. At this time, it is necessary to further identify whether the started service is safe, so the process goes to step S631.
 In step S631, the full path of one or more files is parsed from the registry value to be updated, that is, the file to be started is obtained. Then, search in the history records of all process sets, so as to judge whether the file obtained in the previous step has been included in a process set (step S633). If not, it indicates that the startup file is safe, and the process ends (step S650). If the judgment result is yes, it indicates that the file to be started is released by a suspicious process in the process set, and the flow goes to step S641. In step S641, it is further judged whether the file is the first file in the process collection obtained in the previous step. If the judgment result is yes, it may be determined that the self-release service is installed (step S643).
 In the example of virus A, the registry path is not the system service key, and the flow goes to step S632. In step S632, the sub-flow S600 obtains the process ID of the initiator of the current registry modification action, that is, the process ID of virus A. Then, according to the obtained process ID, search the set where the current process is located in all process sets (step S634), so as to find the process set γ containing virus A. Then, the process goes to step S636 to obtain the full path of one or more files to be started. Then, after the judgment in step S642, it is found that the obtained file B.exe to be started is included in the set γ. Therefore, it can be confirmed that the current registry operation is an act of establishing a self-starting association initiated by virus A (step S644).
 exist Image 6 In the processing process shown, when the initiator of some operations is a program automatically run by the system, it may not be possible to obtain the process set related to it according to the current process ID. But, because the process collection that the present invention proposes has included the historical record of wherein process action, therefore can obtain relevant process collection by searching the object file of these operations in the history file of all process collections, then based on the obtained process collection for further analysis.
 Figure 7 A system call notification processing sub-module 700 is shown. In the following, the Trojan horse program A will be taken as an example to describe the process of system call notification processing. Assume that Trojan horse A.exe is a malicious program that infringes on the computer by "loading the self-release driver". After the Trojan horse A.exe starts, the submodule 200 creates a process set S for it. After A.exe runs, a driver C is released, and the full path information of the driver C is recorded in the monitoring process set S by the submodule 500 . Then, A.exe calls the service-related API, creates a service registry entry for program C and starts the service. The operation of creating the registry and starting the service is initiated by the system process services.exe already existing in the system. At this time, the monitoring module can monitor the driver loading action and issue a corresponding notification.
After obtaining the system call notification, the submodule 700 first judges whether it is a driver loading notification (step S710). After judgment, it is determined that it is a notification to load the driver program C. Then, obtain the full path of driver C from the notification (step S712), and according to the full path of driver C, search for the same file in the historical records of all process collections (step S714), thereby finding that driver C is included in In the corresponding process set S (step S716). Therefore, it is determined that A.exe in the set S executes the behavior of "loading the self-release driver" during operation (step S718).
 In this Trojan program example, since the initiator of the action of loading the driver is an already running system process, it is impossible to determine whether a corresponding monitoring process set already exists through the initiator process ID. For this reason, the present invention proposes to search the object information of the loading action, that is, the information of the driver program C, in the historical record of the monitoring process set, so as to find the relevant process set.
 In addition to the above system calls for loading drivers, Image 6 The system call handling subsystem shown can also handle other system call notifications that may be malicious. For example, if Image 6 As shown, when the received system call notification is not a loading driver action, obtain the process ID of the initiator of the current action (step S720), and then find the corresponding process set according to the obtained process ID (step S730). If the corresponding process set is found, it means that these system calls are initiated by suspicious processes in the process set. Then, according to the specific action of the system call (step S741-745), determine the corresponding malicious behavior (S751-755). For example, when the system call is to hook the global message hook operation (step S745), it is further determined whether the dynamic link library corresponding to the hook processing function is in the monitoring process set where the current process is located (step S746). If it is, it can be determined with certainty that the self-release hook behavior is attached (step S755).
 The process of discovering malicious behaviors by the submodules 400-700 according to the correlations between processes and between processes and files provided by the process set is described above with reference to the accompanying drawings. The operations of these submodules described above are not isolated, and they may also overlap with each other. In other words, the same malicious behavior may be found in multiple modules above. E.g, Figure 5 The discrimination method of "self-release start" behavior has been mentioned in . However, this behavior can also be identified from process creation notifications. For example, when the protection software sends a notification of creating a process, it can also figure 2 After the maintenance of the process set is completed as shown, it is further determined whether the program file corresponding to the created process is in the process set where the parent process of the created process is located. If it is, it can be determined as "self-release start" behavior (see the specific process Figure 8 ).
 Beneficial effect
 The establishment, maintenance and utilization of the process set proposed by the present invention have been described in detail above in conjunction with specific embodiments. The process set proposed by the present invention divides together a plurality of processes related to each other in terms of creation relationship, and records the historical data of each process in the set. Therefore, the process collection concept proposed by the present invention not only embodies the interrelationship between processes, but also embodies the interrelationship between processes and actions such as file operations. These related information can correlate multiple discrete actions such as process creation, system calls, and file operations, so as to identify malicious behaviors. Therefore, the process set is actually a malicious behavior on the logical level. Therefore, it will be more accurate to use process collections to discover malicious behaviors.
 In addition, the process set proposed by the present invention is established after filtering. In this way, after filtering, the parent-child process relationship provided by the original system may be ignored, and a corresponding process set is directly established for suspicious child processes.
 For example, the user interface program explorer.exe creates a.exe and b.exe. From the perspective of the process generation relationship provided by the system, a.exe and b.exe are brothers. But, according to the process assembly creation principle that the present invention proposes, parent process explorer.exe is a safe process and can not be monitored, and the a.exe and b.exe that it creates may involve different malicious behaviors respectively, thereby belong to two mutually A collection of independent processes. From this, there is no longer any relationship between a.exe and b.exe. In this way, after process filtering, the original generational relationship between processes is transformed into a logical functional relationship.
 Furthermore, multiple related processes in a process set are equal to each other. This simple structure makes the process collection easy to maintain and search fast. These advantages are especially suitable for the requirements of the real-time monitoring system, and the performance of the computer will not be affected due to the complexity of the behavior analysis, and the normal use of the user will not be hindered.
 While the invention has been illustrated and described with respect to preferred embodiments, it will be understood by those skilled in the art that various changes and modifications can be made without departing from the spirit and scope of the invention as defined in the following claims.
Description & Claims & Application Information
We can also present the details of the Description, Claims and Application information to help users get a comprehensive understanding of the technical details of the patent, such as background art, summary of invention, brief description of drawings, description of embodiments, and other original content. On the other hand, users can also determine the specific scope of protection of the technology through the list of claims; as well as understand the changes in the life cycle of the technology with the presentation of the patent timeline. Login to view more.