Api access behavior threat hunting method, system, device, medium, and program product

Abstract

The application provides an API access behavior threat hunting method, system, device, medium and program product. The method comprises: obtaining API access data of an access subject and constructing an access behavior sequence; performing vectorization processing on the access behavior sequence to obtain a uniform-dimension behavior representation vector, and performing similarity measurement processing to form a comparable behavior representation; performing unsupervised clustering analysis on the comparable behavior representation to obtain a clustering result including at least one behavior mode cluster and abnormal behavior data; performing behavior analysis processing on the behavior mode cluster and the abnormal behavior data based on the clustering result to generate a behavior analysis result; storing and updating the behavior analysis result, and triggering a corresponding security disposal operation based on the behavior analysis result. The application forms a closed-loop threat hunting mechanism from data collection, behavior representation, mode discovery to knowledge sedimentation and strategy execution, and improves the accuracy, self-adaptability and real-time security response capability of API access behavior identification.

Description

Technical Field

[0001] This application relates to the field of computer network security technology, and in particular to a method, system, device, medium, and program product for hunting API access behavior threats. Background Technology

[0002] With the increasing frequency of Application Programming Interface (API) calls in internet business systems, security analysis based on API access behavior has become an important technical means for business security and risk control. Existing technologies commonly employ API access behavior analysis methods, including rule engine-based detection methods, device fingerprinting-based identification methods, machine learning-based behavioral modeling methods, and clustering-based anomaly detection methods.

[0003] Among these methods, rule-based methods typically identify abnormal behavior by manually setting access frequency thresholds or path rules. While simple to implement, these methods rely on manual experience to configure rules, making them difficult to adapt to constantly changing access patterns in the business environment. Device fingerprinting methods primarily rely on terminal identifiers or device characteristics for identification. Although they can distinguish the accessing entity, they struggle to reflect the behavioral structure information within the API call sequence. Machine learning-based methods typically rely on manually designed statistical features or N-gram sequence features for modeling. In scenarios with a large number of API types, the feature dimensions tend to grow rapidly, leading to high complexity in model training and behavioral similarity calculation. While clustering analysis methods can automatically discover behavioral patterns to some extent, traditional clustering algorithms usually require pre-setting the number of clusters, limiting their adaptability to high-dimensional sparse behavioral data.

[0004] In practical applications, API paths typically contain dynamic parameters, and the request scale and access frequency vary significantly among different users, resulting in API access behavior that is high-dimensional, discrete, and unevenly distributed. Existing technologies often use manually designed statistical features or simple sequence features for representation. When directly vectorizing API access sequences, problems such as feature dimensionality inflation and difficulty in stably calculating behavioral similarity easily arise, affecting the accuracy of behavioral pattern analysis. Furthermore, some methods rely on manually defined rules or supervised learning models, making it difficult to automatically adapt to the constantly changing access behavior structure in actual business scenarios. Traditional clustering methods usually require pre-specifying the number of clusters, failing to adaptively form stable behavioral patterns based on the distribution of behavioral data, and have limited ability to identify anomalous outliers.

[0005] In existing security analysis processes, identified behavioral patterns often lack a unified, structured representation, making them difficult to reuse as stable indexes. This necessitates re-performing behavioral clustering or manual judgment for each analysis, hindering the system's continuous evolution and large-scale deployment. Therefore, how to construct a stable and comparable behavioral representation in high-frequency API access scenarios, achieve adaptive behavioral pattern discovery without relying on manual rules, and support the reuse of identified behavioral patterns has become a pressing technical problem to be solved in this field. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this application provides a method, system, device, medium, and program product for hunting API access behavior threats, which at least solves the problems of difficulty in representing access behavior in high-frequency API access scenarios, difficulty in adaptively discovering behavior patterns, and difficulty in reusing identified behavior patterns.

[0007] To achieve the above objectives and other advantages, some embodiments of this application provide the following aspects:

[0008] In a first aspect, some embodiments of this application provide a method for hunting API access behavior threats, including:

[0009] Obtain API access data of the accessing entity, and construct an access behavior sequence based on the API access data;

[0010] The access behavior sequence is vectorized to obtain a behavior representation vector with a unified dimension, and similarity measurement is performed based on the behavior representation vector to form a comparable behavior representation for behavior pattern analysis.

[0011] Unsupervised clustering analysis is performed on the comparable behavior representations to obtain clustering results including at least one cluster of behavior patterns and abnormal behavior data;

[0012] Based on the clustering results, behavioral pattern clusters and abnormal behavior data are subjected to behavioral analysis processing to generate behavioral analysis results;

[0013] The behavior analysis results are stored and updated, and corresponding security actions are triggered based on the behavior analysis results.

[0014] Secondly, some embodiments of this application provide an API access behavior threat hunting system, including:

[0015] The data processing module is used to acquire API access data of the accessing subject and construct an access behavior sequence based on the API access data;

[0016] The vector representation module is used to vectorize the access behavior sequence to obtain a behavior representation vector with a unified dimension, and to perform similarity measurement based on the behavior representation vector to form a comparable behavior representation for behavior pattern analysis.

[0017] The pattern analysis module is used to perform unsupervised clustering analysis on the comparable behavior representations to obtain clustering results including at least one behavior pattern cluster and abnormal behavior data.

[0018] The behavior analysis module is used to perform behavior analysis processing on the behavior pattern clusters and the abnormal behavior data based on the clustering results, so as to generate behavior analysis results;

[0019] The application execution module is used to store and update the behavior analysis results, and trigger corresponding security actions based on the behavior analysis results.

[0020] Thirdly, some embodiments of this application also provide an electronic device, the electronic device comprising:

[0021] One or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform an API access behavior threat hunting method as described above.

[0022] Fourthly, some embodiments of this application also provide a computer-readable storage medium having a computer program and / or instructions stored thereon, which, when executed by a processor, implement the API access behavior threat hunting method as described above.

[0023] Fifthly, some embodiments of this application also provide a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the API access behavior threat hunting method as described above.

[0024] Compared with existing technologies, the solution provided in this application, by acquiring API access data of the accessing subjects and constructing access behavior sequences, can uniformly transform discrete access logs into a behavioral data foundation with temporal correlation, providing a consistent and stable input source for subsequent analysis. By constructing a comparable behavioral representation with a unified dimension through vectorization processing and similarity measurement, standardized expressions of access behaviors between different accessing subjects are achieved, thereby reducing the complexity of manual feature design and improving the efficiency and comparability of high-dimensional data processing. Unsupervised clustering analysis is used to automatically discover stable behavioral pattern clusters and identify abnormal behavioral data, enabling the system to identify unknown abnormal access patterns without manual rule configuration. Combined with behavioral analysis processing of behavioral pattern clusters and abnormal behavioral data, a closed-loop analysis mechanism integrating historical knowledge reuse and semantic analysis is realized. Furthermore, through the linkage of storing and updating behavioral analysis results with security measures, a closed-loop threat hunting mechanism is formed, encompassing data collection, behavioral representation, pattern discovery, knowledge accumulation, and policy execution. This improves the accuracy, adaptability, and real-time security response capabilities of API access behavior identification. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other implementation methods can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a flowchart illustrating an API access behavior threat hunting method provided in an embodiment of this application;

[0027] Figure 2 This is a schematic diagram of the structure of an API access behavior threat hunting system provided in an embodiment of this application;

[0028] Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] Some embodiments of this application relate to an API access behavior threat hunting method, which can be deployed in a security analysis platform for internet business systems. It is used to uniformly analyze and process API access behavior from multiple business nodes. Its operating environment can be built on a distributed computing framework to support parallel processing of large-scale access data. Exemplarily, the application environment of this method may include a business server cluster, a log collection component, distributed behavior analysis nodes, and execution-end devices. The business server cluster provides API interface services and generates API access logs. The log collection component collects and forwards the API access logs. The distributed behavior analysis nodes perform access behavior sequence construction, vectorization representation, and clustering analysis. The execution-end devices can be gateway devices, firewalls, or risk control systems, used to perform access control operations based on the behavior analysis results, such as rate limiting, blocking, or identity verification. (See also...) Figure 1 As shown, the method may include the following steps:

[0031] Step S1: Obtain the API access data of the accessing subject and construct an access behavior sequence based on the API access data.

[0032] The access subject can be a uniquely identifiable entity that initiates the API request, such as a user account, client device, application instance, or network address, for example, an IP address, user ID, or device ID. API access data can originate from API access logs generated by the business server or API gateway, used to record the interface call behavior of the access subject within a preset time range.

[0033] In an optional embodiment, step S1 specifically includes:

[0034] Step S101: Collect API access logs and identify the original request path in the API access logs.

[0035] API access logs can be generated by business servers, API gateways, load balancers, or security proxy components when processing client requests. These logs record information related to the API request initiated by the accessing entity, such as the request path, request time, source IP address, request method, and request header fields. For example, API access logs can be collected in real-time from distributed business server nodes using a log collection component. This component can obtain log data based on message queues, log subscriptions, or file stream reading methods.

[0036] After obtaining the API access logs, the log content can be parsed to extract the original request paths. Specifically, the unnormalized original paths can be obtained by parsing the URL field in the HTTP request message, such as " / api / user / 152713861849862144 / profile" or " / api / product / list?page=1". The original request paths reflect the API interfaces actually called by the accessing entity and are the foundational data for subsequent path normalization and access behavior statistics. In some implementations, accessing entity identification information, such as the source IP field, user login identifier, or device ID, can also be extracted simultaneously for subsequent aggregation key determination.

[0037] Step S102: Normalize the original request path to obtain the normalized API path.

[0038] Step S102 normalizes the original request path obtained in step S101 to eliminate the impact of dynamic parameter differences on behavior statistics, thereby obtaining a normalized API path. Since API interfaces typically carry dynamic parameters such as user ID, order number, UUID, or file identifier during actual access, different access requests, although semantically identical, may have different path strings. Directly using these for subsequent statistical analysis could easily lead to an explosion in the number of paths and reduce the accuracy of behavior pattern recognition. Therefore, the original request path can be uniformly transformed based on preset normalization rules, where the normalization rules can trim or replace path parameters and query parameters according to different business scenarios.

[0039] For example, dynamic parameters in the path, such as numeric IDs, UUID format strings, or hash values, can be identified based on path matching rules and replaced with uniform placeholders to form a standardized path template. For instance, “ / chats / 152713861849862144” can be converted to “ / chats / {id}”, or “ / api / connector / ws / std / 12d94502-f5d6-4fe7-87ef-e9205fce97a8” can be converted to “ / api / connector / ws / std / {uuid}”. For the query parameters, key fields can be retained, non-key fields can be deleted, or uniform replacements can be performed according to business rules. For example, “ / api / product / list?page=1&size=20” and “ / api / product / list?page=2&size=20” can be uniformly normalized to “ / api / product / list”.

[0040] In an optional implementation, static resource access paths can also be merged. Since access paths in static resource directories (such as JS script directories, JSON data directories, or image resource directories) typically contain version numbers, filenames, or random identifiers, different requests accessing the same resource type may have different path strings, easily leading to too many path dimensions. Therefore, static resource paths can be uniformly processed based on preset merging rules, retaining only fixed directory levels and replacing subsequent path parts with uniform placeholders. For example, " / debug / json / 2025090301K472KH6NKB3HKRRXH5MP0QKE.json" can be converted to " / debug / json / *", and " / formmode / js / CryptoJS3.1.2 / cisco / buildings.xml" can be converted to " / formmode / js / *", reducing path dimensions.

[0041] In an optional implementation, the normalization process can also automatically identify dynamic parameter levels based on path hierarchy analysis. Specifically, statistical analysis can be performed on the original request paths within a preset time window, the paths can be split into layers according to path separators, and the distribution of different path values ​​within the same layer can be statistically analyzed. When a certain layer shows a large number of different values ​​in the statistical results, and there are no stable semantic features among the values, the layer can be determined as a dynamic parameter layer, and the layer can be uniformly replaced with a preset placeholder, thereby achieving path merging processing. For example, in the path sets " / api / user / 152713861849862144 / profile" and " / api / user / 987654321012345678 / profile", the third layer corresponds to different numeric IDs and the number of values ​​increases significantly. This layer can be identified as a dynamic parameter layer and normalized to " / api / user / {id} / profile".

[0042] Through the API path normalization process described above, the original request path containing dynamic parameters is converted into a unified path template to eliminate path differences caused by parameter changes, so that semantically consistent API interfaces can be correctly identified and uniformly aggregated.

[0043] Step S103: Determine the aggregation key of the access subject, and perform statistical processing on the normalized API paths under the same aggregation key based on a preset time window to generate corresponding access frequency information.

[0044] The aggregation key is used to identify the source of the access subject's behavior and can be flexibly selected according to different business scenarios. For example, the IP address can be directly obtained from the source IP field of the API access log as the aggregation key; in other implementations, the user ID can be obtained by parsing the login credentials carried in the request, such as identity recognition based on Token, Cookie, or Session information; in addition, a device ID generated by the client and carried in the request header can also be used as the aggregation key, such as an identifier generated through device fingerprinting technology. The device fingerprint can be calculated based on browser fingerprint information (including features such as Canvas, WebGL, or User-Agent), or generated based on mobile device identifiers (such as iOS IDFA or Android device ID), or provided by a third-party SDK. Through the above methods, unified aggregation of access behaviors from different access subjects can be achieved.

[0045] After determining the aggregation key, normalized API paths can be statistically processed based on a preset time window. For example, access records within a specified time window can be filtered from API access logs and grouped according to the aggregation key. The access frequency information is then used to represent the access statistics of the access subject for each normalized API path within the set time window. This information can include data such as the number of accesses for each normalized API path, the path access distribution, and the total number of requests. It is used to characterize the mapping relationship between normalized API paths and access counts, thereby transforming discrete access logs into structured behavioral statistical features.

[0046] For example, for a given access subject, the statistical results within a set time window may include a set of normalized API paths and the corresponding number of accesses. For instance, the path " / api / user / login" is accessed once, " / api / product / list" is accessed five times, and " / api / cart / add" is accessed twice, for a total of eight requests. In an optional implementation, the statistical processing can be performed within a distributed computing framework. The normalized API paths from multiple business nodes are partitioned according to the aggregation key, and the statistical calculations are performed separately on each computing node to improve the computational efficiency in large-scale access data processing scenarios.

[0047] In one optional implementation, the preset time window can be flexibly configured according to the characteristics of business operations. For example, in business scenarios where access requests fluctuate frequently, an hourly time window can be used to improve the ability to detect short-term abnormal behavior; in scenarios where access behavior is relatively stable, a daily or weekly time window can be used to more comprehensively reflect the long-term behavioral patterns of the access subjects. By making the time window configurable, access frequency statistics can be made more closely aligned with the characteristics of business traffic changes, thereby improving the stability and adaptability of access behavior sequence construction.

[0048] Step S104: Construct an access behavior sequence based on normalized API path and access frequency information.

[0049] Normalized API paths can be used as sequence elements, and the corresponding access counts can be associated with them as weight information to form an access behavior sequence that can characterize the distribution of API calls by a user within a preset time window. For example, for a user, the access frequency information within a set time window is: " / api / user / login" accessed 1 time, " / api / product / list" accessed 5 times, and " / api / cart / add" accessed 2 times. Then, the above normalized API paths can be organized in a preset order and combined with the corresponding access counts to construct an access behavior sequence, which is used to characterize the overall access behavior pattern of the user within that time window.

[0050] In an optional implementation, the access behavior sequence may further include auxiliary statistical information such as the total number of requests, the number of deduplicated paths, or the path access ratio to enhance the ability to characterize the access behavior structure.

[0051] Through steps S101-S104, the original request path is normalized, eliminating path discrepancies caused by dynamic parameter differences, thereby reducing path dimensionality and improving the consistency of behavior statistics. Statistical processing based on aggregation keys and time windows converts individual access records into access frequency information reflecting access intensity, achieving an aggregated expression of the overall behavioral characteristics of the accessing entity. Furthermore, access behavior sequences are constructed based on the normalized API path and access frequency information, transforming unstructured log data into a unified and comparable serialized input. Through these techniques, the original discrete API access logs are gradually transformed into access behavior sequences with a unified structure, realizing a complete preprocessing flow from data collection, path standardization, entity aggregation to behavior expression. This provides a stable data foundation for subsequent behavior vector construction and pattern analysis, thereby improving processing efficiency and analytical reliability in large-scale API access scenarios.

[0052] Step S2: Vectorize the access behavior sequence to obtain a behavior representation vector with a unified dimension, and perform similarity measurement based on the behavior representation vector to form a comparable behavior representation for behavior pattern analysis.

[0053] In an optional embodiment, step S2 specifically includes:

[0054] Step S201: Use a preset mapping function to map the normalized API paths in the access behavior sequence to a vector space of a specified dimension to obtain the original feature vector.

[0055] Since access behavior sequences typically exist as a combination of normalized API paths and their access frequency information, they belong to a discrete data structure with variable dimensions. Therefore, a pre-defined mapping function can be used to map the access behavior sequences to a fixed-dimensional vector space to achieve a unified representation of the behavior data. The pre-defined mapping function can be a hash mapping function, a path encoding function, or other mapping methods that can convert discrete path identifiers into fixed-dimensional indices. The hash mapping function can use a feature-based hashing algorithm, such as hashing the normalized API path based on MurmurHash3 and mapping the hash value to a fixed-length vector space.

[0056] Taking a target vector dimension of 128 as an example, a 128-dimensional zero vector can be initialized. For each normalized API path in the access behavior sequence, its hash value is calculated, and modulo 128 is taken to obtain the index position corresponding to the path, thus mapping the discrete path identifier to the position index in a fixed-dimensional vector. Through the above feature hash mapping, even when the number of system APIs far exceeds the target dimension, the access behavior can still be compressed into a vector representation of a uniform dimension, facilitating subsequent calculation and processing.

[0057] Since a single user typically accesses only a limited number of normalized API paths within a single time window (e.g., 5 to 20), and the vector space dimension can be set to a higher dimension, the distribution of each path in the vector space after feature hashing exhibits a sparse structure, which helps maintain the stability of the behavior representation. Compared to constructing vector representations based on the order of high-frequency APIs, feature hashing allows the same normalized API path to correspond to a stable vector dimension across different time windows, thereby avoiding semantic drift caused by changes in path order and ensuring that different behavior representation vectors still possess consistent structural expressiveness across time window scenarios.

[0058] Step S202: Based on the access frequency information of each normalized API path in the access behavior sequence, perform numerical accumulation processing on the original feature vector.

[0059] Step S202 is used to perform numerical accumulation processing on the original feature vector obtained in step S201 based on the access frequency information, so that the values ​​of each dimension in the vector reflect the access intensity of the access subject to the corresponding path. Specifically, when a normalized API path in the access behavior sequence is mapped to the corresponding index position in the original feature vector through a preset mapping function, the value of the index position can be accumulated based on the number of times the path is accessed within a preset time window, thereby forming an original feature vector with weight information.

[0060] For example, the access frequency information of a certain user within a time window can be represented as {" / api / user / login": 3, " / api / product / list": 5, " / api / cart / add": 2, " / api / order / create": 4}. In a 128-dimensional vector space, if the normalized API paths mentioned above are mapped to the 23rd, 87th, 45th, and 102nd dimensions of the original feature vector in step S201, then the values ​​3, 5, 2, and 4 can be accumulated in the corresponding dimensions, so that the values ​​of each dimension in the original feature vector can reflect the distribution of the access intensity of different API paths by the user within the time window.

[0061] Step S203: Normalize the accumulated original feature vector to obtain a behavior representation vector with a modulus of unit length.

[0062] In this embodiment, the original feature vector obtained in step S202 can be processed by L2 normalization, that is, by calculating the sum of squares of the values ​​of each dimension in the vector and taking the square root as the vector magnitude, and then dividing the values ​​of each dimension in the vector by the magnitude, so that the normalized vector magnitude is 1.

[0063] For example, assuming the original feature vector obtained in step S202 has values ​​of 3, 2, 5, and 4 in the 23rd, 45th, 87th, and 102nd dimensions, respectively, and the remaining dimensions are 0, performing L2 normalization on this vector yields a behavior representation vector with a modulus of unit length, where the values ​​of each dimension are scaled proportionally. In this way, even if different access subjects have different total access volumes within the same time window, their normalized behavior representation vector still primarily reflects the distribution structure characteristics of the access path, without being directly affected by differences in request scale.

[0064] Step S204: Calculate the distance between different behavior representation vectors based on a preset similarity metric function to form comparable behavior representations for behavior pattern analysis.

[0065] Since the normalized behavior representation vectors are in a uniform scale space, a pre-defined similarity metric function can be used to calculate the distance between behavior vectors of different users. For example, the similarity metric function can be a cosine similarity function, which measures the similarity of behavior patterns by calculating the cosine of the angle between two behavior representation vectors.

[0066] Specifically, let the behavior representation vector corresponding to the first access subject be . The behavior representation vector corresponding to the second access subject is The cosine similarity value can be obtained by calculating the dot product of the two. When the normalized API path distributions accessed by two entities within a time window are similar, the cosine similarity value between their behavior representation vectors approaches 1; when the access patterns differ significantly, the similarity value approaches 0. Through the constraints of the aforementioned similarity measurement function, the behavior representation vectors are placed in a unified similarity measurement space, thus forming comparable behavior representations for subsequent unsupervised clustering analysis. These comparable behavior representations are a set of behavior representation vectors that satisfy a unified distance measurement rule.

[0067] Through steps S201-S204, the access distribution of normalized API paths is encoded, enabling massive API access behaviors to be expressed in a fixed-dimensional vector space. Normalization of the original feature vectors eliminates the impact of differences in request scale among different access subjects, allowing the behavior representation to focus more on the access path distribution characteristics themselves. Based on this, a unified comparison standard is established through a similarity metric function, allowing the distance relationship between different behavior representation vectors to be expressed quantitatively, providing a stable and reliable input foundation for subsequent unsupervised clustering analysis. Based on the above processing, access behavior sequences that were originally structurally unstable and difficult to compare directly can be transformed into behavior representation vectors of a unified dimension, forming comparable behavior representations in a unified similarity metric space, thereby significantly reducing the reliance of traditional feature engineering on manually designed rules.

[0068] Step S3: Perform unsupervised clustering analysis on comparable behavior representations to obtain clustering results including at least one behavior pattern cluster and abnormal behavior data.

[0069] In an optional embodiment, step S3 specifically includes:

[0070] Step S301: Perform density clustering on the comparable behavior representations based on the preset neighborhood range parameters and density threshold.

[0071] In this embodiment, a density-based unsupervised clustering algorithm can be used to perform pattern discovery processing on comparable behavior representations. For example, the DBSCAN density clustering algorithm can be selected to perform cluster analysis on behavior vectors. Compared to traditional clustering methods that require pre-specifying the number of clusters, DBSCAN can automatically discover typical behavior patterns in the system, and also has a natural ability to identify noisy data, automatically identifying abnormal access behaviors as outliers.

[0072] Since all behavior representation vectors have undergone L2 normalization in step S203, the differences in request scale between different access subjects have been eliminated. Therefore, similarity can be directly determined based on distance in the vector space. In the normalized vector space, there is a monotonic correspondence between Euclidean distance and cosine similarity; that is, the closer the directions of two behavior representation vectors are, the smaller their Euclidean distance. Therefore, Euclidean distance can be used as a distance metric between samples during clustering calculations.

[0073] In some implementations, a neighborhood range parameter `eps` and a density threshold `min_samples` can be set for the density clustering algorithm. For example, `eps` can be set to 0.15 to limit the distance range between two comparable behavior representations that are considered "similar behaviors," while `min_samples` can be set to 10 to limit the minimum number of samples required to form a stable cluster of behavior patterns. By setting these parameters, the clustering process can focus more on the consistency of the access path distribution structure rather than the number of requests, thereby improving the stability of behavior pattern recognition.

[0074] Step S302: Group the comparable behavior representations with a number of sample points in the neighborhood not less than the density threshold and the reachable samples in the neighborhood into the same behavior pattern cluster.

[0075] In this embodiment, after calculating the neighborhood range in step S301, comparable behavior representations can be merged according to a preset density threshold. Specifically, when the number of sample points contained in the neighborhood range of a comparable behavior representation is not less than the density threshold, the comparable behavior representation can be identified as a core sample. Starting from the core sample, comparable behavior representations that are directly reachable or indirectly reachable through other core samples are gradually merged to form a corresponding behavior pattern cluster.

[0076] For example, when multiple entities accessing the same API within the same time window exhibit similar normalized API path distributions, their corresponding behavioral representation vectors are close in distance within the similarity metric space. These comparable behavioral representations will be aggregated into the same behavioral pattern cluster. For instance, if several entities exhibit similar business access flows, and the distances between their corresponding comparable behavioral representations are all less than the neighborhood range parameter, they can be merged into the same behavioral pattern cluster using density expansion to represent a class of behavioral patterns with highly similar API access structures.

[0077] In some implementations, by setting a density threshold, the formation of behavioral pattern clusters can meet the minimum sample size requirement. That is, a behavioral pattern is only considered stable if at least a preset number of independent users exhibit similar behavioral structures. This effectively filters out low-frequency noise data such as occasional visits, test traffic, or random scanning behavior, preventing them from being mistakenly classified as stable patterns. This results in clustering results that are more closely aligned with real and reproducible user behavior or client access patterns, improving the reliability and stability of behavioral pattern recognition.

[0078] Step S303: Mark comparable behavior representations that are not classified into any behavior pattern cluster as outliers, as anomalous behavior data that is inconsistent with the behavior pattern cluster.

[0079] In this embodiment, after completing the behavior pattern cluster merging in step S302, comparable behavior representations that do not meet the density threshold condition within the neighborhood and cannot be classified into any behavior pattern cluster can be marked as outliers and output as anomalous behavior data. Since density clustering algorithms perform pattern recognition based on sample distribution density, outliers usually correspond to access subjects whose access path combinations deviate significantly from the mainstream behavior structure. Their behavior representation vectors are far from other samples in the similarity measurement space, making it difficult to form stable clustering regions.

[0080] For example, when the normalized API paths accessed by certain users within a time window differ significantly from those of most users—for instance, frequently accessing abnormal interface paths, exhibiting a scanning access structure, or displaying abnormal path combination patterns—their corresponding comparable behavior representations may not meet the density conditions for forming behavior pattern clusters, thus being marked as outliers by the system. In some implementations, outliers can be considered as a candidate set of potential abnormal access behaviors, used for further analysis in conjunction with semantic analysis or intelligent analysis agents, such as identifying automated crawler behavior, interface probing behavior, or potential attack access.

[0081] Through the above processing, stable behavioral patterns can be automatically discovered while abnormal access data deviating from the mainstream pattern can be identified simultaneously, thereby enabling early detection of unknown abnormal behaviors and providing basic input for subsequent threat hunting and security handling.

[0082] Through steps S301 to S303, density clustering identifies clusters of behavioral patterns with highly similar API access structures within a unified metric space. This enables the automatic summarization and structured representation of stable access behavior patterns within the system. Simultaneously, by marking outliers in comparable behavioral representations that do not meet density conditions, abnormal access data deviating from the mainstream behavioral structure can be effectively identified, giving the system the ability to detect unknown abnormal behaviors or potential attack patterns. Based on this process, automatic evolution from behavioral representations to behavioral pattern clusters can be achieved. This enables automatic pattern discovery and anomaly identification of comparable behavioral representations without manual rule configuration, providing a structured input foundation for subsequent behavioral analysis and security policy integration, thereby improving the accuracy and adaptability of API access behavior threat hunting.

[0083] Step S4: Perform behavioral analysis processing on the behavioral pattern clusters and abnormal behavior data based on the clustering results to generate behavioral analysis results.

[0084] Since behavioral pattern clusters typically correspond to stable access behavior structures within a system, while anomalous behavior data may represent access behaviors that deviate from the mainstream patterns, differentiated analysis strategies can be adopted based on different data types. Specifically, for behavioral pattern clusters, pattern matching and reuse of historical conclusions can be prioritized using a behavioral knowledge base to improve analysis efficiency. When no existing pattern is matched, an intelligent analysis agent combined with an API semantic knowledge base can be invoked for semantic reasoning. For anomalous behavior data, in-depth analysis can be performed directly using the intelligent analysis agent to identify unknown anomalous behaviors.

[0085] In an optional embodiment, step S4 specifically includes:

[0086] Step S401: For a behavior pattern cluster, determine the pattern representation vector based on the density distribution of the behavior representation vector in the behavior pattern cluster, and perform similarity matching between the pattern representation vector and the preset behavior knowledge base;

[0087] Step S402: If the match is successful, the historical analysis conclusions associated with the behavior knowledge base are directly reused as the first behavior analysis result;

[0088] Step S403: If the matching fails, the intelligent analysis agent is invoked to perform semantic reasoning on the behavior pattern cluster in conjunction with the API semantic knowledge base, and a second behavior analysis result is generated.

[0089] In this embodiment, step S401 is used to extract pattern representation vectors that can represent the behavioral structure of a given behavior pattern cluster from the clustered behavior pattern clusters, so as to facilitate subsequent knowledge reuse and semantic analysis. The cluster center vector can be calculated based on the distribution of each behavior representation vector in the behavior pattern cluster, and used as the pattern representation vector for that behavior pattern. For example, a representative center vector can be obtained by averaging or density-weighting all behavior representation vectors within the behavior pattern cluster, thereby reflecting the overall characteristics of the cluster in the API access path distribution structure. After obtaining the pattern representation vector, it can be matched with pattern vectors in a preset behavior knowledge base for similarity. For example, the similarity between the current pattern representation vector and each historical pattern vector in the knowledge base can be calculated based on cosine similarity, and a preset similarity threshold can be used to determine whether a known behavior pattern exists.

[0090] When the similarity between a pattern representation vector and a historical pattern representation vector in the behavior knowledge base reaches a preset threshold, the current behavior pattern can be determined to belong to a known behavior category. At this point, analysis conclusions associated with that historical pattern representation vector can be directly retrieved from the behavior knowledge base, such as behavior category identifiers, risk levels, client types, or handling suggestions, and output as the first behavior analysis result. By reusing existing analysis conclusions, the complex semantic analysis process can be avoided by repeatedly calling upon it, thereby reducing computational overhead and improving the efficiency of behavior analysis.

[0091] When a pattern representation vector fails to match a historical pattern representation vector that meets a preset similarity threshold in the behavior knowledge base, the behavior pattern cluster can be identified as a potential novel behavior pattern, triggering the intelligent analysis agent to perform further semantic analysis processing. The intelligent analysis agent can be a semantic analysis agent entity used to perform behavioral semantic parsing and risk reasoning tasks. It is deployed in the security analysis platform and communicates with the API semantic knowledge base.

[0092] The intelligent analysis agent can obtain the normalized API path set and its access structure information contained in the new behavioral pattern cluster, and use the normalized API path as the retrieval key to obtain the corresponding interface semantic description data from the API semantic knowledge base. The API semantic knowledge base can be a pre-built interface semantic information library. Its construction process may include: collecting the actual API call traffic in the business system, extracting typical request samples and response samples from the access logs, and inputting the sample data into the large language model inference component for semantic analysis, thereby automatically generating the functional description, business meaning and parameter description of each API interface, and storing them in a structured form for subsequent behavioral semantic parsing calls.

[0093] During the behavior analysis phase, the intelligent analysis agent can extract sampled traffic data for semantic judgment from the actual call traffic corresponding to the behavior pattern cluster. This sampled traffic data may include information such as request methods, request parameters, request body content, response codes, response fields, or response content. Based on the interface semantic description information and the sampled traffic data, the intelligent analysis agent invokes the large language model inference component to perform semantic association analysis and risk inference processing on the combination relationships, access frequency characteristics, and call order of high-frequency API paths in the behavior pattern cluster. This identifies the business process semantics and potential risk patterns corresponding to the accessing entity within the current time window.

[0094] For example, when a behavioral pattern cluster simultaneously includes high-frequency access paths such as login interfaces, verification code interfaces, and account query interfaces, the intelligent analysis agent can identify the business process semantics corresponding to this access path combination by calling the large language model inference component, and determine whether it conforms to behavioral patterns such as automated script access, batch probing, or abnormal login attempts, thereby generating a second behavioral analysis result. The second behavioral analysis result may include behavioral category identifiers, business semantic description information, risk level assessment results, and handling suggestions, whereby the behavioral category identifier is used to indicate whether the behavioral pattern belongs to normal user behavior, black market behavior, or security incidents, etc. In this way, semantic understanding and risk judgment of unknown behavioral patterns can be achieved without the need for manual rule pre-setting, thereby improving the intelligence and adaptability of the behavioral analysis process.

[0095] In an optional implementation, the similarity threshold in step S401 can be dynamically configured based on the risk tolerance and false positive rate control requirements of the business operation scenario to improve the accuracy of behavior pattern matching. Specifically, within each time window, the maximum similarity score between the pattern representation vector of the behavior pattern cluster and the candidate pattern vector in the behavior knowledge base is recorded, and the handling result and judgment feedback information after the matching reuse are recorded simultaneously. The judgment feedback information is used to indicate whether the reuse conclusion constitutes a false positive or corresponds to a real risk event. Further, the false positive rate index under the current threshold can be calculated within a sliding statistical window, and the false positive rate index is compared with a preset target false positive rate threshold. When the false positive rate index exceeds the target false positive rate threshold, the similarity threshold is increased so that a match is only determined to be successful when the similarity score is higher, thereby reducing the probability of false re-use.

[0096] In another example, when the business side detects an increase in attack loss signals or a rise in the number of high-risk events, the system can lower the similarity threshold to improve the ability to capture potential new behavioral patterns and enhance threat detection sensitivity. Through this dynamic threshold configuration mechanism based on feedback statistics and business risk constraints, the knowledge base matching and reuse process can achieve an adaptive balance between controllable false alarm rates and risk detection capabilities under different business operation scenarios.

[0097] Step S404: For abnormal behavior data, input the access behavior sequence corresponding to the abnormal behavior data into the intelligent analysis agent, and perform semantic reasoning in conjunction with the API semantic knowledge base to generate abnormal behavior analysis results.

[0098] Step S404 is used to perform further semantic analysis and risk assessment on the anomalous behavior data marked as outliers in step S3. Since the anomalous behavior data cannot be categorized into any stable behavior pattern cluster, its access path combinations may deviate from normal business processes. Therefore, the access behavior sequence corresponding to the anomalous behavior data can be used as analysis input and sent to the intelligent analysis agent. The intelligent analysis agent can invoke the large language model inference component and, in conjunction with a pre-built API semantic knowledge base, perform semantic association analysis on the normalized API paths in the access behavior sequence, thereby identifying potential anomalous access logic.

[0099] For example, when an access subject's access behavior sequence within a time window contains a large number of high-frequency interface scanning paths, or exhibits abnormal combinations of calls to login interfaces, CAPTCHA interfaces, and sensitive data query interfaces, the intelligent analysis agent can infer and analyze the business relationships between access paths based on the interface function descriptions and parameter semantic information in the API semantic knowledge base, and determine whether the access behavior belongs to automated probing, interface traversal, or potential attack behavior. Based on the above semantic reasoning process, abnormal behavior analysis results can be generated, which may include abnormal behavior category identifiers, risk level assessment information, and corresponding handling suggestions.

[0100] In some implementations, the abnormal behavior analysis process can also combine access frequency trends, historical access profiles, or contextual time information for comprehensive judgment to improve the accuracy of anomaly identification. Through the above processing, the system can automatically interpret and assess the risks of unknown or low-frequency abnormal access behaviors without pre-defining attack rules, thereby enhancing the adaptability of the threat hunting process and the depth of security analysis.

[0101] Through steps S401-S404, based on generating pattern representation vectors for behavioral pattern clusters and performing knowledge base similarity matching, existing behavioral patterns can be directly associated with historical analysis conclusions, thereby reducing redundant reasoning while maintaining analytical consistency. For behavioral pattern clusters that fail to match, semantic reasoning is performed using an intelligent analysis agent combined with the API semantic knowledge base, enabling the system to automatically perform semantic parsing and risk assessment on newly emerging access patterns. Simultaneously, access behavior sequences corresponding to abnormal behavior data are individually input into the intelligent analysis agent for analysis, allowing low-frequency or structurally anomalous API access behaviors to be independently identified and interpreted. Through these technical means, a continuous data processing chain is formed for API access behavior, from pattern discovery to semantic analysis to risk assessment. This maintains analytical stability while enhancing the ability to interpret and judge complex access behaviors, and improves the automation and analytical efficiency of the overall threat hunting process.

[0102] Step S5: Update the stored behavior analysis results and trigger corresponding security actions based on the behavior analysis results.

[0103] In an optional embodiment, step S5 specifically includes:

[0104] Step S501: For the first behavior analysis result, associate the corresponding behavior pattern cluster with the existing behavior pattern knowledge entries in the behavior knowledge base to avoid repeatedly generating new behavior pattern knowledge entries.

[0105] In this embodiment, when the pattern representation vector corresponding to a behavior pattern cluster can be successfully matched with an existing knowledge entry in the behavior knowledge base, it can be considered that the behavior pattern has been identified by the system and historical analysis conclusions have been established. Therefore, instead of generating new behavior pattern knowledge entries, the identification information of the current behavior pattern cluster is associated with and updated with existing behavior pattern knowledge entries. For example, the behavior pattern cluster ID generated within the current time window can be written into the reference list of the behavior pattern knowledge entry, or the statistical information of the behavior pattern knowledge entry (such as the number of occurrences, recent active time, or confidence score) can be updated, thereby achieving continuous tracking and reuse of existing behavior patterns. In this way, the same behavior pattern can be avoided from being repeatedly entered into the database, reducing knowledge base redundancy and improving subsequent retrieval efficiency and stability.

[0106] In some implementations, for existing behavioral pattern knowledge entries in the behavioral knowledge base, proactive cleanup of knowledge entries that have not been matched for a long time can be avoided. Instead, these behavioral pattern knowledge entries can be continuously retained as candidate benchmarks for subsequent matching. Specifically, when no behavioral pattern cluster corresponding to a certain behavioral pattern knowledge entry is detected within multiple time windows, only the active timestamp of that behavioral pattern knowledge entry can be updated without performing deletion or invalidation processing. In this way, knowledge loss due to periodic changes in business traffic or intermittent occurrences of attack behaviors can be avoided. This allows for direct matching of historical analysis conclusions when similar behavioral patterns reappear, achieving long-term reuse and stable accumulation of knowledge.

[0107] Step S502: For the second behavior analysis result, associate the second behavior analysis result with the corresponding pattern representation vector and store it in the behavior knowledge base to add a behavior pattern knowledge entry and update the retrieval index of the behavior knowledge base.

[0108] In this embodiment, when a behavioral pattern cluster fails to match an existing knowledge entry, the second behavioral analysis result generated by the intelligent analysis agent can be considered as newly discovered behavioral pattern knowledge. Therefore, the second behavioral analysis result and its corresponding pattern representation vector can be structurally stored to form a new behavioral pattern knowledge entry, which is then written back to the knowledge base, allowing for the continuous accumulation and sedimentation of new behavioral knowledge. For example, this behavioral pattern knowledge entry may include fields such as pattern representation vector, behavioral category identifier, business semantic description, risk score, and handling suggestions. Simultaneously, the vector retrieval index of the behavioral knowledge base can be updated based on the pattern representation vector, enabling subsequently generated similar behavioral patterns to quickly match the behavioral pattern knowledge entry through similarity matching, thereby reducing redundant analysis processes and improving the system's knowledge reuse capability.

[0109] Since the evolution of behavioral patterns can be automatically reflected through unsupervised clustering based on time windows, clustering analysis can converge massive API access behaviors into a limited number of behavioral pattern clusters. This allows the intelligent analysis agent to perform semantic reasoning only on new, unmatched behavioral patterns, without having to process each original access log. Therefore, it reduces the scale of large model calls while maintaining analytical accuracy. When behavioral patterns drift, the newly generated behavioral pattern clusters can be automatically identified as drift signals, and new behavioral pattern knowledge entries can be generated through reanalysis. This eliminates the need to build complex drift detection mechanisms, thus achieving adaptive updates to changes in business behavior and the evolution of attack strategies while keeping system computational overhead controllable.

[0110] Step S503: For the abnormal behavior analysis results, persist the abnormal behavior analysis results as abnormal behavior event records, and update the security profile data of the access subject based on the client type information in the abnormal behavior analysis results.

[0111] In this embodiment, for abnormal behavior data that does not belong to a stable behavior pattern cluster, the corresponding abnormal behavior analysis results can be recorded as security events. For example, information such as the occurrence time of the abnormal event, the access subject identifier, the normalized API path combination, the risk level, and the analysis conclusions can be written into an event log database or a security event management system to support subsequent auditing and tracing analysis. In addition, the security profile of the access subject can be updated based on the client type information or behavior tags in the abnormal behavior analysis results, such as adding tags like "high-risk client" or "automated script access," for subsequent behavior assessment or real-time policy decision-making.

[0112] Step S504: Generate a security handling instruction based on at least one of the first behavior analysis result, the second behavior analysis result, and the abnormal behavior analysis result, and send the security handling instruction to the execution end so that the execution end performs access control processing on the access subject.

[0113] In this embodiment, corresponding security handling instructions can be generated based on the risk level and handling suggestions contained in the behavior analysis results. For example, when the risk level is low, access monitoring or rate limiting instructions can be generated; when the risk level reaches a preset threshold, control instructions such as blocking access, forcing secondary identity verification, or CAPTCHA verification can be generated. Security handling instructions can be sent to the execution-end device (such as an API gateway, security protection node, or business server) through message queues, policy interfaces, or control channels to implement real-time access control processing on the corresponding access subject. Through this method, an automated closed loop from behavior analysis results to security policy execution can be achieved, improving the system's response efficiency and handling accuracy for abnormal API access behavior.

[0114] Through steps S501-S504, the behavioral analysis results can be managed and continuously updated in a differentiated manner according to different sources. Specifically, for matched behavioral pattern clusters, they are reused by associating them with existing knowledge entries, reducing knowledge redundancy caused by repeatedly generating new patterns. For newly discovered behavioral patterns, the behavioral knowledge base has continuous expansion and adaptive evolution capabilities by associating and storing the second behavioral analysis results with the pattern representation vector and updating the retrieval index. For abnormal behavioral analysis results, event-based storage and security profile updates enable the system to form long-term behavioral cognition of abnormal access subjects. Based on this, security handling instructions are generated by combining behavioral categories and handling suggestions, and access control processing is implemented in conjunction with the execution end. This allows behavioral analysis results to be directly transformed into executable security policies, thereby realizing a closed-loop processing mechanism from knowledge accumulation and pattern evolution to security response. This improves threat handling efficiency while enhancing the system's continuous adaptability and real-time protection capabilities against complex attack behaviors.

[0115] In summary, the API access behavior threat hunting method provided in this application, by acquiring API access data of accessing entities and constructing access behavior sequences, can uniformly transform discrete access logs into a behavioral data foundation with temporal correlation, providing a consistent and stable input source for subsequent analysis. By constructing a comparable behavioral representation with a unified dimension through vectorization processing and similarity measurement, it achieves standardized expression of access behavior among different accessing entities, thereby reducing the complexity of manual feature design and improving the efficiency and comparability of high-dimensional data processing. Unsupervised clustering analysis is used to automatically discover stable behavioral pattern clusters and identify abnormal behavioral data, enabling the system to identify unknown abnormal access patterns without manual rule configuration. Combining behavioral analysis processing of behavioral pattern clusters and abnormal behavioral data, a closed-loop analysis mechanism combining historical knowledge reuse and semantic analysis is realized. Through the linkage of storing and updating behavioral analysis results with security measures, a closed-loop threat hunting mechanism is formed from data collection, behavioral representation, pattern discovery to knowledge accumulation and policy execution, thereby improving the accuracy, adaptability, and real-time security response capabilities of API access behavior identification.

[0116] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0117] Some embodiments of this application also relate to an API access behavior threat hunting system, which can be deployed in a security analysis platform for internet business systems and performs unified analysis and processing of API access behavior from multiple business nodes based on a distributed computing architecture. (See also...) Figure 2 As shown, it includes:

[0118] The data processing module is used to obtain API access data of the accessing subject and construct access behavior sequences based on the API access data;

[0119] The vector representation module is used to vectorize the access behavior sequence to obtain a behavior representation vector with a unified dimension, and to perform similarity measurement based on the behavior representation vector to form a comparable behavior representation for behavior pattern analysis.

[0120] The pattern analysis module is used to perform unsupervised clustering analysis on comparable behavior representations to obtain clustering results including at least one cluster of behavior patterns and abnormal behavior data.

[0121] The behavior analysis module is used to perform behavior analysis on behavior pattern clusters and abnormal behavior data based on clustering results, in order to generate behavior analysis results.

[0122] The application execution module is used to store and update the behavior analysis results, and trigger corresponding security actions based on the behavior analysis results.

[0123] The modules can interact with each other via message queues, data buses, or internal interfaces to form a complete processing chain from behavioral data collection to security action execution. Through the collaborative work of these modules, the API access behavior threat hunting system can construct an end-to-end behavioral analysis process that includes vector construction, cluster discovery, and a closed loop of knowledge reuse and semantic analysis. By vectorizing access behavior sequences, discrete API access behaviors can be standardized and described in a unified vector space. Based on unsupervised clustering analysis, stable behavioral patterns are automatically discovered and abnormal behavioral data is identified, thereby achieving automatic detection of unknown access patterns. Combining the historical conclusion reuse mechanism of the behavioral knowledge base and the semantic reasoning capabilities of the intelligent analysis agent, unmatched behavioral patterns are semantically parsed and risk assessment results are generated, enabling the system to interpret and judge complex access behaviors. Through this end-to-end processing flow, it can support the identification and handling of abnormal access behaviors such as black market attacks, vulnerability exploitation, and CC attacks, and realize a closed-loop threat hunting mechanism from behavior discovery, semantic analysis to security response.

[0124] The content described in the above embodiments of the API access behavior threat hunting method is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the API access behavior threat hunting method embodiments, and the beneficial effects achieved are also the same as those achieved in the above API access behavior threat hunting method embodiments. To reduce repetition, further details are omitted here.

[0125] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as cellular phones, smartphones, wearable devices, and other similar computing devices.

[0126] The electronic device includes: one or more processors; and a memory storing computer program instructions that, when executed, cause the processor to perform an API access behavior threat hunting method as provided in any one or more of the above embodiments. Figure 3An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0127] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103, and output device 1104 may be connected via a bus or other means. Figure 3 Taking the example of a connection between China and Israel via a bus.

[0128] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0129] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0130] In this embodiment, a computer-readable medium stores a computer program / instructions that, when executed by a processor, implement an API access behavior threat hunting method provided in any one or more of the above embodiments. The computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into that device. The computer-readable medium carries one or more computer-readable instructions.

[0131] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0132] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0133] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0134] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0135] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0136] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0137] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0138] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0139] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or modules recited in a system claim may also be implemented by a single unit or module in software or hardware. Terms such as "first," "second," etc., are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0140] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A method for hunting API access behavior threats, characterized in that, include: Obtain API access data of the accessing entity, and construct an access behavior sequence based on the API access data; The access behavior sequence is vectorized to obtain a behavior representation vector with a unified dimension, and similarity measurement is performed based on the behavior representation vector to form a comparable behavior representation for behavior pattern analysis. Unsupervised clustering analysis is performed on the comparable behavior representations to obtain clustering results including at least one cluster of behavior patterns and abnormal behavior data; Based on the clustering results, behavioral pattern clusters and abnormal behavior data are subjected to behavioral analysis processing to generate behavioral analysis results; The behavior analysis results are stored and updated, and corresponding security actions are triggered based on the behavior analysis results.

2. The API access behavior threat hunting method according to claim 1, characterized in that, The step of obtaining API access data of the accessing subject and constructing an access behavior sequence based on the API access data includes: Collect API access logs and identify the original request paths in the API access logs; The original request path is normalized to obtain a normalized API path; Determine the aggregation key of the access subject, and perform statistical processing on the normalized API paths under the same aggregation key based on a preset time window to generate corresponding access frequency information; The access behavior sequence is constructed based on the normalized API path and the access frequency information.

3. The API access behavior threat hunting method according to claim 1, characterized in that, The steps of vectorizing the access behavior sequence to obtain a behavior representation vector of uniform dimension, and performing similarity measurement based on the behavior representation vector to form comparable behavior representations for behavior pattern analysis include: The normalized API paths in the access behavior sequence are mapped to a vector space of a specified dimension using a preset mapping function to obtain the original feature vector; Based on the access frequency information of each normalized API path in the access behavior sequence, the original feature vector is numerically accumulated. The accumulated original feature vectors are normalized to obtain a behavior representation vector with a modulus of unit length; The distance between different behavior representation vectors is calculated based on a preset similarity metric function to form comparable behavior representations for behavior pattern analysis.

4. The API access behavior threat hunting method according to claim 1, characterized in that, The step of performing unsupervised clustering analysis on the comparable behavior representations to obtain clustering results including at least one cluster of behavior patterns and anomalous behavior data includes: Based on preset neighborhood range parameters and density thresholds, density clustering is performed on the comparable behavior representations; Comparable behavior representations with a number of sample points in their neighborhood not less than the density threshold and their reachable samples in their neighborhood are grouped into the same behavior pattern cluster. Comparable behaviors that are not classified into any behavior pattern cluster are marked as outliers and are considered as anomalous behavior data that are inconsistent with the behavior pattern cluster.

5. The API access behavior threat hunting method according to claim 1, characterized in that, The step of performing behavioral analysis processing on the behavioral pattern clusters and the abnormal behavioral data based on the clustering results to generate behavioral analysis results includes: For the behavior pattern cluster, a pattern representation vector is determined based on the density distribution of the behavior representation vectors in the behavior pattern cluster, and the pattern representation vector is matched with a preset behavior knowledge base for similarity. If a match is successful, the historical analysis conclusions associated with the behavioral knowledge base are directly reused as the first behavioral analysis result; If the match fails, the intelligent analysis agent is invoked to perform semantic reasoning on the behavior pattern cluster in conjunction with the API semantic knowledge base, and a second behavior analysis result is generated. For the abnormal behavior data, the access behavior sequence corresponding to the abnormal behavior data is input into the intelligent analysis agent, and semantic reasoning is performed in conjunction with the API semantic knowledge base to generate abnormal behavior analysis results.

6. The API access behavior threat hunting method according to claim 5, characterized in that, The steps of storing and updating the behavior analysis results, and triggering corresponding security actions based on the behavior analysis results, include: Based on the first behavior analysis result, the corresponding behavior pattern cluster is associated with the existing behavior pattern knowledge entries in the behavior knowledge base to avoid repeatedly generating new behavior pattern knowledge entries. For the second behavior analysis result, the second behavior analysis result is associated with the corresponding pattern representation vector and stored in the behavior knowledge base to add a new behavior pattern knowledge entry and update the retrieval index of the behavior knowledge base; For the abnormal behavior analysis results, the abnormal behavior analysis results are persistently stored as abnormal behavior event records, and the security profile data of the access subject is updated based on the client type information in the abnormal behavior analysis results. Based on at least one of the first behavior analysis result, the second behavior analysis result, and the abnormal behavior analysis result, a security handling instruction is generated and sent to the execution terminal so that the execution terminal performs access control processing on the access subject.

7. An API access behavior threat hunting system, characterized in that, include: The data processing module is used to acquire API access data of the accessing subject and construct an access behavior sequence based on the API access data; The vector representation module is used to vectorize the access behavior sequence to obtain a behavior representation vector with a unified dimension, and to perform similarity measurement based on the behavior representation vector to form a comparable behavior representation for behavior pattern analysis. The pattern analysis module is used to perform unsupervised clustering analysis on the comparable behavior representations to obtain clustering results including at least one behavior pattern cluster and abnormal behavior data. The behavior analysis module is used to perform behavior analysis processing on the behavior pattern clusters and the abnormal behavior data based on the clustering results, so as to generate behavior analysis results; The application execution module is used to store and update the behavior analysis results, and trigger corresponding security actions based on the behavior analysis results.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform the API access behavior threat hunting method as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program and / or instructions stored thereon, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the API access behavior threat hunting method as described in any one of claims 1-6.

10. A computer program product comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the API access behavior threat hunting method as described in any one of claims 1-6.

Images