Rotkit threat detection method and system based on behavior outlier and statistical characteristics

Abstract

The invention relates to a rootkit threat detection method and system based on behavior outliers and statistical characteristics. Clustering to obtain a system driver division library by identifying the loaded system driver; on a system to be detected, stack tracking of system calling of a system API and sub-calling of the stack tracking are obtained, and the position of a kernel module on a disk is searched by using memory addresses of the calling and the sub-calling. A path export table is obtained through a detected kernel module, and whether an abnormal RootKit module exists in a system is judged by adopting a clustering time-phase and time-phase distance algorithm and a method of querying a drive division library. The system comprises a system drive recognizer, a drive partition library builder, a tested system data collector and a Rootkit detector, the Rootkit threat is effectively judged, and the problem of Rootkit detection under the conditions of unknown malicious codes and self-hiding behaviors is solved.

Description

Technical Field

[0001] The present invention relates to a monitoring and security software detection method in the field of network security, and in particular to a rootkit threat detection method and system based on behavioral outliers and statistical features. Background Art

[0002] Currently, in order to obtain and trace the call stack of the system API, ETW can be used on Windows and the ftrace mechanism can be used on Linux:

[0003] The currently used ETW (full name EventTracing for Windows) is a high-speed tracing facility in the Windows operating system. ETW provides a mechanism for tracing and recording events triggered by user-mode applications and kernel-mode drivers. ETW can be used for system and application diagnosis, troubleshooting, and performance monitoring.

[0004] The currently used ftrace (full name: Function Tracer) is one of the Linux kernel performance debugging tools. It can be used to track the calling of kernel functions, help developers and designers understand the kernel's current behavior, and can be used to debug or analyze delays and performance issues outside of user space.

[0005] The stack traceback currently used is under the x86_64 architecture, where ESP, EBP, RSP, and RBP are stack pointer registers. ESP and RSP are both stack pointer registers, used to point to the top of the stack; EBP and RBP are both base address registers, used to point to the bottom of the current stack frame. During a function call, EBP / RBP is used to save the base address of the previous function, while ESP / RSP is used to save the top of the stack of the current function. Stack traceback can be achieved through EBP / RBP and ESP / RSP.

[0006] Currently, in order to obtain detailed sub-calls of a specific function, timer sampling or Intel's PT technology can be used:

[0007] Intel High Precision Event Timer (HPET) is a hardware timer used in personal computers. It was developed jointly by Intel and Microsoft and has been included in PC chipsets since 2005. It is a high-precision timer that can provide more accurate timestamps for computer time synchronization, performance analysis, etc.

[0008] Intel PT (Processor Trace) is a hardware-level tracing mechanism provided by Intel CPU, which can record the instruction flow executed by the CPU, including branch, function call, return and other information, for debugging and performance analysis. This mechanism can record the instruction flow executed by the CPU, including branch, function call, return and other information.

[0009] However, the above existing technologies have certain difficulties in detecting Rootkits, because Rootkits are special malware whose function is to hide itself and designated files, processes, network links and other information on the installation target. It is more common to see that Rootkits are generally used in combination with other malicious programs such as Trojans and backdoors. Rootkits are programs that hide system objects (including files, processes, drivers, registry entries, open ports and network connections, etc.) by modifying the operating system kernel and loading drivers to change the instruction execution path, so as to evade or circumvent standard system mechanisms.

[0010] They can hide themselves so that their behavior and presence cannot be detected by standard system monitoring and security software. Rootkits can hide system objects by modifying the operating system kernel or changing the instruction execution path to escape or circumvent program discovery by standard system mechanisms.

[0011] Rootkit detection is difficult because they can hide themselves so that their behavior and existence cannot be detected by standard system monitoring and security software. Rootkits can hide system objects by modifying the operating system kernel or changing the instruction execution path to escape or circumvent program discovery by standard system mechanisms. At the same time, APT attacks are highly customized and targeted, and attackers often use some new and difficult-to-defend techniques to evade detection. APT attacks often use rootkits to hide themselves, which makes it difficult to detect APT attacks.

[0012] In view of the above-mentioned defects in the existing technology, the inventor has finally created the present invention which is of practical value after continuous research, design, repeated trials and improvements. Summary of the invention

[0013] The main purpose of the present invention is to overcome the defects of the existing technology and provide a new rootkit threat detection method and system based on behavioral outliers and statistical characteristics, so as to effectively solve the rootkit detection problem of unknown malicious code and self-hiding behavior, which is very suitable for practical use.

[0014] The concept of the present invention is that: in Windows and Linux systems, rootkits are usually implemented using drivers, including modifying existing system built-in drivers and registering new drivers with easily confusing names and file system paths. Its main goal is to hide specific system objects such as files, processes, drivers, registry entries, open ports and network connections. Its common implementation measure is to modify the return data of the system API when the system API is accessed.

[0015] The invention proposes a rootkit threat detection method and system based on behavioral outliers and statistical features. When the system API is called, the call stack of the system API and the paths and exported function names of the loaded driver libraries involved in the system API processing are obtained, and these paths and function name strings are used to perform clustering similarity judgments, thereby obtaining classifications (such as graphics card drivers, network drivers, PCI devices, etc.), judging whether the behaviors are relatively consistent among drivers of the same type, and thus finding abnormal outlier behaviors.

[0016] The purpose of the present invention and the technical problem solved are achieved by adopting the following technical solutions. According to a rootkit threat detection method based on behavioral outliers and statistical features proposed by the present invention, the rootkit is detected using behavioral outliers and statistical features. The main steps of the method include: step 1: system driver identification and clustering division stage and step 2: rootkit outlier detection stage. In the system driver identification and clustering division stage, a large number of normal operating systems are extracted to obtain the driver division and execution mode of the normal operating system to form a driver division library, and step 2: rootkit outlier detection stage is performed on the operating system to be detected to obtain the driver division of the operating system to be detected. By comparing and distinguishing with the driver division library, the abnormal outlier driver situation is obtained.

[0017] Furthermore, the step 1: system driver identification and clustering phase includes the following steps:

[0018] Step 1.1 Driver identification of the loaded system

[0019] The driver identification of the loaded system can be carried out in a variety of ways, mainly including: identifying the driver of the loaded system based on the API of the operating system; or identifying the driver of the loaded system by reading the relevant data structure of the system; or recording the instruction pointer of the relevant executing CPU of the system, i.e. IP / EIP / RIP, through timers and high-precision timers during interruption, checking according to the pointer and call stack, and performing comprehensive extraction and deduplication after obtaining the data;

[0020] Step 1.2 Extract the disk path where the driver is located

[0021] After obtaining the driver's memory address, check through the mapping data structure in the kernel:

[0022] On Windows, this is done through _DRIVER_OBJECT, where the DriverStart and DriverSize structures include the data structures that have been loaded into memory;

[0023] On Linux, the base address of the module is obtained through the core_layout and init_layout members in the struct module structure. The core_layout member points to the core code segment of the module, and the init_layout member points to the initialization code segment of the module. Both members are pointers of the struct vm_area_struct type. The base address of the module is obtained through the vm_start member in the vm_area_struct structure.

[0024] Preferably, by establishing a segment tree search data structure for the acquired data structure, the content is acquired according to the acquired memory address such as EIP, thereby accelerating the access efficiency;

[0025] Step 1.3 Driver function table extraction

[0026] Obtained by parsing the PE driver file and the ELF driver file on the disk respectively; or obtained by reading the driver function table loaded in the system;

[0027] In terms of file-based detection, after the disk path where the driver is located is extracted, the file content pointed to by the disk path where the driver is located is read and parsed according to the relevant data structures of ELF and PE files;

[0028] In terms of obtaining by reading the driver function table loaded in the system, in Windows system, it is obtained by parsing the PE file structure loaded in the memory, specifically, obtaining through IMAGE_EXPORT_DIRECTORY in the PE file to obtain its export table structure;

[0029] The function table of the relevant modules in the Linux system has been pre-loaded and is obtained by reading the syms and gpl_syms linked lists in struct module, which are laid out as struct kernel_symbol.

[0030] Step 1.4 Clustering to establish a driver partition library

[0031] Drivers with similar paths and function names are obtained by clustering and dividing widely collected data, and the behavior of driver classification is characterized by function call stacks and related functions called; driver classification includes: graphics card driver, network adapter driver and PCI device driver;

[0032] The data obtained previously are strings, which need to be represented and digitized through feature engineering and converted into TOKEN to facilitate clustering algorithms;

[0033] The normal path and export table are processed in the form of ASCII representation. The tokenization method with word and subword granularity is selected to segment the string into words to retain complete semantic information. According to the characteristics of the data, the subword granularity is used to segment the string into these meaningful sub-units, thereby balancing the size of the vocabulary and semantic information;

[0034] Related tokenization tools use typical tokenization tools, including regular expressions, NLTK, Spacy, Keras, and Gensim;

[0035] The raw data is represented by feature extraction, including word frequency, TF-IDF, one-hot encoding, word2vec, and BERT. The above methods convert tokens into numerical vectors and matrices to facilitate the subsequent application of clustering methods.

[0036] Next is feature-based clustering. Clustering is to classify similar data objects into one category and to classify dissimilar data objects into different categories. Clustering algorithms are used to find reasonable representation patterns in normal data sets, thereby screening clustering patterns and features. The selected clustering algorithms include: partition-based clustering algorithms, hierarchical-based clustering algorithms, density-based clustering algorithms, grid-based clustering algorithms, and model-based clustering algorithms.

[0037] By selecting a clustering algorithm, the files are divided into driver partition libraries according to the extracted paths and function export tables, thereby obtaining the classification information of the target driver files.

[0038] Furthermore, the operating system-based API identifies loaded system drivers: Windows uses the Windows API function EnumDeviceDrivers to enumerate loaded drivers. The function EnumDeviceDrivers returns an array of pointers to driver base addresses, which contains the base addresses of loaded drivers. These base addresses are used to retrieve information about the drivers, including names and paths. Linux refers to the lsmod system tool implementation, or obtains information about loaded modules through the / proc / modules file. The / proc / modules file contains the name, size, usage count and other detailed information about each loaded module.

[0039] Further, the identification of the loaded system driver by reading the relevant data structure of the system is performed on a Windows system by parsing the _LDR_DATA_TABLE_ENTRY structure in the kernel, the _LDR_DATA_TABLE_ENTRY structure is a structure used to represent a loaded module, and the _LDR_DATA_TABLE_ENTRY structure contains information about the loaded module, including the module name, base address, size and other detailed information; using the Windows API function ZwQuerySystemInformation to enumerate the loaded drivers, and using the _LDR_DATA_TABLE_ENTRY structure to retrieve information about the driver; on a Linux system, using the struct module data structure to obtain the status of the loaded driver; the struct module data structure is defined in<linux / module.h> The header file contains information about loaded modules, including the module name, module status, and module reference count.

[0040] Furthermore, the timer or high-precision timer records the status of the relevant instructions being executed by the system during an interrupt, sets a system interrupt or a high-precision timer interrupt, generates an interrupt on each core on the CPU at a fixed interval, obtains the instruction pointer IP / EIP / RIP of the current process in the interrupt handling function, and converts the address of the instruction pointed to by the instruction pointer into an actual physical address through the relevant kernel data structure in the kernel state, obtains the kernel memory mapping of the physical address, and traces the stack through the ESP, EBP / RSP, and RBP registers. For each return address item of the stack, it is identified as system memory or user memory through the system mechanism, and the relationship between the memory address and the disk space is identified through the relevant load mapping data structure in the system kernel, and the module name, size and offset information of these kernel state call stacks are recorded.

[0041] Furthermore, the partition-based clustering algorithm: This algorithm requires the number of clusters to be specified in advance, and then optimizes the objective function through iteration so that the data objects in the same cluster are as similar as possible, and the data objects in different clusters are different.

[0042] Furthermore, the hierarchical clustering algorithm does not need to specify the number of clusters, but rather constructs a hierarchical structure to obtain clustering results at different levels. Hierarchical clustering is divided into two types: agglomerative and divisive.

[0043] Agglomerative clustering is a bottom-up process, that is, starting with each data object as a cluster, and gradually merging similar clusters until a certain termination condition is reached;

[0044] Divisive clustering is a top-down process, that is, starting with the entire data set as a cluster, gradually dividing dissimilar clusters until a certain termination condition is reached, including the AGNES algorithm and the DIANA algorithm.

[0045] Furthermore, the density-based clustering algorithm is clustered according to the density distribution of data objects in space, that is, high-density and continuous areas are divided into a cluster, and low-density or sparse areas are divided into noise or outliers. The algorithm can find clusters of any shape and is robust to noise and outliers; including the DBSCAN algorithm and its improved versions: OPTICS and HDBSCAN.

[0046] Furthermore, the grid-based clustering algorithm divides the data space into a finite number of cells or grids, and performs statistics and analysis on each grid to obtain clustering results, including the STING algorithm and the CLIQUE algorithm.

[0047] Furthermore, the model-based clustering algorithm: This type of algorithm assumes that the data objects obey a certain probabilistic model, and performs clustering according to the model parameters to provide an explanation of the data structure and distribution, and can discover clusters of complex shapes.

[0048] Furthermore, the step 2: rootkit outlier detection phase is to register the stack trace of the system call of the concerned system API on the system to be detected, and when the call of the system API is obtained, obtain the sub-call of the API call, and use the memory address of the sub-call of the collected API call to find the corresponding kernel module and the location of the kernel module on the disk, obtain its path export table through these detected kernel modules, and use the distance algorithm when clustering is the same to query the driver partition library;

[0049] The module is determined to be an abnormal rootkit module in the following two cases:

[0050] 1. The module is far away from the group in the driver partition library and is classified separately;

[0051] 2. The module can be found in the driver partition library, but the call stack related to the module is quite different from the normal module call stack;

[0052] Step 2: The detailed steps of the rootkit outlier detection phase include: Step 2.1 registering the stack trace of the system call to the concerned system API, Step 2.2 when obtaining the call of the system API, obtaining the sub-calls of the API call, Step 2.3: using the memory addresses of these sub-calls, finding the corresponding kernel module and the location of the kernel module on the disk, Step 2.4: through these detected kernel modules, obtaining their path export table, using the distance algorithm when clustering is the same, querying the driver partition library and Step 2.5 abnormal rootkit judgment phase.

[0053] Further, the step 2.1 registers the stack trace of the system call to the concerned system API. Rootkits usually hide specific system objects, including files, processes, drivers, registry entries, open ports and network connections. The hiding process adopts the modification and hijacking of the implementation of the relevant access API of the files, processes, drivers, registry entries, open ports and network connection objects.

[0054] The kernel-mode enumeration functions on Windows include the following, and the related calls and sub-calls of these functions may be modified and hijacked:

[0055] File enumeration function: Use the ZwQueryDirectoryFile function to query the file information in the specified directory, or use the ZwQueryInformationFile function to query the properties of the specified file;

[0056] Process enumeration function: Use the ZwQuerySystemInformation function to obtain information about all processes in the system, or use the ZwQueryInformationProcess function to obtain information about a specified process;

[0057] Driver enumeration function: Use ZwEnumerateDriverEntries to enumerate all drivers in the system, or use ZwQueryDriverEntryOrder to query the loading order of drivers.

[0058] Enumeration function for registry keys: Use the ZwEnumerateKey function to enumerate all subkeys under a specified key, or use the ZwEnumerateValueKey function to enumerate all values ​​under a specified key;

[0059] Enumeration function for open ports and network connections: Use ZwDeviceIoControlFile function to send IOCTL_TCP_QUERY_INFORMATION_EX control code to obtain information about all open ports and network connections in the TCP / IP protocol stack;

[0060] On Linux, the enumeration functions for files, processes, drivers, open ports, and network connections are as follows. The related calls and subcalls of the enumeration functions may be modified and hijacked:

[0061] Enumeration function for files: Use the functions defined in the file_operations structure in the kernel API to operate files, such as open, read, write, and readdir; or use the functions provided by the VFS, the virtual file system layer, to access files, such as vfs_read, vfs_write, and vfs_readdir.

[0062] Enumeration function for the process: Use the task_struct structure in the kernel API to represent the process, which contains various properties and states of the process; or use some macros and functions to traverse the process list, such as for_each_process, find_task_by_pid, etc.

[0063] For driver enumeration function: Use the module structure in the kernel API to represent the driver module, which contains the name, version, dependency and other information of the driver module. Or use macros and functions to traverse the driver module list, such as for_each_module and find_module;

[0064] Enumeration functions for open ports and network connections: Use the socket structure in the kernel API to represent network sockets. Said The socket structure contains the socket type, protocol, address and other information; or use macros and functions to traverse the socket list, such as for_each_netdev, sk_for_each;

[0065] In order to obtain the relevant calling functions and call chains of the system during API processing, ETW (Event Tracing for Windows) is used on Windows, and the ftrace mechanism is used on Linux:

[0066] ETW is a high-speed tracing facility in the Windows operating system. ETW provides a mechanism for tracing and recording events raised by user-mode applications and kernel-mode drivers. ETW is used for system and application diagnostics, troubleshooting, and performance monitoring.

[0067] Specifically, use ETW's NT Kernel Logger to obtain relevant access to kernel state for identification; kernel state related access includes: process, thread, img, proccntr, cswitch, dpc, isr, syscall, disk, file, diskinit, dispatcher, pf, hf, virtalloc, net, registry, alpc, splitio, driver, profile, fileiocompletion and fileio. For each item of interest, kernel state stack trace can be registered to obtain call stack information for detection; or use some event calls of Microsoft-Windows-Kernel-*, refer to relevant manuals and open source solutions;

[0068] On Linux, ftrace (Function Tracer) is used for stack tracing. Its core goal is similar to that of Windows. ftrace is one of the Linux kernel performance debugging tools. It is used to track the calling of kernel functions and help developers and designers understand the kernel's current behavior.

[0069] Specifically, for file access tracking: use the function_graph tracer in ftrace to track file system activities, including file creation, opening, reading, writing, and deletion. Use the function_graph type of tracing to start an ftrace session, capture ext4 file system events, and save the results to a trace file.

[0070] Access tracking of the process: Use the wakeup tracer in ftrace to track the activities of the process, including the creation and termination of the process, and the creation and termination of threads; use the `echo wakeup> / sys / kernel / debug / tracing / current_tracer` command to start an ftrace session, capture the events of the process, and save the results to the trace file;

[0071] Driver access tracking: Use the events directory in ftrace to track driver activities, including driver loading, unloading, device addition, and removal. Use the command `echo 1> / sys / kernel / debug / tracing / events / nvme` to start an ftrace session, capture nvme driver events, and save the results to a trace file.

[0072] Access tracking of open ports and network connections: Use the events directory in ftrace to track the activities of the TCP / IP protocol stack, including port monitoring, connection, and disconnection. Use the echo 1> / sys / kernel / debug / tracing / events / tcpip / enable command to start an ftrace session, capture TCP / IP protocol stack events, and save the results to a trace file.

[0073] Further, in step 2.2, when a system API call is obtained, a sub-call of the API call is obtained.

[0074] Preferably, when a relevant API is called, its sub-calls are obtained;

[0075] There are two ways to obtain the sub-calls of the API call when the system API call is obtained, including: using timer sampling and Intel's PT technology;

[0076] Intel High Precision Event Timer (HPET) is a high-precision timer that provides more accurate timestamps for computer time synchronization and performance analysis.

[0077] Intel PT, or Processor Trace, is a hardware-level tracing mechanism provided by Intel CPUs that can record the instruction stream executed by the CPU, including branches, function calls, and return information. The tracing mechanism records the instruction stream executed by the CPU, including branches, function calls, and return information. The steps required to use this technology include: initializing the configuration of Intel Processor Trace; defining a callback function to handle PT events, such as function entry, function exit, and branch events; allocating memory to store PT data; creating a PT decoder to identify and obtain information given by the CPU; enabling the Intel Processor Trace function and waiting for the corresponding function call;

[0078] In terms of function call identification, a series of variables are defined, which are set when the retrieval function of the above-mentioned related API call enters, and are unset when the retrieval function of the API call exits, so as to track only the call stack of the related API call;

[0079] For development related to Intel Process Trace, please refer to Intel's documentation manuals and open source tool implementations.

[0080] Furthermore, the method of step 2.3: using the memory addresses of these subcalls to find the corresponding kernel modules and the location of the kernel modules on the disk is the same as the method of extracting the disk path where the driver is located in step 1.2.

[0081] Furthermore, the step 2.4 is to obtain the path export table of the kernel modules detected, query the driver partition library using the same distance algorithm as in clustering, and query the driver partition library for the kernel modules involved in each call stack. The method used is the same as the method described in step 1.4 for clustering to establish the driver partition library.

[0082] Furthermore, in the abnormal rootkit determination stage of step 2.5, the module is determined to be an abnormal rootkit module in the following two cases:

[0083] 1. The module is far away from the group in the driver partition library and is classified separately;

[0084] 2. The module can be found in the driver partition library, but the call stack related to the module is quite different from the normal module call stack;

[0085] Specifically, the way of determining abnormality in clustering is closely related to the clustering algorithm used. In the K-means algorithm, it is done by "identifying the minority", that is, the cluster with the least number of samples is regarded as the abnormal cluster, and then the points belonging to the cluster are marked as abnormal points.

[0086] In the DBSCAN algorithm, core points, boundary points, and noise points are divided, and noise points are identified as outliers that are classified separately: core points refer to points that contain enough neighboring points within a specified radius, and core points are representatives of high-density areas; boundary points refer to points that are within the neighborhood of core points but are not core points, and boundary points are bridges connecting different clusters; noise points refer to points that are neither core points nor boundary points, and are low-density areas or isolated points, and are usually considered outliers;

[0087] After finding the classification through the clustering algorithm, the obtained call stack is compared with all typical call stacks in the class one by one to determine the similarity; the comparison method is normalized and the common text similarity calculation method is used to calculate the distance or similarity between texts using the numerical vector of the text. The methods used are cosine similarity, Euclidean distance, Jaccard similarity and simhash method;

[0088] When it is found that the classification can be found, but the similarity of all function calls is low, that is, there is a large difference between the similarity of the found call stack and the normal module call stack, the module is determined to be an abnormal module.

[0089] The purpose of the present invention and the technical problem solved by the present invention are also achieved by the following technical solutions. According to a rootkit threat detection system based on behavioral outliers and statistical features proposed by the present invention, it includes a system driver identifier, a driver partition library builder, a driver partition library, a tested system data collector and a RootKit detector. The data of the system driver identifier is provided to the driver partition library builder for establishing the driver partition library. The tested system data collector provides the data to the RootKit detector. The RootKit detector uses the driver partition library for detection and outputs the result, wherein:

[0090] ——System driver identifier, used for driver identification of loaded system, extraction of disk path where driver is located, and extraction of driver function table; including: identification of driver of loaded system based on API of operating system, identification of driver of loaded system by reading relevant data structure of system, detection of system driver by timed sampling, extraction of disk path where driver is located, and extraction of driver function table; its steps are as described in method step 1.1: identification of driver of loaded system, method step 1.2: extraction of disk path where driver is located, and method step 1.3: extraction of driver function table;

[0091] ——Driver partition library builder, used to build the driver partition library required by the system, which is divided into feature extraction representation, hierarchical clusterer, agglomerative clusterer, and divisive clusterer. Its steps are as described in step 1.4 of the method for clustering and building a driver partition library;

[0092] ——The driver partition library is created by the driver partition library builder, and its form is a software database or disk file, which is used to store the clustering results created by the driver partition library builder.

[0093] ——The data collector of the system under test is used to collect data of the operating system to be tested, including: ETW (EventTracing for Windows) system call tracer, Ftrace system call tracer, timer sampling system call sub-call collector, Intel Processor Trace system call sub-call collector; its steps are as shown in method step 2.1 registering the stack trace of the system call of the concerned system API, method step 2.2 when obtaining the call of the system API, obtaining the sub-call of the API call, 5.1. method step 2.3 using the memory addresses of these sub-calls to find the corresponding kernel module and the location of the kernel module on the disk;

[0094] ——The RootKit detector is used to detect RootKit, and uses the driver partition library to detect and collect data, including: a feature extraction indicator, a clustering distance calculator, and an abnormal rootkit determiner; complete method step 2.4 through these detected kernel modules, obtain their path export table, use the distance algorithm when clustering is the same, query the driver partition library method step 2.5 defined in the abnormal rootkit determination stage; first, the system driver identifier collects data from the normal system, and then the system driver identifier establishes the driver partition library required by the system, and then the tested system data collector collects data from the tested system, and finally the RootKit detector is responsible for completing method step 2.4 through the detected kernel module, obtain its path export table, use the distance algorithm when clustering is the same, query the driver partition library and the work defined in method step 2.5 abnormal rootkit determination stage.

[0095] Further, it includes at least one memory and at least one processor for detecting rootkit threats based on behavioral outliers and statistical features;

[0096] The at least one memory is used to store a machine-readable program;

[0097] The at least one processor is used to call a machine-readable program to execute any abnormal rootkit detection method.

[0098] Furthermore, the invention also includes a computer-readable medium on which computer instructions are stored. When the computer instructions are executed by a processor, the processor is caused to execute any abnormal rootkit detection method.

[0099] Furthermore, the device also includes a storage medium, on which a software program code for realizing any function is stored, and enables a computer or a CPU or an MPU to read and execute the program code stored in the storage medium.

[0100] Furthermore, storage media for providing program codes include floppy disks, hard disks, magneto-optical disks, optical disks, magnetic tapes, non-volatile memory cards and ROMs; program codes can also be downloaded from a server computer via a communication network; and an operating system operating on a computer can also perform part or all of the actual operations through instructions based on the program codes, thereby realizing the functions in any claim.

[0101] Furthermore, the program code read out from the storage medium is written into a memory provided in an expansion board inserted into the computer or into a memory provided in an expansion module connected to the computer, and then based on the instructions of the program code, a CPU installed on the expansion board or expansion module is caused to perform part or all of the actual operations, thereby realizing the functions in any of the above claims.

[0102] Compared with the prior art, the present invention has obvious advantages and beneficial effects. It has at least the following advantages:

[0103] The present invention uses a variety of behavioral outliers and statistical features to detect rootkits, thereby effectively solving the problem of detecting rootkits in the case of unknown malicious codes and self-hiding behaviors.

[0104] The present invention adopts multiple methods to obtain drivers, such as identifying the drivers of the loaded system based on the API of the operating system, identifying the drivers of the loaded system by reading the relevant data structure of the system, and detecting the drivers of the system by timed sampling. It can effectively obtain the drivers in the normal system and lay the foundation for effective characterization of features.

[0105] The present invention uses hierarchical clusterers, agglomerative clusterers, and divisive clusterers to cluster and mine normal features, and through extensive use of clustering algorithms, finds a reasonable representation mode for the normal data set, thereby effectively screening clustering patterns and features. Thus, the appropriate clustering pattern and algorithm for the scenario is found to improve the detection capability of Rootkits.

[0106] Aiming at the characteristics of Rootkit hiding itself, the present invention uses multiple means such as ETW (Event Tracing for Windows), ftrace, and system data structure analysis to extract multi-source data, thereby reducing the probability of Rootkit hiding itself without being discovered. Aiming at the characteristics of Rootkit modifying the operating system kernel or changing the instruction execution path, the present invention adopts methods such as obtaining sub-calls of system calls, using Intel high-precision timers, Intel Processor Tracer and other technologies, effectively extracting normal and abnormal rootkit hiding and distinguishing behaviors, thereby improving the detection effect of Rootkit.

[0107] To solve the problem of Rootkit detection in the case of unknown malicious code, we use behavioral outliers and statistical feature comparison to effectively discover highly customized and targeted Rootkits of APT attacks.

[0108] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the following specifically cites a preferred embodiment and describes it in detail with the accompanying drawings as follows. BRIEF DESCRIPTION OF THE DRAWINGS

[0109] Figure 1 It is a framework diagram of the system driver identification and clustering phase and the rootkit outlier detection phase of the present invention.

[0110] Figure 2 This is a flowchart of the present invention driving the partition library to establish

[0111] Figure 3 This is the functional block diagram of the RootKit threat detection and evidence collection system of the present invention

[0112] Figure 4 This is the functional block diagram of the system drive identifier of the present invention

[0113] Figure 5 This is the functional block diagram of the driver partition library builder of the present invention

[0114] Figure 6 This is the functional block diagram of the RootKit detector of the present invention

[0115] Figure 7 This is the functional block diagram of the data collector of the tested system of the present invention DETAILED DESCRIPTION

[0116] In order to further explain the technical means and effects adopted by the present invention to achieve the predetermined purpose of the invention, the rootkit threat detection method and system based on behavioral outliers and statistical features proposed by the present invention, its specific implementation method, method and effects are described in detail below in conjunction with the accompanying drawings and preferred embodiments.

[0117] A rootkit threat detection method based on behavioral outliers and statistical features is divided into a system driver identification and clustering phase and a rootkit outlier detection phase. Figure 1 shown.

[0118] In the system driver identification and clustering stage, a large number of normal operating systems are extracted to obtain the driver division and execution mode of the normal operating system, forming a driver division library, and then testing is performed on the operating system to be tested to obtain the driver division of the operating system to be tested. By comparing and distinguishing with the driver division library, the outlier abnormal driver situation is obtained. The steps of this method are as follows:

[0119] Step 1: System driver identification and clustering

[0120] In order to establish a driver partition library, the following actions are performed by running a large number of normal operating systems: (a) identifying the drivers that have been loaded into the system, (b) extracting the disk path where the driver is located, (c) extracting the driver's function table, and (d) using clustering and other methods to obtain the driver partition library.

[0121] Step 1.1: Driver identification of loaded system

[0122] In terms of driver identification of loaded systems, multiple methods are used. The multiple methods include: identifying the driver of the loaded system based on the API of the operating system; or identifying the driver of the loaded system by reading the relevant data structure of the system; or recording the instruction pointer (IP / EIP / RIP) of the relevant executing CPU of the system during interruption through timers and high-precision timers, and checking based on the pointer and call stack. After obtaining these data, comprehensive extraction and deduplication are performed. Among them:

[0123] Identify loaded system drivers based on the operating system API: Windows can use the Windows API function EnumDeviceDrivers to enumerate loaded drivers. The function EnumDeviceDrivers returns an array of pointers to driver base addresses, which contains the base addresses of loaded drivers. These base addresses can be used to retrieve information about the driver, such as its name and path. Linux can refer to system tools such as lsmod, or you can get information about loaded modules through the / proc / modules file. The / proc / modules file contains the name, size, usage count, and other details about each loaded module.

[0124] Identify the loaded system drivers by reading the system's related data structures: On Windows systems, one possible way is by parsing the _LDR_DATA_TABLE_ENTRY structure in the kernel. The LDR_DATA_TABLE_ENTRY structure is a structure used to represent loaded modules. The LDR_DATA_TABLE_ENTRY structure contains information about loaded modules, such as module name, base address, size, and other details. You can use the Windows API function ZwQuerySystemInformation to enumerate loaded drivers and use the _LDR_DATA_TABLE_ENTRY structure to retrieve information about the driver.

[0125] On Linux systems, you can use the struct module data structure to get the status of loaded drivers. This struct module data structure is defined in<linux / module.h> The header file contains information about loaded modules, such as module name, module status, module reference count, etc.

[0126] When using a timer or high-precision timer: When recording the system's related instructions being executed during an interrupt, set a system interrupt or high-precision timer interrupt, generate an interrupt on each core on the CPU at a fixed interval, obtain the current process's instruction pointer IP / EIP / RIP in the interrupt handling function, and convert the address of the instruction pointed to by the instruction pointer to the actual physical address through the relevant kernel data structure in kernel state, and obtain the kernel memory mapping of the physical address. And perform stack tracing through the ESP, EBP / RSP, and RBP registers. For each stack return address item, identify it as system memory or user memory through the system mechanism, and identify the relationship between the memory address and the disk space through the relevant load mapping data structure in the system kernel, and record the module name, size, offset and other information of these kernel state call stacks.

[0127] Step 1.2: Extract the disk path where the driver is located

[0128] After obtaining the memory address of the driver, it is checked through the mapping data structures in the kernel. On Windows, it is done through _DRIVER_OBJECT, where the DriverStart and DriverSize data structures include the data structures that have been loaded into memory.

[0129] On Linux, the base address of the module is obtained through the core_layout and init_layout members in the struct module structure. The core_layout member points to the core code segment of the module, and the init_layout member points to the initialization code segment of the module. Both members are pointers of the struct vm_area_struct type, and the base address of the module is obtained through the vm_start member in the vm_area_struct structure.

[0130] Preferably, by establishing a search data structure such as a segment tree for these data structures, the contents are obtained according to the obtained memory addresses such as EIP, thereby speeding up the access efficiency.

[0131] Step 1.3: Driver function table extraction

[0132] The data can be obtained by respectively parsing the PE driver file and the ELF driver file on the disk; or by reading the driver function table loaded in the system.

[0133] In terms of file-based detection, after the disk path where the driver is located is extracted, the file content pointed to by the disk path where the driver is located can be read and parsed according to the relevant data structures of ELF and PE files.

[0134] In terms of obtaining by reading the driver function table loaded in the system, in Windows system, it can be obtained by parsing the PE file structure loaded in the memory. Specifically, it can be obtained by obtaining through IMAGE_EXPORT_DIRECTORY in the PE file to obtain its export table structure.

[0135] The function table of the relevant modules in the Linux system has been pre-loaded and can be obtained by reading the syms and gpl_syms lists in struct module, which are laid out in struct kernel_symbol.

[0136] Step 1.4 Clustering to establish a driver partition library

[0137] The idea of ​​clustering to obtain the driver partition library is that drivers with similar paths and function names have similar behaviors. Therefore, by clustering the widely collected data, we can obtain driver classifications, such as graphics card drivers, network adapter drivers, PCI device drivers, etc., and characterize the driver classification behavior through the function call stack and the related functions called.

[0138] The data obtained previously are strings, which need to be represented and digitized through feature engineering and converted into TOKEN to facilitate clustering algorithms.

[0139] Since normal paths and export tables are processed in ASCII representable form, the tokenization method with word and subword granularity can be selected to segment the string by words to retain complete semantic information. At the same time, since the ' / ' and '\' in the path have typical classification meanings, and in engineering programming data, functions with similar purposes have the same prefix and are often divided by '_', therefore, according to the characteristics of the data, the subword granularity is used to segment the string according to these meaningful sub-units, thereby balancing the vocabulary size and semantic information.

[0140] Related tokenization tools can adopt typical tokenization tools such as regular expressions, NLTK, Spacy, Keras, Gensim, etc.

[0141] The representation of these raw data is obtained through feature extraction, such as word frequency, TF-IDF, one-hot encoding, word2vec, BERT, etc. These methods can convert tokens into numerical vectors and matrices to facilitate the subsequent application of clustering methods.

[0142] Next is clustering based on features. Clustering is an unsupervised learning technique that aims to classify similar data objects into one category and dissimilar data objects into different categories. By using clustering algorithms extensively, we can find reasonable representation patterns in the normal data set, thereby effectively screening clustering patterns and features. The selected clustering algorithms include:

[0143] Partition-based clustering algorithms: This type of algorithm requires the number of clusters to be specified in advance, and then iteratively optimizes the objective function to make the data objects in the same cluster as similar as possible and the data objects in different clusters as different as possible. (6) For example, the k-means algorithm and its variants, such as k-means++, bi-kmeans, kernel k-means, etc.

[0144] Hierarchical clustering algorithms: This type of algorithm does not require the number of clusters to be specified, but instead obtains clustering results at different levels by constructing a hierarchical structure. Hierarchical clustering can be divided into two types: agglomerative and divisive. Agglomerative clustering is a bottom-up process, that is, starting with each data object as a cluster, gradually merging similar clusters until a certain termination condition is reached. Divisive clustering is a top-down process, that is, starting with the entire data set as a cluster, gradually dividing dissimilar clusters until a certain termination condition is reached. For example, the AGNES algorithm and the DIANA algorithm.

[0145] Density-based clustering algorithms: These algorithms cluster data objects based on their density distribution in space, that is, they classify high-density and continuous areas into a cluster, and classify low-density or sparse areas as noise or outliers. These algorithms can find clusters of any shape and are robust to noise and outliers. For example, the DBSCAN algorithm and its improved versions, such as OPTICS, HDBSCAN, etc.

[0146] Grid-based clustering algorithms: These algorithms divide the data space into a finite number of cells or grids, and perform statistics and analysis on each grid to obtain clustering results. These algorithms have high efficiency and scalability, but are sensitive to grid division and grid size, and can only find clusters of regular shapes. For example, the STING algorithm and the CLIQUE algorithm.

[0147] Model-based clustering algorithms: These algorithms assume that data objects obey a certain probabilistic model and perform clustering based on model parameters. These algorithms can provide an explanation of the data structure and distribution and can discover complex clusters, but they are sensitive to model selection and parameter estimation and have high computational complexity. For example, Gaussian mixture models and spectral clustering.

[0148] By selecting a clustering algorithm, the files are divided into driver partition libraries according to the extracted paths and function export tables, thereby obtaining the classification information of the target driver files.

[0149] The process of system driver identification and clustering is as follows: Figure 2 shown.

[0150] Step 2: Rootkit Outlier Detection Phase

[0151] In the Rootkit outlier detection phase, the stack trace of the system call of the concerned system API is registered on the system to be detected, and when the system API call is obtained, the sub-call of the API call is obtained, and the memory address of the sub-call of the collected API call is used to find the corresponding kernel module and the location of the kernel module on the disk. Through these detected kernel modules, the path export table is obtained, and the distance algorithm when clustering is the same is used to query the driver partition library.

[0152] The module is determined to be an abnormal rootkit module in the following two cases:

[0153] 1. The module is far away from the group in the driver partition library and is classified separately.

[0154] 2. The module can be found in the driver partition library, but the call stack associated with the module is quite different from the normal module call stack.

[0155] A detailed description is given below.

[0156] Step 2.1 Register stack traces for system calls to the system API of interest

[0157] Rootkits usually hide specific system objects such as files, processes, drivers, registry entries, open ports, and network connections. The hiding process can be achieved by modifying and hijacking the implementation of the relevant access APIs that hide the specific system objects.

[0158] For example, the kernel-mode enumeration functions on Windows include the following, and the related calls and sub-calls of these functions may be modified and hijacked:

[0159] File enumeration function: You can use the ZwQueryDirectoryFile function to query the file information in the specified directory, or use the ZwQueryInformationFile function to query the properties of the specified file.

[0160] Process enumeration function: You can use the ZwQuerySystemInformation function to obtain information about all processes in the system, or use the ZwQueryInformationProcess function to obtain information about a specified process.

[0161] Driver enumeration function: You can use the ZwEnumerateDriverEntries function to enumerate the information of all drivers in the system, or use the ZwQueryDriverEntryOrder function to query the loading order of the driver.

[0162] Enumeration function for registry keys: You can use the ZwEnumerateKey function to enumerate all subkeys under the specified key, or use the ZwEnumerateValueKey function to enumerate all values ​​under the specified key.

[0163] Enumeration function for open ports and network connections: You can use the ZwDeviceIoControlFile function to send the IOCTL_TCP_QUERY_INFORMATION_EX control code to obtain information about all open ports and network connections in the TCP / IP protocol stack.

[0164] For example, on Linux, the enumeration functions for files, processes, drivers, open ports, and network connections are as follows. The related calls and subcalls of these enumeration functions may be modified and hijacked:

[0165] Enumeration function for files: You can use the functions defined in the file_operations structure in the kernel API to operate files, such as open, read, write, readdir, etc. You can also use the functions provided by the VFS (virtual file system) layer to access files, such as vfs_read, vfs_write, vfs_readdir, etc.

[0166] Enumeration function for processes: You can use the task_struct structure in the kernel API to represent a process, which contains various properties and states of the process. You can also use some macros and functions to traverse the process list, such as for_each_process, find_task_by_pid, etc.

[0167] For driver enumeration function: You can use the module structure in the kernel API to represent the driver module, which contains the name, version, dependency and other information of the driver module. You can also use some macros and functions to traverse the driver module list, such as for_each_module, find_module, etc.

[0168] Enumeration functions for open ports and network connections: You can use the socket structure in the kernel API to represent the network socket, which contains information such as the socket type, protocol, address, etc. You can also use some macros and functions to traverse the socket list, such as for_each_netdev, sk_for_each, etc.

[0169] In order to obtain the relevant calling functions and call chains of the system during API processing, ETW can be used on Windows, and the ftrace mechanism can be used on Linux:

[0170] ETW stands for Event Tracing for Windows, which is a high-speed tracing facility in the Windows operating system. ETW provides a mechanism for tracing and recording events triggered by user-mode applications and kernel-mode drivers. ETW can be used for system and application diagnosis, troubleshooting, and performance monitoring.

[0171] Specifically, ETW's NT Kernel Logger can be used to obtain and identify kernel-mode related accesses. The kernel-mode related accesses include: process, thread, img, proccntr, cswitch, dpc, isr, syscall, disk, file, diskinit, dispatcher, pf, hf, virtalloc, net, registry, alpc, splitio, driver, profile, fileiocompletion, fileio, etc. For each item of interest, kernel-mode stack trace can be registered to obtain call stack information for detection. Some event calls of Microsoft-Windows-Kernel-* can also be used. Please refer to relevant manuals and open source solutions.

[0172] process: indicates the creation or termination event of a process, including the process ID, name, parent process ID and other information.

[0173] thread: indicates the creation or termination event of a thread, including the thread ID, the process ID to which it belongs, priority, and other information.

[0174] img: indicates the loading or unloading event of an image (executable file or dynamic link library), including the image's name, size, base address, and other information.

[0175] proccntr: Represents the performance counter events of a process, including information such as the process ID, CPU time, and working set size.

[0176] cswitch: indicates a context switch event, including thread ID, priority, reason, and other information before and after the switch.

[0177] dpc: Indicates a delayed procedure call (DPC) event, which contains information such as the DPC type, routine address, and parameters.

[0178] isr: indicates an interrupt service routine (ISR) event, including the interrupt number, routine address, parameters, and other information.

[0179] syscall: indicates a system call event, including the system call number, parameters, return value and other information.

[0180] disk: indicates the start or end event of a disk IO operation, including IO type (read or write), size, offset, device ID, and other information.

[0181] file: indicates the start or end event of a file IO operation, including IO type (read or write), size, offset, file name and other information.

[0182] diskinit: indicates the disk initialization event, including the disk type, size, number of sectors, and other information.

[0183] dispatcher: represents the scheduler event, including the scheduler status, ready queue length and other information.

[0184] pf: Indicates a page fault event, including error type (hardware or software), error code, virtual address, and other information.

[0185] hf: indicates a hardware error event, including error type (machine check or bus check), error code, error source, and other information.

[0186] virtalloc: indicates a virtual memory allocation event, including allocation type (reserved or committed), allocation size, allocation address, and other information.

[0187] net: Indicates the start or end event of a network IO operation, including IO type (send or receive), size, protocol type (TCP or UDP), local address and port, remote address and port, etc.

[0188] registry: Indicates the start or end event of a registry operation, including operation type (create, open, read, write, or delete), key name, value name, and other information.

[0189] alpc: Indicates an Advanced Local Procedure Call (ALPC) event, including the ALPC type (send or receive), port name, message ID, and other information.

[0190] splitio: indicates the start or end event of a split IO operation, including IO type (read or write), size, offset, device ID, and other information.

[0191] driver: indicates the loading or unloading event of the driver, including the driver's name, version, base address and other information.

[0192] profile: indicates a performance analysis sampling event, including information such as the address and symbol of the sampling point.

[0193] fileiocompletion: indicates the completion event of a file IO operation, including IO status code, number of completed bytes, completion key value and other information.

[0194] On Linux, you can use ftrace for stack tracing, which has a similar core purpose to Windows. ftrace stands for Function Tracer, and is one of the Linux kernel performance debugging tools. It can be used to track kernel function calls and help developers and designers understand what is happening in the kernel.

[0195] For example, for file access tracking: you can use the function_graph tracer in ftrace to track file system activities, such as file creation, opening, reading, writing, and deletion. For example, you can use function_graph type tracing to start an ftrace session, capture events of the ext4 file system, and save the results to a trace file.

[0196] Access tracking of processes: You can use the wakeup tracer in ftrace to track the activities of processes, such as process creation, termination, thread creation, termination, etc. For example, you can use the `echo wakeup> / sys / kernel / debug / tracing / current_tracer` command to start an ftrace session, capture the events of the process, and save the results to a trace file.

[0197] Access tracking for drivers: You can use the events directory in ftrace to track driver activities, such as driver loading, unloading, device addition, removal, etc. For example, you can use the `echo 1> / sys / kernel / debug / tracing / events / nvme` command to start an ftrace session, capture events of the nvme driver, and save the results to a trace file.

[0198] Access tracking of open ports and network connections: You can use the events directory in ftrace to track the activities of the TCP / IP protocol stack, such as port listening, connection, disconnection, etc. For example, you can use the echo 1> / sys / kernel / debug / tracing / events / tcpip / enable command to start an ftrace session, capture events of the TCP / IP protocol stack, and save the results to a trace file.

[0199] Step 2.2 When the system API call is obtained, the sub-calls of the API call are obtained.

[0200] Preferably, when the relevant API is called, its sub-calls can be obtained. This is because the sub-calls of the API call may be modified or hijacked by the Rootkit, thereby hiding specific data.

[0201] There are two ways to obtain the sub-calls of the API call when the system API call is obtained, including: using timer sampling and Intel's PT technology.

[0202] Intel High Precision Event Timer (HPET) is a hardware timer used in personal computers. It was developed jointly by Intel and Microsoft and has been included in PC chipsets since 2005. It is a high-precision timer that can provide more accurate timestamps for computer time synchronization, performance analysis, etc.

[0203] For examples of using timers or Intel high-precision timers, see Related implementations of Trace Analyzerand Collector, or open source implementations using the perf tool.

[0204] Intel PT (Processor Trace) is a hardware-level tracing mechanism provided by Intel CPUs that can record the instruction stream executed by the CPU, including branching, function calls, returns, and other information. The tracing mechanism can record the instruction stream executed by the CPU, including branching, function calls, returns, and other information. Intel recently published a new article in the latest Intel PT. Detailed information about Intel Processor Trace is published in Chapter 11 of the Intel Architecture Instruction Set Extensions Programming Reference. Intel Processor Trace is a low-overhead execution tracing feature that will be supported on some processors in the future. It works by using dedicated hardware facilities to capture information about software execution on each hardware thread so that after execution is complete, software can process the captured trace data and reconstruct the exact program flow. Intel PT is low-overhead in terms of execution overhead and is sufficient to run properly in production builds of most applications.

[0205] The steps required to use this technology include: initializing the configuration of Intel Processor Trace; defining a callback function to handle PT events, such as function entry, function exit, branch events, etc.; allocating memory to store PT data; creating a PT decoder to identify and obtain the information given by the CPU; enabling the Intel Processor Trace function and waiting for the corresponding function call, etc.

[0206] In terms of function call identification, a series of variables may be defined, which are set when the retrieval function of the above-mentioned related API calls enters, and are unset when the retrieval function of the API calls exits, thereby only tracking the call stack of the related API calls.

[0207] For the development of Intel Process Trace, please refer to Intel's documentation manual and the implementation of some open source tools, which will not be repeated here.

[0208] Step 2.3: Use the memory addresses of these subcalls to find the corresponding kernel module and the location of the kernel module on disk

[0209] This solution is consistent with the method described in detail in step 1.2 for extracting the disk path where the driver is located, and will not be repeated here.

[0210] Step 2.4: Obtain the path export table through these detected kernel modules, use the distance algorithm when clustering is the same, and query the driver partition library

[0211] For each kernel module involved in the call stack, the driver partition library is queried. This is basically the same as the method described in step 1.4 clustering to establish the driver partition library, and will not be repeated here.

[0212] Step 2.5 Abnormal rootkit determination stage

[0213] The module is determined to be an abnormal rootkit module in the following two cases:

[0214] 1. The module is far away from the group in the driver partition library and is classified separately.

[0215] 2. The module can be found in the driver partition library, but the call stack associated with the module is quite different from the normal module call stack.

[0216] A detailed description is given below.

[0217] The way to determine the abnormality of clustering is closely related to the clustering algorithm used. For example, in the K-means algorithm, it can be done by "identifying the minority", that is, the cluster with the least number of samples is regarded as the abnormal cluster, and then the points belonging to the cluster are marked as abnormal points. In the DBSCAN algorithm, the core points, boundary points, and noise points can be divided, and the noise points can be identified as abnormal points in a separate category: the core point refers to the point that contains enough neighboring points within the specified radius. The core point is the representative of the high-density area; the boundary point refers to the point in the neighborhood of the core point but not the core point. The boundary point is the bridge connecting different clusters; the noise point refers to the point that is neither a core point nor a boundary point. The core point is a low-density area or an isolated point, which is usually considered an abnormal point.

[0218] After the clustering algorithm can find the classification, the obtained call stack is compared with all typical call stacks in the class one by one to determine the similarity. The comparison method is to use the common text similarity calculation method after normalization, and use the numerical vector of the text to calculate the distance or similarity between texts, such as cosine similarity, Euclidean distance, Jaccard similarity, simhash and other methods.

[0219] When it is found that classification can be found, but the similarity of all function calls is low (that is, there is a large difference in the similarity between the found call stack and the normal module call stack), the module is determined to be an abnormal module.

[0220] See also Figure 3 As shown, in a rootkit threat detection and evidence collection system, the system is divided into five parts: a system driver identifier, a driver partition library builder, a driver partition library, a tested system data collector, and a RootKit detector.

[0221] See also Figure 4 As shown, the system driver identifier is used to identify the driver of the loaded system, extract the disk path where the driver is located, and extract the driver function table. It includes: identifying the driver of the loaded system based on the API of the operating system, identifying the driver of the loaded system by reading the relevant data structure of the system, detecting the system driver by timing sampling, extracting the disk path where the driver is located, and extracting the driver function table. The steps are as described in method step 1.1: identifying the driver of the loaded system, method step 1.2: extracting the disk path where the driver is located, and method step 1.3: extracting the driver function table.

[0222] See also Figure 5 As shown, the driver partition library builder is used to build the driver partition library required by the system, which is divided into a feature extraction representative, a hierarchical clusterer, an agglomerative clusterer, and a divisive clusterer. Its steps are as described in method step 1.4 clustering to build a driver partition library.

[0223] The driver partition library is created by a driver partition library builder, and its form is a software database or a disk file, which is used to store the clustering results created by the driver partition library builder.

[0224] See also Figure 7As shown, the data collector of the system under test is used to collect data of the operating system to be tested, including: ETW (Event Tracing for Windows) system call tracer, Ftrace system call tracer, timer sampling system call sub-call collector, Intel Processor Trace system call sub-call collector. Its steps are as shown in method step 2.1 registering the stack trace of the system call of the concerned system API, method step 2.2 obtaining the sub-call of the API call when obtaining the call of the system API, and 5.1. method step 2.3 using the memory addresses of these sub-calls to find the corresponding kernel module and the location of the kernel module on the disk.

[0225] See also Figure 6 As shown, the RootKit detector is used to detect RootKit, and the driver partition library is used to detect and collect data, including: feature extraction representation, cluster distance calculator, and abnormal rootkit determiner. The method step 2.4 is completed through these detected kernel modules, and its path export table is obtained. The distance algorithm when clustering is the same is used to query the driver partition library method step 2.5 The work defined in the abnormal rootkit determination stage.

[0226] In a rootkit threat detection and forensics system, the system implements the steps required by the method, including step 1: collecting data from a normal system, step 2: establishing a driver partition library required by the system, step 3: collecting data from a tested system, and step 4: using the driver partition library to detect the collected data.

[0227] Step 1: Normal system data collection is performed by the system drive identifier, which completes the work defined in method step 1.1: driver identification of the loaded system, method step 1.2: disk path extraction of the driver, and method step 1.3: driver function table extraction.

[0228] Step 2: Establish the driver partition library required by the system, which is performed by the driver partition library builder. The driver partition library builder completes the work defined in the method step 1.4 of clustering to establish the driver partition library.

[0229] Step 3: The data collector of the system under test is responsible for collecting data for the system under test. The data collector of the system under test completes method 2.1 to register the stack trace of the system call of the system API of interest, method step 2.2 to obtain the sub-calls of the API call when the call of the system API is obtained, and 5.1. method step 2.3 to use the memory addresses of these sub-calls to find the corresponding kernel module and the work defined in the location of the kernel module on the disk.

[0230] Step 4: The driver partition library is used to detect and collect data, which is the responsibility of the RootKit detector. The RootKit detector completes the method step 2.4 through these detected kernel modules, obtains its path export table, uses the distance algorithm when clustering is the same, and queries the driver partition library method step 2.5 The work defined in the abnormal rootkit determination stage.

[0231] A rootkit threat detection system based on behavioral outliers and statistical features, further comprising: at least one storage area and at least one processor;

[0232] The at least one memory is used to store a machine-readable program;

[0233] The at least one processor is used to call the machine-readable program to execute an abnormal rootkit detection method in any embodiment of the present invention.

[0234] An embodiment of the present invention further provides a computer-readable medium, on which computer instructions are stored. When the computer instructions are executed by a processor, the processor executes an abnormal rootkit detection method in any embodiment of the present invention.

[0235] Specifically, a device equipped with a storage medium can be provided, on which software program codes that implement the functions of any of the above-mentioned embodiments are stored, and a computer (or CPU or MPU) of the system or device can be enabled to read and execute the program codes stored in the storage medium.

[0236] In this case, the program code itself read from the storage medium can realize the function of any one of the above-mentioned embodiments, and thus the program code and the storage medium storing the program code constitute a part of the present invention.

[0237] The storage medium embodiments for providing the program code include a floppy disk, a hard disk, a magneto-optical disk, an optical disk (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), a magnetic tape, a non-volatile memory card, and a ROM. Alternatively, the program code can be downloaded from a server computer by a communication network.

[0238] In addition, it should be clear that the functions of any of the above embodiments can be implemented not only by executing the program code read by the computer, but also by enabling an operating system operating on the computer to complete part or all of the actual operations based on instructions from the program code.

[0239] In addition, it can be understood that the program code read from the storage medium is written to a memory provided in an expansion board inserted into the computer or to a memory provided in an expansion module connected to the computer, and then based on the instructions of the program code, a CPU installed on the expansion board or expansion module is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above-mentioned embodiments.

[0240] The present invention proposes a rootkit threat detection and evidence collection method and system, which uses behavioral outliers and statistical features to detect rootkits, thereby effectively solving the problem of detecting rootkits in the case of unknown malicious codes and self-hiding behaviors.

[0241] The above description is only a preferred embodiment of the present invention and does not limit the present invention in any form. Although the present invention has been disclosed as a preferred embodiment as above, it is not used to limit the present invention. Any technician familiar with this profession can make some changes or modifications to equivalent embodiments of equivalent changes using the technical contents disclosed above without departing from the scope of the technical solution of the present invention. However, any simple modification, equivalent change and modification made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention still falls within the scope of the technical solution of the present invention.

Claims

1. A rootkit threat detection method based on behavioral outliers and statistical features, characterized by: The rootkit is detected by using behavioral outliers and statistical features. The main steps of the method include: step 1: system driver identification and clustering stage and step 2: rootkit outlier detection stage. In the system driver identification and clustering stage, a large number of normal operating systems are extracted to obtain the driver division and execution mode of the normal operating system to form a driver division library, and step 2: rootkit outlier detection stage is performed on the operating system to be detected to obtain the driver division of the operating system to be detected. By comparing and distinguishing with the driver division library, the outlier abnormal driver situation is obtained.

2. The rootkit threat detection method based on behavioral outliers and statistical features according to claim 1, characterized in that: The step 1: system driver identification and clustering phase includes the following steps: Step 1.1 Driver identification of the loaded system The driver identification of the loaded system can be carried out in a variety of ways, mainly including: identifying the driver of the loaded system based on the API of the operating system; or identifying the driver of the loaded system by reading the relevant data structure of the system; or recording the instruction pointer of the relevant executing CPU of the system, i.e. IP / EIP / RIP, through timers and high-precision timers during interruption, checking according to the pointer and call stack, and performing comprehensive extraction and deduplication after obtaining the data; Step 1.2 Extract the disk path where the driver is located After obtaining the driver's memory address, check through the mapping data structure in the kernel: On Windows, this is done through _DRIVER_OBJECT, where the DriverStart and DriverSize structures include the data structures that have been loaded into memory; On Linux, the base address of the module is obtained through the core_layout and init_layout members in the struct module structure. The core_layout member points to the core code segment of the module, and the init_layout member points to the initialization code segment of the module. Both members are pointers of the struct vm_area_struct type. The base address of the module is obtained through the vm_start member in the vm_area_struct structure. Preferably, by establishing a segment tree search data structure for the acquired data structure, the content is acquired according to the acquired memory address such as EIP, thereby accelerating the access efficiency; Step 1.3 Driver function table extraction Obtained by parsing the PE driver file and the ELF driver file on the disk respectively; or obtained by reading the driver function table loaded in the system; In terms of file-based detection, after the disk path where the driver is located is extracted, the file content pointed to by the disk path where the driver is located is read and parsed according to the relevant data structures of ELF and PE files; In terms of obtaining by reading the driver function table loaded in the system, in Windows system, it is obtained by parsing the PE file structure loaded in the memory, specifically, obtaining through IMAGE_EXPORT_DIRECTORY in the PE file to obtain its export table structure; The function table of the relevant modules in the Linux system has been pre-loaded and is obtained by reading the syms and gpl_syms linked lists in struct module, which are laid out as struct kernel_symbol. Step 1.4 Clustering to establish a driver partition library Drivers with similar paths and function names are obtained by clustering and dividing widely collected data, and the behavior of driver classification is characterized by function call stacks and related functions called; driver classification includes: graphics card driver, network adapter driver and PCI device driver; The data obtained previously are strings, which need to be represented and digitized through feature engineering and converted into TOKEN to facilitate clustering algorithms; The normal path and the export table are processed in the form of ASCII representation. The tokenization method with word and subword granularity is selected to segment the string by words to retain the complete semantic information. According to the characteristics of the data, the subword granularity is used to segment the string according to these meaningful sub-units, thereby balancing the vocabulary size and semantic information; Related tokenization tools use typical tokenization tools, including regular expressions, NLTK, Spacy, Keras, and Gensim; The raw data is represented by feature extraction, including word frequency, TF-IDF, one-hot encoding, word2vec, and BERT. The above methods convert tokens into numerical vectors and matrices to facilitate the subsequent application of clustering methods. Next is feature-based clustering. Clustering is to classify similar data objects into one category and to classify dissimilar data objects into different categories. Clustering algorithms are used to find reasonable representation patterns in normal data sets, thereby screening clustering patterns and features. The selected clustering algorithms include: partition-based clustering algorithms, hierarchical-based clustering algorithms, density-based clustering algorithms, grid-based clustering algorithms, and model-based clustering algorithms. By selecting a clustering algorithm, the files are divided into driver partition libraries according to the extracted paths and function export tables, thereby obtaining the classification information of the target driver files.

3. The rootkit threat detection method based on behavioral outliers and statistical features according to any one of claims 1 to 2, characterized in that: The operating system-based API identifies loaded system drivers: Windows uses the Windows API function EnumDeviceDrivers to enumerate loaded drivers. The function EnumDeviceDrivers returns an array of pointers to driver base addresses, which contains the base addresses of loaded drivers. These base addresses are used to retrieve information about the drivers, including names and paths. Linux refers to the lsmod system tool implementation, or obtains information about loaded modules through the / proc / modules file. The / proc / modules file contains the name, size, usage count and other detailed information about each loaded module.

4. The rootkit threat detection method based on behavioral outliers and statistical features according to any one of claims 1 to 2, characterized in that: The method of identifying the loaded system driver by reading the relevant data structure of the system is to parse the _LDR_DATA_TABLE_ENTRY structure in the kernel on the Windows system. The _LDR_DATA_TABLE_ENTRY structure is a structure used to represent the loaded module. The _LDR_DATA_TABLE_ENTRY structure contains information about the loaded module, including the module name, base address, size and other detailed information; use the Windows API function ZwQuerySystemInformation to enumerate the loaded drivers, and use the _LDR_DATA_TABLE_ENTRY structure to retrieve information about the driver; on the Linux system, use the struct module data structure to obtain the status of the loaded driver; the struct module data structure is defined in<linux / module.h> The header file contains information about loaded modules, including the module name, module status, and module reference count.

5. The rootkit threat detection method based on behavioral outliers and statistical features according to any one of claims 1 to 2, characterized in that: The timer or high-precision timer is used to record the status of the relevant instructions being executed by the system during an interrupt, set a system interrupt or a high-precision timer interrupt, generate an interrupt on each core on the CPU at a fixed interval, obtain the instruction pointer IP / EIP / RIP of the current process in the interrupt processing function, and convert the address of the instruction pointed to by the instruction pointer into an actual physical address through the relevant kernel data structure in the kernel state, obtain the kernel memory mapping of the physical address, and trace the stack through the ESP, EBP, RSP, and RBP registers. For each return address item of the stack, it is identified as system memory or user memory through the system mechanism, and the relationship between the memory address and the disk space is identified through the relevant load mapping data structure in the system kernel, and the module name, size and offset information of these kernel state call stacks are recorded.

6. The rootkit threat detection method based on behavioral outliers and statistical features according to any one of claims 1-2, characterized in that: The partition-based clustering algorithm described above: This algorithm requires the number of clusters to be specified in advance, and then optimizes the objective function through iteration so that the data objects in the same cluster are as similar as possible and the data objects in different clusters are different.

7. The rootkit threat detection method based on behavioral outliers and statistical features according to any one of claims 1-2, characterized in that: The hierarchical clustering algorithm does not need to specify the number of clusters, but builds a hierarchical structure to obtain clustering results at different levels. Hierarchical clustering is divided into two types: agglomerative and divisive. Agglomerative clustering is a bottom-up process, that is, starting with each data object as a cluster, and gradually merging similar clusters until a certain termination condition is reached; Divisive clustering is a top-down process, that is, starting with the entire data set as a cluster, gradually dividing dissimilar clusters until a certain termination condition is reached, including the AGNES algorithm and the DIANA algorithm.

8. The rootkit threat detection method based on behavioral outliers and statistical features according to any one of claims 1-2, characterized in that: The density-based clustering algorithm is clustering according to the density distribution of data objects in space, that is, high-density and continuous areas are divided into a cluster, and low-density or sparse areas are divided into noise or outliers. The algorithm can find clusters of any shape and is robust to noise and outliers; including the DBSCAN algorithm and its improved versions: OPTICS and HDBSCAN.

9. The rootkit threat detection method based on behavioral outliers and statistical features according to any one of claims 1-2, characterized in that: The grid-based clustering algorithm divides the data space into a finite number of cells or grids, and performs statistics and analysis on each grid to obtain clustering results, including the STING algorithm and the CLIQUE algorithm.

10. The rootkit threat detection method based on behavioral outliers and statistical features according to any one of claims 1-2, characterized in that: The model-based clustering algorithms described above: This type of algorithm assumes that data objects obey a certain probabilistic model and performs clustering based on model parameters to provide an explanation of the data structure and distribution, and can discover clusters of complex shapes.

11. The rootkit threat detection method based on behavioral outliers and statistical features according to claim 1, characterized in that: Step 2: The rootkit outlier detection phase is to register the stack trace of the system call of the concerned system API on the system to be detected, and when the call of the system API is obtained, obtain the sub-call of the API call, and use the memory address of the sub-call of the collected API call to find the corresponding kernel module and the location of the kernel module on the disk, obtain its path export table through these detected kernel modules, and use the distance algorithm when clustering is the same to query the driver partition library; The module is determined to be an abnormal rootkit module in the following two cases:

1. The module is far away from the group in the driver partition library and is classified separately; 2. The module can be found in the driver partition library, but the call stack related to the module is quite different from the normal module call stack; Step 2: The detailed steps of the rootkit outlier detection phase include: Step 2.1 registering the stack trace of the system call to the concerned system API, Step 2.2 when obtaining the call of the system API, obtaining the sub-calls of the API call, Step 2.3: using the memory addresses of these sub-calls, finding the corresponding kernel module and the location of the kernel module on the disk, Step 2.4: through these detected kernel modules, obtaining their path export table, using the distance algorithm when clustering is the same, querying the driver partition library and Step 2.5 abnormal rootkit judgment phase.

12. The rootkit threat detection method based on behavioral outliers and statistical features according to claim 11, characterized in that: Step 2.1 registers a stack trace of system calls to the concerned system API. Rootkits usually hide specific system objects, including files, processes, drivers, registry entries, open ports, and network connections. The hiding process is to modify and hijack the implementation of the relevant access API of the files, processes, drivers, registry entries, open ports, and network connection objects. The kernel-mode enumeration functions on Windows include the following, and the related calls and sub-calls of these functions may be modified and hijacked: File enumeration function: Use the ZwQueryDirectoryFile function to query the file information in the specified directory, or use the ZwQueryInformationFile function to query the properties of the specified file; Process enumeration function: Use the ZwQuerySystemInformation function to obtain information about all processes in the system, or use the ZwQueryInformationProcess function to obtain information about a specified process; Driver enumeration function: Use ZwEnumerateDriverEntries to enumerate all drivers in the system, or use ZwQueryDriverEntryOrder to query the loading order of drivers. Enumeration function for registry keys: Use the ZwEnumerateKey function to enumerate all subkeys under a specified key, or use the ZwEnumerateValueKey function to enumerate all values ​​under a specified key; Enumeration function for open ports and network connections: Use ZwDeviceIoControlFile function to send IOCTL_TCP_QUERY_INFORMATION_EX control code to obtain information about all open ports and network connections in the TCP / IP protocol stack; On Linux, the enumeration functions for files, processes, drivers, open ports, and network connections are as follows. The related calls and subcalls of the enumeration functions may be modified and hijacked: Enumeration function for files: Use the functions defined in the file_operations structure in the kernel API to operate files, such as open, read, write, and readdir; or use the functions provided by the VFS, the virtual file system layer, to access files, such as vfs_read, vfs_write, and vfs_readdir. Enumeration function for the process: Use the task_struct structure in the kernel API to represent the process, which contains various properties and states of the process; or use some macros and functions to traverse the process list, such as for_each_process, find_task_by_pid, etc. For driver enumeration function: Use the module structure in the kernel API to represent the driver module, which contains the name, version, dependency and other information of the driver module. Or use macros and functions to traverse the driver module list, such as for_each_module and find_module; Enumeration functions for open ports and network connections: Use the socket structure in the kernel API to represent network sockets. Said The socket structure contains the type, protocol, address and other information of the socket; or use macros and functions to traverse the socket list, such as for_each_netdev, sk_for_each; In order to obtain the relevant calling functions and call chains of the system during API processing, ETW (EventTracing for Windows) is used on Windows, and the ftrace mechanism is used on Linux: ETW is a high-speed tracing facility in the Windows operating system. ETW provides a mechanism for tracing and recording events raised by user-mode applications and kernel-mode drivers. ETW is used for system and application diagnostics, troubleshooting, and performance monitoring. Specifically, use ETW's NT Kernel Logger to obtain relevant access to kernel state for identification; kernel state related access includes: process, thread, img, proccntr, cswitch, dpc, isr, syscall, disk, file, diskinit, dispatcher, pf, hf, virtalloc, net, registry, alpc, splitio, driver, profile, fileiocompletion and fileio. For each item of interest, kernel state stack trace can be registered to obtain call stack information for detection; or use some event calls of Microsoft-Windows-Kernel-*, refer to relevant manuals and open source solutions; On Linux, ftrace (Function Tracer) is used for stack tracing. Its core goal is similar to that of Windows. ftrace is one of the Linux kernel performance debugging tools. It is used to track the calling of kernel functions and help developers and designers understand the kernel's current behavior. Specifically, for file access tracking: use the function_graph tracer in ftrace to track file system activities, including file creation, opening, reading, writing, and deletion. Use the function_graph type of tracing to start an ftrace session, capture ext4 file system events, and save the results to a trace file. Access tracking of the process: Use the wakeup tracer in ftrace to track the activities of the process, including the creation and termination of the process, and the creation and termination of threads; use the `echo wakeup> / sys / kernel / debug / tracing / current_tracer` command to start an ftrace session, capture the events of the process, and save the results to the trace file; Driver access tracking: Use the events directory in ftrace to track driver activities, including driver loading, unloading, device addition, and removal. Use the command `echo 1> / sys / kernel / debug / tracing / events / nvme` to start an ftrace session, capture nvme driver events, and save the results to a trace file. Tracking access to open ports and network connections: Use the events directory in ftrace to track the activities of the TCP / IP protocol stack, including port listening, connection, and disconnection. Use the echo 1> / sys / kernel / debug / tracing / events / tcpip / enable command to start an ftrace session, capture TCP / IP protocol stack events, and save the results to a trace file.

13. The rootkit threat detection method based on behavioral outliers and statistical features according to claim 11, characterized in that: In step 2.2, when a system API call is obtained, a sub-call of the API call is obtained. Preferably, when a relevant API is called, its sub-calls are obtained; There are two ways to obtain the sub-calls of the API call when the system API call is obtained, including: using timer sampling and Intel's PT technology; Intel High Precision Event Timer (HPET) is a high-precision timer that provides more accurate timestamps for computer time synchronization and performance analysis. Intel PT, or Processor Trace, is a hardware-level tracing mechanism provided by Intel CPUs that can record the instruction stream executed by the CPU, including branches, function calls, and return information. The tracing mechanism records the instruction stream executed by the CPU, including branches, function calls, and return information. The steps required to use this technology include: initializing the configuration of Intel Processor Trace; defining a callback function to handle PT events, such as function entry, function exit, branch events, etc.; allocating memory to store PT data; creating a PT decoder to identify and obtain information given by the CPU; enabling the Intel Processor Trace function and waiting for the corresponding function call; In terms of function call identification, a series of variables are defined, which are set when the retrieval function of the above-mentioned related API call enters, and are unset when the retrieval function of the API call exits, so as to track only the call stack of the related API call; For development related to Intel Process Trace, please refer to Intel's documentation manuals and open source tool implementations.

14. The rootkit threat detection method based on behavioral outliers and statistical features according to claim 11, characterized in that: The method of step 2.3: using the memory addresses of these subcalls to find the corresponding kernel module and the location of the kernel module on the disk is the same as the method of extracting the disk path where the driver is located in step 1.

2.

15. The rootkit threat detection method based on behavioral outliers and statistical features according to claim 11, characterized in that: The step 2.4 is to obtain the path export table of the kernel modules detected, query the driver partition library using the same distance algorithm as in clustering, and query the driver partition library for the kernel modules involved in each call stack. The method used is the same as the method described in step 1.4 for clustering and establishing the driver partition library.

16. The rootkit threat detection method based on behavioral outliers and statistical features according to claim 11, characterized in that: In the abnormal rootkit determination stage of step 2.5, the module is determined to be an abnormal rootkit module in the following two cases:

1. The module is far away from the group in the driver partition library and is classified separately; 2. The module can be found in the driver partition library, but the call stack related to the module is quite different from the normal module call stack; Specifically, the way of determining abnormality in clustering is closely related to the clustering algorithm used. In the K-means algorithm, it is done by "identifying the minority", that is, the cluster with the least number of samples is regarded as the abnormal cluster, and then the points belonging to the cluster are marked as abnormal points. In the DBSCAN algorithm, core points, boundary points, and noise points are divided, and noise points are identified as outliers that are classified separately: core points refer to points that contain enough neighboring points within a specified radius, and core points are representatives of high-density areas; boundary points refer to points that are within the neighborhood of core points but are not core points, and boundary points are bridges connecting different clusters; noise points refer to points that are neither core points nor boundary points, and are low-density areas or isolated points, and are usually considered outliers; After finding the classification through the clustering algorithm, the obtained call stack is compared with all typical call stacks in the class one by one to determine the similarity; the comparison method is normalized and the common text similarity calculation method is used to calculate the distance or similarity between texts using the numerical vector of the text. The methods used are cosine similarity, Euclidean distance, Jaccard similarity and simhash method; When it is found that the classification can be found, but the similarity of all function calls is low, that is, there is a large difference between the similarity of the found call stack and the normal module call stack, the module is determined to be an abnormal module.

17. A rootkit threat detection system based on behavioral outliers and statistical features, characterized by: The system comprises a system driver identifier, a driver partition library builder, a driver partition library, a tested system data collector and a RootKit detector. The data of the system driver identifier is provided to the driver partition library builder for establishing the driver partition library. The tested system data collector provides the data to the RootKit detector. The RootKit detector uses the driver partition library to perform detection and output the result, wherein: ——System driver identifier, used for driver identification of loaded system, extraction of disk path where driver is located, and extraction of driver function table; including: identification of driver of loaded system based on API of operating system, identification of driver of loaded system by reading relevant data structure of system, detection of system driver by timed sampling, extraction of disk path where driver is located, and extraction of driver function table; its steps are as described in method step 1.1: identification of driver of loaded system, method step 1.2: extraction of disk path where driver is located, and method step 1.3: extraction of driver function table; ——Driver partition library builder, used to build the driver partition library required by the system, which is divided into feature extraction representation, hierarchical clusterer, agglomerative clusterer, and divisive clusterer. Its steps are as described in step 1.4 of the method for clustering and building a driver partition library; ——The driver partition library is created by the driver partition library builder, and its form is a software database or disk file, which is used to store the clustering results created by the driver partition library builder. ——The data collector of the system under test is used to collect data of the operating system to be tested, including: ETW (EventTracing for Windows) system call tracer, Ftrace system call tracer, timer sampling system call sub-call collector, Intel Processor Trace system call sub-call collector; its steps are as shown in method step 2.1 registering the stack trace of the system call of the concerned system API, method step 2.2 when obtaining the call of the system API, obtaining the sub-call of the API call, 5.

1. method step 2.3 using the memory addresses of these sub-calls to find the corresponding kernel module and the location of the kernel module on the disk; ——The RootKit detector is used to detect RootKit, and uses the driver partition library to detect and collect data, including: a feature extraction indicator, a clustering distance calculator, and an abnormal rootkit determiner; complete method step 2.4 through these detected kernel modules, obtain their path export table, use the distance algorithm when clustering is the same, query the driver partition library method step 2.5 defined in the abnormal rootkit determination stage; first, the system driver identifier collects data from the normal system, and then the system driver identifier establishes the driver partition library required by the system, and then the tested system data collector collects data from the tested system, and finally the RootKit detector is responsible for completing method step 2.4 through the detected kernel module, obtain its path export separation table, use the distance algorithm when clustering is the same, query the driver partition library and the work defined in method step 2.5 abnormal rootkit determination stage.

18. The rootkit threat detection system based on behavioral outliers and statistical features according to claim 17, characterized in that: Also included is at least one memory and at least one processor for rootkit threat detection based on behavioral outliers and statistical features; The at least one memory is used to store a machine-readable program; The at least one processor is used to call a machine-readable program to execute any abnormal rootkit detection method.

19. The rootkit threat detection system based on behavioral outliers and statistical features according to claim 17, characterized in that: The invention also includes a computer readable medium on which computer instructions are stored. When the computer instructions are executed by a processor, the processor is enabled to execute any abnormal rootkit detection method.

20. The rootkit threat detection system based on behavioral outliers and statistical features according to claim 17, characterized in that : Also includes a storage medium device, on which software program codes for implementing any function are stored, and enables a computer or CPU or MPU to read and execute the program codes stored in the storage medium.

21. The rootkit threat detection system based on behavioral outliers and statistical features according to claim 20, characterized in that: Storage media for providing program codes include floppy disks, hard disks, magneto-optical disks, optical disks, magnetic tapes, non-volatile memory cards and ROMs; program codes can also be downloaded from a server computer via a communication network; and an operating system operating on a computer can also perform part or all of the actual operations through instructions based on the program codes, thereby realizing the functions in any claim.

22. The rootkit threat detection system based on behavioral outliers and statistical features according to any one of claims 20-21, characterized in that: The program code read from the storage medium is written into a memory provided in an expansion board inserted into the computer or into a memory provided in an expansion module connected to the computer, and then based on the instructions of the program code, a CPU installed on the expansion board or expansion module is enabled to perform part or all of the actual operations, thereby realizing the functions in any of the above claims.

Images