Systematically collects, categorizes, and distributes indicators of compromise (IOCs) during and after security incidents to enable detection, blocking, and threat intelligence sharing. Covers network, host, email, and behavioral indicators using STIX/TAXII formats and threat intelligence platforms. Activates for requests involving IOC collection, indicator extraction, threat indicator sharing, compromise indicators, STIX export, or IOC enrichment.
Systematically collects, categorizes, and distributes indicators of compromise (IOCs) during and after security incidents to enable detection, blocking, and threat intelligence sharing. Covers network, host, email, and behavioral indicators using STIX/TAXII formats and threat intelligence platforms. Activates for requests involving IOC collection, indicator extraction, threat indicator sharing, compromise indicators, STIX export, or IOC enrichment.
During active incident response to identify and block adversary infrastructure
Post-incident to document all observed adversary artifacts for future detection
When sharing threat intelligence with ISACs, sector partners, or law enforcement
When building detection rules in SIEM, EDR, or network security tools
When enriching IOCs with threat intelligence context for risk scoring
Do not use for behavioral TTP analysis without accompanying technical indicators; use MITRE ATT&CK mapping for behavioral characterization.
Detection Gaps & Validation
Atomic IOCs decay fast, behavioral ones don't: IPs and domains rotate hourly and hashes change with every recompile, so a clean hash match does not mean "not infected." Prioritize durable indicators — registry Run keys, scheduled-task/service names, mutexes, named pipes (e.g. Cobalt Strike \\.\pipe\MSSE-*), and file paths — and pair atomic IOCs with the TTP that produced them.
Pyramid-of-Pain trap: blocking only hashes/IPs lets the actor return in minutes. Treat low-cost indicators as detections, not containment.
Enrichment false-positives: flagging a shared CDN, cloud egress IP, or sinkhole as malicious poisons every consumer of the feed. Validate against passive DNS/WHOIS age and provider ranges before scoring; recently registered + privacy-protected + low VT detections is a stronger signal than VT count alone.
Collection coverage gaps: an IOC absent from one source isn't absent from the host — memory-only artifacts (netscan connections, injected strings) never touch disk, and DNS-log gaps hide tunneling. Pull from memory, EDR, network, and email, not just one.
Validate before distributing: confirm each indicator was directly observed in this incident (not inherited from a report), defang in human-readable output, strip internal IPs/hostnames, and set the correct TLP. Cross-check a sample of IOCs by hunting them across the estate — a true IOC should light up on the known-compromised hosts.
Prerequisites
Access to incident evidence sources: SIEM logs, EDR telemetry, memory dumps, disk images, network captures
Threat intelligence platform (MISP, OpenCTI, ThreatConnect) for IOC management and sharing
IOC enrichment tools: VirusTotal, OTX (AlienVault Open Threat Exchange), Shodan, DomainTools
STIX 2.1 knowledge for structured IOC representation
Sharing agreements with relevant ISACs (FS-ISAC, H-ISAC, IT-ISAC) or sector partners
Workflow
Step 1: Identify IOC Categories
Collect indicators across all categories from incident evidence:
Network Indicators:
IP addresses (C2 servers, staging servers, exfiltration destinations)
Yeti: Open-source platform for organizing observables, indicators, and TTPs
CyberChef: GCHQ's data transformation tool useful for decoding, defanging, and formatting IOCs
Common Scenarios
Scenario: Post-Incident IOC Package for ISAC Sharing
Context: After responding to a Qakbot infection that led to Cobalt Strike deployment, the IR team must package all IOCs for sharing with the Financial Services ISAC (FS-ISAC).
Approach:
Compile all network, host, and email indicators from the investigation
Enrich each IOC with VirusTotal and MISP correlation data
Assign confidence scores based on direct observation vs. secondary correlation
Mark all IOCs with TLP:AMBER for partner sharing
Export as STIX 2.1 bundle and submit to FS-ISAC TAXII feed
Create a human-readable IOC summary report for email distribution
Pitfalls:
Including internal IP addresses or hostnames in shared IOC packages (information leakage)
Sharing IOCs at TLP:WHITE that should be restricted to TLP:AMBER
Not defanging URLs and domains in human-readable reports
Sharing IP addresses of legitimate CDNs or cloud providers as malicious IOCs
