Threat Intelligence: What It Actually Is (and Isn't)

"Threat intelligence" has become a vendor buzzword. Let's strip it back.

At its core, threat intelligence is knowledge about adversaries — their infrastructure, tooling, techniques, motivations, and targeting patterns — that can be acted upon to improve your defensive posture. The "intelligence" part matters. A list of IP addresses is not intelligence. A list of IP addresses correlated with C2 patterns, attributed to a specific cluster, with behavioral signatures and observed TTPs — that starts to be useful.

The Diamond Model, Briefly

The Diamond Model describes four elements of every intrusion:

         Adversary
        /          \
  Capability  ---  Infrastructure
        \          /
          Victim

Element	What it captures
Adversary	Who is doing it (if attributable)
Capability	The malware, exploits, and tools used
Infrastructure	Domains, IPs, servers, certificates
Victim	Who's being targeted and why

The model is useful because it reveals pivot points. If you know the infrastructure, you can find other victims. If you know the capability, you can hunt across your logs. Attribution to adversary is often the least actionable piece.

Indicator Types and Their Shelf Lives

Not all IOCs age equally:

# Rough shelf life by indicator type
shelf_life = {
    "file_hash_md5":     "days",     # trivially changed by attacker
    "file_hash_sha256":  "weeks",    # more stable, still mutable
    "domain":            "weeks",    # rotated, but slower
    "ip_address":        "hours",    # shared infra, VPS, CDN noise
    "c2_protocol":       "months",   # harder to change
    "ttp_pattern":       "years",    # behavior-based, most durable
}

IOC shelf life by indicator type — TTP patterns outlast all other indicator classes

This is why TTP-based detection (ATT&CK techniques) ages far better than hash-based or IP-based detection. Adversaries burn infrastructure faster than they rewrite behavior.

Building Attribution Hypotheses

Attribution is a confidence spectrum, not a binary:

Technical overlap — shared code, infra, certs, compile-time metadata
Behavioral overlap — same TTPs, same targeting profile
Geopolitical context — who benefits, who has capability and motive
Corroboration — do independent sources agree?

Real attribution requires multiple independent lines of evidence. Vendor-assigned cluster names (APT-XX, FANCY-BEAR, etc.) encode specific confidence levels — treat them as hypotheses, not facts.

OSINT Workflow Basics

A minimal repeatable workflow for infrastructure analysis:

# Passive DNS lookup
curl "https://api.mnemonic.no/pdns/v3/{indicator}" | jq '.data[]'
 
# Certificate transparency pivoting
crt.sh/?q=%.target-domain.com
 
# Shodan host profile
shodan host <ip>
 
# VirusTotal pivot
vt graph <indicator>

The goal at this stage is mapping, not attributing. Build the graph first. Ask who later.

Next: hunting for C2 infrastructure using certificate fingerprints.