Indicators of Compromise

Overview

The IOC subsystem provides a global indicator registry that spans all cases in your DFIRe instance. Each indicator is stored once and linked to cases through associations, allowing you to:

• Capture IOCs during investigations — manually, via bulk import, or by extracting them from notes
• Classify and tag indicators as malicious, suspicious, benign, or unknown
• Enrich indicators — manually or automatically on creation — against 14 providers, including a live lookup against your own MISP instance
• Detect cross-case correlations when the same indicator appears in multiple investigations
• Share published indicators via TAXII 2.1 server and the MISP-compatible case-as-event feed
• Import and export in CSV, STIX 2.1, and plaintext formats

Supported IOC Types

DFIRe uses the STIX 2.1 Cyber Observable (SCO) type taxonomy. The following 18 indicator types are supported:

Type	Description	Example
IPv4 Address	IPv4 address or CIDR block	203.0.113.42, 173.245.48.0/20
IPv6 Address	IPv6 address or CIDR block	2001:db8::1
Domain Name	DNS domain or subdomain	evil.example.com
URL	Full HTTP/HTTPS URL	https://evil.example.com/payload.exe
Email Address	Email address	attacker@evil.com
Email Message	Email metadata (subject, headers)	Phishing email subject line
File Hash	MD5, SHA-1, or SHA-256 hash	d41d8cd98f00b204...
Process	Process name or command	svchost.exe
Registry Key	Windows registry path	HKLM\Software\...\Run
Network Traffic	Network connection metadata	Port, protocol, src/dst
User Account	User account name	Administrator
MAC Address	Hardware MAC address	00:1A:2B:3C:4D:5E
Software	Software name, version, or CVE	CVE-2021-44228
Artifact	Generic binary or text artifact	Base64 payload fragment
Autonomous System	BGP AS number	AS13335
Directory	File system path	C:\Windows\Temp
Mutex	Named mutex object	Global\evil_mutex
X.509 Certificate	Certificate serial or thumbprint	Certificate SHA-256 thumbprint

Indicator Properties

Each indicator in the registry has the following properties:

Classification

Every indicator has a classification reflecting the analyst’s assessment:

• Unknown (default) — Not yet assessed
• Benign — Determined to be harmless
• Suspicious — Warrants further investigation
• Malicious — Confirmed threat indicator

Confidence

The confidence level reflects how certain you are about the classification:

• Low — Preliminary assessment, needs verification
• Medium — Reasonable certainty based on available evidence
• High — Confirmed through multiple sources or direct observation

TLP (Traffic Light Protocol)

TLP controls how widely an indicator can be shared:

TLP Level	Sharing Scope	Can Publish?
TLP:CLEAR	No restrictions	Yes
TLP:GREEN	Community-wide sharing	Yes
TLP:AMBER	Need-to-know basis	Yes
TLP:AMBER+STRICT	Organization only, no further dissemination	Yes
TLP:RED	Named recipients only	No

Tags

Free-form text tags for organizing indicators. Examples: apt29, phishing, ransomware, c2-server. Tags are set when creating or editing individual indicators.

Public Notes

Shared notes that are visible to all users with indicator view permission, regardless of which case the indicator is associated with. Use public notes for information that does not reveal case details, such as “Known Cobalt Strike C2 infrastructure”.

Adding Indicators to a Case

There are several ways to add indicators to a case:

Manual Entry

1. Open the case and navigate to the IOCs tab
2. Click Add Indicator
3. Enter the indicator value — the type is auto-detected as you type
4. Optionally set the classification, confidence, TLP, and tags
5. Add context notes (these are private to this case)
6. Click Add

If the indicator already exists in the global registry, it is linked to the case rather than duplicated. If it is new, it is created in the registry and linked.

Auto-Extraction from Case Content

DFIRe can scan case notes, item notes, and evidence item values for potential indicators:

1. In the case IOCs tab, click Scan Case
2. DFIRe scans all notes and evidence item fields in the case for patterns matching IOC types (for example, an email address added as an evidence item is detected as an indicator)
3. Review the extracted candidates — each shows the detected type and source note
4. Select which candidates to add, adjust classifications if needed
5. Click Add Selected

Supported extraction patterns include IPv4/IPv6 addresses (with CIDR), domains, URLs, email addresses, file hashes (MD5, SHA-1, SHA-256), MAC addresses, and CVE identifiers.

Text Extraction

The Extract function takes arbitrary text input (threat reports, log output, email headers, intelligence feeds) and searches for indicators using regular expressions. Paste or type text, and DFIRe identifies all potential indicators within it. Review the extracted candidates and add the ones you want to keep.

Bulk Import

Import indicators from files in three formats:

• CSV — Spreadsheet with columns for value, type, classification, confidence, TLP, and tags. Column headers are matched flexibly.
• STIX 2.1 — Standard STIX Bundle JSON file. SCO objects are imported and metadata from wrapping SDO Indicator objects (confidence, labels, indicator_types) is preserved.
• Plaintext — One indicator per line. Types are auto-detected. Works well with pasted lists from threat reports or log analysis.

Imports and extraction are available both from the case IOCs tab (case-scoped) and from the global IOC Registry page.

Hierarchical Decomposition

When you add a composite indicator like a URL or email address, DFIRe automatically breaks it down into its component parts and creates parent-child relationships:

Example: URL Decomposition

Adding https://evil.cdn.hosting.com/downloads/payload.exe creates:

• The full URL (your original indicator)
• evil.cdn.hosting.com — domain extracted from the URL
• cdn.hosting.com — parent domain
• hosting.com — apex domain

Example: Email Decomposition

Adding attacker@mail.evil.com creates:

• The email address (your original indicator)
• mail.evil.com — domain from the email
• evil.com — apex domain

Example: CIDR Adoption

If individual IP addresses like 173.245.48.5 already exist in the registry and you later add the CIDR block 173.245.48.0/20, those IPs are automatically adopted as children of the CIDR block.

Independent Classification

Each level in the hierarchy has its own classification. A malicious URL might be hosted on a benign hosting provider — the subdomain is malicious, but the apex domain is benign. The hierarchy tree view in the Intelligence page shows each node with its own classification color.

IOC Registry

The IOC Registry is accessible from the main navigation and shows all indicators across all cases in your DFIRe instance. From the registry you can:

• Browse and filter indicators by type, classification, confidence, TLP, published/revoked status, and tags
• Search by indicator value or notes
• Perform bulk operations — classify, set confidence, set TLP, publish, revoke, or delete multiple indicators at once
• Import indicators from CSV, STIX 2.1, or plaintext files
• Export indicators to CSV or STIX 2.1 bundles (up to 50,000 indicators per export)

The registry shows a case count for each indicator — how many cases reference it — but does not reveal which cases. This preserves case isolation while providing useful correlation context.

Intelligence Page

Clicking an indicator in the registry or a case opens its Intelligence page with detailed information organized in tabs:

Details Tab

Shows the indicator value, STIX type, classification, confidence, TLP, tags, and metadata (first seen, last seen, created by). Also lists all case associations visible to you, with case-private context notes.

Relations Tab

Displays the indicator’s position in its hierarchical tree. Parent and child indicators are shown with their classifications, making it easy to see how a URL relates to its domain, or how a domain relates to its apex.

Enrichment Tab

Shows results from every configured provider that supports this indicator’s type, each in its own collapsible card with the fetch timestamp. Providers can be run or refreshed on demand from this tab, and changes over time are captured as snapshots so you can compare the current result against earlier responses. MISP results are grouped per Event with a per-event Apply tags to IOC button. See the Enrichment section below for details on available providers.

Cross-Case Correlation

When you add an indicator to a case and it already exists in other cases, DFIRe automatically notifies you:

• You receive a notification: “This indicator has been observed in N other case(s)”
• Other members of your case team also receive the notification
• A webhook event (ioc_correlation) is fired if configured

The notification contains only the count, not the case numbers or details. This preserves case isolation. To learn which cases share the same indicator, contact an administrator or a user with global case read access who can check the associations and determine whether information can be shared between teams.

Enrichment

DFIRe can look up indicators against external threat intelligence services and against your own MISP instance. Enrichments can be triggered manually from the indicator’s Enrichment tab or fired automatically when a new indicator is created (per-provider opt-in).

Built-in Providers (No API Key Required)

Provider	Supported Types	Data Returned
DNS	Domains, IPs	A/AAAA/MX records, reverse DNS
WHOIS	Domains, IPv4, IPv6	Domains: registrar, registration dates, nameservers. IPs: Regional Internet Registry (ARIN / RIPE / APNIC / LACNIC / AFRINIC), NetName, CIDR/range, organisation, country, abuse contact

External Providers (API Key Required)

Provider	Supported Types	Data Returned
VirusTotal	IPs, Domains, URLs, Hashes	Multi-engine scan results, reputation scores
Shodan	IPs	Open ports, services, banners, geolocation
GreyNoise	IPs	IP classification (benign scanner, malicious, unknown)
AlienVault OTX	IPs, Domains, URLs, Hashes	Pulse reports, community threat intelligence
AbuseIPDB	IPs	Abuse reports, confidence score, ISP info
URLhaus	URLs, Domains	Malware hosting detection, malware family
ThreatFox	IPs, Domains, URLs, Hashes	Malware C2 identification, campaign info
MalwareBazaar	Hashes	Malware sample metadata, family, tags
URLscan	URLs, Domains	Live page scan, DOM analysis, screenshots. API key is optional — works keyless with lower rate limits, or supply a key for higher quotas and private scan visibility
Google Safe Browsing	URLs, Domains	Phishing and malware verdicts
Spur	IPs	Residential proxy, VPN/Tor attribution, bot detection, anonymization infrastructure
MISP	All major STIX types (IPs, Domains, URLs, Emails, Hashes, MACs, registry keys, mutexes, x509 certificates, AS numbers)	Matching Attributes from a configured MISP instance: Event info, originating organisation, threat level, tags, to_ids flag, first/last seen

MISP as an Enrichment Source

The MISP provider queries your configured MISP instance through /attributes/restSearch by value and surfaces matching Attributes grouped per MISP Event. This is intended for triage — a match against the organisation’s existing threat-intel body of knowledge is a strong signal for an investigator.

Each matching Event is rendered as its own card on the Enrichment tab with an Apply tags to IOC button. Clicking it copies that event’s tags onto the DFIRe indicator (de-duplicated against any tags already set), so curated MISP tags can be promoted to the DFIRe record with one click. Different events may carry different tag sets, so the choice is per event.

Configuration (System Settings > IOC Enrichment > MISP):

• MISP URL — the base URL of the MISP instance (e.g. https://misp.example.com).
• API key — an authkey with read access to attributes.
• Verify TLS certificate — disable only for MISP instances with self-signed certificates.

Configuring Enrichment Providers

1. Navigate to System Settings > IOC Enrichment.
2. Each provider row shows its supported types. Flip the toggle to enable; disabled providers collapse to just a header row so inactive providers don’t clutter the page.
3. Enter your API key (and any provider-specific extras like the MISP URL) and click Save. Use Test to validate the key against a lightweight API call before saving.
4. Optionally enable Run automatically when a compatible IOC is added — the provider will fire in the background for every newly created indicator of a type it supports.

Cache TTL

A single Enrichment cache TTL (default six hours) applies to all providers. It’s a debounce guard used only on the auto-run path: if an indicator has a cached enrichment younger than the TTL, auto-run reuses it instead of re-querying the provider. Manual Run and Refresh buttons always bypass the TTL and re-query.

Rate Limiting

Enrichment requests are rate-limited per provider to avoid overloading external APIs. Built-in providers have higher limits; paid APIs like VirusTotal’s free tier (4 requests/min) are respected automatically. Combined with the auto-run debounce, this makes it safe to enable auto-run against paid providers without burning through quota.

Publishing and Lifecycle

Indicators in DFIRe have a lifecycle that controls their visibility and sharing status:

States

• Unpublished — Visible only to internal DFIRe users. Not shared externally.
• Published — Available to external consumers via the TAXII 2.1 server and MISP feed. Included in STIX exports.
• Revoked — Marked as no longer valid. Revoked indicators that were published appear with revoked: true in STIX output so consumers know to remove them.

Auto-Revocation

If an indicator has a Valid Until date set and that date passes, DFIRe automatically revokes it via a background task. This is enabled by default and can be configured in System Settings > IOC Lifecycle:

• Auto-revoke expired indicators — Enable or disable
• Default expiration — Number of days until new indicators expire (leave empty for no default expiration)
• Default TLP — TLP level applied to newly created indicators
• Hard-delete revoked after N days — Permanently remove revoked indicators after a retention period (default: disabled)

Publishing Rules

• TLP:RED indicators cannot be published (this is enforced at the system level)
• Revoked indicators cannot be published (unrevoke first, then publish)
• Bulk publish will skip TLP:RED and revoked indicators and report the count skipped

Sharing Indicators

Published non-RED indicators can be shared with external systems via two mechanisms — the TAXII 2.1 server and the MISP-compatible feed — both configured under System Settings > IOC Sharing. Each service has an independent enable toggle; the settings page collapses each service’s configuration when its toggle is off.

TAXII 2.1 Server

DFIRe includes a read-only TAXII 2.1 server that external threat intelligence platforms can poll for indicators. TAXII consumers authenticate with a Bearer API key and retrieve published indicators as STIX 2.1 objects.

• Configure under System Settings > IOC Sharing > TAXII 2.1 Server (server title, description, contact, page-size limits, and case-association toggle).
• Indicator Collections are configured inside the TAXII card: each collection is a filtered view of the registry (by STIX type, classification, confidence, or tag). Collections only apply to TAXII — the MISP feed ignores them.
• TLP:RED indicators are hard-filtered at the database level and never appear in TAXII responses.
• An API key is scoped to TAXII via its TAXII 2.1 Server toggle (see API Key Scopes below).

MISP-Compatible Feed

DFIRe generates a MISP-compatible JSON feed that remote MISP instances can ingest as a feed source. Every published, non-RED indicator is exposed — indicator collections are not consulted here (they only shape TAXII responses).

Case-as-Event Model

The feed is organised by DFIRe case: each case with at least one published non-RED indicator becomes a separate MISP Event, and a single global Event covers indicators that have no case association.

• Event info carries the case number (e.g. CASE-2026-042). A tenant toggle controls whether the case title is appended after the case number — disable it if titles may be sensitive.
• Event analysis reflects the case status: ongoing for open cases, complete for closed or archived cases.
• An indicator that appears in multiple cases publishes as a distinct Attribute in each case’s Event. MISP’s correlation engine stitches them back together on the consumer side.
• All three case statuses (OPEN / CLOSED / ARCHIVED) are eligible — closing a case does not retract shared intel. To stop sharing an indicator, revoke or unpublish it.

TLP Handling in Mixed-TLP Events

A case may contain indicators at several TLP levels. Every Attribute carries its own tlp:* tag (including tlp:clear, tlp:green, tlp:amber, and tlp:amber+strict), and the Event’s distribution is set to the strictest TLP present — one AMBER+STRICT attribute caps the whole Event at organisation-only sharing. TLP:RED is excluded everywhere.

Configuring the Feed

1. Enable the feed under System Settings > IOC Sharing > MISP Feed.
2. Set the organisation name (shown as the producing Orgc in MISP Events). The Orgc UUID is auto-generated and stable — don’t change it once external MISPs have synced.
3. Choose whether to include case titles in the Event info field.
4. Copy the Feed URL (ends with /misp-feed, not /manifest.json) into the remote MISP’s feed configuration. MISP appends manifest.json itself.
5. Create an API key with the MISP Feed scope enabled and supply it as a Bearer token in the remote MISP’s feed Headers.

Revocation and Soft-Deletion

Revoking an indicator in DFIRe (manually, or automatically when its valid_until date passes) sets MISP’s canonical deleted: true flag on the Attribute in the feed output. On the next feed fetch, consumer MISP instances soft-delete the Attribute — removing it from correlation, IDS exports, and detection rules automatically. The Attribute timestamp records when the revocation happened. Unpublishing an indicator (instead of revoking it) drops it from the feed entirely; re-publishing brings it back. Neither requires the consumer’s feed to be configured in any special mode.

Troubleshooting the Consuming MISP

The MISP-side feed configuration defaults in MISP 2.5.x have a few sharp edges. None of these are DFIRe issues, but they can make a correctly-published feed look broken on the consumer side. Worth knowing before you open a debug session:

• “Only one event ingests; the others never appear” — Fixed Event trap. When you add a new MISP-format feed in MISP’s UI, the Target Event (internally fixed_event) field is hidden. The add handler silently defaults it to 1 (Fixed Event), which collapses every event in the feed into a single local event. For a DFIRe feed that legitimately publishes one event per case, this looks like only one event is ever coming through. The field isn’t exposed on the edit form for MISP-type feeds either, so there’s no UI path to change it.
  
  Flip it via the MISP API:

  curl -X POST \
    -H "Authorization: <your-misp-api-key>" \
    -H "Accept: application/json" \
    -H "Content-Type: application/json" \
    -d '{"Feed": {"fixed_event": false}}' \
    https://<your-misp>/feeds/edit/<feed-id>

  Then delete any merged orphan events in MISP and re-fetch the feed. Each DFIRe event should now create its own MISP event.
• “Deleted events never come back, even after revoking and re-publishing” — auto-blocklist trap. MISP has an Event Blocklist feature that’s enabled by default (MISP.enableEventBlocklisting=True). When you delete an event in the MISP UI, its UUID is silently added to the blocklist with the comment “Automatically blocked by deleting event.” Future feed fetches then skip that UUID entirely, without logging an error or surfacing it in the job results — the event simply never reappears.
  
  If a DFIRe case event you’ve deleted and then re-published isn’t showing up:
  1. Check MISP’s blocklist at Administration > Event Blocklists (or GET /event_blocklists/index).
  2. Remove the UUIDs you want to re-ingest.
  3. Re-fetch the feed.
  To stop the automatic blocklisting entirely for a testing MISP, turn MISP.enableEventBlocklisting off in Administration > Server Settings & Maintenance.
• Upgrade note from DFIRe 1.3.0. Pre-1.3.1 DFIRe published a handful of per-TLP events rather than one event per case, so the Fixed Event and blocklist behaviours above rarely bit anyone — the feed mostly produced one effective event. After upgrading to 1.3.1, a DFIRe instance with many active cases can produce many events at once, and both quirks become visible. If you consumed the feed into a long-lived MISP before the upgrade, expect to revisit both settings once.

API Key Scopes

A DFIRe sharing API key carries two independent scopes:

• TAXII 2.1 Server — allows the key to hit the /taxii2/api1/ endpoints. Defaults to enabled.
• MISP Feed — allows the key to hit the /misp-feed/ endpoints. Defaults to disabled.

Either or both scopes can be enabled on a given key. Turning both scopes off keeps the key but denies access from every endpoint — a safe way to temporarily suspend a key without deleting it (and losing the audit trail of past requests). The edit modal shows an amber warning when a key has no scopes, and the API-key list shows a “No access” pill for suspended keys.

Collection restrictions (limiting a key to specific collections) still apply to the TAXII scope only.

Export and Import

Exporting Indicators

Export indicators from either the global registry or a specific case:

• CSV — Spreadsheet format with columns for value, type, classification, confidence, TLP, tags, context, and metadata. Useful for sharing with analysts or importing into other tools.
• STIX 2.1 Bundle — Standard JSON format containing STIX SCO and SDO objects. Includes TLP marking definitions. Compatible with MISP, OpenCTI, and other STIX-consuming platforms.

Bulk exports from the registry support up to 50,000 indicators per operation. You can apply filters before exporting to select only the indicators you need.

Importing Indicators

Import indicators into a case or the global registry:

• CSV — Flexible header matching (accepts IOC Value, Value, indicator, etc.). Type names are mapped flexibly (ipv4, ip, ipv4-addr all work for IPv4 addresses).
• STIX 2.1 Bundle — Imports SCO objects from a STIX Bundle. Metadata from wrapping SDO Indicator objects (confidence, labels, indicator_types) is preserved.
• Plaintext — One indicator per line, types are auto-detected. Ideal for pasting lists from threat reports, log analysis, or intelligence feeds.

Duplicate indicators (same value and type) are automatically skipped during import. The import summary shows the count of added and skipped indicators.

Bulk Operations

From both the IOC Registry and the case Indicators tab, you can select multiple indicators and perform bulk actions:

• Classify — Set classification (unknown, benign, suspicious, malicious) for all selected
• Set Confidence — Update confidence level for all selected
• Set TLP — Change TLP designation (auto-unpublishes if changed to RED)
• Publish — Make selected indicators available via TAXII/MISP (skips TLP:RED and revoked)
• Unpublish — Remove from external visibility
• Revoke — Mark as no longer valid
• Unrevoke — Restore revoked indicators
• Delete — Remove indicators from the registry entirely
• Export — Export selected as CSV or STIX 2.1

Bulk operations can also be applied using the current filter instead of manual selection, allowing you to operate on large sets efficiently.

Indicators in Investigation Reports

When generating an investigation report for a case, DFIRe automatically includes an IOC Summary section listing all indicators associated with the case. This section includes each indicator’s value, type, classification, confidence, public notes, and any case-specific context notes added by the case team.

Webhook Events and Custom Triggers

The following webhook event types are available for IOC-related activities. Configure these in System Settings > Webhooks:

Event	Triggered When
ioc_added	An indicator is added to a case
ioc_classification_changed	An indicator’s classification changes
ioc_classified_malicious	An indicator is classified as malicious
ioc_classified_suspicious	An indicator is classified as suspicious
ioc_classified_benign	An indicator is classified as benign
ioc_published	An indicator is published to TAXII/MISP
ioc_unpublished	An indicator is unpublished
ioc_revoked	An indicator is revoked
ioc_unrevoked	An indicator revocation is removed
ioc_correlation	An indicator is found in multiple cases

Custom Webhook Triggers

In addition to the built-in events, the IOC Enrichment settings allow you to define custom webhook triggers that appear as response buttons on IOC Intelligence pages. This lets you create custom automated actions such as “Block IP on Firewall” or “Add to Blocklist” on the Respond tab of an indicator's Intelligence page.

To set up a custom trigger:

1. Go to Settings > IOC Enrichment and scroll to Webhook Triggers
2. Click Add Trigger and define a name and trigger ID
3. Go to Settings > Webhooks and create an outgoing webhook
4. Select the corresponding custom trigger event type
5. Configure the webhook endpoint and payload template with the indicator data

When an analyst clicks the trigger button on an IOC’s Intelligence page, the configured webhook fires with the indicator data, enabling integration with firewalls, SIEMs, SOAR platforms, or any HTTP endpoint.

Permissions

IOC management requires the following permissions, assigned through user groups:

Permission	Allows
manage_indicators	Create, edit, delete, classify, tag, publish, and revoke indicators
export_indicators	Export indicators in CSV and STIX 2.1 formats
import_indicators	Import indicators from CSV, STIX 2.1, and plaintext

Viewing indicators in the global registry requires the standard view_indicator permission. Adding indicators to a specific case requires both indicator permissions and write access to that case.

Search Integration

Indicators are included in DFIRe’s global search. When you search from the top navigation bar, results include matching indicators alongside cases, evidence, notes, and entities. Indicator search matches against the IOC value, public notes, and STIX type.

Deduplication and Normalization

DFIRe automatically normalizes indicator values to prevent duplicates:

• Domains and emails are lowercased
• URLs have their scheme and host lowercased (path case is preserved)
• IPv4 addresses have leading zeros stripped; CIDR host bits are normalized
• IPv6 addresses are expanded to standard form
• File hashes are lowercased
• AS numbers are normalized to AS<number> format

Two indicators are considered duplicates if they have the same normalized value and STIX type. When you add a duplicate, the existing indicator is linked to your case rather than creating a new entry.