After the static and dynamic analysis is done, the analyst extracts Indicators of Compromise and pivots — using one IOC to find related samples, infrastructure, and campaign linkages. The workflow, the tools, and the confidence model that makes an IOC report defensible.
Sign in to mark this article as read and track your progress.
An Indicator of Compromise (IOC) is an observable artifact that, when present in an environment, indicates with some level of confidence that a malicious activity has occurred or is occurring. The operative phrase is "some level of confidence" — not all IOCs are equal, and conflating high-confidence indicators with speculative ones is one of the most common failures in analyst reporting.
David Bianco's Pyramid of Pain (2013) remains the most useful framework for thinking about IOC quality:
| IOC Type | Attacker cost to change | Analyst detection value |
|---|---|---|
| File hashes | Trivial (recompile) | Low |
| IP addresses | Low | Low-Medium |
| Domain names | Low-Medium | Medium |
| Network artifacts | Medium | Medium |
| Host artifacts | High | High |
| TTPs (tools, techniques) | Very high | Very high |
File hashes are the easiest IOCs to extract and the easiest for attackers to invalidate. A single bit change produces a different hash. TTP-level indicators — the specific way an attacker uses process injection, the registry keys they habitually modify, the naming patterns in their C2 domains — survive across campaigns, across tool updates, and across infrastructure changes.
This does not mean hash-based IOCs are useless. In the first hours of an incident, hashes are the fastest way to determine whether other machines in an environment have the same file. But the analyst must communicate the confidence level accurately.
Atomic IOCs are indivisible values that cannot be broken down further: file hashes (MD5, SHA-1, SHA-256), IP addresses, domain names, email addresses, URLs. They are easy to extract, easy to share, easy to implement in blocklists, and easy to change.
Computed IOCs are derived from analysis: fuzzy hashes (ssdeep, TLSH), YARA rules, import hashes (imphash), section hashes, packer signatures. These survive cosmetic changes to a binary because they capture structural or behavioural properties rather than exact content.
Behavioural IOCs describe what the malware does: mutex names it creates, registry keys it writes, file paths it accesses, network protocols it uses, API call sequences it follows. These are the hardest to extract because they require dynamic analysis, but they are the most durable.
Static analysis extracts:
Dynamic analysis extracts:
Pivoting is the process of using one IOC to find related artifacts. The goal is to expand from a single sample to an understanding of a campaign's infrastructure, tooling, and potential victim scope.
Hash pivot on VirusTotal: Search the SHA-256 on VirusTotal. On the "Relations" tab, examine:
Domain pivot: If you have a C2 domain, look up its passive DNS history on VirusTotal or RiskIQ/SecurityTrails. Find:
Infrastructure pivot: For a C2 IP, check Shodan and Censys for:
Imphash and YARA pivot on VirusTotal Intelligence (requires premium):
Search imphash:[value] to find all samples with the same import hash. Samples from the same builder share the same import table structure. This surfaces the full sample set for a campaign even when file content has been randomised.
Every IOC in an analyst report must carry a confidence level. A workable three-tier model:
A report that lists 200 IOCs without confidence levels is less useful to a defender than one that lists 20 with clear confidence classifications.
