Validate an IOC before blocking it

An indicator match is a starting point. A shared hosting address, an old malware URL and a hash of a file executed on one of your endpoints require different responses. The aim is to preserve enough context for a reviewer to understand why you hunted, escalated, blocked or dismissed a match.

1. Check the original report and the dataset date

1. Open the APT IOC Aggregator. Read its generation time and coverage note before selecting a group or malware family. A scheduled refresh can fail while the last good dataset stays available.
2. Record the indicator exactly, its type, the reporting source and the report's observation dates when available. Preserve the original alongside any normalised value. A hash must include its algorithm; a domain and a URL are different observables.
3. Read the source's surrounding analysis. Does it describe command and control, delivery, a compromised legitimate site, or simply related infrastructure? A malware-family-to-group mapping is a research lead, not evidence that every indicator belongs to that actor.
4. Check whether the evidence is still relevant to your investigation period. The dataset generation date is not the indicator's first-seen or last-seen date. No result in the tool does not establish that a value is safe.

2. Look for relevant sightings in approved telemetry

Search the systems you are authorised to investigate. Record the search period, timezone, fields, data sources and any gaps. A DNS answer alone establishes a lookup; it does not show that a file ran or that credentials were stolen. For a file hash, correlate with process execution, parent process, path and endpoint identity. For a URL or domain, correlate DNS with proxy, browser or network events.

Do not visit a suspicious URL in your normal browser or submit internal documents, private URLs, customer information or secrets to a public reputation service. Use your approved analysis environment and data-sharing policy. Defang values in notes intended for casual reading.

Check alternative explanations

• Is the address shared by unrelated customers, a CDN or a public resolver?
• Did an email scanner, sandbox, security product or analyst generate the connection?
• Does the full hostname or path matter, rather than an entire service or parent domain?
• Do timestamps, device identity and a second independent telemetry source support the same sequence?

3. Choose a proportionate response and a review date

A confirmed malicious execution may justify incident escalation. A weak infrastructure match may justify a bounded hunt or further evidence collection. Before blocking, check business dependencies, expected false positives, the enforcement scope, an expiry or review date and a rollback owner. Follow your incident process rather than converting a public feed directly into a denylist.

Keep the observation separate from the conclusion: “device queried this domain” is an observation; “the device is compromised by this group” needs additional evidence. Record uncertainty and the reason for taking no action as carefully as the reason for escalating.

Worked example: a domain in a research report

Suppose a report lists download.example.invalid as a delivery host. This is a reserved, non-resolving example, not a live indicator. Your proxy records a single request from an email inspection service, with no corresponding user endpoint execution. That evidence supports reviewing the email and scanner activity; it does not by itself establish an endpoint infection.

If a second search instead finds a matching download followed by execution on a user endpoint, preserve the event identifiers and investigate using your incident procedure. Record what changed your assessment. Do not attach an actor name solely because the indicator appeared under a group in a tool.

Use the IOC triage worksheet for the source, observation period, local evidence, alternative explanation, decision and follow-up. For reviewed machine-readable transfer, continue with the STIX and MISP export guide.

Primary references and tool limits

• MITRE ATT&CK FAQ: documented behaviours, groups and the limits of technique coverage.
• CISA KEV catalogue: exploitation evidence for listed vulnerabilities, not reputation for arbitrary indicators.
• ThreatFilter coverage and freshness: retrieval status and completeness are separate.