Skip to content

Back to the catalog

ThreatIntel-Aggregator
github.comrepo

ThreatIntel-Aggregator

ThreatIntel-Aggregator is a self-hosted FastAPI/Next.js platform that polls 60+ tiered security RSS feeds (CISA, Talos, Unit42, etc.), runs AI triage to score severity and tag MITRE ATT&CK TTPs, extracts IOCs/CVEs, and correlates findings against a RunZero asset inventory to surface org-level exposure. Its Detections module goes further: it catalogs AI-generated or locally-imported detection rules (KQL/Sigma/YARA/Suricata/SPL), statically validates them, runs AI-driven MITRE alignment checks against technique coverage, tracks detection "rot," and can sync Hunts/Analytics Rules to a live Microsoft Sentinel workspace. It's designed to run standalone with zero cloud dependency or fully integrated with Azure/Entra/Sentinel, with all storage in Postgres and auth via Entra SSO or a local API key.

TL;DR Self-hosted threat-intel feed aggregator with AI triage, RunZero asset correlation, and a MITRE-mapped detection-engineering/Sentinel-sync module.
Document

What it is

ThreatIntel-Aggregator ships as one codebase deployable at three tiers, differing only by which env vars are set — the same application code runs in all three:

./scripts/setup-basic.sh       # no AI, no cloud
./scripts/setup-basic-api.sh   # + direct Anthropic triage
./scripts/setup-azure.ps1      # full Sentinel/Entra deployment (PowerShell 7+, az CLI)

The two bash scripts stand up a local Postgres container, apply the schema, and generate backend/.env / frontend/.env.local. setup-azure.ps1 wraps infra/provision.ps1, an idempotent Container Apps runbook (Postgres itself is not provisioned — point PG_DSN at any reachable server).

The caveat the summary omits

The summary lists "AI-generated" detection rules as a live capability. Per the page, the AI-generation pipeline is not in this release. The detections.ai orchestrator (backend/detection_pipeline/orchestrator.py) that turns triaged intel into draft KQL is "coming soon," pending detections.ai's own public API. The DETECTIONS review surface, Sentinel sync, and local import all work today; automated rule generation does not.

Getting detections in without AI or Sentinel

For the Basic tier, the working path is local file import. Set LOCAL_IMPORT_DIR to an absolute backend filesystem path (a mounted volume in a container); everything imported must live under that root, and the UI can only pick sub-paths beneath it — no arbitrary filesystem access. Point it at hand-written rules, a real tenant export, or a public Sigma/Sentinel repo.

Formats accepted day one: raw .kql/.txt/.yar/.spl (optionally paired with a .json/.yaml sidecar declaring title/description/technique_id), YARA, Suricata, Sigma YAML (single or multi-doc), Splunk SPL, and Microsoft's native exported Analytics Rule/Hunting JSON — but only Scheduled-kind rules carry evaluable KQL; other kinds are recognized and reported, not evaluated.

What runs on import: static validation always; MITRE alignment only if an AI provider is configured; everything Sentinel-dependent (backtest, telemetry, disposition) renders as "no Sentinel connection configured" rather than a blank. A ready-to-import demo (examples/local-detections-samples/) contains two valid KQL rules, one deliberately invalid, and one unrecognized file — enough to see all three result states on first import.

Other operational specifics

  • Auth is env-toggled: AZURE_AD_TENANT_ID set → Entra SSO (first login becomes admin); unset → single shared LOCAL_API_KEY grants admin to anyone holding it. Frontend auto-detects via GET /api/auth/mode.
  • Sentinel hunt sync is gated by SENTINEL_HUNTING_SYNC_ENABLED with per-team off/manual/auto mode — never a silent auto-push unless opted in.
  • Storage is Postgres-only now; SQLite and Azure Blob support have been fully retired.
  • Stack: Next.js 16 frontend (plain JS), FastAPI/Python 3.12 backend with APScheduler + slowapi. 63 feeds across three trust tiers.

Techniques named here

  • T1059.001