| name | ioc-hunter |
| description | Threat-intel IOC workflow — feed curation (MISP/OpenCTI/vendor/ENISA/CISA), deduplication, confidence scoring (TLP, source reputation, age, sightings), enrichment pipeline to SIEM/EDR, retro-hunt over an N-day window, and lifecycle (expiry + retirement). |
IOC Hunter
Source discipline and TLP respect: IOCs come with a share policy (TLP-RED/AMBER/GREEN/CLEAR). Forwarding to parties the feed contract does not allow is a breach of trust and, in some contracts, of license. Sharing where permitted (intra-industry ISAC, CSIRT-NL, sector PAC) is a net-positive habit.
When to use
IOCs (Indicators of Compromise) are the tactical layer of threat intel: hashes, IPs, domains, URLs, mutexes, certificate fingerprints, JA3/JA4 strings. This skill helps manage feeds, dedup and confidence-score them, plug them into SIEM/EDR, and retro-hunt.
Triggers on:
- A question like "add this IOC feed to our stack", "is this hash known", "retro-hunt the last 30 days against these IOCs", "how do we score IOC confidence", "set up a MISP instance".
- A handoff from
detection-engineer (rule needs IOC input), log-triage or the threat-hunt command (enrichment of findings), malware-triage (extracted IOCs to be integrated).
- A new APT-campaign publication whose IOCs need processing.
- A periodic (quarterly) feed-hygiene review: which feeds deliver value, which do not.
When NOT (handoff)
- Writing a detection rule that consumes the IOC →
detection-engineer. This skill provides the IOC input.
- Triage of the alert that fires from an IOC match →
log-triage.
- A threat-hunt session itself → the
threat-hunt command.
- Malware-sample analysis that produces IOCs →
malware-triage.
- Forensic confirmation of IOC impact →
forensics-assist.
- Strategic CTI (actor profiles, geopolitical context) is out of scope here — that is separate CTI work, not in this skill.
- Vulnerability feed (CVEs) →
cve-triage.
Approach
Six phases. Phase 2 (confidence scoring) and phase 5 (retro-hunt) are where IOC work delivers operational value.
1. Feed curation
Which feeds deserve your SIEM bandwidth? Not all of them.
Source categories:
- Government / national CERT: CISA AIS, NCSC-NL, ENISA feeds, BSI (DE), ANSSI (FR). High-trust, sometimes delayed.
- ISAC / sector PAC: FI-ISAC NL for financial, MS-ISAC for government. Sector-specific relevance.
- Commercial CTI: Mandiant, Recorded Future, CrowdStrike Intelligence, Mandiant Advantage, IntSights/Rapid7, Group-IB. High quality, high price.
- Open-source/community: AlienVault OTX, abuse.ch (URLhaus, MalwareBazaar, ThreatFox), Spamhaus, Emerging Threats. Mixed quality, free or low-cost.
- Vendor-specific threat intel: Microsoft Security Graph, Cisco Talos, Palo Alto Unit 42 — often baked into the product license.
- Internal sources: your own incidents produce the highest-trust IOCs for your organization. Categorize as "internal" with a separate TTL.
Curation criteria:
- Coverage: does the feed cover sectors/regions that touch you?
- Freshness: how quickly after an incident does an IOC appear in the feed?
- Validity: what % of IOCs are still true-positive after 30/60/90 days?
- False-positive history: known noisy feeds (e.g. NRD feeds that flag every newly registered domain) need a separate cadence.
- Format: STIX 2.1 / OpenIOC / MISP event format / CSV. STIX is the de facto standard.
A feed that is not used for matching or retro-hunt does not deserve its ingest slot. Periodically downscale.
2. Deduplication and confidence scoring
One IP can show up in 5 feeds. A hash with 12 sources is not 12× more valuable than one with 1 source — but somewhat more. Confidence model:
- Source-reputation score per feed (kept internally based on TP-rate history). High-trust source = higher weight.
- Age: the older an IOC, the less relevant. Default decay: confidence halves after 30 days; after 90 days it is a retirement candidate unless there is APT context. Some IOC types age faster (IPs > domains > hashes for sustained malware).
- Sightings: number of times reported by different sources. Boosts confidence positively, not linearly.
- TLP: not so much confidence as a sharing restriction. TLP-RED = specific audience only, TLP-AMBER = limited external, TLP-GREEN = community, TLP-CLEAR = open. Sharing discipline: never upgrade TLP without source consent.
- Type-specific:
- Hashes (SHA-256 preferred): highest precision, long life provided the hash does not change. Low false-positive risk.
- IPs: short-lived in cloud context (CDN-shared, ephemeral cloud resources). Drop confidence quickly, retire after 14–30 days unless confirmed APT infrastructure.
- Domains: medium life; sinkholing and takedowns accelerate retirement. Watch out for wildcard-feed noise.
- URLs: short-lived, exploit-kit rotation. Retire fast.
- JA3/JA4 fingerprints: TLS-handshake fingerprint, sustained as long as the malware author keeps the same TLS stack.
- Email addresses / sender domains: medium life, BEC context.
- Mutexes: implementation detail, sustained.
- Yara rules: a pattern, not an IOC, but a functionally related layer — see
malware-triage.
Dedup implementation: MISP/OpenCTI do this natively when events are merged on the same attribute. A custom stack needs its own normalization (canonical form of IPs, lowercased domains, hash-format normalization).
3. Storage and sharing layer
- MISP (open-source) — the de facto standard for threat-sharing platforms in the EU. Event-based, multi-tenant, sharing policy per event/attribute. Strong in the NL/EU community via FI-ISAC and CSIRT-NL.
- OpenCTI (open-source) — more modern, knowledge-graph oriented, better visualization. Imports STIX 2.1 natively.
- Anomali ThreatStream, EclecticIQ, Recorded Future — commercial alternatives.
- Commercial-platform choice is usually contractual with a CTI feed vendor. Open-source self-hosted (MISP) is feasible for medium-size orgs.
Sharing direction:
- Inbound: integrate feeds via MISP-sync, STIX/TAXII feeds, OpenCTI connectors, or API pulls.
- Outbound: what do you generate yourself and share back? Internal IOCs from incidents, thinly confirmed detections. NL FI-ISAC and CSIRT-NL accept contributions. Anonymize where TLP policy requires.
4. Enrichment pipeline to SIEM and EDR
An IOC that does not match anywhere is dead weight. Pipeline to make them active:
- SIEM ingestion: feeds into lookup tables (Splunk lookup files, Sentinel watchlists, Elastic enrich policies). Fresh feed = fresh lookup. Default refresh cadence hourly to daily depending on feed update tempo.
- EDR ingestion: native IOC modules in Microsoft Defender, CrowdStrike Falcon, SentinelOne, Carbon Black accept IOCs as a blocklist or detection trigger. Differentiate detect-only vs. auto-block per type.
- Network tooling: firewall blocklists (IP/domain), DNS-RPZ (recursive policy zone) for domain blocking, proxy/SWG categorization.
- Email gateway: sender domains, hashes for attachments. Microsoft 365 Defender, Proofpoint, Mimecast.
Enrichment discipline: not every feed in every layer. High-confidence actor feeds → block action; lower-confidence feeds → detect-only with a SIEM alert. Aggressive blocking on weak feeds is operational disruption.
5. Retro-hunt and lifecycle
- Retro-hunt on new IOCs: with each new high-confidence feed update, sweep the last N days of logs (typically 30–90 days, depending on retention and compute budget). With
siem-query as the building block.
- Hits triage: a retro-hit is not a confirmed compromise — it can be benign historical traffic. Path to confirmation via
log-triage (was the actor suspicious?) and forensics-assist (was there a follow-on action?).
- IOC lifecycle:
- Active: in scoring, in lookup tables.
- Aging: confidence falling, in detect-only mode.
- Retired: out of active detection. Keep in archive for later retro-hunt.
- Re-promote: an old IOC reappears in a new feed or incident → re-activated with fresh confidence.
- Expiry discipline: feed IOCs have a default TTL from the feed policy. Internal IOCs use a manual expiry (default 90 days, revisable).
6. Verification-loop
Layer 1: scope (feed curation up to date, no feeds nobody reads anymore?), assumptions (IOC source-reputation scoring based on data, not gut feel?), gaps (TLP policy respected on sharing-out, retro-hunt cadence on new high-conf feeds?). Layer 2: feed sources alive (multiple CTI vendors merge or shut down — verify URLs and API status), TLP classification correct (TLP 2.0 since 2022, the old TLP-AMBER+STRICT no longer exists as such), STIX version consistent (STIX 2.1 default in 2024+).
Output
Two modes: feed management (in advance, living) and a hunt report (after a retro-hunt or investigation).
Feed-management mode:
IOC feed inventory
Date: YYYY-MM-DD | Reviewer: <name>
Active feeds:
Name | Category | Format | Update cadence | Source reputation | TLP policy
Per feed:
Coverage: <regions, sectors>
Freshness: <average delay between incident and publication>
Validity rate: <% TPs after 30/60/90 days>
TP-rate trend: <stable / falling / rising>
Decision: <retain / downgrade / replace / drop>
Sharing-out:
Internal IOCs generated: <N>
Shared via: <FI-ISAC NL / MISP-sync / CSIRT-NL>
TLP classification: <per IOC>
Coverage gaps:
<which threat clusters not covered by current feeds>
Hunt report (after retro-hunt on a new IOC set):
IOC retro-hunt — <feed update / campaign name>
Window: last N days | Date: YYYY-MM-DD
Input IOCs:
Hashes: N | IPs: N | Domains: N | URLs: N | JA3/JA4: N
Hits per type:
Hash: N (true-positive: M, false-positive: K, pending triage: L)
IP: N (...)
Domain: N (...)
URL: N (...)
Confirmed sightings:
- <IOC + match context + system + timestamp + handoff>
Pending triage:
- <IOC + reason for uncertainty + next step>
Handoffs:
ir-runbook: <if confirmed compromise>
log-triage: <pending-triage depth>
detection-engineer: <if IOCs basis for a new rule>
forensics-assist: <if post-incident investigation needed>
Verification-loop: ...
References
Categories
