Security advisories often end with a table: a few IP addresses, a few domains, some long hash values. These are IOCs, indicators of compromise. Many companies do exactly one thing with them: add the IPs to the firewall blocklist. Blocking only stops future connections. It does not answer the more important question, which is whether these indicators have already shown up in your environment.

This article is for IT staff who look after logs, endpoints and network devices, and for managers who have to decide whether to start an incident response. It covers IOC types and their limits, defanged notation, which data sources to search, how to rule out false positives, and what to do when you get a hit. When an advisory on this site includes IOCs, they are listed in a table with their type, notes and sources, ready to use as a search list.

What IOCs are and the common types

NIST defines indicators of compromise as technical artifacts or observables that suggest an attack is imminent or under way, or that a compromise may already have occurred[1]. Types you will commonly see in advisories:

  • IP addresses: command-and-control (C2) servers, scanning sources, exfiltration destinations.
  • Domain names: domains that malware calls back to, phishing sites.
  • URLs: more precise than a domain, such as the download path of a malicious file.
  • File hashes: MD5, SHA-1 or SHA-256 fingerprints of a specific file.
  • File names and paths: for example, the name of a web shell dropped into a web root.
  • Email addresses: senders used for phishing or business email compromise; see phishing and BEC.
  • Other: registry keys, service names, scheduled task names, user agents and so on.

The IOC tables in this site's advisories are grouped as IP, domain, hash, file name, URL, email and other, and every entry is linked to its source so you can go back to the original report for context.

The Pyramid of Pain: why IOCs go stale

David Bianco introduced the Pyramid of Pain in 2013 and updated it in 2014 to add a layer for hash values[2]. From bottom to top, the levels are hash values, IP addresses, domain names, network and host artifacts, tools, and, at the top, TTPs (tactics, techniques and procedures). The lower the level, the easier it is for the attacker to change: flip one bit in a file and the hash is completely different; IP addresses can be swapped with very little effort; domains have to be registered, paid for and hosted, which is a little more work but not hard[2]. Higher up, the attacker has to reconfigure or rewrite tools, or even learn new behaviour, and the cost keeps rising[2].

What this means for IOC matching:

  • A hit on a hash or an IP is usually high-confidence, but no hit does not mean you are safe; the attacker may have moved on to new ones long ago.
  • IOCs age. The older the advisory, the more likely its IPs have been reassigned to someone unrelated.
  • Long-term defence means moving up the pyramid and detecting behaviour. MITRE ATT&CK is a knowledge base of adversary tactics and techniques based on real-world observations[3]. Many advisories cite ATT&CK technique IDs, which you can use to check whether your detection rules cover those techniques.

Reading defanged notation: hxxp and [.]

Advisories often write addresses as hxxps://example[.]com/update or 198.51.100[.]23. This is called defanging: http becomes hxxp and dots become [.], so the values do not turn into clickable links in web pages, email or chat, and nobody clicks one by accident or has a preview generator fetch a malicious site. IPs, domains, URLs and email addresses in this site's advisories are displayed the same way.

Two rules when you use them:

  • Refang only inside your tools: before searching in a SIEM, EDR or firewall, change [.] back to . and hxxp back to http. Never paste the refanged value into a browser.
  • Do not reach out to the infrastructure: CISA and its partners warn that pinging, running nslookup against or browsing to adversary infrastructure can reveal that you have detected them[4]. To learn about a domain, look up its history on a threat intelligence platform instead of connecting to it.

Where to search: data sources and look-back windows

Match each IOC type to a data source:

  • IP addresses: firewall and VPN connection logs, proxy logs, NetFlow. Also check sign-in logs for internet-facing services such as VPN, email and websites to see whether anyone logged in successfully from that IP.
  • Domains and URLs: query logs from your internal DNS servers, proxy or secure web gateway logs. DNS logs tell you which host made the query.
  • Hashes and file names: EDR or antivirus file and execution records; you can also search file servers.
  • Email addresses: mail gateway and mail server logs, to find out who received the message and whether anyone clicked or replied.
  • SIEM: if logs are centralised, you can search several sources at once. NIST also recommends feeding up-to-date threat intelligence into log analysis tools to improve detection accuracy[5].

On scope, NIST recommends looking not only at assets known to be affected but also at other potential targets[5], and checking backups for indicators of compromise before restoring from them[5].

The look-back window should at least cover the activity period described in the advisory, and preferably start some time before the earliest known activity. In practice the bottleneck is usually log retention: CISA and its partners recommend retaining log data for at least one year[4]. If you find that some sources only go back a few days, that is a gap to fix regardless of the result.

After a hit: rule out false positives, then escalate

Rule out common false positives

CISA and its partners recommend assessing results for further signs of malicious activity in order to eliminate false positives[4]. Typical cases:

  • CDNs and shared hosting: many websites share the same IP addresses. If an advisory IP belongs to a CDN or cloud provider, your users may simply have visited a legitimate site on the same address. Some CDN providers publish their IP ranges (Cloudflare, for example[6]), so check against those first. Such IPs are useful for correlation but poor candidates for blocking.
  • Reassigned IPs: cloud and residential IPs change hands often. If the hit falls outside the activity period in the advisory, lower your confidence.
  • Common file names: a match on a file name alone (for example, one that mimics a system binary) needs to be checked against path, hash and digital signature.
  • Your own security tools: a mail gateway or sandbox resolving a malicious domain while analysing a suspicious message also leaves DNS records.

Weigh three things: whether the timing falls within the activity period, whether the connection succeeded and actually transferred data (rather than just a DNS lookup), and whether the host shows other signs such as suspicious processes, new accounts or scheduled tasks.

Treat a confirmed hit as an incident

Once a hit is confirmed, handle it as a suspected intrusion and start the response described in the first 24 hours of a suspected breach: preserve logs and host evidence, do not reimage yet, and use the affected host as a starting point to find other hosts that contacted the same indicators in the same period. At this point blocking is no longer routine. CISA and its partners note that replacing infrastructure costs attackers little, so pre-emptive blocking can cost you visibility into their activity, and blocking an IP without finding the malware and how it got in may leave the attacker with access[4]. Whether to block immediately is a decision for the incident lead, based on whether damage is ongoing.

When there is no hit, adding still-relevant IOCs to alerting or blocklists is a reasonable precaution, but record the source and set an expiry date so the list does not grow forever or start blocking legitimate services.

Automation: STIX and TAXII

One advisory can be checked by hand; several a week call for automation. STIX is a language and serialisation format for exchanging cyber threat intelligence, and TAXII is an application-layer protocol for communicating threat information, designed specifically to carry intelligence expressed in STIX. Both are maintained by the OASIS Cyber Threat Intelligence Technical Committee, and the current versions are 2.1[7]. Many SIEMs, threat intelligence platforms and firewalls can subscribe to TAXII feeds. CISA's Automated Indicator Sharing (AIS) is one example: it is a no-cost service, and participants receive indicators with a TAXII 2.1 client[8].

When you automate ingestion, start in alert-only mode and watch the false-positive rate before deciding which feeds may block directly. Keep the source, confidence level and expiry date for every indicator.

Action checklist

  1. Assign an owner: who checks the IOCs in each advisory, and within how many working days.
  2. Take the IOCs from advisories, refang them, and keep them in a list with the source and advisory date.
  3. Search by type: IPs in firewall, VPN and proxy logs; domains and URLs in DNS and proxy logs; hashes and file names in EDR; email addresses in the mail gateway.
  4. Make the look-back window cover at least the activity period in the advisory; check how long each log source is actually kept and plan improvements where it is under a year.
  5. On a hit, check timing, connection outcome and host evidence, and rule out CDN, shared-hosting and reassigned-IP false positives.
  6. On a confirmed hit, start the response in the first 24 hours guide: preserve evidence before acting, and contact us if you need help.
  7. With no hit, add still-relevant indicators to alerting or blocklists with an expiry date, and check whether the techniques described in the advisory are within your detection coverage.
  8. Longer term, evaluate automated ingestion via STIX/TAXII, and subscribe to advisories so new IOCs reach the owner right away.