Extracting Iocs

Prerequisites

• Target system, dependencies and environment configured.

Usage

Purpose

Analysis that stays in the analyst's head helps no one. The point of analysing malware is to produce indicators of compromise — the concrete artifacts (hashes, domains, IPs, file paths, registry keys, behaviours) that let defenders detect the same threat across the estate and hunt for existing compromise. This skill covers extracting well-formed, useful IoCs from analysis and understanding which ones are worth the effort. It's where malware analysis connects to detection, hunting, and IR.

When to use it

Throughout and after analysing a sample (static, dynamic, and code analysis all produce indicators). It's the bridge from the malware domain to detection-engineering, threat-hunting, and incident-response — the deliverable that makes the analysis operationally useful.

Procedure

1. Collect indicators from every analysis stage:
   • Static: file hashes (SHA-256), strings (URLs, IPs, domains), embedded config, certificate/PE metadata.
   • Dynamic: dropped file names/hashes, registry keys, mutexes, service/scheduled-task names, and network destinations captured during detonation.
   • Code: decoded C2 config, hardcoded keys/domains, algorithm-generated indicators.
2. Organise IoCs by type, since defenders apply them differently: file (hashes, names, paths), network (domains, IPs, URLs, JA3/TLS fingerprints), and host/behavioural (registry keys, mutexes, process patterns, persistence).
3. Weight them by durability — the Pyramid of Pain applies. This is the key judgement: a hash is trivial for the attacker to change (recompile) and catches only that exact sample; a domain/IP is a bit harder; a behavioural indicator (a persistence pattern, a distinctive process chain, a mutex) forces the attacker to change how they operate. Extract the low-tier indicators (they're cheap and useful for immediate blocking) but invest in the high-tier behavioural ones for durable detection (ties into the threat-intel pyramid-of-pain skill).
4. Validate indicators to avoid false positives. A shared hosting IP, a legitimate domain the malware abuses (a compromised CDN, a common service), or a generic filename will cause false positives if blocked/alerted naively. Confirm an indicator is actually attacker-specific before shipping it.
5. Produce IoCs in a usable, shareable format — a structured format (STIX, or at minimum a clean typed list) so they feed detection tools, threat-intel platforms (MISP), and IR directly. Include context (what the indicator means, confidence).
6. Feed them onward — network/file indicators to blocking and detection, behavioural indicators to detection-engineering (Sigma/YARA), and all of them to threat-hunting to check for existing compromise.

Cheatsheet

collect by stage
  static:   SHA-256 hash, strings (URL/IP/domain), embedded config, PE metadata
  dynamic:  dropped files+hashes, registry keys, mutexes, services/tasks, network dests
  code:     decoded C2 config, hardcoded keys/domains

organise by type (defenders apply differently)
  FILE      hashes, names, paths
  NETWORK   domains, IPs, URLs, TLS/JA3 fingerprints
  HOST/BEHAVIOURAL  registry keys, mutexes, process patterns, persistence

weight by DURABILITY (Pyramid of Pain)
  hash        trivial to change, catches exact sample only   (cheap, still block it)
  domain/IP   moderate                                        (block, expect churn)
  BEHAVIOURAL forces attacker to change tradecraft            (durable — invest here)

validate: shared-IP / legit-abused-domain / generic-name -> false positives. confirm.
format: STIX / clean typed list + context + confidence -> detection, MISP, IR, hunting

Reading the indicators

• A distinctive behavioural indicator (a unique persistence mechanism, a specific process chain, a mutex) = the most valuable output; it survives the attacker recompiling or rotating infrastructure. Invest analysis effort in extracting these.
• File hashes = useful for immediate blocking but low-durability (one recompile and they're stale); extract them, but don't mistake a hash list for lasting detection.
• A C2 domain/IP decoded from config = high-value network indicator for blocking and hunting — but check it's not a legitimate abused service before blocking wholesale.
• A generic filename or shared-hosting IP = a false-positive risk if used naively; validate that it's attacker-specific before shipping it as an IoC.
• Indicators with context and confidence = usable by defenders (who need to know what an indicator means and how much to trust it); a bare list without context causes misapplication.
• A typed, validated, durability-weighted IoC set fed to detection/hunting/IR = analysis turned into defence — the whole purpose.

Pitfalls

• Only extracting hashes. They're the easiest and least durable indicators; an attacker defeats them with a recompile. Extract behavioural indicators too, and weight by durability.
• Shipping indicators without validation. Blocking a shared IP or a legitimate abused domain, or alerting on a generic filename, floods defenders with false positives and can cause outages. Validate first.
• Leaving analysis un-operationalised. IoCs that stay in a report help no one; feed them into detection, blocking, threat-intel, and hunting.
• No context or confidence. Defenders misapply bare indicators; include what each means and how confident you are.
• Treating all indicators as equal. A hash and a behavioural pattern are worlds apart in durability; the pyramid-of-pain weighting is what makes the IoC set strategically useful.

References

• David J. Bianco — The Pyramid of Pain (and the threat-intel pyramid-of-pain skill)
• STIX/TAXII, MISP, and YARA documentation
• The detection-engineering, threat-hunting, and incident-response domains (consumers of IoCs)
• MITRE ATT&CK (behavioural indicators map to techniques)

Inputs

• Relevant source code, logs, network traces, or system specifications.

Outputs

• Analysis findings, security audit report, or generated code artifacts.