Indicator types

The Type column on the Indicators table tells you what kind of artifact each IOC represents. Mimir tracks nine types in v1, and each one matches against a different kind of agent evidence. This page is the reference for what each type means, where it matches, and when you’d pick one over another.

The nine types

Type	Display	Matches against
`file_hash_sha256`	SHA256	osquery `hash` table + scheduled file events
`file_hash_sha1`	SHA1	same as SHA256, sha1 column
`file_hash_md5`	MD5	same as SHA256, md5 column
`filename`	Filename	osquery `file`, `processes` (basename of `path`)
`filepath`	Path	osquery `file.path`, `processes.path`
`registry_key`	Registry	osquery `registry` (Windows only)
`ipv4`	IPv4	`process_open_sockets` (snapshot) + `socket_events` (evented)
`domain`	Domain	`dns_lookup_events` (`name` / `status`), plus `processes.cmdline` substring
`url`	URL	tracked but not currently matched on-host

Three families: file artifacts (the first six types), network artifacts (ipv4, domain), and URLs (tracked for context but not currently used in matching).

File hashes (SHA256 / SHA1 / MD5)

The cleanest indicator type. Each hash is matched against every file osquery has seen, via the hash table cross-joined with the file table. Hashes also flow through scheduled file events: if the FIM pack is active, every CREATED, UPDATED, or MOVED_TO event generates a hash that’s checked against your active indicators within the next watchlist tick.

When to use which:

SHA256 is the modern default. Every malware-as-a-feed source publishes SHA256 first. Use this unless you have a specific reason not to.
SHA1 is supported because some older indicator sources (and some Windows artifacts like Authenticode catalog entries) publish SHA1 only. The match path is the same.
MD5 is supported for the same reason but is the weakest of the three. Don’t deliberately add MD5 when you have a SHA256 for the same binary — collisions are cheap.

Hashes are checked against files at rest. If an attacker only loads malicious code into memory and never writes it to disk, a hash indicator won’t catch it. Use a filename or behavioral hunt for those cases.

Filename and filepath

filename matches the basename of any path osquery has observed — binaries currently running (via processes), files on disk (via file), files in scheduled file events. This is the right type for “any executable named evil.exe, regardless of where it lives.”

filepath is the full path. Use this when the location is the suspicious signal: “any binary under %TEMP%\Roaming\persist\.” Mimir matches the full path string verbatim, so be specific — trailing slashes, case-sensitivity, and OS path conventions (/ vs \) all matter.

Both types are cheaper than hashes for the agent (no I/O to hash the file) but produce more noise. A filename indicator for notepad.exe would match every Windows host in the fleet.

Registry key

Windows-only. Mimir matches against osquery’s registry table — typically HKEY_LOCAL_MACHINE\... or HKEY_CURRENT_USER\.... The indicator value is the full registry path; matches happen when an agent observes that path (either through a pack or a watchlist sweep).

Most useful for persistence indicators: “anything that wrote to HKLM\Software\Microsoft\Windows\CurrentVersion\Run\<known-bad-name>.”

IPv4

Network indicator. Matched two ways:

Snapshot match via process_open_sockets — any process with an open connection to the indicator IP, at the moment the watchlist query ran.
Evented match via socket_events — every outbound connection that opened in the last 20 minutes, captured by the evented socket_events table the network-IOC pack subscribes to. Evented matches catch short-lived beacons that snapshot polling would miss.

IPv4 indicators are checked against remote_address. Mimir rejects loopback (127.0.0.0/8), private (10/8, 172.16/12, 192.168/16), link-local (169.254/16), CGNAT (100.64/10), multicast (224/4), broadcast (255.255.255.255), and the unspecified address (0.0.0.0) on add — these produce too much noise to be useful as IOCs. If you have a legitimate need to alert on private-range activity, use a hunt with a custom query instead.

Some well-known infrastructure IPs (public DNS resolvers, common CDN edges) come with a “noisy-infra” warning at add time, because they generate high alert volume regardless of malicious context.

Domain

Matched against dns_lookup_events — every DNS resolution attempt the agent has captured, with both the queried name and the status column read. Mimir also does a substring scan over processes.cmdline as a fallback, which catches “the domain appeared in a command line” cases (PowerShell downloading from a URL, curl arguments, etc.).

Domain indicators are the right match for C2 beaconing, phishing infrastructure, and dropper domains. The abuse.ch URLhaus feed imports thousands of these continuously.

URL

URLs are accepted into the indicators table for context (often pasted alongside other indicators from threat reports) but Mimir v1 does not currently match URL indicators against agent activity. The URL’s domain component is your best bet for matching — split the URL and add a domain indicator separately.

How the type column renders

Each indicator’s type is shown as a badge in the Type column, using the short form (SHA256, MD5, Filename, etc.). Hover any value to see the full string; click the copy icon to put the value on your clipboard. Hash values are truncated in the column to keep the table readable — first 8 chars, ellipsis, last 4 chars. The full value is still searchable via the search box.

Where to next

Add an indicator — the form you use to register these types one at a time, or paste a batch.
Matching modes — how the watchlist, historical scan, and hunts each use these types.
Built-in feeds (abuse.ch) — the source of most file-hash, IPv4, and domain indicators in a default tenant.