Malicious load identification method based on load event detection

Abstract

This invention discloses a method for identifying malicious load based on load event detection, belonging to the field of malicious load detection technology. The method includes capturing the resource consumption behavior of computing entities to form a raw runtime load sequence containing multiple indicators; separating load event fragments that conform to preset triggering patterns through event pattern matching to obtain a preliminary load event set; extracting feature vectors from each event fragment; reconstructing a standardized load behavior time-series graph according to event evolution rules using a behavior sequence reconstruction model; comparing the graph with samples from a malicious behavior knowledge base and calculating the matching degree score; and generating a malicious load identification conclusion through threshold judgment and aggregation analysis. This method achieves accurate identification of malicious loads through event fragment separation and time-series graph reconstruction, and is suitable for malicious load detection scenarios during the runtime of computing entities.

Description

Technical Field

[0001] This invention belongs to the field of malicious load detection technology, specifically a malicious load identification method based on load event detection. Background Technology

[0002] Current technologies for identifying malicious loads on computing entities mostly involve directly collecting resource consumption data during the entity's operation. Malicious load determination is achieved through single-indicator threshold judgment, global feature extraction and classification, or direct full-sequence matching. These technologies analyze the complete original load sequence without performing event-level pattern matching or segmentation. Existing identification schemes only perform vector-level direct classification or comparison of extracted load features, without incorporating event evolution rules for structured reconstruction. The comparison with malicious behavior samples remains at the discrete feature level.

[0003] Existing identification methods are susceptible to interference from normal load fluctuations, failing to accurately filter load segments with abnormal triggering characteristics from the original load sequence, resulting in high redundancy in the analyzed objects. Discrete feature comparison cannot reflect the temporal evolution correlation of load events, and the matching with malicious behavior pattern samples lacks complete temporal structure support. The matching degree calculation is only carried out on a single feature dimension, and the threshold judgment and analysis process do not incorporate temporal structure aggregation processing, making it difficult to form malicious load identification results with temporal coherence. It is impossible to achieve preset triggering pattern matching and load event segment separation for the original runtime load sequence of multiple resource consumption indicators, nor can it reconstruct the load event feature vector into a standardized load behavior temporal map according to preset event evolution rules. Summary of the Invention

[0004] This invention aims to solve at least one of the technical problems existing in the prior art; Therefore, this invention proposes a malicious load identification method based on load event detection, including: Capture the resource consumption behavior sequence of computing entities in the runtime environment to form the original runtime load sequence, which includes readings of various resource consumption indicators in the time dimension; Event pattern matching is performed on the original runtime load sequence to identify load event fragments that conform to a preset triggering pattern, and a preliminary load event set is separated from the original runtime load sequence. The event feature vector of each load event segment in the preliminary load event set is extracted, and the event feature vector is fed into the behavior sequence reconstruction model. The behavior sequence reconstruction model reconstructs the event feature vector into a normalized load behavior time series graph according to the preset event evolution rules. The malicious behavior knowledge base stores sample behavioral patterns of known malicious loads. The malicious behavior knowledge base stores sample behavioral patterns of known malicious loads. Based on the results of the pattern comparison, the matching degree between the load behavior time series graph and each behavior pattern sample in the malicious behavior knowledge base is calculated, and a matching degree score list is generated. Threshold decision and aggregation analysis are performed on the matching score list to generate a malicious load identification conclusion for the detected computational entity.

[0005] Furthermore, the step of capturing the resource consumption behavior sequence of computing entities in the runtime environment to form the original runtime load sequence includes: A lightweight probe is deployed on the host machine of the monitored computing entity, and the lightweight probe obtains the resource consumption index readings of the computing entity from the operating system kernel at a fixed sampling frequency. The resource consumption metrics readings include at least the CPU utilization, memory usage, disk read / write frequency, and number of network connections. The lightweight probe appends a high-precision timestamp to the acquired resource consumption index readings and caches them in memory in chronological order. When the cached data reaches the preset batch size, or when the capture operation of the original runtime load sequence is explicitly terminated, the cached timestamped resource consumption index readings are output as a continuous original runtime load sequence.

[0006] Further, event pattern matching is performed on the original runtime load sequence to identify load event segments that conform to a preset triggering pattern, including: Within a preset time window, continuously monitor the CPU utilization index in the original runtime load sequence; When the central processing unit utilization rate exceeds the preset high water level threshold, it is marked as the event start point; Starting from the event start point, the original runtime load sequence is recorded until the CPU utilization index falls below a preset low water level threshold. The complete data record between the start point and the fall point is marked as a load event segment. For all the marked load event segments, verify whether their duration and peak resource consumption meet the minimum event strength constraint, and include the load event segments that pass the verification into the preliminary load event set.

[0007] Further, the event feature vector of each load event segment in the preliminary load event set is extracted, including: The event feature vector includes the resource consumption curve within the event, the interval sequence between events, and the count of concurrent events; For each load event segment, calculate the statistics of resource consumption indicators within the segment as a function of time, including the average, variance, peak, and trough values, to form the resource consumption curve within the event. Calculate the time interval between the current load event segment and the historical load event segments, and form the event interval sequence by combining multiple consecutive time intervals; The number of other load event segments that overlap or are adjacent to the current load event segment in time within a preset neighborhood time window is counted and used as the concurrent event count; The resource consumption curve within the event, the interval sequence between events, and the concurrent event count are normalized and concatenated to form the event feature vector.

[0008] Further, the event feature vector is fed into a behavior sequence reconstruction model, which reconstructs the event feature vector into a normalized load behavior time series graph according to preset event evolution rules, including: The behavior sequence reconstruction model includes an encoding layer, an evolutionary layer, and a graphing layer; The coding layer receives the event feature vector and encodes the event feature vector into an initial event state; The evolution layer simulates the state transition of the initial event state at multiple virtual time steps according to the preset event evolution rules. The preset event evolution rules define the transition probabilities and conditions between different event states. The graphing layer collects the event states generated by the evolution layer at all virtual time steps, maps each event state to a node in the graph, and adds directed edges between graph nodes according to the transition relationship between event states to form the normalized load behavior time sequence graph.

[0009] Furthermore, a malicious behavior knowledge base is used to perform pattern comparison on the time-series graph of the load behavior, including: The stored behavior pattern samples are read one by one from the malicious behavior knowledge base, and each behavior pattern sample is also stored in the form of a load behavior time sequence graph. The normalized load behavior time sequence graph is matched with the behavior pattern sample graph read from the malicious behavior knowledge base. In the process of subgraph isomorphism matching, the similarity between two graphs is compared in terms of node attributes, number of nodes, edge relationships, and connection topology. Record the similarity measurement results generated from each comparison, and use these similarity measurement results as the basis for subsequent calculation of the matching degree.

[0010] Furthermore, based on the results of the pattern comparison, the matching degree between the load behavior time series graph and each behavior pattern sample in the malicious behavior knowledge base is calculated, and a matching degree score list is generated, including: For each behavior pattern sample in the malicious behavior knowledge base, a set of corresponding similarity measurement results is obtained from the pattern comparison process; Weights are assigned to each measurement result in the similarity measurement result set, and the weights are determined by a preset weight configuration parameter table; Based on the assigned weights, the similarity measurement result set is weighted and fused to calculate a comprehensive matching score; Traverse all behavior pattern samples in the malicious behavior knowledge base, repeatedly perform weighted fusion calculations to obtain a matching score corresponding to each behavior pattern sample, arrange the matching scores in order, and generate the matching score list.

[0011] Furthermore, threshold decision and aggregation analysis are performed on the matching score list to generate a malicious load identification conclusion for the detected computational entity, including: The malicious load identification conclusion includes a maliciousness level rating and a corresponding behavioral pattern identifier. A decision threshold is set for each matching score in the matching score list, and the decision threshold is determined based on the confidence level of the corresponding behavioral pattern sample; Each matching score is compared with the corresponding decision threshold, and matching scores that exceed the decision threshold and their associated behavioral pattern samples are marked. The labeled behavioral pattern samples are sorted according to their corresponding matching scores, and a preset number of behavioral pattern samples with the highest matching scores are selected as candidate malicious patterns. Based on the type distribution and score concentration of the candidate malicious patterns, the malicious level rating is calculated, and the identifiers of the candidate malicious patterns are summarized into the behavior pattern identifier.

[0012] Furthermore, after generating the malicious load identification conclusion for the detected computational entity, a feedback learning step is also included, which includes: Obtain external input verification feedback regarding the malicious load identification conclusion, wherein the verification feedback confirms that the true attribute of the detected computing entity is malicious or benign; The load behavior time series graph, the malignant load identification conclusion, and the verification feedback are associated and stored to form labeled sample data; The malicious behavior knowledge base is incrementally updated using the labeled sample data, specifically including: when the verification feedback confirms that the behavior is malicious and there are no highly similar samples in the behavior pattern sample base, the load behavior time series graph is stored as a new behavior pattern sample in the malicious behavior knowledge base.

[0013] Furthermore, it also includes formatting the malignant load identification conclusion into a standard report, specifically: Extract the malicious level rating and behavior pattern identifier from the malicious load identification conclusion, and associate them with the identification information of the detected computing entity; According to the preset report template, the maliciousness level rating is mapped to a level description, and the behavior pattern identifier is mapped to a behavior pattern name; Fill in the corresponding fields of the report template with the level description, the behavior pattern name, the identification information of the detected computing entity, and the start and end times of the load event detection; The completed report template is converted into a file in a specified format. The standard report contains a readable text summary and data fields that can be parsed by machines.

[0014] Compared with the prior art, the beneficial effects of the present invention are: Event pattern matching is performed on the raw runtime load sequence containing multiple resource consumption index readings across the time dimension to identify load event segments that conform to preset triggering patterns. A preliminary load event set is separated from the raw runtime load sequence, filtering out routine load data lacking triggering characteristics, reducing the analytical scope for malicious load identification, isolating the impact of normal load fluctuations on the anomaly identification process, and enabling independent location of abnormal load segments. This transforms full-sequence-level analysis into event segment-level analysis, reducing the processing complexity of the feature extraction stage. Event feature vectors are extracted from each load event segment in the preliminary load event set and fed into a behavior sequence reconstruction model. According to preset event evolution rules, the event feature vectors are reconstructed into a standardized load behavior time-series graph. This transforms discrete event feature vectors into a structured graph with temporal correlations, explicitly revealing the temporal evolutionary relationships of load events. This provides a temporal structure carrier for pattern comparison between load behavior and malicious behavior knowledge base samples, ensuring that pattern comparison covers the complete evolution process of load events. Matching degree calculation is based on the overall structure of the time-series graph, and the matching results possess temporal completeness. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating the steps of the malicious load identification method based on load event detection described in this invention. Figure 2 This is a monitoring graph showing the starting point of the original runtime load sequence events. Figure 3 A flowchart for extracting event feature vectors; Figure 4 This is a graph showing the matching degree of malicious behavior patterns and the threshold judgment results; Figure 5 This is a graph showing the original runtime load sequence. Detailed Implementation

[0016] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and 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.

[0017] See Figure 1 This invention provides a method for identifying malicious load based on load event detection. The overall implementation scheme is as follows: A resource consumption behavior sequence of a computing entity is captured in the runtime environment to form an original runtime load sequence, which includes readings of various resource consumption indicators over time. Event pattern matching is performed on the original runtime load sequence to identify load event segments that conform to a preset triggering pattern, thus separating a preliminary load event set from the original runtime load sequence. Event feature vectors are extracted from each load event segment in the preliminary load event set and fed into a behavior sequence reconstruction model. The behavior sequence reconstruction model reconstructs the event feature vectors into a standardized load behavior time-series graph according to preset event evolution rules. A malicious behavior knowledge base is used to perform pattern comparison on the load behavior time-series graph. The malicious behavior knowledge base stores known malicious load behavior pattern samples. Based on the pattern comparison results, the matching degree between the load behavior time-series graph and each behavior pattern sample in the malicious behavior knowledge base is calculated, generating a matching degree score list. Threshold judgment and aggregation analysis are performed on the matching degree score list to generate a malicious load identification conclusion for the detected computing entity.

[0018] In one embodiment of the invention, a lightweight probe is deployed on the host machine of the monitored computing entity. The lightweight probe acquires resource consumption metric readings of the computing entity from the operating system kernel at a fixed sampling frequency. These resource consumption metric readings include at least CPU utilization, memory usage, disk read / write frequency, and network connection count. The lightweight probe appends high-precision timestamps to the acquired resource consumption metric readings and caches them in memory in chronological order. When the cached data reaches a preset batch size, or when the capture operation of the original runtime load sequence is explicitly terminated, the cached timestamped resource consumption metric readings are output as a continuous original runtime load sequence.

[0019] In practice, a lightweight probe is deployed on the host machine of the monitored computing entity. This lightweight probe obtains resource consumption metrics readings from the operating system kernel at a fixed sampling frequency. The fixed sampling frequency can be configured according to the monitoring granularity requirements, for example, set to collect data once per second or once per millisecond. The lightweight probe obtains raw data by directly reading the process status interface and system performance counters exposed by the operating system kernel. In some embodiments, the lightweight probe runs as a kernel module or privileged process, thereby achieving direct access to low-level system resource information.

[0020] Resource consumption metrics readings include at least CPU utilization, memory usage, disk I / O frequency, and network connections. CPU utilization is the percentage of CPU time slices occupied by the computational entity during the sampling period. Memory usage is the size of the working set of the computational entity residing in physical memory at the sampling time. Disk I / O frequency is the number of disk I / O operations initiated by the computational entity during the sampling period. Network connections are the total number of active Transmission Control Protocol (TCP) connections and User Datagram Protocol (UDP) sockets held by the computational entity at the sampling time. It is understood that the set of resource consumption metrics readings can be expanded according to detection needs, for example, by adding GPU utilization or the frequency of specific file operations.

[0021] The lightweight probe appends high-precision timestamps to the acquired resource consumption metric readings and caches them in memory in chronological order. The high-precision timestamps originate from the host system's monotonic clock or a clock synchronized via a network time protocol, achieving microsecond-level accuracy. Each set of resource consumption metric readings with an appended high-precision timestamp constitutes a data unit. In practice, these data units are sequentially appended to a circular buffer or FIFO queue maintained by the lightweight probe, located in the host's user-space or kernel-space memory. The purpose of memory caching is to reduce frequent I / O operations to persistent storage, thereby minimizing the performance overhead of the monitoring activity itself on system runtime.

[0022] When the cached data reaches the preset batch size, or when the capture operation of the original runtime load sequence is explicitly terminated, the cached timestamped resource consumption metric readings are output as a continuous original runtime load sequence. The preset batch size can be a fixed number of data units or a dynamic threshold based on memory usage. In a specific implementation, a calculation method for determining the batch size is shown in the formula: Where: symbol This indicates the preset batch size, expressed in units of data units. (Symbol) This indicates the upper limit of the memory region pre-allocated for caching by lightweight probes. (Symbol) Indicates the average size of a single data unit. (Symbol) This represents the host machine's average system load factor. It's a floating-point number between 0 and 1, used to dynamically reduce batch sizes during high system loads to output data more frequently, thereby freeing up memory. When the number of cached resource consumption metric readings reaches... The lightweight probe outputs all timestamped resource consumption metric readings in memory as a data batch. The output data batch is represented as an ordered list or a time-series array; this data batch is the raw runtime load sequence. Optionally, the raw runtime load sequence can be written to a local file, sent to a remote analytics server, or published to a message broker. If the capture operation is explicitly terminated, such as upon receiving a stop monitoring command, the lightweight probe immediately outputs all cached data units in memory as the final raw runtime load sequence, without waiting for the preset batch size to be reached.

[0023] In one embodiment of the present invention, the CPU utilization index in the original runtime load sequence is continuously monitored within a preset time window. When the CPU utilization index exceeds a preset high-water mark threshold, it is marked as the event start point. Starting from the event start point, the original runtime load sequence is recorded until the CPU utilization index falls back below the preset low-water mark threshold. The complete data record between the start point and the fallback point is marked as a load event segment. For all marked load event segments, their duration and peak resource consumption are verified to meet the minimum event intensity constraint. Load event segments that pass the verification are included in the initial load event set.

[0024] In practice, the CPU utilization metric in the original runtime load sequence is continuously monitored within a preset time window. The preset time window defines the time span for the event pattern matching process to continuously scan the original runtime load sequence, for example, set to five or ten minutes. The monitoring process uses individual data units of the original runtime load sequence as the basic processing unit, sequentially checking the CPU utilization field in each data unit according to the order of its high-precision timestamp. It can be understood that the monitoring process can stream the original runtime load sequence in memory, without waiting for the complete original runtime load sequence to be generated before starting processing.

[0025] When the CPU utilization metric exceeds a preset high-water mark threshold, it is marked as the start point of an event. The high-water mark threshold is an absolute percentage, such as 70% CPU utilization. In some embodiments, the high-water mark threshold can be dynamically adjusted based on the historical baseline of the computing entity, but for clarity, a fixed threshold is used here. The monitoring logic compares the CPU utilization reading of the current data unit with the high-water mark threshold. Once the CPU utilization reading is greater than the high-water mark threshold, the high-precision timestamp corresponding to that data unit is recorded as the timestamp of the event start point. In a specific implementation, a new, empty data structure is created simultaneously with marking the event start point for subsequent recording of load event segments.

[0026] Starting from the event start point, the original runtime load sequence is recorded until the CPU utilization metric falls below a preset low-water mark threshold. The complete data record between the start point and the fall point is marked as a load event segment. The low-water mark threshold is another absolute percentage; for example, if CPU utilization is 30%, the low-water mark threshold is lower than the high-water mark threshold. Once the event start point is marked, the monitoring logic enters segment recording mode. In segment recording mode, each subsequent data unit in the original runtime load sequence (including CPU utilization and all other resource consumption metric readings) is appended to the data structure created for the current load event segment. The recording process continues until a data unit is encountered whose CPU utilization reading is below the preset low-water mark threshold; at this point, the timestamp of that data unit is marked as the event fall point. All ordered data units recorded from the event start point to the event fall point (including the data units corresponding to the start and fall points) together constitute a complete load event segment. Optionally, a stability condition can be added to the determination of the fallback point, such as requiring the CPU utilization reading to be continuously below the low water level threshold for several sampling cycles, in order to prevent the event segment from ending prematurely due to noise fluctuations.

[0027] For all marked load event segments, verify whether their duration and peak resource consumption meet the minimum event strength constraint. Include the verified load event segments in the initial load event set. The minimum event strength constraint includes requirements for lower limits on duration and peak resource consumption. The duration of a load event segment is calculated by subtracting the event start time stamp from the event fallback time stamp. The peak resource consumption of a load event segment refers to the maximum CPU utilization reading among all data units covered by that segment. The verification process is completed by comparing these two calculated values ​​with preset constraint thresholds. In one specific implementation, the verification logic can use the judgment condition shown in the formula: Where: symbol Indicates the calculated duration of the load event segment, symbol This indicates the preset minimum duration threshold. (Symbol) Represents the peak CPU utilization within the calculated load event segment, symbol [symbol missing]. This represents the preset minimum peak resource consumption threshold. Logical operator " The "AND" sign indicates an AND relationship. This applies only when the duration of the load event fragment is specified. Not less than And its peak resource consumption Not less than Only when the minimum event strength constraint is met is the load event segment considered to satisfy the constraint. All load event segments that satisfy the constraint are collected to form an initial load event set. In some embodiments, short or weak activity segments that do not satisfy the constraint are discarded directly and are not processed as potential events.

[0028] See Figure 2 This is a monitoring chart of the original runtime load sequence event start points. The red event start points are the only anchor points for subsequent extraction of event feature vectors. Without this visualization step, feature extraction would lose its traceability. The first start point is approximately 40 seconds in, when the CPU recovers from a trough and first exceeds the high-water threshold, triggering an event. The second start point is approximately 100 seconds in, when the CPU recovers from the negative range and exceeds the threshold, triggering an event. The third start point is approximately 160 seconds in, when the CPU recovers from a trough and exceeds the threshold, triggering an event. By observing the matching degree between the start point distribution and CPU fluctuations, threshold parameters can be quickly optimized, improving the robustness of event detection. When an abnormal event occurs, the CPU fluctuation corresponding to the event start point can be quickly located, and the cause of the load can be analyzed in conjunction with other resource indicators.

[0029] In one embodiment of the present invention, see [reference] Figure 3The event feature vector includes the resource consumption curve within the event, the interval sequence between events, and the concurrent event count. For each load event segment, the statistics of resource consumption indicators changing over time within the segment are calculated, including the mean, variance, peak, and trough, forming the resource consumption curve within the event. The time interval between the current load event segment and historical load event segments is calculated, and multiple consecutive time intervals are combined into an interval sequence between events. The number of other load event segments that overlap or are adjacent to the current load event segment in time within a preset neighborhood time window is counted as the concurrent event count. The resource consumption curve within the event, the interval sequence between events, and the concurrent event count are normalized and concatenated to form the event feature vector. The behavior sequence reconstruction model includes an encoding layer, an evolution layer, and a graphing layer. The encoding layer receives the event feature vector and encodes it into an initial event state. The evolution layer simulates the state transition of the initial event state at multiple virtual time steps according to preset event evolution rules, which define the transition probabilities and conditions between different event states. The graph layer collects the event states generated by the evolution layer at all virtual time steps, maps each event state to a node in the graph, and adds directed edges between graph nodes according to the transition relationships between event states, forming a normalized load behavior time sequence graph.

[0030] In practical implementation, the event feature vector includes the resource consumption curve within the event, the interval sequence between events, and the concurrent event count. For each load event segment in the initial load event set, these three types of features need to be extracted separately. For each load event segment, the statistics of resource consumption indicators changing over time within the segment are calculated. These statistics include the mean, variance, peak, and trough. The set of these statistics forms the resource consumption curve within the event. The calculation process traverses all ordered data units contained in the load event segment. For the four resource consumption indicators—CPU utilization, memory usage, disk read / write frequency, and network connection count—the mean, variance, maximum (peak), and minimum (trough) values ​​are calculated independently over the entire segment's time span. Taking CPU utilization as an example, its resource consumption curve within the event consists of four scalar values: the segment's average CPU utilization, the segment's variance of CPU utilization, the segment's peak CPU utilization, and the segment's trough CPU utilization. Refer to Table 1, which shows partial data of the resource consumption curve within an example load event segment.

[0031] Table 1: Resource Consumption Curves within Load Event Segments Calculate the time interval between the current load event segment and historical load event segments, and form a sequence of consecutive time intervals into an inter-event interval sequence. A historical load event segment refers to one or more load event segments that have been processed and included in the initial load event set before the current load event segment, and are the closest in time. The time interval is defined as the absolute value of the difference between the event start timestamp of the current load event segment and the event start timestamp of the previous load event segment. For the i-th load event segment in the initial load event set, the time interval between it and the previous segment is... Calculate using the formula: Where: symbol This represents the time interval between the i-th load event segment and the (i-1)-th load event segment. (Symbol) This represents the timestamp of the start point of the i-th load event segment. (Symbol) This represents the timestamp of the start point of the (i-1)th load event segment. Following this method, the time intervals are calculated for each load event segment starting from the second in the initial load event set; these time intervals are arranged in chronological order. This constitutes the sequence of event intervals. For the first load event segment, the event interval can be set to a default value or left blank.

[0032] The number of other load event segments that overlap or are adjacent to the current load event segment in time within a preset neighborhood time window is counted as the concurrent event count. The preset neighborhood time window is centered on the event start point of the current load event segment and extends forward and backward by a fixed time length. In some embodiments, the length of the neighborhood time window may be associated with the average duration of the load event segments. During the count, all segments in the initial load event set other than the current load event segment are examined. If the event start point or event fall point of a segment falls within the neighborhood time window of the current segment, or if the two segments overlap in time intervals, then the segment is determined to be concurrent with the current segment. The total number of segments that meet the concurrency condition is the concurrent event count of the current load event segment. It can be understood that the concurrent event count reflects the density of multiple resource consumption events occurring in the system within a short period of time.

[0033] The resource consumption curve within an event, the interval sequence between events, and the concurrent event count are normalized and concatenated to form the event feature vector. Normalization maps the original feature values ​​of different dimensions and ranges to a unified numerical interval, such as [0,1]. Each statistic in the resource consumption curve within an event, each time interval value in the interval sequence between events, and the concurrent event count are normalized independently. In practice, the min-max normalization method can be used. After normalizing all components, these normalized values ​​are concatenated into a one-dimensional vector in a fixed order; this one-dimensional vector is the final event feature vector. The behavior sequence reconstruction model includes an encoding layer, an evolutionary layer, and a graphing layer. The encoding layer receives the event feature vector and encodes it into an initial event state. The encoding layer is typically a feedforward neural network or a linear transformation layer. It learns to map the high-dimensional event feature vector to a low-dimensional, dense vector representation, which is the initial event state. The initial event state carries the abstract semantic information of the event fragments. The evolution layer simulates the state transitions of the initial event state across multiple virtual time steps according to preset event evolution rules. These rules define the probabilities and conditions for transitions between different event states. The event evolution rules can be modeled as a state transition matrix or a recurrent neural network unit. Each element in the state transition matrix defines a fixed probability of transitioning from one event state to another. In practice, the evolution layer uses the initial event state output by the encoding layer as the state of the first virtual time step, and then recursively calculates the states of subsequent virtual time steps based on the state transition matrix. Each state transition can be viewed as a simulation of the possible temporal evolution of load behavior. The graphing layer collects the event states generated by the evolution layer across all virtual time steps, maps each event state to a node in the graph, and adds directed edges between graph nodes according to the transition relationships between event states, forming a standardized temporal graph of load behavior. The graphing layer assigns a unique node identifier to the event state vector generated for each virtual time step (including the initial step). Node attributes are filled with the corresponding event state vector values. Any two consecutive event states in virtual time, such as the state at step k and the state at step k+1, are connected by a directed edge between their corresponding nodes in the graph. The edge points from the node representing the earlier time step to the node representing the later time step. Optionally, the directed edge can have weights derived from the corresponding transition probabilities in the state transition matrix. In this way, a linear state transition sequence is transformed into a graph structure with nodes and edges, i.e., a normalized load behavior time series graph.

[0034] In one embodiment of the present invention, stored behavior pattern samples are read one by one from a malicious behavior knowledge base, each behavior pattern sample being stored in the form of a load behavior time series graph. The normalized load behavior time series graph is then subjected to subgraph isomorphic matching with the behavior pattern sample graph read from the malicious behavior knowledge base. During subgraph isomorphic matching, the similarity between the two graphs in terms of node attributes, number of nodes, edge relationships, and connection topology is compared. The similarity measurement results generated in each comparison are recorded, and these results serve as the basis for subsequent matching degree calculations. For each behavior pattern sample in the malicious behavior knowledge base, a corresponding set of similarity measurement results is obtained from the pattern comparison process. Weights are assigned to each measurement result in the set of similarity measurement results, determined by a preset weight configuration parameter table. Based on the assigned weights, the set of similarity measurement results is weighted and fused to calculate a comprehensive matching degree score. This weighted fusion calculation is repeated for all behavior pattern samples in the malicious behavior knowledge base to obtain a matching degree score corresponding to each behavior pattern sample. The matching degree scores are then arranged in order to generate a matching degree score list. The malicious load identification conclusion includes a malicious level rating and the corresponding behavior pattern identifier. A decision threshold is set for each match score in the match score list. The decision threshold is determined based on the confidence level of the corresponding behavioral pattern sample. Each match score is compared with its corresponding decision threshold, and match scores exceeding the decision threshold and their associated behavioral pattern samples are marked. The marked behavioral pattern samples are sorted according to their corresponding match scores, and a predetermined number of behavioral pattern samples with the highest match scores are selected as candidate malicious patterns. Based on the type distribution and score concentration of the candidate malicious patterns, a malicious level rating is calculated, and the identifiers of the candidate malicious patterns are aggregated into a behavioral pattern identifier.

[0035] In practice, behavioral pattern samples are read one by one from the malicious behavior knowledge base. Each behavioral pattern sample is also stored in the form of a load behavior time-series graph. The malicious behavior knowledge base can be a local database or a remote knowledge graph service, where each record corresponds to a known malicious load behavior pattern. The reading process traverses the index of the malicious behavior knowledge base, sequentially retrieving the graph data for each behavioral pattern sample. The graph data includes a list of nodes, a set of node attributes, a list of edges, and the relational attributes of the edges. It can be understood that the behavioral pattern sample graph is a standardized load behavior time-series graph pre-generated by abstracting and modeling known malicious load behaviors.

[0036] The normalized load behavior time-series graph is matched with a behavior pattern sample graph retrieved from a malicious behavior knowledge base using subgraph isomorphic matching. Subgraph isomorphic matching is a graph theory algorithm used to determine whether a graph (here, the normalized load behavior time-series graph) has the same structure as a subgraph of another larger graph (here, the behavior pattern sample graph). In practice, graph isomorphism algorithms (such as the Ullmann algorithm, VF2 algorithm, or their variants) are used to calculate possible mappings between the normalized load behavior time-series graph and the behavior pattern sample graph. The matching process attempts to find a subgraph in the behavior pattern sample graph that completely corresponds to the normalized load behavior time-series graph in terms of the number of nodes and connections.

[0037] In subgraph isomorphic matching, the similarity between two graphs is compared in terms of node attributes, number of nodes, edge relationships, and connectivity topology. Node attribute comparison involves calculating the similarity of corresponding node state vectors, for example, using cosine similarity or Euclidean distance. Node number similarity is evaluated by comparing the total number of nodes in both graphs. Edge relationship comparison checks whether corresponding edges have the same or compatible direction and type (if defined). Connectivity topology similarity assesses whether the overall shape or path pattern of the two graphs is consistent. While searching for mappings, the subgraph isomorphic matching algorithm outputs a series of local similarity scores across these dimensions.

[0038] The similarity measurement results generated from each comparison are recorded and used as the basis for subsequent matching degree calculations. The similarity measurement results are a set containing quantified scores generated from comparisons across multiple dimensions, including node attributes, node count, edge relationships, and connection topology. In practice, each comparison of a normalized load behavior time series graph with a behavior pattern sample graph generates a corresponding set of similarity measurement results. This set is temporarily stored and associated with the identifier of the currently compared behavior pattern sample. See Table 2, which shows an example set of similarity measurement results.

[0039] Table 2: Similarity Measurement Results of Comparison with Samples of a Certain Behavioral Pattern For each behavior pattern sample in the malicious behavior knowledge base, the corresponding similarity measurement result set is obtained from the pattern comparison process. The acquisition operation is performed sequentially. After each comparison between the normalized load behavior time series graph and a behavior pattern sample graph is completed, the similarity measurement result set generated by that comparison is immediately acquired and saved.

[0040] Weights are assigned to each similarity measurement result in the set, with the weights determined by a pre-defined weight configuration parameter table. Experts determine the importance of each comparison dimension for identifying different malicious behavior patterns based on prior knowledge or historical data analysis. For example, node attribute similarity may be more important for identifying malicious loads with specific resource consumption patterns, and therefore is given a higher weight; while topology may be more critical for identifying malicious loads with specific execution flows. The weights are stored in the form of a vector, with each weight value corresponding to a measurement result in the similarity measurement result set. In one implementation, the weight vector is statically configured; in other embodiments, the weight vector can be dynamically selected based on the type of behavior pattern sample.

[0041] Based on the assigned weights, the similarity measurement results are weighted and fused to calculate a comprehensive matching score. The weighted fusion is calculated using the following formula: Where: symbol This represents the calculated overall match score. (Symbol) This represents the total number of similarity measurement results in the set. (Symbol) Indicates the preset, corresponding to the first The weight of each metric result. (Symbol) Represents the first in the set of similarity measurement results. The summation operation adds the products of all weights and their corresponding metrics to obtain a matching score between 0 and 1. A higher score indicates a higher degree of similarity.

[0042] The algorithm iterates through all behavior pattern samples in the malicious behavior knowledge base, repeatedly performing weighted fusion calculations to obtain a matching score for each behavior pattern sample. These matching scores are then sorted to generate a matching score list. After the iteration is complete, a list is obtained where each item contains a unique identifier for a behavior pattern sample and its corresponding matching score. It's understandable that the match score list is usually arranged in descending order of score to facilitate subsequent processing.

[0043] The malicious payload identification result includes a maliciousness level rating and a corresponding behavioral pattern identifier. A decision threshold is set for each match score in the match score list, and the decision threshold is determined based on the confidence level of the corresponding behavioral pattern sample. In the malicious behavior knowledge base, each behavioral pattern sample can be associated with a confidence level, such as "high," "medium," or "low." Different confidence levels correspond to different decision thresholds; high-confidence samples may have a lower decision threshold set to increase sensitivity, while low-confidence samples have a higher decision threshold set to reduce false alarms. The decision threshold is a value between 0 and 1.

[0044] Each matching score is compared to its corresponding decision threshold, and matching scores exceeding the threshold and their associated behavioral pattern samples are marked. The comparison operation iterates through the list of matching scores, and if a certain matching score... The decision threshold is greater than or equal to the corresponding behavioral pattern sample. That is, satisfying If the matching score is high, then the matching score and its associated behavioral pattern sample are marked as candidates.

[0045] The identified behavioral pattern samples are sorted according to their corresponding matching scores, and a predetermined number of behavioral pattern samples with the highest matching scores are selected as candidate malicious patterns. This predetermined number can be a fixed value, such as 3 or 5. The sorting is done in descending order of matching scores, and then the top N (N being the predetermined number) behavioral pattern samples are extracted from the sorted list. These selected behavioral pattern samples are considered candidate malicious patterns, representing several known malicious patterns most similar to the behavior of the currently detected computational entity.

[0046] Based on the type distribution and score concentration of candidate malicious patterns, a maliciousness rating is calculated, and the identifiers of the candidate malicious patterns are aggregated into a behavioral pattern identifier. The maliciousness rating is a comprehensive score, such as "high risk," "medium risk," or "low risk." Type distribution examines the diversity of malware families or attack types to which the candidate malicious patterns belong. Score concentration examines the degree of difference in matching scores among the top candidate malicious patterns. The maliciousness rating can be calculated using a predefined decision function, whose inputs include type distribution information, score concentration information, and the original matching scores of each candidate malicious pattern. The behavioral pattern identifier is a list of unique identifiers (e.g., pattern ID or pattern name) of the selected candidate malicious patterns. In some embodiments, the behavioral pattern identifier can directly use the identifier of the candidate malicious pattern with the highest score. Optionally, the maliciousness rating and behavioral pattern identifier together constitute the core content of the malicious payload identification conclusion.

[0047] See Figure 4This is a chart showing the matching degree and threshold judgment results of malicious behavior patterns. It visually displays the matching degree between the payload to be detected and eight known malicious patterns, as well as the confidence judgment threshold for each pattern. The matching degree score shows a clear downward trend from malicious pattern 1 to malicious pattern 8, indicating that the payload to be detected has a higher behavioral similarity to the previous malicious patterns. The matching degree scores of the first five malicious patterns (patterns 1-5) are all ≥ the corresponding confidence thresholds and are marked as candidate malicious patterns. The last three malicious patterns (patterns 6-8) are judged to have no significant malicious behavior association because their scores are below the threshold. Malicious pattern 1 has the highest matching degree (0.89) and is currently the most suspicious malicious behavior pattern. Patterns 4 and 5 are in the threshold critical zone and need to be further verified with more context to avoid false positives. This quickly screens out high-risk candidate malicious patterns, providing a data foundation for subsequent malicious level rating.

[0048] In one embodiment of the present invention, externally inputted verification feedback on the malicious load identification conclusion is obtained, confirming that the true attribute of the detected computing entity is malicious or benign. The load behavior time-series graph, the malicious load identification conclusion, and the verification feedback are associated and stored to form labeled sample data. The labeled sample data is used to incrementally update the malicious behavior knowledge base, specifically including: when the verification feedback confirms maliciousness and there are no highly similar samples in the behavior pattern sample library, the load behavior time-series graph is stored as a new behavior pattern sample in the malicious behavior knowledge base. The maliciousness level rating and behavior pattern identifier are extracted from the malicious load identification conclusion and associated with the identification information of the detected computing entity. According to a preset report template, the maliciousness level rating is mapped to a level description, and the behavior pattern identifier is mapped to a behavior pattern name. The level description, behavior pattern name, identification information of the detected computing entity, and the start and end times of the load event detection are filled into the corresponding fields of the report template. The completed report template is converted into a file of a specified format; the standard report contains a readable text summary and machine-parseable data fields.

[0049] In practice, verification feedback on the malicious payload identification conclusion is obtained from external input. This feedback confirms whether the detected computing entity is truly malicious or benign. External input can come from a security analyst's manual assessment interface or be automatically obtained through the detection results interface of an integrated automated sandbox or threat intelligence platform. The verification feedback includes a clear judgment label indicating whether the detected computing entity is ultimately confirmed as a malicious payload or a benign program. This judgment label is correlated and compared with the malicious payload identification conclusion.

[0050] The load behavior time-series graph, malicious load identification conclusions, and verification feedback are associated and stored to form labeled sample data. This association and storage is performed in a specific sample database. Each labeled sample data record contains the following fields: a unique identifier of the detected computational entity, complete data of the normalized load behavior time-series graph reconstructed from the entity's behavior, a malicious load identification conclusion generated for the entity (including a malicious level rating and behavior pattern identifier), and a verification feedback label provided by external input. In some embodiments, a timestamp and the hash value of the original runtime load sequence are also appended during storage for retrieval.

[0051] Incremental updates to the malicious behavior knowledge base are performed using labeled sample data. Specifically, when verification feedback confirms malicious intent and there are no highly similar samples in the behavior pattern sample library, the load behavior time series graph is stored as a new behavior pattern sample in the malicious behavior knowledge base. There are two triggering conditions for incremental updates, both of which must be met simultaneously. The first condition is that verification feedback confirms the true attribute of the detected computational entity is "malicious." The second condition is that there are no existing behavior pattern samples in the current malicious behavior knowledge base that are highly similar to the generated load behavior time series graph. Determining high similarity requires a similarity calculation and threshold comparison process. The similarity between the load behavior time series graph and each existing sample graph in the knowledge base is calculated, and all similarity values ​​are checked to ensure they are all below a preset entry threshold. Optionally, graph similarity can be calculated using algorithms such as graph edit distance or maximum common subgraph. If both conditions are met, the generated load behavior time series graph, along with the behavior pattern identifier (or a newly generated pattern identifier based on its characteristics) from the associated malicious load identification conclusion, is added as a new behavior pattern sample record to the malicious behavior knowledge base. Similarity can be calculated using the following formula: Where: symbol Representation of the spectrum With atlas Normalized similarity between them. Symbols Representation of the spectrum With atlas The graph edit distance between nodes and edges is calculated through a series of node and edge insertion, deletion, and replacement operations. Convert to The total cost of the minimum required operations. (Symbol) and Representing the spectrum and atlas The number of nodes. Symbol and Representing the spectrum and atlas The number of edges. When For any existing sample in the knowledge base The calculation results are all lower than the entry threshold. When the sample is found to be highly similar to another sample, it is determined that there are no highly similar samples.

[0052] Extract the malicious load identification conclusion's malicious level rating and behavior pattern identifier, and associate them with the identification information of the detected computing entity. The extraction operation directly reads the malicious level rating field and behavior pattern identifier list field from the malicious load identification conclusion's data structure. The identification information of the detected computing entity can be obtained from monitoring metadata, typically including process identifiers, hostnames, image file paths, or container identifiers.

[0053] Following a pre-defined report template, the maliciousness level rating is mapped to a level description, and the behavior pattern identifier is mapped to a behavior pattern name. The pre-defined report template is a structured document framework containing replaceable field placeholders. The maliciousness level rating is typically an internally used code or level number, such as "H", "M", "L" or "3", "2", "1". The report template predefines a mapping table from these codes to human-readable descriptions; for example, "H" maps to "High Risk" and "3" maps to "Severe". The behavior pattern identifier is a sample ID stored in a knowledge base. The report template queries the metadata table of the malicious behavior knowledge base to map the behavior pattern identifier to a more detailed behavior pattern name or family name; for example, "Pattern_001" maps to "Ransomware Encryption Behavior Pattern".

[0054] The report template should be populated with the level description, behavior pattern name, identification information of the detected computational entity, and the start and end times of the load event detection. The start and end times of the load event detection refer to the entire time interval from the start of capturing the original runtime load sequence to generating a malicious load identification conclusion. In practice, the report template exists as an electronic document, such as an Extensible Markup Language (XML) template or a Rich Text (MR) template. The above information is programmatically populated into predefined, tagged field locations within the template. This population process ensures the structure and consistency of the report content.

[0055] The completed report template is converted into a file in a specified format. The standard report contains a readable text summary and machine-parseable data fields. The specified format can be Portable Document Format, Hypertext Markup Language, or plain text. The conversion process is completed by calling the appropriate document generation library. In some embodiments, the standard report uses a structured data format such as JavaScript Object Representation, where the "Text Summary" field contains natural language descriptive paragraphs for human reading, and the "Data Fields" section contains structured key-value pairs for other security systems or platforms to automatically read and parse via an application programming interface.

[0056] See Figure 5 This is a raw runtime load sequence capture graph, showing the time-series data of four core resource consumption of computing entities within 0-200 seconds. It is a typical output of the "raw load sequence capture" stage in the malicious load identification process. From 0-50 seconds, CPU usage spikes from 20 to over 90, then drops back to -50, meeting the event definition of "high watermark trigger → low watermark fallback." From 50-100 seconds, CPU usage peaks again at 100, forming a second complete event segment. Similar fluctuations repeat from 100-150 seconds and 150-200 seconds, forming a periodic load event sequence. These event segments will be further used to extract feature vectors for subsequent behavior sequence reconstruction and malicious pattern matching. Disk I / O and CPU fluctuations are synchronized and can be used to extract the "resource consumption curve within the event" feature; stable memory and network performance can serve as auxiliary features to distinguish between normal and malicious loads.

[0057] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A method for malignant load identification based on load event detection, characterized in that, The method includes: The resource consumption behavior sequence of computing entities is captured in the runtime environment to form the original runtime load sequence, which includes readings of various resource consumption indicators in the time dimension. Event pattern matching is performed on the original runtime load sequence to identify load event fragments that conform to a preset triggering pattern, and a preliminary load event set is separated from the original runtime load sequence. The event feature vector of each load event segment in the preliminary load event set is extracted, and the event feature vector is fed into the behavior sequence reconstruction model. The behavior sequence reconstruction model reconstructs the event feature vector into a normalized load behavior time series graph according to the preset event evolution rules. The malicious behavior knowledge base stores sample behavioral patterns of known malicious loads. The malicious behavior knowledge base stores sample behavioral patterns of known malicious loads. Based on the results of the pattern comparison, the matching degree between the load behavior time series graph and each behavior pattern sample in the malicious behavior knowledge base is calculated, and a matching degree score list is generated. Threshold decision and aggregation analysis are performed on the matching score list to generate a malicious load identification conclusion for the detected computational entity.

2. The method of claim 1, wherein, The process of capturing the resource consumption behavior sequence of computing entities in the runtime environment to form the original runtime load sequence includes: A lightweight probe is deployed on the host machine of the monitored computing entity, and the lightweight probe obtains the resource consumption index readings of the computing entity from the operating system kernel at a fixed sampling frequency. The resource consumption metrics readings include at least the CPU utilization, memory usage, disk read / write frequency, and number of network connections. The lightweight probe appends a high-precision timestamp to the acquired resource consumption index readings and caches them in memory in chronological order. When the cached data reaches the preset batch size, or when the capture operation of the original runtime load sequence is explicitly terminated, the cached timestamped resource consumption index readings are output as a continuous original runtime load sequence. 3.The malignant load identification method based on load event detection according to claim 1, characterized in that, Event pattern matching is performed on the original runtime load sequence to identify load event segments that match a preset triggering pattern, including: Within a preset time window, continuously monitor the CPU utilization index in the original runtime load sequence; When the central processing unit utilization rate exceeds the preset high water level threshold, it is marked as the event start point; Starting from the event start point, the original runtime load sequence is recorded until the CPU utilization index falls below a preset low water level threshold. The complete data record between the start point and the fall point is marked as a load event segment. For all the marked load event segments, verify whether their duration and peak resource consumption meet the minimum event strength constraint, and include the load event segments that pass the verification into the preliminary load event set.

4. The malicious load identification method based on load event detection according to claim 1, characterized in that, Extract the event feature vector for each load event segment in the initial load event set, including: The event feature vector includes the resource consumption curve within the event, the interval sequence between events, and the count of concurrent events; For each load event segment, calculate the statistics of resource consumption indicators within the segment as a function of time, including the average, variance, peak, and trough values, to form the resource consumption curve within the event. Calculate the time interval between the current load event segment and the historical load event segments, and form the event interval sequence by combining multiple consecutive time intervals; The number of other load event segments that overlap or are adjacent to the current load event segment in time within a preset neighborhood time window is counted and used as the concurrent event count; The resource consumption curve within the event, the interval sequence between events, and the concurrent event count are normalized and concatenated to form the event feature vector.

5. The malicious load identification method based on load event detection according to claim 1, characterized in that, The event feature vector is fed into a behavior sequence reconstruction model, which reconstructs the event feature vector into a normalized load behavior time series graph according to preset event evolution rules, including: The behavior sequence reconstruction model includes an encoding layer, an evolutionary layer, and a graphing layer; The coding layer receives the event feature vector and encodes the event feature vector into an initial event state; The evolution layer simulates the state transition of the initial event state at multiple virtual time steps according to the preset event evolution rules. The preset event evolution rules define the transition probabilities and conditions between different event states. The graphing layer collects the event states generated by the evolution layer at all virtual time steps, maps each event state to a node in the graph, and adds directed edges between graph nodes according to the transition relationship between event states to form the normalized load behavior time sequence graph.

6. The malicious load identification method based on load event detection according to claim 1, characterized in that, The time-series graph of the load behavior is compared using a malicious behavior knowledge base, including: The stored behavior pattern samples are read one by one from the malicious behavior knowledge base, and each behavior pattern sample is also stored in the form of a load behavior time sequence graph. The normalized load behavior time sequence graph is matched with the behavior pattern sample graph read from the malicious behavior knowledge base. In the process of subgraph isomorphism matching, the similarity between two graphs is compared in terms of node attributes, number of nodes, edge relationships, and connection topology. Record the similarity measurement results generated from each comparison, and use these similarity measurement results as the basis for subsequent calculation of the matching degree.

7. The method for identifying malicious load based on load event detection according to claim 1, characterized in that, Based on the results of the pattern comparison, the matching degree between the load behavior time series graph and each behavior pattern sample in the malicious behavior knowledge base is calculated, and a matching degree score list is generated, including: For each behavior pattern sample in the malicious behavior knowledge base, a set of corresponding similarity measurement results is obtained from the pattern comparison process; Weights are assigned to each measurement result in the similarity measurement result set, and the weights are determined by a preset weight configuration parameter table; Based on the assigned weights, the similarity measurement result set is weighted and fused to calculate a comprehensive matching score; Traverse all behavior pattern samples in the malicious behavior knowledge base, repeatedly perform weighted fusion calculations to obtain a matching score corresponding to each behavior pattern sample, arrange the matching scores in order, and generate the matching score list.

8. The method for identifying malicious load based on load event detection according to claim 1, characterized in that, The matching score list is subjected to threshold decision and aggregation analysis to generate a malicious load identification conclusion for the detected computational entity, including: The malicious load identification conclusion includes a maliciousness level rating and a corresponding behavioral pattern identifier. A decision threshold is set for each matching score in the matching score list, and the decision threshold is determined based on the confidence level of the corresponding behavioral pattern sample; Each matching score is compared with the corresponding decision threshold, and matching scores that exceed the decision threshold and their associated behavioral pattern samples are marked. The labeled behavioral pattern samples are sorted according to their corresponding matching scores, and a preset number of behavioral pattern samples with the highest matching scores are selected as candidate malicious patterns. Based on the type distribution and score concentration of the candidate malicious patterns, the malicious level rating is calculated, and the identifiers of the candidate malicious patterns are summarized into the behavior pattern identifier.

9. The malicious load identification method based on load event detection according to claim 8, characterized in that, After generating the malicious load identification conclusion for the detected computational entity, a feedback learning step is also included, which includes: Obtain external input verification feedback regarding the malicious load identification conclusion, wherein the verification feedback confirms that the true attribute of the detected computing entity is malicious or benign; The load behavior time series graph, the malignant load identification conclusion, and the verification feedback are associated and stored to form labeled sample data; The malicious behavior knowledge base is incrementally updated using the labeled sample data, specifically including: when the verification feedback confirms that the behavior is malicious and there are no highly similar samples in the behavior pattern sample base, the load behavior time series graph is stored as a new behavior pattern sample in the malicious behavior knowledge base.

10. The method for identifying malicious load based on load event detection according to claim 1, characterized in that, This also includes formatting the malignant load identification conclusion into a standard report, specifically: Extract the malicious level rating and behavior pattern identifier from the malicious load identification conclusion, and associate them with the identification information of the detected computing entity; According to the preset report template, the maliciousness level rating is mapped to a level description, and the behavior pattern identifier is mapped to a behavior pattern name; Fill in the corresponding fields of the report template with the level description, the behavior pattern name, the identification information of the detected computing entity, and the start and end times of the load event detection; The completed report template is converted into a file in a specified format. The standard report contains a readable text summary and data fields that can be parsed by machines.

Images