Application behavior detection method, system and electronic device

Abstract

This invention provides a method, system, and electronic device for detecting application behavior, relating to the field of computer security technology. The method includes: collecting system call data of a target application in user mode and kernel mode; extracting basic statistical features representing the statistical regularity of the calls and deep sequence features representing the correlation between the calls from the system call data, forming a system call feature set; and inputting the system call feature set into a behavior detection model trained based on a normal behavior feature library for analysis to obtain behavior detection results. This invention achieves full-stack, blind-spot-free monitoring of application behavior by simultaneously collecting system call request context in user mode and actual execution data in kernel mode, improving the accuracy and reliability of behavior detection. Furthermore, by constructing a hierarchical feature system combining basic statistical features and deep sequence features, it greatly enhances the detection depth and sensitivity for new and complex threats.

Description

Technical Field

[0001] This invention relates to the field of computer security technology, and in particular to a method, system, and electronic device for detecting the behavior of applications. Background Technology

[0002] Currently, with the continuous increase in the complexity of application functions, the dynamics and uncertainties of their runtime behavior have significantly increased, and advanced escape techniques are constantly evolving, posing increasingly severe challenges to endpoint security. Current mainstream application security detection technologies mainly follow two technical routes: static analysis and dynamic analysis. However, both have inherent limitations and are difficult to effectively address new and complex threats.

[0003] Therefore, improving the sensitivity and accuracy of detecting abnormal behavior in applications has become an urgent technical problem to be solved. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a method, system and electronic device for detecting the behavior of applications, so as to solve the technical problems of low sensitivity and low accuracy of current application abnormal behavior detection schemes.

[0005] In a first aspect, embodiments of the present invention provide a method for detecting the behavior of an application, comprising: Collect system call data of the target application in user mode and kernel mode; For the system call data, basic statistical features representing the statistical regularity of the calls and deep sequence features representing the correlation between the calls are extracted to form a system call feature set; The system call feature set is input into a behavior detection model trained based on a normal behavior feature library for analysis to obtain behavior detection results; wherein, the behavior detection results include a judgment result and an anomaly type.

[0006] In one implementation, the collection of system call data of the target application in user mode and kernel mode includes: By monitoring the user-mode context of the process initiating the system call, the system call requests and call context information initiated by the target application in user mode are collected; By monitoring the execution process of the system call request in kernel mode, the type, parameters, return value, and timestamp of the system call made by the target application in kernel mode are collected; The call context information is associated and integrated with the type, parameters, return value, and timestamp of the system call to generate time-seriesd system call data.

[0007] In one implementation, the system call data includes system call records collected at different time points; after collecting system call data of the target application in user mode and kernel mode, the method further includes: Remove invalid system call records generated spontaneously by the operating system kernel, and filter system call records with the same parameters that are repeated consecutively; The system call parameters are converted into a predefined uniform format, and the system call records are sorted chronologically according to the timestamp.

[0008] In one implementation, the system call feature set is constructed by extracting basic statistical features representing the statistical regularity of the calls and deep sequence features representing the correlation between the calls, respectively, from the system call data. This includes: Within a preset time window, the call frequency of various types of system calls, the proportion of risky system calls, and the value distribution of parameters under the same system call type are statistically analyzed to obtain the basic statistical characteristics. The system call sequence is extracted from the system call data by a frequent itemset mining algorithm, the information entropy value of the system call sequence is calculated, and the parameter correlation of different system calls of the same process is analyzed. The system call sequence, the information entropy value and the parameter correlation constitute the deep sequence feature.

[0009] In one implementation, the behavior detection model trained based on a normal behavior feature library includes: Collect system call characteristics of at least two types of normal applications in different scenarios, and construct the normal behavior feature library; The behavior detection model is trained based on the normal behavior feature library; the behavior detection model is an isolated forest model or an autoencoder model.

[0010] In one implementation, the determination result is normal or abnormal; after inputting the system call feature set into a behavior detection model trained based on a normal behavior feature library for analysis to obtain the behavior detection result, the method further includes: When the determination result is abnormal, risk scores of at least two dimensions of risk quantification indicators are determined based on the system call feature set. Based on the weights corresponding to at least two preset risk quantification indicators, the risk scores of the at least two risk quantification indicators are weighted and calculated to generate a quantitative measurement report containing a comprehensive risk value.

[0011] In one implementation, the risk quantification indicators of at least two dimensions include: the frequency of occurrence of abnormal sequences, the proportion of risk calls, and the behavioral deviation output by the behavioral detection model; The step of weighting the risk scores of the at least two dimensions of risk quantification indicators according to their corresponding weights, and generating a quantitative measurement report containing a comprehensive risk value, includes: The first value is determined by multiplying the risk score corresponding to the frequency of occurrence of the abnormal sequence with its weight. The product of the risk score and weight corresponding to the risk call percentage is determined as the second value; The product of the risk score and weight corresponding to the deviation of the behavior is determined as the third value; The sum of the first value, the second value, and the third value is determined as the comprehensive risk value, and a quantitative measurement report is generated.

[0012] Secondly, embodiments of the present invention also provide an application behavior detection system, the system comprising: The data acquisition module is used to collect system call data of the target application in user mode and kernel mode; The feature extraction module is used to extract basic statistical features that characterize the statistical regularity of the calls and deep sequence features that characterize the correlation between the calls for the system call data, thereby forming a system call feature set; The result output module is used to input the system call feature set into the behavior detection model trained based on the normal behavior feature library for analysis, and obtain the behavior detection result; wherein, the behavior detection result includes the anomaly judgment result and the anomaly type.

[0013] Thirdly, embodiments of the present invention also provide an electronic device, including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method described in any one of the first aspects.

[0014] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the method described in any one of the first aspects.

[0015] This invention provides a method, system, and electronic device for detecting application behavior. The method collects system call data from a target application in both user mode and kernel mode. For the system call data, it extracts basic statistical features representing the statistical regularity of the calls and deep sequence features representing the correlation between calls, forming a system call feature set. The system call feature set is then input into a behavior detection model trained on a normal behavior feature library for analysis, yielding behavior detection results. These results include a judgment result and anomaly type. By simultaneously collecting system call request context from user mode and actual execution data from kernel mode, full-stack, blind-spot-free monitoring of application behavior is achieved, improving the accuracy and reliability of behavior detection. Furthermore, by constructing a hierarchical feature system combining basic statistical features and deep sequence features, the detection model can not only perceive surface-level anomalies such as call frequency and type, but also gain deeper insights into the implicit temporal correlations, logical relationships, and parameter dependencies between system calls, greatly enhancing the detection depth and sensitivity for new and complex threats.

[0016] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating an application behavior detection method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a process for generating system call data according to an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating a monitoring and data collection system calling data, provided in an embodiment of the present invention. Figure 4 This is a schematic diagram of the structure of an application behavior detection system provided in an embodiment of the present invention; Figure 5This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Currently, with the continuous increase in the complexity of application functions, the dynamics and uncertainties of their runtime behavior have significantly increased, and advanced escape techniques are constantly evolving, posing increasingly severe challenges to endpoint security. Current mainstream application security detection technologies mainly follow two technical routes: static analysis and dynamic analysis. However, both have inherent limitations and are difficult to effectively address new and complex threats.

[0022] First, static code analysis (SCA) technology offline analyzes the source code or binary code of an application to extract features such as code structure, control flow, function call graphs, and string constants, and then matches them against known malicious pattern libraries to determine risk. However, this technology has fundamental flaws: First, it cannot perceive and capture the dynamic behavior of applications in the real runtime environment, such as dynamically loading and executing malicious modules in memory (fileless attacks), real-time network interactions based on runtime results, or attacks using legitimate system call sequences. Second, this technology is easily circumvented by adversarial techniques. Attackers commonly use techniques such as code packing, obfuscation, polymorphism, and virtualization instructions, which can easily change the static form of a program, causing analysis based on fixed features to fail, thus creating detection blind spots.

[0023] Secondly, while dynamic behavior detection technology based on preset signature codes can monitor runtime behavior (such as system call sequences), it is essentially still a form of "pattern matching." It relies on security experts manually analyzing and summarizing known malicious behaviors to extract fixed signature codes or rules (e.g., "calling connect immediately after continuously executing fork"). The technology also has significant drawbacks: First, it suffers from poor lag and generalization ability. The signature database is always outdated compared to the emergence of new attack techniques, making it almost impossible to identify unknown threats (zero-day attacks) or minor variations of known threats. Second, it has weak evasion resistance. Attackers can easily disrupt preset signature patterns and bypass detection by inserting invalid (No-op) system calls, adjusting the execution order of malicious operations, or splitting a single behavior into multiple processes working together.

[0024] Given the fundamental limitations of the two aforementioned technologies, the industry has turned its attention to detection methods based on machine learning and dynamic behavior modeling, aiming to discover unknown anomalies by learning normal behavioral patterns. However, in this emerging technological path, existing implementations have not yet completely solved the core problems, specifically: Insufficient depth and completeness of behavioral monitoring, with data collected only from a single perspective of user space or kernel space, leads to fragmented behavioral profiles, leaving room for attackers to hide their true intentions.

[0025] The behavioral feature extraction is limited in scope, relies excessively on shallow statistical features, lacks characterization of deep temporal logic and semantic relationships between system calls, and has a weak ability to identify complex attack sequences that mimic normal behavior.

[0026] The risk assessment results lack actionable quantitative guidance, and the output is mostly binary labels or abstract scores. It cannot provide multi-dimensional quantitative reports that describe the risk composition, level and handling priority, resulting in low safety operation efficiency.

[0027] In summary, how to build a new application behavior detection solution that can achieve full-stack, blind-spot-free behavior monitoring, extract multi-dimensional deep behavioral features, and ultimately output accurate quantitative risk assessment results has become a key technical challenge that urgently needs to be overcome in the current field of endpoint security.

[0028] Based on this, the application behavior detection method provided by this invention can achieve full-stack, blind-spot-free monitoring of application behavior by simultaneously collecting system call request context in user space and actual execution data in kernel space, thereby improving the accuracy and reliability of behavior detection. Furthermore, by constructing a hierarchical feature system combining basic statistical features and deep sequence features, the detection model can not only perceive anomalies such as surface-level call frequency and type, but also gain deeper insights into the implicit temporal correlations, logical relationships, and parameter dependencies between system calls, greatly enhancing the detection depth and sensitivity for new and complex threats.

[0029] To facilitate understanding of this embodiment, a method for detecting the behavior of an application disclosed in this invention will first be described in detail. (See [link to relevant documentation]). Figure 1 The diagram illustrates a behavior detection method for an application, which may include the following steps: S102 collects system call data of the target application in user mode and kernel mode.

[0030] System call data includes user-space data and kernel-space data. User-space data includes at least one of the following: call context information (such as process ID, thread ID, parent process ID), user-space call stack (tracing back to the library function or code module that initiated the call), register state, and raw call parameters passed in user space. Kernel-space data includes at least one of the following: system call type (such as open, fork, and sendto), parameters (such as file path and port number), return value, and timestamp. System calls serve as the sole interface between applications and the operating system kernel, recording the core behavioral patterns of applications (such as file operations, process management, and network communication).

[0031] For example, user-space data acquisition involves attaching to the target application process via process debugging interfaces (such as ptrace in Linux) or process creation hooks (such as CreateProcess monitoring in Windows). This monitoring point is responsible for capturing the instantaneous state of the process when it initiates a system call request. Specific information includes: process context (such as process ID, thread ID, parent process ID), user-space call stack (tracing back to the library function or code module that initiated the call), register state, and the original call parameters passed in user space.

[0032] For example, kernel-mode data acquisition involves hooking into the core functions that handle system calls within the operating system kernel through kernel tracing mechanisms (such as Linux's kprobe / tracepoint) or file system filter drivers (such as Windows' Minifilter). This monitoring point is responsible for capturing the moment when a system call is actually executed in the kernel. Specific information includes: the type of the final executed system call (such as NtOpenProcess), the kernel-level parameters after kernel verification and conversion, the call return value (success / failure and its specific value), and a high-precision kernel timestamp.

[0033] After collecting user-mode and kernel-mode data separately, the two parts of the same system call event from user-mode and kernel-mode are precisely correlated, aligned and merged using shared unique identifiers (such as process ID, thread ID and timestamp accurate to microseconds) to form a complete, time-sequential system call record, which is finally aggregated into system call data.

[0034] S104. For system call data, extract basic statistical features that characterize the statistical regularity of calls and deep sequence features that characterize the correlation between calls to form a system call feature set.

[0035] For example, basic statistical feature extraction: within a sliding time window (e.g., every 10 seconds), perform quantitative statistics on the system call sequence, including but not limited to: 1) call frequency: the absolute count of various system calls, such as 12 sendto calls within 10 seconds; 2) type proportion: the proportion of high-risk calls (such as process creation execve, network connection connect) to the total calls; 3) parameter distribution statistics: the distribution of parameter values ​​under the same call type, such as the number of different file paths accessed by open calls, the dispersion of the target IP of sendto calls, etc.

[0036] For example, deep sequence feature extraction involves using sequence analysis and frequent itemset mining algorithms (such as Apriori) to uncover relationships between system calls. This includes, but is not limited to: 1) Association rule mining: using algorithms such as Apriori and FP-Growth to discover frequent sequences of "call A → call B" (e.g., the probability of occurrence of "open → write → close"). 2) Sequence entropy calculation: calculating the information entropy of system call sequences; lower entropy values ​​indicate stronger behavioral regularity and a higher probability of anomalies. 3) Parameter correlation analysis: based on the file path or target IP of system calls, analyzing the parameter correlations between different system calls of the same process, such as whether there is a historical correlation between the file path of the open call and the target IP of the sendto call.

[0037] S106, input the system call feature set into the behavior detection model trained based on the normal behavior feature library for analysis, and obtain the behavior detection result; wherein, the behavior detection result includes the judgment result and the abnormal type.

[0038] For example, in a trusted environment, a large set of system call features generated by a large number of known normal applications (such as office software, browsers, compilers, etc.) running in various typical scenarios is collected to construct a "normal behavior feature library". This normal behavior feature library is used to train a behavior detection model (such as an Isolation Forest or an Autoencoder). The real-time system call feature set of the target application is input into the trained behavior detection model. The behavior detection model outputs an anomaly score (such as reconstruction error or isolation path length). This score is compared with a preset threshold to obtain a judgment result ("normal" or "abnormal"). For example, if the model outputs an anomaly score greater than 0.8, it is judged as abnormal. When the judgment result is abnormal, root cause analysis is performed based on the specific feature dimensions that triggered the anomaly to label the anomaly type (such as malicious code execution or sensitive data leakage). For example, if it is triggered by "abnormal file read parameter distribution", it is labeled as "sensitive data leakage".

[0039] In practical applications, the behavior detection model is trained by collecting system call features from 10 types of normal applications, including Chrome, LibreOffice, and Vim, over a 72-hour period to build a normal feature library of 100,000 samples. An isolated forest model is trained using the scikit-learn library, with an anomaly threshold of 0.8 set. Real-time detection involves inputting the system call feature set of the target application into the trained behavior detection model and outputting an anomaly score of 0.95. If the score is greater than the set threshold of 0.8, the model is considered an anomaly. Combined with the "execve→connect" anomaly sequence, the model is determined to be an anomaly of "malicious code execution + remote communication".

[0040] The application behavior detection method provided in this embodiment forms a closed-loop, adaptive application behavior detection process through a coherent design of "dual-state full-stack data acquisition → hierarchical multi-dimensional feature extraction → intelligent model analysis based on normal baseline". It effectively solves the core defects of existing technologies such as incomplete monitoring, weak feature representation, inability to detect unknown threats, and insufficient alarm information, and achieves highly accurate and highly adaptable security detection.

[0041] In one implementation, such as Figure 2 The diagram illustrates a process for generating system call data, which involves collecting system call data from the target application in user mode and kernel mode, including: S202 collects system call requests and call context information initiated by the target application in user mode by monitoring the context of the process that initiates the system call in user mode.

[0042] S204 monitors the execution process of system call requests in kernel mode, collecting the type, parameters, return value, and timestamp of system calls made by the target application in kernel mode.

[0043] S206 associates and integrates the call context information with the system call type, parameters, return value, and timestamp to generate time-seriesd system call data.

[0044] In practical applications, at the kernel level: the Linux kernel's kprobe mechanism is used to hook into core system call functions in the sys_call_table (such as sys_open, sys_sendto, and sys_execve) to collect call type, parameters (such as file path obtained through the d_path function), and timestamps (accurate to milliseconds).

[0045] User layer: Attach to the target process (such as a suspicious process with PID 1234) through the ptrace system call, capture the system call requests initiated by the process, and record context information such as process PID and PPID; Data integration: Transfer kernel layer and user layer data to the user space analysis module through shared memory to form a raw system call dataset in JSON format (example: {"pid":1234,"call_type":"open","params":{"path":" / tmp / test.sh"},"timestamp":"1690000000001","return_val":3}).

[0046] For example, such as Figure 3 The diagram illustrates a method for monitoring and collecting system call data. An application initiates a system call request in user mode via a user library function. At the system call interface, a privilege switch is triggered by the `syscall` instruction, entering kernel mode. The kernel executes the system call handler function, completes the service, and returns to user mode, allowing the application to continue execution. User-mode monitoring: Monitoring object: application process context; Monitoring timing: before the system call is initiated; Captured information: process ID, call stack, register status, user-mode parameters, etc. Kernel-mode monitoring: Monitoring object: system call handler function; Monitoring timing: during system call execution; Captured information: call type, kernel-mode parameters, return value, precise timestamp, etc.

[0047] In one implementation, the system call data includes system call records collected at different time points; after collecting system call data of the target application in user mode and kernel mode, the method further includes: removing invalid system call records spontaneously generated by the operating system kernel, and filtering system call records with the same parameters that are repeated consecutively; converting the parameters of the system calls into a predefined unified format, and sorting the system call records in chronological order according to the timestamp.

[0048] For example, system call data is cleaned and standardized to provide high-quality data for feature extraction: Data cleaning: Remove invalid calls spontaneously generated by the operating system kernel (such as periodic calls from kernel threads) and filter out consecutively repeated identical system calls (such as consecutive read calls from the same process without parameter changes). Standardization: Convert system call parameters to a uniform format (e.g., file paths are standardized to absolute paths, port numbers are converted to decimal), and sort the system call data chronologically by timestamp to ensure temporal consistency of the sequence.

[0049] In practical applications, data cleaning involves using a Python script to filter the call records of kernel threads (PID < 100) and removing more than 5 consecutive identical read calls (with no parameter changes); standardization involves converting the relative path ". / test.sh" to the absolute path " / home / user / test.sh", sorting the JSON data by timestamp, and generating a time-series preprocessed dataset.

[0050] In one implementation, for system call data, basic statistical features characterizing the statistical regularity of calls and deep sequence features characterizing the correlation between calls are extracted to form a system call feature set, including: Within a preset time window, the call frequency of various types of system calls, the proportion of risky system calls, and the distribution of parameter values ​​under the same system call type are statistically analyzed to obtain basic statistical characteristics.

[0051] The frequent itemset mining algorithm is used to extract system call sequences from system call data, calculate the information entropy value of the system call sequence, and analyze the parameter correlation of different system calls of the same process. The system call sequence, information entropy value and parameter correlation constitute deep sequence features.

[0052] In practical applications, basic statistical characteristics are as follows: a 10-second time window is set, and execve is called 2 times and connect is called 5 times within the time window, with risky calls accounting for 15% (out of a total of 33 calls); deep sequence characteristics are as follows: the pymining library is used to mine frequent sequences, and the sequence "execve( / tmp / mal.sh)→connect(192.168.1.10:8080)" appears 3 times, with a sequence entropy value of 0.9 (lower than the entropy value of 1.5 for normal applications). The parameter correlation shows that the target IP of connect matches the historical malicious IP.

[0053] In one implementation, the behavior detection model trained based on a normal behavior feature library includes: Collect system call characteristics of at least two types of normal applications in different scenarios to build a normal behavior feature library.

[0054] The behavior detection model is trained based on a normal behavior feature database; the behavior detection model is either an isolated forest model or an autoencoder model.

[0055] In one implementation, the determination result is either normal or abnormal; after inputting the system call feature set into a behavior detection model trained based on a normal behavior feature library for analysis, and obtaining the behavior detection result, the method further includes: When the judgment result is abnormal, risk scores of at least two dimensions of risk quantification indicators are determined based on the system call feature set.

[0056] Based on the weights corresponding to at least two preset risk quantification indicators, the risk scores of the at least two risk quantification indicators are weighted and calculated to generate a quantitative measurement report containing a comprehensive risk value.

[0057] In one implementation, the behavior detection results (normal / abnormal, abnormal type) and quantitative measurement reports (values ​​of each indicator, comprehensive risk value) are output to the endpoint security management system. For high-risk behaviors with a comprehensive risk value ≥ 8, real-time alarms are triggered (such as pop-up prompts, temporary process pauses), and users are allowed to manually provide feedback on the accuracy of the alarms to optimize the model thresholds.

[0058] In one implementation, the risk quantification indicators in at least two dimensions include: the frequency of occurrence of abnormal sequences, the proportion of risk calls, and the behavioral deviation output by the behavioral detection model. Based on the weights corresponding to the at least two dimensions of risk quantification indicators, the risk scores of the at least two dimensions of risk quantification indicators are weighted and calculated to generate a quantitative measurement report containing a comprehensive risk value. This includes: determining the product of the risk score corresponding to the frequency of occurrence of abnormal sequences and its weight as a first value; determining the product of the risk score corresponding to the proportion of risk calls and its weight as a second value; determining the product of the risk score corresponding to the behavioral deviation degree and its weight as a third value; and determining the comprehensive risk value by summing the first, second, and third values, and generating the quantitative measurement report. Wherein, the sum of the weights corresponding to all risk quantification indicators equals 1.

[0059] For example, the frequency of occurrence of normal sequences: the frequency of occurrence of abnormal association rules in deep sequence features (such as the number of times the sequence "open( / etc / passwd)→sendto" appears), with a weight of 40%; the proportion of risky calls: the total number and proportion of risky system calls per unit time, with a weight of 30%; and the deviation of behavior: the deviation between real-time features and the normal feature library (the abnormal score output by the behavior detection model), with a weight of 30%. The comprehensive risk value is calculated using a weighted summation formula (comprehensive risk value = feature association degree × 0.4 + risky call intensity × 0.3 + behavior deviation × 0.3), resulting in a comprehensive risk value of 0-10 (0-3 for low risk, 4-7 for medium risk, and 8-10 for high risk), generating a quantitative measurement report.

[0060] In practical applications, the following parameters are considered: Feature correlation: Abnormal sequence appeared 3 times, score 8 (out of 10), contribution value 8×0.4=3.2; Risk call intensity: Risk call occurred 5 times, accounting for 15%, score 7 (out of 10), contribution value 7×0.3=2.1; Behavioral deviation: Abnormal score 0.95, score 9.5 (out of 10), contribution value 9.5×0.3=2.85; Overall risk value: 3.2+2.1+2.85=8.15, judged as high risk, and a PDF measurement report containing indicator details is generated.

[0061] In one implementation, after generating a quantitative metric report containing a comprehensive risk value, an HTTP alert request is sent to the endpoint security management platform, and a pop-up notification is generated based on the metric report. For example, if the pop-up is triggered, it might display the message: "Process PID1234 exhibits high-risk malicious behavior, with a comprehensive risk value of 8.15. It is recommended to pause the process." Simultaneously, the metric report is stored locally in the " / var / log / behavior_metric / " directory for administrator retrospective analysis.

[0062] The application behavior detection method provided in this invention focuses on system call data during application runtime. It addresses the technical problems of insufficient dynamic behavior coverage, single feature set, and lack of quantitative evaluation in traditional detection methods by comprehensively collecting system call data, preprocessing and optimizing the data, extracting multi-dimensional system call features, implementing behavior detection based on these features, and constructing indicators for quantitative measurement. This invention improves the accuracy and anti-evasion capabilities of behavior detection by extracting basic statistical features and deep sequence features of system calls in a layered manner. Simultaneously, it defines multi-dimensional quantitative indicators to achieve measurable assessment of application behavior risks, making it widely applicable to terminal security protection, malware identification, and application risk management scenarios.

[0063] The program behavior detection method provided in this embodiment of the invention has the following beneficial effects: High detection accuracy: By extracting basic statistical features and deep sequence features in a hierarchical manner, the static attributes and dynamic associations of system calls are covered, which significantly reduces the false alarm rate and false negative rate compared with traditional feature code methods.

[0064] Quantifiable Behavior: For the first time, a multi-dimensional quantitative indicator system has been constructed to transform "abnormal behavior" into calculable risk values, providing accurate data support for security decisions.

[0065] Strong anti-circumvention capability: It does not rely on manually defined signature codes, but is based on the essential characteristics of system calls for detection. It can cope with circumvention methods such as packing and behavior obfuscation, and significantly improves the identification coverage of new malicious behaviors.

[0066] Good real-time performance: Significantly reduces the output latency of behavior detection results, with the latency from system call data acquisition to detection result output controlled within 1 second, meeting the requirements of real-time monitoring.

[0067] The system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0068] Based on the same concept, embodiments of the present invention provide an application behavior detection system, such as... Figure 4 The diagram shown represents a structural block diagram of an application behavior detection system. The application behavior detection system 400 includes: The data acquisition module 410 is used to collect system call data of the target application in user mode and kernel mode.

[0069] The feature extraction module 420 is used to extract basic statistical features that characterize the statistical regularity of system calls and deep sequence features that characterize the correlation between system calls, thereby forming a system call feature set.

[0070] The result output module 430 is used to input the system call feature set into the behavior detection model trained based on the normal behavior feature library for analysis, and obtain the behavior detection result; wherein, the behavior detection result includes the anomaly judgment result and the anomaly type.

[0071] In one embodiment, the data acquisition module 410 includes a first acquisition module, a second acquisition module, and an association and integration module; The first acquisition module is used to collect system call requests and call context information initiated by the target application in user mode by monitoring the context of the process that initiates the system call in user mode. The second acquisition module is used to collect the type, parameters, return value and timestamp of the system calls made by the target application in the kernel mode by monitoring the execution process of system call requests in the kernel mode. The association and integration module is used to associate and integrate the call context information with the type, parameters, return value and timestamp of the system call to generate time-seriesd system call data.

[0072] In one implementation, the system call data includes system call records collected at different time points; the application behavior detection system 400 also includes a data cleaning module, which is used to: remove invalid system call records generated spontaneously by the operating system kernel, and filter system call records with the same parameters that are repeated continuously; convert the parameters of the system calls into a predefined unified format, and sort the system call records in chronological order according to the timestamp.

[0073] In one embodiment, the feature extraction module 420 includes a basic feature extraction module and a deep sequence extraction module; The basic feature extraction module is used to statistically analyze the call frequency of various types of system calls, the proportion of risky system calls, and the distribution of parameter values ​​under the same system call type within a preset time window, thereby obtaining basic statistical features. The deep sequence extraction module is used to extract system call sequences from system call data using a frequent itemset mining algorithm, calculate the information entropy value of the system call sequence, and analyze the parameter correlation of different system calls of the same process. The system call sequence, information entropy value, and parameter correlation constitute the deep sequence features.

[0074] In one implementation, the application behavior detection system 400 further includes a model training module, which is used to: collect system call features of at least two types of normal applications in different scenarios, and construct a normal behavior feature library; train a behavior detection model based on the normal behavior feature library; the behavior detection model is an isolated forest model or an autoencoder model.

[0075] In one implementation, the determination result is either normal or abnormal; the application behavior detection system 400 further includes a report generation module, which is used for: When the judgment result is abnormal, the risk scores of at least two risk quantification indicators are determined based on the system call feature set; according to the weights corresponding to the at least two risk quantification indicators, the risk scores of the at least two risk quantification indicators are weighted and calculated to generate a quantitative measurement report containing a comprehensive risk value.

[0076] In one implementation, the risk quantification indicators in at least two dimensions include: the frequency of occurrence of abnormal sequences, the proportion of risk calls, and the behavioral deviation degree output by the behavioral detection model; the report generation module is specifically used to: determine the product of the risk score and weight corresponding to the frequency of occurrence of abnormal sequences as a first value; determine the product of the risk score and weight corresponding to the proportion of risk calls as a second value; determine the product of the risk score and weight corresponding to the behavioral deviation degree as a third value; and determine the comprehensive risk value by summing the first value, the second value, and the third value, and generate a quantitative measurement report.

[0077] This invention also provides an electronic device, such as... Figure 5 The diagram shows the structure of the electronic device, which includes a processor 51 and a memory 50. The memory 50 stores computer-executable instructions that can be executed by the processor 51. The processor 51 executes the computer-executable instructions to implement the behavior detection method of the aforementioned application.

[0078] exist Figure 5 In the illustrated embodiment, the electronic device further includes a bus 52 and a communication interface 53, wherein the processor 51, the communication interface 53, and the memory 50 are connected via the bus 52.

[0079] The memory 50 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 53 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 52 may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus 52 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0080] Processor 51 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 51 or by instructions in software form. Processor 51 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this invention can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the memory. The processor 51 reads the information in the memory and, in conjunction with its hardware, completes the steps of the application behavior detection method of the aforementioned embodiment.

[0081] This invention also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are invoked and executed by a processor, they cause the processor to implement the behavior detection method of the aforementioned application. For specific implementation details, please refer to the foregoing method embodiments, which will not be repeated here.

[0082] The computer program products of the application behavior detection method, system, and electronic device provided in the embodiments of the present invention include a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0083] Unless otherwise specifically stated, the relative steps, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of the invention.

[0084] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0085] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0086] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for detecting the behavior of an application, characterized in that, The method includes: Collect system call data of the target application in user mode and kernel mode; For the system call data, basic statistical features representing the statistical regularity of the calls and deep sequence features representing the correlation between the calls are extracted to form a system call feature set; The system call feature set is input into a behavior detection model trained based on a normal behavior feature library for analysis to obtain behavior detection results; wherein, the behavior detection results include a judgment result and an anomaly type.

2. The method according to claim 1, characterized in that, The system call data of the target application in user mode and kernel mode collected includes: By monitoring the user-mode context of the process initiating the system call, the system call requests and call context information initiated by the target application in user mode are collected; By monitoring the execution process of the system call request in kernel mode, the type, parameters, return value, and timestamp of the system call made by the target application in kernel mode are collected; The call context information is associated and integrated with the type, parameters, return value, and timestamp of the system call to generate time-seriesd system call data.

3. The method according to claim 1, characterized in that, The system call data includes system call records collected at different time points; after collecting system call data of the target application in user mode and kernel mode, the method further includes: Remove invalid system call records generated spontaneously by the operating system kernel, and filter system call records with the same parameters that are repeated consecutively; The system call parameters are converted into a predefined uniform format, and the system call records are sorted chronologically according to timestamps.

4. The method according to claim 1, characterized in that, For the system call data, basic statistical features representing the statistical regularity of the calls and deep sequence features representing the correlation between the calls are extracted respectively to form a system call feature set, including: Within a preset time window, the call frequency of various types of system calls, the proportion of risky system calls, and the value distribution of parameters under the same system call type are statistically analyzed to obtain the basic statistical characteristics. The system call sequence is extracted from the system call data by a frequent itemset mining algorithm, the information entropy value of the system call sequence is calculated, and the parameter correlation of different system calls of the same process is analyzed. The system call sequence, the information entropy value and the parameter correlation constitute the deep sequence feature.

5. The method according to claim 1, characterized in that, Behavior detection models trained based on a normal behavior feature database include: Collect system call characteristics of at least two types of normal applications in different scenarios, and construct the normal behavior feature library; The behavior detection model is trained based on the normal behavior feature library; the behavior detection model is an isolated forest model or an autoencoder model.

6. The method according to claim 1, characterized in that, The determination result is either normal or abnormal; After inputting the system call feature set into a behavior detection model trained based on a normal behavior feature library for analysis and obtaining the behavior detection results, the method further includes: When the determination result is abnormal, risk scores of at least two dimensions of risk quantification indicators are determined based on the system call feature set. Based on the weights corresponding to at least two preset risk quantification indicators, the risk scores of the at least two risk quantification indicators are weighted and calculated to generate a quantitative measurement report containing a comprehensive risk value.

7. The method according to claim 6, characterized in that, The risk quantification indicators, which have at least two dimensions, include: the frequency of occurrence of abnormal sequences, the proportion of risky calls, and the behavioral deviation output by the behavioral detection model. The step of weighting the risk scores of the at least two dimensions of risk quantification indicators according to their corresponding weights, and generating a quantitative measurement report containing a comprehensive risk value, includes: The first value is determined by multiplying the risk score corresponding to the frequency of occurrence of the abnormal sequence with its weight. The product of the risk score and weight corresponding to the risk call percentage is determined as the second value; The product of the risk score and weight corresponding to the deviation of the behavior is determined as the third value; The sum of the first value, the second value, and the third value is determined as the comprehensive risk value, and a quantitative measurement report is generated.

8. A behavior detection system for an application, characterized in that, The system includes: The data acquisition module is used to collect system call data of the target application in user mode and kernel mode; The feature extraction module is used to extract basic statistical features that characterize the statistical regularity of the calls and deep sequence features that characterize the correlation between the calls for the system call data, thereby forming a system call feature set; The result output module is used to input the system call feature set into the behavior detection model trained based on the normal behavior feature library for analysis, and obtain the behavior detection result; wherein, the behavior detection result includes the anomaly judgment result and the anomaly type.

9. An electronic device, characterized in that, The method includes a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images