/producing-threat-intelligence

name: producing-threat-intelligence
description: Produce cyber threat intelligence by pivoting on indicators to find related infrastructure, tracking actors and campaigns, enriching and contextualizing IOCs, applying attribution discipline and analytic confidence, and packaging finished intel products tied to a consumer's decision. Covers the intelligence lifecycle, the Diamond Model and Pyramid of Pain, STIX/MISP/OpenCTI storage, TLP sharing, and passive enrichment via passive DNS, crt.sh, Shodan, Censys, GreyNoise, and VirusTotal. Use when pivoting from a domain, IP, hash, or certificate to related infrastructure, tracking a threat actor or campaign, enriching raw indicators, writing a finished intel report, assessing an external report's relevance to your org, or building a threat model of adversaries that matter to you.
verified: 2026-07-27

Producing Threat Intelligence

Intelligence is not a pile of indicators — it is analysis that reduces a decision-maker's uncertainty. An IOC with no context, no confidence, and no recommended action is data, not intelligence. Attribution is a claim you must be able to defend from evidence, not a guess dressed in a threat-actor name. The test of a finished product is simple: did someone decide something differently because of it?

When to Use

• Pivoting from a domain, IP, hash, TLS certificate, or registrant to related

infrastructure

• Tracking a threat actor or campaign over time
• Enriching and contextualizing raw indicators into usable intelligence
• Producing a finished intelligence product for a defined consumer
• Assessing whether an external vendor or government report is relevant to

your organization

• Building and curating a threat model of the adversaries that actually

matter to you

When NOT to Use

• **Searching your OWN telemetry for the activity** — use `hunting-threats`
• **Reversing a specific sample** — use `analyzing-malware`
• **Resolving an ATT&CK technique ID to a skill** — use

`mapping-attack-techniques`

• **An active, confirmed incident** — use `responding-to-incidents`
• **Turning intel into deployed detection rules** — use

`engineering-detections`

The Intelligence Lifecycle

Every product moves through the same loop. Naming the stages is not bureaucracy — it is where you catch the two failures that make CTI worthless.

1. Direction     — whose decision, which question (a PIR)
2. Collection    — gather against the requirement, not everything reachable
3. Processing     — normalize, deduplicate, translate, enrich
4. Analysis      — assess, weigh hypotheses, assign confidence
5. Dissemination — deliver in a form the consumer can act on
6. Feedback      — did it help; refine the next requirement

The two failures that account for most wasted CTI effort are at the ends of the loop, not the middle:

• **Skipping direction** produces intelligence nobody asked for. Without a

Priority Intelligence Requirement (PIR) naming the consumer and the decision, you collect what is easy and report what is interesting, and it lands on no one's desk. Start from the question, not the feed.

• **Skipping dissemination** produces analysis that never reaches a decision.

A brilliant assessment sitting in a wiki nobody reads changed nothing. The product is not done when it is written; it is done when it is in front of the person who acts on it, in the form and at the time they need it.

Write the PIR before collecting. Examples: "Which ransomware crews target our sector and what is their initial-access tradecraft?" "Is the actor in last week's incident likely to return?" "Does this vendor report describe a threat to us?" Each names a consumer and a decision.

Indicator Pivoting

Pivoting expands one observable into an infrastructure picture. The discipline is to stay **passive first** — every pivot below reads third-party data or historical records, none of it touches the adversary's live infrastructure.

| Start from | Pivot via | Finds | | --- | --- | --- | | Domain / IP | Passive DNS (PDNS) | Historical resolutions, sibling domains on an IP, IPs a domain used | | Domain | WHOIS / registration history | Registrant email, registrar, creation date, name-server reuse | | Domain / IP | Certificate transparency (crt.sh) | Other hostnames on the same cert, SAN reuse, issuance timeline | | IP / service | TLS fingerprints — JARM (server), JA3/JA3S (client/server handshake) | Hosts running the same C2 or framework default TLS stack | | Web service | Favicon hash (Shodan `http.favicon.hash`, Censys) | Other servers serving the identical panel or login page | | IP / host | Shodan / Censys banners | Open ports, product versions, response bodies, self-signed cert CNs |

A worked pivot chain: a phishing domain resolves (PDNS) to an IP; crt.sh shows the cert's SANs cover four more lookalike domains; the IP's JARM matches a known Cobalt Strike default; Shodan's favicon hash for the panel returns nine more IPs serving the same interface. One indicator became a cluster of ten, none of which required contacting the adversary.

# Certificate transparency — all certs/SANs seen for a domain
curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq -r '.[].name_value' | sort -u

# Shodan: everything serving an identical favicon
shodan search "http.favicon.hash:-247388890"

# Censys: hosts presenting a given JARM fingerprint.
# Censys Platform (CenQL) prefixes every parsed field with its dataset:
censys search "host.services.jarm.fingerprint: <jarm_hash>"
# Legacy Search used the unprefixed form below. It is deprecated as of
# September 2026, so treat any older query you find as needing conversion:
#   services.jarm.fingerprint: <jarm_hash>

**Do not tip off the adversary.** Do not curl the live C2, resolve its domain from a network attributable to you, submit the still-active sample to a public multi-scanner, or scan the infrastructure directly — each of those tells the operator you are watching and invites