7.8 Threat Intelligence in Sentinel

Threat Intelligence in Sentinel

Introduction

Threat intelligence transforms Sentinel from a platform that detects patterns to a platform that detects known threats. An analytics rule that detects “sign-in from an unusual country” catches broad patterns. A TI-matching rule that detects “sign-in from IP 203.0.113.45, a confirmed APT29 C2 server” catches a specific, high-confidence threat. Both detection types are necessary — pattern-based rules catch unknown threats, TI-based rules catch known threats with precision.

Sentinel integrates threat intelligence through the ThreatIntelligenceIndicator table. Indicators (IP addresses, domains, URLs, file hashes, email addresses) are ingested from external feeds, Microsoft’s own threat intelligence, and manual analyst entry. Once ingested, indicators are available for KQL queries, analytics rules, and hunting queries.

Anatomy of a threat indicator

An indicator is a single observable with metadata describing the threat it represents.

Ingestion methods

Microsoft Defender Threat Intelligence (MDTI). Microsoft’s own TI platform provides indicators from global telemetry — billions of Windows endpoints, Azure workloads, and M365 tenants. One-click connector. Highest-value TI source for Microsoft environments because the indicators come from the same ecosystem you defend.

STIX/TAXII feeds. Industry-standard threat intelligence sharing. TAXII (Trusted Automated eXchange of Intelligence Information) is the transport. STIX (Structured Threat Information eXpression) is the format. Sentinel polls a TAXII server on a schedule and imports indicators. Free feeds: CISA AIS (US government threat data), AlienVault OTX (community). Commercial: Anomali ThreatStream, Mandiant Advantage, Recorded Future.

Configuration: Microsoft Sentinel → Data connectors → Threat Intelligence - TAXII → enter the TAXII server URL, collection ID, authentication credentials, and polling frequency.

Threat Intelligence Platform (TIP) connector. For organisations with a dedicated TI platform (MISP, ThreatConnect, Anomali), the TIP connector pushes indicators from the TIP into Sentinel via the Microsoft Graph Security tiIndicators API. This is the preferred method for organisations that curate indicators centrally before distributing to security tools.

Upload Indicators API. Programmatic indicator management: create, update, delete indicators via REST API. Use cases: Logic Apps playbook that extracts IOCs from incident reports and creates indicators automatically; script that ingests indicators from a vendor CSV; integration with a SOAR platform for automated IOC sharing.

Manual entry. For ad-hoc indicators during active investigations: Microsoft Sentinel → Threat Intelligence → Add new. Enter indicator type, value, threat type, confidence, and expiration. Use during incident response when you identify an IOC that needs immediate detection coverage before formal TI feed inclusion.

TI-matching analytics rules

Sentinel includes built-in analytics rule templates that match TI indicators against security data tables. These are the primary operational use of threat intelligence.

How they work: The rule joins ThreatIntelligenceIndicator with a security data table on the indicator value. Match found (sign-in from a known C2 IP) → alert generated.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// TI match: known-malicious IP in sign-in logs
ThreatIntelligenceIndicator
| where Active == true
| where ExpirationDateTime > now()
| where IndicatorType == "ipv4-addr"
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(1h)
    | where ResultType == "0"
) on $left.NetworkIP == $right.IPAddress
| project TimeGenerated, UserPrincipalName, IPAddress,
    ThreatType, ConfidenceScore, Description, Source

Built-in templates cover common scenarios: TI map IP to SigninLogs, TI map IP to AzureActivity, TI map domain to DeviceNetworkEvents, TI map hash to DeviceFileEvents, TI map URL to UrlClickEvents, TI map email to EmailEvents. Enable these templates — immediate detection value with zero custom development.

Confidence-based severity. Use confidence scores to tune alert impact:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// Dynamic severity based on indicator confidence
ThreatIntelligenceIndicator
| where Active == true and ExpirationDateTime > now()
| join kind=inner (
    DeviceNetworkEvents | where TimeGenerated > ago(1h)
) on $left.NetworkIP == $right.RemoteIP
| extend AlertSeverity = case(
    ConfidenceScore >= 80, "High",
    ConfidenceScore >= 50, "Medium",
    "Informational")
| project TimeGenerated, DeviceName, RemoteIP, RemoteUrl,
    ThreatType, ConfidenceScore, AlertSeverity

High-confidence matches (score ≥ 80) generate high-severity alerts for immediate investigation. Low-confidence matches generate informational alerts for analyst review during hunting.

Managing the indicator lifecycle

Threat intelligence is perishable. Indicators accurate last month may generate false positives this month. Effective TI requires ongoing lifecycle management.

Expiration discipline. Every indicator needs an expiration date. Tactical IOCs (campaign-specific IPs, domains): 30-90 days. Strategic IOCs (APT infrastructure patterns): 6-12 months. Review and extend indicators that remain relevant. Delete expired indicators.

Source quality assessment. Not all feeds are equal. Evaluate each TI source on: false positive rate (what percentage of indicators are inaccurate?), timeliness (how quickly do indicators appear after threat discovery?), relevance (does the feed cover threats relevant to your environment?), and overlap (does it duplicate indicators from other feeds?). A feed with a 20% false positive rate degrades your detection quality — remove it.

Volume management. Sentinel supports millions of indicators. However, TI-matching rules that join large indicator tables with large security tables are computationally expensive. If the indicator table exceeds 100,000 active entries, monitor analytics rule execution time. Filter TI-matching rules to high-confidence indicators (ConfidenceScore ≥ 60) to reduce join size without losing high-value matches.

Deduplication. Multiple feeds may report the same indicator. Sentinel handles deduplication — multiple entries for the same value do not generate duplicate alerts. However, periodically audit indicator count per source to identify excessive overlap.

Incident-driven indicator creation. During incident response, IOCs discovered through investigation should be added as indicators for future detection. Found a C2 IP in your investigation? Add it as an indicator so that if the same IP appears in any other data source, an alert fires immediately. This closes the loop between investigation and detection.

The TI operationalisation workflow

For TI to deliver value, it must be more than a passive database. The operationalisation workflow connects TI ingestion to detection, investigation, and continuous improvement.

Phase 1: Ingest. Connect your TI sources (MDTI, STIX/TAXII feeds, TIP, manual entry). Validate ingestion by querying the ThreatIntelligenceIndicator table. Verify that indicators are appearing with correct metadata (type, confidence, expiration).

Phase 2: Detect. Enable TI-matching analytics rules for every indicator type against every relevant data table. The standard deployment: IP indicators matched against SigninLogs, AzureActivity, DeviceNetworkEvents, CommonSecurityLog. Domain indicators matched against DeviceNetworkEvents, DnsEvents. File hash indicators matched against DeviceFileEvents, DeviceProcessEvents. URL indicators matched against UrlClickEvents, EmailUrlInfo.

Phase 3: Triage. When a TI match fires, the analyst triages by assessing: the indicator confidence (high confidence = likely threat, low confidence = needs validation), the indicator source (MDTI match is more reliable than community feed match), the indicator age (a fresh indicator is more likely current than one 6 months old), and the context (a C2 IP matched on a sign-in is more concerning than a scanning IP matched on a firewall reject).

Phase 4: Feedback. After triage, the analyst feeds results back into the TI lifecycle. True positive? Extend the indicator’s expiration and increase confidence. False positive? Mark the indicator for review or delete it. New IOCs discovered? Add them as indicators. This feedback loop improves TI quality over time.

Phase 5: Hunt. Proactively search historical data for newly published indicators. When a TI vendor publishes a new set of IOCs for a campaign, retroactively check whether any of those IOCs appeared in your data before the publication. This catches “dwell time” — threats that were active in your environment before anyone knew about them.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// Retroactive hunt: check if any TI indicators added this week
// appeared in sign-in data over the past 90 days
let NewIndicators = ThreatIntelligenceIndicator
| where TimeGenerated > ago(7d)
| where Active == true and IndicatorType == "ipv4-addr"
| distinct NetworkIP;
SigninLogs
| where TimeGenerated > ago(90d)
| where IPAddress in (NewIndicators)
| summarize EarliestSignIn = min(TimeGenerated),
    LatestSignIn = max(TimeGenerated),
    SignInCount = count(),
    Users = make_set(UserPrincipalName)
    by IPAddress
| extend DwellDays = datetime_diff('day', LatestSignIn, EarliestSignIn)

This retroactive hunt query is one of the highest-value hunting queries in a Sentinel workspace — it finds threats that bypassed your detection at the time because the indicator was not yet known. If the query returns results, each match requires full investigation: which users signed in from this IP, what did they do after authentication, and was any data accessed or exfiltrated?

Integrating TI with the investigation workflow

Beyond automated detection, TI enhances manual investigation through entity enrichment. During an investigation, when you identify an IP address, domain, or file hash, check it against TI before continuing the investigation.

KQL pattern for on-demand TI lookup:

1
2
3
4
5
6
7
8

// Entity enrichment: check if investigation IP has TI match
let InvestigationIP = "203.0.113.47";
ThreatIntelligenceIndicator
| where Active == true
| where NetworkIP == InvestigationIP
| project ThreatType, ConfidenceScore, Description,
    Source = SourceSystem, ValidFrom = ValidFrom,
    Expiration = ExpirationDateTime

If the IP has a TI match, the metadata (threat type, associated campaign, threat actor) provides immediate investigative context. An IP matched to “APT29 infrastructure” drives a very different investigation than an IP with no TI match. The TI context informs the investigation scope, the response urgency, and the escalation path.

Knowledge check