Indicators of compromise

What the registry is

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

Indicator 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	[email protected]
Email Message	Email metadata (subject, headers)	Phishing email subject line
File Hash	MD5, SHA-1, SHA-256 or SHA-512 hash, or an SSDEEP or TLSH 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
AS Number	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

DFIRe checks the value of each new indicator against the format of its type. The checks cover IP addresses and CIDR ranges, email addresses, domains, URLs, MAC addresses, file hashes and AS numbers. DFIRe refuses a value that does not match, and imports list each refused row with the reason.

An indicator’s value and type cannot change after creation. To replace a wrong value, create a new indicator and revoke or delete the old one.

DFIRe does not change existing indicators. An indicator created before these checks keeps its value, even a malformed one, and DFIRe shares it like any other indicator. A receiving platform can refuse a malformed value.

The checks do not query DNS or test reachability. DFIRe accepts CIDR ranges with host bits set and single-label local names such as intranet. It accepts internationalized domains in Unicode or xn-- form, but refuses invisible and full-width characters. It also refuses a domain whose last label is a number: enter an IP address as an IP address type. A URL must start with a scheme, such as https://.

A file hash is MD5, SHA-1, SHA-256 or SHA-512 in hexadecimal, or an SSDEEP or TLSH hash. An AS number is from 0 to 4294967295, with or without an AS or ASN prefix. AS 13335, ASN13335 and AS13335 are one indicator. DFIRe shares a MAC address in colon form, also when you enter it with hyphens.

What an indicator carries

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

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. Set tags when you create or edit an indicator, import a file, or apply the tags from an enrichment result. To add, remove or replace tags on many indicators at once, use POST /api/indicators/bulk-tag/ in the API. See Tagging in bulk.

Add IOC on a case, New Indicator in the registry and the Assessment panel of the intelligence page each have a Tags field. Type a tag and press Enter. A comma is part of the tag. The list under the field suggests the most used indicator tags, each with the number of indicators that carry it. The list shortens a long tag, and pointing to it shows all of it. Select a suggestion with a click, or with the arrow keys and Enter.

To add several tags at once, paste them one per line. Text left in the field becomes a tag when you leave the field or save. The field refuses a tag longer than 128 characters and says why. In the Assessment panel, Save stores the tags with your other changes.

A tag can hold any text of up to 128 characters, including MISP machine tags such as misp-galaxy:threat-actor="APT 28". DFIRe stores the literal text, so R&D stays R&D. However a tag arrives, DFIRe removes markup and trims the ends. It turns HTML codes such as & into the characters they stand for and removes every <. It drops blank and duplicate tags, tags longer than 128 characters, and any value that arrives with more than 4,096 characters. The API refuses a tags value that is not a list, such as a single string or null, and drops list entries that are not text.

The registry and the IOCs tab of a case show the tags on every card and table row. Select a tag there to filter the list by it. See Cards and table.

To select indicators by tag in the API, add a tags row to the filter chain of GET /api/indicators/. The row f=and:tags:equals.case:Acme,%20Inc keeps the indicators that carry the tag Acme, Inc, with the same letter case. DFIRe never splits the value of a row, so a tag can hold a comma. GET /api/indicators/classification-counts/ takes the same rows. A bulk operation on all matching indicators takes them as a list in filter_params.f. The tag parameter splits its value at commas, and an indicator must carry every part.

GET /api/indicators/tags/ returns up to 20 tags, most used first, each with the number of indicators that carry it. With q, it returns only the tags that contain that text, in any letter case. Repeat exclude to leave out tags you have already chosen.

CSV files separate tags with commas. A tag that holds a comma therefore becomes two or more tags when it passes through a CSV file. In Slack, the Tags field of the IOC forms takes one tag per line, so a tag can hold a comma there too.

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:

By hand

1. Open the case and navigate to the IOCs tab
2. Click Add IOC
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 IOC, or Link to Case when the value is already in the registry

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.

Extracted from case content

DFIRe can scan case notes, item notes, evidence item values and the case chat 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. DFIRe scans the case chat a message at a time, assistant answers included. Redacted messages hold no text, so they contribute nothing. A role that cannot read the chat scans the rest of the case
4. Review the candidates. Each names its type and where DFIRe found it, and a chat finding names the author and the time of the message it came from
5. Select which candidates to add, adjust classifications if needed
6. 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.

Scans and extraction suggest only values that pass the checks described under Indicator types. If a URL or an email address fails them, DFIRe suggests its host or domain instead, if that passes.

Pasted text

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.

In bulk

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. The observables are imported with the classification, confidence, and tags carried by the Indicator objects that describe them.
• Plaintext. One indicator per line. Types are auto-detected. Works well with pasted lists from threat reports or log analysis. Like extraction, it takes only values that pass the checks, and the host or domain of a URL or an email address that fails them. The import on the IOC Registry page lists each value it leaves out, with the reason.

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

The case IOCs tab

The IOCs tab of a case shows its indicators as cards or as a table, like the registry. It opens with the indicators most recently added to the case first. The table adds columns for the case context, the evidence items, the source, who added the indicator and when. By default it shows the value, type, classification, TLP, tags, context, evidence and the time added, and Columns shows the others. The case sidebar folds away while the table shows.

An indicator comes under its parent only when the parent is also in the case. Users who can edit the case get buttons at the end of each table row. The buttons edit the case context, choose the evidence items or remove the indicator from the case. Only they can select indicators and use the bulk actions.

The search on the IOCs tab matches the value and the case context. Filter offers the columns of the table except Cases and Enrichment, and also the revoked state. Selecting a tag on a card or in a row adds its filter row, as in the registry. When a filter matches an indicator but not its parent, the parent stays in the list, dimmed. The search and the filters are part of the page address. They stay when you switch to another case tab and back, and the back link of an indicator page returns to them.

Evidence items

An indicator in a case can name the evidence items of that case it is associated with. The link belongs to the case, like the case context. The registry, the STIX and MISP exports and the TAXII server do not carry it. The case export, the report and the API do.

Viewing evidence links requires access to the case and permission to read evidence items. Restricted case associations show only the case number, status and lead investigator.

On a card, Evidence lists the items, each a link to the item. Link evidence... on a card, or the evidence button at the end of a table row, opens the case's evidence items to choose from. Only users who can edit the case change the items.

Each evidence item has an IOCs tab that lists the indicators linked to it. Add IOC there adds the indicator to the case and links it to the item. When the case already holds the indicator, the item joins its evidence. Scans, imports, exports and removing an indicator from the case stay on the case IOCs tab. Deleting an evidence item removes its links, and the indicators stay in the case.

Breaking an indicator apart

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:

A URL

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

An email address

Adding [email protected] creates:

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

A CIDR block

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.

Each part judged on its own

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.

The registry page

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:

• Search and filter indicators. The search matches the value, the public notes and each tag on its own, ignoring letter case. Filter builds rows on the value, the notes, the type, the confidence, the TLP, the published and revoked state, the tags, and the first and last seen dates
• 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.

Search and filters

The classification tabs split the registry, which opens on All IOCs. The search and the filters apply within the selected tab, and each tab count follows them. Filter rows join from left to right with AND, OR and NOT, for example Tags contains phish OR Type equals URL. To move a row, drag its chip by the grip at its start, because the order can change the result. The tab, the search and the filters are part of the page address. They survive a reload, and you can share them as a link. The back link of an indicator page returns to the registry with the same tab, search and filters.

Cards and table

The registry lists indicators as cards or as a table. Switch between them with Cards and Table above the list, and the browser remembers the choice. The list opens with the most recently seen indicators first. In the cards, choose the order under Sort by. In the table, select a column heading to sort by that column, and select it again to reverse the order.

The table shows the value, type, classification, confidence, TLP, tags, case count, enrichment and last seen time. Columns adds the published state and the first seen time, or hides a column, and the browser remembers the choice. Classification, confidence and TLP sort by rank. Tags sort by their number, and enrichment by malicious results, then suspicious results, then all results. An indicator without a value in the sorted column comes last in both directions.

A card or a table row shows up to five tags of the indicator. Select +N to show the rest, and Hide to hide them again. DFIRe shortens a long tag, and pointing to it shows all of it.

Select a tag to add the row Tags equals that tag, with Match case, to the filters. Selecting a tag does not open the indicator. If the filters already have that row, nothing changes. A list holds at most 20 filter rows, and when it is full, a message asks you to remove one first.

Both views show the hierarchy. A child indicator, such as a URL under its domain, always comes directly under its parent. Sorting orders the indicators at each level among themselves. When a filter matches a child but not its parent, the parent stays in the list, dimmed, so the child keeps its place.

DFIRe sorts the whole registry before it loads a page. The count above the list compares the matching indicators loaded so far with all matching indicators, for example 50 of 1,204 indicators. Load more adds the next indicators, and a parent always loads together with the indicators under it.

The intelligence page

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

Details

Shows the public notes, the indicator hierarchy and metadata such as the normalized value and the creation and update times. The classification, confidence, TLP and tags are in the Assessment panel beside the tabs.

To place the indicator under another indicator, select Set Parent, or Set Parent Manually on an indicator without a hierarchy, and search for the parent. DFIRe refuses a parent that is the indicator itself or one of the indicators under it, because that would make a loop. The same rule applies to PATCH /api/indicators/{id}/ and to the MCP tool update_indicator.

Relations

Lists the cases associated with the indicator. A case you can open shows its title and its case-private context notes. A case you cannot open shows only its number, its status and its lead investigator, whom you can ask for details. The tab also 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

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.

Correlation across cases

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, no key needed

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, 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. Requires an API key (add one under Settings → IOC Enrichment) to submit and read scans
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 a 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 (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.

Turning providers on

1. Navigate to 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.

Caching

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 limits

Enrichment requests are capped per provider, at 30 requests per minute for most providers, so DFIRe does not overload an external API. A provider that reaches its cap is skipped until its earlier requests age out of the one-minute window. The cap does not track a provider’s own quota: if your plan allows fewer requests per minute than that, leave auto-run off for the provider and enrich on demand.

Publishing and lifecycle

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

States

• Unpublished. Visible only to internal DFIRe users and not shared through TAXII or MISP. Authorized manual exports can still include it.
• Published. Available to external consumers via the TAXII 2.1 server and MISP feed.
• Revoked. Marked as no longer valid. Revoked indicators that were published appear with revoked: true in STIX output so consumers know to remove them.

Automatic 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 Settings → Retention Policy → IOC Lifecycle:

• Auto-revoke expired indicators. Enable or disable
• Default expiration. Days until new indicators expire, 365 on a new installation. The add-indicator form prefills Valid Until from it. Set it to 0 for no 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)

What can be published

• Publishing and unpublishing require the manage_indicators permission, wherever they are done: from the registry, in bulk, from Slack, or by selecting Publish immediately when adding an indicator to a case
• 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
• Adding an indicator to a case succeeds even when publishing is declined; the indicator is added unpublished and the reason is shown

Revoked indicators

STIX 2.1 makes revocation permanent, so DFIRe sends no new version of a revoked indicator. Its value, type, classification, confidence, TLP, tags, public notes and expiry cannot change until you unrevoke it. Bulk changes to classification, confidence, TLP and tags skip revoked indicators and report how many they skipped. Unpublishing, deleting, enriching and linking to cases still work on a revoked indicator, and so do changes to its parent and case context.

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 Settings → IOC Sharing. Each service has an independent enable toggle; the settings page collapses each service’s configuration when its toggle is off.

The 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 Settings → IOC Sharing > TAXII 2.1 Server (server title, description, contact, page-size limits, and case-association toggle).
• Indicator Collections are filtered views of the registry by STIX type, classification, confidence, or tag. Copy the Collection ID beside its name when configuring a client. Collections only apply to TAXII.
• Match any tag in the collection dialog sets the tag filter. A collection with tags there admits an indicator that carries any one of them, matched exactly and case-sensitively. The field adds and suggests tags as the indicator tag field does, so a comma is part of a tag. DFIRe refuses a filter with a blank tag, a tag longer than 128 characters, or a tag with markup or an HTML code. The field then shows the reason, and the collection stays as it was.
• The audit log records the creation, each edit and the deletion of a collection. An edit entry holds the old and new value of each changed field, such as the tag filter.
• TLP:RED indicators are hard-filtered at the database level and never appear in TAXII responses.
• With Share case associations on, each case appears as a STIX Grouping, and Relationship objects link it to its indicators. TAXII clients then see which cases an indicator belongs to. The manifest lists these objects, and the filters select them by type, ID and version like any other object.
• A Grouping lists every indicator of the case that the collection holds, and arrives with the last of them. Adding an indicator to the case or editing the case gives the Grouping a new version. A client that polls with added_after receives that version after the next publication or edit of one of the case’s indicators. A poll without added_after carries the current version. Removing an indicator does not give a new version, so a client that already holds the Grouping keeps the old list.
• An API key is scoped to TAXII via its TAXII 2.1 Server toggle (see API Key Scopes below).

Connecting a TAXII client

1. Enable the TAXII server and create a collection under Settings → IOC Sharing.
2. Create an API key with TAXII access and allow access to that collection.
3. Set the client to TAXII 2.1. Use https://your-dfire-host/taxii2/ for discovery or https://your-dfire-host/taxii2/api1/ for the API root.
4. Paste the collection’s UUID into the client’s collection field. Authenticate with Authorization: Bearer <API key>.
5. Publish the indicators to share. Choose an initial import date before their publication to include existing data.

OpenCTI uses the API root and collection ID in its TAXII feed configuration. Its confidence and decay policies also affect imported indicators.

Updates and markings

DFIRe skips network-traffic, artifact, and email-message records when preparing TAXII pages. Their stored text values lack the structured fields needed for STIX export. Process records remain available as Indicator patterns. These records remain in the IOC registry.

Incremental polling includes newly published indicators, edits, and revocations. DFIRe serves each object’s current version. A change reaches TAXII clients about 5 seconds after DFIRe saves it. Editing a collection refreshes its snapshot, including older indicators that now match its filters.

Follow every next token while more is true, and resume an interrupted walk with its last next token. DFIRe sets more to true only when the next page has objects. After a complete walk, use its last X-TAXII-Date-Added-Last value as added_after for the next poll. Do not resume an incomplete walk with this value. Publishing or editing in bulk, or editing a collection, gives many indicators the same date-added value, and a page can end inside that group. Date-added values are whole milliseconds, so a client that stores them at millisecond precision, such as OpenCTI, does not receive the same objects again.

Revocation keeps an indicator in the feed with revoked: true. DFIRe refuses edits to a revoked indicator, so it sends no later version of it. Unpublishing an indicator, or changing an active one to TLP:RED, removes it from future responses. Removal does not delete copies already imported by a client.

Both indicators and observables carry their source TLP marking. TLP:AMBER+STRICT uses the OASIS TLP 2.0 extension. A receiving platform must support that extension to enforce the restriction. Other levels use the STIX 2.1 standard markings, including TLP:WHITE for CLEAR.

Exported bundles include the TLP 2.0 marking and extension definitions. A TAXII collection sends them once, before its first TLP:AMBER+STRICT object. A client that starts polling after that object can request them by ID with match[id]: marking-definition--939a9414-2ddd-4d32-a0cd-375ea402b003 and extension-definition--60a3c5c5-0d10-413e-aab3-9e08dde9e88d.

The MISP 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 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.

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

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 observables and Indicator objects, with the TLP marking definitions the bundle references. Compatible with MISP, OpenCTI, and other STIX-consuming platforms.

Observables and Indicator objects both carry the source indicator’s TLP marking. STIX 2.1 itself has no TLP:AMBER+STRICT marking. DFIRe exports those indicators with the AMBER+STRICT marking from the OASIS TLP 2.0 extension, and the bundle includes the marking and extension definitions. The receiving platform must support that extension to enforce the restriction. STIX 2.1 has no TLP:CLEAR either, and DFIRe exports those indicators as TLP:WHITE, the older name for the same level.

Some indicators cannot be written as valid STIX 2.1 and are left out of the bundle rather than exported in a form no consumer can read. Network traffic, artifact, and email message indicators are omitted, because STIX 2.1 describes those types with properties DFIRe does not hold. So are a file hash whose length matches no algorithm or whose value is not hexadecimal, and an autonomous system number that is not a number. Process indicators export as an Indicator object with a pattern and no observable. Use the CSV export when you need every indicator regardless of type. A bundle with nothing to export has no objects list, because STIX 2.1 does not allow an empty one.

CSV exports open as text, never as live formulas: a cell starting with a character a spreadsheet would treat as the start of a formula is prefixed with a single quote, which DFIRe removes again if the file is imported back.

Manual exports are separate from TAXII and MISP publication, so CSV and STIX exports can include both published and unpublished indicators. Global, bulk, and case exports require both view_indicator and export_indicators. Case exports also require access to the case.

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

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 the observables in a bundle, with the classification, confidence, and tags carried by the Indicator objects that describe them. A bundle of Indicator objects with no observables imports the values from their patterns. A bundle without an objects list is empty and imports nothing.
• 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

In the IOC Registry and the case IOCs tab, choose Select... between the search box and Filter to show checkboxes. Selecting indicators opens a toolbar of bulk actions. Switching between cards and table keeps the selection. Choose Cancel selection to clear the selection and hide the checkboxes again.

Five of them are staged rather than applied on the spot. Choose a value in any of these, leave the rest blank, and press Apply to commit them together:

• Publishing: publish the selection via TAXII and MISP, or unpublish it. Publishing skips TLP:RED and revoked indicators and reports how many it skipped.
• Revocation: mark indicators as no longer valid, or restore revoked ones.
• Classification: malicious, suspicious, benign or unknown.
• Confidence: high, medium or low.
• TLP: CLEAR, GREEN, AMBER, AMBER+STRICT or RED.

Staging them together means one confirmation for the whole change, and the markings are written before publishing, so raising an indicator to TLP:RED in the same action stops it from being published.

Classification, confidence and TLP changes skip revoked indicators, and DFIRe reports how many it skipped. Apply unrevokes before it makes these changes and revokes after them, so one action can do both.

The remaining actions apply immediately: Export CSV and Export STIX 2.1, and either Delete in the registry or Remove from case on a case's IOCs tab, which detaches the indicators without deleting them.

In the registry, to act on every indicator that matches the search and the filters, select all visible indicators first. The toolbar then offers to select all matching indicators. A dimmed parent, shown only to place a matching indicator, is not selected by either. Changing the tab, the sort, the search or the filters clears the selection.

Tagging in bulk

To change the tags of many indicators at once, use POST /api/indicators/bulk-tag/. Select the indicators with indicator_ids, or select every indicator that matches the filters in filter_params. Its filter rows go in filter_params.f, as described in Filtering lists. Give the tags as a list. The mode decides what happens:

• add, the default, adds the tags an indicator does not have yet after its own tags.
• remove takes the given tags off.
• replace sets the tags of each indicator to the given list.

Any other mode returns status 400. The response counts in updated only the indicators whose tags changed, and in skipped_revoked the revoked indicators it left as they were. The request needs the permission to change indicators, and the audit log records it.

Indicators in 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 triggers

The following webhook event types are available for IOC-related activities. Configure these in Settings → Webhooks & Email:

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 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 & Email 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	Publishing, unpublishing, revoking and unrevoking, one indicator at a time or in bulk
export_indicators	Export registry and case indicators in CSV and STIX 2.1 formats when combined with view_indicator
import_indicators	Import indicators from CSV, STIX 2.1, and plaintext

Creating, editing and deleting an indicator use the ordinary add, change and delete permissions on the indicator object, and reading the registry needs view_indicator. The same permissions apply in bulk: change for classification, confidence, TLP and tags, and delete for deleting. Adding an indicator to a case additionally needs write access to that case. See Users and roles.

Search

Indicators appear in global search alongside cases, evidence and notes, matched on their value, their public notes, their STIX type and their tags. The Indicator button in search shows only the indicators. To filter them by STIX type, TLP, classification and tags, use the registry. See Search.

Deduplication

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, except SSDEEP hashes, which keep their case. A TLSH hash loses its T1 prefix
• MAC addresses are lowercased and use colons
• 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.

An earlier DFIRe version may have stored an indicator in another form. Entering the same value again still finds it. Another spelling creates a new indicator, for example AS13335 when the stored value is AS 13335.