Indicators of compromise

This article is about your own indicators of compromise: entries you create, edit or bulk-import yourself, each with an action, a severity and an optional host-group scope. It is the same underlying table Threat-intelligence feeds already populates from the eleven subscribed feed presets — a feed-sourced indicator and a manually-created one sit in the same list, with the same fields, and are matched the same way. Read that article first if you have not already; this one covers what changed when the table gained an action, a severity, a host-group scope and hit counting, and how to manage indicators directly rather than through a subscription.

Indicator types

Eight indicator types exist in the data model: file_hash, domain, ip, url, email, mutex, registry_key and yara_rule. The console's Indicators of compromise panel (on the consolidated /xdr/policy page — see Policy objects and host groups for why everything lives on one page) has a quick-add form covering the four most common types — file_hash, domain, ip and url. Creating an email, mutex, registry_key or yara_rule indicator, or setting fields the quick-add form does not expose, means calling the API directly today: POST /api/v1/organizations/{orgID}/xdr/indicators.

Action, severity, host-group scope and hit counting

How a match happens, and where hit counting comes from

Two things read your indicators, and it is worth keeping them straight:

1. The explicit hash-on-fetch path, described in detail in Threat-intelligence feeds: when a file is fetched from an endpoint through a live-response ticket, its SHA-256 digest is looked up against your active file_hash indicators, and a match can prepare a quarantine_file ticket.
2. Server-side matching against ordinary sensor telemetry as it is ingested. This is what feeds hit counting and last_hit_at on the indicator row itself, and what raises an alert on a match, independently of the fetch-triggered path above. Because the sensor does not emit network-connection events (see What the sensor collects), a domain, ip or url indicator has very little live traffic to match against day to day; a file_hash indicator is the type most likely to actually see a hit in the ordinary course of ingest.

Either way, a match is a server-side alert against your organisation's telemetry — never a local block or kill on the machine itself.

Bulk import is JSON, not CSV or STIX, and it is API-only

POST /api/v1/organizations/{orgID}/xdr/indicators/import takes a JSON body of {"rows": [...]}, where each row has the same shape as creating one indicator. There is no CSV or STIX bulk-import today, and there is no console control for bulk import at all — the endpoint exists and is fully functional, but importing a batch means calling it directly rather than uploading a file in the console. If your source data is a CSV or a STIX bundle, converting it to the {"rows": [...]} shape is a step you do yourself before calling the endpoint; nothing in the product does that conversion for you.

The console panel, and who can manage indicators

The Indicators of compromise panel lists every indicator — type, value, action, hit count, expiry — and its quick-add form creates one at a time with type, value and action. Editing severity, host-group scope, platforms or the less common indicator types, and bulk-importing, all go through the API today.

Reading indicators needs xdr:indicators.read; creating, editing, importing and deleting them needs xdr:indicators.write. Both are ordinary member-grade permissions in the default role set.

What to read next

1. Threat-intelligence feeds — the eleven subscribed presets that feed the same table, and the one thing that actually gets matched automatically.
2. Custom IOA rules — the other kind of detection content carried in the bundle, with its own vocabulary and its own enforcement gap.
3. The signed policy bundle — exactly what does and does not happen on the endpoint with an indicator's action.