[Feature Proposal] Applied AI: Local LLM-based Analyzer for Result Summarization, Threat Classification & Enrichment (Ollama / LocalAI integration)

[R1sh0bh-1]

Name

LocalLLMAnalyzer (or LLMSummarizer)

Link

• Ollama: https://ollama.com (primary recommended backend – easy local setup, many models)
• LocalAI: https://localai.io (alternative for more backends)
• Optional: Hugging Face transformers pipelines for pure-Python local inference (no extra container)

Type of analyzer

Observable (primary – works on IPs, domains, URLs, hashes, etc.)
File (future extension – e.g. summarize deobfuscated strings, script analysis, or multi-analyzer file reports)
Docker (optional – if we bundle a lightweight Ollama container for easier deployment)

Why should we use it

IntelOwl already aggregates rich data from 100+ analyzers (VirusTotal, GreyNoise, Shodan, Abuse.ch, YARA, CAPA, Intezer, etc.), but analysts often spend significant time manually reading and correlating verbose/conflicting reports to understand the real threat context.

This analyzer would use a self-hosted / local Large Language Model (no data sent to external providers like OpenAI → full privacy for sensitive investigations) to:

• Generate concise, natural-language summaries of multi-analyzer results
• Classify threat type (phishing, ransomware, C2, credential-theft, etc.) and assign a normalized risk score
• Extract additional entities / IOCs (e.g. targeted brands, wallet addresses, TTPs)
• Provide actionable insights and suggested pivots / next steps
• Reduce analyst triage time dramatically while preserving drill-down to raw data

Benefits:

• Privacy-first (critical for SOC/CTI teams)
• Enhances usability: turns raw intel into readable reports for tickets, alerts, executives
• Differentiates IntelOwl as a next-gen TI platform with applied AI
• Aligns perfectly with Honeynet/IntelOwl interest in applied AI
• Extensible: custom prompts, model switching, fine-tuning support later
• Complements existing analyzers without replacing them

This builds on patterns from analyzers like Intezer (behavioral insights) or recent additions (Phunter, etc.), but adds semantic understanding.

Possible implementation

High-level architecture

• New Python class inheriting from ObservableAnalyzer (and later FileAnalyzer)
• Connects to local LLM backend via API (Ollama default: http://localhost:11434)
• Input: aggregated analyzer reports (from job results, easily accessible via self.report)
• Prompt engineering: structured system prompt + few-shot examples to reduce hallucinations and enforce output format
• Output: parsed into IntelOwl-standard fields
  • summary: main text paragraph
  • tags: auto-added (e.g. ai:malicious, ai:phishing, severity levels)
  • extra_data: JSON with risk_score (0-100), threat_categories, confidence, extracted_iocs, suggested_pivots
• Runs async via Celery (like slow analyzers: VirusTotal, URLscan)
• Secrets: store LLM endpoint / API key (if any) via existing secrets management

Phased / Minimal Viable Implementation

1. Support Ollama only (simplest: REST API, no auth by default)
2. Focus on observable analysis
3. Fixed prompt template:

[R1sh0bh-1]

Hi @mlodic, what do you think about this local LLM analyzer idea? Ready to start prototyping the Ollama version if it looks interesting. Thanks!

[mlodic]

have you read this AI slop or you just copy/pasted? 📦

It's clear that the AI has not full comprehension of the whole IntelOwl framework. Only analyzers are cited, which are the most popular and the base ground of the project but to create real orchestration you need to use the other plugins.

If you want to work on that, you have to understand the framework. Go through the documentation and try the project on your own, then re-structure this proposal differently.

[R1sh0bh-1]

Hi @mlodic,

You were right the first version did read like generic AI output and didn’t show enough understanding of how playbooks, connectors and orchestration actually work in IntelOwl. Thanks for calling it out directly; it helped me step back and rethink properly.

Revised approach:

• Make it a connector (LLMSummarizerConnector) instead of an analyzer
• Runs after playbooks/analyzers on the full job.report['results']
• Uses Ollama /api/generate → structured JSON output (summary, risk_score, tags e.g. ai:phishing, extracted_iocs)
• Few-shot prompt tuned to IntelOwl’s existing tags & verdicts
• Designed to plug into playbooks (e.g. summarize → pivot on new IOCs → export)

If this direction makes more sense now, I’d like to reopen the issue and open a small PoC PR (observables only, should be testable in 1–2 days). Any quick thoughts on connector vs analyzer placement, or playbook integration gotchas?

Thanks again happy to iterate.

[mlodic]

@R1sh0bh-1 sure go for it, open a draft PR once you have something to discuss

[mlodic]

A connector should be fine, also please consider that a Visualizer is its perfect companion for this case.

[AnshSinghal]

what do you think about a RAG over IntelOwl artifacts?

[AnshSinghal]

One additional thought to keep the LLM connector grounded and extensible:
instead of sending the full job report raw, we could add a small internal retrieval step (RAG-style) over IntelOwl-owned data only (relevant analyzer results, prior jobs, tag/verdict definitions).

This keeps the model aligned with IntelOwl semantics, reduces hallucinations, and fits naturally in a connector + visualizer flow.

Backend-wise, alongside Ollama, GPT-OSS could be considered as an optional local LLM backend. Architecturally it would just be another backend behind the same connector interface, preserving the same privacy and playbook integration guarantees.

Totally fine to keep the initial PoC minimal; just wanted to flag both as future-safe design directions.

[R1sh0bh-1]

Thanks, this makes a lot of sense.

I agree that keeping the LLM grounded in IntelOwl’s own semantics is important, and a lightweight RAG step over IntelOwl artifacts (selected analyzer outputs, verdict/tag definitions) sounds like a good future direction to reduce noise and hallucinations.

For the initial PoC, I’ll keep things intentionally minimal (Ollama backend, connector only, structured JSON output) so we can validate the integration, playbook flow, and UX quickly. Once that’s stable, a scoped internal retrieval layer would fit naturally without changing the external interface.

I’ll keep this in mind while designing the connector abstraction so it stays extensible. Thanks for the suggestion!

[rootp1]

It might also be useful to think about how the connector behaves when results are sparse,,,, clearly signaling “low confidence” summaries could be a feature, not a bug.

[R1sh0bh-1]

👍 Agreed explicitly surfacing low confidence is important. I’ll keep this in mind for the PoC.