Trojan horse process detection method and device

Abstract

The invention discloses a Trojan horse process detection method and device. The Trojan horse process detection method and device are used for solving the problem that a Trojan horse process with a hidden kernel module as a back door is difficult to recognize. According to the method, the Trojan horse program can be effectively identified, and the kernel module assisting the Trojan horse program in hiding traces can be accurately positioned. The method comprises the steps of obtaining a process file of each to-be-detected process from a memory of a system; determining an identifier of a target kernel module corresponding to any to-be-detected process according to the process file of any to-be-detected process; when any one to-be-detected process meets a first condition, determining that any one to-be-detected process is a Trojan horse process; wherein the first condition comprises that the target kernel module is determined to be the kernel module hidden in the system based on the identifier.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to a method and device for detecting a Trojan process. Background Art

[0002] A Trojan process, also known as malicious code, is a user-mode process that lurks on a computer and can be controlled by an external user to steal local information or gain control. Trojan processes can cause numerous hazards, such as consuming system resources, reducing computer performance, and compromising local information security. Therefore, timely detection of Trojan processes is crucial.

[0003] However, in today's cybersecurity landscape, malicious code exists that can infiltrate the operating system kernel, concealing other Trojan processes and network activity. This technique not only provides hackers with difficult-to-detect backdoor access but also allows them to escalate to root privileges, allowing them to remain lurking within the host for extended periods, creating a difficult-to-counter advanced threat. Summary of the Invention

[0004] In an exemplary embodiment of the present application, a method and apparatus for detecting a Trojan process are provided to solve the problem that a Trojan process having a hidden kernel module as a backdoor is difficult to identify.

[0005] In a first aspect, an embodiment of the present application provides a method for detecting a Trojan process, comprising:

[0006] Obtain the process file of each process to be detected from the system's memory;

[0007] Determining an identifier of a target kernel module corresponding to any process to be detected according to a process file of the process to be detected;

[0008] When any of the processes to be detected meets a first condition, determining that any of the processes to be detected is a Trojan process; wherein the first condition includes determining, based on the identifier, that the target kernel module is a kernel module hidden in the system.

[0009] Based on the above scheme, the present application analyzes the process files in the system memory to determine the identifier of the kernel module corresponding to each process to be detected, and identifies whether the kernel module corresponding to each process is in a hidden state based on the identifier. When it is determined that the kernel module corresponding to a process is in a hidden state, it can be determined that the process is a Trojan process, and the corresponding hidden kernel module is used to assist the Trojan process in hiding its traces. Traditional schemes cannot detect Trojan processes with malicious kernel modules as backdoors. The scheme of the present application directly starts from the kernel module corresponding to the process, which can not only effectively detect Trojan processes in the system, but also locate the kernel module that helps the Trojan process hide its traces, thereby achieving kernel-level detection and killing.

[0010] In some embodiments, the processes to be detected include hidden processes in the system and processes in the system that use deleted files.

[0011] Based on the above scheme, this application identifies the processes to be detected that meet the characteristics of Trojan processes from multiple processes running in the system based on the characteristics of conventional Trojan processes, and then performs Trojan detection on the processes to be detected. Compared with the traditional method of detecting processes one by one, the scheme of this application can effectively improve the efficiency of Trojan detection.

[0012] In some embodiments, determining, based on the identifier, that the target kernel module is a kernel module hidden in the system specifically includes:

[0013] Executing a first instruction to output a first number of non-hidden kernel modules included in the system;

[0014] generating a second instruction according to the identifier, wherein the second instruction is used to unhide the target kernel module corresponding to the identifier;

[0015] After executing the second instruction, executing the first instruction again to output a second number of non-hidden kernel modules included in the system;

[0016] If the first number is not equal to the second number, it is determined that the target kernel module is a hidden kernel module in the system.

[0017] Based on the above scheme, the kernel module of the backdoor is controlled to unhide through system instructions, and then the number of kernel modules before and after the execution of the instructions is compared to determine whether there is a hidden kernel module.

[0018] In some embodiments, before obtaining the process file of each process to be detected from the memory of the system, the method further includes:

[0019] Executing the first instruction to output a third number of non-hidden kernel modules included in the system;

[0020] Generate a third instruction according to a preset identifier; the preset identifier is an identifier of a known malicious kernel module, and the third instruction is used to unhide the kernel module corresponding to the preset identifier;

[0021] After executing the third instruction, executing the first instruction again to output a fourth number of non-hidden kernel modules included in the system;

[0022] It is determined that the third quantity and the fourth quantity are equal.

[0023] Based on the above solution, before executing the Trojan detection of the process, it is first determined based on the identification of the known malicious kernel module that there is no known malicious kernel module in the system.

[0024] In some embodiments, after determining that any of the processes to be detected is a Trojan process, the method further includes:

[0025] Deleting the Trojan process and the process files of the Trojan process, and restoring the operations of the Trojan process on the files;

[0026] If it is determined based on the identifier that the target kernel module is a hidden kernel module in the system, the target kernel module is uninstalled.

[0027] Based on the above solution, after locating the Trojan process, the relevant content is deleted from the system, and the Trojan process's operations on system files are restored to ensure the integrity and security of system memory. If a hidden kernel module is confirmed to exist, it is uninstalled to achieve kernel-level detection and elimination.

[0028] In some embodiments, the first condition further includes one or more of the following:

[0029] The destination address of the communication connection associated with any of the processes to be detected complies with a preset address blacklist; or the usage rate of the central processing unit (CPU) of any of the processes to be detected exceeds a set threshold.

[0030] Based on the above solution, multiple features of each process are parsed through the process file. When any feature meets the Trojan feature, the process is determined to be a Trojan process, reducing the missed reporting rate of Trojan processes.

[0031] In a second aspect, an embodiment of the present application provides a Trojan process detection device, comprising:

[0032] An acquisition unit, used for acquiring a process file of each process to be detected from a system memory;

[0033] a processing unit, configured to determine an identifier of a target kernel module corresponding to any process to be detected based on a process file of the process to be detected;

[0034] The processing unit is further configured to determine that any process to be detected is a Trojan process when the any process to be detected satisfies a first condition; wherein the first condition includes determining, based on the identifier, that the target kernel module is a kernel module hidden in the system.

[0035] In some embodiments, the processes to be detected include hidden processes in the system and processes in the system that use deleted files.

[0036] In some embodiments, the processing unit is specifically configured to:

[0037] Executing a first instruction to output a first number of non-hidden kernel modules included in the system;

[0038] generating a second instruction according to the identifier, wherein the second instruction is used to unhide the target kernel module corresponding to the identifier;

[0039] After executing the second instruction, executing the first instruction again to output a second number of non-hidden kernel modules included in the system;

[0040] If the first number is not equal to the second number, it is determined that the target kernel module is a hidden kernel module in the system.

[0041] In some embodiments, the processing unit is further configured to:

[0042] Executing the first instruction to output a third number of non-hidden kernel modules included in the system;

[0043] Generate a third instruction according to a preset identifier; the preset identifier is an identifier of a known malicious kernel module, and the third instruction is used to unhide the kernel module corresponding to the preset identifier;

[0044] After executing the third instruction, executing the first instruction again to output a fourth number of non-hidden kernel modules included in the system;

[0045] It is determined that the third quantity and the fourth quantity are equal.

[0046] In some embodiments, the processing unit is further configured to:

[0047] Deleting the Trojan process and the process files of the Trojan process, and restoring the operations of the Trojan process on the files;

[0048] If it is determined based on the identifier that the target kernel module is a hidden kernel module in the system, the target kernel module is uninstalled.

[0049] In some embodiments, the first condition further includes one or more of the following:

[0050] The destination address of the communication connection associated with any of the processes to be detected complies with a preset address blacklist; or the usage rate of the central processing unit (CPU) of any of the processes to be detected exceeds a set threshold.

[0051] In a third aspect, an embodiment of the present application provides an electronic device comprising a controller and a memory. The memory is configured to store computer-executable instructions, and the controller executes the computer-executable instructions in the memory to utilize hardware resources in the controller to perform the steps of any possible implementation of the method of the first aspect.

[0052] In a fourth aspect, the present application provides a computer-readable storage medium, in which instructions are stored. When the computer-readable storage medium is run on a computer, the computer executes the methods in the above aspects.

[0053] In addition, the beneficial effects of the second to fourth aspects can refer to the beneficial effects described in the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present application.

[0055] Figure 1 A schematic diagram of a network architecture provided in an embodiment of the present application;

[0056] Figure 2 A flowchart of a method for detecting a Trojan process provided in an embodiment of the present application;

[0057] Figure 3 A schematic diagram of a method for detecting and killing a Trojan process provided in an embodiment of the present application;

[0058] Figure 4 A schematic diagram of the structure of a Trojan horse detection and killing device provided in an embodiment of the present application;

[0059] Figure 5 A schematic diagram of the structure of a Trojan process detection device provided in an embodiment of the present application;

[0060] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0061] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of the technical solutions of this application, but not all of them. Based on the embodiments described in this application document, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the technical solutions of this application.

[0062] The terms "first" and "second" in the specification and claims of this application and the above-mentioned drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the term "comprising" and any of its variations are intended to cover non-exclusive protection. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally also includes steps or units that are not listed, or optionally also includes other steps or units inherent to these processes, methods, products or devices. "Multiple" in this application can mean at least two, for example, two, three or more, and the embodiments of this application are not limited thereto.

[0063] In addition, the term "and / or" in this document simply describes an association between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " in this document, unless otherwise specified, generally indicates an "or" relationship between the related objects.

[0064] To facilitate understanding of the solutions of this application, the following first introduces the technical terms involved in the embodiments of this application:

[0065] 1. Root privilege: A type of system privilege, also known as root privilege, is a super administrator user account in Linux and Unix systems. This account has the privilege to access all objects in the operating system. Obtaining root privilege is equivalent to obtaining the highest privilege in the system, allowing you to add, delete, modify, and query any file in the system.

[0066] 2. Linux rootkit: A rootkit is a backdoor program left in a system by an intruder. Installed after the system has been compromised and the intruder has gained root privileges, it helps the intruder maintain long-term control of the system, search for host and network information, and conceal the intruder's traces. Different operating systems have different rootkits. Linux rootkits are classified as user-level and kernel-level. Kernel-level rootkits are further divided into loadable kernel module (LKM)-based and non-LKM-based rootkits.

[0067] 3. Loadable Kernel Module LKM: A code fragment that can be dynamically loaded into the system kernel to extend the functionality of the system kernel. It runs in kernel space and has full system permissions but no independent execution context.

[0068] 4. Mining Trojans: Attackers use various means to implant mining programs into victims' computers, exploiting their computing power to mine cryptocurrencies without their knowledge and profiting from them. These illegally implanted mining programs are known as mining Trojans. Let's use the Bitcoin system as an example to explain mining (of course, Bitcoin is just an example; there are many other types of mining, including Monero). Periodically, the Bitcoin system generates a random code. All computers on the internet search for this code to generate blocks and receive rewards. This process of searching for this code is called mining. Mining requires a significant amount of computing power, so some hackers will compromise other computers to use them for mining.

[0069] 5. Various commands and tools of Linux system: (1) lsmod command: used to display the kernel modules that have been loaded into the system. (2) wc -l command: counts the number of lines in the specified file and displays the statistical results. (3) kill command: used to terminate the running of the specified process, and sends a specified signal to the process based on the process identification (PID) to end the same process; the kill command is also used to instruct the system's kernel module to hide / unhide, that is, it can be used as a hiding switch for the kernel module, and instruct the corresponding kernel module to hide or unhide through the kernel module identification. (4) rmmod command: used to delete the specified kernel module. (5) ps -ef command: used to display all processes running in the system and information such as the PID, CPU usage, and start time of each process. (6) unhide tool: a network forensics tool used to discover processes and ports that are hidden with the help of rootkits, LKMs, and other technologies. This tool can work under Linux, Unix, and other systems.

[0070] 6. Socket connection: used to realize two-way data exchange between two programs on the network.

[0071] 7. Security Orchestration Automation and Response (SOAR) technology: used to solve security response problems in the network, mainly including three core technologies: security orchestration and automation, security incident response platform and threat intelligence platform.

[0072] The following is an introduction to the network architecture applicable to the present application solution. For example, see Figure 1 , is a schematic diagram of a network architecture provided in an embodiment of the present application. It should be understood that the embodiment of the present application is not limited to Figure 1 In the architecture shown, in addition, Figure 1 The device in the embodiment can be hardware, or functionally divided software, or a combination of the two. Figure 1 The network architecture shown includes a host device and an attack device, wherein the attack device controls the host device by implanting a Trojan process in the host device. The Trojan process invading the host device can communicate with the control process in the attack device through a socket connection and exchange data and instructions, thereby enabling the attack device to obtain files in the host device and control the host device to perform certain operations, such as utilizing the computing power of the host device for mining calculations. It should be noted that this application does not limit the specific implementation of the host device and the attack device. For example, it can be a terminal such as a personal computer (PC) or a laptop, or a server, a server cluster, or a cloud computing platform. This application does not limit this.

[0073] In modern cybersecurity, a new type of Trojan, rootkits, has been discovered. For example, Linux rootkits in Linux systems infiltrate the kernel of the host device's Linux operating system, concealing the files and network behavior of other malicious processes. This Trojan not only provides difficult-to-detect backdoor access to the attacking device but also allows escalation to root privileges. This type of Trojan is often used to steal the host device's computing power for mining. For ease of description, we will refer to this type of Trojan as a mining Trojan.

[0074] Currently, detection of mining Trojans is primarily achieved by monitoring the communication between the Trojan process on the host device and the attacking device. This involves monitoring the host device's network traffic, obtaining the IP addresses of external devices communicating with the host device, and comparing these IP addresses with malicious IP addresses in the threat intelligence database. If the IP address matches the threat intelligence database, the corresponding process on the host device is identified as a Trojan process. This disconnects the Trojan process from the attacking device, blocking the virus's instructions and data transmission. Furthermore, the Trojan process and related program files can be deleted to eliminate the virus's impact. However, this approach relies heavily on the threat intelligence database to detect Trojan processes. Therefore, mining Trojans communicating through intranet proxies or proxy servers may evade detection. Furthermore, for rootkit-type mining Trojans, backdoor programs can modify the hosts file to redirect traffic, disguising malicious communications as legitimate intranet traffic. In this case, the mining Trojan cannot be detected. Furthermore, with the help of backdoor programs, network activity and files of these mining Trojans can be tampered with, making accurate detection difficult.

[0075] Related technologies have also proposed using SOAR technology to detect mining trojans. This involves sending the host device's process information to a sandbox system and threat intelligence system to verify the legitimacy of the files and processes. Based on the verification results, a response policy is then issued to the host device's protection software or firewall. This solution is implemented by installing client software on the host device and reporting logs. However, the presence of hidden kernel modules can help mining trojans hide their presence, preventing complete collection of abnormal logs. Consequently, sandbox systems or threat intelligence systems cannot detect mining trojans based on incomplete logs.

[0076] It can be seen that the current security protection technology cannot effectively identify and remove rootkit-type Trojan processes. In order to solve this problem, the embodiment of the present application proposes a method and device for detecting Trojan processes. By extracting and analyzing the process files of the abnormal process, the kernel module corresponding to the abnormal process is identified. When it is determined that the identified kernel module is in a hidden state in the system, the corresponding process is determined to be a Trojan process. The solution of the present application can not only effectively detect Trojan processes in the system, but also locate the kernel module that helps the Trojan process hide traces. Exemplarily, the solution of the present application can be applied to cloud computing environments, including private clouds, public clouds, and hybrid clouds, and the solution can be set in virtual machines and container environments. Alternatively, the solution of the present application can also be applied to the security protection of Internet of Things devices. The present application does not limit the scenarios to which the detection solution for Trojan processes is applicable.

[0077] Next, combine Figure 1 The network architecture shown here introduces the solution of this application. Figure 2 , is a flow chart of a method for detecting a Trojan process provided by an embodiment of the present application. For example, the method flow can be as follows: Figure 1 The architecture shown may be implemented by a host device, or by a firewall gateway device in a local area network to which the host device belongs, and this application does not limit this. Figure 2 The method flow shown specifically includes:

[0078] 201. Obtain the process file of each process to be detected from the system memory.

[0079] For example, the present application does not limit the operating system of the host device application, for example, a Linux system can be used. The process file of each process running in the system is stored in the memory, and the process file may include the process stack information, string and shell script information, etc.

[0080] The processes to be detected include hidden processes in the system and processes that use deleted files. As an example, the unhide tool can be used to identify hidden processes in the system. For example, the ps -ef command can be used to output a list of normally running, non-hidden processes in the system, and then the unhide tool can be used to output a list of all processes (including hidden and non-hidden processes). The lists output in the two steps can be compared to identify hidden processes. Furthermore, the association between the file system and each process can be checked to identify processes that use deleted files.

[0081] 202 : Determine an identifier of a target kernel module corresponding to any process to be detected according to a process file of any process to be detected.

[0082] For example, after obtaining the process file of each process to be detected from memory, a memory dump of each process file can be performed, and the dump file can be parsed to extract the shell script information contained therein. The shell script information of each process includes the identifier of the kernel module corresponding to the process, which can also be called the kernel module's signal number. The identifier of the kernel module corresponding to each process is the variable value of the SIGMODINVIS parameter contained in the shell script information of the process.

[0083] 203. When any process to be detected meets the first condition, determine that any process to be detected is a Trojan process.

[0084] The first condition includes determining, based on the identifier, that a target kernel module corresponding to any process to be detected is a kernel module hidden in the system. Exemplarily, the first condition may also include that a CPU usage rate of any process to be detected exceeds a set threshold, or that a destination address of a communication connection associated with any process to be detected meets one or more items in an address blacklist.

[0085] For example, a kill command can be used based on the target kernel module's identification to determine whether the target kernel module is a hidden kernel module. Since the kill command can be used to switch kernel module hiding, the number of kernel modules before and after executing the kill command based on the target kernel module's identification can be compared to determine whether the target kernel module is a hidden kernel module. If so, the target kernel module is a malicious kernel module, used to help any detected process hide its traces, thereby determining that the detected process is a Trojan process.

[0086] Based on the above scheme, the present application analyzes the process files in the system memory to determine the identifier of the kernel module corresponding to each process to be detected, and identifies whether the kernel module corresponding to each process is in a hidden state based on the identifier. When it is determined that the kernel module corresponding to a process is in a hidden state, it can be determined that the process is a Trojan process, and the corresponding hidden kernel module is used to assist the Trojan process in hiding its traces. Traditional schemes cannot detect Trojan processes with malicious kernel modules as backdoors. The scheme of the present application directly starts from the kernel module corresponding to the process, which can not only effectively detect Trojan processes in the system, but also locate the kernel module that helps the Trojan process hide its traces, thereby achieving kernel-level detection and killing.

[0087] In some embodiments, after determining the process to be detected, the process file of the process to be detected can be analyzed to determine whether the corresponding kernel module is a hidden kernel module. For example, the process file of each process to be detected can be analyzed separately using the PID of each process to be detected as a benchmark. The following describes the process of analyzing the process file and determining the hidden kernel module using process A as an example. Process A is any one of the multiple processes to be detected.

[0088] Exemplarily, a memory dump of the process file of process A can be performed, and the shell script information of process A contained in the dump file can be extracted. The identifier of the kernel module corresponding to process A can be obtained from the shell script information. For ease of description, the kernel module corresponding to process A will be referred to as kernel module A. Furthermore, a first instruction is executed to output a first number of all non-hidden kernel modules contained in the system. Exemplarily, the first instruction can be a combination of the lsmod command and the wc -1 command. Furthermore, a second instruction is generated based on the identifier of kernel module A. The second instruction can be a kill command, which is used to unhide kernel module A. For example, if kernel module A's identifier is 64, the corresponding second instruction can be kill -64.0. After executing the second instruction, the first instruction is executed again to output a second number of hidden kernel modules contained in the system. If the first number equals the second number, it can be determined that kernel module A is not a hidden kernel module, and therefore, the corresponding process A is not a Trojan process. Conversely, if the first number does not equal the second number, it can be determined that kernel module A is a hidden kernel module, and therefore, the corresponding process A is a Trojan process.

[0089] As an optional method, after determining the process to be detected, the operations performed by the process indicated in the process file can be analyzed to determine whether it is a Trojan process. In one possible implementation, the CPU usage of the process to be detected can be parsed from the process file. When the CPU usage exceeds a set threshold, the process to be detected can be determined to be a Trojan process. For example, when the CPU usage of the process to be detected exceeds 100%, it is determined to be a Trojan process.

[0090] In another possible implementation, the destination address of the communication connection associated with the process to be detected included in the process file can be analyzed, and this can be used to determine whether the process to be detected is a Trojan process. Exemplarily, the process of determining whether it is a Trojan process based on the communication connection associated with process A is introduced by taking process A as an example. Optionally, the file descriptors contained in the process file of process A can be traversed to parse out the socket communication connections contained therein, and determine the destination address of each communication connection. Further, determine whether the parsed destination address meets the preset address blacklist. For example, the parsed destination address can be reported to the threat intelligence platform for detection, and determine whether the parsed destination address is an address in the address blacklist based on the detection result returned by the threat intelligence platform. If so, it can be determined that process A is a Trojan process.

[0091] In some embodiments, when determining whether a process to be detected is a Trojan process, the multiple features identified from the process file of the process to be detected as described in the above embodiments can also be used to make a judgment. For example, still taking process A as an example, it can be seen from the description in the above embodiments that four features are parsed from the process file of process A: the destination address of the communication connection associated with process A, the identifier of the kernel module corresponding to process A, whether process A uses deleted files, and the CPU usage of process A. When determining whether process A is a Trojan process, it can be determined that process A is a Trojan process when any of the above four features meets the Trojan feature. For example, the Trojan features of a process may include: the destination address of the associated communication connection meets the address blacklist, the corresponding kernel module is a hidden kernel module, deleted files are used, and the CPU occupancy rate exceeds a set threshold.

[0092] In one possible implementation, when determining whether a process to be detected has Trojan features based on its process file, the method introduced in the above embodiment can be used to extract information from the process file item by item for analysis. The process file can also be input into a pre-trained neural network to output the Trojan features contained in the process file, thereby improving the efficiency of process detection.

[0093] As an optional method, after determining that a process to be detected is a Trojan process, the Trojan process and its process files can be deleted, and the Trojan process's operations on system files can be restored. For example, the Trojan process's operations on various files in the system can be determined based on its process files, and each operation can be restored. Furthermore, the system's hosts file can be checked based on the Trojan process's process files, and abnormal entries in the hosts file modified by the Trojan process can be searched and restored. Furthermore, the SSH login failure log can be queried based on the Trojan process's process files. When it is determined that the number of abnormal logins exceeds a threshold, an abnormal prompt message is generated to alert the administrator that a brute force attack may have occurred.

[0094] In some embodiments, after determining that a process to be detected is a Trojan process, if the kernel module corresponding to the Trojan process is a hidden kernel module, the kernel module corresponding to the Trojan process can be uninstalled. Exemplarily, the corresponding kernel module can be uninstalled using the rmmod command.

[0095] Exemplarily, before extracting the process file to detect the Trojan process, it is also possible to determine whether there is a hidden kernel module in the system based on the identifier of the known malicious kernel module. In one possible implementation, before obtaining the process file, a first instruction can be executed to output a third number of non-hidden kernel modules contained in the system. The first instruction is a combination of the lsmod command and the wc -1 command. Furthermore, a third instruction is generated based on the identifier of the known malicious kernel module, and the third instruction is a kill instruction for canceling the hidden state of the known malicious kernel module.

[0096] After executing the third instruction, execute the first instruction again to output the fourth number of non-hidden kernel modules contained in the system. For example, if the known malicious kernel modules are identified as 53 and 63, the third instruction can be set to kill-53.0 and kill-63.0. After executing the third instruction, if there are known malicious kernel modules hidden in the system, they will be displayed after executing the first instruction again. Furthermore, it can be determined whether the third number and the fourth number are equal. If they are equal, it means that there are no hidden known malicious kernel modules, and the process detection can be continued to determine whether there are other hidden kernel modules based on the process file; otherwise, if they are equal, it means that there are hidden known malicious kernel modules, and the rmmod command can be executed to uninstall the known malicious kernel modules.

[0097] In order to further understand the solution of this application, the following is an introduction with reference to specific embodiments. Figure 3 , is a flow chart of a method for detecting and killing a Trojan process provided in an embodiment of the present application, specifically including:

[0098] 301, determine whether there is a hidden kernel module in the system.

[0099] Exemplarily, a kill command may be issued using the identifier of the kernel module to be detected to determine whether a hidden kernel module exists.

[0100] If yes, continue to execute step 302.

[0101] If not, continue to execute step 303.

[0102] 302, uninstall the hidden kernel module in the system.

[0103] Exemplarily, the hidden kernel module may be uninstalled using the rmmod command.

[0104] 303. Determine whether there is a hidden process in the system.

[0105] For example, the unhide tool may be used to detect whether there are hidden processes in the system. The specific detection process may be referred to the introduction in the above embodiment, which will not be described in detail here.

[0106] If yes, continue to execute step 305.

[0107] If not, continue to execute step 304.

[0108] 304. Determine whether there is any process in the system that uses the deleted file.

[0109] If yes, continue to execute step 305.

[0110] If not, the process ends.

[0111] 305 , taking the PID of each process as a benchmark, extracting process features from the process file of each process.

[0112] For example, taking process A as an example, the features of process A extracted from process A include the destination address of the communication connection associated with process A, the identifier of the kernel module corresponding to process A, whether process A uses deleted files, and the CPU usage of process A.

[0113] After extracting the identifier of the kernel module corresponding to process A, the process returns to step 301 to determine whether the kernel module corresponding to process A is a hidden kernel module, and then continues to execute step 306 simultaneously.

[0114] 306 , judging whether each process is a Trojan process based on the characteristics of each process.

[0115] For example, when any one of the multiple features of a process meets the Trojan feature, the process is determined to be a Trojan process. The process of determining whether each feature of the process meets the Trojan feature can be referred to the introduction of the above embodiment and will not be repeated here.

[0116] If yes, continue to step 307.

[0117] If not, the process ends.

[0118] 307, delete the Trojan process and restore the Trojan process's related operations on system files.

[0119] As an optional method, the solution described in the above embodiment can be executed by a host device or a gateway firewall device. For the sake of convenience, the execution subject of the solution of this application is collectively referred to as a Trojan killing device. In an optional method, it can also be executed by a specific processing module in the Trojan killing device. The following introduces each processing module in the Trojan killing device and its corresponding functions. For example, see Figure 4 , is a schematic diagram of the structure of a Trojan horse detection and killing device provided in an embodiment of the present application. It should be noted that, Figure 4 The modules included in are only used as an example and are not intended to limit the specific components of the Trojan horse detection and killing device. Figure 4 The architecture shown includes a detection module and a killing module, wherein the detection module includes a kernel detection module and a process detection module, and the killing module includes a kernel unloading module, a process killing module and a risk inspection module.

[0120] For example, Figure 4 The kernel detection module is configured to detect whether a known malicious kernel module is hidden in the system before detecting a process. The kernel detection module is further configured to detect whether the kernel module corresponding to the process to be detected is hidden based on the kernel module's identifier after determining the kernel module corresponding to the process to be detected based on the process file. Figure 4 The process detection module shown is used to determine the process to be detected from the system, parse the characteristics of the process to be detected from the process file of the process to be detected, and determine whether the characteristics of the process to be detected meet the characteristics of a Trojan horse, thereby determining whether the process to be detected is a Trojan horse process. Figure 4 The kernel unloading module is used to unload the hidden kernel module when it is determined that the hidden kernel module exists in the system. Figure 4 The process killing module shown in is used to delete the determined Trojan process and the process file corresponding to the Trojan process. Figure 4The risk check module shown in is used to check multiple files (including hosts files) in the system according to the process files of the Trojan process, determine abnormal entries modified by the Trojan process, and reply to the abnormal entries.

[0121] Based on the same concept as the above method, see Figure 5 , is a Trojan process detection device 500 provided in an embodiment of the present application. The device 500 is used to implement the various steps in the above method embodiment. In order to avoid repetition, it will not be described here. The device 500 includes: an acquisition unit 501 and a processing unit 502.

[0122] The acquisition unit 501 is used to acquire the process file of each process to be detected from the system memory;

[0123] The processing unit 502 is configured to determine an identifier of a target kernel module corresponding to any process to be detected based on a process file of the process to be detected;

[0124] The processing unit 502 is further configured to determine that any process to be detected is a Trojan process when the any process to be detected satisfies a first condition; wherein the first condition includes determining that the target kernel module is a kernel module hidden in the system based on the identifier.

[0125] In some embodiments, the processes to be detected include hidden processes in the system and processes in the system that use deleted files.

[0126] In some embodiments, the processing unit 502 is specifically configured to:

[0127] Executing a first instruction to output a first number of non-hidden kernel modules included in the system;

[0128] generating a second instruction according to the identifier, wherein the second instruction is used to unhide the target kernel module corresponding to the identifier;

[0129] After executing the second instruction, executing the first instruction again to output a second number of non-hidden kernel modules included in the system;

[0130] If the first number is not equal to the second number, it is determined that the target kernel module is a hidden kernel module in the system.

[0131] In some embodiments, the processing unit 502 is further configured to:

[0132] Executing the first instruction to output a third number of non-hidden kernel modules included in the system;

[0133] Generate a third instruction according to a preset identifier; the preset identifier is an identifier of a known malicious kernel module, and the third instruction is used to unhide the kernel module corresponding to the preset identifier;

[0134] After executing the third instruction, executing the first instruction again to output a fourth number of non-hidden kernel modules included in the system;

[0135] It is determined that the third quantity and the fourth quantity are equal.

[0136] In some embodiments, the processing unit 502 is further configured to:

[0137] Deleting the Trojan process and the process files of the Trojan process, and restoring the operations of the Trojan process on the files;

[0138] If it is determined based on the identifier that the target kernel module is a hidden kernel module in the system, the target kernel module is uninstalled.

[0139] In some embodiments, the first condition also includes one or more of the following: the destination address of the communication connection associated with any process to be detected complies with a preset address blacklist; or the usage rate of the central processing unit (CPU) of any process to be detected exceeds a set threshold.

[0140] Figure 6 The electronic device 600 according to the embodiment of the present application is shown in FIG. The electronic device 600 may further include a communication interface 603 , such as a network port, through which the electronic device may transmit data.

[0141] In the embodiment of the present application, the memory 602 stores instructions that can be executed by at least one controller 601. At least one controller 601 can be used to execute the various steps in the above method by executing the instructions stored in the memory 602. For example, the controller 601 can implement the above Figure 5 The functions of the acquisition unit 501 and the processing unit 502 are as follows.

[0142] Controller 601 is the control center of the electronic device, connecting various parts of the entire electronic device using various interfaces and lines, and running or executing instructions stored in memory 602 and accessing data stored in memory 602. Optionally, controller 601 may include one or more processing units. Controller 601 may integrate an application controller and a modem controller, where the application controller primarily handles the operating system and application programs, and the modem controller primarily handles wireless communications. It is understood that the modem controller may not be integrated into controller 601. In some embodiments, controller 601 and memory 602 may be implemented on the same chip. In some embodiments, they may also be implemented on separate chips.

[0143] The controller 601 can be a general controller, such as a central processing unit (CPU), a digital signal controller, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, which can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general controller can be a microcontroller or any conventional controller, etc. The steps performed by the data statistics platform disclosed in the embodiments of the present application can be performed directly by a hardware controller, or performed by a combination of hardware and software modules in the controller.

[0144] The memory 602 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The memory 602 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (Random Access Memory, RAM), a static random access memory (Static Random Access Memory, SRAM), a programmable read-only memory (Programmable Read Only Memory, PROM), a read-only memory (Read Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic memory, a disk, an optical disk, etc. The memory 602 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 602 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.

[0145] By designing and programming the controller 601, for example, the code corresponding to the method introduced in the aforementioned embodiment can be solidified into the chip, so that the chip can execute the steps of the aforementioned method during operation. How to design and program the controller 601 is a technology well known to those skilled in the art and will not be repeated here.

[0146] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0147] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a controller of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the controller of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0148] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device that implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0149] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0150] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present application.

[0151] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A method for detecting a Trojan process, characterized in that: include: Get the process file of each process to be detected from the system's memory; Determining an identifier of a target kernel module corresponding to any process to be detected according to a process file of the process to be detected; When any of the processes to be detected meets a first condition, determining that any of the processes to be detected is a Trojan process; wherein the first condition includes determining, based on the identifier, that the target kernel module is a kernel module hidden in the system.

2. The method according to claim 1, characterized in that The processes to be detected include processes hidden in the system and processes using deleted files in the system.

3. The method according to claim 1 or 2, characterized in that Determining, based on the identifier, that the target kernel module is a kernel module hidden in the system specifically includes: Executing a first instruction to output a first number of non-hidden kernel modules included in the system; generating a second instruction according to the identifier, wherein the second instruction is used to unhide the target kernel module corresponding to the identifier; After executing the second instruction, executing the first instruction again to output a second number of non-hidden kernel modules included in the system; If the first number is not equal to the second number, it is determined that the target kernel module is a hidden kernel module in the system.

4. The method according to claim 3, characterized in that Before obtaining the process file of each process to be detected from the system memory, the method further includes: Executing the first instruction to output a third number of non-hidden kernel modules included in the system; Generate a third instruction according to a preset identifier; the preset identifier is an identifier of a known malicious kernel module, and the third instruction is used to unhide the kernel module corresponding to the preset identifier; After executing the third instruction, executing the first instruction again to output a fourth number of non-hidden kernel modules included in the system; The third quantity and the fourth quantity are determined to be equal.

5. The method according to claim 1 or 2, characterized in that After determining that any of the processes to be detected is a Trojan process, the method further includes: Deleting the Trojan process and the process files of the Trojan process, and restoring the operations of the Trojan process on the files; If it is determined based on the identifier that the target kernel module is a hidden kernel module in the system, the target kernel module is uninstalled.

6. The method according to claim 1 or 2, characterized in that The first condition also includes one or more of the following: The destination address of the communication connection associated with any of the processes to be detected complies with a preset address blacklist; or the usage rate of the central processing unit (CPU) of any of the processes to be detected exceeds a set threshold.

7. A Trojan process detection device, characterized in that: include: An acquisition unit, used for acquiring a process file of each process to be detected from a system memory; a processing unit, configured to determine an identifier of a target kernel module corresponding to any process to be detected based on a process file of the process to be detected; The processing unit is further configured to determine that any process to be detected is a Trojan process when the any process to be detected satisfies a first condition; wherein the first condition includes determining, based on the identifier, that the target kernel module is a kernel module hidden in the system.

8. The device according to claim 7, characterized in that The processes to be detected include processes hidden in the system and processes using deleted files in the system.

9. The device according to claim 7 or 8, characterized in that The processing unit is specifically configured to: Executing a first instruction to output a first number of non-hidden kernel modules included in the system; generating a second instruction according to the identifier, wherein the second instruction is used to unhide the target kernel module corresponding to the identifier; After executing the second instruction, executing the first instruction again to output a second number of non-hidden kernel modules included in the system; If the first number is not equal to the second number, it is determined that the target kernel module is a hidden kernel module in the system.

10. The device according to claim 9, characterized in that The processing unit is further configured to: Executing the first instruction to output a third number of non-hidden kernel modules included in the system; Generate a third instruction according to a preset identifier; the preset identifier is an identifier of a known malicious kernel module, and the third instruction is used to unhide the kernel module corresponding to the preset identifier; After executing the third instruction, executing the first instruction again to output a fourth number of non-hidden kernel modules included in the system; It is determined that the third quantity and the fourth quantity are equal.

11. The device according to claim 7 or 8, characterized in that The processing unit is further configured to: Deleting the Trojan process and the process files of the Trojan process, and restoring the operations of the Trojan process on the files; If it is determined based on the identifier that the target kernel module is a hidden kernel module in the system, the target kernel module is uninstalled.

12. The device according to claim 7 or 8, characterized in that The first condition also includes one or more of the following: The destination address of the communication connection associated with any of the processes to be detected complies with a preset address blacklist; or the usage rate of the central processing unit (CPU) of any of the processes to be detected exceeds a set threshold.

13. An electronic device, characterized in that: The electronic device includes a controller and a memory, The memory is used to store computer programs or instructions; The controller is configured to execute the computer program or instructions in the memory so that the method according to any one of claims 1 to 6 is performed.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which, when called by a computer, enable the computer to execute the method according to any one of claims 1 to 6.

Images