Threat Intelligence: Teaching Your Platform to Recognise Bad Actors

An IP Address Means Nothing on Its Own

A log line lands in your pipeline: a server accepted an outbound connection to 185.220.101.47. On its own, that number is inert. It's not suspicious, it's not safe — it's just a destination. A human analyst who's seen it before might feel a prickle of recognition. Everyone else shrugs.

Threat intelligence is what closes that gap at machine speed. It's the module that turns an anonymous IP into a known ransomware command-and-control server, a hash into a known malware sample, a domain into a known phishing host. Without it, your platform is technically watching everything and understanding none of it — it can see the connection but has no idea the destination has been burning through victims for the past three weeks.

This is the third layer in an AI-native security platform, sitting between the log processing pipeline that normalises raw events and the detection engine that turns them into alerts. Get it right and every alert arrives pre-loaded with context. Get it wrong and you either drown in false positives or miss the one connection that mattered.

What Threat Intelligence Actually Is

Strip away the marketing and threat intelligence is a set of curated lists of things known to be bad, kept current by people and organisations who track attackers for a living. The industry term for an entry on one of those lists is an indicator of compromise, or IOC — an IP address, a domain, a file hash, a URL, an email sender — that has been observed in malicious activity.

You don't have to build these lists yourself, and you shouldn't try. A mature platform imports them from established feeds:

• CISA — advisories and known-exploited-vulnerability data from the US cyber agency.
• AlienVault OTX — a large community threat-sharing exchange.
• AbuseIPDB — crowd-reported IP addresses associated with abuse and attacks.
• Spamhaus — long-running block lists for spam and malware infrastructure.
• Emerging Threats — network signatures and IP reputation, widely used with intrusion detection.
• CVE feeds — the canonical catalogue of publicly disclosed software vulnerabilities.
• MITRE ATT&CK — a structured knowledge base of attacker tactics and techniques.
• Exploit DB — a repository of public exploit code, useful for knowing what's weaponised.

Some are free, some are paid, some are community-maintained. The engineering work isn't in any single feed — it's in ingesting all of them into one normalised store, keeping them fresh, and making a lookup fast enough to run against every event flowing through the platform.

The Enrichment Flow

Enrichment is the moment threat intelligence earns its place. Here's the shape of it, using the outbound connection from the opening.

A normalised event arrives from the processing layer: source host, destination IP 185.220.101.47, timestamp, port. Before the detection engine ever looks at it, the enrichment step asks a series of fast questions against the IOC store:

1. Is this IP in any reputation feed? A hit in AbuseIPDB or Spamhaus immediately raises its risk weight.
2. Is it associated with a known ransomware group's infrastructure? If threat intel ties it to a named campaign, the event stops being a curiosity.
3. Is it a known botnet node? Command-and-control traffic often lights up here.
4. Is it a known TOR exit node? Worth knowing — but, as we'll get to, not automatically damning.
5. Is it a known phishing or malware-hosting server? If so, an internal host reaching it is a strong signal something is already wrong.

The output isn't a yes/no verdict. It's context attached to the event: "destination flagged by two reputation feeds, associated with a known ransomware campaign, first reported eleven days ago." That enriched record is what moves downstream. The detection engine can now weight the event far more heavily, and when an alert fires, the investigation agent inherits all of that context for free rather than starting cold.

Managing Indicators of Compromise at Scale

The volume is what makes this hard. A single feed can carry hundreds of thousands of IOCs; run several dozen feeds and you're maintaining tens of millions of indicators, refreshed constantly, that you need to check against every relevant event in real time.

Three engineering problems follow from that.

The lookup has to be fast. If checking one IP against the IOC store takes 50 milliseconds, and you're processing tens of thousands of events a second, the enrichment step becomes the bottleneck for the entire platform. In practice this means holding hot indicators in an in-memory store (Redis is a common choice) with the full corpus behind it, and structuring lookups so a "not found" answer is as cheap as a "found" one.

Deduplication matters. The same malicious IP appears across a dozen feeds. You don't want a dozen records — you want one indicator with a list of which feeds reported it and when, because how many independent sources agree is itself a signal of confidence.

Every indicator needs metadata, not just a value. When it was first seen, when it was last confirmed, which feed reported it, what it's associated with, and a confidence score. Without that, you can't reason about staleness, and you can't explain to a downstream analyst why an event was flagged — which is the whole point of enrichment.

Freshness, Staleness, and the Quiet Failure

Threat intelligence has a short shelf life, and this is the part teams underestimate.

Attacker infrastructure is disposable. A ransomware group spins up a C2 server, uses it for a fortnight, and abandons it before it gets too hot. A phishing domain might live for 48 hours. This means intel goes stale in two directions, and both are dangerous.

Stale intel causes false negatives — the failure nobody notices. If your feeds haven't updated in a week, a brand-new malicious IP that first appeared yesterday simply isn't in your store. The connection sails through enrichment marked "unknown, no reputation data," the detection engine sees nothing to weight, and no alert fires. The platform looks calm precisely because it's blind. There's no error message for intelligence you never received.

The fix is unglamorous: feeds must be pulled on a schedule appropriate to how fast each one moves, ingestion failures must alert loudly, and the age of your intelligence should itself be a monitored metric. A dashboard tile reading "newest indicator: 9 days old" is a red flag, not a footnote.

The mirror problem is intel that should expire but doesn't. An IP that hosted malware last year may belong to an ordinary cloud tenant today. Indicators need an ageing policy — confidence that decays over time and eventually retires the entry — or you generate false positives against infrastructure that reformed months ago.

The False-Positive Problem: TOR Exit Nodes and Friends

Here's where naive threat intelligence quietly damages trust in the whole platform.

Consider TOR exit nodes. They are absolutely worth knowing about — traffic to or from one is worth a second look. But TOR is not malware. Plenty of entirely legitimate people use it: privacy-conscious researchers, journalists, employees in restrictive jurisdictions. If your platform treats "known TOR exit node" as equivalent to "known ransomware C2," you'll fire high-severity alerts every time someone browses your public site over TOR, and within a week your analysts will be muting the category wholesale — at which point you've trained your own team to ignore a genuine signal.

The same nuance applies broadly. A shared-hosting IP might carry one malicious site among thousands of innocent ones. A CDN address might appear on a block list because of a single abusive customer. Treating every IOC as a binary "malicious" flag is the fastest way to turn a useful platform into noise.

The discipline is to enrich with context and confidence, not verdicts. "This destination is a TOR exit node" is a fact you attach to the event. Whether that rises to an alert is a decision for the detection engine, weighed against everything else it knows — who the internal host is, what it was doing, whether the connection pattern is unusual. Threat intelligence should inform judgement, not replace it.

Mapping to MITRE ATT&CK

Reputation feeds tell you whether something is bad. MITRE ATT&CK helps explain what kind of bad — and that framing is disproportionately useful once an alert reaches a human.

ATT&CK is a structured catalogue of attacker tactics (the goal — say, Command and Control or Exfiltration) and techniques (the specific method within that goal). When enrichment maps an indicator or a detection to an ATT&CK technique, an alert stops reading like an isolated event and starts reading like a step in a recognisable playbook.

The difference in an analyst's experience is stark:

That last row is the real payoff. Once alerts carry ATT&CK context, the investigation agent can recognise a sequence — an attacker moving through stages — rather than treating each detection in isolation. It's the difference between noticing three unlocked doors and realising someone is walking through your building.

How Enrichment Feeds the Rest of the Platform

Threat intelligence is not a destination; it's a service the layers above depend on.

For the detection engine, enrichment is an input to scoring. A behavioural rule might notice an unusual outbound connection and assign it a low base score — until enrichment reveals the destination is a known C2 server, and the score jumps to critical. The same raw event produces a very different alert depending on what threat intelligence knew about it.

For the investigation agent, enrichment is pre-gathered evidence. When the agent assembles the story of an incident, it doesn't have to look up every IP and hash itself — the context is already attached. Its job shifts from collecting facts to reasoning over them, which is exactly where an AI agent adds value and exactly the kind of scoped, well-bounded tool design that keeps agent behaviour predictable and safe.

The through-line: good enrichment makes every layer above it smarter without those layers doing more work.

What Good Looks Like

A well-built threat intelligence module has a handful of recognisable properties:

• Multiple feeds, deduplicated into one store, with each indicator carrying its sources, timestamps, and a confidence score.
• Fast lookups that run against live traffic without becoming the pipeline's bottleneck.
• Freshness as a monitored metric — you know how old your newest and oldest intelligence is, and ingestion failures page someone.
• An ageing policy so stale indicators decay in confidence rather than lingering forever.
• Context, not verdicts — TOR exit nodes and shared hosts are labelled, not auto-condemned.
• ATT&CK mapping so alerts explain themselves in the language of attacker behaviour.
• Clean hand-off to detection and investigation, so enrichment happens once and benefits everything downstream.

Questions to Ask Before You Build

"How fresh is our intelligence, and how would we know if a feed stopped updating?" If nobody can answer, you have a false-negative risk you can't see. Freshness must be measured, not assumed.

"How do we avoid alerting on legitimate TOR or shared-hosting traffic?" The answer should be about confidence and context feeding the detection engine — not about matching an IOC and firing an alert.

"What happens when the same indicator appears in five feeds?" You want one deduplicated record with corroboration counted, not five duplicate alerts.

"Do our alerts carry MITRE ATT&CK context?" Without it, analysts see isolated events instead of attack sequences, and investigations take far longer.

What It Costs and How Long It Takes

Honestly, a working threat intelligence module is one of the more tractable pieces of a security platform — the feeds already exist, and the hard problems are engineering ones you can reason about rather than open research questions. A first version that ingests a handful of reputable feeds, deduplicates into a fast IOC store, and enriches live events is typically a four-to-six-week effort for a small team, assuming the log processing pipeline it depends on is already in place.

The cost lives in the long tail, not the build. Some high-quality feeds carry commercial licensing. Keeping intelligence fresh, tuning confidence and ageing so you neither drown in false positives nor go quietly blind, and expanding ATT&CK coverage are ongoing operational work rather than one-off tasks. Budget for the module as something you run, not something you ship and forget — stale threat intelligence is worse than useless, because it looks like coverage while providing none.

Related guides

• Building an AI-native security operations platform: the complete architecture
• The log processing pipeline that feeds threat intelligence
• Building the detection engine
• The AI investigation agent that inherits your enrichment
• AI agent security: what business owners need to know
• Our AI development services

We Build Enrichment That Actually Enriches

Threat intelligence is deceptively easy to do badly — plug in a few feeds, match some IPs, call it done — and the failure mode is silent. We build it the way it needs to be built: multiple feeds deduplicated into a fast store, freshness monitored as a first-class metric, context and confidence rather than blunt verdicts, and ATT&CK mapping so every alert explains itself. And we build it to hand off cleanly to the detection and investigation layers that depend on it.

If you're weighing how to add real threat intelligence to a security product, or wondering why your current alerts arrive with no context, we're happy to walk through the specifics for your platform.

Talk to us about your platform — no commitment, just a conversation.

Frequently Asked Questions

What is an indicator of compromise (IOC)?

An IOC is a specific, observable piece of data associated with malicious activity — an IP address, a domain, a file hash, a URL, or an email sender that has been seen in attacks. Threat intelligence feeds are essentially large, curated lists of IOCs. Your platform imports them into one store and checks incoming events against them, so an otherwise-anonymous connection can be recognised as reaching known-bad infrastructure. The value of an IOC depends heavily on its freshness and the confidence attached to it, not just its presence on a list.

Which threat intelligence feeds should a platform use?

A sensible starting set mixes free and community sources — CISA advisories, AlienVault OTX, AbuseIPDB, Spamhaus, and Emerging Threats for reputation data; CVE feeds and Exploit DB for vulnerability and exploit awareness; and MITRE ATT&CK for behavioural context. There's no single correct list; the engineering challenge isn't picking feeds but ingesting several into one deduplicated, well-scored store and keeping them fresh. Commercial feeds add coverage and speed but come with licensing costs, so most platforms start with reputable free sources and add paid ones as the need becomes clear.

Why does stale threat intelligence cause false negatives?

Attacker infrastructure is disposable — a command-and-control server or phishing domain may only live for days before being abandoned. If your feeds haven't refreshed recently, a brand-new malicious address simply won't be in your store, so enrichment marks the connection "unknown," the detection engine finds nothing to weight, and no alert fires. The platform looks calm because it's blind, and there's no error for intelligence you never received. That's why freshness has to be a monitored metric with loud alerts on ingestion failure, not something assumed to be working.

Are TOR exit nodes always malicious?

No, and treating them as if they were is a common way to flood a platform with false positives. TOR is used by plenty of legitimate people — researchers, journalists, employees in restrictive jurisdictions — as well as by attackers. The right approach is to enrich an event with the fact that a destination or source is a known TOR exit node, then let the detection engine weigh that against everything else it knows before deciding whether to alert. Threat intelligence should supply context and confidence, not deliver binary verdicts that fire alerts on their own.

What does MITRE ATT&CK add to threat intelligence?

Reputation feeds tell you whether something is bad; ATT&CK helps explain what kind of bad. It's a structured catalogue of attacker tactics and techniques, so when enrichment maps an indicator or detection to an ATT&CK technique, an alert reads as a recognisable step in an attack rather than an isolated event. The biggest payoff is sequence recognition — several alerts mapped to consecutive tactics suggest one campaign progressing through stages, which lets the investigation agent connect events that would otherwise look unrelated.

How does threat intelligence connect to the rest of the security platform?

It sits between log processing and detection, enriching every normalised event before an alert can fire. For the detection engine, enrichment is a scoring input — the same raw event becomes low or critical severity depending on what intelligence knew about the destination. For the investigation agent, enrichment is pre-gathered evidence, so the agent reasons over context rather than collecting it from scratch. Done well, threat intelligence makes every layer above it smarter without those layers doing extra work; done badly, it silently starves them of the context they were built to rely on.