10.1 Threat Intelligence & Indicator Match Rules

In modern enterprise Security Operations Centers (SOCs), defending against sophisticated threat actors requires continuously correlating internal operational telemetry with external cyber threat intelligence (CTI). Relying solely on static indicators of compromise (IOCs) hardcoded into traditional query rules introduces severe operational friction: updating an IP blocklist or file hash table would require manually editing dozens of individual detection rule queries. Furthermore, simple Lucene queries cannot cross-reference two independent data sets dynamically without complex ingestion-time joins.

Elastic Security addresses this challenge through Indicator Match Rules (internally designated as threat_match rules). This specialized rule type executes a high-performance, dual-query correlation engine that matches streaming telemetry against dedicated threat intelligence indices in real time. Mastering the architecture, field mapping mechanics, feed integrations, and lifecycle tuning of Indicator Match rules is a core competency for the Elastic Certified SIEM Analyst.

---

Indicator Match Rule Architecture: The Dual-Query Correlation Engine

Unlike standard Custom Query rules that inspect a single index pattern (such as logs-endpoint.events.*), Indicator Match rules operate across two fundamentally distinct index sets during every execution interval:

1. Source Telemetry Indices: The operational event streams generated by enterprise infrastructure (e.g., endpoint process logs, perimeter firewall connections, DNS resolutions, authentication audits).
2. Threat Intelligence Indicator Indices: The reference data streams populated by threat intelligence integrations (by default the logs-ti_* pattern from the securitySolution:defaultThreatIndex advanced setting, which matches Elastic's threat intelligence integrations), containing validated indicators such as malicious file hashes, command-and-control (C2) domain names, and botnet IP addresses.

+---------------------------------------------------------------------------------------------------+
|                         INDICATOR MATCH DUAL-QUERY EXECUTION ARCHITECTURE                         |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|   [ SOURCE TELEMETRY INDICES ]                             [ THREAT INTEL INDICATOR INDICES ]     |
|   - Index Pattern: logs-endpoint.*, logs-network.*         - Index Pattern: logs-ti_*             |
|   - Source Query: event.category: "network"                - Indicator Query:                     |
|   - Look-back Window: Last 5 minutes                         threat.indicator.confidence: "High"  |
|                                                              AND @timestamp > "now-30d/d"          |
|                   |                                                        |                      |
|                   +---------------------------+----------------------------+                      |
|                                               |                                                   |
|                                               v                                                   |
|                               +-------------------------------+                                   |
|                               |  THREAT MAPPING CORRELATION   |                                   |
|                               |  destination.ip  <=========>  |                                   |
|                               |       threat.indicator.ip     |                                   |
|                               +-------------------------------+                                   |
|                                               |                                                   |
|                                               v                                                   |
|                               [ MATCH IDENTIFIED: TRUE POSITIVE ]                                 |
|                                               |                                                   |
|                                               v                                                   |
|                               +-------------------------------+                                   |
|                               |     ALERT ENRICHMENT ENGINE   |                                   |
|                               | Injects threat.* metadata:    |                                   |
|                               | - threat.feed.name            |                                   |
|                               | - threat.indicator.confidence |                                   |
|                               | - threat.tactic.name          |                                   |
|                               +-------------------------------+                                   |
|                                               |                                                   |
|                                               v                                                   |
|                        [ WRITE TO .alerts-security.alerts-* ]                                     |
|                                                                                                   |
+---------------------------------------------------------------------------------------------------+

The Execution Pipeline

During each scheduled rule execution interval (e.g., every 5 minutes with a 1-minute look-back buffer), the Elastic Security Detection Engine executes the following operational phases:

1. Source Query Execution: The engine queries the source indices using the defined Source Query and time window. For example, it retrieves all network connection events where event.category: "network" and not destination.ip: (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16).
2. Indicator Query Execution: Concurrently, the engine evaluates the Indicator Query against the indicator indices. To prevent querying stale or low-confidence data, this query filters indicators by age and, where the feed provides it, confidence. The default indicator index query is @timestamp > "now-30d/d", which keeps indicators ingested in the last 30 days (rounded down to midnight UTC). A stricter example: @timestamp > "now-30d/d" and threat.indicator.confidence: ("High" or "Medium").
3. Threat Mapping Join: The engine cross-references the retrieved source events with the active indicator documents based on configured Threat Mapping Field Pairs. Elasticsearch performs optimized inverted index lookups between the specified fields.
4. Alert Synthesis and Metadata Enrichment: When a source document field matches an indicator field, the engine constructs a security alert document in .alerts-security.alerts-*. Crucially, the alert contains the full source event context combined with enriched metadata copied directly from the matching indicator document.

---

Configuring Threat Mapping Field Pairs

The foundation of an Indicator Match rule is the Threat Mapping configuration. This defines which ECS field in the source telemetry corresponds to which ECS field in the threat indicator index.

Elastic Common Schema (ECS) standardizes threat intelligence fields under the top-level threat.* and threat.indicator.* hierarchies. Because different attack vectors manifest across distinct telemetry types, analysts must establish precise mapping pairs:

Common Threat Mapping Field Pairs

Multi-Field Composite Mappings

Elastic Security supports defining multiple mapping sets within a single Indicator Match rule. For example, an analyst can configure an endpoint file monitoring rule with two alternative mappings:

• Mapping 1: file.hash.sha256 <===> threat.indicator.file.hash.sha256
• Mapping 2: file.hash.md5 <===> threat.indicator.file.hash.md5

Entries joined with AND inside one mapping group must all match, while separate groups are joined with OR, so if either mapping group matches, an alert is generated. Only single-value fields are supported, and pairing fields of incompatible types (for example an IP field with a keyword domain field) will not produce matches. You can even point the indicator index at a value list (.items-<space-id>) to match events against an uploaded list of indicators.

---

Threat Intelligence Integrations & Ingestion Pipelines

Threat indicators enter the Elastic Stack through Elastic Agent integrations managed via Fleet, or through custom ingestion pipelines communicating with threat intelligence platforms (TIPs).

Supported Fleet Threat Intel Integrations

Elastic Security provides prebuilt integrations for industry-standard threat intelligence feeds and protocols:

• MISP (Malware Information Sharing Platform): Ingests MISP events, attributes, and threat levels over REST APIs.
• AlienVault OTX: Subscribes to Open Threat Exchange pulses, parsing IP, domain, and hash indicators.
• Anomali ThreatStream & Mandiant Advantage: Enterprise integrations streaming commercial high-fidelity threat intelligence.
• TAXII (Trusted Automated eXchange of Intelligence Information): Polls TAXII 2.x servers that publish STIX-formatted indicator collections.
• Custom Threat File Ingestion: Ingests flat CSV or NDJSON feeds containing internal SOC blacklists or incident-specific indicators.

Ingestion Pipelines and Normalization

Incoming indicators pass through ingest pipelines that parse vendor-specific structures into ECS-compliant fields. For example, an AlienVault pulse indicator of type IPv4 is mapped to threat.indicator.ip, while the pulse name is mapped to threat.feed.name. The pipeline also populates:

• @timestamp: Set to the ingestion timestamp or indicator publication timestamp.
• threat.indicator.type: Normalized indicator classification using ECS values such as ipv4-addr, domain-name, url and file.
• threat.indicator.marking.tlp: Traffic Light Protocol classification (ECS values such as CLEAR, GREEN, AMBER and RED).
• Expiry handling: many Elastic threat intelligence integrations support IOC expiration, keeping only unexpired indicators in a separate latest-indicators index so rules stop matching stale IOCs.

---

Alert Metadata Enrichment

The main operational advantage of Indicator Match rules is automatic indicator enrichment. When a match occurs, the alert records which field matched and copies the matching indicator's details into the threat.enrichments array of the alert document:

{
  "threat": {
    "enrichments": [
      {
        "matched": {
          "atomic": "198.51.100.42",
          "field": "destination.ip",
          "type": "indicator_match_rule"
        },
        "indicator": {
          "type": "ipv4-addr",
          "ip": "198.51.100.42",
          "confidence": "High",
          "description": "Command and control node reported by the feed",
          "first_seen": "2026-08-15T04:12:00.000Z",
          "last_seen": "2026-09-28T18:22:10.000Z",
          "marking": { "tlp": "AMBER" }
        },
        "feed": { "name": "Example Threat Feed" }
      }
    ]
  }
}

Two points are often confused:

• The MITRE ATT&CK tactic and technique shown on an alert come from the rule's own threat mapping (kibana.alert.rule.threat), not from the indicator document.
• Enrichment is not limited to indicator match rules. The alert details flyout's Threat intelligence section also queries the threat indices at investigation time. By default it searches the past 30 days for indicators that match fields on any alert, listed as Fields enriched with threat intelligence. The Threat match detected part is populated only for alerts from indicator match rules.

This enrichment saves analysts from copying IP addresses into external portals during triage. The feed, confidence and TLP marking are already on the alert.

---

Performance Optimization & Indicator Lifecycle Hygiene

Because Indicator Match rules perform cross-index search joins, poorly configured rules can degrade cluster search performance, trigger query timeouts, or flood the SOC with false positives from stale indicators. SIEM analysts must implement strict indicator hygiene.

1. Scoping Source and Indicator Queries

Never leave the Source Query or Indicator Query blank. An unconstrained query forces Elasticsearch to scan millions of documents across all historical indices:

• Source Scoping: Constrain source telemetry to specific event categories or protocols (e.g., event.category: "network" and network.direction: "outbound"). Exclude RFC 1918 private subnets from destination IP matching to prevent accidental internal matches.
• Indicator Scoping: Restrict indicators by recency and confidence: threat.indicator.confidence: ("High" or "Medium") and @timestamp > "now-30d/d" (ECS confidence values are capitalized: Not Specified, None, Low, Medium, High). Stale indicators frequently represent reallocated cloud IPs or recycled domains.

2. Indicator Deduplication

Threat feeds frequently publish the same IOC across multiple pulses or updates. If an indicator index contains 50 identical documents for the same IP address, an Indicator Match rule matching that IP will process redundant join operations. Ingestion pipelines should implement fingerprint processors or leverage Elasticsearch document IDs derived from SHA256(threat.indicator.ip + threat.feed.name) to enforce index-level deduplication.

3. Indicator Expiration & Index Lifecycle Management (ILM)

Threat indicators have a finite half-life. C2 servers are decommissioned, compromised websites are remediated, and dynamic DNS entries change hourly. Managing indicator lifecycles requires:

• Turning on IOC expiration in threat intelligence integrations that support it, so expired indicators drop out of the latest-indicators index the rule searches.
• Keeping the indicator index query time-bounded (the default @timestamp > "now-30d/d" or a window that suits the feed) and using ILM on logs-ti_* data streams to delete raw indicator history you no longer need.