The full open-source threat-intel stack, April 2026

Three legitimate reasons to run an OSS CTI stack in 2026: cost (a capable three-person SOC can run a full agentic CTI workflow on OSS at $300-$1,500 per month in infrastructure), transparency (no vendor controls your data pipeline or changes your feed terms unilaterally), and integration flexibility (OpenCTI's GraphQL API and MISP's TAXII interface integrate with anything; commercial platforms have proprietary integration walls).

Where OSS genuinely struggles compared to commercial: data depth. MISP plus abuse.ch feeds give you operational IoC data. They do not give you Insikt Group research, Intel 471 criminal-underground coverage, or Mandiant's IR-pedigree actor profiles. The data-depth gap is real and matters for advanced threat intelligence programs. For threat hunting against named APTs in specific sectors, commercial feeds are not optional.

Community sourced threat data via sharing communities (ISACs, sector-specific MISP groups, CIRCL OSINT) narrows the gap for organisations that qualify for and actively participate in sharing. ISAC participation is free for sector members and provides threat intelligence that approaches commercial feed quality in specific sectors.

The integrated stack, working in production as of April 2026:

# Full OSS agentic CTI stack (April 2026)

## Data ingress (MISP)
MISP pulls from:
  - CIRCL OSINT feed     (TAXII 2.0, requires free account)
  - abuse.ch URLhaus      (API, free)
  - abuse.ch MalwareBazaar (API, free)
  - abuse.ch ThreatFox    (API, free)
  - AlienVault OTX       (TAXII, free account)
  - CISA KEV              (JSON, free, no account)

## Knowledge graph (OpenCTI)
OpenCTI connector imports MISP events:
  - Converts to STIX2 objects
  - Builds relationships (IoC -> Campaign -> Actor -> TTP)
  - GraphQL API for analyst queries

## Analyser orchestration (Cortex)
Cortex fires on new indicators from MISP/OpenCTI:
  - VirusTotal (file hash, IP, domain, URL)
  - AbuseIPDB (IP reputation)
  - URLscan.io (URL/domain sandbox)
  - Shodan (IP infrastructure)
  - Greynoise (IP context: scanner vs targeted)
  - crt.sh (domain cert transparency)
  - BGPview (IP ASN context)
  - WhoisXML (domain registration history)
  - + 40 more community analysers

## LLM orchestrator (Claude Sonnet / GPT-5 / Llama 4)
Agent reads Cortex output (JSON), then:
  1. Synthesises enrichment note from analyser results
  2. Maps to MITRE ATT&CK TTPs
  3. Assigns confidence (High/Medium/Low with rationale)
  4. Writes STIX-formatted note back to OpenCTI
  5. Flags Low-confidence outputs for analyst review

## Case management (TheHive)
  - Promoted-to-incident findings from OpenCTI -> TheHive
  - Analyst reviews case in TheHive UI
  - Approves or rejects enrichment notes
  - Escalates to Cortex responder for response actions

## Detection output
  - YARA rules (LLM draft, analyst review, corpus test)
  - Sigma rules (LLM draft, schema validation, 7-day staging)
  - SIEM alert rules pushed via CI pipeline

## Infrastructure (April 2026 pricing)
  MISP:     Hetzner CPX31   8vCPU/32GB/500GB  ~$55/mo
  OpenCTI:  Hetzner CPX51  16vCPU/64GB/1TB   ~$165/mo
  TheHive:  Hetzner CPX21   4vCPU/8GB/160GB   ~$25/mo
  Cortex:   Hetzner CPX31   8vCPU/32GB/500GB  ~$55/mo
  Elasticsearch: ~$50-100/mo
  LLM API: Claude Sonnet 4.5 ~$500-1,500/mo
  -----------------------------------------------
  Total: ~$850-$1,900/mo at moderate SOC volume

The MCP (Model Context Protocol) bridges for connecting Claude and other LLMs to the MISP and OpenCTI APIs are maintained by the community as of April 2026. Check the Anthropic MCP registry and the MISP project GitHub for current connector status. The architecture above works with direct API calls if MCP bridges are not yet available for your specific LLM.

Most mature teams run both: MISP as the community feed ingestion layer, OpenCTI as the analyst-facing enriched intelligence graph. The integration is well-documented; OpenCTI has a native MISP connector that imports events and converts them to STIX2 objects.

Prices: Hetzner public pricing, April 2026. AWS/GCP multiplier: approximately 2-3x. Self-hosted on co-lo hardware: approximately 0.3-0.5x at 1+ year depreciation.

Honest verdict: workable as a draft accelerator, not a production-ready automation. LLMs can draft YARA rule skeletons from natural-language descriptions or sample binary analysis. The output is structurally valid YARA more often than not. The failure modes:

• xHallucinated byte patterns: the LLM invents hex sequences that look plausible but are not present in the actual malware sample. Always validate against a known-malicious corpus.
• xOverly broad string matching: the LLM includes common library strings that appear in both malicious and benign software, producing high false-positive rates.
• xMissing PE structure context: YARA rules for PE files need to account for section offsets and import table structure; LLMs frequently get these wrong.
• xVirusTotal Retrohunt cost risk: deploying untested YARA rules to VirusTotal Retrohunt costs credits; bad LLM-generated rules burn Retrohunt credits with no value.

Best practice: LLM drafts the rule skeleton. Human analyst validates strings against a corpus of at least 50 known-malicious samples and 200 clean-baseline binaries. Rule enters a PR workflow with test results attached. Only then does it deploy to endpoint scanning or Retrohunt. See the Awesome-YARA community repository on GitHub for reference rule patterns that help the LLM produce better drafts.

Better than YARA. Sigma's YAML structure is more tractable for LLMs. The primary failure mode is hallucinated field names (see the AI SIEM correlation page for the full Sigma workflow). With a schema-validation CI step (SigmaHQ provides validators for Splunk, Sentinel, Elastic, Chronicle), LLM-generated Sigma rules are a valid accelerator for detection engineering.

The SigmaHQ sigma-cli tool validates Sigma rules against product-specific schemas and converts them to the target SIEM query language. Adding this to a CI pipeline catches field-name hallucinations before the rule reaches staging. With this guard in place, the LLM-to-engineer-to-staging-to-production workflow reduces detection engineering time by 40-60% on well-understood TTP coverage gaps.