Threat Intelligence Indicators in Sentinel

Threat intelligence is evidence-based knowledge about existing or emerging threats, including context, mechanisms, indicators, and actionable advice. In cybersecurity, threat intelligence indicators (IOCs) are specific artifacts observed by security researchers that indicate malicious activity. Common IOCs include IP addresses, domain names, URLs, file hashes (MD5, SHA1, SHA256), email addresses, and registry keys. Sentinel uses these indicators to detect known threats by matching them against data ingested from various sources like Azure AD logs, Windows Event Logs, and network logs.

Sentinel supports two primary methods for ingesting threat intelligence:

1. Built-in Threat Intelligence Connectors: These connect to external threat intelligence platforms (TIPs) or feeds. The main connectors are: - Microsoft Defender for Threat Intelligence (MDTI): Provides premium intelligence from Microsoft's vast telemetry. It includes indicators, articles, and threat actor profiles. - TAXII Connector: Supports TAXII 2.0 and 2.1 protocols to pull intelligence from feeds like AlienVault OTX, Anomali, and others. You configure a TAXII server URL, collection ID, and polling interval. - Threat Intelligence – Upload Indicators (Preview): Allows manual upload of CSV or JSON files containing IOCs.

Once ingested, indicators are stored in the ThreatIntelligenceIndicator table in Log Analytics. This table has a schema that includes fields like IndicatorId, IndicatorType, ThreatType, ConfidenceScore, Severity, and ExpirationDateTime. The table is optimized for high-volume ingestion and fast lookups.

Every indicator has an expiration date. Sentinel automatically removes expired indicators from the active matching set. The default expiration is set by the source feed, but you can override it. Expired indicators are still stored in the table for historical analysis but are not used for alert generation. The indicator lifecycle:

To use threat intelligence, you must create an Analytics Rule of type Threat Intelligence. These rules are essentially detection queries that join the ThreatIntelligenceIndicator table with other data tables (e.g., SigninLogs, CommonSecurityLog, SecurityEvent). The rule runs on a schedule (default every 5 minutes) and generates alerts when a match is found.

Key configuration parameters:

let iocs = ThreatIntelligenceIndicator
| where ExpirationDateTime > now()
| where Active == true;
let ipMatches = CommonSecurityLog
| where TimeGenerated > ago(5m)
| evaluate ipv4_lookup(iocs, DestinationIP, NetworkIP, return_unmatched = false);
ipMatches
| project TimeGenerated, Message, SourceIP, DestinationIP, IndicatorId, ThreatType, ConfidenceScore

Sentinel uses several matching techniques:

Large threat intelligence feeds can contain millions of indicators. To maintain performance, Sentinel uses a lookup table that is optimized for high-speed joins. The ThreatIntelligenceIndicator table is indexed and partitioned. However, joining with large tables (e.g., CommonSecurityLog) can be resource-intensive. Best practices:

Threat intelligence indicators can be shared with Microsoft Defender XDR (formerly Microsoft 365 Defender) via the Microsoft Graph Security API. This bidirectional sharing allows indicators created in Defender to appear in Sentinel and vice versa. For example, a custom indicator added in Microsoft Defender for Endpoint can be used in Sentinel analytics rules.

To verify that threat intelligence is being ingested:

ThreatIntelligenceIndicator
| where TimeGenerated > ago(1h)
| summarize Count = count() by SourceSystem

If indicators are missing, check the connector health in Data connectors.

Threat intelligence integrates with:

A large financial institution subscribes to multiple threat intelligence feeds, including Microsoft Defender for Threat Intelligence (MDTI) and a third-party TAXII feed from a commercial provider. Their SOC team needs to detect when internal hosts connect to known malicious IPs. They deploy Sentinel and configure the MDTI connector (using the built-in connector) and the TAXII connector for the third-party feed. They create a TI Map analytics rule that joins the ThreatIntelligenceIndicator table with CommonSecurityLog from their firewalls. The rule runs every 5 minutes and alerts on any match with a confidence score above 60. In production, they ingest approximately 500,000 indicators daily. Performance is acceptable because Sentinel uses optimized lookups. However, they notice that some alerts are false positives due to stale indicators. To mitigate, they set a shorter expiration (e.g., 30 days) for indicators from less reliable sources. They also use entity mapping to group alerts by source IP, which helps the SOC prioritize incidents. Misconfiguration example: setting the polling interval too high (e.g., 60 minutes) causes delayed detection, allowing attackers more time. The SOC learned to set the interval to 5 minutes for critical feeds.

A technology company wants to detect insider threats by monitoring file hashes of proprietary documents. They create custom indicators using the Upload Indicators connector. They manually upload a CSV with SHA256 hashes of sensitive files and set the threat type to 'Insider Threat' and severity to High. They create an analytics rule that joins ThreatIntelligenceIndicator with SecurityEvent (for file creation events). When a user creates a file matching the hash, an alert fires. In production, they have about 1,000 custom indicators. They use expiration dates to automatically remove indicators after 90 days. A common pitfall: they initially forgot to set the indicator type correctly, causing the rule to not match because the query filtered by a specific type. They also learned that file hash matching is exact, so any modification to the file changes the hash and bypasses detection. They now use fuzzy hashing (SSDEEP) for similarity matching, which Sentinel supports if the indicator includes a fuzzy hash value.

A managed security service provider (MSSP) uses Sentinel to manage multiple customers. They create custom indicators in Microsoft Defender for Endpoint (MDE) for known malicious domains. They enable the bidirectional sharing via the Microsoft Graph Security API. These indicators automatically appear in Sentinel for all customers. They create a TI Map rule that matches these domains against Azure DNS logs. In production, they share about 10,000 indicators. They notice that indicators from MDE have a confidence score of 75 by default. They adjust the rule to only alert on confidence > 80 to reduce noise. A misconfiguration: they enabled sharing but forgot to assign the appropriate permissions (Threat Intelligence Read/Write) in Microsoft Graph, causing sync failures. They resolved by granting the Sentinel service principal the required permissions.