IOC Types and Confidence

IOC Taxonomy

An indicator of compromise is a forensic artifact or observable that suggests a system may have been compromised or that adversary activity is present. The word "may" is intentional. Indicators are probabilistic, not deterministic. A malicious IP appearing in a firewall log does not confirm a breach. It confirms that something in your environment communicated with an address associated with adversary infrastructure at some point. What you do with that depends on the confidence level, the context, and what other signals are present.

Network indicators include IP addresses, domain names, and URLs. An IP address identifies a server that was used in a campaign. A domain name is one step more durable than an IP because the attacker can point a domain at new IPs without changing the domain itself. A URL is the most specific: a particular path on a particular host. Network indicators are highly shareable, easy to automate into blocklists, and fast to decay. An actor who notices their infrastructure is being burned will rotate it quickly.

Host indicators include file hashes, file names, registry keys, mutex names, and file paths. File hashes (MD5, SHA-1, SHA-256) are the most common host indicator. They are deterministic for a specific file: the same file always produces the same hash. This is also their weakness. Recompiling a binary with a minor change produces a completely different hash. Attackers who know their malware is burned recompile and redeploy. SHA-256 is preferred over MD5 for hash verification due to MD5's collision vulnerabilities, though neither solves the trivial recompilation problem.

Email indicators cover sender addresses, subject line patterns, attachment names, and email header fields. They are commonly extracted from phishing campaigns and are useful for blocking delivery of follow-on waves after an initial attack. Like IP addresses, email sender domains rotate quickly as actors burn through infrastructure.

Behavioral indicators describe how an attacker operates rather than what artifacts they leave. A behavioral indicator might be: "actor executes PowerShell with base64-encoded content, immediately followed by a process injection into svchost.exe, followed by LDAP reconnaissance against the domain controller." No specific hash, no specific IP, no specific domain. The behavior is the indicator. These are the most durable indicators because they describe what an actor must do to accomplish their objective, not the particular tools they use to do it.

The Pyramid of Pain

David Bianco's Pyramid of Pain is the most useful single framework for understanding indicator value in threat intelligence. It organizes indicators by the cost they impose on an adversary when defenders detect and respond to them. The pyramid has six levels. The bottom levels are easy to detect but easy for the attacker to change. The top levels are hard to detect but almost impossible for the attacker to change without fundamentally altering how they operate.

Hash values sit at the base. Detecting and blocking a specific file hash is easy. But changing a hash costs an attacker almost nothing: recompile with a minor modification, pad the binary, swap a string, and the hash changes completely. Every antivirus vendor knows this. Hash-based detection is reactive: by the time you have the hash, the sample has already executed somewhere. Hashes still have value as confirmation and forensic evidence, but as a predictive or proactive detection mechanism, they are the weakest indicator type.

IP addresses are one level up. Blocking an IP causes mild disruption for an attacker, who must pay for a new server or rotate to a different bulletproof hosting provider. With automation, this can happen in under an hour. IP blocking is still worthwhile for known-bad ranges, but treating IP blocklists as a primary defense is an illusion. Sophisticated actors maintain large pools of rotating infrastructure specifically to defeat IP-based blocking.

Domain names impose somewhat more cost. Registering a new domain, setting up DNS, and deploying it takes longer than rotating an IP. Some actors use DGA (domain generation algorithms) to produce large numbers of fallback domains, but even then, the specific algorithmic patterns can become signatures. Domain indicators are more durable than IPs but still decay within days to weeks for active campaigns.

Network artifacts such as specific HTTP headers, User-Agent strings, URI patterns, and SSL certificate fingerprints start to impose real pain. These are harder to change because they are often baked into implant behavior. An attacker who changes their Cobalt Strike team server configuration, beacon profile, and SSL certificate all at once while an active campaign is running introduces operational risk. The Pyramid starts to bite here.

Tools cause significant pain. If defenders can identify and detect the specific malware family, RAT, or post-exploitation framework an actor uses, the actor must switch tools. Developing or acquiring a new tool is expensive and time-consuming. YARA rules that detect an actor's custom implant, or behavioral signatures that identify Cobalt Strike beaconing patterns regardless of configuration, impose this cost.

TTPs, at the apex, are the most valuable detections. An attacker's TTPs describe their fundamental operational behavior. To change TTPs, an actor must retrain, redevelop, and potentially rebuild their entire intrusion methodology. Detections anchored at TTP level are almost immune to infrastructure rotation, toolset changes, or recompilation. A detection that fires whenever PowerShell encodes a base64 payload and spawns a child process that injects into a system binary will catch the actor whether they are using Cobalt Strike, Metasploit, or a custom implant.

IOC Confidence Scoring

Confidence scoring answers: how certain are we that this indicator is genuinely associated with adversary activity, and how certain are we that it is still relevant? Without confidence scores, every indicator in a blocklist gets treated identically, which means a high-fidelity TTP-level detection and a low-confidence IP from a single source with no corroboration both block traffic or fire alerts with equal authority. That is not a workable operating model at scale.

Source quality is the first factor. An IP address extracted from a vetted government ISAC report with documented campaign attribution carries different weight than the same IP from a public pastebin scrape. Source categories, from most to least reliable, generally run: direct victim telemetry (you observed it in your own environment), trusted sharing partner with documented methodology, commercial intelligence provider with disclosed collection practices, open-source research from reputable vendors, and unvetted public feeds. Weight accordingly.

Corroboration is the second factor. An indicator seen in a single report is low confidence. The same indicator appearing in three independent reports from different vendors using different collection methods is high confidence. Independence is critical: if three vendors are all citing the same original source, that is one data point, not three. True corroboration requires independent collection paths reaching the same conclusion.

Recency determines whether an indicator is still operationally relevant. An IP address from a campaign six months ago may have been decommissioned, taken over by a sinkhole, or repurposed by an unrelated actor. A domain registration that expired and was re-registered is no longer the actor's. Age decay should be factored into any confidence score: technical indicators depreciate quickly, behavioral TTPs depreciate slowly.

Context specificity affects confidence in a different direction: does this indicator apply to your environment? An IP address associated with attacks on Japanese financial institutions is a lower-confidence signal for a North American healthcare provider than the same IP associated with attacks on healthcare targets globally. Sector relevance, geographic relevance, and organizational size relevance all affect whether a given indicator should trigger defensive action in your specific context.

IOC Lifecycle

An indicator of compromise does not remain valid indefinitely. It has a lifecycle that begins at collection and ends when the indicator is retired as no longer reliable or relevant. Managing this lifecycle is one of the least glamorous and most important parts of CTI operations. A blocklist full of stale indicators wastes analyst time on false alerts and creates a false sense of coverage.

Collection is the first stage. The indicator is observed or received from a source and logged with its provenance: where it came from, when it was collected, and what context accompanied it. Provenance is essential because it determines the indicator's starting confidence and enables reassessment if the source is later found to be unreliable.

Validation confirms the indicator is not already known as benign. IP addresses must be cross-checked against CDN ranges, known benign scanning services (Shodan, Censys scan ranges), and your organization's own infrastructure. Domains must be checked against newly registered domain feeds, DGA dictionaries, and parking services. A surprising fraction of "malicious" indicators in public feeds are shared scanning infrastructure, CDN exit nodes, or research honeypots.

Enrichment adds context: geolocation, ASN and hosting provider, registration date, passive DNS history, associated malware families, and ATT&CK technique mappings where available. Enriched indicators are significantly more actionable than bare IOCs. A bare IP address tells an analyst nothing. An IP address with ASN attribution to a known bulletproof hosting provider, associated with three known malware families, first observed in a specific campaign, tells an analyst a great deal.

Deployment moves the indicator into defensive use: SIEM watchlist, firewall blocklist, EDR deny list, or proxy block. The deployment tier should match confidence level. High-confidence indicators with strong corroboration can go directly to blocking. Low-confidence indicators should go to alerting-only so analysts can review before action is taken.

Review and retirement are where most CTI programs fail. Indicators should be reviewed on a schedule tied to their type: technical indicators (IPs, hashes) should be reviewed within 30 days. Domain indicators within 90 days. Behavioral indicators can persist longer but should still be reviewed annually for continued relevance. Indicators that fail review should be retired, not left in place to accumulate false positives indefinitely.

Indicator Context

A bare indicator without context is an obstacle, not an asset. When an analyst receives an alert that an internal host communicated with a flagged IP, the useful question is not "is this IP bad" but "what does this IP tell us about what happened and who did it." Answering that question requires context that goes well beyond the indicator itself.

Kill chain position is one of the most important context elements. Does this indicator appear in initial access (phishing delivery IP), command and control (beacon endpoint), or exfiltration (destination of outbound data transfer)? The kill chain position tells the analyst what phase of the attack they are observing and what is likely to have come before and after. A C2 indicator means dwell time has already occurred. An exfiltration indicator means data has likely already left.

Actor attribution gives the indicator meaning beyond the specific campaign. If an IP address is associated with a known APT group, the analyst can immediately apply existing knowledge about that actor's TTPs, typical targets, and usual post-exploitation behavior. Attribution is probabilistic, but even low-confidence attribution to a category (financially motivated actor vs nation-state) changes the response priority and scope.

Related indicators extend the value of any single IOC through pivoting. A domain leads to its IP. That IP leads to other domains sharing the same infrastructure. Those domains lead to certificate fingerprints. Certificate fingerprints lead to additional IPs. A single IOC with good enrichment can open a pivot chain that maps a significant portion of an actor's infrastructure. Chapter 5 covers this pivot workflow in detail in the context of intel-driven hunting.

False positive risk is context that often gets neglected. An IP on an APNIC range in a region associated with threat activity is not the same as an IP that appears in multiple vendor reports with direct evidence of malicious use. Blocklisting a shared hosting IP because it appeared once in a low-fidelity feed is how teams get an angry call from a business partner whose legitimate web presence just went dark. Context includes knowing the limitations and false positive profiles of your sources.

IOC Quality vs Quantity

The most common indicator program failure is optimizing for quantity. Teams subscribe to more feeds, ingest more indicators, build bigger blocklists, and measure success by the number of IOCs in the database. At a certain scale this approach produces nothing but alert fatigue, and alert fatigue produces the same outcome as no detection at all: analysts stop investigating.

Feed fatigue is real and well-documented. A SOC that receives 50,000 threat feed hits per day and closes 80% without investigation because they are known false positives has not built a CTI-enhanced detection capability. It has built a noise machine. The time spent handling low-fidelity feed hits is time not spent investigating higher-priority signals. The opportunity cost is significant.

Curation is the solution. A curated set of 500 high-confidence, context-enriched, recently validated indicators will outperform a firehose of 500,000 bare IOCs every time. Curation requires human judgment: reviewing sources, applying confidence scoring, validating against environment, and retiring stale indicators. It is more work than subscribing to a feed and ingesting everything, but it produces a system analysts trust and use rather than one they suppress.

Feed evaluation should be a regular practice. Measure the true positive rate of each feed: how many hits from this feed resulted in confirmed malicious activity versus false positives? Feeds with consistently poor TP rates should be deprioritized or eliminated. Feeds that consistently surface high-confidence, well-contextualized indicators should get more attention and integration.

Internal telemetry often outperforms external feeds for detection. IOCs observed directly in your own environment, extracted from endpoint forensics or network captures during incident response, carry the highest possible confidence because you have direct evidence of malicious use in your specific context. Building a program to capture, enrich, and operationalize internal indicators is usually more valuable than adding another external feed subscription.