Automated penetration testing method, apparatus, electronic device, and computer storage medium

Abstract

The application relates to the technical field of network security, in particular to an automatic penetration testing method and device, an electronic device and a computer storage medium, wherein input data of a target system in an authorized penetration testing scene is acquired, the input data is input into a preset target security identification model, a security feature node is generated by identifying a risk event, a first security knowledge data set is obtained, the set is associated with historical test data, a second security knowledge data set is formed, global reasoning is performed based on the second set, a penetration testing execution plan is generated, and a security test action is performed on the target system according to the plan. The application can dynamically adjust a test strategy, reduce resource consumption, and improve test efficiency, stability and controllability.

Description

Technical Field

[0001] This application relates to the field of cybersecurity technology, and in particular to an automated penetration testing method, apparatus, electronic device, and computer storage medium. Background Technology

[0002] Traditional penetration testing methods that rely on human experience are inefficient and costly. Furthermore, the testing process and results are highly dependent on the individual abilities of the testers, making them difficult to reproduce and quantify.

[0003] To improve testing efficiency, existing technologies are increasingly incorporating automation tools and artificial intelligence (AI) to assist security testing. Currently, the main penetration testing techniques fall into the following categories: One type is rule-based or signature-based automated security scanning solutions, which test the target system according to a predefined process. However, these automated scanning solutions have fixed processes and cannot dynamically adjust testing strategies based on the actual feedback from the target system, easily generating a large number of invalid requests. Another type is automated testing solutions based on a single AI model. This model analyzes the target system and generates test behaviors, but a single AI model simultaneously handles analysis, decision-making, and execution tasks, resulting in high resource consumption and poor stability and controllability. A third type is semi-automated penetration testing solutions led by human testers, combined with multiple tools. Summary of the Invention

[0004] To overcome the shortcomings of existing technologies, this invention provides an automated penetration testing method, apparatus, electronic device, and computer storage medium that dynamically adjusts testing strategies, reduces resource consumption, and improves testing efficiency, stability, and controllability.

[0005] A first aspect of this application provides an automated penetration testing method, the method comprising: Obtain the target system's input data in an authorized penetration testing scenario; The target system input data is input into a preset target security identification model. When a risk event is identified, the target security identification model generates a security feature node to obtain a first security knowledge data set. The first security knowledge data set is associated with historical test data to obtain the second security knowledge data set; Based on the second security knowledge data set, a global reasoning is performed to generate a penetration test execution plan for the target system; Security testing actions are performed on the target system according to the penetration testing execution plan.

[0006] In one optional implementation, the target security identification model is a model pre-built based on random forest, the number of base learners of the target security identification model is 100 decision trees, the maximum depth of each tree is 10, the feature sampling ratio is √N features randomly sampled from each tree, and the splitting criterion adopts Gini impurity.

[0007] In an optional implementation, the step of associating the first security knowledge data set with historical test data to obtain the second security knowledge data set includes: The first security knowledge data set is parsed into structured triples; The structured triples are imported into a pre-built security knowledge graph to create inter-entity relationship edges and generate a local subgraph of the current analysis result; the current analysis result is the current risk event, which includes multiple entity nodes. The local subgraph is input into a preset first natural language processing model. The text description of each entity node in the local subgraph is vectorized and encoded by the first natural language processing model to generate the current analysis result vector. Calculate the similarity between the current analysis result vector and the historical data vector of the historical test data, and filter out similar vector pairs with similarity higher than a preset threshold; Extract the historical test records corresponding to the historical test data in the similarity vector pairs, and generate context information based on the current entity node and the historical test records; The structured triples are fused with the context information to generate the second security knowledge data set.

[0008] In an optional implementation, the step of performing global reasoning based on the second security knowledge data set to generate a penetration test execution plan for the target system includes: Extract network topology data and vulnerability data from the second security knowledge dataset; The network topology data is encoded into a target system topology vector, and the vulnerability data is encoded into a vulnerability distribution vector; Multiple potential attack paths and corresponding probability scores are generated based on the target system topology vector and the vulnerability distribution vector; Each potential attack path is broken down into test actions, and a priority score is calculated for each test action. Each test action is sorted from low to high according to the priority score; The sorted sequence of test actions is converted into a standardized execution plan, and the standardized execution plan is determined as the penetration test execution scheme.

[0009] In an optional implementation, the vulnerability data includes at least one vulnerability identifier, the IP address of the affected device, and vulnerability description text, and encoding the vulnerability data into a vulnerability distribution vector includes: The vulnerability description text of each vulnerability in the vulnerability data is segmented into words to generate a word sequence; Each vulnerability's word sequence is input into a pre-defined second natural language processing model, which then generates a vulnerability text vector. Based on the IP addresses of affected devices in the vulnerability data, all vulnerability text vectors belonging to the same device are aggregated to obtain the vulnerability distribution vector.

[0010] In an optional implementation, calculating the priority score for each test action includes: The CVSS score of each vulnerability is obtained from an open-source vulnerability database, the asset criticality coefficient of the target system is obtained from an open-source network topology analysis tool, and the path probability of each test action is obtained from an open-source attack path simulation tool. The CVSS score, the asset criticality coefficient, and the path probability are weighted and summed to output the priority score for each test action.

[0011] In an optional implementation, the method further includes: Obtain the test execution results after the security test actions are performed; The success rate of each test action, the vulnerability distribution of the target system, and the strength of the dependency relationship between each test action are calculated in the test execution results to obtain the summary analysis results; The summarized analysis results are converted into a triple format that satisfies the security knowledge graph, and the triples are written into the security knowledge base.

[0012] A second aspect of this application provides an automated penetration testing apparatus, the apparatus comprising: The data acquisition module is used to acquire the target system input data in authorized penetration testing scenarios. The task analysis module is used to input the target system input data into a preset target security identification model, and generate security feature nodes when a risk event is identified by the target security identification model to obtain a first security knowledge data set. The data association module is used to associate the first security knowledge data set with historical test data to obtain the second security knowledge data set; The plan generation module performs global reasoning based on the second security knowledge data set to generate a penetration test execution plan for the target system. The test execution module is used to perform security test actions on the target system according to the penetration test execution plan.

[0013] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the automated penetration testing method.

[0014] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described automated penetration testing method.

[0015] In summary, the automated penetration testing method, apparatus, electronic device, and computer storage medium provided in this application have at least one of the following beneficial effects: 1. By acquiring the target system input data, inputting the preset target security identification model to generate security feature nodes to obtain the first security knowledge data set, and then associating it with historical test data to obtain the second security knowledge data set, global reasoning is performed to generate a penetration test execution plan and execute security test actions. The whole process is automated, reducing manual operation and improving testing efficiency. 2. Based on a preset model and a series of data association and reasoning operations, an execution plan is generated and the test is executed. The entire process is standardized and regulated. As long as the same target system input data is input and the same process is followed, the same or similar test process and results can be obtained, which is easy to reproduce. At the same time, through the data set and reasoning process, the test process and results can be quantitatively analyzed. For example, based on the global reasoning of the second security knowledge data set, the risks of the target system can be quantitatively assessed, thereby achieving quantitative assessment. 3. By identifying risk events and generating security feature nodes through the target security identification model, and then associating them with historical test data, a penetration test execution plan is generated based on global reasoning on these dynamic data sets. This allows for dynamic adjustment of the test strategy according to the actual situation of the target system, reducing invalid requests. 4. Construct a target security identification model to identify risk events and generate security feature nodes. Generate an execution plan by associating historical data and global reasoning. Decompose tasks such as analysis and decision-making, so that no single model completes all tasks, reducing resource consumption and improving stability and controllability. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating an automated penetration testing method according to an embodiment of this application; Figure 2 This is a schematic diagram illustrating the training of a target security identification model according to an embodiment of this application; Figure 3 This is a functional block diagram of an automated penetration testing device shown in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0017] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0018] The following will clearly and completely describe the concept, specific structure, and technical effects of the present invention in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the scope of protection of the present invention. Furthermore, all connections / linkages involved in the patent do not simply refer to direct contact between components, but rather to the ability to form a better connection structure by adding or reducing connecting accessories according to specific implementation conditions. The various technical features in this invention can be combined interactively without contradicting each other.

[0019] Reference Figure 1 The diagram shown is a flowchart illustrating an automated penetration testing method according to an embodiment of this application. The automated penetration testing method includes the following steps.

[0020] S11, Obtain the target system input data in the authorized penetration testing scenario.

[0021] The target system refers to the target network or information system.

[0022] In some embodiments, in authorized penetration testing scenarios, electronic devices can obtain asset information, network structure information, host and service information, and application fingerprint information of any target network or information system as input data for the target system through network detection modules, interface calls, or storage media.

[0023] S12, the target system input data is input into a preset target security identification model, and when a risk event is identified by the target security identification model, a security feature node is generated to obtain a first security knowledge data set.

[0024] Once the target system input data is acquired, the electronic device can input the target system input data into a preset target security identification model. The target security identification model then analyzes and processes the target system based on the input data, identifying potential attack surfaces, abnormal configuration characteristics, and risk clues, forming a security knowledge data set MT containing multiple security feature nodes. The target security identification model is pre-trained using a random forest. For ease of understanding, the following will illustrate this further. Figure 2 The specific training process for the target security identification model is explained. Figure 2 This is a schematic diagram illustrating the training of a target security identification model according to an embodiment of this application: S21, Selection and Construction of Security Identification Model.

[0025] In this step, the electronic device can use a lightweight machine learning model based on Random Forest as the initial security identification model for the classification and anomaly detection of structured security feature data.

[0026] The training parameters of the initial security identification model can be predetermined, including the number of base learners (n_estimators), the maximum depth of each tree (max_depth), and the feature sampling ratio. In this step, the number of base learners can be set to 100 decision trees (the optimal value is determined through cross-validation); the maximum depth of each tree is set to 10 (to prevent overfitting); the feature sampling ratio is set to random sampling of √N per tree (based on the heuristic rule of the square root of the feature dimension, where N is the total feature dimension, N=20); and the splitting criterion is set to Gini impurity, which is suitable for classification tasks.

[0027] S22, Obtain historical penetration test data.

[0028] Electronic devices can obtain historical penetration test data by extracting known vulnerability features from historical penetration test reports (labeled normal / abnormal configurations), public vulnerability databases (such as CVE, NVD), and synthetic data generated by simulating attack scenarios (covering weak passwords, unauthorized access, etc.). This includes normal configuration samples (labeled 0) and anomalous configuration samples (labeled 1). The anomalous configuration samples are configured with known vulnerabilities (such as CVE-2021-44228) or violate security policies (such as empty SSH passwords).

[0029] The historical penetration test data was divided into training set, validation set and test set, with the ratio of training set: validation set: test set = 70%: 15%: 15%.

[0030] S23, Feature Extraction.

[0031] The feature dimensions include at least 20 fields such as port open status, service version, protocol type, and permission settings. Electronic devices can extract 20 key features from the training set, as shown in Table 1 below: Categorical features (such as service version) are one-hot encoded to convert them into binary vectors (e.g., HTTP → [1,0,0], FTP → [0,1,0]). Numerical features (such as port number) are normalized, for example by scaling to the [0,1] range through min-max normalization (e.g., port 22 → 0.1, port 8080 → 0.8).

[0032] In addition, electronic devices can also eliminate features with relevance below a threshold (such as 0.05) based on the feature importance score of random forest.

[0033] S24, Initial security identification model training.

[0034] First, an initial security identification model is initialized. Then, 100 decision trees are generated iteratively based on the extracted key features. Specifically, a subset of the dataset is constructed by randomly sampling (with replacement) from the training set. The nodes of the subset are recursively split until the maximum depth is reached or the node purity is ≥95%.

[0035] The predictions from all trees are integrated, and the final classification is determined by majority vote.

[0036] S25, Post-training model validation and optimization.

[0037] The evaluation metrics are determined, including accuracy, recall, and F1 score. Accuracy represents the percentage of correctly classified samples, recall represents the percentage of outliers detected (a key metric for optimization), and the F1 score represents a comprehensive metric that balances accuracy and recall.

[0038] The trained initial security identification model is identified as the target security identification model and exported as a lightweight format (such as PMML) and integrated into the task analysis module.

[0039] After obtaining the target system input data through step S11, the electronic device first parses the target system input data into a structured format and extracts key features (such as open ports, service versions, and system patch status). The preprocessed key features are then input into a trained target security identification model. The model determines whether each feature is abnormal (e.g., port 22 is open but SSH login source IP is not restricted). For each identified abnormal or risky feature (e.g., the "MySQL weak password" risk event), a corresponding security feature node is generated. The node attributes include feature type (e.g., "configuration defect"), risk level (high / medium / low), and associated asset ID. For example, if the input key feature includes "Apache 2.4.7 version," the model compares the version number with the CVE vulnerability database in the knowledge base and generates the node {Feature ID: CVE-2017-7679, Type: Known Vulnerability, Risk Level: High}. All security feature nodes are integrated by asset ID to form a hierarchical data structure (e.g., JSON or XML format), resulting in the security knowledge data set MT. For ease of distinction, the security knowledge data set MT is referred to as the first security knowledge data set. MT describes the current testable security status of the target system, for example: MT = { "Asset ID_001": [ {"Specimen ID": "CVE-2017-7679", "Type": "Known Vulnerability", "Risk Level": "High"}, {"Feature ID": "SSH_Weak_Auth", "Type": "Configuration Defect", "Risk Level": "Medium"} ], "Asset ID_002": [...] } S13, associate the first security knowledge data set with the historical test data to obtain the second security knowledge data set.

[0040] Furthermore, the electronic device can also write the security knowledge data set MT into the security knowledge base, which includes a knowledge graph-based data storage structure and a retrieval enhancement generation module. By associating the current analysis results with historical test data, vulnerability knowledge, and attack path information, a security knowledge data set MK with contextual relationships is formed.

[0041] In an optional implementation, the step of associating the first security knowledge data set with historical test data to obtain the second security knowledge data set includes: The first security knowledge data set is parsed into structured triples; The structured triples are imported into a pre-built security knowledge graph to create inter-entity relationship edges and generate a local subgraph of the current analysis result; the current analysis result is the current risk event, which includes multiple entity nodes. The local subgraph is input into a preset first natural language processing model. The text description of each entity node in the local subgraph is vectorized and encoded by the first natural language processing model to generate the current analysis result vector. Calculate the similarity between the current analysis result vector and the historical data vector of the historical test data, and filter out similar vector pairs with similarity higher than a preset threshold; Extract the historical test records corresponding to the historical test data in the similarity vector pairs, and generate context information based on the current entity node and the historical test records; The structured triples are fused with the context information to generate the second security knowledge data set.

[0042] In some implementations, electronic devices parse each security feature node in the knowledge graph (MT) into structured triples. Each triple contains an entity (e.g., vulnerability, asset, attack path), a relationship type (e.g., "impact," "exploitation," "co-occurrence"), and associated attributes (e.g., CVE number, CVSS score, attack step description). For example, the node {Feature ID: CVE-2017-7679, Type: Known Vulnerability, Risk Level: High} is converted into triples (CVE-2017-7679, Associated Asset, Asset ID_001) and (CVE-2017-7679, Vulnerability Type, Buffer Overflow). Nodes are mapped to knowledge graph entities using predefined regular expressions, and node attributes are stored as entity attributes. Associated attributes (e.g., vulnerability type, CVSS score) are extracted from the vulnerability knowledge base to ensure consistent data format.

[0043] Next, the triples are imported into a storage structure based on a security knowledge graph. This security knowledge graph is constructed using the Neo4j graph database, which defines security entity types (assets such as servers and routers), vulnerabilities such as servers and routers, attack paths (such as "phishing email → privilege escalation → lateral movement"), relationship types (associated asset-vulnerability), containment (asset-asset), exploitation (vulnerability-attack path)), and attribute fields (asset ID, vulnerability risk level, attack path success rate, timestamp). The Neo4j graph database uses nodes to represent entities (such as vulnerabilities, assets, and attack paths) and edges to represent relationships (such as "impact," "exploitation," and "co-occurrence"). Cypher query language dynamically creates relationship edges between entities (e.g., if a vulnerability affects multiple assets, a "vulnerability-impact-asset" edge is created and the scope of impact is marked), generating a local subgraph with the current analysis results (i.e., currently detected risk events, such as vulnerabilities and high-risk assets) as core nodes, including related assets, historical vulnerabilities, and potential attack paths (e.g., current analysis result = asset ID_001 + CVE-2023-4567 + attack event ID_123). For example, if the analysis result shows that asset ID_001 has an unpatched SQL injection vulnerability, then asset ID_001 and CVE-2023-4567 (SQL injection vulnerability) become the core nodes of the subgraph.

[0044] Furthermore, the local subgraph is input into a pre-defined natural language processing model, namely the BERT language model (referred to as the first natural language processing model for ease of distinction). The language model vectorizes the text descriptions (such as vulnerability descriptions and attack steps) of each entity node (e.g., vulnerability nodes, asset nodes, and attack event nodes) in the current analysis result of the subgraph, generating corresponding vectors. For example, the vulnerability description vector is [0.1, 0.3, ..., 0.8] (768 dimensions), and the attack event description vector is [0.2, 0.4, ..., 0.7] (768 dimensions). The vectors of all entity nodes are then weighted and averaged or concatenated to generate a comprehensive vector representing the current analysis result, called the current analysis result vector. For example, the current analysis result vector = 0.6 × vulnerability vector + 0.3 × attack event vector + 0.1 × asset vector.

[0045] Calculate the cosine similarity between the current analysis result vector and the pre-stored historical data vectors in the historical test data, and filter similar vector pairs with a similarity higher than a preset threshold (e.g., 0.85). For each similar vector pair, extract the unique identifier of the historical entity vector (e.g., the CVE ID of a historical vulnerability, the event ID of a historical attack event). Based on the identifier, query the complete historical test records from the historical database, including vulnerability exploitation events (attack time, attacker, exploited vulnerability, affected assets, attack steps) and remediation solutions (patch version, configuration modification, verification results, rollback steps). Then, generate context information based on the current entity ID of the current analysis result and the historical test records, in the format {current entity ID: [associated historical record 1, associated historical record 2, ...]}. For example, { "CVE-2023-4567": [ { "event_id": "ATT-2022-123", "attack_time": "2022-05-10", Steps: SQL Injection → Privilege Escalation → Data Leakage "remediation": "Upgrade the web framework to v2.5.1" } ] } Finally, the structured data in the security knowledge graph is fused with the retrieved contextual information to generate a security knowledge data set MK. This contextual information set is then embedded as an additional field into the output of the current analysis result (such as a JSON report or knowledge graph node attributes), resulting in a security knowledge data set MK with contextual relationships. For ease of distinction, this contextual security knowledge data set MK is referred to as the second security knowledge data set, for example: MK = { "Asset ID_001": { "Related Vulnerabilities": ["CVE-2017-7679", "CVE-2021-44228"], Attack path: ["Phishing email → Privilege escalation → Lateral movement"], "Contextual Attributes": {"Last Test Time": "2026-03-20", "Risk Level": "High Risk"} } } Among them, MK supports semantic queries of the enhanced generation module. For example, if you input "high-risk vulnerability of asset ID_001", it will return the associated CVE number and attack path details.

[0046] S14, perform global reasoning based on the second security knowledge data set to generate a penetration test execution plan for the target system.

[0047] Based on the MK data generated in step S13 above, the strategy generation module calls a large model (such as a customized security inference engine based on the LLaMA-2 architecture) to perform global inference analysis and generate an executable penetration testing strategy and execution plan (MP).

[0048] In an optional implementation, the step of performing global reasoning based on the second security knowledge data set to generate a penetration test execution plan for the target system includes: Extract network topology data and vulnerability data from the second security knowledge dataset; The network topology data is encoded into a target system topology vector, and the vulnerability data is encoded into a vulnerability distribution vector; Multiple potential attack paths and corresponding probability scores are generated based on the target system topology vector and the vulnerability distribution vector; Each potential attack path is broken down into test actions, and a priority score is calculated for each test action. Each test action is sorted from low to high according to the priority score; The sorted sequence of test actions is converted into a standardized execution plan, and the standardized execution plan is determined as the penetration test execution scheme.

[0049] In some embodiments, the electronic device first extracts network topology data and vulnerability data from the security knowledge dataset MK, wherein the network topology data can be represented as follows: { "devices": [ {"ip": "10.0.0.1", "type": "Web server", "services": ["HTTP:80", "SSH:22"]}, {"ip": "10.0.0.2", "type": "database", "services": ["MySQL:3306"]} ], "connections": [ {"source": "10.0.0.1", "target": "10.0.0.2", "protocol": "TCP"} ] } Vulnerability data includes identification information for at least one vulnerability (such as CVE ID), the IP address of the affected device, and a vulnerability description text. Vulnerability data can be presented as follows: { "vulnerabilities": [ {"cve_id": "CVE-2023-1234", "cvss": 9.8, "affected_ip": "10.0.0.1","description": "SQL injection vulnerability"}, {"cve_id": "CVE-2023-5678", "cvss": 7.5, "affected_ip": "10.0.0.2","description": "weak password"} ] } Next, a graph neural network (GNN) is used to encode the device connectivity into a 128-dimensional vector, obtaining the target system topology vector. For example: Web server (10.0.0.1): [0.12, -0.45, ..., 0.78]; Database (10.0.0.2): [-0.33, 0.89, ..., -0.12]. Simultaneously, the description text of each vulnerability is segmented using NLTK or Jieba word segmentation tools to generate word sequences. The word sequence of each vulnerability is then input into a pre-defined natural language processing model (such as BERT, RoBERTa, or their variants; for ease of distinction, this is referred to as the second natural language processing model) to generate a fixed-dimensional vulnerability text vector (e.g., 768-dimensional). The second natural language processing model is trained in the following way: Use vulnerability description texts from publicly available vulnerability databases (such as NVD, CVE Details) as training corpus; Optimize model parameters using masked language modeling (MLM) or contrastive learning tasks so that the generated vectors can capture the semantic features of vulnerabilities (such as attack type and scope of impact).

[0050] Then, based on the IP addresses of the affected devices in the vulnerability data, all vulnerability text vectors belonging to the same device are aggregated (e.g., by taking the arithmetic mean or weighted average) to obtain the vulnerability distribution vector. For example: Web server vulnerability vector: avg(BERT("CVE-2023-1234..."), ...); Database vulnerability vector: avg(BERT("CVE-2023-5678..."), ...).

[0051] Furthermore, electronic devices can obtain CVSSv3.1 scores for vulnerabilities from open-source vulnerability databases (such as NVD and CVE Details), which include a basic set of metrics (Exploitability and Impact) and an environmental set of metrics (ModifiedBase Metrics); and obtain the AssetCriticism coefficient of the target system from open-source network topology analysis tools (such as OpenNMS and Zabbix), which is calculated using the following formula: ; in, The preset weights are (e.g., database = 0.4, web server = 0.3, test server = 0.1), and the Attribute is the asset attribute value (e.g., data sensitivity, business continuity requirements). The path probability of the test action is obtained from open-source attack path simulation tools (such as Metasploit and Caldera). The probability is obtained by statistically analyzing the path success rate of 10,000 simulated attacks using the Monte Carlo tree search algorithm.

[0052] For each test action, calculate the PriorityScore using the following formula: PriorityScore=α×CVSS+β×PathProbability+γ×AssetCriticality; Where α, β and γ are preset weight coefficients, satisfying α+β+γ=1; CVSS is the CVSS v3.1 score of the vulnerability, with a value range of [0,10]; PathProbability is the path probability, with a value range of [0,1]; AssetCriticism is the asset criticality coefficient, with a value range of [1,5].

[0053] Furthermore, the calculated PriorityScores are sorted in descending order to generate a test action execution sequence, which is then converted into a standardized MP file, i.e., a penetration test execution plan MP, for example: { "MP_ID": "PT-20231001-002", "actions": [ { "id": "ACT-001", "type": "SQL injection test", "tool": "SQLMap#1.6#stable", "target": "10.0.0.1:80 / login", "priority": 7.38, "timeout": 300, "dependencies": ["ACT-000"], # Dependency front-end scan "rollback": "Clears test requests from the web logs" } ] } In some embodiments, if the target system has real-time threat intelligence (such as TTPs associated with the MITRE ATT&CK framework), the weights are adjusted according to the following rules: When a TTP associated with the current action (such as T1190 - Utilizing Public Tools) is detected, α increases by 0.1; When lateral movement is detected (such as T1210-remote service exploitation), β increases by 0.1; The adjusted weights need to be renormalized to ensure that α+β+γ=1.

[0054] S15, Perform security testing actions on the target system according to the penetration testing execution plan.

[0055] In some embodiments, after obtaining the test execution plan (MP), corresponding security testing actions are performed on the target system according to the execution plan. These testing actions include, but are not limited to, sending probe requests, simulating interactive behaviors, and collecting test results. The execution results generated during the test are recorded in real time.

[0056] Specifically, the electronic device can parse the penetration test execution plan (MP), which contains a sequence of test actions and dependencies. These test actions include sending probe requests, simulating interactive behavior, and collecting test results. A directed acyclic graph (DAG) is generated based on the dependencies in the MP, and the execution order of the test actions is determined using a topology sorting algorithm to generate corresponding scheduling instructions. These instructions include the test action ID, target system address, tool parameters, and a timeout threshold (default: 30 seconds). Pre-defined probe packets are sent to the target system by calling open-source network probing tools (such as Nmap 7.93). These probe packets include ICMP Ping, TCP SYN scans, and UDP port probes. TTPs (such as T1190 - Exploiting Public Tools) from open-source attack payload libraries (such as Metasploit Framework 6.4.0) are loaded to simulate the interaction between the attacker and the target system. The target system's response data, including HTTP status codes, network latency, and system log fragments, is captured in real time using open-source log analysis tools (such as ELK Stack 8.12.0).

[0057] The electronic device can then encapsulate the collected test results into JSON format and store them in an open-source time-series database (such as InfluxDB 2.7.0), including: { "action_id": "EXP-001", "timestamp": "2024-03-01T14:30:22Z", "target": "192.168.1.100:80", "response": {"status_code": 404, "latency_ms": 120}, "tool": "Nmap#7.93" } If the test action times out or fails, the electronic device generates an exception log and triggers the rollback mechanism of the process orchestration module. The rollback mechanism includes terminating subsequent dependent actions and generating an alarm notification.

[0058] In an optional implementation, the method further includes: Obtain the test execution results after the security test actions are performed; The success rate of each test action, the vulnerability distribution of the target system, and the strength of the dependency relationship between each test action are calculated in the test execution results to obtain the summary analysis results; The summarized analysis results are converted into a triple format that satisfies the security knowledge graph, and the triples are written into the security knowledge base.

[0059] In some embodiments, the electronic device can continuously monitor the test execution results of security test actions, including test action ID, target system identifier, response status code, network latency, and exception logs.

[0060] The success rate (number of successful executions / total number of executions), vulnerability distribution of the target system (proportion of high-risk response codes by port / service type), and dependency strength between test actions (based on the co-occurrence frequency of actions in the DAG) are calculated using aggregation analysis algorithms (such as group statistics based on Pandas). The success rate of each test action, vulnerability distribution of the target system, and dependency strength between test actions are then used as the summary analysis results.

[0061] The summary analysis results are converted into a knowledge graph triple format (e.g., <Test Action ID, Association Vulnerability, Confidence>), whereby the confidence is calculated using the following formula: Confidence level = (Number of high-risk responses / Total number of executions) × 100%.

[0062] Call the security knowledge graph update interface (such as the Cypher statement in Neo4j 5.12.0) to write the triples into the security knowledge base and update the following structure: Nodes: Test actions, vulnerabilities, target system; Edge: Test action → Associate vulnerability (weight = confidence level), target system → Contain vulnerability (weight = vulnerability severity level).

[0063] Based on the updated security knowledge graph, the priority of subsequent test actions is predicted using a graph neural network (GNN) model (such as PyTorch Geometric 2.5.0). The priority scoring formula is as follows: Priority = α × historical success rate + β × target system vulnerability weight + γ × dependency strength; Among them, α, β and γ are adjustable parameters (satisfying α+β+γ=1, with default values ​​of 0.4, 0.4 and 0.2 respectively).

[0064] Test actions are scheduled for execution based on their priority. For example, EXP-003 has a priority of 0.74, which is higher than other actions, so it is scheduled for execution first.

[0065] Through the above optional implementation methods, by continuously monitoring and aggregating test results, summary data containing success rate, vulnerability distribution and dependency relationships is generated. After being converted into knowledge graph triples, the knowledge base is updated. Combined with the GNN model to predict the priority of test actions, the test strategy is dynamically optimized, thereby improving the efficiency of penetration testing and the accuracy of vulnerability discovery.

[0066] Reference Figure 3 The diagram shown is a functional block diagram of an automated penetration testing device according to an embodiment of this application.

[0067] In some embodiments, the automated penetration testing device 30 may include multiple functional modules composed of computer program segments. The computer programs for each program segment of the automated penetration testing device 30 may be stored in the memory of an electronic device and executed by at least one processor to perform (see details). Figure 1 (Description) The function of automated penetration testing. Based on the functions it performs, it can be divided into multiple functional modules. These functional modules may include: a data acquisition module 301, a task analysis module 302, a data association module 303, a plan generation module 304, and a test execution module 305. The module referred to in this application is a series of computer program segments that can be executed by at least one processor and perform a fixed function, stored in memory. In this embodiment, the functions of each module will be detailed in subsequent embodiments.

[0068] The data acquisition module 301 is used to acquire target system input data of the target system in the authorized penetration testing scenario.

[0069] The task analysis module 302 is used to input the target system input data into a preset target security identification model, and generate security feature nodes when a risk event is identified by the target security identification model to obtain a first security knowledge data set.

[0070] The data association module 303 is used to associate the first security knowledge data set with historical test data to obtain a second security knowledge data set.

[0071] The plan generation module 304 performs global reasoning based on the second security knowledge data set to generate a penetration test execution plan for the target system.

[0072] The test execution module 305 is used to perform security test actions on the target system according to the penetration test execution plan.

[0073] It should be understood that the various variations and specific embodiments of the automated penetration testing method provided in the above embodiments are also applicable to the automated penetration testing device of this embodiment. Through the foregoing detailed description of the automated penetration testing method, those skilled in the art can clearly understand the implementation method of the automated penetration testing device in this embodiment. For the sake of brevity, it will not be described in detail here.

[0074] See Figure 4 The diagram shown is a schematic representation of the structure of an electronic device according to an embodiment of this application. In a preferred embodiment of this application, the electronic device 4 includes a memory 41, at least one processor 42, and at least one communication bus 43.

[0075] Those skilled in the art should understand that Figure 4 The structure of the electronic device shown does not constitute a limitation of the embodiments of this application. It can be a bus structure or a star structure. The electronic device 4 may also include more or fewer other hardware or software than shown, or different component arrangements.

[0076] In some embodiments, the electronic device 4 is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), digital processors, and embedded devices. The electronic device 4 may also include user equipment, which includes, but is not limited to, any electronic product capable of human-computer interaction with a user via a keyboard, mouse, remote control, touchpad, or voice control device, such as a personal computer, tablet computer, smartphone, or digital camera.

[0077] In the embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, computer-readable storage media, and electronic devices can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple components or modules may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices, components, or modules may be electrical, mechanical, or other forms.

[0078] The components described as separate parts may or may not be physically separate. The components shown as components may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the components can be selected to achieve the purpose of this embodiment according to actual needs.

[0079] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each component can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

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

[0081] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0082] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0083] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. An automated penetration testing method, characterized in that, The method includes: Obtain the target system's input data in an authorized penetration testing scenario; The target system input data is input into a preset target security identification model. When a risk event is identified, the target security identification model generates a security feature node to obtain a first security knowledge data set. The first security knowledge data set is associated with historical test data to obtain the second security knowledge data set; Based on the second security knowledge data set, a global reasoning is performed to generate a penetration test execution plan for the target system; Security testing actions are performed on the target system according to the penetration testing execution plan.

2. The automated penetration testing method according to claim 1, characterized in that, The target security identification model is a model pre-built based on random forest. The number of base learners in the target security identification model is 100 decision trees, the maximum depth of each tree is 10, the feature sampling ratio is √N features randomly sampled from each tree, and the splitting criterion adopts Gini impurity.

3. The automated penetration testing method according to claim 1, characterized in that, The step of associating the first security knowledge data set with historical test data to obtain the second security knowledge data set includes: The first security knowledge data set is parsed into structured triples; The structured triples are imported into a pre-built security knowledge graph to create inter-entity relationship edges and generate a local subgraph of the current analysis result; the current analysis result is the current risk event, which includes multiple entity nodes. The local subgraph is input into a preset first natural language processing model. The text description of each entity node in the local subgraph is vectorized and encoded by the first natural language processing model to generate the current analysis result vector. Calculate the similarity between the current analysis result vector and the historical data vector of the historical test data, and filter out similar vector pairs with similarity higher than a preset threshold; Extract the historical test records corresponding to the historical test data in the similarity vector pairs, and generate context information based on the current entity node and the historical test records; The structured triples are fused with the context information to generate the second security knowledge data set.

4. The automated penetration testing method according to claim 1, characterized in that, The step of generating a penetration test execution plan for the target system based on the second security knowledge data set through global reasoning includes: Extract network topology data and vulnerability data from the second security knowledge dataset; The network topology data is encoded into a target system topology vector, and the vulnerability data is encoded into a vulnerability distribution vector; Multiple potential attack paths and corresponding probability scores are generated based on the target system topology vector and the vulnerability distribution vector; Each potential attack path is broken down into test actions, and a priority score is calculated for each test action. Each test action is sorted from low to high according to the priority score; The sorted sequence of test actions is converted into a standardized execution plan, and the standardized execution plan is determined as the penetration test execution scheme.

5. The automated penetration testing method according to claim 4, characterized in that, The vulnerability data includes at least one vulnerability identifier, the IP address of the affected device, and a vulnerability description text. Encoding the vulnerability data into a vulnerability distribution vector includes: The vulnerability description text of each vulnerability in the vulnerability data is segmented into words to generate a word sequence; Each vulnerability's word sequence is input into a pre-defined second natural language processing model, which then generates a vulnerability text vector. Based on the IP addresses of affected devices in the vulnerability data, all vulnerability text vectors belonging to the same device are aggregated to obtain the vulnerability distribution vector.

6. The automated penetration testing method according to claim 4, characterized in that, The calculation of the priority score for each test action includes: The CVSS score of each vulnerability is obtained from an open-source vulnerability database, the asset criticality coefficient of the target system is obtained from an open-source network topology analysis tool, and the path probability of each test action is obtained from an open-source attack path simulation tool. The CVSS score, the asset criticality coefficient, and the path probability are weighted and summed to output the priority score for each test action.

7. The automated penetration testing method according to claim 2, characterized in that, The method further includes: Obtain the test execution results after the security test actions are performed; The success rate of each test action, the vulnerability distribution of the target system, and the strength of the dependency relationship between each test action are calculated in the test execution results to obtain the summary analysis results; The summarized analysis results are converted into a triple format that satisfies the security knowledge graph, and the triples are written into the security knowledge base.

8. An automated penetration testing device, characterized in that, The device includes: The data acquisition module is used to acquire the target system input data in authorized penetration testing scenarios. The task analysis module is used to input the target system input data into a preset target security identification model, and generate security feature nodes when a risk event is identified by the target security identification model to obtain a first security knowledge data set. The data association module is used to associate the first security knowledge data set with historical test data to obtain the second security knowledge data set; The plan generation module performs global reasoning based on the second security knowledge data set to generate a penetration test execution plan for the target system. The test execution module is used to perform security test actions on the target system according to the penetration test execution plan.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the automated penetration testing method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the automated penetration testing method according to any one of claims 1 to 7.

Images