Method, device and medium for generating and verifying vulnerability rules based on intermediate components

Abstract

This disclosure provides a method, device, and medium for vulnerability rule generation and verification based on an intermediate component, relating to the field of computer technology, particularly artificial intelligence and network security. The specific implementation scheme includes: running the simulation environment constructed through the intermediate component; converting a vulnerability scanner tool template into an executable vulnerability detection service within the simulation environment, wherein the vulnerability detection service is a simulated service executed by a vulnerable web server; generating vulnerability detection rules in the simulation environment based on the vulnerability scanner tool template; and verifying the validity of the rules in the simulation environment based on the vulnerability detection rules and the vulnerability detection service.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the fields of artificial intelligence and cybersecurity. Background Technology

[0002] Web vulnerability exploitation is a common attack method used by attackers to intrude into networks. In network security operations, to shorten the emergency response time for web vulnerability detection, it is necessary to respond quickly and generate targeted vulnerability detection rules for web vulnerabilities. Summary of the Invention

[0003] This disclosure provides a method, device, and medium for generating and verifying vulnerability rules based on intermediate components.

[0004] According to one aspect of this disclosure, a method for generating and verifying vulnerability rules based on an intermediate component is provided. The intermediate component is used to construct a simulated environment for generating and verifying vulnerability rules that supports dynamic interaction. The method includes: Run the simulation environment built through the intermediate components; In the simulated environment, the vulnerability scanner tool template is converted into an executable vulnerability detection service, which is a simulated service used to simulate the execution of a vulnerable web server; Vulnerability detection rules are generated in the simulated environment based on the vulnerability scanner tool template. In the simulated environment, the validity of the vulnerability detection rules is verified according to the vulnerability detection service.

[0005] According to another aspect of this disclosure, an intermediate component is provided, comprising: A web simulation service generator based on a large language model is used to receive vulnerability scanner tool templates, parse the vulnerability scanner tool templates, and convert the vulnerability scanner tool templates into executable vulnerability detection services. The vulnerability detection services are simulation services used to simulate the execution of a web server with vulnerabilities. A vulnerability rule generator based on a large language model is used to generate vulnerability detection rules based on the vulnerability scanner tool template, and to verify the validity of the rules based on the vulnerability detection rules and the vulnerability detection service.

[0006] According to another aspect of this disclosure, a vulnerability rule generation and verification apparatus based on an intermediate component is provided. The intermediate component is used to construct a simulated environment for vulnerability rule generation and verification that supports dynamic interaction. The apparatus includes: A runtime module for running the simulation environment constructed through the intermediate components; The simulation service generation module is used to convert a vulnerability scanner tool template into an executable vulnerability detection service in the simulation environment. The vulnerability detection service is a simulation service used to simulate the execution of a vulnerable web server. The rule generation module is used to generate vulnerability detection rules based on the vulnerability scanner tool template in the simulated environment; The verification module is used to verify the validity of the vulnerability detection rules in the simulated environment based on the vulnerability detection rules and the vulnerability detection service.

[0007] According to another aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and The memory is communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method provided in any embodiment of this disclosure.

[0008] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform a method provided according to any embodiment of this disclosure.

[0009] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method provided according to any embodiment of this disclosure.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a schematic diagram of a distributed cluster processing scenario according to an embodiment of the present disclosure; Figure 2 This is a flowchart illustrating a vulnerability rule generation and verification method based on an intermediate component according to an embodiment of this disclosure. Figure 3 This is a flowchart illustrating another vulnerability rule generation and verification method based on an intermediate component according to an embodiment of this disclosure; Figure 4 This is a flowchart illustrating another vulnerability rule generation and verification method based on an intermediate component according to an embodiment of this disclosure; Figure 5This is a flowchart illustrating another vulnerability rule generation and verification method based on an intermediate component according to an embodiment of this disclosure; Figure 6 This is a schematic diagram of the composition structure of an intermediate component according to an embodiment of the present disclosure; Figure 7 This is a schematic diagram illustrating the request-processing-response interaction based on a Web Mock Server in an application example according to an embodiment of this disclosure; Figure 8 This is a schematic diagram of the request flow for an OOB out-of-band request in an application example according to an embodiment of this disclosure; Figure 9-10 This is a schematic diagram illustrating the verification process of a vulnerability service generated by the LLM-WebMockServer generator based on a WebMock Server in an application example according to an embodiment of this disclosure. Figure 11-12 This is a flowchart illustrating the process of the LLM-Suricata rule generator interacting with a vulnerability service generated by a WebMock Server to verify rules in an application example according to an embodiment of this disclosure. Figure 13 This is a schematic diagram illustrating the process of updating scheduling rules via an LLM-task scheduler in an application example according to an embodiment of this disclosure; Figure 14 This is a schematic diagram of the composition structure of a vulnerability rule generation and verification device based on an intermediate component according to an embodiment of the present disclosure; Figure 15 This is a block diagram of an electronic device used to implement the vulnerability rule generation and verification method based on intermediate components according to embodiments of the present disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] In this document, the term "and / or" merely describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. The term "at least one" in this document indicates any combination of at least two of a plurality of elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C. The terms "first" and "second" in this document refer to and distinguish between multiple similar technical terms, not to restrict the order or to limit there to only two. For example, "first feature" and "second feature" refer to two categories / two features; the first feature can be one or more, and the second feature can also be one or more.

[0014] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0015] According to embodiments of this disclosure, Figure 1 This is a schematic diagram of a distributed cluster processing scenario according to an embodiment of the present disclosure. The distributed cluster system is an example of a cluster system, and the diagram exemplarily describes a method for generating and verifying vulnerability rules based on intermediate components that can be used with this distributed cluster system. This disclosure is not limited to methods for generating and verifying vulnerability rules based on intermediate components on a single machine or multiple machines; using distributed processing can further improve the efficiency of such methods. Figure 1 As shown, this distributed cluster system includes multiple nodes (such as server cluster 101, server 102, server cluster 103, server 104, and server 105; server 105 can also connect to electronic devices, such as mobile phone 1051 and desktop computer 1052). These nodes, as well as the nodes and connected electronic devices, can collaboratively execute one or more vulnerability rule generation and verification tasks based on intermediate components. Optionally, the multiple nodes in this distributed cluster system can adopt a data-parallel approach to vulnerability rule generation and verification based on intermediate components. This allows multiple nodes to execute vulnerability rule generation and verification tasks based on intermediate components using the same data processing method. Furthermore, one or more processing logics from the data processing method can be distributed across multiple nodes to collaboratively complete the vulnerability rule generation and verification tasks based on intermediate components.

[0016] The technical terms used in this disclosure are explained below: 1. Nuclei Templates: A customized vulnerability scanner tool based on YAML syntax templates, used to simulate web vulnerability attacks and construct web vulnerability attack requests. Each Nuclei template in the Nuclei template library clearly describes the characteristics of the HTTP request (or other protocol request) to be sent, and how to determine the existence of a vulnerability from the response (i.e., whether it matches vulnerability detection rules). Due to its templated design, Nuclei templates can quickly integrate newly discovered vulnerabilities, describing the characteristics of vulnerability attacks and the signs of vulnerability existence.

[0017] 2. Suricata Rules: A network intrusion detection tool based on the Suricata rule language to inspect network traffic. It is used to: detect web vulnerability attacks based on web vulnerability attack requests, and trigger attack alerts on network traffic caused by these requests. It analyzes network traffic and, based on a set of rules, detects and reports potential vulnerability attacks in real time. Suricata rules can define the characteristics of malicious traffic (e.g., specific strings, protocol anomalies, traffic patterns, etc.).

[0018] 3. WebMockServer (or "vulnerability probing site"): Uses Large Language Model (LLM) technology to parse the scanning strategy of Nuclei templates and dynamically generate a Web mock service (i.e., mock.py) to build a vulnerability probing site that meets the conditions. It is used to: respond to specific Web vulnerability scanning requests through the vulnerability probing site, thereby simulating the existence of vulnerability scenarios.

[0019] 4. LLM: LLM is an artificial intelligence model based on deep learning. It is trained on massive amounts of text data to generate natural language text and understand its meaning. Its core architecture can be based on the Transformer model, which uses a self-attention mechanism to process sequential data, has powerful text processing capabilities, and can better understand contextual relationships.

[0020] 5. Web Mock Technology: This involves simulating web interfaces or services. During testing, a virtual object is created to replace objects that are difficult to construct or obtain, facilitating testing. For example, a lightweight web mock server (WebMockServer) can be quickly built using Python's Flask framework or a dedicated mock framework. This WebMockServer can return specific response data (such as response body, status code, etc.) based on predefined rules (such as request path, method, parameters, request body, etc.). In this embodiment, the LLM-WebMockServer generator built using LLM and Web Mock technologies can construct a "vulnerability testing site" to simulate a vulnerable server environment without deploying a real, potentially insecure environment. This simulates real application scenarios (such as vulnerability detection scenarios) in front-end and back-end development and testing. Combined with an LLM-based vulnerability rule generator (such as the LLM-Suricata rule generator), the reliability of test results (vulnerability detection rules, such as Suricata rules) can be pre-verified.

[0021] According to embodiments of this disclosure, a vulnerability rule generation and verification method based on an intermediate component is provided. Figure 2 This is a flowchart illustrating a vulnerability rule generation and verification method based on intermediate components according to an embodiment of this disclosure. This method can be applied to a vulnerability rule generation and verification device based on intermediate components. For example, the device can be deployed on a terminal, server, or other processing device in a single-machine, multi-machine, or cluster system to perform vulnerability rule generation and verification tasks based on intermediate components. The terminal can be a user equipment (UE), mobile device, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, wearable device, etc. In some possible implementations, the method can also be implemented by a processor calling computer-readable instructions stored in memory. Figure 2 As shown, this method is applied to Figure 1 In any node or electronic device within the cluster system shown, the vulnerability rule generation and verification method based on intermediate components includes: S201. Run the simulation environment built through intermediate components.

[0022] In some examples, the intermediate components are used to build a simulated environment that supports dynamic interaction for vulnerability rule generation and verification. These can be two core components: a Web Mock Server generator based on the Large Language Model (LLM) and Web Mock technologies, and a vulnerability rule generator based on the Large Language Model (LLM) (such as the LLM-Suricata rule generator). Additionally, a task scheduler based on the Large Language Model (such as the LLM-task scheduler) is added when the Nuclei template is updated.

[0023] In some examples, a simulated environment built through an intermediate component can simulate a web server with corresponding vulnerabilities. Within this simulated environment, the LLM-WebMockServer generator can convert a Nuclei template into an executable vulnerability detection service. The LLM-WebMockServer generator can also generate vulnerability probing sites. Subsequently, the LLM-Suricata rule generator verifies the validity of Suricata rules generated based on the same Nuclei template. This automated closed-loop process of "template → simulated environment → detection rule → verification" not only constructs a dynamic and interactive vulnerability rule generation and verification environment but also implements a closed-loop verification mechanism to achieve intelligent conversion and verification from Nuclei templates to Suricata intrusion detection rules through LLM technology.

[0024] S202. In the simulation environment, convert the vulnerability scanner tool template into an executable vulnerability detection service. The vulnerability detection service is a simulation service used to simulate the execution of a vulnerable web server.

[0025] In some examples, the vulnerability scanner tool template can be the Nuclei template, and the vulnerability detection service can be mock.py.

[0026] In some examples, the LLM-WebMockServer generator can be used to convert Nuclei templates into WebMockServer routing functions and generate vulnerability testing sites to verify whether the WebMockServer routing functions are generated effectively.

[0027] S203. Generate vulnerability detection rules in a simulated environment based on the vulnerability scanner tool template.

[0028] In some examples, the vulnerability scanner tool template can be a Nuclei template, and the vulnerability detection rules can be Suricata rules. In this way, the Nuclei template can be converted into Suricata rules in a simulated environment using an LLM-Suricata rule generator to verify whether the Suricata rules are generated effectively.

[0029] S204. Verify the validity of the rules in a simulated environment based on the vulnerability detection rules and the vulnerability detection service.

[0030] In some examples, the LLM-Suricata rule generator can also be used in a simulated environment to verify the validity of vulnerability detection rules based on Suricata rules. If a vulnerability attack alert can be triggered, it means that the generated Suricata rule is a valid vulnerability detection rule.

[0031] In some examples, it may also include: an LLM-task scheduler in a simulated environment, which, upon discovering that the Nuclei template has been updated, issues a rule generator task and merges the generated and validated WebMockServer routing function with the Suricata rule into the WebMockServer and Suricata rule set.

[0032] By employing the embodiments of this disclosure, the overall technical solution comprised of the aforementioned technical features achieves "automated closed-loop" vulnerability detection and vulnerability rule validity verification. This is fundamentally different from the separate multiple stages in related technologies that heavily rely on manual completion by security experts. In other words, the simulation environment constructed by the intermediate component in this disclosure can support dynamic interactive vulnerability rule generation and verification. Based on the same Nuclei template, it utilizes the text processing capabilities of LLM to parse the Nuclei template, automatically completing vulnerability detection, vulnerability rule writing, and testing and verification of the validity of simulated vulnerability services and vulnerability rules within a unified simulation environment. This disclosure is particularly suitable for application scenarios involving massive vulnerability outbreaks because the "automated closed-loop" vulnerability detection and vulnerability rule validity verification enables batch and automated generation and pre-verification of detection capabilities, thereby achieving rapid response to "massive vulnerability outbreaks," reducing response time from hours or even days to minutes. Because the generated vulnerability detection rules (such as Suricata rules) have undergone empirical testing in their corresponding, precisely simulated vulnerability environment (Web Mock service) before release, this ensures the "targeting" and effectiveness of the rules. This fundamentally reduces the risks of false positives (i.e., false positives caused by overly broad vulnerability detection rules) and false negatives (i.e., false negatives caused by vulnerability detection rules failing to match real vulnerability characteristics), thus generating accurate and trustworthy vulnerability detection rules. Since the WebMockServer generated by LLM can not only be used for internal testing but is itself a vulnerability probing site supporting dynamic and highly interactive methods, it can be deployed in real networks to lure and trace attack behavior. This provides a high-quality interactive environment for threat intelligence gathering and attacker profiling, realizing derivative effects in the technical path, and is not limited to the simulated service executed by a vulnerable Web server as disclosed in this disclosure.

[0033] According to embodiments of this disclosure, a vulnerability rule generation and verification method based on an intermediate component is provided. Figure 3 This is a flowchart illustrating a vulnerability rule generation and verification method based on an intermediate component according to an embodiment of this disclosure. This method can be applied to a vulnerability rule generation and verification apparatus based on an intermediate component, such as... Figure 3 As shown, this vulnerability rule generation and verification method based on intermediate components includes: S301. Run the simulation environment built through intermediate components.

[0034] In some examples, the intermediate components are used to build a simulated environment that supports dynamic interaction for vulnerability rule generation and verification. These can be two core components: the LLM-WebMockServer generator based on LLM and Web Mock technologies, and the LLM-Suricata rule generator, as well as the LLM-task scheduler added during Nuclei template updates.

[0035] In some examples, a simulated environment built through an intermediate component can simulate a web server with corresponding vulnerabilities. Within this simulated environment, the LLM-WebMockServer generator can convert a Nuclei template into an executable vulnerability detection service. The LLM-WebMockServer generator can also generate vulnerability probing sites. Subsequently, the LLM-Suricata rule generator verifies the validity of Suricata rules generated based on the same Nuclei template. This automated closed-loop process of "template → simulated environment → detection rule → verification" not only constructs a dynamic and interactive vulnerability rule generation and verification environment but also implements a closed-loop verification mechanism to achieve intelligent conversion and verification from Nuclei templates to Suricata intrusion detection rules through LLM technology.

[0036] S302. In the simulation environment, convert the vulnerability scanner tool template into an executable vulnerability detection service, which is a simulation service used to simulate the execution of a vulnerable web server.

[0037] In some examples, the vulnerability scanner tool template can be the Nuclei template, and the vulnerability detection service can be mock.py.

[0038] In some examples, the LLM-WebMockServer generator can be used to convert Nuclei templates into WebMockServer routing functions and generate vulnerability testing sites to verify whether the WebMockServer routing functions are generated effectively.

[0039] S303. Generate vulnerability detection rules in a simulated environment based on the vulnerability scanner tool template.

[0040] In some examples, the vulnerability scanner tool template can be a Nuclei template, and the vulnerability detection rules can be Suricata rules. In this way, the Nuclei template can be converted into Suricata rules in a simulated environment using an LLM-Suricata rule generator to verify whether the Suricata rules are generated effectively.

[0041] S304. Use vulnerability detection rules to test the vulnerability detection service to see if it can trigger vulnerability attack alerts.

[0042] S305. When a vulnerability attack alert associated with the vulnerability detection service is triggered, the validity of the vulnerability detection rule is verified.

[0043] In some examples, vulnerability attack alerts include: alerts triggered by simulated attack traffic in the vulnerability detection service that correspond to vulnerability detection rules.

[0044] This disclosure introduces a specific implementation mechanism for validity verification, establishing a built-in, practically tested standard for the validity verification of automatically generated vulnerability detection rules. Unlike the syntax checking and theoretical deduction verification methods in related technologies, this method performs dynamic interactive "attack-detection" tests in a simulated environment, using "successfully triggering alarm information" as an objective criterion. This ensures that each generated vulnerability detection rule has practical capabilities (i.e., whether it can trigger alarm information is verified through actual testing before the vulnerability detection rule is released, which is equivalent to attaching a "functional test report" to each generated vulnerability detection rule. This elevates rule verification from subjective judgment relying on expert experience to automatic execution by the system deploying the simulated environment, with the verification results being objectively judged through clear and traceable alarm information logs). This transforms the output of the system deploying the simulated environment from "possible detection rules" to "verified and reliable detection rules," realizing the validity verification of vulnerability rules from "automated closed-loop" vulnerability detection to "reliable delivery."

[0045] In one embodiment of this disclosure, the method further includes: when the vulnerability scanner tool template (such as the Nuclei template) is updated, merging the vulnerability detection rules (such as the Suricata rules) that have passed the above rule validity verification with the corresponding vulnerability detection service (a simulation service used to simulate the execution of a vulnerable web server) and storing them in the rule set. This embodiment introduces a dynamic and continuous update mechanism for the rule set through "update-verification-merge-storage," upgrading the one-time verification of vulnerability detection rules into a continuously evolving security capability supply chain, sustainably producing vulnerability detection rules delivered with the aforementioned "trusted delivery." Since the system deploying the simulation environment can automatically respond to updates to external vulnerability intelligence (such as the Nuclei template), when a new vulnerability is discovered and a Nuclei template is released, the system can automatically complete the entire pipeline from obtaining vulnerability intelligence to generating, verifying, and finally producing directly deployable vulnerability detection rules without human intervention. This establishes a real-time synchronization capability between proactive security defense and vulnerability intelligence, thereby compressing the vulnerability detection response cycle from "days / hours" to "minutes." The merged and stored rule set can be used by downstream automated deployment systems (such as the Suricata management platform). For example, verified update rule packages can be pulled from this rule set periodically or triggered automatically and distributed to the Suricata management platform, thus automating the deployment.

[0046] According to embodiments of this disclosure, a vulnerability rule generation and verification method based on an intermediate component is provided. Figure 4 This is a flowchart illustrating a vulnerability rule generation and verification method based on an intermediate component according to an embodiment of this disclosure. This method can be applied to a vulnerability rule generation and verification apparatus based on an intermediate component, such as... Figure 4 As shown, this vulnerability rule generation and verification method based on intermediate components includes: S401. Run the simulation environment built through intermediate components.

[0047] In some examples, the intermediate components are used to build a simulated environment that supports dynamic interaction for vulnerability rule generation and verification. These can be two core components: an LLM-WebMockServer generator based on LLM and Web Mock technologies, and an LLM-Suricata rule generator, as well as an LLM-task scheduler added during Nuclei template updates.

[0048] In some examples, a simulated environment built through an intermediate component can simulate a web server with corresponding vulnerabilities. Within this simulated environment, the LLM-WebMockServer generator can convert a Nuclei template into an executable vulnerability detection service. The LLM-WebMockServer generator can also generate vulnerability probing sites. Subsequently, the LLM-Suricata rule generator verifies the validity of Suricata rules generated based on the same Nuclei template. This automated closed-loop process of "template → simulated environment → detection rule → verification" not only constructs a dynamic and interactive vulnerability rule generation and verification environment but also implements a closed-loop verification mechanism to achieve intelligent conversion and verification from Nuclei templates to Suricata intrusion detection rules through LLM technology.

[0049] S402. In a simulated environment, convert the vulnerability scanner tool template into at least one web simulation server routing function to obtain an executable vulnerability detection service.

[0050] In some examples, the vulnerability detection service is implemented via a WebMockServer, which is a simulation service used to impersonate a vulnerable web server. A WebMockServer, also known as a "vulnerability simulation server" or "vulnerability environment simulation server," is used to simulate the behavior of a real web server or service.

[0051] S403. Deploy and run a vulnerability probing site containing at least one WebMockServer routing function in a simulated environment.

[0052] In some examples, the vulnerability probing site generated by dynamically creating a WebMockServer based on the Nuclei template and simulating the corresponding vulnerability serves as a controllable and secure "target," ensuring the "targeting" and effectiveness of the rules. This is used to verify whether the Suricata rules targeting the vulnerability can correctly trigger alerts, forming a key link in automated closed-loop verification.

[0053] S404. Based on the vulnerability testing site, verify the validity of at least one WebMockServer routing function.

[0054] S405. Generate vulnerability detection rules in a simulated environment based on the vulnerability scanner tool template.

[0055] In some examples, the vulnerability scanner tool template can be a Nuclei template, and the vulnerability detection rules can be Suricata rules. In this way, the Nuclei template can be converted into Suricata rules in a simulated environment using an LLM-Suricata rule generator to verify whether the Suricata rules are generated effectively.

[0056] S406. Use vulnerability detection rules to test the vulnerability detection service to see if it can trigger vulnerability attack alerts.

[0057] S407. When a vulnerability attack alert associated with the vulnerability detection service is triggered, the vulnerability detection rule is verified to be effective.

[0058] In some examples, vulnerability attack alerts include: alerts triggered by simulated attack traffic in the vulnerability detection service that correspond to vulnerability detection rules.

[0059] Using the embodiments of this disclosure, an automated closed-loop verification process is executed concurrently by intelligent agents (such as LLMs) in a unified digital space (i.e., a simulated environment) based on the same Nuclei template. This differs from the fragmented, sequential processes in related technologies, such as "writing detection rules," "building a test environment," and "verifying the validity of the rules," which are highly dependent on expert experience. This avoids the subjectivity of expert experience and the passive defense of relying on expert experience. The embodiments of this disclosure represent an active defense for automated closed-loop verification, eliminating the cross-role communication costs, test environment construction waiting time, and test dependency of verification rules caused by the fragmented steps in related technologies. The uncertainty of expert experience, the rapid response of proactive defense, and the feedback of continuous optimization of verification rules enable a dynamic interaction mechanism, which is especially suitable for complex vulnerabilities that require multi-step interaction or out-of-band (OOB) verification (such as Log4Shell). Log4Shell is a complex vulnerability that relies on OOB interaction. Specifically, the evidence of whether the attack on this type of vulnerability is successful (i.e., proof that the vulnerability has been triggered) is not included in the direct response of the request, but is manifested as a new network connection initiated by WebMockServer to a third-party server controlled by the attacker after being attacked.

[0060] According to embodiments of this disclosure, a vulnerability rule generation and verification method based on an intermediate component is provided. Figure 5 This is a flowchart illustrating a vulnerability rule generation and verification method based on an intermediate component according to an embodiment of this disclosure. This method can be applied to a vulnerability rule generation and verification apparatus based on an intermediate component, such as... Figure 5 As shown, this vulnerability rule generation and verification method based on intermediate components includes: S501, Run the simulation environment built through intermediate components.

[0061] In some examples, the intermediate components are used to build a simulated environment that supports dynamic interaction for vulnerability rule generation and verification. These can be two core components: the LLM-WebMockServer generator based on LLM and Web Mock technologies, and the LLM-Suricata rule generator, as well as the LLM-task scheduler added during Nuclei template updates.

[0062] In some examples, a simulated environment built through an intermediate component can simulate a web server with corresponding vulnerabilities. Within this simulated environment, the LLM-WebMockServer generator can convert a Nuclei template into an executable vulnerability detection service. The LLM-WebMockServer generator can also generate vulnerability probing sites. Subsequently, the LLM-Suricata rule generator verifies the validity of Suricata rules generated based on the same Nuclei template. This automated closed-loop process of "template → simulated environment → detection rule → verification" not only constructs a dynamic and interactive vulnerability rule generation and verification environment but also implements a closed-loop verification mechanism to achieve intelligent conversion and verification from Nuclei templates to Suricata intrusion detection rules through LLM technology.

[0063] S502. In a simulated environment, convert the vulnerability scanner tool template into at least one web simulation server routing function to obtain an executable vulnerability detection service.

[0064] In some examples, the vulnerability detection service is implemented via a WebMockServer, which is a simulation service used to impersonate a vulnerable web server. A WebMockServer, also known as a "vulnerability simulation server" or "vulnerability environment simulation server," is used to simulate the behavior of a real web server or service.

[0065] S503. Deploy and run a vulnerability probing site containing at least one WebMockServer routing function in a simulated environment.

[0066] In some examples, the vulnerability probing site generated by dynamically creating a WebMockServer based on the Nuclei template and simulating the corresponding vulnerability serves as a controllable and secure "target," ensuring the "targeting" and effectiveness of the rules. This is used to verify whether the Suricata rules targeting the vulnerability can correctly trigger alerts, forming a key link in automated closed-loop verification.

[0067] S504. Receive HTTP requests that match the vulnerability attack requests defined in the vulnerability scanning template through the vulnerability probing site.

[0068] S505. Response to HTTP requests through the vulnerability testing site to obtain response results.

[0069] S506. If the response result meets the vulnerability existence conditions defined in the vulnerability scanning template, verify that at least one WebMockServer routing function is valid.

[0070] By using S504-S506, the validity of at least one WebMockServer routing function can be verified based on the vulnerability testing site.

[0071] S507. Generate vulnerability detection rules in a simulated environment based on the vulnerability scanner tool template.

[0072] In some examples, the vulnerability scanner tool template can be a Nuclei template, and the vulnerability detection rules can be Suricata rules. In this way, the Nuclei template can be converted into Suricata rules in a simulated environment using an LLM-Suricata rule generator to verify whether the Suricata rules are generated effectively.

[0073] S508. By responding to test requests through the vulnerability testing site, the network traffic generated by the response to test requests is obtained.

[0074] S509. Analyze network traffic according to vulnerability detection rules to detect whether the vulnerability detection service can trigger vulnerability attack alarm information.

[0075] S508-S509 enables testing of the vulnerability detection service using vulnerability detection rules to determine whether the vulnerability detection service can trigger vulnerability attack alerts.

[0076] S510. When a vulnerability attack alert associated with the vulnerability detection service is triggered, the validity of the vulnerability detection rule is verified.

[0077] In some examples, vulnerability attack alerts include: alerts triggered by simulated attack traffic in the vulnerability detection service that correspond to vulnerability detection rules.

[0078] This disclosure fundamentally addresses the technical pain point of vulnerability detection rules being "untrustworthy and unusable." Through dual testing and verification—"realistic verification of the vulnerability detection service in a simulated environment" and "dynamic interactivity verification of the vulnerability detection rules in a simulated environment"—a quality standard system is automatically established for vulnerability detection scenarios. This system, deployed in a simulated environment, can be rigorously executed and its results objectively judged. This dual testing and verification, through two parallel and objective verification chains (i.e., vulnerability detection service generation and verification, and vulnerability detection rule generation and verification), constructs a delivery system that does not rely on external trust and can self-prove its functional correctness. It verifies that the vulnerability simulation service generated by the LLM-WebMockServer generator can accurately reproduce a high-fidelity environment of vulnerability characteristics, ensuring the effectiveness of the test from the source. It also verifies that the vulnerability detection rules generated by the LLM-Suricata rule generator are not a static feature library, but a dynamic detector that can accurately identify vulnerability attack behaviors and generate alarm information in real network flows, ensuring that the vulnerability detection rules have real-world combat capabilities and are traceable.

[0079] According to embodiments of this disclosure, an intermediate component is provided. Figure 6 It is an intermediate component according to embodiments of this disclosure, such as Figure 6 As shown, the intermediate component includes: The LLM-WebMockServer generator 601 is used to receive vulnerability scanner tool templates, parse the vulnerability scanner tool templates, and convert the vulnerability scanner tool templates into executable vulnerability detection services. The vulnerability detection services are simulation services used to simulate the execution of a vulnerable web server. The vulnerability scanner tool templates can be Nuclei templates.

[0080] The LLM-Suricata rule generator 602 is used to generate vulnerability detection rules based on vulnerability scanner tool templates and to verify the validity of the rules based on the vulnerability detection rules and vulnerability detection services.

[0081] By employing embodiments of this disclosure, a simulated environment supporting dynamic interactive vulnerability rule generation and verification is constructed using the LLM-WebMockServer generator and the LLM-Suricata rule generator. This simulates a web server with corresponding vulnerabilities. Within this simulated environment, the LLM-WebMockServer generator can convert Nuclei templates into executable vulnerability detection services and generate vulnerability probing sites. Furthermore, the LLM-Suricata rule generator verifies the validity of Suricata rules generated based on the same Nuclei template. This automated closed-loop process of "template → simulated environment → detection rule → verification" not only constructs a dynamic and interactive vulnerability rule generation and verification environment but also implements a closed-loop verification mechanism to achieve intelligent conversion and verification from Nuclei templates to Suricata intrusion detection rules through LLM technology.

[0082] In one embodiment of this disclosure, an LLM-task scheduler is further included, which is communicatively connected to the LLM-WebMockServer generator 601 and the LLM-Suricata rule generator 602. The LLM-task scheduler monitors update events of vulnerability scanner tool template libraries (such as the Nuclei template library). Upon detecting an update to a vulnerability scanner tool template, it issues a new rule generation task to the LLM-Suricata rule generator 602, merging the vulnerability detection rules that have passed rule validity verification with the corresponding vulnerability detection service and storing them in the rule set. The vulnerability scanner tool template can be a Nuclei template. This embodiment introduces a dynamic and continuous rule set update mechanism of "update-verify-merge-store" through the LLM-task scheduler, upgrading the one-time verification of vulnerability detection rules into a continuously evolving security capability supply chain, sustainably producing vulnerability detection rules that have undergone the aforementioned "trusted delivery."

[0083] In one embodiment of this disclosure, an LLM-WebMockServer generator 601 is used to convert a vulnerability scanner tool template into at least one WebMockServer routing function; an LLM-Suricata rule generator 602 is used to verify the validity of rules based on vulnerability detection rules and at least one WebMockServer routing function; and an LLM-task scheduler is used to merge the vulnerability detection rules that have passed the rule validity verification with the corresponding at least one WebMockServer routing function and store them in a rule set. The vulnerability scanner tool template can be a Nuclei template. This implementation method utilizes the LLM-WebMockServer generator and the LLM-Suricata rule generator to verify the validity of WebMockServer routing functions and vulnerability detection rules in a simulated environment. The generated WebMockServer routing functions are more realistic, and the vulnerability detection rules are more accurate. The dedicated processing of the two generators improves task processing accuracy compared to using a single generator. The LLM-task scheduler can quickly respond to Nuclei template updates and schedule the division of labor and collaborative cooperation between the LLM-WebMockServer generator and the LLM-Suricata rule generator, achieving "automated closed-loop" vulnerability detection, vulnerability rule validity verification, and optimization of dynamic vulnerability rule updates.

[0084] In one embodiment of this disclosure, the LLM-WebMockServer generator 601 is further used to deploy and run a vulnerability testing site containing at least one WebMockServer routing function, so as to verify the validity of at least one WebMockServer routing function through the vulnerability testing site. The validity of at least one WebMockServer routing function is used to characterize whether at least one WebMockServer routing function can correctly simulate the service behavior of a vulnerable web server. Using this embodiment, a lightweight vulnerability testing site can be deployed. The vulnerability testing site is created automatically by the LLM-WebMockServer generator 601 on demand and can be destroyed after testing, eliminating the need to maintain a permanent and complex testing environment, thus demonstrating its lightweight and on-demand characteristics. The LLM-WebMockServer generator 601 operates by receiving vulnerability scanner tool templates (such as the Nuclei template), parsing the templates to generate at least one WebMockServer routing function, building and deploying a vulnerability testing site containing at least one WebMockServer routing function to deploy an executable vulnerability detection service, automating testing, and outputting verification results (verifying the validity of at least one WebMockServer routing function). This automated generation and verification closed-loop process avoids the manual handover costs between generation and verification, ensuring that each verified WebMockServer routing function output by the LLM-WebMockServer generator 601 is a finished product with controllable quality, rather than a semi-finished product (unverified and uncontrollable).

[0085] In one embodiment of this disclosure, the LLM-WebMockServer generator 601 is further configured to receive HTTP requests matching the vulnerability attack requests defined in the vulnerability scanning template via a vulnerability probing site, respond to the HTTP requests via the vulnerability probing site to obtain response results, and verify the validity of at least one WebMockServer routing function if the response results meet the vulnerability existence conditions defined in the vulnerability scanning template. The vulnerability scanner tool template can be a Nuclei template. Using this embodiment, the vulnerability probing site generated by dynamically creating a simulated WebMockServer with the corresponding vulnerability based on the Nuclei template serves as a controllable and secure "target," ensuring the "targeting" and effectiveness of the rules. It is used to verify whether the Suricata rule targeting the vulnerability can correctly trigger an alert, forming a crucial link in the "automated closed-loop" vulnerability detection, vulnerability rule validity verification, and dynamic update optimization of vulnerability rules. By responding to HTTP requests via the vulnerability probing site, it is possible to directly verify whether at least one WebMockServer routing function generated by the LLM-WebMockServer generator 601 can reproduce the key characteristics of the vulnerability (such as specific response headers, status codes, and page content) in real HTTP interactions. This ensures that the generated WebMockServer routing function is not only "syntactically correct code" but also "behaving correctly." It provides a tested and reliable basis for all subsequent tests based on this simulation environment (such as Suricata rule verification), avoiding the failure of the entire verification chain caused by "testing the validity of Suricata rules in an incorrect simulation environment."

[0086] In one embodiment of this disclosure, an LLM-WebMockServer generator 601 is used to respond to test requests through a vulnerability testing site, generating network traffic. An LLM-Suricata rule generator 602 is used to send the test request to the LLM-WebMockServer generator 601, receive the network traffic generated in response to the test request, and analyze the generated network traffic according to the vulnerability detection rules to detect whether the network traffic can trigger vulnerability attack alert information. The LLM-WebMockServer generator 601 is also used to parse the request and response features in the vulnerability scanner tool template to obtain at least one WebMockServer routing function based on the request and response features. In this implementation, every step of the automated verification process—namely, test case generation (the LLM-Suricata rule generator 602 obtains test requests based on the Nuclei template), test environment stimulation (the LLM-WebMockServer generator 601 receives and responds to the test requests), and test result determination (the LLM-Suricata rule generator 602 analyzes whether its vulnerability detection rules based on the Nuclei template can trigger vulnerability attack alarm information)—is automatically completed by the system itself based on the same original data (Nuclei template). This eliminates the uncertainty and subjectivity brought about by manually constructing test cases, setting up test environments, and judging test results, making each automated verification a predictable and repeatable technical process. This "vulnerability detection-vulnerability detection rule matching pair" ensures that each automated verification follows the same "standard operating procedure," allowing the verification process itself to be monitored and measured, such as statistical verification success rate, average time consumption, common failure modes, etc. It also enables fault location when verification fails (such as inaccurate vulnerability location detection or inaccurate vulnerability detection rules) and further fault self-healing mechanisms.

[0087] In one embodiment of this disclosure, the LLM-WebMockServer generator 601 is further used to parse attack features in a vulnerability scanner tool template to obtain vulnerability detection rules based on those attack features. The vulnerability scanner tool template can be a Nuclei template. Using this embodiment, the LLM-WebMockServer generator 601 can parse a vulnerability scanner tool template (such as a Nuclei template) to simulate a service in a vulnerable environment, or what is called an "executable vulnerability detection service" (i.e., a mock.py service). The LLM-Suricata rule generator 602 works in conjunction with the LLM-WebMockServer generator 601. The LLM-Suricata rule generator 602 can parse the vulnerability scanner tool template (such as a Nuclei template) to generate Suricata rules for detecting vulnerability attacks. Since the LLM-WebMockServer generator 601 and the LLM-Suricata rule generator 602 are targeted... The division of labor in parsing the same Nuclei template and the same set of attack features ensures from the source that the output of the LLM-WebMockServer generator 601 and the output of the LLM-Suricata rule generator 602 are semantically homologous and matched. This "homogeneous design" greatly simplifies the complexity of internal system coordination and avoids the problem of mismatch between environment simulation and Suricata rules caused by inconsistent understanding of the Nuclei template by the output of the LLM-WebMockServer generator 601 and the LLM-Suricata rule generator 602 (mismatch could be: "the environment simulates attack A, but the rule detects feature B"). Furthermore, the LLM-WebMockServer generator 601 can also reuse some of the work of the LLM-Suricata rule generator 602. In order for the component responsible for generating the simulation environment to also deeply understand the attack features, the LLM-WebMockServer generator 601 can also parse the attack features in the vulnerability scanner tool template to obtain vulnerability detection rules based on the attack features.

[0088] The following provides an example of the vulnerability rule generation and verification method based on intermediate components provided in the above-described embodiments of this disclosure.

[0089] Exploiting web vulnerabilities to commit network intrusions is a common attack method used by attackers. For network security operators, it is necessary to develop corresponding detection strategies for web vulnerabilities. However, with the diversification of asset applications and the increasing number of vulnerabilities, relying solely on manual methods to write detection rules leads to excessively long response cycles. This disclosure presents an automated closed-loop solution for vulnerability detection rule generation and verification, achieved by combining the superior text processing capabilities of LLM with Web mock technology. This solution automates the generation and verification of network security rules.

[0090] The overall scheme of this disclosure includes two core components (LLM-WebMockServer generator and LLM-Suricata rule generator) and a task scheduler (LLM-task scheduler). The LLM-WebMockServer generator converts Nuclei templates into WebMockServer routing functions, generates vulnerability testing sites (i.e., WebMockServer), and verifies whether the routing functions are generated effectively. The LLM-Suricata rule generator converts Nuclei templates into Suricata rules and verifies whether the rules are generated effectively. The LLM-task scheduler, upon detecting an update to the Nuclei template, issues a rule generator task and merges the generated WebMockServer routing functions and Suricata rules into the WebMockServer and Suricata rule sets.

[0091] The LLM-WebMockServer generator, LLM-Suricata rule generator, and LLM-task scheduler are described below: (a) LLM-WebMockServer Generator Input to the LLM-WebMockServer generator: Nuclei template; The LLM-WebMockServer generator outputs the mock.py service; The LLM-WebMockServer generator's internal processing involves using LLM to parse the Nuclei template, constructing routes, actions, and responses in mock functions to create web vulnerability attack requests and responses, thereby generating an executable vulnerability detection service. This vulnerability detection service is a simulation service used to simulate the execution of a vulnerable web server, thus enabling the generation of an executable vulnerability detection service based on the Nuclei template.

[0092] Internally, the route is constructed by extracting the HTTP path and HTTP request method of the HTTP request and creating a route entry for each path (consisting of at least one WebMockServer route function). Internally, the response is constructed by extracting keywords from the feature extractors and feature matchers to build the HTTP response. In the internal processing, the action construction is as follows: for vulnerability scenarios without obvious response characteristics, time-based blind injection and out-of-bounds (OOB) external injection are used for auxiliary verification, and this type of action needs to be simulated synchronously.

[0093] Specifically, the time-based blind injection simulation in the action construction involves extracting the `duration>=N` function from `matchers` and using the system function `time.sleep(N)` for simulation. The OOB (Out-of-Band) simulation in the action construction involves: verifying whether the Nuclei template has the `interactsh-url` variable; if so, using the custom function `send_oob_request()` (OOB request replay) for simulation. The `send_oob_request` function extracts and replays OOB requests, and its steps include: OOB request capture: extracting the OOB request from the HTTP request protocol; OOB request replay: replaying the OOB request according to the specified user agent (UA), request body, and request headers before performing the above simulation.

[0094] The validity of the mock.py service output by the LLM-WebMockServer generator is verified. Specifically, for the "Nuclei template" simulating a vulnerability detection scenario, the validity of the constructed "Web vulnerability attack request" is verified to determine whether the vulnerability construction was successful. This includes: starting the mock.py service; scanning the mock.py service with the Nuclei template; checking whether the Nuclei template can detect the vulnerability; if the vulnerability is detected, the mock.py service was successfully generated; if it cannot be detected, the reason for the failure is submitted to LLM for intelligent retry.

[0095] (ii) LLM-Suricata rule generator Input to the LLM-Suricata rule generator: Nuclei template; Output of the LLM-Suricata rule generator: Suricata rules, PCAP packets; The internal processing of the LLM-Suricata rule generator: It uses LLM to parse Nuclei templates and construct Suricata rules, including template preprocessing and classification parsing, to generate Suricata rules based on Nuclei templates.

[0096] Internally, template preprocessing includes: 1) Variable substitution: replacing variables in the template with fixed placeholders and marking in the prompt that placeholders should not be written into the generation rules; 2) Template simplification: for multiple HTTP requests, take the last HTTP request for conversion.

[0097] Internally, the parsing is categorized into two types: 1) With echo: both attack request detection rules and attack response detection rules are generated simultaneously; 2) Out-of-Band (OOB) outbound: only attack request detection rules are generated, and attack response detection relies on general OOB outbound request rules for coverage.

[0098] The validity of "Suricata rules" is verified based on the mock.py service output by the LLM-WebMockServer generator. Specifically, a vulnerability detection scenario is simulated using the "Nuclei template." The "Suricata rules" corresponding to the simulated "constructed Web vulnerability attack request" are then verified to be effective. This includes: starting the mock.py service; scanning the mock.py service with Nuclei; capturing network traffic and generating PCAP packets; using Suricata rules to detect the PCAP packets and check if vulnerability attack alerts are generated. If vulnerability attack alerts are generated, the Suricata rules are successfully generated. If no vulnerability is detected, the reason for the failure is submitted to LLM for intelligent retry.

[0099] (III) LLM - Task Scheduler When the LLM-task scheduler detects an update to the Nuclei template, it issues a rule generator task and merges the generated WebMockServer routing function with the Suricata rules into the WebMockServer and Suricata rule sets. Specifically, this includes: monitoring Nuclei template updates, such as monitoring the Nuclei-template source code repository; detecting new Nuclei templates; if a Nuclei template has been updated (added or modified), determining if Suricata already has security detection capabilities; if so, loading the current Suricata rule set; and validating the Suricata rules. If a vulnerability attack alert is triggered, the Suricata rule is considered valid; otherwise, the LLM-task scheduler schedules the LLM-WebMockServer generator and the LLM-Suricata rule generator, issuing rule generation instructions to generate new Suricata rules. Simultaneously, the LLM-task scheduler merges the validated Suricata rules and their corresponding mock.py services into the WebMockServer. The system utilizes the WebMockServer index table in Table 1 to store metadata. It merges mock.py services based on routing rules (mock.py services on the same route are logically matched according to HTTP request content, while mock.py services on different routes are directly merged). Verified Suricata rules are normalized and merged into the rule set. Normalization can be performed by updating the Suricata rule ID (SID, Signature ID) according to the current Suricata rule set's specifications. The SID is a crucial and mandatory metadata field in Suricata intrusion detection rules. As a unique numerical identifier, the SID uniquely identifies a rule within the Suricata rule set, acting like an "ID number" for each rule. When a Suricata rule triggers a vulnerability attack alert, the alert will include the SID of the triggering Suricata rule, allowing for quick and accurate identification of which Suricata rule in the rule set generated the alert.

[0100] Table 1 Figure 7This is a schematic diagram illustrating a request-processing-response based on a Web Mock Server in an application example according to an embodiment of this disclosure. The Web Mock Server (or "vulnerability testing site") is generated by an LLM-Webmockserver generator. The Web Mock Server includes at least a request matcher and a response generator, simulating a standard request-processing-response test environment in a real network environment. The request matcher can be used to parse requests, perform rule matching, and make routing decisions. Parsing requests includes extracting the request path, method, headers, parameters, and body. Rule matching includes matching the parsed request features with all routing rules (i.e., at least one WebMockServer routing function) automatically generated by the LLM-Webmockserver generator according to the Nuclei template in the dynamic routing table. The matching can be based on keyword matching, regular expression matching, or status code matching defined in the Nuclei template. Routing decisions include routing the request to the processing function of the "response generator" corresponding to the first successfully matched rule according to the routing rules. This response generator can be used to construct responses and return corresponding responses to requests. Constructing a response includes dynamically generating a "vulnerability exists" response based on keyword matching, regular expression matching, or status code matching within a successfully matched Nuclei template. This response may include a specific status code, HTTP headers, and a response body. Returning a corresponding response to a request includes sending the constructed HTTP request and response back to the requester (the request can be initiated by the Nuclei template scanner or by the attacker). Figure 7 As shown, it includes: S701, Request Reception: During the rule verification phase, the automated script will simulate an attacker defined in the Nuclei template and send an HTTP request to the Web Mock Server.

[0101] In some examples, a pre-configuration step of initialization and rule injection is included before S701. The pre-configuration step is as follows: when the system starts, the LLM-task scheduler can dynamically load at least one WebMockServer routing function (i.e., the routing rules of the "request matcher" and the response construction logic of the "response generator") that has been successfully verified by the LLM-WebMockServer generator into the Web Mock Server's in-memory routing table.

[0102] S702, Request Matching: The "Request Matcher" within this Web Mock Server parses the request and finds routing rules that match the attack characteristics of the request.

[0103] S703, Request Response: The corresponding "Response Generator" function is called and returns a response that is completely consistent with the expected rules of the Nuclei template. This process verifies the validity of the "WebMockServer routing function generated by the LLM-WebMockServer generator".

[0104] Figure 8 This is a schematic diagram of the OOB request flow according to an embodiment of this disclosure, which is different from... Figure 7 HTTP requests, Figure 7 The HTTP request can be directly parsed to determine if a vulnerability exists. Evidence of whether such an attack was successful (i.e., proof that the vulnerability was triggered) is directly contained in the direct response returned by the request. Figure 8 These types of Out-of-Brow (OOB) requests cannot be directly parsed to determine if a vulnerability exists. The "HTTP request path," "HTTP request querystring," "HTTP request headers," and "HTTP body data" must be extracted and decoded before any vulnerability can be identified. For complex vulnerabilities relying on OOB interactions, the evidence of a successful attack (i.e., proof that the vulnerability has been triggered) is not included in the direct response. Instead, it manifests as a new network connection initiated by the WebMockServer to a third-party server controlled by the attacker after the attack. The diagram illustrates the request-processing-response model of a Web Mock Server. The Web Mock Server (or "vulnerability testing site") is generated by the LLM-Webmockserver generator. A Web MockServer includes at least a request matcher and a response generator, simulating a standard request-processing-response testing environment in a real network setting. It can automatically capture, parse, and replay OOB requests.

[0105] Figure 9-10 This is a schematic diagram illustrating the process of generating and verifying vulnerability services based on WebMock Server using the LLM-WebMockServer generator in an application example according to an embodiment of this disclosure. Figure 9 As shown, it includes: S901. Start the Mock service (i.e., the mock.py service): The Mock rule validator starts the mock.py service, deploys and runs a Web Mock Server (or "vulnerability probing site") containing at least one WebMockServer routing function. This Web Mock Server is generated by the LLM-WebMockServer generator to obtain a running and accessible vulnerability simulation environment by starting the mock.py service.

[0106] S902, Initiate Scan: The Mock rule validator calls the Nuclei template scanner to initiate a scan, specifying the Nuclei template corresponding to the mock.py service and the address of the WebMockServer. The Nuclei template scanner sends an HTTP request (i.e., a simulated attack) that conforms to the Nuclei template definition to the WebMockServer based on the WebMockServer's address. The WebMockServer receives the HTTP request, matches the routing rules inside the WebMockServer (i.e., at least one WebMockServer routing function), and returns an HTTP request response.

[0107] In some examples, the dynamically interactive Mock rule validator, Nuclei template scanner, and WebMockServer can be deployed independently or integrated into the LLM-WebMockServer generator.

[0108] S903. Check for vulnerability detection: If the HTTP request response contains a part that matches the keyword, regular expression, or status code defined in the Nuclei template, and the part matches the template definition exactly, the Nuclei template scanner determines that a vulnerability exists.

[0109] In some examples, such as Figure 10As shown, in a vulnerability detection scenario simulated by the Web MockServer generated by the LLM-WebMockServer generator, after the LLM-WebMockServer generator converts the Nuclei template into at least one WebMockServer routing function, the validity of the WebMockServer routing function needs to be verified. The WebMockServer responds to an HTTP request and returns an HTTP request response to the Nuclei template scanner. If the Nuclei template scanner determines that a vulnerability exists, it means that at least one WebMockServer routing function generated by the LLM-WebMockServer generator is valid and can detect the existence of the vulnerability (indicating that the WebMockServer successfully simulated the vulnerable behavior, and the response characteristics are completely correct). If the Nuclei template scanner determines that the vulnerability does not exist, it means that the simulated behavior of the WebMock Server is incorrect and fails to reproduce the vulnerability characteristics, requiring the LLM-WebMockServer generator to regenerate a new WebMockServer routing function.

[0110] Figure 11-12 This is a flowchart illustrating the process of the LLM-Suricata rule generator interacting with a vulnerability service generated by a WebMock Server to verify rules in an application example according to an embodiment of this disclosure. Figure 11 As shown, it includes: S1101. Start the mock.py service: The Suricata rule validator starts the mock.py service, deploys and runs a Web Mock Server (or "vulnerability probing site") containing at least one WebMockServer routing function. This WebMock Server is generated by the LLM-WebMockServer generator to obtain a running and accessible vulnerability simulation environment by starting mock.py.

[0111] S1102, Initiate Scan: The Suricata rule validator calls the Nuclei template scanner to initiate a scan, specifying the Nuclei template corresponding to mock.py and the address of the WebMockServer. The Nuclei template scanner sends an HTTP request (i.e., a simulated attack) that conforms to the Nuclei template definition to the WebMockServer based on the WebMockServer's address. The WebMockServer receives the HTTP request, matches the routing rules inside the WebMockServer (i.e., at least one WebMockServer routing function), and returns an HTTP request response.

[0112] In some examples, the dynamically interactive Suricata rule validator, Nuclei template scanner, and WebMockServer can be deployed independently or integrated into the LLM-Suricata rule generator.

[0113] S1103. Capture network traffic generation: Capture network traffic generated by all dynamic interactions between the Nuclei template scanner and the WebMockServer at the network level, including HTTP requests and responses, and save the network traffic as a standard pcap network packet capture file for use in verifying the validity of Suricata rules.

[0114] S1104. Initiate Suricata detection: Initiate Suricata detection according to the specified Suricata rule. The Suricata rule verifier starts the Suricata detection engine, loads the specified Suricata rule to be verified, and provides the pcap network packet capture file obtained in S1103 to the Suricata detection engine for analysis. The analysis determines whether the generated network traffic can trigger vulnerability attack alarm information.

[0115] S1105. Check for attack alerts: The Suricata rule validator checks the logs generated by the Suricata detection engine after processing the pcap network packet capture file. If the logs contain vulnerability attack alerts, it means that the vulnerability can be detected according to the specified Suricata rule.

[0116] In some examples, such as Figure 12 As shown, in the vulnerability detection scenario simulated by the Web MockServer generated by the LLM-WebMockServer generator, after the LLM-Suricata rule generator converts the Nuclei template into at least one Suricata rule, the validity of the Suricata rule needs to be verified. If the Suricata rule detects and determines that a vulnerability exists, that is, the specified Suricata rule generates a vulnerability attack alarm for the pcap network packet capture file, and the vulnerability attack alarm matches the specified Suricata rule to be verified, it proves that the specified Suricata rule is valid and can detect the vulnerability. If the Suricata rule detects and determines that a vulnerability does not exist, that is, the specified Suricata rule does not generate a vulnerability attack alarm for the pcap network packet capture file, it indicates that the Suricata rule is incorrect and fails to match the vulnerability characteristics, and the LLM-Suricata rule generator needs to regenerate a new Suricata rule.

[0117] Figure 13 This is a schematic diagram illustrating the process of updating scheduling rules via an LLM-task scheduler in an application example according to an embodiment of this disclosure, such as... Figure 13 As shown, it includes: S1301, Nuclei template update monitoring.

[0118] In some examples, updates to the Nuclei template library or internal repository can be continuously monitored. The LLM-task scheduler can schedule the LLM-WebMockServer generator and the LLM-Suricata rule generator. In other words, the LLM-task scheduler is like a central controller, used to detect whether the Nuclei template has been updated in order to trigger the entire process.

[0119] S1302. If a new or modified Nuclei template is found, execute S1303; otherwise, end the process.

[0120] In some examples, vulnerability intelligence is obtained in real time by adding or modifying vulnerability templates.

[0121] S1303, Initiate a test of Suricata's existing security capabilities.

[0122] S1304. If it can be detected that Suricata has safety capabilities, the process ends; otherwise, proceed to S1305.

[0123] In some examples, detection is a key decision-making step. It does not directly perform a scan, but rather performs a rapid knowledge retrieval and matching judgment on the currently deployed Suricata rule set. It analyzes whether there are Suricata rules in the currently deployed Suricata rule set that can detect the vulnerability feature based on the new vulnerability feature.

[0124] In some examples, if the judgment is "the vulnerability characteristics can be detected", it means that the new variant of the vulnerability or the way the vulnerability is used is still within the detection range of the currently deployed Suricata rule set. Therefore, there is no need to generate redundant rules, and the currently deployed Suricata rule set can be used.

[0125] In some examples, if the judgment is "the vulnerability feature cannot be detected", it means that the vulnerability is a completely new attack feature or that the currently deployed Suricata rule set has a detection blind spot, and a new Suricata rule must be generated.

[0126] S1305. Generate new Suricata rules using an intermediate component that includes an LLM-WebMockServer generator and an LLM-Suricata rule generator.

[0127] In some examples, the LLM-WebMockServer generator, as part of the intermediate component, focuses on the processing of vulnerability services and the construction of the simulation environment, while the LLM-Suricata rule generator, as another part of the intermediate component, focuses on the generation and validity verification of Suricata rules.

[0128] In some examples, a preprocessing step for automated vulnerability detection and verification can also be achieved through an "intermediate component." This preprocessing step includes: receiving new or modified Nuclei templates, performing preliminary verification and classification of the Nuclei templates, and coordinating the parallel or sequential processing logic of the LLM-WebMockServer generator and the LLM-Suricata rule generator.

[0129] In some examples, the LLM-WebMockServer generator, upon receiving a new or modified Nuclei template, can leverage LLM's understanding and code generation capabilities to automatically generate an executable WebMockServer (or "vulnerability probing site") to simulate the vulnerability. This is a prerequisite for achieving "verifiability." The LLM-Suricata rule generator generates new, syntactically correct Suricata rules for the same new or modified Nuclei template.

[0130] S1306, mock.py update and merge.

[0131] S1307, Suricata rule standardization, updating and merging.

[0132] In some examples, newly generated Suricata rules that have been verified as valid by the mock.py environment are normalized and merged and updated into the Suricata rule set to obtain an updated Suricata rule set, thereby realizing the automatic accumulation and version management of the proactive defense knowledge base.

[0133] In some examples, Suricata intrusion detection refers to the updated Suricata rule set being implemented on the Suricata engine in the production environment, providing real-time network threat detection capabilities. Simultaneously, mock.py can also be deployed independently to enter proactive decoy mode for locating and tracking attackers.

[0134] According to embodiments of this disclosure, a vulnerability rule generation and verification apparatus based on an intermediate component is provided. Figure 14 This is a schematic diagram of the composition structure of a vulnerability rule generation and verification device based on an intermediate component according to an embodiment of this disclosure. The intermediate component is used to construct a simulated environment for vulnerability rule generation and verification that supports dynamic interaction, such as... Figure 14 As shown, the device includes: Run module 1401 is used to run the simulation environment built through the intermediate component; The simulation service generation module 1402 is used to convert a vulnerability scanner tool template into an executable vulnerability detection service in a simulation environment. This vulnerability detection service is a simulation service used to simulate the execution of a vulnerable web server. The rule generation module 1403 is used to generate vulnerability detection rules based on vulnerability scanner tool templates in a simulated environment. Verification module 1404 is used to verify the validity of rules based on vulnerability detection rules and vulnerability detection services in a simulated environment.

[0135] In one embodiment of this disclosure, the verification module 1404 is configured to: test the vulnerability detection service using vulnerability detection rules to detect whether the vulnerability detection service can trigger vulnerability attack alarm information; and verify the validity of the vulnerability detection rules when vulnerability attack alarm information associated with the vulnerability detection service is triggered; the vulnerability attack alarm information includes: alarm information in the vulnerability detection service triggered by simulated attack traffic and corresponding to the vulnerability detection rules.

[0136] In one embodiment of this disclosure, it further includes: a task scheduling module, used to merge the vulnerability detection rules that have passed the rule validity verification with the corresponding vulnerability detection service and store them in the rule set when the vulnerability scanner tool template is updated.

[0137] In one embodiment of this disclosure, the simulation service generation module 1402 is used to: convert a vulnerability scanner tool template into at least one WebMockServer routing function in a simulation environment to obtain an executable vulnerability detection service; wherein, WebMockServer is a simulated web server with vulnerabilities.

[0138] In one embodiment of this disclosure, the simulation service generation module 1402 is used to: deploy and run a vulnerability testing site containing at least one WebMockServer routing function in a simulation environment; and verify the validity of at least one WebMockServer routing function based on the vulnerability testing site.

[0139] In one embodiment of this disclosure, the simulated service generation module 1402 is configured to: receive an HTTP request matching the vulnerability attack request defined in the vulnerability scanning template through a vulnerability probing site; respond to the HTTP request through the vulnerability probing site and obtain a response result; and verify that at least one WebMockServer routing function is valid if the response result meets the vulnerability existence conditions defined in the vulnerability scanning template.

[0140] In one embodiment of this disclosure, a rule generation module is used to respond to a test request through a vulnerability testing site, obtain the network traffic generated in response to the test request, and analyze the network traffic according to the vulnerability detection rules to detect whether the vulnerability detection service can trigger vulnerability attack alarm information.

[0141] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0142] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0143] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0144] Figure 15 A schematic block diagram of an example electronic device 1500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0145] like Figure 15 As shown, device 1500 includes a computing unit 1501, which can perform various appropriate actions and processes according to a computer program stored in read-only memory (ROM) 1502 or a computer program loaded from storage unit 1508 into random access memory (RAM) 1503. The RAM 1503 may also store various programs and data required for the operation of device 1500. The computing unit 1501, ROM 1502, and RAM 1503 are interconnected via bus 1504. Input / output (I / O) interface 1505 is also connected to bus 1504.

[0146] Multiple components in device 1500 are connected to I / O interface 1505, including: input unit 1506, such as keyboard, mouse, etc.; output unit 1507, such as various types of monitors, speakers, etc.; storage unit 1508, such as disk, optical disk, etc.; and communication unit 1509, such as network card, modem, wireless transceiver, etc. Communication unit 1509 allows device 1500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0147] The computing unit 1501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1501 performs the various methods and processes described above, such as the vulnerability rule generation and verification method based on intermediate components. For example, in some embodiments, the vulnerability rule generation and verification method based on intermediate components can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1508. In some embodiments, part or all of the computer program can be loaded and / or installed on device 1500 via ROM 1502 and / or communication unit 1509. When the computer program is loaded into RAM 1503 and executed by the computing unit 1501, one or more steps of the vulnerability rule generation and verification method based on intermediate components described above can be performed. Alternatively, in other embodiments, the computing unit 1501 may be configured, by any other suitable means (e.g., by means of firmware), to perform a vulnerability rule generation and verification method based on intermediate components.

[0148] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0149] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0150] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0151] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) 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, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0152] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0153] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0154] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0155] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A vulnerability rule generation and verification method based on an intermediate component, wherein the intermediate component is used to construct a simulated environment for vulnerability rule generation and verification that supports dynamic interaction, the method comprising: Run the simulation environment built through the intermediate components; In the simulated environment, the vulnerability scanner tool template is converted into an executable vulnerability detection service, which is a simulated service used to simulate the execution of a vulnerable web server; Vulnerability detection rules are generated in the simulated environment based on the vulnerability scanner tool template. In the simulated environment, the validity of the vulnerability detection rules is verified according to the vulnerability detection service.

2. The method according to claim 1, wherein, The step of validating the validity of the vulnerability detection rules and the vulnerability detection service in the simulated environment includes: The vulnerability detection service is tested using the aforementioned vulnerability detection rules to determine whether the vulnerability detection service can trigger vulnerability attack alerts. When the vulnerability attack alert information associated with the vulnerability detection service is triggered, the validity of the vulnerability detection rule is verified. The vulnerability attack alarm information includes: alarm information triggered by simulated attack traffic in the vulnerability detection service that corresponds to the vulnerability detection rules.

3. The method according to claim 2, further comprising: When the vulnerability scanner tool template is updated, the vulnerability detection rules that have passed the rule validity verification are merged with the corresponding vulnerability detection services and stored in the rule set.

4. The method according to claim 2 or 3, wherein, The step of converting the vulnerability scanner tool template into an executable vulnerability detection service in the simulated environment includes: In the simulated environment, the vulnerability scanner tool template is converted into at least one web simulation server routing function to obtain the executable vulnerability detection service; The Web simulation server is a simulated Web server that has vulnerabilities.

5. The method according to claim 4, further comprising: Deploy and run a vulnerability probing site containing at least one Web simulation server routing function in the simulated environment; Verify the validity of the at least one Web simulation server routing function based on the vulnerability testing site.

6. The method according to claim 5, wherein, The step of verifying the validity of the at least one Web simulation server routing function based on the vulnerability testing site includes: The vulnerability probing site receives HTTP requests that match the vulnerability attack requests defined in the vulnerability scanning template. The vulnerability testing site responds to the HTTP request, and the response result is obtained; If the response result satisfies the vulnerability existence condition defined in the vulnerability scanning template, the validity of the at least one Web simulation server routing function is verified.

7. The method according to claim 6, wherein, The step of testing the vulnerability detection service using the vulnerability detection rules to determine whether the vulnerability detection service can trigger vulnerability attack alerts includes: The network traffic generated in response to the test request is obtained by responding to the test request through the vulnerability testing site; The network traffic is analyzed according to the vulnerability detection rules to detect whether the vulnerability detection service can trigger vulnerability attack alarm information.

8. An intermediate component, comprising: A web simulation service generator based on a large language model is used to receive vulnerability scanner tool templates, parse the vulnerability scanner tool templates, and convert the vulnerability scanner tool templates into executable vulnerability detection services. The vulnerability detection services are simulation services used to simulate the execution of a web server with vulnerabilities. A vulnerability rule generator based on a large language model is used to generate vulnerability detection rules based on the vulnerability scanner tool template, and to verify the validity of the rules based on the vulnerability detection rules and the vulnerability detection service.

9. The intermediate component according to claim 8, further comprising: A task scheduler based on a large language model that is communicatively connected to the web simulation service generator based on the large language model and the vulnerability rule generator based on the large language model. The task scheduler based on the large language model is used to monitor update events of the vulnerability scanner tool template library. When an update of the vulnerability scanner tool template is detected, a new rule generation task is issued to the vulnerability rule generator based on the large language model. The vulnerability detection rules that have passed the rule validity verification are merged with the corresponding vulnerability detection services and stored in the rule set.

10. The intermediate component according to claim 8 or 9, wherein, The Web simulation service generator based on the large language model is used to convert the vulnerability scanner tool template into at least one Web simulation server routing function. The vulnerability rule generator based on the large language model is used to verify the validity of the rules according to the vulnerability detection rules and the at least one Web simulation server routing function; The task scheduler based on the large language model is used to merge the vulnerability detection rules that have passed the rule validity verification with at least one corresponding Web simulation server routing function and store them in the rule set.

11. The intermediate component according to claim 10, wherein the Web simulation service generator based on the large language model is further configured to deploy and run a vulnerability probing site containing the at least one Web simulation server routing function, so as to verify the validity of the at least one Web simulation server routing function through the vulnerability probing site; in, The validity of the at least one Web simulation server routing function is used to characterize whether the at least one Web simulation server routing function can correctly simulate the service behavior of a vulnerable Web server.

12. The intermediate component according to claim 10, wherein, The Web simulation service generator based on the large language model is used to receive HTTP requests that match the vulnerability attack requests defined in the vulnerability scanning template through the vulnerability probing site. The vulnerability testing site responds to the HTTP request and obtains a response result; if the response result meets the vulnerability existence conditions defined by the vulnerability scanning template, the validity of the at least one Web simulation server routing function is verified.

13. The intermediate component according to claim 11 or 12, wherein, The vulnerability rule generator based on the large language model is used to send test requests to the web simulation service generator based on the large language model; and to receive network traffic generated in response to the test requests. The network traffic is analyzed according to the vulnerability detection rules to detect whether the network traffic can trigger vulnerability attack alarm information; The Web simulation service generator based on the large language model is used to respond to the test request through the vulnerability testing site and generate the network traffic.

14. The intermediate component according to any one of claims 10-13, wherein, A web simulation service generator based on a large language model is used to parse the request and response features in the vulnerability scanner tool template to obtain the at least one web simulation server routing function based on the request and response features.

15. The intermediate component according to any one of claims 10-13, wherein, The vulnerability rule generator based on the large language model is used to parse the attack features in the vulnerability scanner tool template to obtain the vulnerability detection rules based on the attack features.

16. A vulnerability rule generation and verification apparatus based on an intermediate component, wherein the intermediate component is used to construct a simulated environment for vulnerability rule generation and verification that supports dynamic interaction, the apparatus comprising: A runtime module for running the simulation environment constructed through the intermediate components; The simulation service generation module is used to convert a vulnerability scanner tool template into an executable vulnerability detection service in the simulation environment. The vulnerability detection service is a simulation service used to simulate the execution of a vulnerable web server. The rule generation module is used to generate vulnerability detection rules based on the vulnerability scanner tool template in the simulated environment; The verification module is used to verify the validity of the vulnerability detection rules in the simulated environment based on the vulnerability detection rules and the vulnerability detection service.

17. An electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

18. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

19. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.

Images