Cyber Threat Intelligence (CTI)

Evidence-based knowledge about existing or emerging threats — actors, capabilities, infrastructure, and intent — that supports a specific decision. Intelligence is not raw data; it is data that has been collected, evaluated, and interpreted for a consumer to act on. A firewall block list of IP addresses is data. A profile explaining who is behind those addresses, what they are after, what they have already compromised elsewhere, and how they are likely to adapt once blocked is intelligence.

That distinction is operational, not just semantic. The most common failure mode in threat-intel consumption is treating a report as a list of indicators to push into a blocklist and close the ticket — what "Why IOC-Only Detection Fails" walks through in detail. IP addresses rotate, domains age out, and hashes change with a recompile or a packer swap; an actor who has been operating for more than a week has almost certainly already planned around exactly that kind of blocking. CTI done properly asks a harder question than "what do we block" — it asks what this actor is likely to do next, and how you would know if they were already inside your environment — which is why mature programs build detection in layers, from atomic indicator rules up through TTP-based and anomaly detection, instead of stopping at IOC matching.

That "decision support" framing is also why CTI work has to be reviewable, not merely informative: every claim should trace back to sourcing, carry an explicit reliability rating, and keep fact separated from analytic judgment. The CTI Analyst Field Manual lays out that full operating model end to end — collection requirements, evidence handling, analytic discipline, attribution, infrastructure pivoting, actor research, and the handoff into detection engineering — and CTI as a Code shows the same discipline applied as a version-controlled, repeatable methodology instead of one-off research notes, with a worked reactive-investigation case study showing what that looks like against a real incident.

AdversaryGraph is this whole workflow built as a self-hosted platform rather than a manual process: report ingestion, IOC enrichment, ATT&CK mapping, actor tracking, and detection handoff in one place. If you want to see the technique and actor vocabulary that underpins all of it without installing anything, Threat Matrix is the free public ATT&CK Navigator-style workspace connected to it.

Further reading on 1200km: CTI Analyst Field Manual · From Threat Intelligence to Detection · CTI as a Code — Methodology · CTI as a Code — LifeTech Pharma Case Study · AdversaryGraph platform · Threat Matrix · More CTI research on 1200km

Data is a raw, unprocessed observation: a log line, a hash, an IP address someone saw once. Information is data organized into context — a list of IPs grouped under "seen in this campaign." Intelligence is information analyzed against a specific requirement to produce an assessment a decision-maker can act on. The step that actually matters is the last one, and it is the one most self-taught analysts skip: turning a pile of correlated observations into a claim you would defend under questioning.

That defensibility comes from tradecraft most people never see written down. The CTI Analyst Field Manual builds it from three separable layers: evidence labels that keep an observed fact from quietly turning into an assumption as it gets passed around; source reliability, graded on the classic Admiralty scale — reliability A through F for the source itself, credibility 1 through 6 for the specific information — so a rating like "B2" means something consistent across analysts instead of a gut feeling; and confidence language, where words like "likely" or "almost certainly" map to a defined probability range instead of decorating a sentence. The manual is explicit that these ratings are review prompts, not mathematical truth — they exist to force the question "why do I believe this," not to launder a guess into a number.

The manual draws one more line that is easy to blur under deadline pressure: finished intelligence versus research notes. Research notes are where an analyst thinks out loud — half- confirmed leads, open questions, dead ends. Finished intelligence is what actually gets handed to a consumer, and it has to survive contact with someone who was not in the room while it was produced. If you cannot tell which one a document is, neither can the person reading it. The companion piece, Applying Sherman Kent's Analytic Discipline to CTI, goes deeper on the estimative-language side of this — including four worked "bad example, then corrected" pairs that show exactly how vague hedging gets rewritten into a defensible claim.

Further reading on 1200km: CTI Analyst Field Manual · Applying Sherman Kent's Analytic Discipline to CTI

A threat is a potential cause of harm — an actor or an event. A vulnerability is a weakness that could be exploited. Risk is the likelihood and impact of a threat actually exploiting that vulnerability against a specific asset you own. Said as one sentence, that sounds obvious. Said as a scanner output with 400 "Critical" findings and one Tuesday to triage them, it is the difference between a defensible prioritization and a wall of red numbers nobody trusts.

CVSS v4.0: The Practical Field Guide for Vulnerability Management is built almost entirely around this triad, and its central lesson is that a single CVSS score conflates all three layers into one number and then everyone acts surprised when prioritizing by that number alone goes wrong. The guide walks through a scoring lifecycle that keeps the layers separate instead: CVSS-B (Base) scores the vulnerability in isolation — how bad this flaw is in the abstract, independent of whether anyone is using it. CVSS-BT (Base + Threat) folds in whether it is actually being exploited in the wild, using feeds like CISA's KEV catalog and EPSS probability scores — that is the actor-driven "threat" layer arriving on top of the raw vulnerability. CVSS-BTE (Base + Threat + Environmental) finally asks the risk question: given this vulnerability, and given that it is being exploited, what does that actually mean for this asset in this environment? A critical flaw in an internet-facing system with real user data is not the same risk as the identical flaw on an air-gapped lab machine, even though both start from the same Base score.

The article's worked examples make the gap concrete rather than theoretical: Log4Shell's score moving as exploitation evidence accumulated over 72 hours, and one firmware assessment where eighteen findings scored "Critical" on Base alone collapsed to Medium once environmental context was actually applied. That is the threat/vulnerability/risk distinction doing real prioritization work, not just vocabulary.

Further reading on 1200km: CVSS v4.0: The Practical Field Guide for Vulnerability Management

An IOC is an observable artifact — a hash, an IP address, a domain, a mutex, or a registry key — assessed as associated with malicious activity. It may support prevention, detection, scoping, or retrospective investigation, but it does not prove compromise by itself. Many IOCs are easy to collect and share, and static values can be inexpensive for an adversary to replace after disclosure.

The Pyramid of Pain, covered in detail in the CTI Analyst Field Manual, puts hash values and IP addresses at the bottom of the pyramid for exactly this reason: they are the easiest thing for an adversary to change and cost them almost nothing to rotate. That does not make IOCs useless — the manual is explicit that they are the right tool for triage, scoping, and retroactive search ("has this hash ever touched our environment") — it means they are the wrong tool for durable detection strategy. Building a program around IOC feeds alone means you are always reacting to yesterday's infrastructure, which is precisely the failure mode "Why IOC-Only Detection Fails" walks through: by the time a public report lists an IP or hash, an adversary who has been operating for more than a week has almost certainly already burned it.

This is also why IOC enrichment is a distinct workflow step in its own right, not a side effect of collection — AdversaryGraph's IOC Library exists specifically to attach first/last-seen dates, confidence, provenance, and related-campaign context to a raw indicator before anyone acts on it, rather than trusting the artifact on its own. The single-IOC investigation guide shows that workflow step by step.

Further reading on 1200km: CTI Analyst Field Manual — Pyramid of Pain · From Threat Intelligence to Detection · AdversaryGraph: check one IOC · Build an IOC enrichment pipeline

An IOA is a behavior or sequence assessed as consistent with attack activity, independent of one static artifact — for example, "an Office process spawns a script interpreter, which then makes an outbound connection to a newly registered domain." It may reveal preparation, attempted execution, or activity in progress; like any analytic signal, it requires context and validation. No known hash is required because the pattern is the indicator.

This is the upper end of the same Pyramid of Pain: tools, TTPs, and behaviors sit at the top precisely because they are what an adversary can least afford to change. Swapping a hash costs an adversary a recompile. Swapping the underlying tradecraft — the tooling, the sequencing, the operational habits — costs them retraining, retooling, and risk. That is what makes IOA-driven detection durable in a way IOC-driven detection structurally cannot be, and it is the same principle behind the layered detection model in From Threat Intelligence to Detection: atomic IOC rules at the bottom for triage, behavioral and TTP-based rules layered above them for anything that actually has to hold up over time. The TTP module right after this one is where that behavior actually gets named using a shared vocabulary — ATT&CK.

Further reading on 1200km: CTI Analyst Field Manual — Pyramid of Pain · From Threat Intelligence to Detection

TTPs are the "how" of an adversary, described at three levels of resolution. A tactic is the goal, not a step — "why" the adversary is doing something (e.g. Credential Access, Persistence). A technique is the specific method used to accomplish that goal. A procedure is the exact implementation a given actor uses — the specific tool, the specific command line, the specific order of operations.

ATT&CK as a Working Tool makes a point that trips up a lot of newcomers to the framework: ATT&CK's Enterprise tactics are adversary goals, not a linear kill-chain sequence — an intrusion does not march through them in order, and an actor can revisit the same tactic repeatedly. Techniques sit below tactics as the "core analytical unit" of the framework: when a CTI analyst says "map this behavior to ATT&CK," they mean identifying which techniques were observed. T1003 — OS Credential Dumping is a good worked example of why the framework then needed sub-techniques: T1003 alone is too broad to drive a specific detection, but splitting it into T1003.001 (LSASS Memory), extracted with tools like Mimikatz's sekurlsa::logonpasswords or ProcDump, versus T1003.003 (NTDS), extracted with ntdsutil or secretsdump, gives each variant a distinct, buildable detection profile — which is exactly the procedure layer of TTPs made concrete.

This is also the vocabulary that makes IOA-style behavioral detection legible across a team: "TTP-based rule" and "T1003.001" mean the same specific thing to a CTI analyst, a detection engineer, and a threat hunter, which is the entire point of a shared framework instead of prose descriptions that drift between reports. You can browse the live technique page for that exact example — T1003.001 — LSASS Memory — on Threat Matrix, this site's free public ATT&CK workspace, or map it against actor coverage and detection backlog directly inside AdversaryGraph.

Further reading on 1200km: ATT&CK as a Working Tool: Theory and Hands-On Practical Usage · Tools by MITRE ATT&CK Guide (Library) · T1003.001 on Threat Matrix · AdversaryGraph platform

A threat actor is an individual or group conducting malicious activity. A threat group is a tracked cluster of activity attributed, with varying confidence, to a common actor — "cluster" is the operative word, because what analysts actually observe is correlated behavior, not a verified identity. A campaign is a bounded set of operations sharing goals, timeframe, or infrastructure, which may or may not map cleanly onto a single group.

Attribution Methodology: How to Build, Defend, and Challenge a Threat Actor Attribution treats this distinction as load-bearing rather than semantic, separating cluster-level attribution (this set of activity is internally consistent and probably one actor) from incident-level attribution (this specific intrusion was that actor) — the first is usually far more defensible than the second. It ranks evidence for making either claim from weakest to strongest: IOC overlap is the weakest signal (too easy to share, reuse, or plant), infrastructure reuse is stronger but still explainable by shared tooling or resold access, TTP consistency is the real behavioral fingerprint, and operator mistakes — a reused personal email, a misconfigured VPN leaking a real source IP — are the strongest evidence of all, precisely because they are the hardest for an adversary to fake or avoid. The same guide devotes a full worked exercise to attributing APT29 / Cozy Bear / SVR end to end using exactly this evidence ladder.

None of this is theoretical on this site — the CTI research case studies on Handala Hack Group, Sandworm / APT44, and MuddyWater / Seedworm are exactly this kind of actor and group tracking applied to real, currently active clusters — a good next stop once the methodology above makes sense on paper.

Both groups have live profile pages on Threat Matrix — Sandworm Team (G0034) and MuddyWater (G0069) — showing exactly how a tracked cluster's techniques accumulate into a profile over time. AdversaryGraph takes that further with sector-aware relevance scoring and campaign comparison against your own environment.

Further reading on 1200km: Attribution Methodology · CTI Research: Handala Hack Group · CTI Research: Sandworm / APT44 · CTI Research: MuddyWater / Seedworm · Sandworm on Threat Matrix · AdversaryGraph platform

The repeatable production process — Direction, Collection, Processing, Analysis & Production, Dissemination, Feedback, and Refinement — that turns a stakeholder question into a usable product. It matters because threat reporting is noisy by default: without a cycle, analysts collect whatever looks interesting and go searching for a use case afterward. With one, every piece of collection traces back to a requirement, and every finished product traces forward to the decision it is meant to support.

The CTI Analyst Field Manual frames the test plainly: a CTI team should be able to trace a finished product backward to the requirement that caused it. If it can't, the product may still be useful research, but it isn't finished intelligence. The manual's most common failure modes are worth internalizing early — starting with sources instead of requirements, treating collection as the whole job, publishing before source reliability and contradictions are processed, and sending the same product to executives, SOC analysts, and detection engineers as if they needed the same thing. Its worked mini-case is a good template for what the cycle looks like end to end: a SOC lead asks whether new reporting on an actor should change monitoring, and the cycle turns that vague prompt into direction (do the actor's behaviors intersect our telemetry?), collection (public reporting plus existing telemetry inventory), processing (extract behaviors, not just IOCs), analysis (which behaviors are huntable with current logs), dissemination (a detection backlog item and a telemetry gap note), and feedback (did the hunt actually produce results).

At larger scale, the cycle stops being a diagram and becomes a real delivery pipeline — the Customer-Driven AI CTI Project Template runs it as a full fifteen-phase engagement, from a Phase 0 project charter through requirements definition, collection, detection engineering, pilot deployment, and a closing Phase 14 continuous-improvement loop — direction and feedback made explicit as named phases with their own deliverables rather than implied steps. AdversaryGraph operationalizes the same cycle as one connected platform workflow instead of a chain of disconnected tools and handoffs.

Further reading on 1200km: CTI Analyst Field Manual · Customer-Driven AI CTI Project Template — Phase-by-Phase Execution · AdversaryGraph platform

A PIR is the specific, stakeholder-defined question that drives what a CTI team collects and analyzes — for example, "is our sector being targeted by ransomware affiliates this quarter?" PIRs sit at the top of a small hierarchy: a PIR is the high-level question tied to a decision, a Specific Intelligence Requirement (SIR) breaks that question into answerable sub-questions, and an Essential Element of Information (EEI) defines the concrete, collectible information needed to answer a SIR.

The CTI Analyst Field Manual makes the most common mistake concrete with a single contrast: "MuddyWater" is a topic, not a requirement. "Which MuddyWater behaviors reported since 2024 are observable with our endpoint and identity telemetry?" is close to an actual PIR. The manual's fully worked example decomposes a real decision — should the SOC prioritize a 30-day hunt for remote-management-tool abuse — into a PIR ("which public CTI reporting since 2024 describes adversary abuse of RMM tools relevant to our endpoint estate?"), two SIRs (which actors are reported using RMM tools after initial access; can our telemetry actually observe that behavior), and EEIs concrete enough to drive real collection: tool names, initial access method, observed process behavior, required telemetry, and source reliability for each claim.

The Customer-Driven AI CTI Project Template treats this as important enough to be its own phase — Phase 1 is Customer Decision and PIR/SIR Definition, run before any collection starts — and its companion Foundations piece covers the governance and role definitions that make a PIR someone's actual, named responsibility instead of an orphaned question nobody owns.

Further reading on 1200km: CTI Analyst Field Manual — PIR, SIR, and EEI · Customer-Driven AI CTI Project Template — Phase 1 · Customer-Driven AI CTI Project Template — Foundations

High-level, non-technical intelligence for executives — trends, geopolitical drivers, and business risk — usually with a long time horizon and framed in decision language rather than activity language. The question a strategic product answers isn't "what did the SOC do this month," it's "what should leadership decide, and why."

The Customer-Driven AI CTI Project Template's Phase 13 makes that discipline explicit with a real Executive Report Template: reporting period, top customer decisions supported, key judgments, threat scenarios prioritized, business risks requiring a decision, and what happens in the next 30 days — deliberately excluding the operational noise (individual alerts, raw hunt counts) that belongs one level down. It also tracks detection work-in-progress as its own metric specifically so a strategic report doesn't overstate readiness: work at DRL 2–6 (drafted through preview) is explicitly barred from being cited as "coverage," which only starts at DRL 7 and above. The CTI Analyst Field Manual gives the same idea a one-line test: a board-level risk note, a SOC hunt hypothesis, a detection backlog item, an actor profile, and an infrastructure pivot log are all legitimate CTI outputs — the category matters less than whether each one is actually fit for the consumer reading it.

Further reading on 1200km: Customer-Driven AI CTI Project Template — Phase 13 · CTI Analyst Field Manual

Intelligence about specific campaigns, operations, targeting, and near-term adversary activity, used to anticipate and prepare for a particular threat — one level more concrete than strategic trend-watching, one level less granular than the individual technical artifacts a detection engineer works with. This is the altitude where a tracked campaign becomes the unit of analysis: not "ransomware is a growing risk" (strategic), and not "block this specific hash" (technical), but "this campaign is currently active against our sector and is likely to reach us within weeks."

This is also where the evidence discipline from attribution methodology pays off directly: an operational assessment is only as good as the cluster-level confidence behind it, which is why the Attribution Methodology guide's cluster-versus-incident distinction matters here well beyond pure attribution work — an operational warning built on a weakly-clustered campaign is a warning built on sand.

Further reading on 1200km: Attribution Methodology · Threat Matrix

Actor TTPs and behavior patterns used to build detections and inform hunting — the analyst- and engineer-facing layer, and the altitude where most of the day-to-day CTI-to-detection handoff actually happens. A tactical product isn't "watch out for ransomware" or "block this IP"; it's "this actor's confirmed TTPs are X, Y, and Z, here is the telemetry needed to hunt for them, and here is the detection backlog item that should come out of it."

This is exactly the handoff Module 8 covers in depth — from TTP to detection rule, threat hunting hypotheses, and detection engineering handoff — and the layered-detection argument in From Threat Intelligence to Detection is tactical intelligence's whole reason for existing: strategic and operational products tell you a campaign matters, but only tactical intelligence is concrete enough to actually build and validate a detection from.

Further reading on 1200km: From Threat Intelligence to Detection · Module 8 — Operationalizing CTI

The most granular layer: raw IOCs, malware samples, and infrastructure data, often machine-consumable and the fastest to go stale. This is the layer the Pyramid of Pain puts at the bottom for exactly the reasons covered in Module 1 — cheap to produce, cheap for an adversary to invalidate — but it is also the raw material every other altitude of intelligence is ultimately built from.

AdversaryGraph's IOC Library and investigation graph exist specifically at this altitude, and link analysis and infrastructure pivoting (Module 5) is the discipline that turns a pile of technical-intelligence artifacts into something closer to operational or tactical value.

Further reading on 1200km: AdversaryGraph platform

A globally accessible knowledge base of adversary tactics and techniques based on real-world observations, organized as a matrix (Enterprise, Mobile, ICS) and used as the common language for describing behavior. Module 1 covers how tactics, techniques, and sub-techniques actually decompose using the T1003/T1003.001 example; this entry is about the framework itself as a shared standard.

ATT&CK as a Working Tool makes the case that most security professionals have "heard of" ATT&CK without having internalized how to actually work with it day to day — mapping a report's behavior to techniques with analytic rigor, running a meaningful Navigator coverage-gap analysis instead of a false-confidence heatmap, and connecting a CTI report's ATT&CK table all the way through to a detection engineering backlog. Browse the live matrix, actor by actor, on Threat Matrix, or map coverage against a real detection backlog inside AdversaryGraph.

Further reading on 1200km: ATT&CK as a Working Tool · Module 1 — TTPs · Threat Matrix · AdversaryGraph platform

An ATT&CK-style knowledge base specifically for adversarial threats against AI and machine-learning systems — prompt injection, training-data poisoning, model extraction, and the rest of the AI-specific attack surface, cataloged with the same tactic/technique structure as classic ATT&CK.

AI Offensive Security: Practical Attacks Against LLM Agents cites ATLAS directly as one of the three grounding references for its methodology, alongside the OWASP Top 10 for LLM Applications and academic indirect-prompt-injection research — a real example of ATLAS being used the way ATT&CK is used elsewhere: as a shared taxonomy that keeps a threat write-up falsifiable instead of just plausible-sounding.

Further reading on 1200km: AI Offensive Security: Practical Attacks Against LLM Agents

A seven-stage intrusion model — Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command & Control, Actions on Objectives — used to identify where a defense can break the attack. Developed by Lockheed Martin as part of Intelligence Driven Defense, it remains useful mainly as an organizing structure for evidence, not as a claim about what actually happened at every stage.

CTI Kill Chain: An Analyst Guide With Real-World Evidence is explicit about the model's real limitation: most public reporting describes what responders observed after compromise, and doesn't always directly show reconnaissance, weaponization decisions, or adversary intent. The model is only useful when analysts preserve that uncertainty, which is why the guide labels every example with one of five evidence tiers — Observed (directly reported technical behavior), Reported (stated by a source but not independently verified), Assessed (the source's own analytic judgment), Inferred (a reasonable analyst interpretation not directly observed), and Caveat (a limitation or alternate explanation) — plus plain-language confidence levels alongside them. That five-tier discipline is a reusable pattern for applying any kill-chain-style model without quietly overstating what the evidence actually proves.

Further reading on 1200km: CTI Kill Chain: An Analyst Guide With Real-World Evidence

A model that represents every intrusion event as four connected vertices — Adversary, Infrastructure, Capability, and Victim — used to pivot between known facts and discover new ones. Its strongest use isn't drawing the diagram; it's testing whether the links between vertices are actually supported by evidence.

The CTI Analyst Field Manual makes a point that matters more than the model's geometry: an analyst can often know capability and infrastructure while the adversary vertex remains genuinely unknown, and that is still useful CTI as long as the uncertainty is explicit — the common mistake is filling the adversary vertex just because the diagram feels incomplete. Its worked example is a good template: a domain, a certificate, a lure theme, and a payload family define a campaign cluster with the adversary vertex left as Unknown, which then directly generates the next collection tasks — passive DNS, malware config review, lure recipient analysis, and overlap checks against known clusters. The model is especially useful for exactly the kind of work infrastructure pivoting (Module 5) and actor clustering (Module 1) already cover.

Further reading on 1200km: CTI Analyst Field Manual — Diamond Model

A knowledge graph of defensive techniques mapped to the offensive techniques they counter, complementing ATT&CK from the defender's side — where ATT&CK answers "what did the adversary do," D3FEND answers "what specific defensive control actually counters that."

The Customer-Driven AI CTI Project Template's reference toolkit treats a D3FEND Mapping Register as required evidence at its detection-design gate, alongside the ATT&CK mapping — a detection cannot pass that gate without one, and an incomplete D3FEND mapping is only a waivable blocker for lab work, never for a pilot. That is D3FEND used the way it is meant to be used: not as a reference chart, but as a governance artifact that keeps a claimed detection honest about which specific defensive technique it actually implements.

Further reading on 1200km: Customer-Driven AI CTI Project Template — Reference Toolkit

David Bianco's model ranking indicator types by how much cost it imposes on an adversary to change them when detected — trivial (hash values) at the bottom, painful (TTPs) at the top. Module 1 covers this in depth from the indicator side: see IOC and IOA for what sits at the bottom and top of the pyramid respectively, and why that ranking should drive where a CTI team actually invests detection effort.

AdversaryGraph's enrichment and detection backlog are organized around this same principle: cheap indicators get triage-level handling, while TTP-level findings get routed toward durable detection engineering work.

Further reading on 1200km: Module 1 — Indicator of Compromise · Module 1 — Indicator of Attack · AdversaryGraph platform

STIX (Structured Threat Information Expression) is a standardized language for representing threat intelligence as structured data. TAXII (Trusted Automated Exchange of Intelligence Information) is the transport protocol used to share it between platforms — STIX defines the shape of the data, TAXII defines how it moves. STIX 2.1 and TAXII 2.1 are the current published OASIS Standards.

The Intelligent Shield: OpenCTI shows what this looks like implemented rather than just specified: OpenCTI uses the STIX 2.1 Knowledge Graph as its native data model, where every object — threat actors, campaigns, malware, vulnerabilities, indicators, attack patterns — is stored as a STIX Domain Object (SDO) or STIX Relationship Object (SRO), backed by full-text search and graph-relationship storage underneath. AdversaryGraph supports STIX/OpenCTI export directly for exactly this reason — structured intelligence is only as useful as the platforms that can actually consume it without a manual translation step.

Further reading on 1200km: The Intelligent Shield: OpenCTI · AdversaryGraph: pull TAXII or import STIX · ATT&CK and STIX data model

FIRST's current TLP 2.0 standard defines four labels — TLP:RED, TLP:AMBER, TLP:GREEN, and TLP:CLEAR — plus the TLP:AMBER+STRICT sharing caveat. The marking tells a recipient how widely a piece of intelligence may be shared. It is one of the simplest CTI conventions to explain and one of the easiest to get wrong in practice, because the label has to travel with the content through every re-share and summary, not just the original document.

The CTI Analyst Field Manual applies this to itself rather than just describing it in the abstract: it states plainly that it is built from public, TLP:CLEAR material and author-owned public writing, precisely so a reader knows the sharing boundary without having to ask. That's the practical test for whether TLP is actually working — can a downstream reader tell the marking at a glance, or does it require checking the source.

Further reading on 1200km: CTI Analyst Field Manual

The Vocabulary for Event Recording and Incident Sharing: a common, structured vocabulary for describing security incidents consistently — actors, actions, assets, and attributes — so incidents from different organizations can be aggregated and compared rather than read as one-off prose narratives. It's the structural backbone behind large-scale, data-driven incident analysis such as the annual Verizon Data Breach Investigations Report.

The underlying discipline — describing an incident in structured, comparable fields instead of free text — is the same instinct behind evidence labeling and source-rated claims covered in Modules 1–2: a VERIS record and a properly evidence-labeled CTI product are both attempts to make a claim about an incident checkable rather than just readable.

Further reading on 1200km: Module 1 — Data, Information, Intelligence

Intelligence derived from publicly available sources: news, social media, forums, code repositories, certificate transparency logs, and more. The hard part was never finding a single public data point — it's querying dozens of scattered sources, correlating what they return, and doing it without tipping off the target.

SpiderFoot Deep Dive makes the scale problem concrete: manually querying WHOIS, DNS, Shodan, paste sites, and breach databases one at a time is slow and error-prone, so automation tools query hundreds of sources in parallel and correlate the results into a graph instead of a pile of disconnected tabs. theHarvester covers the narrower, earlier-stage version of the same idea — pulling emails, subdomains, and employee details from public sources before an investigation or engagement even has a shape yet.

Further reading on 1200km: SpiderFoot Deep Dive · theHarvester

Adjacent intelligence disciplines — Human, Signals, Geospatial, and Technical intelligence — that CTI sometimes draws on or parallels in tradecraft, mostly inherited from the traditional intelligence community rather than practiced directly by most CTI teams. HUMINT is intelligence from human sources (undercover forum access, informants); SIGINT is intercepted communications and signals; GEOINT is imagery and geospatial analysis; TECHINT is intelligence derived from adversary technical materiel — captured tools, malware, or hardware.

A working CTI team touches TECHINT constantly without necessarily using the term — every malware sample and every piece of captured tooling analyzed under Module 1's TTP framework is technical intelligence in the classic sense. The other three stay mostly conceptual reference points: useful for understanding where CTI sits inside the broader intelligence discipline, less often something a CTI analyst directly collects.

Collection from restricted-access forums, marketplaces, and Telegram/Discord channels where criminal actors trade access, tools, and stolen data. This is where initial access brokers advertise footholds, where breached credentials surface before an organization even knows it was compromised, and where ransomware affiliates coordinate outside the reach of standard OSINT tooling.

SpiderFoot packages a version of this as automated modules rather than manual forum-lurking — sfp_pwned checks whether emails or accounts tied to a target appear in known breach dumps, and sfp_darkweb searches dark web sites and forums for target mentions. That's the accessible end of closed-source monitoring; the deeper end (actual forum access, vetted marketplace accounts) is closer to HUMINT than automated collection, which is exactly why the two disciplines sit next to each other in this module.

Further reading on 1200km: SpiderFoot Deep Dive

Structured streams of indicators or reports, from open-source (abuse.ch, ThreatFox), commercial (vendor feeds), or community (ISAC/ISAO) sources — the closest thing CTI has to a raw-material supply chain, and the layer most teams over-invest in relative to what it can actually deliver on its own (see IOC in Module 1 for why).

AdversaryGraph manages feed configuration and ingestion as a first-class workflow rather than a side script — indicators land in the same enrichment and scoring pipeline as manually collected ones, instead of sitting in a separate, unreviewed blocklist.

Further reading on 1200km: AdversaryGraph platform

A historical record of DNS resolutions over time, used to pivot from a known-bad domain to related infrastructure without directly querying the adversary's systems. Infrastructure Pivoting calls it "the history book of the internet" for a precise reason: recursive DNS resolvers log every question and answer — domain X resolved to IP Y at timestamp Z — and those logs accumulate for months or years into a record that survives infrastructure rotation.

That gives passive DNS three specific analytic uses the article walks through: attackers rotate infrastructure after detection, but passive DNS still shows what a domain pointed to before the rotation; multiple unrelated-looking domains resolving to the same IP historically reveals co-hosting and clustering even when the names share nothing in common; and domains registered and resolved within hours of each other are a strong signal of a single coordinated campaign rather than unrelated activity. This is exactly the kind of evidence the Diamond Model (Module 3) uses to generate new collection tasks from a single starting indicator.

Further reading on 1200km: Infrastructure Pivoting: How CTI Analysts Expand From a Single IOC to a Full Attacker Network · Module 3 — Diamond Model

Deliberately vulnerable systems or networks deployed to attract, observe, and collect intelligence on attacker behavior. A honeypot is a single decoy asset; a honeynet is a connected set of them designed to look like a real network segment, giving an intruder enough room to reveal tooling and lateral-movement habits rather than just an initial exploit attempt.

The value isn't really the exploit that gets caught — it's the behavioral telemetry that comes with it: what an attacker does once they believe they're inside a real environment. That's the same behavior-over-artifact principle the Pyramid of Pain (Module 3) argues for everywhere else, applied to a controlled collection environment instead of production telemetry.

Further reading on 1200km: Module 3 — Pyramid of Pain

Automated dynamic analysis — detonating a sample in an isolated environment — as a collection source for behavioral IOCs and TTPs. Where static analysis reads a file without running it, sandboxing runs it deliberately, on the assumption that a sample's real behavior is harder to fake than its static appearance.

AdversaryGraph's MalwareGraph-backed malware analysis workbench covers the static side of this triage in depth — string and IOC extraction, unpacking, decompilation — with gated dynamic workflow categories for the sandboxing side once a sample clears static review, rather than detonating everything indiscriminately.

Further reading on 1200km: AdversaryGraph Malware Analysis · AdversaryGraph platform

SIEM, EDR, firewall, and proxy logs from your own environment — often the most relevant and highest-fidelity CTI source for your specific organization, and the one every other collection source in this module is ultimately in service of: external intelligence only matters once it can be checked against what your own systems actually recorded.

Newest Detection Engineering Techniques makes the dependency blunt: modern detection should start with a data question — which log source proves process creation, parent process, command line, user, host, timestamp, and network follow-on activity — not a rule idea. Its conclusion is the whole point of this term: "if the data does not exist, the rule is not a detection. It is a wish." Every tactical and technical intelligence product from Module 2 depends on that telemetry actually existing before any of the collection above becomes actionable.

Further reading on 1200km: Newest Detection Engineering Techniques · Module 2 — Tactical Intelligence

A family of formal methods — Analysis of Competing Hypotheses, Key Assumptions Check, Red Team analysis, premortems — used to inject deliberate friction into analysis so a conclusion has to survive scrutiny before it ships. They exist because unstructured analysis tends to converge on whatever hypothesis felt right first, then collects evidence to support it rather than test it.

Applying Sherman Kent's Analytic Discipline to CTI frames SATs as bias controls rather than bureaucratic decoration: "alternative hypotheses, key assumptions checks, evidence matrices, and premortems... force friction into the analysis." The practical version of that discipline is simple — before publishing an attribution or assessment, write down the strongest evidence against it.

Further reading on 1200km: Applying Sherman Kent's Analytic Discipline to CTI

A technique that lists every plausible explanation for the evidence up front — not just the favored one — and evaluates each against the same evidence set simultaneously, looking for what would disconfirm each hypothesis rather than what confirms it. The goal is to catch the case where evidence looks supportive of a theory mainly because no competing theory was ever seriously tested.

Applying Sherman Kent's Analytic Discipline to CTI walks through this pattern using NotPetya: rather than asserting one motive, it lays out competing hypotheses side by side — state-directed destruction disguised as ransomware, Ukraine-focused disruption that spread further than intended, or mixed objectives behind a ransomware presentation — and identifies what evidence would discriminate between them. That framing generalizes directly: for any attribution or intent judgment, list the alternatives before committing to one.

Further reading on 1200km: Applying Sherman Kent's Analytic Discipline to CTI

The foundational doctrine of intelligence analysis, credited to Sherman Kent's work professionalizing U.S. intelligence analysis: separate observed fact from assumption and judgment, use estimative language deliberately, state confidence apart from probability, and make the analytic path auditable rather than asserting a conclusion and hoping it's trusted.

Applying Sherman Kent's Analytic Discipline to CTI translates this doctrine directly into CTI terms: a file hash can support a malware-family claim, a C2 pattern can support a campaign link, victimology can support a targeting assessment — but none of those, on its own, proves adversary intent or state tasking. Kent-style discipline is the habit of never letting that gap between technical evidence and strategic judgment go unstated.

Further reading on 1200km: Applying Sherman Kent's Analytic Discipline to CTI

Standardized language — "almost certainly," "likely," "roughly even chance," "unlikely" — that maps qualitative confidence to a consistent probability band across a team, so "likely" means the same thing in every report a given team publishes instead of drifting with each analyst's personal sense of the word.

Applying Sherman Kent's Analytic Discipline to CTI puts it plainly: "different organizations use different probability bands, but a CTI team should publish and reuse one internal lexicon." The article also shows what disciplined wording looks like in practice — preferring "the cited vendor blog says FireEye assessed APT28 was most likely sponsored by the Russian government" over the flatter, false-certainty claim "APT28 is Russian government-directed."

Further reading on 1200km: Applying Sherman Kent's Analytic Discipline to CTI

A separate axis from probability: confidence reflects the quality, access, and corroboration of the underlying sourcing, not the likelihood of the conclusion itself. A judgment can be likely but low confidence if the evidence is thin, or high confidence but still short of certain.

Applying Sherman Kent's Analytic Discipline to CTI makes the split concrete with WannaCry: technical behavior — SMBv1/EternalBlue propagation — can carry high confidence because it's directly observable, while the DPRK/Lazarus attribution and the operators' strategic intent sit at a separately-stated, lower confidence level, because they rest on a longer inference chain from thinner evidence. Reporting both under one blended confidence figure hides exactly the distinction a reader needs.

Further reading on 1200km: Applying Sherman Kent's Analytic Discipline to CTI

A standardized two-part rating — source reliability A through F, information credibility 1 through 6 — used to grade raw reporting before it's used in analysis. Also called the Admiralty System or the STANAG 2511 model, and codified in the MISP admiral taxonomy for tagging source and claim quality directly on indicators and reports.

The CTI Analyst Field Manual is explicit that the notation "is not mathematical" — it's a review prompt that forces the analyst to justify the weight a claim gets, not an automated trust score: "an A-rated source can make a weak claim. A weak source can report something that later proves true." Corroboration for a credibility rating of 1 has to come from independent primary sources; a secondary summary citing the same original report doesn't count twice.

Further reading on 1200km: CTI Analyst Field Manual — Source Reliability

Following relationships between entities — domains, IPs, certificates, WHOIS registrants, malware hashes — to expand a single indicator into a broader picture of adversary infrastructure. This is what AdversaryGraph's IOC investigation graph is built to do interactively, turning a manual, tab-by-tab pivoting habit into a visual, queryable graph.

Infrastructure Pivoting: How CTI Analysts Expand From a Single IOC covers the discipline end to end — starting from one hash, domain, or IP and pivoting through shared certificates, hosting infrastructure, and registration patterns until a single indicator becomes a mapped attacker network. It's the same discipline covered from the collection side under OSINT in Module 4, applied here as an analytic technique rather than a data-gathering step.

Further reading on 1200km: Infrastructure Pivoting

The process, and inherent difficulty, of tying an intrusion to a specific actor or sponsor. Usually expressed with an explicit confidence level, since false flags, shared tooling, and leaked or resold malware make certainty rare. See Threat Actor / Group / Campaign in Module 1 for the full evidence hierarchy, illustrated with actor profiles on Threat Matrix.

Attribution Methodology: How to Build, Defend, and Challenge a Threat Actor Attribution covers the mechanics — evidence types, the difference between technical clustering and sponsor attribution, and how to challenge a public attribution rather than accept it at face value. Applying Sherman Kent's Analytic Discipline to CTI adds the SolarWinds case as a model of doing this correctly: keeping technical compromise, tooling (SUNSPOT/SUNBURST), vendor label, government attribution, and assessed intent as five separate claims instead of collapsing them into one.

Further reading on 1200km: Attribution Methodology · Applying Sherman Kent's Analytic Discipline to CTI

Systematic errors in judgment that structured techniques and peer review are designed to catch: confirmation bias (treating every new overlap as support for the actor hypothesis already in the analyst's head), anchoring (over-weighting the first vendor label or first incident-response theory), mirror-imaging (assuming the adversary values risk and cost the way the defender does), availability bias (over-weighting the most memorable recent campaign), and groupthink (converging on a shared label because peers use it, without separately testing the evidence).

Applying Sherman Kent's Analytic Discipline to CTI names all five patterns directly and ties them back to SATs as the practical countermeasure — bias is rarely fixed by trying harder to be objective; it's fixed by building a process step that forces the alternative case onto the page.

Further reading on 1200km: Applying Sherman Kent's Analytic Discipline to CTI

A sophisticated, typically state-sponsored or state-aligned actor conducting stealthy, long-term intrusions with defined strategic objectives — intelligence collection, pre-positioning, sabotage — rather than smash-and-grab financial gain. "Persistent" is the operative word: these actors are frequently detected, evicted, and come back with adjusted tradecraft rather than moving on.

CTI Research: Sandworm / APT44 and APT41 Targeting Pharmaceutical Sector are both evidence-labeled profiles of that pattern in practice — years-long operational histories, documented tooling evolution, and, in the APT41 case, a full chain from a Log4Shell foothold to domain compromise. See full actor profiles, including alias crosswalks, on Threat Matrix.

Further reading on 1200km: CTI Research: Sandworm / APT44 · APT41 Targeting Pharmaceutical Sector

Different vendors track — and name — the same underlying activity differently: Mandiant (APTxx / UNCxxxx), CrowdStrike (animal + adjective, e.g. "Fancy Bear"), Microsoft (weather names, e.g. "Midnight Blizzard"), MITRE ATT&CK (Gxxxx group IDs). None of these are the "real" name — they're independent clustering judgments that sometimes converge on the same activity and sometimes don't.

CTI Research: MuddyWater / Seedworm (Mango Sandstorm) is the naming problem made concrete in its own title — three vendor names for one Iranian-aligned group — and its alias crosswalk includes a documented correction: one outlet listed APT34/OilRig as a MuddyWater alias, which the report flags as incorrect, since APT34/OilRig is a distinct tracked group (MITRE's G0049) despite observed operational cooperation between the two. Threat Matrix uses the Gxxxx convention and lists known aliases on every actor page for exactly this reason.

Further reading on 1200km: CTI Research: MuddyWater / Seedworm (Mango Sandstorm)

A criminal business model where ransomware developers lease their malware and infrastructure to "affiliates," who conduct the actual intrusions and split the extortion proceeds with the developer. RaaS is what turned ransomware from a bespoke capability a handful of groups had into a commodity service almost any capable intruder can rent.

The business-model split matters for tracking: the malware brand (the RaaS platform) and the intrusion actor (the affiliate) are frequently different entities with different tradecraft, which is why two "LockBit" intrusions can look completely different at the TTP level covered in TTPs in Module 1 — the affiliate, not the ransomware binary, drives most of the observable behavior.

A specialized criminal actor who breaches organizations and then sells that access to other threat actors — often ransomware affiliates — rather than exploiting it directly. IABs are the wholesale layer of the intrusion economy: they turn "we found a way in" into a tradeable commodity, decoupling initial compromise from whatever happens next.

CTI Research: MuddyWater / Seedworm (Mango Sandstorm) documents an unusually direct example: ESET assessed that MuddyWater — normally tracked as an espionage-motivated APT — likely operated as an IAB for Lyceum (an OilRig/APT34 subgroup) in a January to February 2025 Israeli manufacturing intrusion, deploying Syncro RMM and a custom Mimikatz loader before handing off stolen credentials. It's a reminder that the APT/criminal/IAB categories in this module describe roles and business models, not rigid boxes — the same group can occupy more than one.

Further reading on 1200km: CTI Research: MuddyWater / Seedworm (Mango Sandstorm)

Politically or ideologically motivated cyber activity — defacement, DDoS, leaks, hack-and-leak operations — aimed at making a statement, applying pressure, or shaping a narrative rather than direct financial gain. Attribution is often harder here than with financially motivated crime, since the "statement" itself is part of the operation and personas are frequently built to obscure sponsorship.

CTI Research: Handala Hack Group profiles exactly this pattern: a "politically aligned hack-and-leak threat persona whose operations are designed to create both technical disruption and information shock," combining intrusion, selective data theft, and fast public messaging timed to geopolitical tension peaks. The report is careful to separate confirmed activity from claimed activity — a distinction that matters more for hacktivist personas than almost any other actor category, since amplification is often the point.

Further reading on 1200km: CTI Research: Handala Hack Group

Risk originating from someone with legitimate access — malicious, negligent, or compromised — rather than an external adversary. It's the category CTI tends to under-serve relative to its impact, since most CTI tradecraft (IOCs, infrastructure pivoting, actor tracking) assumes an outside intruder to track.

Detecting Malicious Insider Activity builds the detection side of this problem from 14 documented incidents into a four-phase implementation programme covering deterministic rules, behavioral heuristics, UEBA, and exfiltration-path coverage — useful context for why insider detection leans so much more heavily on behavioral baselining than indicator-based detection does.

Further reading on 1200km: Detecting Malicious Insider Activity

Refined, analyzed intelligence output ready for a consumer, as opposed to raw data — spans flash/tactical alerts, actor profiles, and long-form strategic assessments. Research notes capture what an analyst found; finished intelligence explains what it means, how confident the analyst is, what's still unknown, and what action should follow.

The CTI Analyst Field Manual draws the line sharply: "if [a product] cannot [be traced backward to the requirement that caused it and forward to the decision it supports], the product may still be useful research, but it is not finished intelligence." Its listed common mistakes are worth internalizing directly — delivering source summaries without judgment, treating long reports as more mature than concise ones, hiding contradictions in appendices, and publishing raw IOCs without expiration, context, or source rating.

Further reading on 1200km: CTI Analyst Field Manual — Finished Intelligence vs Research Notes

A finished-intelligence product consolidating everything known about a tracked group — TTPs, targeting, tooling, alias crosswalk, and history — as a reference for analysts and detection engineers. Threat Matrix publishes these as browsable public pages; AdversaryGraph adds sector relevance scoring on top.

CTI Research: Sandworm / APT44, MuddyWater / Seedworm, and Handala Hack Group from Module 6 are all published examples of the format — report metadata, evidence labels, confidence basis, alias crosswalk, key judgments, timeline, and ATT&CK-oriented mapping in a single consistent shape.

Further reading on 1200km: CTI Research: Sandworm / APT44

Adding context — first/last seen, confidence, related campaigns, source rating, TLP marking — to raw indicators so downstream consumers can prioritize and act on them instead of receiving an undated, unsourced list of hashes and domains, which is closer to an IOC dump than to intelligence.

The CTI Analyst Field Manual treats "publishing raw IOCs without expiration, context, or source rating" as a named common mistake, and pairs Admiralty Code source/credibility ratings from Module 5 with TLP:CLEAR-style handling markings as the two enrichment layers a raw indicator needs before it's fit to share.

Further reading on 1200km: CTI Analyst Field Manual

Software used to aggregate, correlate, enrich, and disseminate threat intelligence — e.g. MISP, OpenCTI, ThreatConnect, Anomali, or the self-hosted AdversaryGraph. The core job is the same across all of them: turn scattered feeds and reports into a queryable, correlated store instead of a pile of disconnected spreadsheets and PDFs.

The Intelligent Shield: OpenCTI covers one such platform in depth — OpenCTI's STIX 2.1 knowledge graph, GraphQL API, and how an AI-driven enrichment layer (LLM-based context building, ATT&CK mapping, and calculated confidence scoring) sits on top of it to convert unstructured feeds into structured, actionable intelligence rather than just another dashboard of raw data.

Further reading on 1200km: The Intelligent Shield: OpenCTI

Information Sharing and Analysis Center/Organization — sector-specific (e.g. FS-ISAC for finance) or cross-sector communities for sharing threat intelligence among trusted peers, usually under a traffic-light-style handling protocol that governs how far a given piece of intelligence can be re-shared.

This is the peer-sharing layer that sits above a single team's own TIP — an organization's internal enrichment and scoring stays internal, but a defanged indicator, a TTP pattern, or a sanitized actor note can move between member organizations through the ISAC/ISAO structure, which is what makes sector-wide early warning possible instead of every organization rediscovering the same campaign independently.

The discipline of adjusting the same underlying finding for different audiences — an executive summary versus a SOC-facing technical bulletin versus a detection engineer's telemetry requirements — without changing the underlying judgment or quietly dropping the uncertainty that qualifies it.

The CTI Analyst Field Manual includes "is the output tailored to the consumer?" directly in its analyst checklist, and its practical workflow closes with the same instruction that opens this discipline: preserve source links and limitations, then convert conclusions into actions or documented gaps — for whichever audience is reading.

Further reading on 1200km: CTI Analyst Field Manual

The workflow of translating an adversary behavior into a written detection, commonly expressed in Sigma (generic), YARA (file/memory pattern matching), or Snort/Suricata (network) formats. AdversaryGraph's Attack Simulation module then validates whether that rule actually fires.

From Threat Intelligence to Detection: A Practitioner's Guide builds the taxonomy this term sits inside: atomic rules match a single known-bad value and are the fastest to write and the fastest to evade; TTP-based rules detect the technique rather than a specific tool, so "a TTP-based rule for credential dumping fires whether the actor uses Mimikatz, ProcDump, comsvcs.dll, or a custom tool" because all of them touch LSASS memory the same behavioral way. That's why TTP-level detection in Module 1 survives tool swaps that break hash-based rules outright.

Further reading on 1200km: From Threat Intelligence to Detection: A Practitioner's Guide · AdversaryGraph Attack Simulation guide · Newest Detection Engineering Techniques

The point where CTI's tactical output — a TTP, a new IOC set, an actor profile — becomes an engineering backlog item with defined telemetry requirements and validation criteria, instead of a report that gets read once and filed away.

Operation Desert Hydra opens on exactly the failure mode this term exists to prevent: "most threat actor writeups stop too early. They describe the group, list ATT&CK techniques, and paste some IOCs. Then the report sits in a folder while defenders wonder: what do I actually do with this on Monday?" The article builds an end-to-end pipeline — MuddyWater CTI research through to deployed Kibana detections — as the concrete answer to that question.

Further reading on 1200km: Operation Desert Hydra article · Operation Desert Hydra project · Detection Atlas

A falsifiable statement — "if actor X is present, telemetry Y should show Z" — derived from CTI, used to proactively search for compromise that automated detections may have missed.

Endpoint Threat Hunting frames a hypothesis-driven hunt as starting from "an assumption... informed by recent threat intelligence or ATT&CK mappings," then searching telemetry to confirm or refine it — as opposed to IOC-driven or anomaly-based hunting. The intersection this drives toward is concrete: as one worked example in ATT&CK as a Working Tool puts it, "the intersection of 'used by my threat actors' and 'not well-covered by my detections' is your hunting queue."

For an operational implementation, the AdversaryGraph Threat Hunting guide turns a reviewed report or hypothesis into scoped telemetry requirements, a selectable query language, findings, evidence, and a defensible handoff. The workspace records analyst decisions; it does not claim that a copied query was executed in the destination SIEM.

Further reading on 1200km: Endpoint Threat Hunting · ATT&CK as a Working Tool · AdversaryGraph Threat Hunting guide

Deliberately reproducing a specific tracked actor's TTPs — via tools like Atomic Red Team or MITRE Caldera — to validate whether existing detections actually fire, rather than assuming a written rule works because it looks correct on paper.

ATT&CK as a Working Tool describes Atomic Red Team as providing "small, discrete, reproducible test cases... each of which emulates a specific ATT&CK technique or sub-technique in isolation," organized in folders that mirror the ATT&CK matrix itself, so a hunter or detection engineer can run Invoke-AtomicTest T1003.001 and check whether the corresponding rule actually catches it.

Further reading on 1200km: ATT&CK as a Working Tool · Attack Simulation and rule validation

Plotting your organization's detections against the ATT&CK matrix to visualize gaps and prioritize new detection engineering work — the same layout you can explore for free on Threat Matrix, or connect to a live detection backlog in AdversaryGraph.

ATT&CK as a Working Tool warns against turning this into a checklist exercise: "claiming 'we have a rule for T1003' means nothing if that rule has never been validated, never fires in practice, or fires against a data source you stopped collecting six months ago." It draws a hard line between theoretical coverage (a rule exists) and validated coverage (the rule has been confirmed to fire via Atomic Red Team or a purple team exercise) — mark the difference explicitly rather than reporting a single coverage percentage.

Further reading on 1200km: ATT&CK as a Working Tool · Build an ATT&CK coverage baseline

A collaborative exercise where red team (attack) and blue team (defense) work together in real time to validate and improve detection coverage, rather than operating as adversarial, siloed exercises where a red team report lands weeks later with the operational context already gone.

ATT&CK as a Working Tool frames ATT&CK as the shared language that makes real-time collaboration work: "when the red team says 'we just executed T1003.001,' the blue team knows exactly what alert to look for. There is no translation overhead." Its documented workflow starts before the exercise even begins — the CTI team supplies an actor TTP profile as a Navigator layer, and the red team builds its emulation plan from the highest-priority, most-frequently-observed techniques in that profile.

Further reading on 1200km: ATT&CK as a Working Tool

An open-source threat intelligence platform for storing, correlating, and sharing IOCs and threat data, including "galaxies" of actor and malware taxonomy. MISP is also where a source-grading standard becomes executable rather than just a table in a document: the CTI Analyst Field Manual notes that the Admiralty Code covered in Module 5 "is also codified in the MISP admiral taxonomy," letting a team tag source reliability and information credibility directly on the objects being shared instead of tracking it separately.

Further reading on 1200km: CTI Analyst Field Manual — Source Reliability

An open-source platform for structuring, storing, and visualizing threat intelligence knowledge as a connected graph, with native STIX 2.1 support and a GraphQL API for all read/write operations. See the Threat Intelligence Platform entry in Module 7 for how this fits alongside MISP and commercial TIPs.

The Intelligent Shield: OpenCTI covers a deployed, AI-enriched OpenCTI stack in depth — Docker Compose deployment, connector configuration, and an enrichment pipeline that uses an LLM to build context, map findings to ATT&CK, and generate calculated confidence scores on top of the raw STIX knowledge graph.

Further reading on 1200km: The Intelligent Shield: OpenCTI

A multi-engine scanning and enrichment service for files, URLs, domains, and IPs, widely used for first-pass indicator triage — the fastest way to check whether an artifact is already known-bad before spending analyst time on it.

SpiderFoot Deep Dive documents VirusTotal as one of the automated modules (sfp_virustotal) that checks whether a target domain or IP appears in known malware or phishing data — folding what used to be a manual lookup step into the same automated pivoting pipeline covered in Module 5's Link Analysis / Infrastructure Pivoting.

Further reading on 1200km: SpiderFoot Deep Dive

Internet-wide scanning search engines used to discover exposed services, adversary infrastructure, and misconfigured assets, indexed continuously rather than queried live against the target each time.

SpiderFoot Deep Dive covers the automated side of this — modules like sfp_shodan and sfp_ports query Shodan for a target's exposed services and known vulnerabilities as part of a broader OSINT pipeline, rather than a one-off manual search per indicator.

Further reading on 1200km: SpiderFoot Deep Dive

A link-analysis and visualization tool for graphing relationships between entities during infrastructure pivoting and OSINT investigations — turning a list of pivots into a graph an analyst can actually read.

Infrastructure Pivoting places Maltego CE in its visualization layer alongside VirusTotal Graph, Obsidian, and SpiderFoot, in a worked example that starts from a single phishing domain and pivots through certificates, hosting, and registration data until it's mapped into a full C2 network — the same discipline covered as a term under Link Analysis / Infrastructure Pivoting in Module 5.

Further reading on 1200km: Infrastructure Pivoting

A pattern-matching tool for identifying and classifying malware samples based on textual or binary signatures — the standard way to say "this file matches a known malware family" in a form other tools and platforms can consume directly.

Android Malware Analysis: A Practical Guide uses YARA as one stage of a detection-engineering workflow — matching against capabilities like notification-listener-based OTP interception or DexClassLoader-based droppers — combined with androguard static analysis and semantic component analysis into a single triage pipeline rather than run as an isolated, standalone step.

Further reading on 1200km: Android Malware Analysis: A Practical Guide

A web tool for visualizing, annotating, and comparing coverage across the ATT&CK matrix — for example, an actor's known techniques versus your detections. Threat Matrix is a free public instance of this same idea, pre-loaded with actor and technique data.

ATT&CK as a Working Tool calls Navigator "the primary tool for coverage analysis, threat actor profiling, and communicating detection status to both technical and non-technical audiences," and walks through building a green/yellow/gray coverage heatmap layer by layer — the exact ATT&CK Coverage Mapping workflow from Module 8.

Further reading on 1200km: ATT&CK as a Working Tool

Self-hosted CTI-to-detection platform connecting most of the workflow above into one tool: report ingestion, IOC enrichment, ATT&CK mapping, malware analysis, attack simulation, and SIEM validation. Its public technique and actor browser, Threat Matrix, is free to use without deploying anything.

AdversaryGraph: I Built a Self-Hosted AI Threat Intelligence Platform covers the build and the reasoning behind it, and From Log to Report Using AdversaryGraph walks the platform end to end in the opposite direction from most of this module — starting at raw log data and working forward to a finished report, rather than starting from a report and working forward to a detection rule as in Module 8.

Further reading on 1200km: AdversaryGraph: I Built a Self-Hosted AI Threat Intelligence Platform · From Log to Report Using AdversaryGraph

Entry-level roles often focus on indicator triage and enrichment (tactical/technical) — the Indicator Enrichment & Scoring and Admiralty Code work from Modules 5 and 7. Senior roles move toward actor tracking, campaign analysis, and strategic reporting — the Threat Actor Profile and Finished Intelligence work from Module 7, built on the analytic discipline in Module 5.

The published Threat Matrix actor profiles in Modules 6 and 7 — Sandworm/APT44, MuddyWater/Seedworm — are written at that senior tier's output level; reading a few end to end, alias crosswalk and all, is a faster way to internalize what "senior CTI writing" looks like than any tier definition.

Options include GCTI (SANS/GIAC Cyber Threat Intelligence) and CTIA (EC-Council), plus broader analyst certifications like GCFA or OSCP for adjacent skill depth. None of these substitute for published, reviewable analytic work — a certification demonstrates you learned the material; a public actor profile or a defended attribution judgment demonstrates you can apply it.

Start with the intelligence cycle in Module 2 and ATT&CK in Module 3 — browse ATT&CK hands-on on Threat Matrix — then practice collection and indicator pivoting in Module 4, learn a structured analytic technique in Module 5, study the actor landscape in Module 6, and build toward finished-intelligence writing and CTI-to-detection handoff in Module 7 and Module 8 inside a platform like AdversaryGraph.

Customer-Driven AI CTI Project Template — Part 1: Foundations is a practical next step once this field guide is familiar: a full project template that goes from pure CTI through hands-on detection engineering with explicit validation gates, structured as the kind of end-to-end engagement a working analyst is actually expected to deliver.

Further reading on 1200km: Customer-Driven AI CTI Project Template — Part 1

CTI collection must stay within authorized scope and applicable law — accessing systems without authorization, even for "research," is illegal regardless of intent. The same discipline applies to attribution: naming an actor or a sponsor is an analytic judgment, not a legal or government determination, and should be written and hedged accordingly.

The CTI Analyst Field Manual states its own boundary explicitly: it "does not provide malware source code, unauthorized access instructions, leaked data, credentials, or victim-sensitive information," and treats every attribution example in the manual as "analytic exercises, not legal or government determinations" — the same standard this field guide follows throughout Module 5 and Module 6.

Further reading on 1200km: CTI Analyst Field Manual