8.3 Connecting Microsoft Defender XDR

Connecting Microsoft Defender XDR

Introduction

The Defender XDR connector is the most important single connector for M365 security operations. It ingests all Defender product data — alerts, incidents, and the Advanced Hunting tables that power endpoint, email, identity, and cloud app investigation — into the Sentinel workspace. Module 7.9 introduced the integration architecture. This subsection covers the connector configuration in detail.

What the connector ingests

The Defender XDR connector operates at two levels.

Level 1: Incidents and alerts. All incidents and alerts from Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps are synchronised to the Sentinel SecurityAlert and SecurityIncident tables. Bi-directional sync means status changes, severity changes, and assignments propagate between portals.

Level 2: Advanced Hunting raw data tables. The connector can also ingest the raw event data that Defender collects — the Device*, Email*, Identity*, and CloudApp* tables you queried in Modules 1-5. These are the same tables available in Defender XDR Advanced Hunting, now queryable in Sentinel alongside your other workspace data.

You can selectively enable which Advanced Hunting tables to ingest. This is an important cost and coverage decision.

Configuration steps

Step 1: Install the Defender XDR Content Hub solution. Navigate to Sentinel → Content Hub → search “Microsoft Defender XDR” → Install. This deploys the connector plus analytics rule templates and hunting queries.

Step 2: Open the connector page. Sentinel → Data connectors → Microsoft Defender XDR → Open connector page.

Step 3: Enable incident sync. Under “Connect incidents & alerts,” toggle the connection to On. This enables bi-directional incident synchronisation — incidents from Defender XDR appear in Sentinel, and status changes sync between portals.

Step 4: Select Advanced Hunting tables. Under “Connect events,” select the tables you want to ingest. Use the recommendation table above as a starting point. Each table can be toggled independently.

Step 5: Verify. Wait 5-10 minutes, then verify data flow:

1
2
3
4
5
6

// Verify Defender XDR incidents are syncing
SecurityIncident
| where TimeGenerated > ago(24h)
| where ProviderName == "Microsoft 365 Defender"
| summarize Count = count() by Severity
| order by Count desc

1
2
3
4
5
6
7

// Verify Advanced Hunting tables are ingesting
union withsource=TableName
    DeviceProcessEvents,
    EmailEvents,
    CloudAppEvents
| where TimeGenerated > ago(1h)
| summarize EventCount = count(), LastEvent = max(TimeGenerated) by TableName

Understanding table volumes and cost impact

Each Advanced Hunting table generates different volumes depending on environment activity. Understanding these volumes helps you make informed table selection decisions.

High-volume tables (5-20 GB/day in a 5,000-user environment):

DeviceNetworkEvents — every outbound connection from every managed device. This is typically the highest-volume Defender XDR table because modern endpoints make hundreds of network connections per hour.

DeviceProcessEvents — every process creation on managed devices. Volume scales with endpoint count and user activity. Busy servers generate far more process events than idle workstations.

DeviceFileEvents — file creation, modification, and deletion. High volume on file servers and developer workstations.

Medium-volume tables (1-5 GB/day):

EmailEvents — one row per email delivery attempt. Volume depends on email traffic.

CloudAppEvents — SaaS application activity. Volume depends on user activity in Exchange, SharePoint, Teams.

DeviceLogonEvents — device logon/logoff events. Moderate volume.

Low-volume tables (< 1 GB/day):

UrlClickEvents — only records when users click Safe Links-protected URLs.

EmailAttachmentInfo, EmailUrlInfo — one row per attachment or URL, not per email.

IdentityLogonEvents — on-premises AD logons (requires Defender for Identity).

Cost estimation workflow: Enable all recommended tables. After 7 days, run the volume assessment:

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

// Defender XDR table volume assessment — run after 7 days
union withsource=TableName
    DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents,
    DeviceLogonEvents, EmailEvents, EmailAttachmentInfo,
    EmailUrlInfo, UrlClickEvents, CloudAppEvents, IdentityLogonEvents
| where TimeGenerated > ago(7d)
| summarize
    WeeklyGB = count() * 0.001 / 1024,  // Approximate GB
    DailyAvgEvents = count() / 7
    by TableName
| extend EstMonthlyCost = WeeklyGB / 7 * 30 * 5.22  // Approx PAYG
| order by WeeklyGB desc

If a table’s monthly cost exceeds its investigation value, consider disabling it and querying the data directly in the Defender portal’s Advanced Hunting when needed.

Configuration walkthrough: step by step with verification

Step 1: Install the Defender XDR Content Hub solution. Navigate to Sentinel → Content Hub → search “Microsoft Defender XDR” → Install. This deploys the connector plus analytics rule templates and hunting queries. Wait for installation to complete (1-2 minutes).

Step 2: Open the connector page. Sentinel → Data connectors → Microsoft Defender XDR → Open connector page. The connector page has two sections: “Connect incidents & alerts” and “Connect events.”

Step 3: Enable incident sync. Under “Connect incidents & alerts,” toggle the connection to On. This activates bi-directional synchronisation. A confirmation message appears: “Connected successfully.”

Step 4: Disable redundant incident creation rules. Before proceeding, check Sentinel → Analytics → Active rules. If you have “Microsoft Security” rules that create incidents from Defender product alerts (e.g., “Create incidents based on Microsoft Defender for Endpoint alerts”), disable them now. With bi-directional sync enabled, these rules create duplicate incidents.

Step 5: Select Advanced Hunting tables. Under “Connect events,” you see a list of all available Defender XDR tables with toggles. Use the recommendation table earlier in this subsection as your guide. Enable each recommended table. Each toggle takes effect within seconds.

Step 6: Verify incident sync. If active incidents exist in Defender XDR:

1
2
3
4
5
6

// Verify incidents are syncing from Defender XDR
SecurityIncident
| where TimeGenerated > ago(24h)
| where ProviderName has "Microsoft 365 Defender"
| summarize Count = count() by Status, Severity
| order by Count desc

If this returns results, incident sync is working. If no results after 30 minutes and Defender XDR has active incidents, check: is the connector status “Connected”? Is bi-directional sync toggled On?

Step 7: Verify table ingestion. Wait 10-15 minutes for Advanced Hunting tables to begin populating:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Comprehensive verification: all enabled Defender XDR tables
union withsource=TableName
    DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents,
    DeviceLogonEvents, EmailEvents, EmailAttachmentInfo,
    EmailUrlInfo, UrlClickEvents, CloudAppEvents, IdentityLogonEvents
| where TimeGenerated > ago(4h)
| summarize EventCount = count(), LastEvent = max(TimeGenerated) by TableName
| extend MinutesSinceLastEvent = datetime_diff('minute', now(), LastEvent)
| extend Status = iff(MinutesSinceLastEvent > 120, "⚠️ CHECK", "✓ OK")
| order by MinutesSinceLastEvent desc

Tables with “CHECK” status may not be ingesting. Verify: is the table toggle enabled in the connector page? Does the Defender product that populates the table have active data? (EmailEvents requires Defender for Office 365 with email flowing. DeviceProcessEvents requires onboarded endpoints with MDE.)

Incident sync deep dive: how bi-directional works

Defender → Sentinel: When Defender XDR creates an incident (from alert correlation), a corresponding incident is created in the Sentinel incident queue within minutes. The Sentinel incident includes: the same title, description, severity, and alert list. The incident is tagged with the provider “Microsoft 365 Defender.”

Sentinel → Defender: When a Sentinel analyst changes the incident (assigns it, changes severity, closes it, adds a comment), the change is pushed back to Defender XDR. The sync is not instant — changes typically propagate within 5-10 minutes.

What syncs: Status (New/Active/Closed), severity, assignment, classification (True Positive/False Positive/Benign Positive), and determination reason. Comments added in Sentinel appear in Defender XDR.

What does NOT sync: Custom tags added in Sentinel do not sync to Defender XDR. Automation rule actions taken in Sentinel (adding tags, running playbooks) do not propagate. Entities and evidence are synced at incident creation but additional evidence gathered during investigation may not sync bidirectionally.

Conflict resolution: If an analyst changes the incident in Defender XDR and a different analyst changes the same incident in Sentinel simultaneously, the last write wins. In practice, establish a clear operational policy: one portal is the primary investigation interface. The unified Defender portal (Module 7.9) eliminates this issue by providing a single interface.

Managing table selection over time

Your initial table selection is not permanent. As your analytics rule library grows (Module 9), you may need to enable additional tables. As you optimise costs (Module 8.10), you may disable tables with low detection value.

When to enable a new table: You are creating an analytics rule or hunting query that references a Defender XDR table you have not ingested. Example: building a DLL sideloading detection rule that queries DeviceImageLoadEvents — currently not ingested. Enable the table, wait for data to populate, then deploy the rule.

When to disable a table: Quarterly, review table usage: which tables are actually queried by active analytics rules and hunting queries? Which tables have zero rule hits in 90 days?

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

// Identify unused Defender XDR tables
let XDRTables = datatable(TableName:string) [
    "DeviceProcessEvents", "DeviceNetworkEvents", "DeviceFileEvents",
    "DeviceLogonEvents", "DeviceImageLoadEvents", "DeviceRegistryEvents",
    "EmailEvents", "EmailAttachmentInfo", "EmailUrlInfo", "UrlClickEvents",
    "CloudAppEvents", "IdentityLogonEvents", "IdentityQueryEvents"
];
let QueriedTables = SecurityAlert
| where TimeGenerated > ago(90d)
| extend TablesQueried = extract_all(@"(\w+Events|\w+Info|\w+Logs)", tostring(ExtendedProperties))
| mv-expand TablesQueried to typeof(string)
| distinct TablesQueried;
XDRTables
| join kind=leftanti (QueriedTables | project TableName = TablesQueried) on TableName
| project TableName, Recommendation = "Consider disabling — no rule has queried this table in 90 days"

Disable unused tables to reduce ingestion volume and cost. The data remains queryable in the Defender portal’s Advanced Hunting — you are not losing the capability, just the Sentinel copy.

Verifying the XDR tier cost benefit

The XDR tier should reduce your effective Sentinel ingestion cost for Defender data. Verify the benefit is being applied:

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

// Check which Defender XDR tables are billable vs XDR-tier
Usage
| where TimeGenerated > ago(30d)
| where DataType in (
    "DeviceProcessEvents", "DeviceNetworkEvents", "DeviceFileEvents",
    "DeviceLogonEvents", "EmailEvents", "CloudAppEvents",
    "SecurityAlert", "SecurityIncident")
| summarize
    TotalGB = sum(Quantity) / 1024,
    BillableGB = sumif(Quantity, IsBillable == true) / 1024,
    FreeGB = sumif(Quantity, IsBillable == false) / 1024
    by DataType
| extend XDRTierApplied = iff(FreeGB > 0, "✓ Yes", "✗ No")
| order by TotalGB desc

If the XDR tier is not being applied (all data shows as billable), check: is your Defender XDR licence an eligible SKU (M365 E5, E5 Security, or standalone Defender XDR)? Is the connector configured through the unified platform (not a legacy configuration)? Check the current Microsoft documentation for eligibility criteria.

SC-200 exam scenarios for the Defender XDR connector

The exam frequently tests these decision points.

Scenario: “You enabled the Defender XDR connector but incidents are not appearing in Sentinel.” Answer: bi-directional sync is not enabled. Open the connector page and toggle incident sync to On.

Scenario: “After enabling the connector, you see duplicate incidents for the same alert.” Answer: Microsoft Security incident creation rules are still active alongside bi-directional sync. Disable the analytics rules that create incidents from Defender product alerts.

Scenario: “Your Sentinel cost is too high. 60% of ingestion is from Defender XDR tables.” Answer: review which Advanced Hunting tables are enabled. Disable high-volume tables with low detection value (DeviceNetworkInfo, DeviceInfo, DeviceFileCertificateInfo). Verify the XDR tier is being applied — if eligible data is being billed, fix the configuration.

Advanced Hunting in the unified platform: Sentinel tables meet Defender tables

With the Defender XDR connector enabled and the unified security operations platform configured (Module 7.9), the Defender portal’s Advanced Hunting provides access to both Defender XDR tables AND Sentinel workspace tables in a single query interface.

This means you can write queries that join Defender endpoint data with Sentinel Syslog data, or correlate Defender email events with custom application logs from a custom table. The unified query surface eliminates the need to run separate queries in separate portals and mentally correlate the results.

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

// Unified query: correlate Defender endpoint C2 detection with firewall data
// (requires both Defender XDR and CEF connectors)
let SuspiciousOutbound = DeviceNetworkEvents
| where Timestamp > ago(1h)
| where RemotePort !in (80, 443, 53)
| where ActionType == "ConnectionSuccess"
| where not(ipv4_is_private(RemoteIP))
| project Timestamp, DeviceName, RemoteIP, RemotePort,
    InitiatingProcessFileName;
CommonSecurityLog
| where TimeGenerated > ago(1h)
| where SourceIP in (SuspiciousOutbound | project RemoteIP)
    or DestinationIP in (SuspiciousOutbound | project RemoteIP)
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort,
    DeviceAction, DeviceVendor

This query finds unusual outbound connections from Defender-managed endpoints and then checks whether the same IPs appear in firewall logs — correlating endpoint and network data in one investigation step.

The XDR data tier and cost implications

Data ingested through the Defender XDR connector may qualify for the XDR tier — meaning it does not incur additional Sentinel ingestion charges. This applies to data that Microsoft considers included with the Defender XDR licence.

The practical impact: in an M365 E5 environment, a significant portion of your Sentinel data (all Defender product tables) may be cost-free at the Sentinel level. This dramatically changes the cost calculation from Module 7.5 — recalculate your expected monthly cost after applying the XDR tier benefit.

Check the current Microsoft documentation for the definitive list of tables eligible for the XDR tier — it evolves as the integration matures.

Bi-directional sync operational considerations

Incident ownership clarity. When bi-directional sync is enabled, the same incident exists in both portals. Establish which portal is the primary investigation interface (Module 7.9 recommends the Defender portal for investigation). If two analysts work the same incident in different portals simultaneously, conflicting status changes create confusion.

Alert grouping differences. Defender XDR groups alerts into incidents using its own correlation engine. Sentinel groups alerts using analytics rule configuration. When both systems create incidents from the same underlying alerts, you may see duplicate incidents. To avoid this: let Defender XDR handle correlation for its own alerts (through bi-directional sync), and use Sentinel analytics rules only for data sources that Defender XDR does not cover (Syslog, CEF, custom logs).

Turning off Microsoft Security incident creation rules. After enabling bi-directional sync, disable any Sentinel “Microsoft Security” analytics rules that create incidents from Defender product alerts. These rules are redundant when sync is enabled — they create duplicate incidents for the same alerts.

Knowledge check