IoC Analysis: A Complete Guide for SOC Teams

Indicators of Compromise (IoCs) are the most immediate forensic evidence that a system has been — or is being — attacked. Analyzing them correctly is the starting point of the threat intelligence cycle, but it is also the step where SOC teams make the most costly mistakes: trusting a single feed, ignoring context, or stopping at the IoC when they should climb up to the adversary's TTPs.

What IoCs are and how they are classified

An IoC is any observable artifact that, with a sufficient level of confidence, indicates malicious activity. The security literature has consolidated six main categories:

• File hashes (MD5, SHA-1, SHA-256): the cryptographic identity of a malicious executable or document. They are the most precise, but also the easiest to change — a trivial recompilation generates a completely different hash.
• IP addresses: IPs of C2 (command-and-control) servers, proxies used in exfiltration or scanning sources. They have a lifespan of hours to a few days in active campaigns.
• Domains and URLs: phishing infrastructure, DGA (Domain Generation Algorithm) domains, payload URLs. A domain can be registered and discarded in less than 48 hours.
• Email addresses: senders used in spearphishing. Easily replaced, but useful for historical correlation in prolonged campaigns.
• Registry keys and system artifacts: persistence locations in Windows (Run keys, services, scheduled tasks), mutex names created by malware, characteristic file paths. More specific to the target operating system.
• Network patterns: anomalous User-Agents, JA3/JA3S strings for TLS fingerprinting, beaconing patterns (a fixed C2 communication interval). Harder to rotate than IPs or domains.

IoC vs. IoA vs. TTPs: where each one fits

Confusion between these terms leads to poorly calibrated detection strategies. An IoC answers the question of what was left behind — it is retrospective by nature. An IoA (Indicator of Attack) answers what the attacker is doing right now — it focuses on behavior during execution, such as process injection into lsass.exe or the use of PowerShell to download a payload, regardless of the specific artifact used.

TTPs (Tactics, Techniques and Procedures) are the most abstract and most valuable level: they describe the adversary's operational pattern, catalogued in MITRE ATT&CK. While a hash changes in seconds, a TTP such as using native operating-system tools for persistence can remain stable in an APT group for years. TTP-based detections withstand changes in the attacker's infrastructure.

The Pyramid of Pain: why climbing levels matters

In 2013, David Bianco published the Pyramid of Pain model, which remains one of the most cited conceptual references in threat intelligence. The pyramid describes the relationship between the type of indicator detected and the cost that detection imposes on the adversary:

• Base — Hash values: minimal cost to the attacker (a recompilation), trivial detection for the defender.
• IPs and domains: low to moderate cost — infrastructure is cheap and can be rotated via bulletproof hosting or fast-flux DNS.
• Network and host artifacts: User-Agents, registry keys, specific file names — they require some effort to modify the malware.
• Tools: the specific executable (Cobalt Strike, Mimikatz) — switching tools takes time and resources.
• Top — TTPs: Tactics, Techniques and Procedures. Detecting at the TTP level forces the adversary to rethink the entire attack chain. This is the level that really hurts.

The practical consequence is direct: teams that invest only in IP and hash blocklists spend hours updating lists that the adversary bypasses in minutes. The return on investment in detection grows exponentially as you climb the pyramid.

Sources of IoCs: feeds, OSINT and platforms

No single source covers the full spectrum of threats. A mature threat intelligence strategy combines:

• Commercial feeds: Recorded Future, Mandiant Advantage, CrowdStrike Adversary Intelligence — high confidence, human curation, geopolitical context.
• Free OSINT feeds: AlienVault OTX (Open Threat Exchange), abuse.ch (URLhaus, MalwareBazaar, Feodo Tracker), CIRCL MISP feeds — high volume, variable quality, requiring triage.
• Malware analysis: VirusTotal, ANY.RUN, Hybrid Analysis — execution sandbox, behavior reports, YARA matches, hashes of known families.
• Passive intelligence: SecurityTrails, PassiveTotal (RiskIQ/Microsoft Defender EASM) for historical DNS; Shodan and Censys for fingerprinting exposed infrastructure.
• Structured sharing: MISP platforms with the STIX 2.1/TAXII 2.1 protocol let organizations share IoCs with context, confidence and TLP (Traffic Light Protocol) in an interoperable way.
• Internal collection: firewall, DNS, proxy, EDR and in-house honeypot logs produce IoCs of high contextual relevance — they are observations from your own environment, not generic ones.

How to analyze and enrich an IoC

Receiving an IP or hash from an alert is not the end of the work — it is the beginning. The enrichment process turns raw data into actionable intelligence:

For an IP address: look up geolocation, ASN, abuse history (AbuseIPDB), presence on blocklists (GreyNoise, Spamhaus), exposed ports and services (Shodan), and whether it is a Tor exit node or a commercial VPN. An IP in a data center with a recent C2 history warrants different handling from a legitimate CDN IP that appeared in a false positive.

For a domain: check WHOIS (registration date, registrar, data privacy), historical DNS records (MX, A, CNAME), TLS certificates via crt.sh, reputation on VirusTotal and URLScan.io. Domains registered less than 30 days ago with WHOIS privacy and a free Let's Encrypt certificate have an elevated risk profile.

For a file hash: submit it to VirusTotal for multi-AV detection, analyze the sandbox report (process behavior, registry modifications, network connections), identify the malware family and map it to MITRE ATT&CK. If the hash is new with zero detections, submit it to a private sandbox before blocking — it may be a false positive.

Use in detection: SIEM, EDR, YARA and Sigma

IoCs gain operational power when integrated into detection tools:

In the SIEM, IoCs are consumed via threat intelligence integration (STIX/TAXII, CSV or REST API) and stored in reference lists. Log events (firewall connections, DNS queries, proxy requests) are compared in real time. Sigma rules provide a declarative language to describe log patterns that translate to any SIEM, making detection portable and versionable in repositories such as SigmaHQ/sigma on GitHub.

In the EDR (Endpoint Detection and Response), YARA rules let you describe binary patterns, strings and file structures to detect malware families even when the hash changes. A well-written YARA rule based on unique strings from the malware's source code can detect variants for months.

In the context of threat hunting, IoCs work as initial hypotheses: the analyst starts from a known IoC (e.g. a C2 domain from a documented campaign) and actively searches the environment for evidence of compromise that did not generate an automatic alert — historical connections to the domain, related persistence artifacts, anomalous child processes.

The lifecycle of an IoC

Every IoC ages and must be managed as such. The standard cycle has five phases:

1. Collection: ingestion of the raw indicator from the source (feed, alert, investigation).
2. Triage and enrichment: validation, context, ATT&CK mapping.
3. Active detection: publication in the SIEM/EDR with a defined TTL.
4. Review: periodic reassessment — is the IoC still valid? Did it generate real alerts or only false positives?
5. Expiration or archiving: expired IoCs must be removed from active lists to avoid alert fatigue. The historical record is kept for forensic correlation.

Volatility defines the TTL: hashes of active malware may expire in 30 days, C2 IPs in 7 days, DGA domains in 3 days. TTPs in MITRE ATT&CK do not expire — they are reviewed and updated by the community over the years.

Common limitations and pitfalls

IoCs are ephemeral by adversarial design. The main pitfalls in SOC operations include:

• Alert fatigue from outdated blocklists: legitimate CDN IPs frequently appear in generic feeds, generating volume without value.
• Over-reliance on VirusTotal: zero detections does not mean the file is safe — custom, obfuscated or recent malware may not have a signature yet.
• Lack of context: a malicious IP in a firewall log, without knowing whether the connection was initiated from inside or outside, whether it was blocked or allowed, and which process originated it, has analytical value close to zero.
• Not climbing the pyramid: treating IoCs as a final product rather than a starting point for understanding the campaign and the adversary is the most common strategic mistake in immature SOCs.

Frequently asked questions

What is the difference between an IoC and an IoA?

An IoC (Indicator of Compromise) is forensic evidence that a system has been or is compromised — file hashes, IPs, domains, registry keys. An IoA (Indicator of Attack) focuses on the adversary's behavior during the execution of the attack, such as process injection or the use of living-off-the-land tools, regardless of the specific artifact. IoAs are more stable over time and harder for the attacker to disguise.

Why do IoCs become obsolete so quickly?

Attackers rotate infrastructure with ease: a malicious domain can be changed in minutes, an IP in hours, and the hash of an executable changes with a single compilation. David Bianco's Pyramid of Pain quantifies this problem — at the base are the artifacts easiest to change (hashes, IPs), at the top are the TTPs, which require the adversary to rewrite entire campaigns.

What are the main sources of IoCs?

Commercial feeds (Recorded Future, Mandiant, CrowdStrike), free OSINT feeds (AlienVault OTX, abuse.ch, URLhaus, Feodo Tracker), malware analysis platforms (VirusTotal, ANY.RUN), sharing via MISP and STIX/TAXII, and your own internal collection of logs, endpoints and honeypots. Always evaluate confidence and context before blocking.

How does a SIEM consume IoCs in practice?

The SIEM receives IoCs via STIX/TAXII or REST API, stores them in reference lists and compares them with events in real time — firewall, DNS, proxy and EDR logs. When there is a match, it generates an alert correlated with the severity and source of the indicator. Sigma rules make it possible to translate IoCs into detections portable across SIEMs.

What is IoC enrichment and why is it necessary?

Enriching an IoC means adding context beyond the raw value: geolocation and ASN for IPs, WHOIS and PassiveDNS for domains, a sandbox report and malware family for hashes. Without enrichment, an analyst cannot prioritize — a single hash may be irrelevant or part of an active APT campaign.

How does Decripte use IoCs in the SOC?

Decripte's SOC operates 24x7, integrating OSINT and commercial feeds into the DIC platform (Detection, Investigation and Correlation). IoCs are enriched automatically, correlated with alerts from the client's environment and promoted to investigations when they reach a confidence threshold, climbing from raw evidence up to the TTP to produce actionable intelligence.

References

• MITRE ATT&CK Framework — a base of TTPs organized by tactic, technique and sub-technique, with mappings to APT groups and documented campaigns.
• MISP Threat Sharing Platform — an open-source platform for collecting, storing and sharing IoCs structured in STIX/TAXII.
• David Bianco, The Pyramid of Pain (2013) — a conceptual model on the cost imposed on the adversary by different types of indicators.
• AlienVault OTX — a collaborative OSINT feed with millions of IoCs shared by the security community.
• abuse.ch — a set of projects (URLhaus, MalwareBazaar, Feodo Tracker, ThreatFox) focused on malware and C2 infrastructure.

Continuous IoC monitoring for your company

Maintaining an effective threat intelligence operation requires infrastructure, processes and analysts trained to distinguish signal from noise — from the sole proprietor who needs basic threat visibility to the enterprise with hundreds of critical systems. Decripte's SOC operates 24 hours a day, 7 days a week, ingesting IoC feeds, automatically enriching the indicators relevant to each client and escalating to investigation when confidence justifies action.

Companies from 1 to more than 100,000 employees find in Decripte a service model calibrated to their size: from the free threat monitoring plan, which already delivers visibility of IoCs associated with your domain, to advanced plans with TTP-based detection and incident response. Explore the plans or start for free and see in minutes which indicators of compromise are associated with your environment today.