1
GenTI: Benchmarking LLMs for Autonomous IDPS Rule Generation for Unseen Attacks
arXiv:2606.05844v1 [cs.CR] 4 Jun 2026
Hassan Jalil Hadi, Rehana Yasmin, Ali Shoker
Abstract—Rule-based Intrusion Detection and Prevention Systems (IDPS) offer precise attack detection as well as mitigation, however their manually crafted, signature-driven rules limit adaptability to emerging and zero-day threats. Additionally, existing public datasets (e.g., CICIDS2017, UNSW-NB15) focus on traffic classification and provide little structured information to support automatic rule synthesis or prevention logic. To address this gap, we propose Generative Thread Intelligence (GenTI) 1 an LLM-driven benchmark for automatic generation of IDPS rules targeting unseen attacks. The dataset (GTI) aggregates over 150k detection and prevention rules from Snort, Suricata, Emerging Threats, as well as 50k YARA, each annotated with protocol behavior, payload signatures, contextual relationships, mappings to Cyber Threat Intelligence (CTI), along with actionable response types (alert, drop, reject). Moreover, on top of this corpus we design an LLM-based pipeline that transforms analyst prompts and representative payloads into deployable rules via structured prompt engineering, Chain-of-Thought (CoT) reasoning, as well as a Chain-of-Verification (CoVe) loop for syntactic, semantic, and security validation. The generated rules are executed in real time on (Snort/Suricata) and evaluated by syntax accuracy, semantic similarity, CTI coverage, security effectiveness as well as unseen attacks detection. Furthermore, our GenTI instantiation achieves a composite rule-quality score of 89.4%, with 94.8% CTI coverage, improving unseen attacks detection from 45% to 87.4% and reducing the false-positive rate from 8.5% to 2.3%. Overall, GenTI establishes the first large-scale benchmark that tightly couples rule-level CTI with LLM-based automation, enabling adaptive, self-evolving IDPS.
behaviour-based, machine learning-based, and anomaly detection approaches [4], [5]. Rule-based (signature-based) systems identify threats by matching observed traffic against predefined attack patterns, triggering alerts when a rule condition is satisfied, as illustrated in Fig. 1. Behavioural and statistical methods typically rely on thresholds or aggregated metrics to flag deviations. Further, anomaly detection methods learn normal traffic patterns and detect malicious activity as significant departures from this learned baseline. Although, machine-learning-based NIDPS have demonstrated strong detection capability [1], they are still rarely trusted in production environments due to opaque decision processes and the large number of false alerts they may generate [5], [6]. As a result, rule-based NIDPS remain the dominant choice in many organizations. Open-source communities provide and maintain extensive rule sets for engines such as Snort, Suricata, YARA as well as Emerging Threats, which are continuously updated and widely deployed. However, these rule sets primarily detect known attacks and offer limited protection against zero-day or previously unseen intrusion attempts. This limitation arises because rules are typically crafted manually by security experts based on already disclosed vulnerabilities and documented attack patterns.
Index Terms—IDPS, Large Language Models (LLMs), CTI, Cybersecurity Automation, Unseen Attacks
I. I NTRODUCTION
I
N recent years, the scale and sophistication of cyber threats have continued to grow, making timely as well as accurate detection of attacks a central challenge in cybersecurity. To mitigate these risks, organizations increasingly rely on a broad ecosystem of security solutions, including next-generation firewalls, Network Intrusion Detection Systems (NIDS), Network Intrusion Prevention Systems (NIPS) [1], Security Operations Centers (SOC) [2], Security Information and Event Management (SIEM), endpoint detection [3], EDR, XDR and response tools [1]. Among these, NIDPS are particularly critical, as they monitor network traffic, identify suspicious or abnormal behavior, and generate alerts or protective actions to support security analysts. Also, modern NIDPS techniques can broadly be categorized into rule-based, statistical-based,
Fig. 1. Core Architecture of a Basic NIDPS
Hassan Jalil Hadi, Rehana Yasmin, and Ali Shoker are with the Cyber Security and Resilience Technology (CyberSaR), King Abdullah University of Science and Technology (KAUST), Saudi Arabia (e-mail: [email protected], [email protected]). 1 GenTI refers to the proposed framework, and GTI refers to the dataset.
Furthermore, attackers increasingly exploit undisclosed vulnerabilities and employ obfuscation techniques to disguise payloads and evade existing signatures. These strategies create new attack variants for which no rules currently exist.
2
To address this challenge, numerous machine-learning-based intrusion detection approaches have been proposed to identify previously unseen attacks [7]. Nevertheless, these models are usually trained on a narrow set of attack patterns from a number of public datasets, such as CICIDS2017 [8] and CSECIC-IDS2018 [8], which restricts their coverage along with generalization in realistic environments. To bridge this gap, our work introduces a new benchmark dataset Generative Thread Intelligence (GTI) , designed to support automatic generation, updating, and verification of detection as well as prevention rules for IDS and IPS. In addition, automatic generation of high-quality detection rules faces three key challenges. First, there is no largescale, publicly available benchmark dataset tailored for IDPS research. Existing resources do not support fine-tuning LLMs on rule synthesis, refinement, or contextual reasoning. Second, most automatic rule-generation methods are designed for firewalls or header-level pattern matching. As a result, they fail to capture payload-level semantics and the detailed behaviours, tactics, and techniques used in modern attacks. Third, there is no systematic mechanism to verify the syntactic correctness and semantic soundness of automatically generated rules. It also remains unclear whether such rules can operate with acceptable false-positive rates in realistic production environments. To address these issues, we propose GenTI, a benchmark dataset (GTI) and LLM-driven workflow for automatic NIDPS rule generation. GenTI provides a large corpus of payloadaware detection as well as prevention rules, enriched with mappings to CTI sources such as OTX, MISP, and MITRE ATT&CK. The workflow consists of seven components including, preprocessing, prompt analysis, attack–sample mapping, rule refinement and validation, CoT–CoVe reasoning, and output generation. Attack payloads and metadata are first normalized then converted into task-specific prompts. After that, a three-stage prompt design is applied in which LLMs generate the initial rules and Chain-of-Thought (CoT) prompting refines the rule logic. Then, a Chain of Verification (CoVe) integrates refinement and optimization to remove redundant rules, prune irrelevant options, and ensure syntactic along with semantic consistency, thereby reducing false positives. Building on this pipeline, the main contributions of this work are as follows: • Firstly, to the best of our knowledge, we introduce GTI, the first benchmark dataset and CTI-enriched corpus tailored to LLM-based NIDPS rule generation. It consolidates over 150k detection as well as prevention rules from Snort2 , Suricata3 , Emerging Threats4 5 , and 50k YARA into a unified format. It leverages LLMs to map rules to CTI sources (e.g., MITRE ATT&CK, MISP, OTX) and to annotate Rule–Context and Relationships Annotation (RCRA), thereby providing deeper insight into attacks and their corresponding detection rules. • Secondly, we incorporate YARA-style payload-level signatures and translate them into IDPS-compatible logic, 2 https://www.snort.org/downloads 3 https://suricata.io/download/ 4 https://rules.emergingthreats.net/ 5 https://rulezet.org/
enabling the automatic generation of both detection as well as prevention rules (e.g., alert, drop, reject) at the payload level. • Thirdly, we develop a four-stage progressive training pipeline comprising: (1) syntactic grounding through rule structure and header pattern learning, (2) semantic enrichment via CTI-augmented CoT reasoning, (3) CoVedriven verification for false-positive reduction, and (4) fullcomplexity integration with transfer learning across stages. • Lastly, a real-time evaluation of GenTI on open-source NIDPS engines (Snort and Suricata) is performed using realistic malicious and benign traffic, showing strong malicioustraffic detection performance across standard IDS metrics. II. R ELATED WORK This section reviews related work on three key aspects including, (1) Existing IDS datasets, (2) Automatic rule generation for malicious traffic detection, and (3) The need for benchmark datasets that support LLM-based rule synthesis and evaluation. We also underline the limitations of current approaches that motivate the design of the proposed GenTI benchmark. A. Existing IDS Dataset Early research on NIDS has relied heavily on benchmark datasets such as DARPA [17], KDD-Cup99 [9], NSL-KDD [10], DEFCON [11], CAIDA [18]. These datasets were primarily designed for flow or connection-level anomaly and attack classification, often in simulated or controlled network environments. Later efforts, including [8], CSE-CIC-IDS2018 [8], UNSW-NB15 [19], 5G-NIDS [12], IoT-NI [13], IoT-23 [15], MQTT-IoT-IDS [15], and UAV-NIDDs [16], provide more diverse and realistic traffic. They include multiple attack categories such as DoS, probing, brute force, botnets, and DDoS. A recent survey offers a concise overview of these datasets until 2024 and confirms their continued importance for evaluating NIDS performance [5], [16]. However, as summarized in Table I, these datasets are not designed for rule-level modeling or automatic new rule generation. Most of them do not release the actual IDS rules used in their experiments, nor do they provide structured mappings to CTI sources. Attributes that are crucial for LLM-based rule synthesis are typically absent, including rule availability, CTI mapping, RCRA, rule verification metadata, explicit action types (e.g., alert, drop, reject), and any indication of LLM compatibility or unseen attacks utility. Moreover, they mainly expose flow or header-level features (e.g., IP addresses, ports, and basic protocol statistics) and provide little or no labelled payload content. In practice, they support traffic or attack classification. However, they cannot be directly used to learn how production-grade IDPS rules, especially payloadlevel rules based on YARA-style content patterns, are written, refined, or validated. In contrast, GenTI is explicitly constructed as a rule-centric benchmark. It aggregates more than 200k real-world detection as well as prevention rules from Snort, Suricata, Emerging Threats, YARA, and attaches rich metadata for each rule,
3
TABLE I C OMPARISON OF C URRENT I NTRUSION D ETECTION DATASETS WITH THE GTI B ENCHMARK . = “N OT AVAILABLE ”, = “PARTIALLY AVAILABLE ”, = “AVAILABLE ”. Dataset
Rule Availability
CTI Mapping
RCRA
KDD-Cup99 [9] NSL-KDD [10] DEF-CON [11] CICIDS2017 [8] CIC-IDS2018 [8] 5G-NIDS [12] IoT-NI [13] IoT-23 [14]
DoS, Probe, R2L, U2R DoS, Probe, R2L, U2R Buffer Overflow DDoS Port Scanning Botnet Fuzzers, DoS, Exploits DDoS, Heartbleed, Infiltration, Brute-Force UDPFlood, HTTPFlood DoS, MITM, Port Scan, Botnet All Types of Attacks
MQTT-IoT [15] UAV-NIDDS [16] GTI (2025)
200K+ real production IDPS rules
Type of Attacks
Chain of Thought
including CTI mappings, RCRA, rule verification status, and action types. Moreover, GenTI is explicitly designed for rulelevel modelling at the payload level. It exposes rich, labelled payload content and YARA-style signatures, enabling LLMs to learn as well as synthesize new regular expressions with content patterns required for rule creation. This design aims to improve coverage of previously unseen attacks. These attacks manifest their behavior in payload semantics rather than only in header features. As a result, GenTI is suitable for evaluating intrusion detection performance. It is also uniquely suited for fine-tuning and assessing LLM-based pipelines that perform rule generation, refinement, and verification.
B. Approaches to Automatic Rule Generation Automatic generation of detection rules from attack samples can reduce the manual workload of security experts and improve the detection of unseen attacks and emerging threats. Early work on automatic rule generation relied on honeypots and protocol analysis without using machine learning. Honeycomb, for example, creates Snort rules by extracting common substrings from honeypot sessions and applying protocol conformance checks to avoid trivial patterns [20]. Such systems reduce some manual effort, but the generated rules are typically narrow, tied to specific flows, and lack higher-level threat semantics. Later approaches introduced machine-learning techniques to mine signatures from malicious traffic. LARGen used Latent Dirichlet Allocation on network flows to extract multiple content strings and then constructed IDS signatures from the resulting topics. Further, CMIRGen combined clustering, sequence similarity, and black-box model inference to derive token-based rules from malicious payloads, improving robustness over simple pattern matching [21]. Besides, the automatic NIDS Rule Generating System focused on HTTPlike malware communication and generated Snort rules from protocol-aware analysis of traffic traces [22]. These methods generalised better than pure honeypot pattern mining, yet they still operate on limited attack corpora, focus mainly on flow
Rules Verification
Actions Types
LLM Compatibility
Unseen Attacks Utility
CoVe Alert, Drop, Reject
or header features, and provide little semantic context about tactics, techniques, or vulnerabilities. More recently, LLMs have been used to automate IDS rule creation. Harnessing LLMs for automated rule generation in cyber ranges introduced a prompt-based framework that generates and refines rules for web attacks [23]. Hex2Sign converts hexadecimal PCAP data from honeypots into Suricata signatures using LLMs, demonstrating rule synthesis directly from low-level traffic [24]. Hu et al. designed an LLM-based agent that ingests vulnerability reports and existing rules to generate and generalize IDS signatures, showing improved detection on proprietary datasets [25]. These LLM-driven systems show that large models can reason about attack payloads and security context. However, existing work typically rely on small rule sets (roughly 400–700 IDS rules) and narrowly scoped, task-specific datasets (e.g., web attacks, vulnerabilityspecific traffic, or header-level features). Additionally, instead of designing fundamentally new, payload-level rules for unseen attack patterns, current methods largely regenerate similar instances of existing rules. As a result, they are not evaluated in production or real-time environments, do not release reusable rule corpora, and do not provide payload-level YARA-style signatures. C. Why creating a new benchmark dataset Upon careful examination of Table I and the current landscape of IDS datasets, we identify two critical limitations. First, existing datasets such as CICIDS2017 [8], CSECICIDS2018 [8], UNSW-NB15 [19] and related corpora have greatly facilitated NIDS research. However, these datasets cover a relatively fixed set of attack families (e.g., DoS, DDoS, brute-force, basic web attacks) and are primarily labelled for traffic classification. Consequently, they provide limited support for modelling zeroday behaviour or for deriving new patterns and signatures that generalize beyond predefined attack types. Second, most of these datasets are traffic-oriented, they provide packets, flows, and labels, but do not expose the underlying IDPS rules or the contextual information that drives rule engineering. They lack structured CTI (e.g., MITRE
4
ATT&CK, CVE/CWE, D3FEND, MISP, OTX), RCRA, and detailed payload-level semantics such as reusable regular expressions or YARA-style content patterns. This also prevents the systematic training and evaluation of LLMs on realistic rule-generation and rule-verification tasks. To address these limitations, we proposed GenTI to fill precisely this gap by providing a rule-centric, CTI-enriched, payload-aware benchmark that exposes both production rules and their surrounding context for LLM-based IDPS rule synthesis. III. P RELIMINARY This section present IDPS and YARA rule structure to understand rule architecture. IDPS uses signature-based rules that provide rudimentary payload inspection capabilities and mainly function at the network and transport levels (L3/L4). The four main parts of an IDPS rule are the rule header, rule message, rule content, and rule metadata, as shown in Fig. 2. The action type (drop/reject for active IPS prevention or alert for detection-only IDS mode), source and destination addresses with port numbers, protocol specification, and traffic direction are among the network-layer attributes defined by the rule header. Simple payload matching, such as matching HTTP methods or file extensions (e.g., content="GET"; content:".exe") is made possible by the rule content section using string patterns and regular expressions. Nevertheless, the payload structure’s spatial precision is lacking in these content matches. The throughput speed is given priority in this architectural design, IDPS engines like Snort and Suricata can process several million packets every second at network perimeters, making them appropriate for real-time traffic monitoring and quick threat alerts based on recognized protocol characteristics.
the rule name and classification tags. Hexadecimal byte sequences with wildcards (such as {6A 40 68 00 30 00 00}), ASCII and Unicode text strings, and regular expressions to match Command & Control (C2) communication patterns are all supported by the strings section. Crucially, offsetprecise matching is made possible by the condition section, which enables analysts to provide specific byte locations (like \$mz at 0 for PE header validation) or byte ranges inside file structures (like $shellcode in (0x400..0x1000) for code section analysis). By identifying particular shellcode patterns, decryption techniques, and API call sequences at their anticipated locations inside executable binaries, this specific positioning capability enables precise malware family.
Fig. 3. YARA Rule Structure
IV. M ETHODOLOGY FOR CREATING THE DATASET A. Datasets (GTI)
Fig. 2. Modern IDPS Rule Structure
Unlike header-level IDPS rules, YARA offers a patternmatching framework made especially for deeper payload analysis at the application layer (L7), allowing accurate binary analysis of memory dumps, network streams, and file contents. A YARA rule, as shown in Fig. 3, is composed of four sections: a strings section that defines payload-level signatures, a condition section that specifies the detection logic, a meta section that documents threat intelligence context, containing malware family attribution, and the rule header that contains
We curate a CTI-enriched corpus, termed GTI, which is organised into two complementary components: an IDS/IPS rule component (GTI–IDPS) and a YARA rule component (GTI–YARA). The IDPS part captures network-level behaviour, while the YARA part targets payload and file-level patterns. Together, these components support the analysis as well as generation of rules that operate both on packet headers/flows and on content. Further, the GTI–IDPS component is derived from Snort and Suricata rule sets together with selected emerging signatures. Each rule is normalised into a fixed schema that groups fields into header, flow, threat-context, CTI, and rulemetadata categories. At a high level, the dataset records how the rule views the traffic, including the protocol, direction, and application service. It also specifies what the rule is designed to detect (such as payload patterns and attack types) and how it fits within the broader threat-intelligence landscape through MITRE ATT&CK/D3FEND mappings, CVE/CWE links, and malware family associations. Additional blocks store intelligence from AlienVault OTX and MISP, as well as the
5
TABLE II GTI F IELD G ROUPS AND C OVERAGE Category Header Features (8) Flow Features (3) Payload Features (3) Threat Context (10) OTX Intelligence (4) MISP Intelligence (8) Action & Impact (3) Training Prompts (6) Rule Metadata (3)
Fields protocol, src ip, dst ip, src port, dst port, tcp flags, ttl, ip fragments flow direction, flow state, detection filter payload content, application layer field, target service classtype, attack type, mitre techniques, mitre tactics, mitre d3fend, mitre report, ioc, cve id, cwe id, malware family otx pulses, otx cves, otx malware, otx refs misp event ids, misp threat level, misp tags, misp galaxies, misp sightings, misp last seen, misp org, misp attr ids action, severity level, confidence score rationale, reference, input prompt, user prompt, rule syntax, target output rule text, sid, rev
operational action, severity with confidence level of the rule. Finally, a dedicated prompt block encodes an input prompt, user-style prompt, rationale, rule-syntax explanation and target rule, which we later use for LLM training and evaluation. The complete set of 48 structured fields and their categories is summarised in Table II. Next, the GTI–YARA component focuses on payload-level signatures. Each YARA rule is represented by its identifier, rule body and parsed abstract syntax tree, along with the indicators embedded in the rule (metadata, string definition, condition expression, and registry keys). For every rule we record both counts and lists of these IoCs, together with CTI from MISP and OTX, mappings to ATT&CK and D3FEND, quality scores and provenance information. Similar to the IDPS part, we attach LLM-oriented annotations such as an explanation of what the rule detects, recommended use-cases, deployment notes, suggested variants and safety warnings. B. Dataset Construction The construction of the GTI dataset follows the CTIenriched pipeline as shown in Fig. 4, which consists of twelve stages (steps 1–12) from rule ingestion to LLM-ready examples and response actions. The main steps are outlined below. • First, we aggregate base rules from multiple sources (steps 1–2). Snort and Suricata distributions and selected community rule sets provide the initial IDPS signatures. Besides, high-quality public YARA repositories and in-house rules contribute the payload-level signatures. After deduplication as well as normalisation, we incorporated two additional repositories containing both So_Rules (sharedobject rules) and Preproc-Rules (preprocessor-based detection rules)6 . These expanded rule sources were then passed to the GTI controller in the Data Source block. The controller orchestrates the flow of rules towards the parser, CTI modules, LLM models, and the database. • Second, we perform rule parsing and schema normalisation (step 3). For IDPS rules, a dedicated parser extracts header, flow features, such as the network protocol, source and destination IP addresses, along with ports, TCP flags, TTL, and fragmentation bits. It also identifies flow direction and state, detection filters, in addition to application-layer payload content (e.g., HTTP fields or target service). Together 6 https://www.snort.org/downloads
Coverage 100% 67% 100% 78%
Purpose Network packet analysis Connection tracking Deep packet inspection Threat intelligence
75% 88%
AlienVault threat data Community threat sharing
100% 100% 100%
Rule execution control LLM training data Rule identification
with this, we derive a compact initial context, including the classtype and high-level attack_type. For YARA rules, we construct an abstract syntax tree (rule_ast) from the raw rule body and isolate imports, metadata, string definitions and condition expressions. At this stage, each rule is represented as structured rules data (IP-level fields, metadata, direction and action) that can be systematically enriched and, where appropriate, directly stored in the repository. • Third, we derive Indicators of Compromise (IoCs) from the parsed rules (step 4). In GTI–IDPS, each signature is associated with a primary IoCs and, where available, cve_id, cwe_id as well as malware_family. In GTI–YARA, we count and enumerate all indicator types embedded in the rule body, including metadata, string definition, condition expression, and registry keys (stored in the corresponding iocs_* fields). These IoCs form the bridge between static rule content as well as external threat-intelligence services and are forwarded by the GTI controller to the MITRE enrichment modules. • Fourth, we enrich both components with external CTI from AlienVault OTX (steps 5–6). The extracted IoCs are submitted to OTX to retrieve related pulses, CVEs, malware entries, and external references, which are stored in the otx_* fields. The returned CTI is then normalised into STIX objects and cached in a local STIX/TAXII store. This intermediate STIX representation enables consistent reasoning over OTX data and avoids repeated external lookups when rules share indicators. • Fifth, we perform MITRE ATT&CK and D3FEND mapping using the MITRE Enrichment module (steps 7–8). The STIX-encoded CTI, together with rule descriptions and any embedded references, is mapped to one or more ATT&CK tactics as well as techniques, in addition to relevant software and adversary groups. The same context is passed through the D3F3ND ontology to obtain corresponding defensive techniques and countermeasures. In the IDPS component these mappings appear in mitre_techniques, mitre_tactics, mitre_d3fend, and mitre_report. In the YARA component we additionally maintain explicit counts (e.g., mitre__count, d3fend__count) alongside the lists themselves. The resulting ATT&CK/D3FEND mappings are persisted to the central database as part of the threat-context layer. • Sixth, we integrate community threat intelligence from
6
Fig. 4. CTI-enriched dataset construction infrastructure for GenTI
MISP (steps 9–10). Using the same IoCs, the GTI controller queries one or more MISP instances and retrieves event identifiers, attributes, tags, galaxies, threat levels, sightings, last-seen timestamps, and the contributing organisation. These responses are normalised into the misp_* fields and attached to each rule instance. Together with the OTX/STIX and MITRE/D3FEND blocks, this yields a multi-source CTI profile for every rule. • Seventh, we compute quality and operational metrics. For IDPS rules, we record the runtime action (alert, drop, or reject), the severity level (severity_level), and a confidence score (confidence_score). This score reflects how well the CTI supports the rule and how reliable the signature is expected to be in practice. We compute overall, completeness, complexity, coverage, and CTI-confidence scores for YARA rules. Provenance fields provenance_source_file and provenance_collection _timestamp are populated to ensure traceability and reproducibility of the dataset, as well as to support later ablation studies. • Eighth, the system employs a multi-model LLM architecture to achieve robust and nearly accurate CTI enrichment of the
security ruleset for those rules which have missing IOCs and or highly simple rules (step 11). So all the rules should have proper relative information. This process bifurcates based on the presence of existing IOCs; where IOCs are present. Further, LLMs are utilized for targeted contextual enrichment. Conversely, rules lacking IOCs undergo synthetic CTI generation primarily facilitated by the Qwen-7B model. To ensure the generation of high-fidelity, contextually relevant CTI, the LLaMA 3.2-7B model is strategically deployed for sophisticated instructional prompting (prompt engineering). Furthermore, all intricate human language-based tasks, including the generation of use cases, the building of rationale, and linguistic enrichment for auto prompt refinement, are delegated to the DeepSeek-7B model. This model is guided by precise instructions derived from the LLaMA 3.27B model. • Ninth, we integrate a prompt-engineering layer to support LLM-based rule synthesis and explanation (step 12). A structured input_prompt is constructed from the header, flow, payload, and CTI fields for every IDPS rule. A corresponding user_prompt is written in the style of an analyst asking for a rule. The canonical Snort/Suricata signature is
7
stored as target_output, while rationale and In the second phase, it conducts a logical check comparing rule_syntax provide natural-language explanations of the rule conditions with the mapped ATT&CK technique, the detection logic. YARA rules use llm_rationale, payload semantics, and CTI context. In the third phase, CoVe llm_use_cases, llm_deployment_notes, and executes a false-positive analysis by replaying benign traffic llm_variants to capture the model’s reasoning, profiles. If any check fails, the rule is rejected and may trigger intended deployment scenarios, and suggested variants, another refinement cycle; only rules that pass all CoVe stages while llm_safety_warnings highlights any potential are promoted to final outputs. For each accepted rule, GenTI misuse. These artifacts constitute the prompt-engineering also computes a composite score combining syntax accuracy, block stored alongside the CTI-enriched records. semantic similarity, CTI coverage and security effectiveness, • Finally, all enriched records are stored in the GTI repository which is later used in comparative evaluation. and linked to the downstream detection-and-response layer (alerts, block/drop, reject), forming the right-hand part of the pipeline. The resulting corpus combines network-level IDPS B. GenTI System Modules To implement the above solution, GenTI is decomposed into rules and payload-level YARA signatures with detailed CTI mappings, MITRE/D3FEND context, RCRA, quality the following modules, corresponding to the numbered blocks metrics, and LLM-oriented annotations. This forms a com- in Fig. 5: prehensive benchmark for automatic new rules generation 1) Analyst Prompt & Payload Analysis (Pre-processing): and evaluation, as illustrated in Fig. 4. The process begins with an analyst describing the suspected threat in natural language (e.g., QakBot C2 traffic to a known Feodo Tracker host). This description includes exV. P ROPOSED G EN TI F RAMEWORK plicit requirements such as tracking by source IP, temporal In this section, we introduce the GenTI framework, which thresholds, and references to specific ATT&CK techniques. transforms CTI-aware analyst prompts and representative atIn parallel, representative payloads are parsed, and salient tack payloads into verified IDPS rules. GenTI operates as features such as HTTP headers, C2 markers and known bot an end-to-end pipeline that integrates prompt analysis, LLMsignatures are extracted to form an initial feature set F0 . based rule synthesis, CTI-driven attack mapping, COT, itera2) Prompt Construction and LLM Process (Prompt Analtive rule refinement, and a structured CoVe stage. The overall ysis: The prompt-construction module consolidates the anaarchitecture of the framework is depicted in Fig. 5. lyst intent, payload features and selected CTI attributes into a structured prompt Pstruct and a natural-language prompt A. Solution Approach Puser . The LLM process interprets the detection objective, At a high level, GenTI takes as input a CTI-aware analyst infers the traffic and environment context, and analyses prompt, representative malicious payload samples and the payload patterns. It then generates an initial IDPS rule enriched rule context from the GTI dataset. The goal is to candidate r0 along with RCRA and CoT C0 . produce a IDPS compatible rule that is syntactically correct, 3) Threat-Intelligence Mapping (Attack Sample Mapping): semantically aligned with the analyst intent and mapped to Using indicators extracted from r0 and the payloads, this the appropriate MITRE ATT&CK and D3FEND entries, while module queries the CTI store built from AlienVault OTX, also satisfying security-effectiveness constraints. MISP and MITRE ATT&CK/D3FEND. It returns a threatThe generation and optimisation phase starts from strucintelligence profile comprising technique and tactic identitured context extracted from the analyst prompt and payloads. fiers (e.g., T1071.001 / TA0003), related CVE/CWE entries, A prompt-construction module builds a structured prompt malware families and external feed references. This profile Pstruct and an analyst-style user prompt Puser . These are prois attached to the candidate rule as its threat context. vided to the LLM together with selected CTI fields (e.g., 4) Rule Refinement and Validation Engine: This engine mapped CTI techniques, IoCs, malware family) to generate an realises the refinement loop in Algorithm 1. Each candidate initial candidate rule r0 and a COT trace C0 . GenTI then enters rule rk is evaluated against malicious and benign traces and an iterative refinement loop, where each rule candidate rk is representative payload variants. Basic checks ensure that the evaluated on both attack and benign traffic. This evaluation rule fires on all known attack samples and remains silent on produces a metric vector Mk that captures syntax validity, clean traffic. Rule variants that either over-generalise or miss semantic similarity to the baseline intent, ATT&CK coverage, important samples are discarded. The engine records status detection rate, false-positive rate, and resource cost. If Mk labels (PASS/FAIL) for each variant and generates focused does not satisfy configurable thresholds, a feedback message feedback Fk+1 that highlights missing patterns, overly broad Fk+1 is constructed and fed back into the LLM to produce a conditions or conflicting options. refined rule rk+1 . This loop continues until convergence, as 5) Optimisation and Metric Computation: Candidates that captured in the refinement block of Algorithm 1. pass basic validation proceed to a performance evaluation Next, the verification phase applies a structured CoVe stage, where their effectiveness and impact are assessed. In pipeline to the best candidate from the optimisation phase. this stage, GenTI computes metrics such as detection rate, CoVe comprises three ordered checks. In the first phase, CoVe false-positive rate, computational impact (e.g., average CPU performs a syntactic check to ensure Snort/Suricata compatutilisation), coverage of the targeted ATT&CK technique, ibility, including the header, options, and keyword structure. and an overall threat level.
8
Fig. 5. Proposed GenTI workflow for CTI-aware, LLM-driven intrusion detection rule generation and verification.
6) Chain-of-Verification (CoVe): CoVe performs final verification in three ordered stages: syntactic verification, logical verification and false-positive analysis. Syntactic verification ensures that rk can be loaded by the IDS engine without errors. Logical verification checks the consistency between the rule and its ATT&CK/D3FEND mapping. It validates that the protocol, ports, payload patterns, and flow direction align with the documented behaviour for the specific technique. False-positive analysis replays benign traffic profiles to identify noisy triggers; rules that cause unacceptable alert volumes are rejected. 7) Output Assembly and Reporting: Rules that pass CoVE are used by GenTI to construct a final output record. This record includes the verified Suricata/Snort rule with SID and revision, a natural-language explanation based on the CoT describing the QakBot C2 detection logic and its threat context, a concise MITRE report with associated techniques, tactics, and D3FEND defences, and a short deployment guide. The deployment guide summarises how the rule should be tested, monitored, and tuned before production use.
C. CoT/CoVE-based Data Augmentation The LLM component inside GenTI is trained not only on plain rule–prompt pairs, but also on auxiliary examples that encourage explicit reasoning and self-verification. We construct additional training samples for each rule instance in the GenTI dataset that expose the CoT and CoVe structure of the framework. Concretely, given a CTI-enriched rule record, we generate a reasoning-style prompt that asks the model to explain why the rule correctly detects a given attack scenario. We also generate a verification-style prompt that asks the model to check the rule for syntactic errors, logical inconsistencies, and potential false-positive conditions. The corresponding targets are derived from the ground-truth rule, its CTI mappings (e.g., ATT&CK technique, malware family) and pre-computed validation results. These augmented samples are stored as additional CoT and CoVe entries in the training set and are interleaved with standard generation examples during finetuning. This augmentation has two effects. First it teaches the model to verbalise the detection logic and threat context that underlie a rule, which directly improves the quality of the natural-language explanations produced at inference time. Second, it exposes the model to structured verification patterns (syntax checks, semantic checks and FP analysis), thereby
9
Algorithm 1 GenTI: CTI-aware LLM rule generation and verification Require: Analyst prompt P ; payload samples S; CTI store C Ensure: Verified IDPS rule r̂ with context ĉ
1: Pre-processing and prompt construction 2: (Pstruct , Puser , F0 ) ← B UILD P ROMPT(P, S) 3: Initial LLM generation 4: (r0 , C0 ) ← LLMG ENERATE(Pstruct , Puser , F0 ) 5: Threat-intelligence mapping 6: c0 ← M AP CTI(r0 , S, C) 7: Refinement and validation loop 8: k ← 0 9: while N OT C ONVERGED(rk , ck ) do 10: Mk ← E VALUATE RULE(rk , S) ▷ DR, FPR, CPU, coverage 11: if M EETS T HRESHOLDS(Mk ) then 12: break 13: end if 14: Fk+1 ← B UILD F EEDBACK(Mk ) 15: (rk+1 , Ck+1 ) ← LLMR EFINE(Pstruct , Puser , Ck , Fk+1 ) 16: ck+1 ← U PDATE CTI(rk+1 , C) 17: k ←k+1 18: end while 19: Chain-of-Verification (CoVe) 20: if not S YNTACTIC OK(rk ) then 21: return R EJECT RULE() 22: end if 23: if not L OGIC OK(rk , ck ) then 24: return R EJECT RULE() 25: end if 26: if not FPA NALYSIS OK(rk ) then 27: return R EJECT RULE() 28: end if 29: Finalisation 30: r̂ ← rk 31: ĉ ← B UILD C ONTEXT(Ck , ck ) 32: return (r̂, ĉ)
▷ Explanation, MITRE report, short guide
aligning the model’s internal reasoning with the downstream CoVe pipeline and improving robustness to imperfect prompts.
number of epochs with a stage-specific learning rate schedule, and the model parameters are warm-started from the previous stage. This curriculum design prevents the model from overfitting to complex CTI-heavy rules at the beginning of training, while still allowing it to master the full spectrum of rule complexity by the final stage. In our experiments, the curriculum yields higher syntax accuracy, better semantic similarity and improved CTI coverage compared to a single-stage fine-tuning regime on the same data. VI. E XPERIMENTS AND E VALUATION A. Dataset (GTI) and Experimental Configuration In this section, we present the experimental evaluation of GenTI, relying on the CTI-enriched GTI corpus introduced in Section IV. The corpus contains approximately 150 k IDPS rules and 50 k payload-level YARA rules. The network subset aggregates signatures from Snort and Suricata taken from their official distributions and curated community feeds. It also includes a small number of high-quality emerging rules contributed by industry partners. Each IDPS rule is normalised into the GTI–IDPS schema (Table II). Every rule instance is annotated with an impact level (low, medium, high, critical) based on its mapped MITRE ATT&CK technique, associated CVEs, and analyst-provided severity labels. This produces a distribution that is skewed toward high and critical threats (Fig. 6). In addition, we assign each example a difficulty score that captures structural and contextual complexity, such as the number of payload constraints, richness of CTI annotations, and presence of CoT/CoVe-augmented prompts. This score is then used to build the curriculum schedule.
D. Curriculum Learning with Difficulty Levels To further stabilise training and improve generalisation, we adopt a multi-stage curriculum learning strategy over the dataset. Each rule instance is assigned a scalar difficulty score that reflects the complexity of its structure and threat context. The score accounts for factors such as the number of header and payload constraints, the richness of CTI annotations (including multiple ATT&CK techniques and CVE/CWE links), and the presence of CoT/CoVe augmented prompts. Lower scores correspond to simple header-only rules with minimal CTI context, whereas higher scores correspond to rules with complex payload patterns and dense CTI mappings. We partition the training set into a sequence of curriculum stages, where early stages contain only low-difficulty examples and later stages progressively introduce more complex rules. In Stage 1, the model is exposed primarily to syntactically simple rules and basic generation prompts, which allows it to quickly learn the core Snort/Suricata syntax and common header patterns. Stage 2 introduces examples with richer CTI context and simple CoT prompts, encouraging the model to connect rule structure with ATT&CK techniques and IoCs. Stage 3 adds harder CoVe-augmented examples, emphasising verification and robustness. Finally, Stage 4 combines the full difficulty range of rules. Each stage is trained for a fixed
Fig. 6. Attacks Severity Level
Next, the combined corpus is split in a stratified manner into 80% training, 10% validation, and 10% test data. This preserves the distribution of rule sources, MITRE ATT&CK techniques, severity levels, and difficulty scores, while ensuring that rules remain within the same partition. By default, all quantitative results in this section are reported on the held-out test set. GenTI is implemented in PyTorch using HuggingFace Transformers and fine-tuned on a 8 Nividia A100 GPUs. We
10
adopt a QLoRA-based recipe on the DeepSeek-7B backbone, training lightweight adapters over four curriculum stages that progress from simple header/payload patterns, through complex rule-syntax learning and reasoning (e.g., evasion and pattern detection), to CTI-rich, verification-oriented examples. The mini-batch size, learning rate of 10−4 , and the number of epochs per stage are chosen to fit within the A100 memory budget while maintaining high GPU utilisation. Early stopping is applied based on the validation composite score. B. Evaluation Metrics We evaluate GenTI on a held-out test set of CTI-aware prompts and their corresponding expert-analyst rules. For each test instance the model generates a candidate rule, which is then scored along five dimensions, Syntax Accuracy (SA), Semantic Similarity (SS), CTI Coverage (CC), Security Effectiveness (SE), and a Composite Score (CS). All metrics are normalised to the range [0, 1] unless stated otherwise. 1) Syntax Accuracy (SA): Syntax accuracy measures whether the generated rules are accepted by the target engine without manual correction. Let N be the number of generated rules and 1{·} the indicator function that returns 1 when its argument is true and 0 otherwise. A rule r̂i is considered syntactically valid if it can be loaded by Snort/Suricata (or the YARA engine) without parse errors: N
SA =
1 X 1{PARSE OK(r̂i )}. N i=1
(1)
This metric captures the model’s ability to respect low-level rule syntax and keyword structure. 2) Semantic Similarity (SS): Semantic similarity evaluates how closely a generated rule r̂i matches the corresponding reference rule ri in terms of detection intent. We decompose each rule into a set of key fields (e.g., protocol, direction, source/destination ports, flow options, main content pattern, action). Let F denote this field set and f (r) the value of field f in rule r. The per-instance similarity is defined as the fraction of fields that match: 1 X SSi = 1{f (r̂i ) = f (ri )}, (2) |F| f ∈F
and the overall semantic similarity is the average over the test set: N 1 X SS = SSi . (3) N i=1 For YARA rules we apply the same definition using protocolagnostic fields such as condition structure and sets of IoCs. 3) CTI Coverage (CC): CTI coverage quantifies how well the generated rules preserve the ground-truth ATT&CK mappings. Let Ti be the set of ATT&CK techniques associated with the reference rule ri and T̂i the set predicted (or implied) by the generated rule r̂i . We define a per-instance Jaccard similarity: |Ti ∩ T̂i | CCi = , (4) |Ti ∪ T̂i |
and report the average CTI coverage as N
CC =
1 X CCi . N i=1
(5)
4) Security Effectiveness (SE): Security effectiveness reflects the operational quality of the generated rules when deployed on network traffic. For a given rule set, we replay labelled malicious and benign traces and compute the detection rate (true positive rate) and false positive rate: DR =
TP , TP + FN
FPR =
FP . FP + TN
(6)
To obtain a single scalar score we combine these quantities as SE = α DR + (1 − α)(1 − FPR),
(7)
where α ∈ [0, 1] controls the trade-off between detection and false positives (we set α = 0.5 in our experiments). When available, we additionally monitor the normalised CPU utilisation CPU of the NIDS engine and report it separately. 5) Composite Score (CS): Finally, we report a composite score that aggregates the previous dimensions into a single metric: CS = wSA SA + wSS SS + wMC MC + wSE SE,
(8)
with wSA +wSS +wMC +wSE = 1. In our default configuration we use wSA = 0.2, wSS = 0.3, wMC = 0.2 and wSE = 0.3, giving slightly higher weight to semantic fidelity and security effectiveness. The composite score is used to compare different model variants and training strategies.
C. Cross-Model Evaluation on GenTI To evaluate the effectiveness of GenTI relative to baseline LLMs, Table III reports cross-model performance on the GenTI test set in terms of SA, SS, CC, SE and CS. The zeroshot GPT-3.5-Turbo baseline serves as a strong yet generic reference point, obtaining SA ≈= 0.72, SS ≈= 0.68 and CC ≈= 0.75, with a CS ≈= 0.71. Applying few-shot prompting to LLaMA-3-8B and Mistral-7B produces consistent gains across all metrics, reaching composite score CC ≈= 69.5%, CS ≈= 73.0. This indicates that general-purpose LLMs can benefit significantly from limited task-specific context when generating intrusion detection rules. The proposed GenTI model, trained with QLoRA, curriculum learning, and CoT/CoV-based augmentation, outperforms all baselines on every metric. It achieves this despite having the same parameter budget as other open-source models and far fewer parameters than GPT-4-Turbo. GenTI attains SA = 89.5%, SS = 87.2%, CC = 94.8% and SE 89.4, resulting in the highest composite score of 89.4%. These results show that CTI-enriched supervision and the proposed training strategy improve not only syntactic correctness but also semantic alignment with expert labels. They also lead to rules that better cover the underlying MITRE ATT&CK techniques.
11
Fig. 7. Unseen Attacks Detection Performance Analysis
TABLE III OVERALL PERFORMANCE OF G EN TI COMPARED WITH BASELINE LLM S Model
SA
SS
CC
SE
CS
Params
Mistral-7B
70.5%
67.9%
73.3%
66.3%
69.5%
7B
GPT-3.5 Turbo
72.1%
68.6%
75.4%
70.3%
71.5%
175B
Phi-3-Medium
71.4%
68.7%
74.1%
67.2%
70.1%
14B
LLaMA-3-8B
72.8%
69.9%
75.9%
68.5%
71.6%
8B
Mixtral-8x7B
73.5%
70.6%
76.8%
69.2%
72.3%
45B
LLaMA-3.1-8B
74.1%
71.4%
77.1%
70.5%
73.0%
8B
DeepSeek-7B
74.6%
72.5%
77.3%
70.7%
73.5%
7B
Qwen2-7B
75.4%
72.6%
78.5%
71.3%
74.4%
7B
Gemini-1.0-Pro
75.9%
73.4%
79.0%
72.1%
74.9%
Unknown
Claude-3-Opus
77.1%
74.5%
80.2%
73.2%
76.1%
175B
GPT-4
78.3%
75.8%
80.9%
74.4%
77.3%
1.76T
Qwen2.5-7B
78.7%
76.2%
81.4%
74.8%
78.0%
7B
Gemini-1.5-Pro
79.1%
76.9%
82.1%
75.4%
78.4%
Unknown
GPT-4-Turbo
79.9%
77.3%
82.9%
75.9%
79.0%
Unknown
Claude-3.5-Sonnet
80.5%
78.1%
83.7%
76.8%
79.8%
175B
GPT-4o
81.2%
78.9%
84.1%
77.3%
80.4%
Unknown
GenTI
89.5%
87.2%
94.8%
85.9%
89.4%
7B
particularly effective in teaching the model to recognise attack patterns that were not explicitly present in the training rules. Fig. 7 (b) reports the False-Positive (FP) rate over the same stages. While unseen attacks detection increases substantially, the FP rate decreases from around 8.5% at baseline to approximately 2.3% in the final model. This monotonic reduction suggests that the additional reasoning and verification signals help the model refine decision boundaries rather than simply making its rules more aggressive. The unseen attacks improvement is further shown in Fig. 9, where the relative gain increases from 0% at baseline to more than 42% for the final configuration. This highlights the combined contribution of CoT, CoV, QLoRA, and the curriculum schedule. Finally, Fig. 10 compares the final detection rates for known and unseen attacks side by side. Although unseen attacks performance remains slightly below that for known attacks (88.4% versus 94.2%), the gap is substantially narrower than at baseline and is achieved with a significantly lower FP rate. Overall, these results show that GenTI CTI-aware prompting, CoT/CoV feedback loop, and difficulty-aware curriculum collectively improve the model’s robustness to Unknown attacks. At the same time, they also enhance the model’s precision on benign traffic.
D. Unseen Attacks Detection Analysis To assess how GenTI generalises beyond seen threats, we measure its ability to detect previously unseen attacks on a held-out PCAP set 7 . Fig. 7 summarises the evolution of detection performance across the training stages (Baseline, +CoT, +CoV, +QLoRA, +Curriculum +GenTI). In Fig. 7 (a), the detection rate for known attacks increases moderately from about 92% at baseline to 98.2% for GenTI. This shows that the additional training components do not compromise performance on in-distribution traffic. In contrast, unseen attacks detection improves much more sharply, from roughly 45% at baseline to 87.4% in the GenTI, corresponding to a gain of about 42 percentage points. This gap illustrates that CoT/CoV augmentations and curriculum training are 7 https://www.malware-traffic-analysis.net/
E. Ablation Study of Training Components To evaluate the contribution of each training component in the GenTI pipeline, we conduct an ablation study whose results are summarised in Fig 8. These graphs present five evaluation metrics (SA, SS, CC, SE, and CS) across five configurations: the baseline,+QLoRA, +Curriculum, Base+QLoRA+Curriculum+CoT/CoV, and the final GenTI system. The Base LLM configuration, which relies solely on prompting without any task-specific tuning, achieves moderate scores (e.g., SA ≈ 0.65, SS ≈ 0.60, CC ≈ 0.70). Introducing parameter-efficient fine-tuning with QLoRA yields the largest single improvement, with all five metrics increasing by roughly 8–13 percentage points. This shows that alignment with the CTI-enriched GenTI corpus is essential for high-quality rule
12
Fig. 8. Ablation study of detection rule generation steps across evaluation metrics
Fig. 9. Improvement in Unseen Attacks Threat Detection
Fig. 11. Final Performance Analysis
range for production deployment. GenTI closely approaches this target on all axes, reaching high values for SA and SS (around 0.88), while maintaining strong CC above 0.9 and SE in the mid-0.8 range. The CS, which jointly accounts for these dimensions, also remains close to the target, indicating that gains in one metric are not obtained at the expense of others. VII. C ONCLUSION Fig. 10. Detection Rate Comparison for known and Unseen Attacks
generation. Adding difficulty-aware curriculum learning further boosts performance, particularly in SS and SE, as the model is gradually exposed to more complex, CTI-rich rules. Finally, injecting CoT and CoVe signals produces a consistent, though more incremental, gain across all metrics, mainly by refining rule coverage and reducing residual errors. The resulting full configuration, GenTI attains the highest scores on every metric. This demonstrates that QLoRA provides the main benefit, while curriculum learning and CoT/CoV work together to stabilise and refine the model’s behaviour. Fig. 11 provides an aggregated view of GenTI final performance across all evaluation dimensions. The radar plot contrasts the achieved scores (solid polygon) with a target envelope (dashed polygon) that represents our desired operating
In this paper, we presented GenTI, a CTI-aware LLM framework that turns analyst prompts and attack payloads into verified IDPS and YARA rules. Most existing work reproduces traditional Snort/Suricata signatures and reports improvements in rule syntax or generic similarity. In contrast, GenTI is designed to extend rulebases with new, threatintelligence–grounded rules, especially for unseen attacks. To support this, we curated the GenTI corpus (150k IDPS and 50k YARA rules), defined multi-view evaluation metrics ( SA, SS, CC, SE, CS), and coupled LLM-based rule generation with CTI mapping, iterative refinement and a CoVe loop. Additionally, our experiments indicated that GENTI consistently outperforms strong baselines such as GPT-4o, LLaMA3-7B, and Mistral-7B across all evaluation dimensions. It also achieved substantial improvements in unseen attacks detection while reducing false positives to operationally acceptable levels.
13
Our experiments show that GenTI consistently outperforms strong baselines such as GPT-4o, LLaMA-3-7B, DeepSeek-7B and Mistral-7B on all evaluation dimensions, while achieving substantial gains in unseen attacks detection and reducing false positives to operationally acceptable levels. The ablation study confirmed that QLoRA fine-tuning, curriculum training and CoT/CoV-based augmentation are all necessary to reach this robustness. Overall, GENTI demonstrated that LLMs can move beyond simply copying existing signatures and instead act as CTI-aware agents for expanding and maintaining IDS rulebases against evolving real-world threats. DATA AVAILABILITY The dataset and code used in this study are available at https://figshare.com/s/f34cd4706de24eecf0d6 R EFERENCES [1] F. Wei, H. Li, Z. Zhao, and H. Hu, “{xNIDS}: Explaining deep learning-based network intrusion detection systems for active intrusion responses,” in 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 4337–4354. [2] H. J. Ofte and S. Katsikas, “Understanding situation awareness in socs, a systematic literature review,” Computers & Security, vol. 126, p. 103069, 2023. [3] A. M. Winkler and P. Sharma, “Proactive threat detection in enterprise systems using wazuh: A mitre att&ck evaluation,” Computers & Security, p. 104702, 2025. [4] K. He, D. D. Kim, and M. R. Asghar, “Adversarial machine learning for network intrusion detection systems: A comprehensive survey,” IEEE Communications Surveys & Tutorials, vol. 25, no. 1, pp. 538–566, 2023. [5] Q. A. Al-Haija, S. Altamimi, and M. AlWadi, “Analysis of extreme learning machines (elms) for intelligent intrusion detection systems: a survey,” Expert Systems with Applications, vol. 253, p. 124317, 2024. [6] A. Aldweesh, A. Derhab, and A. Z. Emam, “Deep learning approaches for anomaly-based intrusion detection systems: A survey, taxonomy, and open issues,” Knowledge-Based Systems, vol. 189, p. 105124, 2020. [7] M. Al-Zewairi, S. Almajali, M. Ayyash, M. Rahouti, F. Martinez, and N. Quadar, “Multi-stage enhanced zero trust intrusion detection system for unknown attack detection in internet of things and traditional networks,” ACM Transactions on Privacy and Security, 2025. [8] I. Sharafaldin, A. H. Lashkari, and A. A. Ghorbani, “Toward generating a new intrusion detection dataset and intrusion traffic characterization.” ICISSp, vol. 1, pp. 108–116, 2018. [9] UCI KDD Archive, “Kdd cup 1999 data,” https://kdd.ics.uci.edu/ databases/kddcup99/kddcup99.html, 1999, accessed: 2026-01-13. [10] Canadian Institute for Cybersecurity, “Nsl-kdd dataset,” https://www. unb.ca/cic/datasets/nsl.html, 2009, accessed: 2026-01-13. [11] DEF CON Communications, Inc., “Def con hacking conference: Capture the flag archive,” https://defcon.org/html/links/dc-ctf.html, 2024, accessed: 2026-01-13. [12] S. Samarakoon, Y. Siriwardhana, P. Porambage, M. Liyanage, S.-Y. Chang, J. Kim, J. Kim, and M. Ylianttila, “5g-nidd: A comprehensive network intrusion detection dataset generated over 5g wireless network,” arXiv preprint arXiv:2212.01298, 2022. [13] I. Ullah and Q. H. Mahmoud, “A scheme for generating a dataset for anomalous activity detection in iot networks,” in Canadian conference on artificial intelligence. Springer, 2020, pp. 508–520. [14] ——, “Design and development of a deep learning-based model for anomaly detection in iot networks,” IEEE Access, vol. 9, pp. 103 906– 103 926, 2021. [15] H. Hindy, E. Bayne, M. Bures, R. Atkinson, C. Tachtatzis, and X. Bellekens, “Machine learning based iot intrusion detection system: An mqtt case study (mqtt-iot-ids2020 dataset),” in International networking conference. Springer, 2020, pp. 73–84. [16] H. J. Hadi, Y. Cao, M. K. Khan, N. Ahmad, Y. Hu, and C. Fu, “Uavnidd: A dynamic dataset for cybersecurity and intrusion detection in uav networks,” IEEE Transactions on Network Science and Engineering, 2025.
[17] R. P. Lippmann, “Evaluating intrusion detection systems: The 1998 darpa off-line intrusion detection evaluation,” in Proceedings DARPA Information Survivability Conference and Exposition. DISCEX’00, vol. 2. IEEE, 2000, pp. 12–26. [18] CAIDA, “The caida DDoS attack 2007 dataset,” https://www.caida.org/ catalog/datasets/ddos-20070804 dataset/, Jun. 2020, accessed: 2026-0113. [19] N. Moustafa and J. Slay, “Unsw-nb15: a comprehensive data set for network intrusion detection systems (unsw-nb15 network data set),” in 2015 military communications and information systems conference (MilCIS). IEEE, 2015, pp. 1–6. [20] C. Kreibich and J. Crowcroft, “Honeycomb: creating intrusion detection signatures using honeypots,” ACM SIGCOMM computer communication review, vol. 34, no. 1, pp. 51–56, 2004. [21] R. Zhang, M. Tong, L. Chen, J. Xue, W. Liu, and F. Xie, “Cmirgen: Automatic signature generation algorithm for malicious network traffic,” in 2020 IEEE 19th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom). IEEE, 2020, pp. 736–743. [22] C.-N. Kao, Y.-C. Chang, N.-F. Huang, I.-J. Liao, R.-T. Liu, H.-W. Hung, and C.-W. Lin, “Automatic nids rule generating system for detecting http-like malware communication,” in 2015 International Conference on Intelligent Information Hiding and Multimedia Signal Processing (IIHMSP). IEEE, 2015, pp. 199–202. [23] L. Du, J. Li, H. Yan, Y. Chai, B. Fang, and Z. Gu, “Harnessing large language models for automated intrusion detection rule generation in cyber range,” IEEE Network, 2025. [24] P. Balasubramanian, T. Ali, M. Salmani, D. KhoshKholgh, and P. Kostakos, “Hex2sign: Automatic ids signature generation from hexadecimal data using llms,” in 2024 IEEE International Conference on Big Data (BigData). IEEE, 2024, pp. 4524–4532. [25] X. Hu, H. Chen, H. Bao, W. Wang, F. Liu, G. Zhou, and P. Yin, “A llm-based agent for the automatic generation and generalization of ids rules,” in 2024 IEEE 23rd International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom). IEEE, 2024, pp. 1875–1880.