IOC Types & Lifecycle

What Is an Indicator of Compromise (IOC)?

An Indicator of Compromise is any observable artifact — an IP address, a domain name, a file hash, a URL, an email address — that provides evidence a system or network has been breached. IOCs are the breadcrumbs attackers leave behind. Some are intentional (C2 infrastructure the attacker needs to maintain access), and some are accidental (a log entry they forgot to delete, a DNS query they did not expect you to capture).

Think of IOCs as forensic evidence at a crime scene. A fingerprint on a window frame does not tell you how the burglar broke in or what they were after, but it tells you someone was here who should not have been. That fingerprint lets you link this break-in to other crimes with the same prints. IOCs work the same way: they let you detect, correlate, and attribute malicious activity.

Here is a concrete example. Your SIEM fires an alert: the host WIN-SERVER-01 made a DNS query for update-service.darkoperator.com at 03:14 AM. You check the domain against your threat intelligence feeds and find it tagged as a Cobalt Strike C2 domain, first reported 6 days ago. That domain is an IOC. It does not tell you how the attacker got in (phishing? RDP brute force?), but it tells you the host is compromised and communicating with adversary infrastructure right now.

The Five Core IOC Types

Not all IOCs are created equal. Each type has different longevity, specificity, and operational value. The table below summarizes the five types you will work with daily, followed by a deep dive into each.

IP Addresses

IP addresses are the most common IOC type and the first thing most analysts check. When a Wazuh alert fires showing outbound traffic to 185.220.101.42, your first instinct is to look up that IP — and you should. That particular address is a known Tor exit node, which means traffic to it could be an attacker exfiltrating data through the Tor network, or it could be a legitimate user browsing the internet with Tor Browser.

IPv4 addresses are the norm, but IPv6 IOCs are increasingly common as dual-stack networks proliferate. Pay attention to:

• Public vs private: An internal RFC 1918 address (10.x.x.x, 172.16-31.x.x, 192.168.x.x) is not an IOC in the traditional sense — it is an internal asset identifier. The IOC is the external address it is talking to.
• Tor exit nodes: Lists like the Tor Project's bulk exit list rotate frequently. An IP that was a Tor exit yesterday might be a legitimate web server tomorrow.
• VPN/proxy IPs: Commercial VPN providers cycle IP pools. One address may serve thousands of users, both benign and malicious. Blocking it creates collateral damage.
• Cloud provider IPs: 52.x.x.x (AWS), 104.x.x.x (Azure/Cloudflare) — blocking these is almost never viable.

# Example: Checking an IP against a Wazuh alert
Source IP: 185.220.101.42
GeoIP: Germany (DE)
ASN: AS205100 - F3 Netze e.V.
Tor Exit Node: Yes (confirmed via TorDNSEL)
First Seen in Feeds: 2026-01-14
Threat Tags: tor-exit, anonymization-service
Confidence: Medium — Tor exit ≠ malicious, but requires investigation

Key limitation: IP addresses are cheap and fast to rotate. An attacker using bullet-proof hosting can spin up a new VPS with a fresh IP in minutes. If your detection strategy relies solely on blocking known bad IPs, you are playing whack-a-mole against an adversary who has an infinite supply of moles.

Domain Names

Domains are a step up from IPs in terms of stability and intelligence value. While an IP can be rotated in seconds, domains require registration, DNS propagation, and sometimes reputation building. Attackers use several domain strategies:

• Static C2 domains: Registered months in advance, sometimes using expired legitimate domains to inherit their reputation. Example: evil-update.example.com points to a Cobalt Strike team server.
• Domain Generation Algorithms (DGA): Malware generates hundreds of pseudo-random domains daily (xk9f2m.com, p3jd8s.net). The attacker registers only a few, but the malware queries all of them. DGA domains are recognizable by their randomness — no human would type xk9f2m.com.
• Typosquatting: micros0ft-update.com, gooogle.com, arnazon.com. These exploit human error and are common in phishing campaigns.
• Newly registered domains (NRDs): A domain registered yesterday that is already receiving DNS queries from your network is suspicious by default. Legitimate services do not spin up brand-new domains for production traffic.

# Example: Suspicious domain from DNS logs
Query: update-service.darkoperator.com
Type: A record
Response: 198.51.100.23
First Seen: 2026-02-17 (6 days ago)
Registrar: Namecheap
Registration Date: 2026-02-15
Tags: cobalt-strike-c2, newly-registered
Confidence: High — known C2 infrastructure, fresh registration

File Hashes

A hash is a cryptographic fingerprint of a file. Change one bit of the file, and the hash is completely different. This makes hashes extremely specific — a SHA256 hash uniquely identifies exactly one file — but also trivially evadable. An attacker who recompiles their malware with a single modified comment produces a binary with identical behavior but a completely new hash.

Three hash algorithms matter for threat intelligence:

# Example: Cobalt Strike beacon hash
MD5:    b326b5062b2f0e69046810717534cb09
SHA1:   f572d396fae9206628714fb2ce00f72e94f2258f
SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
File:   beacon_x64.dll (stageless, HTTPS listener)
Family: Cobalt Strike 4.9
Tags:   cobalt-strike, rat, post-exploitation

URLs

A URL is more specific than a domain because it includes the full path. The domain legitimate-cdn.com might host millions of files, but the URL http://legitimate-cdn.com/images/../../../upload/shell.php points to a web shell an attacker uploaded through a path traversal vulnerability.

URLs are common in phishing campaigns (the link in the email), drive-by downloads (the iframe source), and malware staging (the URL the dropper fetches stage-two from). They tend to be short-lived — attackers rotate paths frequently, and hosting providers take down malicious content. A URL IOC from 48 hours ago may already be dead.

# Example: Malware staging URL
URL: https://cdn-images-hosting.com/assets/js/update/stage2.exe
Host: cdn-images-hosting.com
Path: /assets/js/update/stage2.exe
Last Seen Active: 2026-02-18
Status: HTTP 200 (still live as of scan)
Content-Type: application/x-msdownload
SHA256 of payload: 7d8a3f...
Tags: emotet-loader, stage2-dropper

Email Addresses

Email addresses appear in phishing IOCs as sender addresses. They are useful for tracking campaigns — the same sender address across multiple phishing waves indicates a single actor — but they are easily spoofed. An email "from" ceo@yourcompany.com does not mean it actually came from that address. DMARC, SPF, and DKIM help verify authenticity, but many organizations still do not enforce them.

Email IOCs are primarily used for:

• Retroactive mailbox searches (find everyone who received mail from hr-benefits@company-update.net)
• Campaign clustering (link 15 phishing reports to the same sender)
• Feed enrichment (connect a sender address to a known phishing kit)

Other IOC Types Worth Knowing

Beyond the big five, you will occasionally encounter:

• Registry keys: Windows-specific. Persistence mechanisms like HKLM\Software\Microsoft\Windows\CurrentVersion\Run\malware.exe. Highly specific but only relevant in Windows forensics.
• Mutexes: Names used by malware to prevent multiple instances. Finding Global\UNIQUESTRING123 on a host is strong evidence of a specific malware family.
• JA3/JA3S fingerprints: Hashes of TLS client/server hello parameters. They fingerprint the TLS implementation, not the content. Useful for identifying C2 traffic that mimics legitimate HTTPS but uses a unique TLS stack.
• Certificate thumbprints: SHA1 hashes of X.509 certificates. If an attacker reuses the same self-signed cert across C2 servers, the thumbprint becomes a high-confidence IOC.

The Pyramid of Pain

David Bianco's Pyramid of Pain is the most practical framework for understanding IOC value. It ranks indicator types by how much pain your blocking causes the attacker — that is, how expensive it is for the adversary to change that indicator and continue their operation.

Click to enlarge

From the bottom (easiest for attackers to change) to the top (hardest):

The key insight: Most SOC analysts spend their days at the bottom of the pyramid — blocking hashes, IPs, and domains. This is necessary work, but it is the least painful for the attacker. A mature SOC invests in detection at the top — behavioral rules that catch TTPs regardless of which specific tools, domains, or IPs the attacker uses.

As a practical example: blocking the SHA256 hash of a specific Emotet payload costs the attacker nothing — they repack the binary and the hash changes. Blocking the C2 domain costs them a few dollars and an hour of setup. But detecting the TTP "Word document with macro that spawns PowerShell to download and execute a remote payload" catches Emotet, QakBot, IcedID, and any future malware that uses the same delivery technique — regardless of hashes, IPs, or domains.

The IOC Lifecycle

IOCs are not static facts. They are living data points that move through a lifecycle from the moment they are discovered to the moment they expire and become noise. Understanding this lifecycle is critical because acting on a stale IOC is worse than having no IOC at all — it generates false positives, wastes analyst time, and can block legitimate traffic.

Click to enlarge

Stage 1: Discovery

An IOC enters your awareness through one of three channels:

• Alert-driven: Your SIEM fires an alert containing an IP, domain, or hash you have not seen before. You extract it during triage.
• Feed-driven: A threat intelligence feed (OSINT or commercial) delivers a batch of new indicators. MISP event published, STIX/TAXII feed updated, or an analyst reads a threat report and manually extracts IOCs.
• Hunt-driven: A threat hunter proactively searches for anomalies and discovers a new C2 domain in DNS logs that no alert caught.

At discovery, you have a raw indicator with minimal context. You know the artifact exists, but you do not yet know if it is reliable or relevant to your environment.

Stage 2: Validation

Not every IOC is worth acting on. Validation answers one question: is this indicator real and relevant?

• Single-source IOC: One threat feed reports 198.51.100.50 as malicious. Could be a false positive in that feed. Low confidence.
• Multi-source IOC: Three independent feeds (VirusTotal, AlienVault OTX, and a commercial feed) all flag the same IP within 48 hours. Much higher confidence.
• Contextual validation: The IP appears in a threat report linked to APT29, and your organization is in a sector APT29 targets (government, defense, energy). Relevant. If you are a local bakery, APT29 IOCs may not be worth blocking.

The validation rule of thumb: one source = investigate, two sources = monitor, three sources = act.

Stage 3: Enrichment

Raw IOCs are addresses without context. Enrichment turns a bare IP into an intelligence object:

Before enrichment:
  IP: 198.51.100.50
  Source: AlienVault OTX pulse

After enrichment:
  IP: 198.51.100.50
  Malware Family: LockBit 3.0
  Campaign: Operation Gold Dust
  TLP: TLP:AMBER
  Confidence: 85/100
  First Seen: 2026-01-20
  Last Seen: 2026-02-15
  ASN: AS12345 - Bullet Proof Hosting Ltd
  GeoIP: Moldova (MD)
  Related Hashes: 7d8a3f..., e5c9b1...
  Related Domains: lockbit-decrypt.onion, payment-portal.example.com
  MITRE ATT&CK: T1486 (Data Encrypted for Impact)
  Source Count: 4 independent feeds

Enrichment transforms detection into intelligence. Without it, you have an IP to block. With it, you have campaign context, related indicators to hunt for, and ATT&CK techniques to build behavioral detections against.

Stage 4: Dissemination

An enriched IOC sitting in a spreadsheet helps nobody. Dissemination pushes the indicator into the systems that can act on it:

• SIEM rules: Create a Wazuh CDB list or Sigma rule that alerts when the IOC appears in logs
• Firewall/proxy blocks: Add the IP or domain to a blocklist at the network perimeter
• MISP events: Publish the IOC as a MISP event so other organizations in your sharing community can benefit
• EDR watchlists: Push the file hash to your endpoint detection tool so it blocks or quarantines on sight
• Email gateway rules: Block the sender address or subject line pattern

The goal is zero latency between "we know this is bad" and "our systems are watching for it."

Stage 5: Aging and Expiry

This is the stage most teams neglect, and it causes real damage. IOCs have a shelf life:

A healthy IOC lifecycle includes automatic expiry. Many MISP deployments tag IOCs with a last-seen date and automatically reduce confidence scores after a set period (e.g., 30 days for IPs, 90 days for domains). If no new sighting refreshes the indicator, it ages out of active detection and into archive status.

Confidence and Freshness

Two attributes separate actionable intelligence from noise: confidence and freshness.

Confidence scoring quantifies how certain you are that an indicator is truly malicious. Common scales:

Freshness is equally important. An IOC's value decays over time:

• A C2 IP reported today → high operational value. The attacker is likely still using it.
• The same IP reported 2 weeks ago → moderate. The attacker may have rotated.
• The same IP reported 6 months ago → low to zero. Almost certainly reassigned or decommissioned.

The combination matters. A high-confidence IOC that is 6 months old is less actionable than a medium-confidence IOC from this morning. Your SIEM and MISP should track both first_seen and last_seen timestamps, and your detection rules should weight freshness accordingly.

SOC SLA for intel freshness: Many mature SOCs define a maximum latency between receiving a threat intelligence report and having the extracted IOCs deployed to detection systems. Common targets are 30 minutes for critical indicators and 4 hours for standard updates. If your team takes 3 days to ingest IOCs from a report, the attacker has already rotated their infrastructure, and your "new" IOC is already stale.

What's Next

You now understand what IOCs are, how they are categorized, how they move through a lifecycle, and why their quality decays over time. But knowing about IOCs in the abstract is not the same as working with them in a live platform. In Lesson 5.2: MISP for SOC Analysts, you will learn the tool that brings all of these concepts together — searching for indicators across events, correlating attributes, understanding MISP's data model (Events → Attributes → Objects → Galaxies), and managing the feeds that keep your IOC database current. Then in Lab 5.1, you will put both lessons into practice by searching, correlating, and analyzing real IOC data in a live MISP instance.