A Structured Workflow for Transforming Cyber Threat Intelligence into Computable Detection Patterns

Summary

Here, we present a protocol to convert indicators of compromise from cyber threat intelligence reports file paths, registry keys, and command-line indicators into validated regular expressions for security information and event management (SIEM) detection rules, using ensemble extraction with large language models (LLMs) and graph-assisted component labeling.

Abstract

Security Operations Centers (SOCs) routinely convert cyber threat intelligence (CTI) reports into operational detection content. A persistent bottleneck in this workflow is the translation of extracted indicators of compromise (IOCs) particularly file paths, registry keys, and command-line strings into deployable regular expressions (regexes) suitable for embedding in security information and event management (SIEM) correlation rules. Although prior work has improved automated indicator-of-compromise (IOC) extraction, transforming extracted strings into validated regex patterns remains largely manual, requires specialized expertise, and is prone to error. The goal of this protocol is to provide a standardized, reproducible procedure for IOC-to-regex translation. The workflow comprises five stages: (1) parsing heterogeneous CTI reports into a unified Markdown representation; (2) IOC extraction using multiple large language models (LLMs) with consensus voting; (3) rule-based normalization, categorization, and deduplication of extracted IOCs; (4) graph-assisted labeling of IOC components as keep (capture-group) or discard (non-capture-group); and (5) iterative regex generation with diagnostic validation against the original IOC strings. To assess utility, the workflow was applied to 3,156 CTI reports, and the resulting regexes were evaluated against more than 2,400 independently collected ground-truth strings from ten MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) Evaluation scenarios, yielding an average hit rate of 99.1 % and an average cross-IOC mismatch rate of 0.8 %. The protocol therefore documents a reproducible implementation for IOC-to-regex translation and explicitly delineates its current scope, operational assumptions, and known failure cases.

Introduction

Cybercrime continues to impose substantial operational and financial burdens on organizations across public and private sectors. In 2023, reported losses due to cybercrime in the United States exceeded $12.5 billion¹, highlighting the scale and persistence of malicious activity. Within this landscape, Security Operations Centers (SOCs) serve as the primary operational units responsible for detecting, analyzing, and responding to threats in real time.
Detection logic in many SOC workflows is implemented through rule-based mechanisms within Security Information and Event Management (SIEM) platforms, which are widely used because they are interpretable, deterministic, and compatible with existing SOC workflows. Among the different rule types, correlation-based SIEM rules are especially important for identifying attack behaviors that span multiple events, hosts, and time windows. Within these rules, regular expressions (regexes) function as a reusable search primitive: analysts embed them within broader detection rules that add field constraints, platform-specific filters, and event-correlation logic, rather than deploying them as self-contained detectors.

In practice, SOC analysts often begin rule development with indicators of compromise (IOCs) derived from cyber threat intelligence (CTI) reports published by security vendors, independent researchers, or public knowledge bases such as MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK)². These IOC strings may include file paths, command-line fragments, registry keys, or other structured artifacts observed during attacks³. Translating such strings into regex patterns suitable for SIEM correlation rules is a recurring task in the rule-authoring workflow.

This translation step is a practical operational bottleneck. Authoring regex patterns that are general enough to capture meaningful variation but precise enough to avoid unintended matches require specialized expertise; small syntactic errors or incorrect decisions about which components to preserve or generalize can render an otherwise useful detection rule ineffective. Because this work is manual, repetitive, and detail-oriented, it may delay detection deployment for emerging threats, require review by more experienced analysts, and contribute to analyst workload in operational SOC settings^4,5.

The central challenge in IOC-to-regex translation is deciding which parts of an IOC encode stable, attacker-relevant behavior and should therefore be preserved, and which parts reflect environment- or host-specific variation and should be generalized. For example, canonical registry roots such as HKEY_CLASSES_ROOT\CLSID, system directories such as System32, and known executable names such as rundll32.exe typically need to remain explicit, whereas user profile paths, host-specific Security Identifiers (SIDs), and Globally Unique Identifiers (GUIDs) should ordinarily be abstracted. Doing this consistently across heterogeneous IOC types is what makes the translation task non-trivial. Throughout this protocol, we refer to the former as preserved or capture-group components, and the latter as abstract or non-capture-group components.

Prior work has explored automated extraction of threat intelligence from unstructured text using natural language processing and entity-extraction techniques^6,7. More recently, several studies have investigated direct generation of detection rules from CTI reports using large language models (LLMs)⁸. These approaches demonstrate that parts of the rule-authoring workflow can be assisted by language models, but they do not typically focus on the specific operational problem of generating regex patterns that preserve capture-group semantics and remain suitable for downstream SIEM deployment. Complementary lines of work have structured CTI content for downstream use in different ways, including knowledge-graph-based representations such as TINKER⁹ and CTI-driven generation of log-hunting queries such as ThreatRaptor¹⁰, which convert unstructured CTI into structured knowledge or domain-specific query languages rather than into regex patterns intended for embedding in SIEM correlation rules.

In parallel, prior studies have explored automated regex synthesis using example-based methods, neural translation, and generate-and-repair approaches^{11,12,13,14,15,16}. However, those methods are generally designed for settings that rely on large sets of representative examples or natural-language descriptions rather than IOC-driven detection contexts. In SOC workflows, IOC strings are often sparse, structurally heterogeneous, and closely tied to operational semantics. This mismatch motivates a workflow tailored to IOC-to-regex translation rather than a claim that existing regex-generation methods are broadly inadequate.

The protocol presented here focuses specifically on the IOC-to-regex translation stage of the SOC detection workflow. IOC extraction is treated as an upstream input that may originate from manual analysis, automated tools, or a combination of both; the protocol does not attempt to generate complete SIEM rules. Instead, it provides a systematic procedure for converting IOC strings into regex patterns that are syntactically valid, semantically interpretable, and suitable for operational deployment. The current IOC scope is deliberate: file paths, registry keys, and command-line indicators contain both stable and variable structural components that benefit from regex generalization, whereas atomic indicators such as IP addresses, domains, and hashes are more naturally operationalized through exact-match conditions or reputation-style lookups and therefore fall outside the primary scope. Within these boundaries, the protocol is intended to be portable across SOC environments that share comparable input formats and tooling preconditions.

Protocol

Use the following five-stage workflow to transform a CTI report into validated regex patterns with traceable intermediate outputs (see Figure 1 for an overview).

1. System setup

1. Install prerequisites.
   1. Install Python 3.8 or later, all Python dependencies listed in requirements.txt, and a Neo4j graph database.
      1. Confirm access to one or more application programming interfaces (APIs) for the chosen large language models and verify that the Neo4j service is running and reachable from the local machine.
   2. Confirm that the Materials Table is complete.
      1. Verify that runtime dependencies are listed, including the Python interpreter version, the pipeline dependencies, the Neo4j version, and the Portable Document Format (PDF) text-extraction backend.
      2. Verify that LLM configuration options are listed, including the LLM providers, model names and versions, temperature, reasoning-effort options, and ensemble-voting settings.
      3. Verify that input and output formats are listed, including the supported input file formats and the supported export formats.
2. Launch the web user interface (UI).
   1. Open a terminal, navigate to the reference-implementation root directory, and start the application using the documented launch command (in the reference implementation: cd langchain_pipeline followed by streamlit run app_v2.py).
   2. Verify that the application loads at http://localhost:8501 and that the sidebar configuration panel is visible.
3. Configure the LLM provider.
   1. In the sidebar’s LLM Configuration section, select an LLM provider, enter the model name, and provide a valid application programming interface (API) key.
   2. Record the provider, model name, model version, temperature, reasoning-effort options, and the date of access for the Materials Table.
      ​NOTE. In the reference implementation, single-LLM IOC extraction defaults to the primary commercial LLM listed in the Materials Table with temperature = 0.0; regex generation defaults to temperature = 0.3.
4. Enable ensemble voting (optional but recommended for reproducible results).
   1. Enable the Ensemble Voting option in the sidebar to retain only IOCs that meet a minimum vote threshold (Min Votes ≥ 2 recommended).
   2. Add additional LLM instances by specifying provider, model name, API key, and number of execution repetitions per model.
      1. Record each provider’s repetition count and the selected minimum-vote threshold.
         NOTE. Ensemble voting is optional. When disabled, the pipeline performs single-LLM extraction and the consensus filter is skipped. Default ensemble settings are repeats = 1 per configured model and min_votes = 2.
5. Connect to Neo4j.
   1. In the Neo4j Connection section of the sidebar, enter the connection URI (for example, bolt://localhost:7687), the username, and the password.
   2. Confirm that the interface reports a successful connection. Do not proceed without an active connection.
6. Secure all credentials.
   1. Treat LLM API keys and the Neo4j password as sensitive credentials. Store them in environment variables or a secrets manager rather than in source files, exported reports, or screenshots, and rotate any key promptly if a leak is suspected.
      NOTE. This software protocol does not require a chemical fume hood, biosafety cabinet, or other physical containment equipment; handle confidential CTI reports and credentials according to institutional data-security policies.

2. Stage 1: document parsing

1. Procedure.
   1. Navigate to the Processing tab in the main interface.
   2. Upload a CTI report in a supported format (.pdf, .docx, .md, .txt, or .html).
   3. Click "Run Next Stage" to execute Stage 1, or "Run All Stages" to execute the full pipeline in sequence.
2. Confirm the Stage 1 checkpoint.
   1. Confirm that a Markdown preview of the input document is displayed.
   2. Verify that file paths, registry keys, command-line fragments, and section boundaries remain intact in the preview.
   3. If technical strings are truncated or formatting is dropped, correct the source file or pre-process the document with an external converter before re-uploading.

3. Stage 2: IOC extraction

1. Procedure.
   1. Confirm the LLM configuration (and ensemble voting, if enabled).
   2. Click "Run Next Stage" to execute Stage 2.
2. Confirm the Stage 2 checkpoint.
   1. Confirm that the interface displays an IOC collection in JavaScript Object Notation (JSON) format with three top-level keys: File Paths, Command Lines, and Registry Keys.
   2. When ensemble voting is enabled, verify that vote counts and contributing-model metadata are recorded for each retained IOC.
      NOTE. The verbatim Stage 2 system and human prompts, together with the Stage 5 generation and optimization prompts, are released as Supplementary File 1 (Supplemental_File_1_Prompts.txt).

4. Stage 3: IOC analysis and classification

1. Procedure.
   1. Click "Run Next Stage" to execute Stage 3.
2. Confirm the Stage 3 checkpoint.
   1. Confirm that each retained IOC is listed with a standardized category, a source tag, and the original extraction key when available.

5. Stage 4: Neo4j-assisted IOC normalization

1. Procedure.
   1. Confirm that the Neo4j connection is active.
   2. Click "Run Next Stage" to execute Stage 4.
   3. Inspect the per-IOC normalization output and verify that keep/discard labels are produced for path and command-line components and that registry keys yield a contiguous canonical substring.
2. Confirm the Stage 4 checkpoint.
   1. Confirm that normalized IOC tables are produced for each IOC type (file paths, registry keys, command-line indicators).
   2. Verify that each entry includes the original value, the normalized value, and a component list of element/status pairs labeled keep or discard.
      NOTE. Detailed Neo4j schema, Cypher queries, decision rules, and the registry-key normalization procedure are listed in Supplementary File 2; a worked example is provided in Representative Results.

6. Stage 5: regex generation and scoring

1. Procedure.
   1. Click "Run Next Stage" to execute Stage 5. Confirm that each normalized IOC and its forbidden-token list are submitted for regex generation and deterministic validation.
   2. If a candidate fails validation, allow the optimization loop to refine the regex until a compliant candidate is produced or the iteration cap is reached.
   3. Inspect the diagnostic output, optimization history, and iteration counts for any IOC whose final regex falls back from compliant to highest-scoring partial match (recorded as used_fallback = True).
2. Confirm the Stage 5 checkpoint.
   1. Confirm that a final regex is produced for each retained IOC.
   2. Verify that candidate scores, optimization histories, issue lists, and iteration counts are recorded.
   3. Verify that per-IOC telemetry, including estimated token usage and latency, is logged.
      NOTE. Detailed regex validation rules, the scoring formula, and iteration-control parameters are listed in Supplementary File 2.

7. Analytics and validation

1. Open the Analytics tab to review IOC distributions, ensemble-voting outcomes (when enabled), regex-quality summaries, and optimization statistics. Use these summaries to detect anomalies such as extraction imbalance or repeated optimization failures.

8. Export results

1. In the Export tab, select the export format (plain text, JSON, or YAML) and download the regex set. Confirm that the exported regexes include the associated scores and categorization metadata.
2. Generate and download the full JSON report containing parsed documents, extracted IOCs, normalized representations, candidate regexes, and final outputs. Preserve this report as a reproducibility record.

9. Troubleshooting

1. If Stage 1 returns truncated or empty PDF content, pre-process the document with an external converter or optical character recognition tool before re-uploading, and confirm that technical artifacts remain visible in the Markdown preview.
2. If Stage 2 returns too few consensus IOCs, verify the provider, model, API-key, repeat-count, and min votes settings before changing the threshold. Inspect excluded candidates to distinguish hallucinations from overly strict voting.
3. If Stage 4 labels all components as discard, verify Neo4j connectivity and confirm that the graph contains the relevant Path, Registry, or command-line interface (CLI) vocabulary for the IOC type being analyzed.
4. If Stage 5 produces a regex that compiles but fails matching or over-generalizes, inspect the optimization history, diagnostic failure position, and over-generalization checks before regenerating the candidate.

10. Confirm final protocol outputs.

1. Confirm that the parsed Markdown file, the IOC set (consensus-validated when ensemble voting is enabled, or single-model when disabled), the categorized IOC table, and the graph-normalized IOC representations are all present.
2. Confirm that the SIEM-compatible regex set, the analytics summaries, and the full JSON report are all present, and archive the JSON report as the reproducibility record.

Results

This section presents representative outcomes produced by the IOC-to-regex protocol and summarizes the reference evaluation used to assess its operational applicability. The reference evaluation processed 3,156 CTI reports associated with MITRE ATT&CK techniques, analyzed more than 230,000 sentences, extracted more than 63,000 IOC candidates, and evaluated generated regexes against more than 2,400 independently collected ground-truth strings from ten MITRE ATT&CK Evaluation scenarios. These ground-truth strings are expert-curated attack artifacts reported independently by cybersecurity vendors during the MITRE ATT&CK Evaluation exercises and therefore reflect the structural patterns that human analysts and vendors document in practice. The results below focus on workflow behavior, structural correctness, and evaluation outcomes relevant to operational log analysis and detection workflows.

An overview of the end-to-end pipeline is provided in Figure 1, which summarizes the capture-group finding and regex generation stages that frame the remainder of the representative results.

Stage 1: Document Parsing Output

Figure 2 shows the output of Stage 1, where an input CTI report is parsed into a unified Markdown representation. Upon successful execution, the interface displays a structured preview of the document, including section boundaries and relevance indicators.

Correct execution is indicated by coherent paragraph segmentation and preservation of technical artifacts such as file paths, registry keys, and command-line fragments. Excessive truncation or loss of formatting at this stage may affect downstream analysis and should be addressed before proceeding.

Stage 2: Consensus-Based IOC Extraction

Figure 3 illustrates the output of Stage 2, where candidate IOCs are extracted using multi-LLM ensemble voting. The resulting interface presents a JSON-formatted IOC collection annotated with vote counts and contributing models.

Only IOCs that meet the configured minimum consensus threshold are retained. IOCs excluded at this stage typically reflect model-specific hallucinations or ambiguous text fragments. Their exclusion is an expected and desirable outcome, indicating that ensemble voting is functioning correctly.

Stage 3: IOC Analysis and Classification

Table 2 summarizes the expected output, automated validation steps, and analyst-facing quality-control checks for each protocol stage.

Figure 4 displays the IOC candidates that did not meet the consensus threshold during ensemble voting at Stage 2 and that the interface surfaces for analyst inspection. Such candidates typically reflect model-specific hallucinations or ambiguous text fragments. Figure 4 and Figure 5 therefore correspond to distinct stage outputs — the discarded set from Stage 2 and the retained set from Stage 3 — rather than to alternative views of the same Stage 3 process.

Figure 5 presents the retained IOC table produced by Stage 3 after JSON parsing, rule-based categorization, and IOC deduplication. For each retained IOC, the stage records a standardized category, source tag, and the original extraction key when available, before passing the IOC to downstream normalization.

Stage 4: Graph-Assisted IOC Normalization Across IOC Types

Figures 6, Figure 7 and Figure 8 illustrate representative normalization results for three IOC categories addressed in the current study: file paths, registry keys, and command-line indicators. For each category, the figures compare the original IOC extracted from the CTI report with the normalized representation produced using graph-assisted analysis.

Across all IOC types, the protocol decomposes each IOC into semantic components and resolves hierarchical relationships using structured knowledge encoded in the graph database. In the current implementation, Neo4j stores normalized Path, Registry, and CLI nodes and uses adjacency relationships to test whether components belong to recognized chains. This role is analogous to the use of structured ATT&CK knowledge during detection engineering².

Importantly, this normalization step records explicit semantic roles for IOC components by labeling them as keep or discard rather than silently removing them from the analysis record. The normalized string is reconstructed primarily from keep components, while discard components remain available as metadata for downstream regex generation and validation.

Correct execution of this stage is indicated by normalized IOCs that retain meaningful structural context and exhibit consistent capture-group labeling across different IOC types. Visual comparison between original and normalized representations provides a practical quality-control mechanism to verify that capture-group resolution has been applied consistently and without unintended information loss.

Stage 5: Regular Expression Generation with Auxiliary Constraint-Based Selection

Figure 9 illustrates the output of Stage 5, where the protocol generates structurally compliant regular expressions from normalized IOCs through an iterative validation workflow. The implementation combines an initial generation prompt, diagnostic re-prompting when a candidate fails to match the IOC, discard-aware validation, and capped retry loops.

Given a normalized IOC and its associated keep/discard component specification, the workflow first generates an initial regex candidate. The candidate is then tested against the IOC, diagnostically re-prompted when matching fails, checked for forbidden discarded tokens, and evaluated for over-generalization using random negative strings.

When multiple candidates satisfy the basic validation checks, the protocol applies an auxiliary constraint-based selection mechanism to retain a representative regex for downstream use. The current implementation scores candidates with `Score = n_cg - n_wc`, where `n_cg` is the number of represented keep components and `n_wc` is the number of discarded or unmapped tokens present in the regex.

The selection function is defined as:

Score = n_cg − n_wc

This is the equal-weight specialization (α = β = 1) of the more general form Score = α·n_cg − β·n_wc. Here, n_cg denotes the number of represented keep components and n_wc denotes the number of discard components or unmapped extra tokens reintroduced by the regex. The implementation also records iteration counts, issue lists, estimated token consumption, cache usage, and latency telemetry for each IOC. The equal-weight setting was used as a simple deterministic default for the reference implementation; because it treats a missing keep component and a reintroduced discard component as equally undesirable, other weightings may be preferred in deployment contexts where false negatives and false positives carry different operational costs.

The final regex is selected as the candidate that best satisfies these constraints. Regexes that place required capture-group components inside optional constructs, for example ( ... )?, are excluded from selection because they weaken semantic consistency. This selection step is auxiliary to the generation process and is not intended to serve as a standalone quality metric.

Analytics Overview of CTI Processing

Figure 10 provides an overview of the CTI analysis outcomes across all processed documents. In the reference evaluation, IOC extraction over 3,156 CTI reports produced more than 63,000 IOC candidates, including 12,195 file paths, 2,302 registry keys, and 10,286 command-line indicators, with the remaining candidates belonging to non-regex-target IOC types.

These counts provide a high-level validation that the extracted indicators are concentrated in the three IOC categories targeted by the current protocol while also showing that many extracted artifacts remain outside the regex-generation scope. When reproducing the workflow, report the exact number of CTI reports processed, total IOC candidates, category-wise counts, and the provider, model, model version, temperature, repeat count, and consensus threshold used during extraction.

In the reference evaluation, generated regexes were assessed against more than 2,400 independently collected ground-truth strings from ten MITRE ATT&CK Evaluation scenarios and achieved an average hit rate of 99.1 % together with an average cross-IOC mismatch rate of 0.8 %. In this manuscript, mismatch rate is used as a semantic-specificity measure: a mismatch occurs when a regex generated for one IOC also matches a ground-truth string associated with a different IOC. This quantity should not be interpreted as an end-to-end operational alert false-positive rate, which also depends on downstream rule logic and deployment context.

The distribution reflects the structural composition of the CTI corpus and allows users to verify that the extracted indicators align with expected IOC types. Large deviations from expected proportions may indicate upstream parsing or extraction issues and should be examined before proceeding to downstream normalization and regex generation.

Analysis of Regex Optimization Actions

Figure 11 summarizes the actions performed during regular expression generation and refinement. The distribution includes three types of actions: initial regex generation, LLM-driven optimization steps, and retry-based regeneration.

LLM-driven optimization accounts for 51.7 % of all actions observed. This prevalence indicates that initial generation alone is frequently insufficient to produce regexes that satisfy capture-group constraints and exclusion requirements. Instead, iterative optimization is actively and repeatedly applied to refine candidate regexes.

Rather than reflecting inefficiency, this distribution demonstrates that the optimization workflow is a necessary and integral component of the protocol when generating structurally compliant regexes from complex IOC inputs.

A separate scalability characterization over a random sample of 6,000 IOCs generated with the scalability-test LLM (see the Materials Table) reported a median latency of 2.95 s per IOC and a mean latency of 23.18 s. In the same characterization, syntax-valid regex compilation reached 99.56 %, overall generation success reached 99.4 %, the mean estimated token usage was approximately 3,986 tokens per IOC, and the workflow required approximately 7.89 LLM calls per IOC on average. First-pass success rates were 56.46 % for the match-debug loop and 72.92 % for the non-capture-group validation loop. These measurements help characterize computational cost and operational throughput for batch use.

No expert review of a sampled output subset was used for model retraining in the current reference characterization; the reported results reflect automated pipeline execution and the downstream evaluation datasets described above.

Operational evidence and failure handling. Figure 12 shows the structure of the exported SIEM regex file produced by the protocol, together with rule-level validation evidence for representative file-path, registry-key, and command-line patterns. Figure 13 shows the corresponding full JSON report, which exposes all stage outputs (extracted, analyzed, and normalized IOCs together with the generated regex patterns and per-IOC validation flags) and is the primary artifact downstream tooling consumes. Figure 14 illustrates the protocol’s handling of a noisy CTI input: a defanged, whitespace-perturbed file path is flagged at the analysis stage, corrected, normalized to the canonical %TEMP% template, and then converted into a compiling, matching regex. This worked example complements the operational evidence in Figure 12 and Figure 13 by documenting how the protocol behaves when the raw IOC text departs from the canonical form.

Figure 1: Overall architecture of the IOC-to-regex protocol. The figure summarizes the end-to-end pipeline. Candidate IOC strings produced by the upstream IOC extractor are decomposed and compared against reference nodes in a Neo4j graph populated from Windows documentation (step 1), which retrieves known path, registry, and command-line components (step 2). Variable or environment-specific fragments are labeled as discard and excluded from the normalized reconstruction while retained in component metadata, yielding a normalized IOC with component-level keep and discard labels (step 3). These normalized IOCs are then passed to an LLM-based regex generation stage (step 4) that produces candidate regular expressions, which are scored and iteratively optimized against capture-group constraints and discarded-token rules (step 5) before a final regex is selected (step 6). Please click here to view a larger version of this figure.

Figure 2: Stage 1 document parsing output. Side-by-side comparison of the original CTI report and the parsed document preview. The left panel shows the original CTI report in PDF format, while the right panel displays the unified Markdown representation generated by the parser. Please click here to view a larger version of this figure.

Figure 3: Consensus-based IOC extraction using multi-LLM ensemble voting. The interface illustrates the ensemble-based IOC extraction process and its intermediate results. The red box highlights the configured LLM instances participating in IOC extraction, including the selected providers and the number of repeated extraction runs performed for each model. The blue box indicates the user-defined consensus threshold, which specifies the minimum number of occurrences required for an IOC to be retained. After aggregating extraction results across all models and repetitions, candidate IOCs that appear fewer times than the threshold are discarded. The orange box shows the final set of retained IOCs that satisfy the consensus criterion and are passed to downstream analysis stages. Please click here to view a larger version of this figure.

Figure 4: IOCs discarded by ensemble voting at Stage 2. Side-by-side view of IOC candidates that did not meet the configured minimum-vote threshold during ensemble voting and are surfaced for analyst inspection. Discarded candidates typically reflect model-specific hallucinations or ambiguous text fragments and are not passed to the Stage 3 categorization step. Please click here to view a larger version of this figure.

Figure 5: Retained IOC set with standardized classification. IOC candidates retained after Stage 3 processing are shown together with their standardized categories, source tags, and original extraction keys when available. This table provides the structured IOC input used by the normalization stage. Please click here to view a larger version of this figure.

Figure 6: File path IOC normalization using graph-assisted analysis. Side-by-side comparison of an original file path IOC and its normalized representation. Graph-based traversal queries known Path components by normalized name and labels each component as keep or discard. Drive identifiers and variable filename fragments can therefore be marked discard in the component record while the normalized form is reconstructed primarily from kept structural segments required for downstream pattern construction. Please click here to view a larger version of this figure.

Figure 7: Registry key IOC normalization using graph-assisted analysis. Normalization of a registry key IOC through graph-assisted resolution of hierarchical registry structures. Abbreviated root keys are expanded to canonical registry hives, and the analyzer extracts the longest contiguous known registry substring while skipping host placeholders, SID-like values, and GUID-like tokens. The output records keep/discard labels for each retained component and produces a canonical registry path for downstream processing. Please click here to view a larger version of this figure.

Figure 8: Command-line IOC normalization using graph-assisted analysis. Comparison of an original command-line IOC and its normalized representation. The protocol tokenizes the command line while preserving quoted strings, normalizes the leading command token through Neo4j lookup when possible, and recursively analyzes embedded path-like or registry-like fragments. Stable command-related components are labeled keep, variable arguments are labeled discard, and the final canonical command structure is reconstructed from the kept elements. Please click here to view a larger version of this figure.

Figure 9: Constraint-based selection of regular expression candidates. Multiple regex candidates are generated for each normalized IOC using an iterative validation workflow. A constraint-driven scoring mechanism is applied to select a final regex that preserves designated capture-group components while limiting undesired variable substrings. Please click here to view a larger version of this figure.

Figure 10: Distribution of extracted IOCs across CTI reports. Summary of IOC extraction results showing the total number of indicators identified from CTI reports and their distribution across file paths, registry keys, and command-line indicators. This view provides a high-level validation of CTI content coverage and extraction behavior. Please click here to view a larger version of this figure.

Figure 11: Distribution of optimization actions during regular expression generation. Breakdown of actions performed during regex generation, including initial generation, LLM-driven optimization, and retry-based regeneration. LLM-driven optimization accounts for 51.7 % of all actions, illustrating that iterative refinement is an essential component of the protocol for producing regexes that satisfy capture-group constraints. Please click here to view a larger version of this figure.

Figure 12: Representative exported regex file. Sample contents of the SIEM regex export (siem_rules.txt) generated by the protocol. Each entry includes the source IOC, the inferred category (file path, registry key, or command line), and the validated regex pattern. The accompanying validation table summarizes the expected behavior and the system evidence used to confirm correctness for each rule type. Please click here to view a larger version of this figure.

Figure 13: Representative full JSON report. End-to-end pipeline output produced after running all five protocol stages on a representative CTI report. The JSON document records the source file, parsed-section count, extracted IOCs grouped by category, stage-3 categorized records with source tags, stage-4 normalization diff, and stage-5 regex patterns with per-IOC validation flags. The report also exposes top-level success and error metadata that allow downstream tooling to detect partial failures. Please click here to view a larger version of this figure.

Figure 14: Failed or noisy input: identification and correction. Worked example of how the protocol identifies and recovers from a noisy IOC. The raw input %T E M P%\malware[.]exe is flagged because its environment-variable token contains inserted spaces and its file extension has been defanged. The correction step removes the inserted whitespace and restores the literal dot; Stage 4 normalization then expands %TEMP% to the canonical Windows Temp directory template; and Stage 5 generates a regex that compiles and matches the corrected normalized IOC. This example illustrates the noisy-input handling discussed in the Discussion. Please click here to view a larger version of this figure.

Element	Type	Value / Schema	Example	Notes
Node label	Label	:Path	Windows, System32, cmd.exe	Stores Windows file-path components
Node label	Label	:Registry	SOFTWARE, Microsoft, Windows NT	Stores registry-key components below root hives
Node label	Label	:CLI	powershell.exe, -ExecutionPolicy, Bypass	Stores command tokens and parameters
Node property	String	name	cmd.exe	Original casing; used for display in normalized output
Node property	String	name_lower	cmd.exe	Lowercase form; used as lookup key for all MATCH queries
Relationship	Directed edge	(a)-[:NEXT]->(b)	(Windows)-[:NEXT]->(System32)	Both endpoints share the same label; encodes native adjacency on Windows systems
Constraint	Uniqueness	n.name_lower UNIQUE per label	-	Applied to :Path, :Registry, :CLI
Data source	Coverage	Windows 8, 10, 11	-	Client OS populated into graph
Data source	Coverage	Windows Server 2012, 2016, 2019, 2022	-	Server OS populated into graph

Table 1: Neo4j graph schema used for IOC normalization (Stage 4). Lists the three node labels (Path, Registry, CLI), their shared property schema (name, name_lower), the directed adjacency relationship used for native-ordering edges, uniqueness constraints, and the Windows client and server versions that populate the graph.

Stage	Expected output	Automated validation	Analyst-facing quality control
Stage 1: Document parsing	Unified Markdown text, chunked at 4,000 characters before LLM processing.	—	Visual check of Markdown preview to confirm that file paths, registry keys, command-line fragments, and section boundaries survive parsing; switch backend if technical strings are truncated.
Stage 2: IOC extraction	JSON with three top-level keys (File Paths, Command Lines, Registry Keys); per-IOC vote counts and contributing-model metadata when ensemble voting is enabled.	Consensus threshold filter (min_votes) excludes IOCs whose vote count is below the configured threshold.	Inspection of excluded candidates to distinguish hallucinations from overly strict voting before adjusting min_votes.
Stage 3: IOC analysis and classification	Categorized IOC list: each IOC paired with a standardized category, source tag, and original extraction key when available.	Standardized-category mapping via regex-based rules and IOC-pattern heuristics; (IOC, category) pair deduplication.	Spot-check of categorized output for ambiguous or noisy candidates (Figure 4A).
Stage 4: Neo4j-assisted normalization	Per-IOC normalized form with component-level keep / discard labels.	Cypher queries (i)-(iii) over the Windows reference graph; deterministic preprocessing fallback when Neo4j is unavailable.	Inspection of all-discard cases to identify graph-coverage gaps; extension of graph data with vendor- or environment-specific references when needed.
Stage 5: Regex generation and scoring	Final regex per IOC with candidate scores, optimization history, iteration counts, and per-IOC telemetry.	Match test, static quality checks, boundary-aware forbidden-token check, over-generalization test against 5 deterministic negative samples; fallback to highest-scoring partial match (used_fallback flag).	Optimization-history review for fallback regexes; per-IOC failure-position diagnostic inspection before regenerating.

Table 2: Stage-output and validation summary. Maps each protocol stage (1–5) to its expected artifact, the automated validation evidence produced by the pipeline (regex compilation status, hit rate, cross-IOC mismatch rate, optimization iteration counts), and the corresponding analyst-facing quality-control check (visual comparison, inspection of discarded candidates, and category review).

Supplementary File 1: Verbatim LLM prompts. The verbatim system and human prompts used for Stage 2 IOC extraction and Stage 5 regex generation and optimization.Please click here to download this file.

Supplementary File 2: Implementation details for Stages 4 and 5. Algorithmic and implementation details supporting the Stage 4 graph-assisted IOC normalization and the Stage 5 regex validation, scoring, and iteration control. Please click here to download this file.

Discussion

Translating unstructured CTI reports into executable detection logic remains a time-consuming and error-prone task in operational security workflows. While prior efforts have explored automation at the level of IOC extraction or high-level rule generation, practitioners still face substantial challenges in converting extracted IOC strings into regexes that are structurally correct, semantically precise, and suitable for downstream SIEM use. The protocol presented here addresses that gap through a staged workflow in which each phase produces a well-defined intermediate artifact and applies explicit validation before passing results to the next stage. Figure 14 documents one such case, in which a defanged, whitespace-perturbed file path is identified, corrected, normalized, and converted into a compiling regex; the protocol’s noisy-input handling and its current scope are discussed jointly with the limitations enumerated below.

A central contribution of this protocol is its explicit decomposition of the workflow into stages with inspectable intermediate outputs. The implementation is now described concretely: document parsing produces Markdown and chunked text for LLM processing; IOC extraction emits structured JSON for file paths, registry keys, and command-line indicators; rule-based IOC analysis standardizes and deduplicates extracted values; Neo4j-assisted normalization labels each IOC component as keep or discard; and regex generation applies match debugging, discard validation, and over-generalization checks before candidate selection.

The protocol treats regular-expression generation as an iterative construction task rather than as a one-shot prediction problem. The implementation uses an initial generation prompt, automated match diagnostics, capped refinement loops, and a component-based scoring function to preserve structurally important IOC elements while penalizing discarded or unmapped substrings. This iterative design, together with deterministic validators applied at each step, supports the production of regex patterns that remain structurally faithful across a large and heterogeneous evaluation set. In the reference evaluation, this workflow was applied to 3,156 CTI reports and evaluated against more than 2,400 independent ground-truth strings, yielding an average hit rate of 99.1 % and an average cross-IOC mismatch rate of 0.8 %. Because these ground-truth strings are expert-curated artifacts reported by cybersecurity vendors during the MITRE ATT&CK Evaluation exercises, this evaluation implicitly compares the protocol’s output against IOC patterns documented by human analysts rather than against automatically generated ones.

As shown in the representative results, iterative optimization is particularly important when the workflow handles complex IOC structures such as nested file paths or long command-line strings. Reference evaluation results also indicate that the most common unmatched cases occur when attackers use custom executables or parameters that are not represented in the graph database or not explicitly documented in the source CTI reports. In operational use, these failure modes should be treated as expected boundary conditions rather than silent errors and should trigger review of graph coverage, source-report completeness, and regex-debug telemetry.

The protocol can be compared to three families of alternative methods. First, example-based regex synthesis methods such as TransRegex¹¹ and Regex+¹² learn regexes from curated sets of positive and negative string examples. These methods perform well when representative example sets are available but are less directly applicable to SOC contexts, where each IOC reported in CTI typically appears as only a single representative string, and the required generalization boundary is driven by operational semantics rather than by example coverage. Second, genetic-programming approaches such as those introduced by Bartoli et al.^13,14 search the space of regexes through evolutionary operators and typically require a labeled corpus of match and non-match strings; they are well suited to batch construction of extraction patterns but do not directly consume unstructured CTI narratives. Third, recent neural and LLM-based approaches^15,16 translate natural-language descriptions directly into regex strings; these methods are powerful for well-specified prompts but, in single-shot use, may produce regexes that are syntactically valid yet miss required capture-group components or over-generalize across unrelated IOC variants. The present protocol complements these directions by (i) taking unstructured CTI reports rather than curated example sets or natural-language queries as input, (ii) decomposing each IOC into keep and discard components via graph-assisted normalization before any regex is generated, and (iii) validating each candidate regex with deterministic match, discard, and over-generalization checks within a capped iterative loop. The goal is not to outperform prior methods on their own benchmarks but to provide a reproducible IOC-to-regex pipeline whose intermediate decisions are inspectable and auditable by SOC analysts.

The protocol makes several assumptions about the quality of the input CTI reports. It assumes that (i) IOC strings appear in a recoverable textual form after document parsing, i.e., file paths, registry keys, and command-line indicators are not embedded exclusively in images, screenshots, or obfuscated encodings; (ii) IOC fragments reported in the CTI are sufficiently complete to preserve their structural anchors (for example, registry keys retain their hive prefix, file paths retain at least one directory anchor recognizable to the Windows-documentation graph, and command lines retain the invoking executable or a known module reference); and (iii) the reported IOCs are not truncated, redacted, or rewritten in ways that remove the capture-group components the protocol depends on. CTI reports that satisfy these assumptions include most MITRE ATT&CK technique descriptions, vendor advisories, incident-response writeups, and well-formatted threat bulletins. Reports that rely primarily on screenshots, highly abbreviated IOC lists lacking surrounding context, or free-text paraphrases without explicit IOC strings fall outside the intended operating envelope and should be expected to produce reduced extraction recall and less faithful normalization; such reports may benefit from upstream image-to-text preprocessing or analyst review before entering the pipeline.

Several limitations should be considered when applying this protocol. First, the current implementation focuses on file paths, registry keys, and command-line indicators rather than broader IOC categories such as domains, email artifacts, user-agent strings, or behavioral sequences. This is a deliberate scope choice, as atomic indicators are generally well served by exact-match workflows and the present protocol targets variable-structure IOCs that benefit from regex generalization; it nevertheless constrains applicability to IOC types not currently represented in the graph. Second, current failure scenarios fall into three main categories: non-native paths or command-line arguments that are absent from the operating-system graph, incomplete graph coverage for relevant utilities or structures, and incompleteness in the CTI source itself when important command fragments or cmdlets are never reported. Third, the cross-IOC mismatch metric used in the reference evaluation measures semantic specificity of generated regexes rather than end-to-end alert false positives under deployed SIEM logic.

Reproducibility under LLM variability and versioning. Because the IOC extraction and regex-generation stages depend on commercial LLM endpoints, two sources of variability affect reproducibility: provider-side model updates over time and per-call sampling stochasticity. To mitigate the first, all LLM-related fields in the Materials Table record exact model identifiers and the access date used in the reference evaluation, and the protocol recommends pinning to a specific model snapshot whenever the provider exposes one. To mitigate the second, the reference implementation fixes the IOC-extraction temperature at 0.0 and uses a non-zero temperature only at the regex-generation stage, where ensemble voting and deterministic validators in Stages 2 and 5 absorb residual variation. When replicating these results, users should record the exact model version, access date, temperature, and ensemble vote threshold used; substantive deviations on any of these axes should be expected to shift hit-rate and mismatch metrics.

Several recoverable failure modes can be addressed at the level of the stage that produced them. Stage 1 parsing failures (for example, scanned PDFs producing empty or garbled Markdown): pre-process the input with optical character recognition or an external converter before re-uploading; verify that the parsed-section count and total character count are non-zero before proceeding. Stage 2 extraction failures (no IOCs returned, or hallucinated entries): increase the ensemble vote threshold (Min Votes ≥ 2), enable additional model instances, or lower the LLM temperature; verify API connectivity and that the configured model accepts JSON-formatted output. Stage 4 normalization with all-discard labels (every IOC component is labeled discard): extend the Neo4j reference graph with vendor- or environment-specific path components and registry roots; the Cypher import scripts and the keep/discard decision rule are listed in Supplementary File 2. Stage 5 regex failures (used_fallback = true, or repeated discard-validation rejections): inspect the per-IOC optimization-history field to identify the failing validator; if the IOC genuinely lacks stable keep-components, consider manual regex authoring for that IOC or excluding it from automated rule generation while retaining it in the categorized IOC table for analyst review.

Consistent with the above limitations, the generated regexes are best treated as reusable search primitives within broader SOC detection content rather than as self-sufficient detectors. In operational settings, analysts can combine them with platform-specific field logic, whitelists, provenance checks, or correlation conditions to suppress benign matches that arise from unusual but non-malicious paths.

Future work may include systematic comparison against human-authored regexes, broader evaluation across additional IOC categories, structured analyst-feedback studies, expanded graph coverage for attacker-created utilities and cmdlets, and fuller reporting of end-to-end latency and cost across deployment settings. Nevertheless, the present protocol provides a reproducible and operationally interpretable framework for IOC-to-regex translation that documents both its strengths and its current limits.

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
Computer (CPU)	—	≥ 4 cores recommended	No GPU required
LangChain	LangChain	≥ 0.1.x	LLM orchestration framework
LLM (IOC extraction, single-model)	OpenAI	gpt-5.1	Used for IOC extraction (Stage 2) when ensemble voting is disabled. temperature = 0.0; max_workers = 5. Accessed: 2025-12-15.
LLM (Regex generation)	OpenAI	gpt-5.1	Used for regex generation (Stage 5). temperature = 0.3 before downstream validation. Accessed: 2025-12-15.
LLM (Scalability characterization)	OpenAI	gpt-5.1	Used for the 6,000-IOC scalability run reported in Representative Results. Accessed: 2025-12-15.
Memory (RAM)	—	≥ 16 GB recommended	Required for document processing
Neo4j	Neo4j, Inc.	≥ 5.x	Graph database for IOC normalization
Neo4j Python Driver	Neo4j, Inc.	≥ 5.x	Python interface to Neo4j
Operating System	Microsoft / Apple / Linux	Windows, macOS, or Linux	Cross-platform support
PDF parsing — primary backend	Microsoft	MarkItDown ≥ 0.0.x	Stage 1 backend; converts PDF/DOCX/HTML/TXT inputs to Markdown. Parsed output chunked at 4,000 characters before LLM processing. Accessed: 2025-12-15. https://github.com/microsoft/markitdown
Pipeline configuration (Stage 2 — IOC extraction)	—	Reference defaults	Single-LLM mode: temperature = 0.0, max_workers = 5. Ensemble-voting mode defaults: repeats = 1 per configured model, min_votes = 2.
Pipeline configuration (Stage 5 — regex generation)	—	Reference defaults	Generation temperature = 0.3. Validation: overgen_random_tests = 5 deterministic negative samples per IOC. Iteration bounds: max_iterations = 10, debug_loop_cap = 5, discard_validation_cap = 5.
Python	Python Software Foundation	≥ 3.8	Required runtime environment
Regex Engine	Python Standard Library	re module	Used for regex validation and testing
Streamlit	Streamlit Inc.	≥ 1.25	Web-based user interface
Reference implementation source code	Authors / GitHub | GitHub repository		Source code for the Streamlit interface, LangChain pipeline, Neo4j-assisted normalization, regex generation, validation utilities, and example configuration files. Available at https://github.com/SOCautomatic/cti-ioc-regex-pipeline. Accessed: June 11, 2026.