Threat Intelligence on a Budget: A Practitioner’s Guide

Why Most “Threat Intelligence” Is Just Data You Can’t Use

Let’s get the uncomfortable truth out of the way: the majority of what the industry calls “threat intelligence” is neither intelligent nor particularly threatening. It’s data. Raw, unprocessed, decontextualised data – millions of IP addresses, hashes, and domains dumped into feeds that nobody reads, piped into SIEMs that nobody tunes, generating alerts that nobody investigates.

The distinction matters. Data is a list of malicious IPs. Information is knowing those IPs belong to a botnet targeting financial services. Intelligence is knowing that botnet is actively exploiting a vulnerability in the specific software version running on your perimeter – and having that knowledge early enough to do something about it.

Most organisations never get past the first stage. They subscribe to feeds, congratulate themselves on “doing threat intelligence,” and proceed to drown in noise they’ll never action. Meanwhile, the vendors are happy to sell you the solution. Recorded Future starts north of $100K/year. Mandiant Intelligence, ThreatConnect Enterprise, Anomali ThreatStream – these are serious platforms built for organisations with dedicated intelligence teams of five or more analysts and budgets to match.

That pricing isn’t unreasonable for what they deliver. But it creates a dangerous perception: that useful, operational threat intelligence requires enterprise spend. It doesn’t.

We’ve run a functional TI programme for under $5/month. Not a toy setup – a proper MISP instance with 50+ OSINT feeds, automated correlation, and enrichment that feeds directly into our detection stack. The real bottleneck was never the tooling. It’s analyst time, clear requirements, and the discipline to process what you collect rather than collecting more.

The Stack: What You Actually Need

A workable threat intelligence programme has three layers: collection, processing, and analysis. You can build all three with open-source tools and free feeds. The paid options are genuinely useful but not essential to start.

Collection: Where Good Intel Comes From

The free tier of threat intelligence feeds is remarkably good – better, honestly, than most teams realise, because they never properly configure what’s already available.

AlienVault OTX

AlienVault OTX is the largest open threat intelligence community in existence. Over 100,000 participants across 140 countries contribute to “pulses” – curated collections of indicators tied to specific threats. The platform processes north of 19 million indicators daily and provides a free STIX/TAXII server for automated ingestion. The signal-to-noise ratio varies by pulse author, but the top contributors produce genuinely excellent work.

abuse.ch

abuse.ch deserves special mention. Run by the Institute for Cybersecurity and Engineering at Bern University of Applied Sciences, it operates multiple focused projects – URLhaus for malicious URLs, MalwareBazaar for malware samples, ThreatFox for IOCs, Feodo Tracker for botnet C2s, and SSLBL for malicious SSL certificates. All free. All quality-verified. The Feodo Tracker in particular is exceptional for banking trojan infrastructure.

CIRCL OSINT Feed

CIRCL OSINT Feed is maintained by the team behind MISP itself, which means the feed format is always compatible and the curation reflects deep expertise in intelligence sharing standards.

PhishTank

PhishTank, operated by Cisco Talos, provides community-verified phishing URLs via an open API. One caveat: new user registration was removed back in 2020 due to abuse, so you’ll need the API for automated access rather than manual submissions. Still a solid source for phishing URL verification.

VirusTotal

VirusTotal is probably the single most-used tool in any SOC, and the free tier is more capable than people give it credit for. You get 500 lookups per day, file analysis up to 650MB, URL scanning, and access to the community comments that often contain analyst notes you won’t find anywhere else. For a small team, 500 daily lookups covers your triage needs comfortably. The real value isn’t just the detection ratio – it’s the behavioural analysis, network indicators, and relationships tab that show you how a sample connects to broader campaigns. We use it daily and the free tier has never been the bottleneck.

On the affordable side, two tools stand out.

GreyNoise Community

GreyNoise Community solves a problem every analyst has encountered: “Is this IP actually malicious, or is it Shodan scanning again?” GreyNoise classifies IPs as benign scanners, malicious actors, or unknown using data from over 5,000 sensors in 80 countries. The free community tier gives you 50 searches per week – restrictive, but the context quality is excellent. When you’re triaging alerts at 2 AM and need to know if an IP is Censys or a genuine threat, those 50 searches earn their keep.

Last quarter we caught a credential-stuffing campaign against our SSH infrastructure purely because we were correlating GreyNoise data with auth logs. Three of the IPs were classified as “benign scanner” by GreyNoise – turns out they’d been compromised and were being used as attack infrastructure. That’s the kind of nuance that pure automation misses. The “benign” classification was technically correct at time of observation; the IPs had been legitimate scanners before being hijacked. Without manual correlation against our own logs, we’d have whitelisted active attackers.

Shodan Membership

Shodan Membership costs $49 as a one-time, lifetime purchase. That’s not a typo – it’s a permanent membership that includes 100 query credits and 100 scan credits per month. Academic accounts (free with a .edu email) get additional benefits. Shodan occasionally runs Black Friday sales where the membership drops to $5. For external attack surface monitoring and infrastructure reconnaissance, nothing else comes close at this price point.

Your Own Telemetry

Then there’s the source most teams undervalue: your own telemetry. DNS query logs, email headers from rejected phishing attempts, firewall denies, authentication failures, web application logs. This is intelligence about threats targeting your organisation specifically – not generic feeds about threats targeting someone else’s. A pattern of failed SSH logins from a specific ASN tells you more about your threat landscape than a thousand generic IOCs.

Processing: Making Sense of the Noise

MISP

MISP (Malware Information Sharing Platform) is the gold standard for IOC management, and it’s completely free and self-hosted. Originally developed by the Belgian defence sector and now maintained by CIRCL in Luxembourg, MISP handles the entire intelligence lifecycle – ingestion, correlation, enrichment, distribution, and sharing. It ships with over 50 pre-configured OSINT feed templates that you can enable with a click.

The web interface looks like it was designed in 2008 and hasn’t been updated since. Navigation is unintuitive, the terminology takes weeks to internalise, and the correlation engine’s logic will confuse you until you’ve read the documentation twice. The learning curve is real – we spent our first week convinced half the features were broken when they were just badly labelled. But once feeds are flowing and you understand the event/attribute/object model, nothing else comes close at any price. We’ve looked. Repeatedly.

The Docker installation is straightforward. We run ours on a Hetzner CX22 – that’s 2 vCPUs, 4GB RAM, 40GB disk for approximately the same cost as our blog’s infrastructure. MISP 2.5, which shipped its major UI overhaul in 2025, runs comfortably on this. Feed syncs, correlation, and the web interface all perform well. You won’t run machine learning enrichment modules on this spec, but for operational IOC management serving a small team, it’s more than sufficient.

Where MISP genuinely shines is feed management. Enable a feed, set the sync interval, map it to a distribution level, and forget about it. New indicators appear, get correlated against your existing events, and surface in the UI when they match something you care about. The MISP warning lists – pre-built exclusion lists for known benign infrastructure like Cloudflare, Google DNS, and Microsoft Azure ranges – save you from drowning in false positives. Enable those on day one. We didn’t, and spent three days investigating why our “malicious IP” detections included half of AWS.

OpenCTI

OpenCTI takes a different approach. Built natively on STIX 2.1, it’s a knowledge graph platform designed for strategic and analytical threat intelligence – tracking threat actors across campaigns, mapping infrastructure overlaps, visualising relationships between incidents. The Community Edition is free under Apache 2.0.

But OpenCTI is heavy. Looks amazing in demos. Then you try to run it on 8GB of RAM and watch Redis eat your entire system. We tried OpenCTI first, actually. After the third OOM kill in a week – always at 3 AM, always during a scheduled connector sync – we went back to MISP and haven’t looked back. OpenCTI is brilliant if you have 32GB of RAM to spare. We don’t. Production deployments need 16GB as a minimum. You’re looking at a CX42 VPS at approximately 16 euros per month or higher for comfortable operation.

The distinction matters: MISP excels at operational TI – rapid IOC sharing, automated feed management, SIEM integration. OpenCTI excels at analytical and strategic TI – threat actor profiling, campaign tracking, long-term pattern analysis. Many mature teams run both, with MISP feeding IOCs into OpenCTI for deeper analysis. If you’re starting from zero, start with MISP. It delivers value faster.

CrowdSec

CrowdSec takes a community-driven approach to blocklists. It analyses behaviour patterns rather than relying solely on reputation, and provides “bouncers” – enforcement plugins for nginx, iptables, Cloudflare, and dozens of other platforms. The free tier includes 3 blocklists with a 3,000 IP cap. For perimeter defence based on crowdsourced intelligence, it’s surprisingly effective.

TheHive and Cortex

TheHive paired with Cortex gives you a free, open-source incident response platform that pairs naturally with MISP. TheHive handles case management – creating cases from MISP alerts, assigning tasks, tracking observables through an investigation. Cortex handles automated enrichment: feed it an IP and it queries VirusTotal, Shodan, MISP, and a dozen other sources in parallel, returning structured results into your TheHive case. It’s heavier than MISP alone – you’re running three services instead of one – but once you’re handling actual incidents rather than just collecting indicators, the workflow TheHive provides is hard to replicate with spreadsheets and sticky notes. Don’t deploy it on day one. Deploy it the first time you realise you’re tracking an incident across four browser tabs and a text file.

Analysis: The Human Part

No amount of automation replaces an analyst who understands context. But good tools make the analytical work faster and more thorough.

CyberChef

CyberChef, developed by GCHQ and open-sourced with over 34,200 GitHub stars, is the Swiss Army knife of data transformation. It runs entirely in the browser – no installation, no dependencies. Hundreds of operations for encoding, decoding, hashing, parsing, decompressing, and defanging. The “recipe” system lets you chain operations together: take a base64-encoded string, decode it, extract URLs, defang them, and export as a list – all in one saved recipe. For malware analysis, phishing investigation, and general IOC manipulation, CyberChef is indispensable.

Maltego Community Edition

Maltego Community Edition provides visual link analysis – mapping relationships between domains, IPs, email addresses, and organisations. The 24-result cap on transforms makes it feel like a trial version pretending to be free software, and the 200 monthly credits constrain serious investigations. Useful for learning to think in graphs. Frustrating for actual casework.

YARA Rules

YARA is the language for malware detection rules – originally created at VirusTotal and now maintained by Google. You write rules that describe patterns in files: specific strings, byte sequences, file size constraints, header characteristics. When a new malware family hits your sector, a well-written YARA rule lets you scan your entire environment for variants, not just the single hash that appeared in the feed. YARA Forge provides curated community rules that cover major malware families, saving you from writing everything from scratch. The learning curve is gentle if you’ve ever written regex – steeper if you haven’t – but the payoff is detection capability that works at the file level, where IOC blocklists can’t reach.

Sigma Rules

Sigma does for SIEM detections what YARA does for file scanning: provides a vendor-neutral rule format. Write a Sigma rule once, then convert it to Splunk SPL, Elastic KQL, Microsoft Sentinel, CrowdStrike LogScale, or a dozen other query languages. The SigmaHQ repository contains thousands of community rules covering ATT&CK techniques, and new rules appear within days of major threat disclosures. This is where threat intelligence becomes operational – you read a report about a new campaign, find or write Sigma rules for the described TTPs, convert them to your SIEM’s format, and deploy. Without Sigma (or something like it), “operationalising intelligence” means manually rewriting detection logic for every platform. Nobody has time for that.

MITRE ATT&CK

MITRE ATT&CK is the framework that organises everything else on this page. It catalogues adversary tactics and techniques based on real-world observations – 14 tactics, hundreds of techniques, each mapped to specific threat groups and software. Free, continuously maintained by MITRE, and adopted across the entire industry. Map your YARA rules to ATT&CK techniques. Map your Sigma rules to ATT&CK techniques. Map your MISP events to ATT&CK techniques. Then look at the gaps. Which tactics have zero detection coverage in your environment? Those gaps are where you’re blind, and they should drive your next round of PIRs and detection engineering. If you’re not using ATT&CK to organise your programme, you’re not doing threat intelligence – you’re collecting IOCs and hoping for the best.

The Diamond Model

For structuring your analysis, the Diamond Model remains one of the most practical frameworks available. Every intrusion maps to four vertices – Adversary, Capability, Infrastructure, and Victim – connected by edges that represent relationships. When you discover a new IOC, the Diamond Model gives you immediate pivot points: what capability does this infrastructure support? What adversary operates that capability? What other victims has that adversary targeted? Simple, but surprisingly powerful for organising investigative threads.

From Alert to Action: A Real Workflow

Tools are useless without a workflow connecting them. Here’s what an actual day looks like – not a theoretical architecture diagram, but the sequence of actions that turns a feed indicator into a defensive decision.

08:15 – Feed sync completes. MISP’s scheduled pull from abuse.ch ThreatFox finishes overnight. Forty-seven new indicators landed: a mix of IP addresses, domains, and file hashes associated with a Lumma Stealer campaign. MISP correlated them automatically against your existing events and flagged three IPs that also appeared in yesterday’s Feodo Tracker sync. That overlap is interesting – it suggests shared infrastructure between two malware families, which is worth a closer look.

08:30 – Triage. You open MISP’s “new events since last login” view. Most of the 47 indicators are hashes for Lumma Stealer variants you’ve never seen on your network. Low priority – they go into the correlation pool for future matching but don’t need immediate action. The three overlapping IPs are different. You check them against your firewall logs from the past 72 hours. One hit: 198.51.100.47 appeared in your outbound connection logs yesterday at 14:22, destination port 443, from a workstation in the finance department.

08:45 – Enrichment. Before escalating, you need context. Is 198.51.100.47 actually malicious, or is this a false positive from a shared hosting IP? You query GreyNoise. Result: not classified as a known scanner, last observed conducting targeted activity against financial sector organisations. That rules out Shodan, Censys, and the other usual suspects. You check VirusTotal – the IP resolves to a domain with three community flags for C2 activity. Shodan shows port 443 serving a self-signed certificate that doesn’t match any legitimate service.

09:00 – Correlation and scoping. Back to your logs. You search for any other internal hosts that connected to that IP or its associated domains in the past week. Two more workstations appear. All three are in the same department. The connection times cluster between 14:00 and 15:00 – consistent with a phishing email opened during the afternoon. You pull the DNS logs and find the initial domain resolution happened at 13:58, four minutes before the first outbound connection.

09:15 – Detection rule. You write a Sigma rule that detects outbound connections to the three overlapping IPs and the associated domains, with additional logic for the self-signed certificate fingerprint. Convert it to your SIEM’s query language. Deploy. Now if those indicators appear in any future traffic, you’ll know within minutes instead of discovering it during the next morning’s triage.

09:30 – Blocking. The three IPs go into your CrowdSec blocklist via the API, which propagates to your nginx bouncers and firewall rules within the sync interval. If you’re running CrowdSec’s community blocklist, this also benefits other CrowdSec users – crowdsourced defence working as intended.

09:45 – Documentation and sharing. You create a MISP event documenting the entire chain: the original ThreatFox indicators, your internal correlation findings, the GreyNoise and VirusTotal enrichment results, the Sigma rule, and the affected internal hosts (tagged as “internal only” – you don’t share those externally). Tag the event with the relevant ATT&CK techniques: T1566.001 (Spearphishing Attachment), T1071.001 (Web Protocols for C2). Publish to your MISP sharing community so other organisations in your sector get the same indicators with your added context.

10:00 – Incident handoff. The three affected workstations go to your incident response process – whether that’s TheHive, a ticketing system, or walking over to the finance department with a USB drive containing your forensic tools. The TI workflow’s job is done. It took 105 minutes from feed sync to documented, shared, blocked, and detected. That’s the process working.

Not every morning looks like this. Most days, the feed sync produces nothing that correlates with your logs, and triage takes fifteen minutes. That’s fine. The workflow exists for the days when it matters.

A Realistic Monthly Budget

Theory is fine. Numbers are better. Here’s what three budget tiers actually look like in practise.

$0/month – Full Open Source

If you have existing infrastructure – a spare machine, a home lab, even a reasonably powered laptop – you can run a functional TI programme at zero marginal cost. MISP on Docker, abuse.ch feeds (all free), AlienVault OTX integration, CyberChef for analysis, GreyNoise Community for IP context (50 searches/week), and Maltego CE for visual investigation. The limitation is infrastructure: if MISP is competing with other workloads on shared hardware, feed synchronisation and correlation slow down.

~$5/month – Dedicated VPS + Feeds

This is what we run. A Hetzner CX22 at approximately 4 euros per month provides 2 vCPUs, 4GB RAM, and 40GB SSD – dedicated to MISP with Docker. All the free feeds above, properly configured and synchronising on schedule. Total monthly cost under $5. It won’t handle OpenCTI alongside MISP, and you won’t be running heavy enrichment modules, but for operational IOC management serving a team of one to three analysts, it’s genuinely sufficient. Not a compromise – sufficient.

One note on Hetzner pricing: they’ve announced price increases of 30-37% taking effect from April 2026. The CX22 will move from approximately 3.79 euros to approximately 5.19 euros. Still cheap, but worth knowing if you’re planning ahead.

~$55/month – Add Enrichment

Everything above, plus Shodan Membership ($49 one-time, amortised to roughly $4/month over a year), a GreyNoise paid plan for operational IP enrichment beyond the 50/week free limit, and an upgrade to a CX32 VPS (approximately 6.80 euros per month, 3 vCPUs, 8GB RAM) for comfortable headroom running MISP with aggressive feed schedules and enrichment modules enabled. At this tier, you have a setup that genuinely rivals what many mid-sized organisations achieve with five-figure annual contracts.

Component	$0/mo	~$5/mo	~$55/mo
Platform	MISP (existing hardware)	MISP (Hetzner CX22)	MISP (Hetzner CX32)
Feeds	abuse.ch + OTX	abuse.ch + OTX	abuse.ch + OTX + GreyNoise paid
Enrichment	GreyNoise Community	GreyNoise Community	GreyNoise + Shodan
Analysis	CyberChef + Maltego CE	CyberChef + Maltego CE	CyberChef + Maltego CE
Detection	Manual YARA/Sigma	Manual YARA/Sigma	Manual YARA/Sigma
Total	$0	~$5/mo	~$55/mo

What you don’t need: Recorded Future ($100K+/year), Mandiant Intelligence (call for pricing – if you have to ask…), ThreatConnect Enterprise, Anomali ThreatStream. These platforms are exceptional. They’re also built for organisations with dedicated TI teams of five or more analysts and the processes to match. If you’re reading an article about budget threat intelligence, you aren’t the target customer, and that’s perfectly fine.

Building Your First Intelligence Requirement

Here’s the step most teams skip, and it’s the reason their feeds generate noise instead of intelligence: they never define what they actually need to know.

Priority Intelligence Requirements (PIRs) are the foundation of any intelligence programme, regardless of budget. A PIR is a question – not a topic, not a keyword, not a feed category. A question that, when answered, directly informs a security decision.

Good PIRs look like this:

• “What threat actors are actively targeting organisations in our sector and geography?”
• “What vulnerabilities affect the specific software versions deployed on our external-facing infrastructure?”
• “What initial access techniques are being used in intrusions against organisations of our size?”

Bad PIRs look like this: “APT groups,” “ransomware trends,” “zero-days.” Those are topics, not questions. They don’t tell you when you’ve found an answer or what decision the answer supports.

Keep it to three to five PIRs. The hierarchy runs from broad Intelligence Requirements down to PIRs (highest priority), then to Specific Intelligence Requirements (SIRs) that break each PIR into collectible, answerable sub-questions. A PIR asking about threat actors targeting your sector might generate SIRs like “Which ransomware groups have claimed victims in UK financial services in the past 90 days?” or “What phishing lure themes are associated with current campaigns against our sector?”

Once you have PIRs, your feeds and collection become purposeful. You’re not subscribing to everything – you’re subscribing to feeds that answer your questions. abuse.ch’s Feodo Tracker answers questions about banking trojan infrastructure. GreyNoise answers questions about whether scanning activity is benign or hostile. Your own DNS logs answer questions about what domains your users are resolving. Each feed maps to a PIR or it’s noise.

Two operational modes emerge naturally: standing queries (automated, feed-driven, continuously answering PIRs) and ad-hoc investigation (incident-triggered, manual deep dives when something demands attention). Most of your week should be standing queries. If you’re spending more than two hours per week manually correlating data that could be automated, it’s time to invest in paid enrichment or better MISP correlation rules.

One mistake we see repeatedly: skipping stakeholder consultation when defining requirements. The SOC has obvious intelligence needs. But product teams care about supply chain risk. Fraud teams care about credential markets. Legal and compliance care about regulatory threat landscapes. Each of these stakeholders introduces risk dimensions that a purely technical TI programme misses.

Common Mistakes That Kill Budget TI Programmes

Collecting everything, analysing nothing. This is the single most common failure mode. A modest MISP instance with 20 feeds enabled will generate thousands of new indicators daily. Without triage – confidence scoring, TTL management, relevance filtering – those indicators are just a very large, very noisy database. Feed fatigue is real. We’ve watched teams enable every available feed in their first week, get overwhelmed by the volume within a month, and quietly stop checking MISP by month three. Start with three to five feeds mapped to your PIRs. Add more only when you’re actually processing what you have.

Feeds without context. An IP blocklist without time-to-live values, confidence scores, or source attribution is noise pretending to be intelligence. When was the IP last observed? How confident is the source? Is it a C2 server, a scanning node, or a compromised host being used as a proxy? Without this metadata, you’re either blocking legitimate traffic or letting threats through because you can’t prioritise. MISP’s event-based model with attributes, tags, and taxonomies exists precisely to solve this. Use it.

Automating before understanding. The urge to build automated pipelines is strong, especially for technical teams. Resist it initially. Successful programmes start with use cases – “I need to know when a new CVE affects our Apache servers” – and build manual workflows first. Only when you understand the workflow well enough to specify its decision logic should you automate it. Premature automation bakes in assumptions you haven’t validated.

Treating TI as a product. Intelligence is a cyclical process: requirements, collection, processing, analysis, dissemination, and feedback. Each stage feeds the next. Feedback from consumers refines requirements. Requirements shape collection. When organisations treat TI as a product – a dashboard, a feed, a report – they freeze one stage and starve the others. The dashboard becomes a trophy that nobody updates. The feeds run on autopilot while requirements drift. Buy-in evaporates because the output stopped being relevant months ago.

Over-reliance on tactical intel. IOCs are useful. They’re also ephemeral. An attacker’s IP address changes. A C2 domain gets burned and replaced. File hashes shift with each recompile. If your entire TI programme is consuming and blocking IOCs, you’re perpetually reactive – always one step behind the attacker’s latest infrastructure. Strategic intelligence (understanding adversary motivation, capability, and intent) and operational intelligence (understanding adversary TTPs and campaign patterns) drive proactive defence. They tell you where to look before you have an IOC to search for.

No integration with security operations. Intelligence locked in a separate platform – accessed by a separate team, through a separate interface – adds to the operational workload instead of reducing it. If your MISP instance doesn’t feed your SIEM, if your enrichment data doesn’t appear in your EDR console, if your analysts have to context-switch between three platforms to triage a single alert, the intelligence programme is creating friction rather than removing it. Integration isn’t a nice-to-have. It’s the mechanism by which intelligence becomes operational.

---

Disclosure: This post may contain affiliate links. If you purchase through these links, we may earn a commission at no extra cost to you. See our Affiliate Disclosure for details.