Intelligent terminal kernel malicious behavior real-time detection method and device, equipment and medium

Abstract

The embodiment of the invention provides an intelligent terminal kernel malicious behavior real-time detection method and device, equipment and a medium. In the embodiment of the invention, the feature data set is generated based on the calling record when the function corresponding to each event which is specified to be tracked in the configuration file is called, so that the malicious software detection model is trained by utilizing the feature data set to be used for monitoring whether at least one application program has a malicious behavior or not; in this way, the malicious application program can be accurately recognized, and effective detection of the malicious application program is achieved. Furthermore, in the embodiment of the invention, when it is detected that the write-in function of the virtual file system is called, whether the behavior of writing the function into the target file is a potential two-stage release attack malicious behavior or not is detected by utilizing a corresponding detection processing program based on a calling record when the function is called; and a prompt is output when the malicious attack behavior is released for the potential second stage, so that the malicious behavior can be quickly and accurately identified, and the attack is prevented from being neglected.

Description

Technical Field

[0001] The present application relates to the field of detection technology, and in particular to a method, device, equipment and medium for real-time detection of malicious behavior in the kernel of a smart terminal. Background Art

[0002] With the upgrading of the anti-countermeasures technology of malicious applications, malicious applications usually use anti-countermeasures such as obfuscation, Java reflection, and dynamic loading to hide, which makes these malicious applications difficult to identify and detect. In practical applications, dynamic analysis methods are usually used to overcome the above-mentioned anti-countermeasures to achieve the detection of malicious applications. However, since benign applications also use the above-mentioned anti-countermeasures in normal business scenarios, it is difficult to effectively distinguish malicious applications from normal applications using the above-mentioned dynamic analysis methods. Therefore, how to achieve effective detection of malicious applications is a technical problem that needs to be solved urgently. Summary of the invention

[0003] In view of this, the present application provides a method, apparatus, device and medium for real-time detection of malicious behavior in the kernel of a smart terminal, so as to achieve effective detection of malicious applications in a smart terminal.

[0004] The embodiment of the present application provides a method for real-time detection of malicious behavior in a smart terminal kernel, which is applied to an electronic device, wherein a kernel in the electronic device loads a function detection program, and the kernel also runs a detection processing program associated with at least one event specified in a configuration file to be tracked; the method comprises: If a detection handler associated with a kernel function call event is running in the kernel, when the virtual file system write function is called, a call record of the virtual file system write function is obtained, and the target file written by calling the virtual file system write function is detected by the detection handler to detect whether the behavior of calling the virtual file system write function to write the target file is a potential second-stage release attack malicious behavior, and if so, a prompt is output; Generate a feature data set based on the call records obtained by the detection processing program associated with each event when the function corresponding to each event is called; the call records at least include: the function call frequency and the call sequence; the call sequence at least includes: the caller of the function and other operations associated with the operation performed after the function is called; A malware detection model is trained by using supervised machine learning based on a feature data set; the malware detection model is used to monitor whether at least one application has malicious behavior.

[0005] The embodiment of the present application also provides a real-time detection device for malicious behavior of a smart terminal kernel, which is applied to an electronic device, wherein a kernel in the electronic device loads a function detection program, and the kernel also runs a detection processing program associated with at least one event specified in a configuration file to be tracked; the device comprises: a detection module, for obtaining a call record of the virtual file system write function when the virtual file system write function is called if a detection handler associated with the kernel function call event is running in the kernel, and detecting the target file written by calling the virtual file system write function through the detection handler to detect whether the behavior of calling the virtual file system write function to write the target file is a potential malicious behavior of the second-stage release attack, and if so, outputting a prompt; A generating module, for generating a feature data set based on the call records obtained by the detection processing program associated with each event when the function corresponding to each event is called; the call records at least include: the function call frequency and the call sequence; the call sequence at least includes: the caller of the function and other operations associated with the operation performed after the function is called; The training module is used to apply supervised machine learning based on the feature data set to train a malware detection model; the malware detection model is used to monitor whether at least one application has malicious behavior.

[0006] The present application also provides an electronic device, the electronic device comprising: Processor; and A computer-readable storage medium stores computer program instructions, which, when executed by a processor, cause the processor to execute the steps of the above method.

[0007] An embodiment of the present application further provides a computer-readable storage medium, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the processor executes the steps in the above method.

[0008] It can be seen from the above technical solution that in an embodiment of the present application, a feature data set is generated based on the call records when the functions corresponding to each event that needs to be tracked in the configuration file are called, and the malware detection model is trained using the feature data set to monitor whether at least one application has malicious behavior. In this way, malicious applications can be accurately identified and effective detection of malicious applications can be achieved.

[0009] Furthermore, in an embodiment of the present application, when it is detected that the virtual file system write function is called, the corresponding detection handler is used to detect whether the behavior of the function writing the target file is a potential second-stage release attack malicious behavior based on the call record when the function is called, and a prompt is output when it is a potential second-stage release attack malicious behavior. In this way, malicious behavior can be identified quickly and accurately to avoid attacks being ignored.

[0010] Furthermore, in the embodiments of the present application, there is no need to modify the kernel source code and application programs in the system. Instead, a function detection program is loaded in the kernel to implement call tracking of the functions corresponding to each event that needs to be tracked. In this way, function call monitoring of the application can be implemented without modifying the kernel source code and application programs, thereby improving the stability of the system operation. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings, which are incorporated in the specification and constitute a part of this application, illustrate embodiments consistent with the application and, together with the description, serve to explain the principles of the application.

[0012] Figure 1 A flow chart of the method provided in an embodiment of the present application.

[0013] Figure 2 Another method flow chart provided in the embodiment of the present application.

[0014] Figure 3 A flowchart of another method provided in an embodiment of the present application.

[0015] Figure 4 A schematic diagram of the device structure provided in an embodiment of the present application.

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

[0017] In order to enable those skilled in the art to better understand the technical solutions provided by the embodiments of the present application and to make the above-mentioned purposes, features and advantages of the embodiments of the present application more obvious and understandable, the technical solutions in the embodiments of the present application are further described in detail below in conjunction with the accompanying drawings.

[0018] See also Figure 1 , Figure 1 A flowchart of a method provided in an embodiment of the present application. The method is applied to an electronic device. As an embodiment, the electronic device may be, for example, a smart terminal, a server, or other device, which is not specifically limited in this embodiment.

[0019] In this embodiment, the kernel in the electronic device loads a function detection program. Here, the function detection program refers to a program used for function call detection. The function detection program includes a detection handler associated with at least one event specified in the configuration file to be tracked; based on this, the above-mentioned kernel also runs a detection handler associated with at least one event specified in the configuration file to be tracked, so as to detect the calling status of the function corresponding to each event. As for how to load the function detection program and the specific content of the configuration file, this embodiment does not specifically limit it, and an example will be given below, so it will not be repeated here.

[0020] Based on the above description, Figure 1 As shown, the process may include the following steps: Step 101, if a detection handler associated with a kernel function call event is running in the kernel, then when the virtual file system write function is called, a call record of the virtual file system write function is obtained, and the target file written by calling the virtual file system write function is detected through the detection handler to detect whether the behavior of calling the virtual file system write function to write the target file is a potential second-stage release attack malicious behavior, and if so, a prompt is output.

[0021] In this embodiment, most malicious applications are usually similar to normal applications and do not directly expose some operations that can be classified as malicious behaviors, but these malicious applications widely use a two-stage release attack technology to release the second-stage malicious attack; specifically, malicious applications usually store malicious payloads in files to release the second-stage malicious attack by means such as file decompression or downloading. Based on this, this embodiment can detect whether the behavior of calling the virtual file system write function to write to the target file is a potential two-stage release attack malicious behavior by detecting the call of the virtual file system write function, so as to achieve effective identification of this type of attack. Here, the virtual file system write function is also the Vfs_write function; Vfs_write is the abbreviation of (Virtual File System Write).

[0022] In this embodiment, as an embodiment, the above-mentioned call record at least includes: function call frequency and call sequence.

[0023] The function call frequency refers to the number of times the function is called within a specified time period. The specified time period is not specifically limited here, for example, it can be the time period from the time when the detection processing program associated with the event corresponding to the function is started to the current time.

[0024] The above-mentioned calling sequence at least includes the caller of the function and other operations associated with the operation performed after the function is called. Here, the caller of the function refers to the application that calls the function. As for other operations associated with the operation performed after the function is called, this embodiment takes the Vfs_write function as an example for explanation: the operation performed after the Vfs_write function is called refers to the write operation of calling the Vfs_write function to write the target file; based on this, before writing the target file, operations such as opening the target file and allocating memory for the target file will be involved. Therefore, other operations associated with the operation performed after the Vfs_write function is called may include, for example, calling the virtual file system open function to open the target file, and calling the kernel memory allocation function to allocate memory for the target file. It should be noted that for other functions except the Vfs_write function, other operations associated with the operation performed after the function is called are similar to the above-mentioned Vfs_write function, and will not be repeated here.

[0025] In this embodiment, a malware detection model can be trained to monitor whether at least one application has malicious behavior. Based on this, in the model training stage of the malware detection model, the obtained call record when the Vfs_write function is called can be used for the training of the malware detection model; in the model application stage of the malware detection model, the obtained call record when the Vfs_write function is called can be used by the malware detection model to monitor whether the application has malicious behavior.

[0026] As for how to detect whether the behavior of calling the virtual file system write function to write the target file in step 101 is a potential malicious behavior of the second-stage release attack, and how to output a prompt, the following will be described with examples and will not be repeated here.

[0027] Step 102 : Generate a feature data set based on the call records obtained when the functions corresponding to the events are called by the detection processing programs associated with the events to be tracked specified in the configuration file.

[0028] In this embodiment, as described above, the call record includes at least: the frequency of function calls and the call sequence; wherein the call sequence includes at least: the caller of the function and other operations associated with the operations performed after the function is called. As an embodiment, the call record may also include the input parameters of the function, which is not specifically limited in this embodiment. The input parameters here refer to the parameters passed to the function when the function is called. For example, taking the Vfs_write function as an example, the input parameters of the Vfs_write function may refer to the target file written by the Vfs_write function.

[0029] In this embodiment, as an embodiment, this step 102 can be specifically implemented as: taking the call record when the function corresponding to each event is called as the feature data set; or, filtering out part of the call record when the function corresponding to each event is called as the feature data set, and so on.

[0030] As for how to filter out part of the content from the call records when the function corresponding to each event is called to serve as a feature data set, this embodiment does not specifically limit it; for example, for multiple call records corresponding to the same function with the same function caller, one call record can be selected from these multiple call records to serve as a feature data set.

[0031] Step 103: Using supervised machine learning based on the feature data set, a malware detection model is trained; the malware detection model is used to monitor whether at least one application has malicious behavior.

[0032] In this embodiment, the feature data set obtained above is used as a training data set, and a malware detection model is obtained by training through supervised machine learning. Based on this, after the malware detection model is obtained through training, the trained malware detection model can be stored, so that when it is necessary to monitor whether an application has malicious behavior in the future, the stored malware detection model can be used to monitor whether at least one application has malicious behavior.

[0033] In this embodiment, as an embodiment, the above-mentioned storage of the trained malware detection model may include, for example, storing the trained malware detection model in the electronic device; or storing the trained malware detection model in the cloud; and so on.

[0034] So far, completed Figure 1 The process shown.

[0035] pass Figure 1 As can be seen from the illustrated process, in the embodiment of the present application, a feature data set is generated based on the call records when the functions corresponding to each event that needs to be tracked in the configuration file are called, and the feature data set is used to train a malware detection model for monitoring whether at least one application has malicious behavior. In this way, malicious applications can be accurately identified and effective detection of malicious applications can be achieved.

[0036] Furthermore, in an embodiment of the present application, when it is detected that the virtual file system write function is called, the corresponding detection handler is used to detect whether the behavior of the function writing the target file is a potential second-stage release attack malicious behavior based on the call record when the function is called, and a prompt is output when it is a potential second-stage release attack malicious behavior. In this way, malicious behavior can be identified quickly and accurately to avoid attacks being ignored.

[0037] Furthermore, in the embodiments of the present application, there is no need to modify the kernel source code and application programs in the system. Instead, a function detection program is loaded in the kernel to implement call tracking of the functions corresponding to each event that needs to be tracked. In this way, function call monitoring of the application can be implemented without modifying the kernel source code and application programs, thereby improving the stability of the system operation.

[0038] The following describes how to load the above function detection program: In this embodiment, as an embodiment, loading the above-mentioned function detection program can be specifically implemented as: loading the above-mentioned function detection program into the kernel through Berkley Packet Filter (BPF) or Extended Berkley Packet Filter (eBPF).

[0039] Here, BPF refers to a tool that allows users to write programs in the user space of electronic devices and load the programs in the user space into the kernel through a specific Application Programming Interface (API) call. eBPF is an extension based on BPF and also has the functions of BPF.

[0040] The above configuration files are further described below: In this embodiment, the specific content of the configuration file is not limited and can be flexibly configured based on actual application requirements. For example, as an embodiment, the above configuration file may include at least one event that needs to be tracked and the functions corresponding to each event. This embodiment can not only improve the flexibility of function call monitoring of the application program by dynamically configuring at least one event that needs to be tracked and the functions corresponding to each event in the configuration file based on actual application requirements, but also can perform accurate function call monitoring, thereby effectively responding to and resisting various malicious attack methods of malicious applications, that is, having a strong confrontation mechanism.

[0041] In this embodiment, the at least one event that needs to be tracked may include at least one of the following: a framework layer API method call event, a Native layer library function call event, a direct system call event, and a kernel function call event.

[0042] In this embodiment, as described above, as an embodiment, for each detection handler associated with an event, the detection handler associated with the event can be associated with at least one function corresponding to the event by means of Hook mounting, so that the detection handler associated with the event monitors the call of at least one function corresponding to the event.

[0043] In this embodiment, the functions corresponding to the above-mentioned events may include, for example, kernel memory allocation function, kernel memory release function, virtual file system open function, virtual file system write function, virtual file system read function, process creation function, process exit function, process cloning function, Internet control socket receive function, TCP message send function, and TCP message receive function.

[0044] Here, the kernel memory allocation function, also known as the Kmalloc function, refers to the function used to allocate memory in the kernel space; Kmalloc is the abbreviation of Kernel Memory Allocation. The kernel memory release function, also known as the Kfree function, refers to the function used to release memory in the kernel space; Kfree is the abbreviation of Kernel memory Free.

[0045] The virtual file system open function, also known as the Vfs_open function, is a function used to open a file in the virtual file system; Vfs_open is the abbreviation of Virtual File System Open. The virtual file system write function, also known as the Vfs_write function, is a function used to write a file in the virtual file system. The virtual file system read function, also known as the Vfs_read function, is a function used to read a file in the virtual file system; Vfs_read is the abbreviation of Virtual File System Read.

[0046] The process creation function, also known as the Do Fork function, is a function used to create a process. The process exit function, also known as the Do Exit function, is a function used to exit a process. The process cloning function, also known as the Clone function, is a function used to clone (or copy) a process.

[0047] The Internet Control Socket Accept function, also known as the Inet_csk_accept function, is a function used to accept a TCP connection request and create a new socket for subsequent communication. Inet_csk_accept is the abbreviation of Internet Control Socket Accept.

[0048] The TCP message sending function, also known as the Tcp_sendmsg function, is a function used to send messages through TCP; TCP is the abbreviation of Transmission Control Protocol; sendmsg is the abbreviation of SendMessage. The TCP message receiving function, also known as the Tcp_recvmsg function, is a function used to receive messages through TCP; recvmsg is the abbreviation of Receive Message.

[0049] Exemplarily, assume that the configuration file contains framework layer API method call events, Native layer library function call events, direct system call events, and kernel function call events. Among them, for the framework layer API method call events, when configuring in the configuration file, they can be configured as follows: API identifier (such as API name), and API method corresponding to the API identifier. For the Native layer library function call events, when configuring in the configuration file, they can be configured as follows: library function call path, library function identifier (such as library function name), and parameter type of input parameters of the library function. For direct system call events, when configuring in the configuration file, they can be configured as follows: system call identifier (such as system call name). For kernel function call events, when configuring in the configuration file, they can be configured as follows: kernel function identifier (such as kernel function name).

[0050] The description of the above configuration file is now complete. The following describes how to detect whether the behavior of calling the Vfs_write function to write the target file in the above step 101 is a potential malicious behavior of the second-stage release attack: In this embodiment, see Figure 2 As shown, the above detection of whether the behavior of calling the Vfs_write function to write the target file is a potential malicious behavior of the second-stage release attack may include the following steps in the specific implementation: Step 201 , detecting whether the file format of the target file matches the specified file format; if yes, executing step 202 ; if no, executing step 203 .

[0051] In this embodiment, the specified file format may include, for example, an Executable and Linkable Format (ELF) format and / or a Dalvik Executable File (DEX) format.

[0052] In this embodiment, as an embodiment, detecting whether the file format of the target file matches the specified file format can be specifically implemented as follows: first, obtaining format feature data indicating the file format of the target file from the target file; then, matching the obtained format feature data indicating the file format of the target file with pre-configured format feature data indicating the specified file format to detect whether the file format of the target file matches the specified file format.

[0053] In this embodiment, for a file, usually the first 4 bytes of data in the file header are used to indicate the file format of the file; based on this, the above-mentioned obtaining of format feature data for indicating the file format of the target file from the target file may include, for example, reading the first 4 bytes of data in the target file header as format feature data for indicating the file format of the target file.

[0054] Based on the above description, in this embodiment, assuming that the specified file format includes ELF format and DEX format, the format feature data used to indicate the ELF format may be, for example, "\x7fELF" or "7f454c46"; the format feature data used to indicate the DEX format may be, for example, "dex\n".

[0055] Step 202, determining that the behavior of calling the Vfs_write function to write the target file is a potential second-stage release attack malicious behavior.

[0056] Step 203, determining that the behavior of calling the Vfs_write function to write the target file is not a potential malicious behavior of the second-stage release attack.

[0057] This completes the description of how to detect whether the behavior of calling the Vfs_write function to write a target file is a potential malicious behavior of a two-stage release attack.

[0058] The following describes how to output a prompt when the behavior of calling the Vfs_write function to write a target file is detected as a potential malicious behavior of a second-stage release attack: In this embodiment, as an embodiment, when it is detected that the behavior of calling the Vfs_write function to write the target file is a potential two-stage release attack malicious behavior, a prompt that the behavior of calling the Vfs_write function to write the target file is a potential two-stage release attack malicious behavior and the tracking information of the target file are output, so that relevant technical personnel can perform corresponding processing based on the output prompt and tracking information.

[0059] In this embodiment, the tracking information includes at least: the file path parameter of the target file in the kernel, and the context of calling the Vfs_write function to write the target file.

[0060] The file path parameter of the target file in the kernel refers to the path parameter of the path to which the target file is written in the kernel.

[0061] The context of calling the Vfs_write function to write the target file refers to the function call chain information of the Vfs_write function. The function call chain information of the Vfs_write function may include the calling relationship (such as the calling order) of the upper-level function of the Vfs_write function and the lower-level function of the Vfs_write function; the lower-level function of the Vfs_write function here can be considered to be the function that continues to be called after the operation performed by calling the Vfs_write function is completed.

[0062] The specific implementation process of the above-mentioned intelligent terminal kernel malicious behavior real-time detection method is described below through a specific embodiment: As an example, see Figure 3 As shown, the method comprises the following steps: Step 301: load a function detection program into the kernel through BPF, and run a detection handler in the function detection program associated with at least one event that needs to be traced and is specified in a configuration file in the kernel.

[0063] Step 302: within a set time period, for a detection processing program associated with each event, when the detection processing program detects that any function corresponding to the event specified in the configuration file is called, a call record of the function is obtained.

[0064] In this embodiment, the set time period can be understood as a time period for collecting a training data set, which can be set based on actual application requirements and is not specifically limited in this embodiment.

[0065] Step 303: Generate a feature data set based on the obtained call records of the functions corresponding to each event.

[0066] Step 304: A malware detection model is obtained by using supervised machine learning training based on the feature data set; wherein the malware detection model is used to monitor whether at least one application has malicious behavior.

[0067] In this embodiment, as an embodiment, in the actual application stage, if any application is detected to have malicious behavior through the malware detection model, an alarm indication of the malicious behavior of the application is output to prompt relevant technical personnel to take corresponding measures in time to avoid affecting the normal operation of the smart terminal.

[0068] At this point, the description of the method provided in the embodiment of the present application is completed. The following is a description of the device provided in the embodiment of the present application: See also Figure 4 , Figure 4 A schematic diagram of the structure of a real-time detection device for malicious behavior of the kernel of an intelligent terminal provided in an embodiment of the present application. The device is applied to an electronic device, the kernel of which loads a function detection program, and the kernel also runs a detection processing program associated with at least one event specified in a configuration file to be tracked. Figure 4 As shown, the device 400 includes a detection module 401, a generation module 402 and a training module 403; The detection module 401 is used for obtaining a call record of the virtual file system write function when the virtual file system write function is called if a detection handler associated with the kernel function call event is running in the kernel, and detecting the target file written by calling the virtual file system write function through the detection handler to detect whether the behavior of calling the virtual file system write function to write the target file is a potential second-stage release attack malicious behavior, and if so, outputting a prompt; The generating module 402 is used to generate a feature data set based on the call records obtained by the detection processing program associated with each event when the function corresponding to each event is called; the call records at least include: the function call frequency and the call sequence; the call sequence at least includes: the caller of the function and other operations associated with the operation performed after the function is called; The training module 403 is used to apply supervised machine learning based on the feature data set to train a malware detection model; the malware detection model is used to monitor whether at least one application has malicious behavior.

[0069] As an embodiment, detecting whether the behavior of calling a virtual file system write function to write a target file is a potential two-stage release attack malicious behavior includes: Detect whether the file format of the target file matches the specified file format; wherein the specified file format includes ELF format and / or DEX format; If yes, it is determined that the behavior of calling the virtual file system write function to write the target file is a potential two-stage release attack malicious behavior; if no, it is determined that the behavior of calling the virtual file system write function to write the target file is not a potential two-stage release attack malicious behavior.

[0070] As an embodiment, the at least one event that needs to be tracked includes at least one of the following: Framework layer application program interface API method call events, Native layer library function call events, direct system call events, kernel function call events.

[0071] As an example, the output prompt includes: Outputting the behavior of calling the virtual file system write function to write the target file is a hint of potential malicious behavior of the second-stage release attack and the tracking information of the target file; The tracking information at least includes: the file path parameter of the target file in the kernel, and the context of calling the virtual file system write function to write the target file.

[0072] As an embodiment, the function corresponding to each event also includes at least one of the following: Kernel memory allocation function, kernel memory release function, virtual file system open function, virtual file system read function, process creation function, process exit function, process cloning function, Internet control socket receive function, transmission control protocol TCP message send function, TCP message receive function.

[0073] As an embodiment, the function detection program is loaded into the kernel through BPF or eBPF.

[0074] So far, completed Figure 4 Structural description of the device shown.

[0075] The implementation process of the functions and effects of each module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, which will not be repeated here.

[0076] For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can refer to the partial description of the method embodiment. The device embodiment described above is only schematic, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present application scheme. A person of ordinary skill in the art can understand and implement it without paying creative labor.

[0077] See also Figure 5, is a schematic diagram of the hardware structure of an electronic device provided by an exemplary embodiment of the present application. The electronic device may include a processor 501, a communication interface 502, a computer-readable storage medium 503 and a communication bus 504. The processor 501, the communication interface 502 and the computer-readable storage medium 503 communicate with each other through the communication bus 504. Among them, computer program instructions are stored on the computer-readable storage medium 503; the processor 501 can execute the steps of the method described in the above embodiment by executing the computer program instructions stored on the computer-readable storage medium 503. The electronic device may also include other hardware according to the actual function of the electronic device, which will not be described in detail.

[0078] Correspondingly, an embodiment of the present application further provides a computer-readable storage medium, on which a number of computer program instructions are stored. When the computer program instructions are executed by a processor, the method disclosed in the above example of the present application can be implemented.

[0079] Exemplarily, the computer-readable storage medium may be any electronic, magnetic, optical or other physical storage device that may contain or store information, such as executable instructions, data, etc. For example, the computer-readable storage medium may be: RAM (Radom Access Memory), volatile memory, non-volatile memory, flash memory, storage drive (such as hard disk drive), solid state drive, any type of storage disk (such as optical disk, DVD, etc.), or similar storage medium, or a combination thereof. The processor and memory may be supplemented by or incorporated into a dedicated logic circuit.

[0080] The above are only preferred embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A real-time detection method for malicious behavior of the kernel of an intelligent terminal, characterized in that: The method is applied to an electronic device, wherein a kernel in the electronic device loads a function detection program, and the kernel also runs a detection processing program associated with at least one event specified in a configuration file to be tracked; the method comprises: If a detection processing program associated with a kernel function call event is running in the kernel, when a virtual file system write function is called, a call record of the virtual file system write function is obtained, and a target file written by calling the virtual file system write function is detected by the detection processing program to detect whether the behavior of calling the virtual file system write function to write the target file is a potential second-stage release attack malicious behavior, and if so, a prompt is output; Generate a feature data set based on the call records obtained by the detection processing program associated with each event when the function corresponding to each event is called; the call records at least include: the function call frequency and the call sequence; the call sequence at least includes: the caller of the function and other operations associated with the operation performed after the function is called; Based on the feature data set, supervised machine learning is used to train a malware detection model; the malware detection model is used to monitor whether at least one application has malicious behavior.

2. The method according to claim 1, characterized in that Detecting whether the behavior of calling the virtual file system write function to write the target file is a potential two-stage release attack malicious behavior includes: Detecting whether the file format of the target file matches the specified file format; wherein the specified file format includes ELF format and / or DEX format; If yes, it is determined that the behavior of calling the virtual file system write function to write the target file is a potential two-stage release attack malicious behavior; if no, it is determined that the behavior of calling the virtual file system write function to write the target file is not a potential two-stage release attack malicious behavior.

3. The method according to claim 1, characterized in that: The at least one event that needs to be tracked includes at least one of the following: Framework layer application program interface API method call events, Native layer library function call events, direct system call events, kernel function call events.

4. The method according to claim 1, characterized in that: The output prompts include: Outputting a prompt that the behavior of calling the virtual file system write function to write the target file is a potential second-stage release attack malicious behavior and tracking information of the target file; The tracking information includes at least: the file path parameter of the target file in the kernel, and the context of calling the virtual file system write function to write the target file.

5. The method according to claim 1, characterized in that The function corresponding to each event also includes at least one of the following: Kernel memory allocation function, kernel memory release function, virtual file system open function, virtual file system read function, process creation function, process exit function, process cloning function, Internet control socket receive function, transmission control protocol TCP message send function, TCP message receive function.

6. The method according to claim 1, characterized in that The function detection program is loaded into the kernel through the Berkeley Packet Filter BPF or the extended BPF.

7. A real-time detection device for malicious behavior of the kernel of an intelligent terminal, characterized in that: The device is applied to an electronic device, wherein a function detection program is loaded into a kernel in the electronic device, and the kernel also runs a detection processing program associated with at least one event specified in a configuration file and requiring tracing; The device includes: a detection module, configured to obtain a call record of a virtual file system write function when a virtual file system write function is called if a detection handler associated with a kernel function call event is running in the kernel, and detect a target file written by calling the virtual file system write function through the detection handler to detect whether the behavior of calling the virtual file system write function to write the target file is a potential malicious behavior of a second-stage release attack, and if so, output a prompt; A generating module, for generating a feature data set based on a call record obtained by a detection processing program associated with each event when a function corresponding to each event is called; the call record includes at least: a function call frequency and a call sequence; the call sequence includes at least: a function caller and other operations associated with the operation performed after the function is called; A training module is used to apply supervised machine learning based on the feature data set to train a malware detection model; the malware detection model is used to monitor whether at least one application has malicious behavior.

8. The device according to claim 7, characterized in that Detecting whether the behavior of calling the virtual file system write function to write the target file is a potential two-stage release attack malicious behavior includes: detecting whether the file format of the target file matches the specified file format; wherein the specified file format includes the ELF format and / or the DEX format; if yes, determining that the behavior of calling the virtual file system write function to write the target file is a potential two-stage release attack malicious behavior; if not, determining that the behavior of calling the virtual file system write function to write the target file is not a potential two-stage release attack malicious behavior; and / or, The at least one event to be tracked includes at least one of the following: a framework layer application program interface API method call event, a Native layer library function call event, a direct system call event, a kernel function call event; and / or, The output prompt includes: outputting a prompt that the behavior of calling the virtual file system write function to write the target file is a potential two-stage release attack malicious behavior and tracking information of the target file; the tracking information at least includes: the file path parameter of the target file in the kernel, the context of calling the virtual file system write function to write the target file; and / or, The function corresponding to each event also includes at least one of the following: kernel memory allocation function, kernel memory release function, virtual file system open function, virtual file system write function, virtual file system read function, process creation function, process exit function, process cloning function, Internet control socket receive function, transmission control protocol TCP message send function, TCP message receive function; and / or, The function detection program is loaded into the kernel through the Berkeley Packet Filter BPF or the extended BPF.

9. An electronic device, characterized in that: The electronic device includes: Processor; and A computer-readable storage medium, wherein computer program instructions are stored in the computer-readable storage medium, and when the computer program instructions are executed by the processor, the processor executes the steps in any one of the methods of claims 1 to 6.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, which, when executed by a processor, enable the processor to perform the steps of any one of the methods of claims 1 to 6.

Images