Open Source Threat Intelligence
A threat intelligence feed is only worth acting on if you know where each indicator came from and whether it is still true, yet most arrive as flat lists you are expected to trust on sight. The work that matters is turning that noise into intelligence with context: provenance, confidence, expiration, sightings, and handling rules that say who is allowed to see it. Open source tooling lets you inspect exactly how indicators are collected, enriched, and correlated, and keep your most sensitive material - internal incidents, partner-shared reports, live investigations - inside your own environment rather than handing it to a platform whose enrichment lookups you cannot see.
OpenCTI
Threat intelligence platform for structuring, linking, and visualizing cyber threat knowledge
MISP
Open source threat intelligence sharing platform for collecting, correlating, and exchanging cyber threat data
capa
Command line binary analysis tool that identifies capabilities in PE, ELF, .NET, shellcode, and sandbox reports
IntelOwl
Threat intelligence management with one API to query many sources and analysis tools at once
Yeti
Threat intelligence platform for DFIR teams, with bulk observable search and enrichment via web API
Cortex
Observable analysis and active response engine for threat intelligence and incident response
Harpoon
OSINT and threat intelligence CLI tool for querying many external sources from one command line
IntelMQ
Threat intelligence collection and processing for CERTs, CSIRTs, and SOCs
Our picks
The right tool depends on whether you need to store intelligence, enrich indicators, or bridge into DFIR.
Structured threat knowledge: OpenCTI OpenCTI structures technical and non-technical threat knowledge on a STIX2 schema, linking TTPs, observables, attribution, and victimology to their primary sources with confidence levels and first and last seen dates. It maps findings to MITRE ATT&CK and can infer new relationships from existing ones. Connectors integrate MISP, TheHive, and ATT&CK, making it a strong central knowledge base.
Sharing between teams: MISP MISP is the established choice for sharing. It correlates attributes automatically to surface links between events, supports structured objects and sightings, and lets instances synchronize to build trusted communities. It imports and exports MISP JSON, STIX 1 and 2, CSV, OpenIOC, and IDS rules for Suricata, Snort, and Zeek, so intelligence flows straight into detection tooling.
One-request enrichment: IntelOwl IntelOwl enriches files and observables like IPs, domains, URLs, and hashes from many sources through a single API request, instead of querying each service by hand. A plugin framework of analyzers, connectors, pivots, visualizers, and playbooks lets teams chain analyses and replay whole investigations, which suits high-volume triage.
CTI for DFIR: Yeti Yeti bridges CTI and DFIR, built to answer where an artifact has been seen and which IOCs tie to a given threat. It stores observables, TTPs, and campaigns, supports bulk observable search, and acts as a backend for Yara signatures, Sigma rules, and DFIQ, with a web API for automated queries and enrichment.
What actually separates a threat intel platform from a feed dump
These tools are not variations on one product; they occupy different stages of the pipeline. OpenCTI, MISP, and Yeti are knowledge platforms that store observables, reports, relationships, and confidence over time. IntelOwl, Cortex, and Harpoon are enrichment engines that take an indicator and query many sources at once. IntelMQ sits upstream of both, collecting and normalizing raw feeds through a message queue, while capa is narrower still, detecting what a binary can do. Decide which stage you are missing first, because an enrichment engine will not store your intelligence and a knowledge platform will not triage a malware sample.
For the knowledge layer, the data model decides whether context survives. Look for observables, indicators, reports, sightings, relationships, confidence, and source provenance, not a flat IOC table. OpenCTI is built on a STIX2 schema and maps findings to MITRE ATT&CK, while MISP centers on automatic correlation and can synchronize between instances to build trusted sharing communities. Both import and export STIX, which matters the moment you exchange intelligence with a partner. Also check that handling labels like TLP travel with the data, so a careless export does not leak a restricted report.
Enrichment is powerful but leaky, so treat it as a privileged path. Automatic lookups through IntelOwl or Cortex can enrich an indicator from dozens of sources, but every external query can reveal what you are investigating, and Harpoon depends entirely on the provider APIs and keys you configure. Before production, decide which systems consume the output - SIEM, SOAR, EDR, firewalls, case management - and confirm exports preserve relationships, timestamps, confidence, and source metadata rather than dumping a bare CSV. Cortex pairs natively with TheHive and MISP, which shortens that wiring for teams already using them.
Related categories
Frequently asked questions
How is a threat intelligence platform different from a plain feed aggregator?+
An aggregator pulls indicators from many sources and republishes them. A platform preserves what makes them usable later: provenance, relationships, analyst decisions, confidence, expiration, and sharing restrictions. OpenCTI records first and last seen dates, confidence levels, and links back to primary sources, so when an alert fires weeks later you can see where the indicator came from and whether it was ever validated. That history is the difference between intelligence and a longer blocklist.
When do STIX and TAXII actually matter?+
They matter the moment you exchange intelligence with partners, an ISAC, or another platform, because they preserve structure that CSV throws away. OpenCTI is built on a STIX2 schema, and MISP imports and exports STIX 1 and 2 alongside its own JSON and IDS formats. If you only feed indicators into your own detection tools, simpler formats can be enough, but check that imports and exports keep relationships, confidence, and timestamps, not just bare indicators.
What is the difference between a knowledge platform and an enrichment engine here?+
A knowledge platform like OpenCTI, MISP, or Yeti stores intelligence over time, with relationships, sightings, and source history. An enrichment engine like IntelOwl or Cortex takes a single observable and queries many analyzers at once to tell you more about it right now. They complement each other: Cortex is designed to pair with MISP and TheHive to enrich cases. If you already store intelligence but triage indicators by hand, the engine is what you are missing.
Does automatic enrichment risk exposing my investigations?+
Yes, and it is easy to overlook. Every external lookup an enrichment engine makes can reveal to a third party which domain, hash, or address you are looking into. IntelOwl and Cortex query many sources per indicator, and Harpoon is purely a client for external services like Shodan, VirusTotal, and Censys using your API keys. For sensitive cases, prefer local or self-hosted analyzers where possible, and understand which lookups leave your network before you run them in bulk.
How does MISP support sharing between organizations?+
MISP instances can synchronize events and attributes with one another to build trusted sharing communities, so a partner's feed updates yours automatically. It supports warning lists, sightings, and structured objects, and secures notifications with GnuPG and S/MIME signing and encryption. Because sharing is the point, pay attention to the distribution and handling label on each event, since synchronization is exactly where a restricted indicator leaks if it is marked wrong.
What does IntelMQ do that the storage and enrichment tools do not?+
IntelMQ sits upstream, collecting and processing raw security feeds through a message-queue pipeline before they reach a platform. Configurable bots parse, normalize, deduplicate, and enrich events as JSON, then output to stores like PostgreSQL, Elasticsearch, or Splunk, and can generate blocklists. Built by European CERTs and CSIRTs, it is the automation layer that turns messy feeds and log files into clean, structured data, rather than a place analysts browse intelligence.
This list includes capa - how does binary analysis fit threat intelligence?+
capa is the outlier: instead of managing indicators, it inspects an executable and reports what it can do, such as installing a service or opening an HTTP channel. It works on PE, ELF, and .NET files, shellcode, and sandbox reports from CAPE, DRAKVUF, and VMRay, and plugs into IDA Pro and Ghidra. It feeds the intelligence process by turning an unknown sample into described capabilities that analysts can then record and correlate elsewhere.
How do I keep my intelligence from being trapped in one platform?+
Portability is the safeguard, because your intelligence is often the only copy of hard-won context. Favor tools that export objects, relationships, tags, sightings, and source metadata in usable formats: OpenCTI exports CSV and STIX2 bundles, MISP exports STIX and IDS rules, and Yeti exports in user-defined formats for SIEMs. Keep documented schemas, scheduled backups, and a tested export, so that if a project slows down you can move without losing provenance.