Indicators of Compromise and Threat Intelligence: A Practitioner Reference

A working analyst’s reference. Twenty sections, sixteen frameworks — the Pyramid of Pain, the Diamond Model of Intrusion Analysis, the Cyber Kill Chain mapped to MITRE ATT&CK, STIX 2.1 / TAXII 2.1 / OpenIOC / Sigma / YARA, F3EAD, the Admiralty source reliability code, TLP 2.0, the Hunting Maturity Model, PIR / SIR / KIT / KIQ. Field-level detail on IOC pivoting (passive DNS, WHOIS history, JA3/JA4/JARM, TLS SAN, ASN). No vendor pitches, no beginner restatements — the structure, the standards, and the operator tradecraft you reach for at the keyboard.

Bookmark the sections you use. Reference IDs are stable across revisions, so deep links from your runbooks remain valid.

PART 1 · IOC Engineering

01 · Definition and taxonomy

An Indicator of Compromise is an observable artefact — a value, a pattern, or a sequence — whose presence in telemetry suggests that a host, an account, or a network segment has been touched by adversary activity. The definition has four operative words: observable, artefact, suggests, and activity.

• Observable — it must be visible in at least one telemetry source. Theoretical artefacts are not IOCs.
• Artefact — the unit is a thing, not a story. A hash, a domain, a process tree, a registry edit. Stories about the threat actor are intelligence, not IOCs.
• Suggests — an IOC is probabilistic evidence, not proof. The job of the analyst is to convert suggestion into determination through corroborating IOCs and context.
• Activity — the underlying event is adversary action: scanning, initial access, execution, persistence, lateral movement, exfiltration, impact.

The taxonomy that follows in the rest of this guide rests on this definition. Every IOC type, every framework, every standard is a way of structuring observables so they can be reasoned about at scale.

02 · The Pyramid of Pain — the foundational mental model

The Pyramid of Pain is the most useful single mental model in operational threat intelligence. It ranks indicator categories by the operational cost the adversary pays when defenders deny that indicator. The wider the base of the pyramid, the cheaper the adversary’s rotation; the narrower the apex, the more painful the defender’s denial.

How to use the pyramid in detection design. Whenever you write a detection rule, ask which tier it sits on. A hash-based rule is fragile by design — the adversary defeats it with a one-byte change. A TTP-based rule (parent-process anomaly, command-line argument anomaly, named-pipe handshake pattern) cannot be defeated without the adversary retraining their operators. Spend your detection-engineering hours where the leverage is.

The asymmetric insight. Defenders typically write 80 percent of their detections at tiers 01-03 because the data is easy to acquire. Adversaries typically defeat 80 percent of detections at tiers 01-03 because rotation at those tiers is cheap. The 80/80 mismatch is why most SOCs feel like they are running uphill. Invert the ratio.

03 · Atomic, Computed, and Behavioural indicators

The Pyramid of Pain ranks indicators by adversary pain. A parallel taxonomy ranks them by analytical complexity. Every IOC falls into one of three buckets.

The taxonomy matters because the three categories require different tooling, different detection grammars, and different analyst skill sets. An atomic IOC ships through a blocklist; a computed IOC ships through a similarity-matching engine; a behavioural IOC ships through a detection-as-code pipeline. Mistaking one for another (writing a behavioural detection as an atomic blocklist, for example) is the most common detection-engineering failure mode.

04 · The four IOC domains — field-level detail

The four domains describe where the observable surfaces. For each, there is a canonical telemetry source, a canonical indicator field, and a canonical class of failure mode.

Domain 01 · Network-based

Domain 02 · Host-based

Domain 03 · Email-based

Domain 04 · Behavioural

05 · Pivoting tradecraft — turning one IOC into a hundred

The single most valuable analyst skill is pivoting: starting from one indicator, identifying the related observables an adversary forgot to vary, and expanding to the broader infrastructure or tool family. The pivoting techniques below are the working analyst’s reference set. Each technique converts a single IOC into many.

The pivot discipline. Never stop at one IOC. The atomic indicator is a thread; the campaign is the rope. Every working investigation produces a pivot graph — the original IOC at the root, each pivot a child, each child producing the next round of pivots. Save the graph; it becomes the campaign profile.

06 · Standards — STIX 2.1, TAXII 2.1, OpenIOC, MISP

Indicators travel between teams, organisations, and tools through standardised formats. A serious programme picks one canonical format internally and translates to the others at the boundary.

STIX 2.1 (Structured Threat Information Expression)

The dominant interchange standard. STIX 2.1 represents the world as a graph of typed JSON objects linked by typed relationships. The eighteen-plus STIX Domain Objects include Indicator, Malware, Threat-Actor, Campaign, Intrusion-Set, Attack-Pattern, Tool, Vulnerability, Identity, Infrastructure, Course-of-Action, Malware-Analysis, Note, Observed-Data, Opinion, Report, Sighting, and Grouping. Relationships such as indicates, uses, targets, attributed-to, and variant-of turn the objects into a knowledge graph. Indicators carry STIX patterns — a small expression language ([file:hashes.'SHA-256' = '…']) for matching observables.

TAXII 2.1 (Trusted Automated eXchange of Intelligence Information)

The transport layer for STIX. TAXII 2.1 is a REST API with API roots, collections, and channels. A producer publishes STIX bundles into a collection; consumers pull from the collection on their own cadence. TAXII handles authentication, paging, filtering by date and object type, and discovery (so a consumer can ask a server “what collections do you offer?”).

OpenIOC

An older XML-based format originally designed for endpoint indicators with Boolean logic over evidence fields. Still appears in legacy reports and some endpoint-tool exports. Convert to STIX 2.1 on ingest unless your tooling specifically requires OpenIOC.

MISP (Malware Information Sharing Platform)

An open-source platform that ships with its own JSON event format. MISP events bundle attributes (the indicators), objects (groupings of attributes with semantic meaning), and galaxies (taxonomies for threat actor, ransomware family, attack pattern). MISP can export to STIX 2.1 and OpenIOC; many sharing communities exchange MISP events natively.

The interchange pattern

Decide on one canonical internal format. STIX 2.1 is the safe default because every modern threat intel platform speaks it. Build translation adapters at the edges: ingest OpenIOC, MISP, and feed-specific formats and emit STIX into your internal graph. On dissemination, emit STIX for external consumers and translate to SIEM-specific formats (proprietary rule languages, native blocklist syntax) at the egress.

07 · Detection content — Sigma and YARA

Atomic IOCs become blocklists. Behavioural IOCs become detection content. Two open standards dominate the field: Sigma for log-based detections and YARA for content-based detections.

Sigma — portable log-based detections

Sigma is a YAML-based, vendor-agnostic rule format. A Sigma rule expresses a detection in abstract terms; converters translate the abstract rule to the query language of any SIEM (KQL, SPL, ESQL, EQL, OpenSearch DSL, and most proprietary rule grammars). The structural value: write the rule once, run it everywhere, share it across organisations without rewriting per-vendor.

title: Suspicious Office Process Spawning Command Interpreter
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: stable
description: Detects an office document reader spawning powershell.exe, cmd.exe,
  or a scripting host within 30 seconds of document open.
references:
  - https://attack.mitre.org/techniques/T1059/
author: Practitioner Reference
date: 2026/06/22
tags:
  - attack.execution
  - attack.t1059.001
  - attack.t1204.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
  selection_child:
    Image|endswith:
      - '\powershell.exe'
      - '\cmd.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate macro-driven document workflows (enumerate allowlisted parents)
level: high

YARA — content-based pattern matching

YARA matches patterns inside files and process memory. Rules combine string sets, byte patterns, and Boolean conditions over file metadata. YARA is the canonical format for malware family identification, sandbox tagging, memory-forensics signatures, and email-attachment scanning.

rule Suspicious_Beacon_Loader
{
    meta:
        description = "Generic beacon-loader pattern observed across multiple families"
        author      = "Practitioner Reference"
        date        = "2026-06-22"
        reference   = "https://hackforlab.com/ioc-threat-intelligence-complete-guide/"

    strings:
        $api1 = "VirtualAlloc"      ascii wide
        $api2 = "CreateRemoteThread" ascii wide
        $api3 = "WriteProcessMemory" ascii wide
        $cfg  = { 4D 5A ?? ?? ?? ?? ?? ?? ?? ?? 50 45 00 00 }
        $beacon_check_path = "/api/v1/check" ascii nocase

    condition:
        uint16(0) == 0x5A4D
        and filesize < 2MB
        and 2 of ($api*)
        and $cfg
        and $beacon_check_path
}

The relationship. Sigma rules fire on events; YARA rules fire on content. Together they cover both halves of the detection surface — log telemetry and file/memory artefacts. Modern intelligence platforms ship both: every cluster carries Sigma rules for log-based detection and YARA rules for binary identification.

08 · IOC vs IOA vs TTP — the operator’s distinction

Three terms get conflated. They are not interchangeable. The distinction matters because the three live at different altitudes of the Pyramid of Pain and produce different detection economics.

The relationship is sequential. An adversary executes a TTP. The execution produces IOAs that defenders can recognise in motion. After the fact, defenders extract IOCs from the evidence. Today’s IOAs become tomorrow’s IOCs become next week’s training data for behavioural models. The intelligence cycle continuously promotes observables up the Pyramid of Pain and pushes detection content down it.

The practitioner heuristic. Every detection you write should be classifiable as IOC-, IOA-, or TTP-based. If you can’t tell which, the detection is muddled — rewrite it cleanly at one altitude. Pile too many IOC-tier detections and the SOC drowns in low-leverage signal. Pile too many TTP-tier detections without the IOC layer and you miss the easy wins. Balance the pyramid deliberately.

PART 2 · Threat Intelligence Architecture

09 · The four TI tiers — producer-consumer contract per tier

Threat intelligence is not a homogeneous product. It is four product lines, each with a different audience, different cadence, different format, and different success metric. A mature programme produces all four; each tier has an explicit producer-consumer contract.

The contract. Each tier’s producer commits to a delivery cadence, a delivery format, and a definition of done. Each tier’s consumer commits to consuming the output and feeding back failure modes (a stale IOC, a hunt that produced nothing, a brief that didn’t change a decision). Without the consumer commitment, intelligence becomes a dashboard nobody opens; without the producer commitment, the SOC starves of inputs.

The single most common failure. Programmes over-invest in technical intelligence (the easiest tier to produce because feeds exist) and under-invest in strategic and tactical intelligence (the hardest tiers to produce because they require human analysis). Result: the board has no view of risk; the detection engineers have no TTP catalogue; the SOC has a million IOCs and no story.

10 · The TI lifecycle and the F3EAD overlay

Threat intelligence is a workflow. The classic six-phase lifecycle is the inherited model:

The F3EAD overlay — the operator’s parallel cycle

The six-phase lifecycle is what the intelligence team runs. The F3EAD cycle is what happens when an operational team uses intelligence in an investigation or hunt. The two cycles run in parallel and feed each other.

F3EAD turns every incident into an intelligence production opportunity. Without the E-A-D back-half, the incident is a one-time event; with it, the incident becomes a force multiplier — every future detection in your environment (and your sharing community’s environments) becomes stronger.

11 · Intelligence requirements — PIR, SIR, KIT, KIQ

The Direction phase of the lifecycle has its own structured vocabulary. A working programme writes its requirements explicitly and reviews them every quarter.

The four levels nest. KITs define the areas. KIQs define the regularly answered questions within an area. PIRs are the leadership-level umbrella questions. SIRs decompose PIRs into actionable production work. A programme that cannot map every analyst-hour back to one of the four is producing intelligence without a customer — the work has no accountability and predictably starves of resources at the first budget review.

The requirements matrix. Maintain a living document — rows are PIRs and KITs, columns are time horizons (this week, this month, this quarter), cells are the SIRs and KIQs being worked. Review weekly with the consumers. Drop requirements that nobody is using; promote new ones that the SOC starts asking for repeatedly.

12 · The Diamond Model of Intrusion Analysis

The Diamond Model is the canonical structure for analysing a single intrusion event. Every event has four core features and a set of meta-features. The features are the corners of the diamond; analysing one corner exposes the others.

The corners are connected. Capability is the verb that connects Adversary to Infrastructure to Victim. Pivoting on one corner exposes the others — a known adversary’s capability set narrows the suspect tool list; a known infrastructure observation narrows the suspect adversary list. The model is the formal grammar for the analyst’s instinct to “follow the thread.”

Meta-features (the analytical metadata)

• Timestamp — when the event was observed; when each corner was active.
• Phase — which Kill Chain phase or ATT&CK tactic the event corresponds to.
• Result — success, failure, unknown; what the adversary obtained.
• Direction — from adversary infrastructure to victim, victim to adversary, or lateral within victim.
• Methodology — the general approach (spearphish, drive-by, supply chain, valid-account abuse).
• Resources — the assets the adversary expended (development effort, infrastructure cost, operator-hours).

The Diamond Model’s operational value is that it gives every intrusion analyst a shared structure for the artefact-to-attribution chain. Two analysts who both populate the diamond for the same intrusion produce comparable artefacts; the comparison forces the analytical confidence question into the open.

13 · The Cyber Kill Chain × MITRE ATT&CK

The Cyber Kill Chain models an intrusion as seven sequential phases. The model is older than ATT&CK and more abstract; ATT&CK is the modern technique catalogue that lives inside the kill chain phases. The two are complementary, not competing.

How to use the two together

Use the kill chain to describe an intrusion at a glance (the adversary made it through phases 03-06 before defenders interrupted). Use ATT&CK to describe the techniques used at each phase (specifically T1566.001 for delivery, T1204.002 for execution, T1547.001 for persistence). The kill chain is the shape; ATT&CK is the colour.

ATT&CK Navigator is the canonical visualisation tool — an open colour-coded matrix where defenders track which techniques they detect, which they hunt, and which they leave blind. Used at the programme level, the Navigator becomes the public coverage map for the detection programme.

The practical exercise. Pick one ATT&CK technique you do not currently detect. Spend an hour answering three questions: what telemetry would detect it, do we collect that telemetry, what Sigma rule would express the detection? Repeat with a different technique next week. Within one quarter the Navigator coverage map fills out by twelve techniques — a measurable maturity gain.

14 · The Admiralty source reliability code — structured confidence

Intelligence consumers need to know how much to trust each indicator. Eyeballing reliability does not scale; a structured grading code does. The Admiralty code (also known as the NATO source reliability and information credibility grading) is the canonical structure.

Every catalogued indicator should carry a two-character grade. A1 is “reliable source, confirmed information.” B2 is “usually-reliable source, probably true.” F6 is “unknown source, unverified.” Automation policy follows the grade: A1–B2 can promote to automated blocking; C3–D4 belong in watchlists and human-review queues; E5–F6 go to the research bin.

The discipline question. Ask your TI source for the grading. If they cannot provide one, treat the entire feed as ungraded and apply your own consistent grading pass on ingest. A graded feed is intelligence; an ungraded feed is data.

15 · Traffic Light Protocol (TLP 2.0) — sharing discipline

Intelligence travels between organisations only as far as the producer permits. TLP 2.0 is the universal four-tier marking scheme that producers stamp onto every disseminated artefact — report, brief, IOC bundle, briefing slide. Consumers honour the marking; violations break sharing relationships permanently.

The marking discipline is straightforward but easy to break inadvertently. A report received as TLP:AMBER+STRICT cannot be forwarded to a managed-service provider. An IOC bundle received as TLP:GREEN cannot be posted to a public threat-research blog. The technical detail being shared is often less sensitive than the relationship the sharing represents — broken sharing relationships are very hard to repair.

Sharing communities use TLP markings on every artefact. A producer who refuses to mark is a producer who has not yet built sharing discipline. A consumer who refuses to honour markings is a consumer who will not be invited to the next sharing meeting.

PART 3 · Operationalisation

16 · The Hunting Maturity Model

The Hunting Maturity Model (HMM) grades a hunt programme on a five-level scale (0-4). The grade is determined by data availability, hunt repeatability, and the degree to which the programme produces detection content from its hunts.

How to use the HMM. Grade your programme honestly. The grade tells you which capability gap is the next investment. HM0 needs telemetry collection. HM1 needs structured hypothesis generation. HM2 needs hunt-to-detection plumbing. HM3 needs detection-as-code infrastructure. HM4 is the asymptote; nothing further to do but stay there.

17 · Detection engineering pipeline — IOC to production rule

A detection-as-code pipeline turns the journey from “new IOC arrived” to “production rule firing” into a repeatable engineering workflow. The pipeline is a sequence of seven stages, each with a checkpoint.

The pipeline’s value is consistency, not speed. Every rule that reaches production has been triaged, designed, tested, tuned, deployed, and committed to a maintenance schedule. Rules that skip stages produce the chronic SOC pathology: a content library no analyst trusts because nobody knows which rules still work and which have rotted.

18 · SOAR integration patterns

Security orchestration, automation, and response — SOAR — is where intelligence becomes action without human latency. Four integration patterns cover most operational needs.

The integration discipline that determines whether SOAR is a force multiplier or a liability is the kill switch. Every automated action must be reversible by a single analyst command. Confidence-graded automation that you cannot disable in one click is automation that nobody trusts.

19 · KPIs — MTTD, MTTR, dwell time, coverage, hit rate

Measure what matters; manage what you measure. The five KPIs below are the working set most mature programmes track.

Report the KPIs monthly. Trend them quarterly. Use them in budget conversations — “MTTD dropped from 14 days to 4 days this quarter because of the detection-engineering investment” is a sentence the CFO understands.

20 · The practitioner reference stack

The reference stack below is the canonical mental layout of the operational intelligence discipline. Every working programme has each of these layers represented, even if the implementation varies by organisation.

FAQ · 12 practitioner questions