Understanding IOCs: A Practical Primer
A grounded introduction to Indicators of Compromise — what they are, where they break, and how to actually use them inside a SOC workflow without drowning in false positives.
What is an IOC, really?
An Indicator of Compromise (IOC) is any observable artefact that suggests an intrusion: an IP address, a domain, a file hash, a registry key, a user-agent string. The concept is simple. The hard part is using them without turning your SIEM into a noise machine.
The four classic families
| Family | Examples | Typical shelf life |
|---|---|---|
| Network | IPs, domains, URLs | Hours to weeks |
| File | MD5, SHA-1, SHA-256, imphash | Short — trivially mutated |
| Host | Registry keys, mutexes, scheduled tasks | Days to months |
| Behavioural | TTPs, command-line patterns | Months to years |
The higher you climb the pyramid of pain, the harder it is for an adversary to change the indicator. Hashes are cheap to rotate. TTPs are expensive.
Where IOC pipelines break
- Confidence is missing. A raw hash list with no source, no first-seen, no context will produce false positives at scale.
- Context decays. An IOC from 2021 might now point to a legitimate service.
- Enrichment is lazy. Blocking an IP without checking whether it is a shared CDN will page your on-call.
A simple intake checklist
- Source and trust level
- First-seen / last-seen
- Associated campaign or family
- Suggested action (alert / block / hunt)
- Expiration date
If an IOC feed does not give you at least the first three, treat it as hunting material — not blocking material.
Using Mlab for IOC triage
On mlab.sh you can paste any IP, domain, hash, or URL and get a normalized answer in seconds. That is the fast, read-only path. For production pipelines, the developer API gives you the same data as JSON.
IOCs are a tool, not a religion. Use them to accelerate investigation, not replace it.
