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 a...

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...

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.