Advanced Threat Intelligence & Hunting with Microsoft Defender and Sentinel

Modern adversaries move quickly, reuse infrastructure aggressively, and rely on one key assumption: defenders will only react after damage is done. Microsoft Sentinel integrated with Microsoft Defender Threat Intelligence (TI) flips that assumption on its head.

By operationalizing Microsoft-curated, high-fidelity threat intelligence directly inside Sentinel, security teams can shift from alert-driven response to continuous, intelligence-led threat hunting. Instead of treating threat intelligence as a static list of indicators, Sentinel enables defenders to correlate adversary infrastructure with real telemetry—network traffic, sign-in activity, and endpoint events—in near real time.

This guide walks through how to enable Defender TI feeds in Sentinel, validate and understand the indicator schema, and apply production-ready KQL hunting patterns. Beyond detection, it covers expiration-aware logic, confidence-based prioritization, and tiered automation strategies that scale in mature SOC environments.

The outcome is a repeatable, defensible approach to using threat intelligence as an operational asset. When Defender TI provides adversary context and Sentinel provides data gravity, hunters gain earlier visibility, clearer signal, and higher confidence—often before traditional analytics ever fire.

In this bonus post, I wanted to share that TI or Threat Intelligence can be used by anyone in Sentinel, and that there are ways to utilize it in real-time to take your detections into the next-level! TI can really elevate a SOC Team’s effectiveness by finding those threats that are hiding in your data!

Let’s dive in!

1. Enabling Microsoft Defender Threat Intelligence in Sentinel

Step 1: Connect the Threat Intelligence Data Source

• In the Sentinel portal, go to Content management → Data connectors.
• Select Threat Intelligence – Microsoft Defender TI.
• Click Connect to begin ingesting curated Microsoft TI indicators into Sentinel.

Step 2: Validate Indicator Ingestion

Use KQL to confirm indicators are flowing:

ThreatIntelligenceIndicator

| summarize Count = count() by SourceSystem

You should see Microsoft-sourced indicators populating regularly.

Step 3: Understand the Indicator Schema

Key fields include:

• IndicatorType
• NetworkIP
• DomainName
• Url
• ConfidenceScore
• ValidFrom, ValidUntil
• ThreatType
• Active

These fields are critical for filtering out expired or low-confidence indicators.

2. Threat Hunting with Defender TI Feeds

Why Hunt with Threat Intelligence?

• Analytics rules detect what you expect.
• Threat hunting finds what attackers hope you never notice.
• TI hunting allows you to detect known malicious infrastructure, identify lateral movement, and correlate low-signal events into high-confidence findings.

Core Threat Hunting Pattern

1. Filter active TI indicators.
2. Join against relevant telemetry tables.
3. Apply time and confidence constraints.
4. Investigate matches contextually.

3. Step-by-Step: KQL Threat Hunting Scenarios

Scenario 1: High-Confidence Malicious IP Activity

let TIIPs = ThreatIntelligenceIndicator

    | where Active == true

    | where ValidUntil > now()

    | where isnotempty(NetworkIP)

    | where ConfidenceScore >= 80

    | project NetworkIP, ThreatType, Description;

DeviceNetworkEvents

    | join kind=inner (TIIPs) on $left.RemoteIP == $right.NetworkIP

    | project Timestamp, DeviceName, RemoteIP, ThreatType, Description

What this does: Filters to active, high-confidence indicators, matches against device network activity, and produces investigation-ready output.

*Note: Not all indicators populate every field. Always filter with isnotempty() and validate indicator freshness before joining with telemetry.

Scenario 2: Threat Intelligence Domain Hunting

let TIDomains = ThreatIntelligenceIndicator

    | where Active == true

    | where ValidUntil > now()

    | where isnotempty(DomainName);

DeviceNetworkEvents

    | where isnotempty(RemoteUrl)

    | join kind=inner (TIDomains) on $left.RemoteUrl contains $right.DomainName

Use case: Detects command-and-control callbacks, phishing infrastructure, and malware staging servers.

Scenario 3: Sign-in Events Correlated with TI IPs

Use case: Correlates sign-in attempts with known malicious IPs for rapid detection of compromised accounts.

4. Advanced Threat Intelligence Hunting Techniques

1. Expiration-Aware Hunting

Always respect indicator freshness:

| where ValidUntil > now()

Expired indicators increase false positives and SOC fatigue.

2. Confidence-Weighted Detection Logic

• Use ConfidenceScore to prioritize alerts.
• Apply higher confidence requirements for automation, lower for hunting dashboards.

3. Multi-Table Correlation

Correlate across:

• DeviceNetworkEvents
• SigninLogs
• EmailUrlInfo
• CommonSecurityLog

This exposes multi-stage attacks that single telemetry misses.

4. Tiered Automation Strategy

This approach balances detection speed with analyst trust.

5. Custom TI Enrichment Functions

Create reusable KQL functions to:

• Normalize TI fields.
• De-duplicate indicators.
• Apply environment-specific allowlists.

5. Example: Analytics Rule Outline

Name: High-Confidence Threat Intelligence Network Match Data Sources:

• ThreatIntelligenceIndicator
• DeviceNetworkEvents Logic:
• Match active, non-expired TI indicators (ConfidenceScore >= 80)
• Join with network telemetry
• Suppress known benign IPs Entity Mapping:
• IP Address → RemoteIP
• Host → DeviceName Severity: High Tactics: Command and Control, Initial Access Automation: Auto-create incident, Notify SOC Tier 2

6. Threat Intelligence Workflow Overview

1. Ingest Microsoft Defender TI feeds into Sentinel.
2. Validate indicator flow and schema.
3. Hunt using KQL to join TI with telemetry.
4. Automate high-confidence matches.
5. Investigate and enrich incidents with TI context.

A Couple of Analytics Rules to Deploy

Now, you will need to make some minor changes to tune this for your environment, but here are a couple of analytics rules using threat intelligence to help detect threats in your data:

1)

Purpose
Detect endpoint network connections to active, high-confidence malicious IPs from Microsoft Defender Threat Intelligence.

{
  "kind": "Scheduled",
  "properties": {
    "displayName": "High-Confidence Threat Intelligence IP Match (Endpoint Network)",
    "description": "Detects endpoint network activity communicating with active, non-expired, high-confidence Microsoft Defender Threat Intelligence IP indicators.",
    "severity": "High",
    "enabled": true,
    "queryFrequency": "PT5M",
    "queryPeriod": "PT1H",
    "query": "let TIIPs = ThreatIntelligenceIndicator\n| where Active == true\n| where ValidUntil > now()\n| where isnotempty(NetworkIP)\n| where ConfidenceScore >= 80\n| project NetworkIP, ThreatType, Description;\nDeviceNetworkEvents\n| where Timestamp >= ago(1h)\n| join kind=inner (TIIPs) on $left.RemoteIP == $right.NetworkIP\n| project Timestamp, DeviceName, RemoteIP, ThreatType, Description",
    "suppressionDuration": "PT1H",
    "suppressionEnabled": false,
    "triggerOperator": "GreaterThan",
    "triggerThreshold": 0,
    "tactics": [
      "CommandAndControl",
      "InitialAccess"
    ],
    "techniques": [
      "T1071",
      "T1095"
    ],
    "entityMappings": [
      {
        "entityType": "IP",
        "fieldMappings": [
          {
            "identifier": "Address",
            "columnName": "RemoteIP"
          }
        ]
      },
      {
        "entityType": "Host",
        "fieldMappings": [
          {
            "identifier": "HostName",
            "columnName": "DeviceName"
          }
        ]
      }
    ],
    "incidentConfiguration": {
      "createIncident": true,
      "groupingConfiguration": {
        "enabled": true,
        "reopenClosedIncident": false,
        "lookbackDuration": "PT1H",
        "matchingMethod": "Selected",
        "groupByEntities": [
          "IP",
          "Host"
        ]
      }
    },
    "eventGroupingSettings": {
      "aggregationKind": "AlertPerResult"
    }
  }
}

2)

Purpose
Detects authentication attempts from known malicious IP infrastructure, often an early signal of credential compromise or password spray activity.

When to use

• Identity-focused SOCs
• Medium-to-high confidence automation
• Excellent early-warning rule

{
  "kind": "Scheduled",
  "properties": {
    "displayName": "Threat Intelligence IP Match on Azure AD Sign-in",
    "description": "Correlates Azure AD sign-in events with active, non-expired Microsoft Defender Threat Intelligence IP indicators.",
    "severity": "High",
    "enabled": true,
    "queryFrequency": "PT5M",
    "queryPeriod": "PT1H",
    "query": "let TIIPs = ThreatIntelligenceIndicator\n| where Active == true\n| where ValidUntil > now()\n| where isnotempty(NetworkIP)\n| project NetworkIP, ThreatType;\nSigninLogs\n| where TimeGenerated >= ago(1h)\n| join kind=inner (TIIPs) on $left.IPAddress == $right.NetworkIP\n| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ThreatType",
    "suppressionDuration": "PT1H",
    "suppressionEnabled": false,
    "triggerOperator": "GreaterThan",
    "triggerThreshold": 0,
    "tactics": [
      "CredentialAccess",
      "InitialAccess"
    ],
    "techniques": [
      "T1110",
      "T1078"
    ],
    "entityMappings": [
      {
        "entityType": "IP",
        "fieldMappings": [
          {
            "identifier": "Address",
            "columnName": "IPAddress"
          }
        ]
      },
      {
        "entityType": "Account",
        "fieldMappings": [
          {
            "identifier": "Name",
            "columnName": "UserPrincipalName"
          }
        ]
      }
    ],
    "incidentConfiguration": {
      "createIncident": true,
      "groupingConfiguration": {
        "enabled": true,
        "reopenClosedIncident": false,
        "lookbackDuration": "PT1H",
        "matchingMethod": "Selected",
        "groupByEntities": [
          "IP",
          "Account"
        ]
      }
    },
    "eventGroupingSettings": {
      "aggregationKind": "AlertPerResult"
    }
  }
}

Deployment Notes (Important)

• These rules assume:
  • Defender TI connector is enabled
  • Microsoft Defender for Endpoint and/or Azure AD logs are flowing
• Adjust ConfidenceScore thresholds if your SOC prefers broader visibility
• Consider adding allowlists (proxy IPs, VPN egress) before automation
• Cost-aware environments may reduce queryPeriod to 30 minutes

Closing Thoughts

Threat Intelligence transforms Sentinel from a reactive SIEM into a proactive hunting platform. By integrating Defender TI feeds, validating indicator quality, and applying structured hunting queries, security teams gain early visibility into adversary activity that traditional alerts often miss.

Threat Intelligence gives you the map. Sentinel gives you the flashlight. Hunting is knowing where—and when—to look.