Every day, SOC analysts and threat intelligence teams are handed a list of suspicious indicators — an IP address flagged by a firewall, a domain that showed up in a phishing alert, a file hash from an EDR detection. The instinct is to look it up: paste it into VirusTotal, check it against a threat feed, move on. That instinct is understandable. It is also systematically insufficient.
Single-source lookups are fast and familiar, but they answer one narrow question: does this vendor know about this indicator? That is not the same as asking whether the indicator is actually malicious, how confident you should be, what it is connected to, or whether you have seen it before across your environment. IOC enrichment is the process that closes that gap — querying multiple intelligence sources simultaneously, normalizing the results, and producing a composite picture that an analyst can actually act on.
This article explains how that process works, what it surfaces for each indicator type, and how to integrate it into daily SOC operations.
What Are Indicators of Compromise?
An indicator of compromise is any observable artifact that suggests a system or network may have been involved in malicious activity. The most common types are:
- IP addresses — source or destination IPs seen in traffic logs, firewall alerts, or network captures
- Domains — hostnames used for command-and-control, phishing infrastructure, or malware distribution
- File hashes — MD5, SHA-1, or SHA-256 fingerprints of executables, documents, or scripts
- URLs — full uniform resource locators, including path and query parameters, which carry more context than bare domains
- File paths — filesystem locations associated with known malware artifacts or persistence mechanisms
Each type is different in what it reveals and how quickly it becomes stale. IP addresses rotate across hosting providers. Domains get sinkholed or re-registered. Hashes are trivially modified to evade detection. A good enrichment workflow accounts for these differences rather than treating all IOCs as interchangeable strings.
The Problem with Single-Source Lookups
When an analyst queries a single threat intelligence platform, they get that platform's view of the world. That view is shaped by the platform's data sources, update cadence, geographic coverage, and commercial incentives. None of those factors are visible in the result.
Three failure modes appear consistently:
False positives from vendor bias. Some platforms are aggressive classifiers — they flag infrastructure that shares IP space with known bad actors, or domains that match superficial patterns, without evidence of actual malicious use. If you treat a single vendor's verdict as ground truth, you will act on bad data.
False negatives from coverage gaps. No single source sees everything. A newly registered phishing domain may not yet appear in one feed but may already be flagged in passive DNS data or a regional threat sharing community. A hash that evades one sandbox may detonate cleanly in another with different configuration.
Incomplete context. Even a correct malicious verdict from a single source tells you little about attribution, campaign association, related infrastructure, or how the indicator fits into your environment. Without that context, triage becomes guesswork.
The practical consequence is wasted analyst time: chasing alerts that turn out to be clean, missing alerts that should have been escalated, and making triage decisions without the information needed to prioritize correctly.
How Multi-Source Enrichment Works
Multi-source enrichment addresses these problems by querying many intelligence sources in parallel, then processing the results into a unified, analyst-readable output. The pipeline has four stages:
Parallel queries. Rather than querying sources sequentially, a well-designed enrichment system dispatches requests to all configured sources simultaneously. This keeps latency acceptable even when the source count is high. DFIR Lab's IOC Enrichment API queries 14+ sources in parallel, covering threat feeds, WHOIS providers, passive DNS repositories, sandbox results, and abuse databases.
Normalization. Different sources return data in different schemas. One may express a verdict as a numeric score, another as a categorical label, a third as a list of tags. Normalization maps these varied representations into a common structure so downstream logic can operate on consistent fields.
Deduplication. Multiple sources often report overlapping data — the same WHOIS registrar, the same ASN, the same detection name from different AV engines. Deduplication removes redundant information so the analyst sees a clean summary rather than a wall of repeated data.
Consensus scoring. Once results are normalized and deduplicated, a scoring model aggregates the verdicts. Sources are weighted by their historical reliability for the indicator type in question. The output is a confidence-adjusted risk score alongside the raw evidence, so the analyst can see both the conclusion and the reasoning behind it.
IOC Types and What Enrichment Reveals for Each
IP Addresses
For a suspicious IP, enrichment surfaces:
- Geolocation — country, city, and coordinates. Useful for identifying unexpected geographic origins and for policy-based blocking decisions.
- ASN and hosting provider — autonomous system number and the organization that owns the IP block. Bulk hosting providers and VPS services are frequently abused; ASN context can indicate infrastructure type at a glance.
- Abuse history — reports submitted to abuse databases (Spamhaus, AbuseIPDB, and similar), including the nature and recency of reports.
- IP reputation — aggregate verdict from threat feeds, including whether the IP has been observed in scanning activity, brute-force attempts, botnet traffic, or malware distribution.
- Open ports and banners — where available, passive scan data indicating what services were exposed, which helps characterize whether the host is a legitimate server or opportunistic attack infrastructure.
Domains
Domain enrichment draws on:
- WHOIS data — registrant, registrar, creation date, expiration date, and name servers. Newly registered domains (under 30 days old) with privacy-protected registrants are a significant risk signal.
- Passive DNS — the historical record of what IP addresses the domain has resolved to, and when. This reveals infrastructure reuse: attackers often park multiple malicious domains on the same IP, and passive DNS exposes those connections.
- Domain reputation — categorical and scored verdicts from web filtering services, threat feeds, and phishing detection systems.
- Certificate transparency — subdomains discovered through CT log monitoring, which can reveal the full scope of infrastructure associated with a domain.
File Hashes
Hash enrichment aggregates:
- Antivirus detections — the number and identity of AV engines that flag the hash, and the detection names they use. Detection names often encode malware family, which aids attribution.
- Sandbox behavioral results — dynamic analysis from automated sandbox systems. Behavioral indicators (network connections made, registry keys written, processes spawned) are more meaningful than static detection verdicts alone.
- File metadata — PE compilation timestamps, embedded strings, imported libraries, and packer signatures where available.
- Known-good correlation — whether the hash appears in software allowlists or trusted software repositories, which is critical for reducing false positives on dual-use tools.
URLs
Full URL enrichment goes beyond domain-level checks:
- Redirect chain analysis — many malicious URLs pass through multiple redirectors before reaching the final destination. Enrichment follows the chain and inspects each hop.
- Landing page classification — the content type and category of the final destination: phishing login form, malware download, exploit kit landing page, or benign site.
- URL shortener resolution — shortened URLs are resolved to their targets before enrichment begins.
- Historical snapshots — archived versions of the page from web cache services, useful when the URL has been taken down since it was first observed.
Operationalizing Enrichment
Knowing how enrichment works is only useful if it is embedded in the workflows where decisions are made.
SIEM integration. Most modern SIEM platforms support external enrichment via lookup tables or REST API calls triggered on field values. Configuring your SIEM to automatically enrich IP and domain fields in high-priority alert categories removes manual lookup steps from the analyst workflow entirely. Alert context arrives pre-enriched, with reputation scores and metadata already attached.
SOAR playbooks. SOAR platforms are the natural home for automated IOC enrichment. A playbook triggered by a phishing alert can extract all IOCs from the email — sender IP, links, attachments — enrich them in parallel, evaluate the consensus scores against a threshold, and route the ticket to the appropriate queue without analyst involvement for clear-cut cases. Analysts handle the ambiguous middle tier, where human judgment adds value. The DFIR Lab Enrichment API supports batch mode, so a single API call can enrich all IOCs from an alert simultaneously, keeping playbook execution time low.
Automated triage scoring. Enrichment scores can feed a composite alert priority model. An alert involving an IP with high abuse history, a domain registered in the last 72 hours, and a hash detected by 30+ AV engines is a different priority than an alert involving a clean IP and an unknown hash. Enrichment makes that distinction computable rather than requiring an analyst to manually assemble the picture.
Practical Example: Enriching a Suspicious IP
A firewall alert fires on outbound traffic to 203.0.113.47. Here is what a multi-source enrichment workflow produces.
Step 1 — Dispatch parallel queries. The enrichment API sends simultaneous requests to geolocation providers, AbuseIPDB, Spamhaus, threat feed aggregators, and passive scan data sources.
Step 2 — Normalize results. Geolocation returns country: CN, ASN: AS4134 (China Telecom). AbuseIPDB returns 47 reports in the last 90 days, categories including port scanning and brute force. Two threat feeds return a malicious verdict; one returns no data; one returns a low-confidence suspicious verdict.
Step 3 — Deduplicate. The ASN is reported by three sources; it appears once in the output. The port scanning category is reported by multiple abuse entries; the count is aggregated.
Step 4 — Score. The consensus model weights the two malicious verdicts, the high abuse report count, and the ASN's reputation for hosting attack infrastructure. Output: risk score 87/100, confidence high.
Step 5 — Act. The score exceeds the automated block threshold in the SOAR playbook. A firewall rule is queued for review, the alert is escalated to Tier 2 with full enrichment context attached, and the IP is added to the internal threat intel watchlist.
Total analyst time before a decision lands in their queue: zero. Time to reach a confident verdict once they review: under two minutes.
Using the DFIR Lab CLI, an analyst can run this manually in seconds:
dfir-cli enrich 203.0.113.47The same enrichment runs against 14+ sources and returns structured JSON or a formatted table, depending on the output flag used.
Try IOC enrichment yourself with our free exposure scanner for domain/IP analysis, or the phishing email checker for email-based threat indicators.
See multi-source enrichment in action. The DFIR API Playground aggregates 14+ threat intelligence sources into a single normalized JSON response — 10 free calls per week, no signup. Paste in an IP, domain, hash, or URL and read every source's verdict side by side instead of opening 14 browser tabs.
Conclusion
Single-source IOC lookups are a starting point, not an answer. The gap between "one vendor flagged this" and "we have high confidence this is malicious and here is why" is where investigations stall, false positives accumulate, and analysts burn time doing work that should be automated.
Multi-source enrichment closes that gap by aggregating signal from many independent sources, normalizing the results into a consistent structure, and producing a scored, contextualized verdict that supports faster and more accurate decisions — whether that decision is made by a human analyst or a SOAR playbook.
DFIR Lab's IOC Enrichment API queries 14+ sources across IPs, domains, hashes, and URLs, with batch mode support for high-volume workflows. Free accounts include 100 credits per month (approximately 3–5 credits per lookup). Use code LAUNCH50 for 50% off your first paid month.
Start enriching at platform.dfir-lab.ch, or install the CLI and run dfir-cli enrich <ioc> against your first indicator today.