💻 computer science

From IOCs to Regex: Automating CTI Operationalization for SOC with LLMs

This paper introduces IOCRegex-gen, an automated LLM-based system that transforms Indicators of Compromise from CTI reports into semantically precise and syntactically valid regular expressions through a group-aware mechanism and iterative validation pipeline, achieving a 99.1% hit rate and significantly reducing manual effort in security operations.

Original authors: Pei-Yu Tseng, Lan Zhang, ZihDwo Yeh, Xiaoyan Sun, Xushu Dai, Peng Liu

Published 2026-04-15

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Pei-Yu Tseng, Lan Zhang, ZihDwo Yeh, Xiaoyan Sun, Xushu Dai, Peng Liu

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Picture: The "Lost in Translation" Problem

Imagine you are a security guard (a SOC Analyst) at a massive skyscraper. Every day, you receive a stack of "Wanted Posters" (Cyber Threat Intelligence Reports) from other security agencies. These posters describe bad guys and give you clues on how to spot them, like: "The thief will try to enter through the back door using a red key labeled '11.bat'."

In the digital world, these clues are called IOCs (Indicators of Compromise).

The Problem:
The "Wanted Posters" are written in plain English. But your security cameras and alarm systems (the Logs) don't speak English; they only speak a strict, robotic code called Regular Expressions (Regex).

To catch the thief, you have to translate the plain English clue ("red key labeled '11.bat'") into a complex code that says: "Look for any file ending in .bat, but ignore the specific number, because the thief might change it to '12.bat' tomorrow."

Currently, human analysts have to do this translation manually. It's slow, boring, and prone to mistakes. If the analyst gets tired, they might write the code wrong, and the thief slips right past the alarm.

The Solution: The "Super-Translator" Robot

The authors of this paper built a new AI system called IOCRegex-gen. Think of it as a Super-Translator Robot that takes the plain English clues and instantly writes the perfect robotic code for the alarm system.

But here's the catch: A standard AI (like a basic chatbot) is bad at this. If you ask a normal AI to write the code, it might get confused, write gibberish, or make the code too vague (like saying "Look for any file," which would trigger the alarm every time someone opens a text document).

The authors' system solves this with two special tricks:

Trick 1: The "Smart Highlighter" (Capture Group Finding)

Imagine the clue is: "The thief uses the file C:\Users\Public\11.bat."
A human expert knows that C:\Users\Public is a standard, unchangeable part of the computer (like the building's address), but 11.bat is the part the thief can change (like the name on the key).

The Old Way: A basic AI might try to match the entire string exactly. If the thief changes the name to 12.bat, the alarm doesn't go off.
The New Way: The system uses a Knowledge Graph (a giant digital encyclopedia of how Windows computers work) to figure out which parts are "fixed" and which parts are "variable."
- It highlights C:\Users\Public as a Capture Group (the part we must see).
- It treats 11.bat as a Non-Capture Group (the part that can change).
- Result: The robot writes code that says, "Look for the address C:\Users\Public, followed by any filename ending in .bat."

Trick 2: The "Self-Correcting Editor" (Iterative Reasoning)

Even with the Smart Highlighter, the AI might still make mistakes. So, the system uses a Reasoning Loop.

Draft: The AI writes a draft code.
Test: A "Debugger" tool tries to run the code against the original clue.
Feedback: If the code fails, the tool tells the AI, "You missed the backslash!" or "You made this too broad; it's matching innocent files too!"
Retry: The AI fixes the code and tries again.
Grading: Finally, the system generates five different versions of the code and picks the one that is the "Goldilocks" version—not too strict, not too loose, but just right.

The Results: How Good is the Robot?

The researchers tested this system on over 3,000 real-world threat reports and checked it against 2,400 real attack examples from a famous security testing framework (MITRE ATT&CK).

Accuracy: The system caught 99.1% of the real attacks.
False Alarms: It only raised a false alarm 0.8% of the time.
Comparison: When they compared this smart system to just asking a standard AI to "write the code," the smart system was 30% better.

Why This Matters

Think of the current security world as a library where new "Wanted Posters" arrive every second. Human guards can't read them all fast enough, and they get tired.

This paper introduces a robot librarian that:

Reads the poster instantly.
Understands the difference between the building's address and the thief's variable disguise.
Writes the perfect alarm code automatically.
Checks its own work to make sure it's perfect before handing it to the guards.

This allows security teams to stop spending hours manually typing code and start focusing on actually stopping the hackers. It turns "threat intelligence" (information) into "actionable defense" (automated protection) at a speed humans simply cannot match.

1. Problem Statement

Cyber Threat Intelligence (CTI) reports provide Indicators of Compromise (IOCs) essential for Security Operations Centers (SOCs). However, a critical gap exists between the raw IOCs extracted from these reports and their operationalization in Security Information and Event Management (SIEM) systems.

The Gap: IOCs (e.g., file paths, registry keys, command-line arguments) are often context-specific. Direct string matching fails because system logs vary in capitalization, path delimiters, and execution parameters.
Current Limitation: The industry standard is to manually convert IOCs into Regular Expressions (regex) to handle these variations. This process is slow, error-prone, and unsustainable given the volume of CTI reports.
Existing AI Gaps: While recent Large Language Model (LLM) approaches automate IOC extraction, they stop at producing raw strings. They fail to translate these strings into deployable regexes. Furthermore, existing regex generation methods (NLP-based or rule-based) struggle with security-specific challenges:
1. Capture Group Identification: Determining which parts of an IOC are static (capture groups) vs. variable (non-capture groups).
2. Syntactic Validity: LLMs often generate invalid or incomplete regex patterns.
3. Over-Generalization: LLMs tend to produce overly broad patterns (e.g., .*) that lack detection value.

2. Methodology: IOCRegex-gen

The authors propose IOCRegex-gen, a fully automated LLM-based system designed to translate extracted IOCs into syntactically valid and semantically precise regexes. The system operates in two primary phases:

Phase 1: Capture Group Finding

This phase addresses the challenge of distinguishing between static system components (capture groups) and variable attacker-controlled components (non-capture groups).

Knowledge-Enhanced Graph Database: The system utilizes a pre-constructed graph database (Neo4j) containing native Windows file paths, registry keys, and command-line arguments for various OS versions.
Tree Structure & Algorithms:
- File paths and registry keys are stored as hierarchical trees.
- Command-line arguments are structured with commands as parent nodes and parameters as children.
Algorithm:
1. Preprocessing: Normalizes IOCs (e.g., expanding environment variables, standardizing registry roots like HKCU).
2. Matching: The system splits the IOC into substrings and queries the graph database.
3. Longest Sequence Identification: It identifies the longest sequence of adjacent nodes in the graph database to define the capture group.
4. Filtering: If an IOC string contains no valid capture groups (i.e., it is entirely attacker-controlled or a false positive), it is discarded.

Phase 2: Reasoning-Based Regex Generation

This phase uses an iterative reasoning loop to generate and refine the regex, addressing syntactic errors and over-generalization.

Iterative Workflow:
1. Initial Generation: The LLM generates an initial regex based on the IOC and the identified capture groups.
2. Debugging Loop: A regex debugger tests the pattern against the original IOC. If it fails, the error details are fed back to the LLM for refinement.
3. Non-Capture Group Validation: The system checks if the regex inadvertently includes non-capture group elements. If so, the LLM is prompted to remove them.
4. Over-Generalization Check: The system generates 10 random strings to test if the regex matches everything. If it does, the pattern is deemed too broad, and the generation restarts.
Grading & Selection:
- The system generates multiple candidate regexes (typically 5) for each IOC.
- A scoring formula ( $Score = \alpha \cdot n_{cg} - \beta \cdot n_{wc}$ ) evaluates candidates based on the number of correct capture group components ( $n_{cg}$ ) and penalties for non-capture group inclusions ( $n_{wc}$ ).
- The highest-scoring regex is selected as the final output.

3. Key Contributions

IOCRegex-gen System: A novel framework that automates the full pipeline from raw CTI IOCs to deployable SIEM regexes, bridging the gap between threat extraction and actionable detection.
Knowledge-Enhanced Capture Grouping: A unique mechanism using a graph database of OS-native structures to accurately identify capture groups, solving a problem LLMs struggle with due to lack of domain context.
Iterative Reasoning Pipeline: A multi-stage validation workflow (debugging, non-capture validation, and over-generalization checks) that ensures syntactic correctness and semantic precision without relying on expensive fine-tuning.
Comprehensive Evaluation: The first large-scale evaluation of regex generation for security IOCs using real-world ground truth.

4. Experimental Results

The system was evaluated using 3,156 real-world CTI reports and 2,400+ ground-truth strings collected from the MITRE ATT&CK Evaluation framework (independent of the CTI reports).

Hit Rate (Recall): The generated regexes achieved an average hit rate of 99.1% across all datasets. In several scenarios (e.g., Enterprise2024 LockBit, Turla Snake), the hit rate was 100%.
False Positive Rate: The average false-positive rate was extremely low at 0.8%.
Complexity: The generated regexes had an average grading score above 3, indicating substantial structural complexity (incorporating multiple capture groups) rather than simple literal matches.
Generalization: The average similarity score between generated regexes and source IOCs was 0.4, demonstrating that the system successfully introduced necessary variability to match different system contexts without becoming overly broad.
Ablation Study: Removing either the Capture Group Finding or the Reasoning-based Generation components caused a significant performance drop:
- Hit rates decreased by over 16.7%.
- False-positive rates increased by over 23.3%.
- This confirms that both components are essential for high-quality regex synthesis.

5. Significance

Operational Efficiency: IOCRegex-gen drastically reduces the time required to operationalize CTI, potentially reducing hours/days of manual analyst work to seconds.
Scalability: The system can process thousands of reports, enabling SOCs to keep pace with the increasing volume of global cyber threats.
Accuracy & Reliability: By integrating domain knowledge (graph DB) with LLM reasoning, the system overcomes the "hallucination" and "over-generalization" issues common in pure LLM approaches, producing regexes ready for immediate deployment in SIEMs.
Open Source: The authors have released the source code, fostering reproducibility and further research in automated threat detection.

In conclusion, this work represents a significant leap forward in Cyber Threat Intelligence operationalization, moving beyond simple extraction to the generation of high-fidelity, actionable detection rules.