Threat Hunting

What Is Cyber Threat Intelligence? Types & Lifecycle

14 min read·Updated June 2026·blue team securitythreat intelligenceSOCCyber Threat intelligenceCCDL1 RelevantCCDL2 Relevant

Two reports land on a SOC analyst's desk, both about the same IP address.

The first says: 198.51.100.23: malicious, block it. That is the whole report. A row in a feed.

The second says: that address is a command-and-control server for a ransomware crew that has spent the last month breaking into healthcare organizations through an unpatched VPN appliance, the same appliance model running at your edge. They exploit the appliance (MITRE ATT&CK T1190), steal credentials, and encrypt within days. Here is the detection to deploy, the CVE to patch tonight, and three more addresses from the same campaign.

The first is data. The second is intelligence. Cyber threat intelligence is the work that turns one into the other.

This guide covers what cyber threat intelligence is and is not, why it matters, the three types and who consumes each, the intelligence lifecycle with a worked example, where intelligence comes from and how to grade it, the frameworks that structure it, how it is shared, how it differs from hunting and detection, the pitfalls that waste it, and how to build the skill. It is written for blue teamers: SOC analysts, threat hunters, and DFIR practitioners who have to act on the output.

What is cyber threat intelligence?

Cyber threat intelligence (CTI) is the collection, processing, and analysis of data about adversaries, turned into something a defender can act on. It answers three questions a raw indicator never does: who is attacking, why, and how.

The clearest way to define it is the climb from data to intelligence:

Data is a raw observation. An IP address, a file hash, a domain. True or false, but on its own it tells you nothing about what to do.
Information is data with some context. "This hash belongs to a piece of malware." Useful, but still not a decision.
Intelligence is information analyzed against a question that matters to you, with a recommendation attached. "This malware is used by an actor targeting your sector, it arrives through the appliance you run, and here is the control that stops it."

Gartner's widely cited definition makes the same point: threat intelligence is "evidence-based knowledge, including context, mechanisms, indicators, implications and actionable advice, about an existing or emerging menace." The load-bearing words are evidence-based and actionable. A feed of indicators with no analysis and no recommendation is data wearing an intelligence label.

The test for whether something is intelligence is simple: does it change a decision? If a report does not tell someone what to patch, hunt, block, or brief the board on, it has not finished the trip from data to intelligence.

Why cyber threat intelligence matters

Most security tooling is reactive by design. A detection rule fires on a pattern someone already knew was bad. Threat intelligence is how a defender gets ahead of that, by learning how adversaries operate before they operate on you.

The threat picture moves fast enough that last year's assumptions mislead. IBM's X-Force Threat Intelligence Index 2026 found that exploitation of public-facing applications became the top initial-access vector at 40% of incidents, up 44% year over year, overtaking stolen credentials at 32%. A defense built around the previous year's "identity is the front door" framing would be aiming at the wrong door. Intelligence is what keeps the aim current.

Used well, it does three things:

Prioritizes. Not every threat is your threat. Intelligence tells you which actors target your sector, your geography, and your technology, so finite analyst hours go to the campaigns that can actually reach you.
Anticipates. Knowing an actor's playbook lets you deploy a detection for step three before they take step one. That is the difference between watching an intrusion and interrupting it.
Informs the spend. Strategic intelligence gives a CISO evidence for where to invest, in language a board understands, instead of buying controls by vendor fashion.

Most organizations only scratch the surface. They wire a feed into the firewall and the SIEM, block what it flags, and call it a CTI program. That captures the cheapest, shortest-lived slice of intelligence and none of the rest.

The three types of threat intelligence

Cyber threat intelligence is usually split into three types, separated by who reads it, how long it stays useful, and what decision it drives. The mistake is treating them as a hierarchy. They are different products for different consumers.

Type	Consumer	Time horizon	Form	Example
Tactical	SOC, detection engineering, security tools	Hours to weeks	IOCs, machine-readable feeds	"Block these C2 IPs and hashes from campaign X"
Operational	Threat hunters, IR, detection engineers	Weeks to months	TTPs, campaign analysis, ATT&CK mappings	"This actor exploits T1190, then encrypts within days"
Strategic	CISO, executives, the board	Months to years	Reports, risk briefings, trend analysis	"Ransomware against our sector is rising; here is the exposure"

Tactical intelligence is the indicators: malicious IPs, domains, URLs, file hashes. It is machine-readable, automatable, and the easiest to consume, which is why most programs start and stop here. It is also the most perishable. Infrastructure rotates in days, so a tactical feed is only as good as it is fresh, and it is prone to false positives when an indicator gets reused or sinkholed. It tells you what to block, not who or why.

Operational intelligence is the layer above: the tactics, techniques, and procedures (TTPs) behind a campaign, the attribution, the motive. It does not automate cleanly because producing it takes human analysis, and that is the point. It outlives tactical intelligence because behavior changes slower than infrastructure. This is the tier that feeds threat hunting and detection engineering: "this group uses valid accounts and living-off-the-land binaries to move laterally" survives long after their current IP set is dead.

Strategic intelligence is the high-level view: which threats are rising, how geopolitics and sector trends shift targeting, where the organization's risk actually sits. It is written for decision-makers, usually as reports rather than data, and it is the hardest to produce because it requires both security and business context. Done right, it is what turns a security budget from guesswork into an argument.

The threat intelligence lifecycle

Intelligence is produced, not found. The threat intelligence lifecycle is the process that takes a question and returns an answer someone can act on. It is commonly modeled in six phases, and it is a loop: the last phase feeds the first.

1. Direction

Set the requirements. Intelligence with no question behind it is just collection for its own sake. This phase defines the Priority Intelligence Requirements (PIRs): the specific questions stakeholders need answered. A good PIR is narrow enough to collect against. "Tell us about ransomware" is not a PIR. "Are ransomware actors targeting our healthcare sector through internet-facing VPN appliances?" is.

2. Collection

Gather data against the requirements: vendor feeds, OSINT, dark web forums, ISAC sharing, and your own internal telemetry. Collection driven by a PIR stays focused. Collection without one becomes hoarding.

3. Processing

Raw collection is not usable yet. Processing normalizes it: deduplicate indicators, parse a STIX bundle, translate a foreign-language forum post, enrich a hash with sandbox results, strip the noise. Most of the volume dies here, and that is healthy.

4. Analysis

This is where information becomes intelligence. The analyst correlates processed data against the requirement, tests hypotheses, maps behavior to a framework, and produces a judgment with a recommendation. Analysis is also where structured technique and bias awareness matter, because a confident wrong answer is worse than no answer.

5. Dissemination

Deliver the finished intelligence to whoever needs it, in the form they can use. The same finding splits by audience: tactical IOCs pushed to the SIEM and EDR, an operational detection handed to detection engineering, a one-page strategic brief to the CISO. A brilliant analysis nobody reads changed no decision.

6. Feedback

Ask the consumers whether it helped. Did the detection fire? Was the brief actionable? Were the indicators noisy? Feedback resets the requirements and starts the loop again. This is the phase most programs skip, and skipping it is why so many produce intelligence nobody uses.

A worked example. Start with the PIR above: ransomware actors hitting healthcare through VPN appliances. Collection pulls a Health-ISAC advisory, a commercial feed, and your own edge logs. Processing dedupes the indicators and parses the advisory's STIX bundle. Analysis confirms a named actor is exploiting a specific appliance CVE, maps the chain to ATT&CK (Exploit Public-Facing Application T1190 through Data Encrypted for Impact T1486), and judges the threat as live for your environment. Dissemination sends the IOCs to the SOC, the T1190 detection to engineering, and a patch-tonight recommendation to the CISO. Feedback comes back a week later: the detection fired on a real probe, with two false positives to tune. The loop turns.

Where threat intelligence comes from

Collection draws from several source types, each with a different trade-off between coverage, cost, and trust.

Open source (OSINT). Vendor blogs, security researchers, news, public reports. Free and broad, but unstructured and slow to verify.
Commercial feeds. Paid, curated, structured, often near real-time. Better signal, but you are trusting the vendor's collection and judgment, and quality varies widely.
Community and ISAC sharing. Sector-specific groups (Financial Services ISAC, Health-ISAC, and others) trade intelligence among members who share a threat profile. High relevance because the other members look like you.
Internal telemetry. Your own logs, alerts, and past incidents. The most relevant source you have, and the most underused. Your last breach is intelligence about your next one.
Closed sources. Dark web forums and marketplaces, HUMINT, paste sites. High value, high effort, and easy to get wrong without tradecraft.

Grading what you collect

Not all sources are equally trustworthy, and good analysts say so explicitly. The Admiralty Code, the NATO grading system codified in AJP-2.1, scores every piece of intelligence on two axes: source reliability from A (completely reliable) to F (cannot be judged), and information credibility from 1 (confirmed by other sources) to 6 (cannot be judged). A report graded "B2" reads as a usually-reliable source providing probably-true information. The grade keeps a single anonymous forum post from being treated like a confirmed vendor report, and forces the analyst to separate who said it from how likely it is true. SANS teaches the same system for CTI for exactly this reason.

The frameworks that structure intelligence

Three frameworks give analysts a shared language for describing adversaries. They are complementary, not competing.

Framework	What it models	Use in CTI
Cyber Kill Chain	The seven linear stages of an intrusion	Locate where an attack is; decide where to break it
Diamond Model	Each event as adversary, capability, infrastructure, victim	Pivot between events; cluster them into campaigns
MITRE ATT&CK	Adversary tactics and techniques seen in the wild	The common vocabulary for TTPs; tag and share behavior

The Cyber Kill Chain, introduced by Lockheed Martin in 2011, breaks an intrusion into seven stages: reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on objectives. Its value to intelligence is the framing that an attacker has to complete every stage while a defender only has to break one. It maps where a campaign is and which stage your controls should have caught.

The Diamond Model, published by Caltagirone, Pendergast, and Betz in 2013, describes every intrusion event as four linked features: adversary, capability, infrastructure, and victim. Its power is the pivot. Knowing the infrastructure leads you to other victims; knowing the capability leads you to other infrastructure. That pivoting is how individual events get clustered into a tracked campaign and, eventually, attribution.

MITRE ATT&CK is the knowledge base of adversary tactics and techniques observed in real intrusions, each with an ID like T1190. It is less a model of an attack than a shared dictionary, and that is exactly why it matters for intelligence: when one team says an actor uses T1486, every other team knows precisely what they mean. ATT&CK is what makes operational intelligence portable between organizations.

How threat intelligence gets shared

Intelligence is more valuable shared than hoarded, which only works if everyone speaks the same format. Two open standards from the OASIS Cyber Threat Intelligence committee carry most of the structured sharing:

STIX (Structured Threat Information Expression) is the language. It represents indicators, malware, attack patterns, threat actors, and the relationships between them as structured objects, so a campaign can be described once and read by any tool. The current version is STIX 2.1.
TAXII (Trusted Automated Exchange of Intelligence Information) is the transport. It is the protocol that moves STIX data between producers and consumers over the wire, currently TAXII 2.1.

In practice, an ISAC or a vendor publishes a STIX bundle, a TAXII feed delivers it, and a threat intelligence platform (TIP) ingests it, deduplicates against what it already holds, and pushes the relevant indicators into the SIEM, EDR, and firewall. That last mile, from a shared bundle to a live detection, is where a CTI program earns its keep.

Threat intelligence vs. hunting, detection, and DFIR

These four functions sit next to each other and feed each other, so the boundaries blur. The clean split:

Function	Question it answers	Driven by	Output
Threat intelligence	Who is attacking whom, and how?	External and internal research	Finished intelligence: IOCs, TTPs, reports
Threat hunting	Is something here we have not detected?	A hypothesis, often from intel	Findings and new detections
Threat detection	Did something known-bad just happen?	Rules and models	Alerts
Incident response	What happened, and how do we recover?	A confirmed incident	Containment, root cause, lessons

Intelligence is the upstream function. It supplies the adversary behaviors a hunter turns into hypotheses, the patterns a detection engineer turns into rules, and the actor context that helps an IR team scope a breach. In return, every hunt and every incident produces internal telemetry that feeds back into intelligence. CTI is not a separate silo; it is the connective tissue that makes the other three sharper.

Common CTI pitfalls

Most failed threat intelligence programs fail the same handful of ways:

Feed hoarding. Buying more feeds than the team can process, with no requirements to filter them. Volume is not coverage. More indicators with no PIR behind them is just a bigger pile.
IOC tunnel vision. Living entirely at the tactical layer, blocking hashes and IPs, and never producing the operational and strategic intelligence that actually changes posture.
Intelligence that never reaches a detection. Analysis that ends in a PDF nobody operationalizes. If a finding does not become a rule, a hunt, or a decision, the lifecycle stopped at dissemination.
No feedback loop. Producing intelligence and never asking whether it helped. Without feedback, the program optimizes for output volume instead of decisions changed.
Confusing data with intelligence. Treating a raw feed as a finished product. The whole discipline is the analysis between the two, and skipping it just automates the delivery of noise.

Building a threat intelligence capability

A CTI capability rests on the same three things as most blue-team disciplines, and tooling buys only one of them.

Requirements. Start with the questions, not the feeds. A handful of sharp PIRs tied to your actual sector and tech stack will out-perform a six-figure feed subscription with no direction behind it.

Analysts. Someone has to do the analysis that turns information into intelligence: correlate sources, grade reliability, map to ATT&CK, write the recommendation. This is the binding constraint, and it is a learned skill, not a product feature.

Integration. The pipeline from a shared bundle to a live detection: a place to store and deduplicate intelligence, and the connections that push it into the SIEM, EDR, and the hunting workflow. Intelligence that cannot reach the tools changes nothing.