Tool Stack Integration

Tools serve functions, not the other way around

The Microsoft security stack provides three platforms that SOC analysts use daily: Microsoft Sentinel (SIEM — log aggregation, detection rules, incident management), Microsoft Defender XDR (extended detection and response — cross-product correlation, entity pages, Advanced Hunting), and Microsoft Entra ID (identity provider — authentication logs, conditional access, user/group management). Each platform serves distinct SOC functions. Knowing which tool to use for which function eliminates the context-switching that slows investigation.

The Vectra AI 2026 State of Threat Detection report found that 69% of organizations use more than 10 detection and response tools, and 39% use more than 20. Tool sprawl — too many tools, too much context-switching, too little integration — is a recognized drag on SOC efficiency. The Microsoft stack's advantage is that Sentinel, Defender XDR, and Entra ID share a common data model and query language (KQL). An analyst who masters KQL can query identity data, endpoint data, email data, and cloud application data from a single query workspace. This cross-domain capability is what makes the detection rules in Modules 3-6 possible.

Estimated time: 40 minutes.

Sentinel — detection and queue management

Sentinel is the SIEM — the platform where detection rules run, alerts generate incidents, and the incident queue lives. L1 triage starts in Sentinel because that's where the incident queue is managed.

Analytics rules

Sentinel's analytics rules are the detection engine. Scheduled rules run KQL queries at defined intervals — every 5 minutes for near-real-time detection, every hour for lower-priority patterns, every 24 hours for trend analysis. When the query returns results, Sentinel creates an incident with severity, entity mapping, and alert details.

Sentinel supports four rule types, each serving a different detection purpose. Scheduled rules are the primary detection mechanism — a KQL query runs on a cadence and creates incidents when results are returned. Near-real-time (NRT) rules run every minute with minimal delay, designed for high-priority detections where even a 5-minute delay is unacceptable (active ransomware indicators, critical credential compromise patterns). Fusion rules use machine learning to correlate alerts across data sources — Sentinel's built-in multi-stage attack detection. Microsoft security incident creation rules automatically import alerts from other Defender products into the Sentinel incident queue.

The detection rules this course builds in Modules 3-6 are primarily scheduled rules with specific KQL queries. Each rule includes the query, the schedule (how often it runs), the lookback window (how far back it queries), entity mappings (which fields map to user, IP, device, and hostname entities), and incident configuration (severity, grouping, automated response triggers). NRT rules are reserved for the highest-priority detections where sub-minute detection latency matters.

Incident management

Sentinel's incident management is the SOC's work queue. Each incident has a severity, a status (New, Active, Closed), an owner, and a classification (True Positive, Benign Positive, False Positive). The classification field is the data source for the quality metrics from Section 1.6 — every disposition the L1 analyst selects feeds the false positive rate, classification accuracy, and undetermined rate calculations.

Sentinel also supports incident comments — where the escalation format (trigger, entity, evidence, question) is recorded, where investigation findings are documented, and where the handover state is captured. The incident comment thread becomes the investigation record that enables L2 quality review and post-incident analysis.

Watchlists and UEBA

Two Sentinel features directly support the triage framework. Watchlists store reference data — VPN exit IPs, service accounts, VIP users, known-good applications — that the L1 analyst checks during the "known sources" step of triage. Rather than maintaining these lists in spreadsheets, watchlists are queryable via KQL: _GetWatchlist('VPN_ExitIPs') | where IPAddress == AlertIP. Detection rules can reference watchlists to auto-exclude known-good entities, reducing false positive volume at the detection layer rather than the triage layer.

User and Entity Behavior Analytics (UEBA) builds behavioral baselines for users and entities, flagging deviations that might indicate compromise. UEBA doesn't generate incidents directly — it provides risk scores and anomaly indicators that enrich L1 triage and L2 investigation. A user with a UEBA risk score of 85 who triggers a medium-severity alert gets more investigative attention than the same alert on a user with a risk score of 12. UEBA context is visible in Sentinel entity pages and in Defender XDR entity pages.

Automation (SOAR)

Sentinel's automation rules and Logic Apps provide the SOAR capability. When an incident is created, automation can enrich it (pre-populate entity context, run VirusTotal lookups, check watchlists), notify (send Teams message to the SOC channel, page the on-call analyst for Severity 1), or contain (disable a user account, block an IP). Module 10 builds the automation playbooks that the operational foundation supports.

Defender XDR — investigation platform

Defender XDR is where investigation happens. While Sentinel manages the detection and queue, Defender XDR provides the investigation tools that L2 analysts use to scope incidents and determine blast radius.

Unified incidents

Defender XDR correlates alerts from multiple products — Defender for Endpoint, Defender for Office 365, Defender for Cloud Apps, Defender for Identity — into unified incidents. An alert from email detection and an alert from identity detection that share the same user entity are automatically correlated into a single incident timeline. This means the L2 analyst investigating a credential compromise sees the suspicious sign-in, the inbox rule creation, and the mailbox access in one view — not three separate alerts they need to manually correlate.

This cross-product correlation is the primary reason L2 investigation should happen in Defender XDR rather than Sentinel. Sentinel's incidents are based on individual analytics rules. Defender XDR's incidents are based on entity correlation across products. For multi-phase attacks — which is what sophisticated attackers execute — the correlated view shows the full attack chain while Sentinel's view shows individual phases.

Entity pages

Defender XDR's entity pages provide the context that the triage framework's enrichment steps require. The user entity page shows: sign-in history, device associations, group memberships, risk score, related alerts, and timeline of all security-relevant activities. The device entity page shows: installed software, vulnerabilities, security configurations, alert history, and process timeline.

L1 analysts use entity pages for triage enrichment — checking user sign-in history, verifying device compliance, and reviewing related alerts. L2 analysts use them for investigation scoping — tracing every action an entity took during the compromise window.

Advanced Hunting

Advanced Hunting is the KQL query workspace in Defender XDR. It provides access to the same data tables that Sentinel analytics rules query — SigninLogs, OfficeActivity, DeviceProcessEvents, EmailEvents, CloudAppEvents — but in an interactive environment designed for investigation rather than automated detection.

The investigation KQL queries that L2 analysts run during incident scoping use Advanced Hunting. "Show me every sign-in for this user in the last 7 days, with MFA method details, IP addresses, and device information" is an Advanced Hunting query. "Show me every inbox rule created in the last 48 hours across the entire organization" is an Advanced Hunting query. These are the enrichment and investigation queries that the triage and escalation frameworks reference.

A worked example: investigation flow through the tools

When a credential compromise alert fires at NE, the investigation flows through all three platforms in a specific sequence. The L1 analyst starts in Sentinel — reads the incident details, checks the entity against watchlists, runs the triage enrichment. If the alert doesn't resolve at L1, they escalate with the structured format.

The L2 analyst picks up in Defender XDR. They open the correlated incident view — which may show the credential alert alongside an inbox rule alert and a MailItemsAccessed anomaly on the same user, automatically correlated. They check the user entity page for sign-in timeline, device associations, and UEBA risk score. They run Advanced Hunting queries to trace the session: "What happened after this sign-in? Did the user access any mailboxes? Were any rules created? Were any emails sent?"

If the investigation confirms compromise, containment executes in Entra ID: disable the account, revoke sessions, reset credentials. The SOC lead approves containment (or the automation playbook executes pre-approved containment for specific incident types). The analyst documents findings in the Sentinel incident comments — closing the loop back to the incident queue where metrics are tracked.

This flow — Sentinel for detection and queue, Defender XDR for investigation, Entra ID for containment, Sentinel for documentation — is the standard investigation path. Every analyst should know it by muscle memory. The investigation doesn't start in Defender XDR (no queue management) and it doesn't end in Entra ID (no incident documentation for metrics). Each tool handles its phase of the workflow.

Entra ID — identity context and containment

Entra ID provides the identity layer — the authentication logs, conditional access policies, and user management that inform identity investigations and enable identity-based containment.

Sign-in context

The sign-in logs in Entra ID provide the deepest authentication context available. The MFA method check from the triage framework (Section 1.5) — distinguishing interactive MFA from token-claim MFA — requires the AuthenticationDetails field in SigninLogs. The conditional access evaluation — which policies applied to the sign-in and whether any were bypassed — comes from the ConditionalAccessPolicies field.

For AiTM investigations specifically, the sign-in log reveals whether the MFA claim was satisfied interactively or inherited from a previous session. This distinction — invisible in the alert, visible in the sign-in log detail — is the difference between a legitimate authentication and a stolen token.

Containment actions

When investigation confirms a compromise, Entra ID is where containment actions execute. Disable the user account. Revoke all refresh tokens (forcing re-authentication). Reset the password. Reset MFA registrations. These containment actions stop active compromise immediately. The SOC lead or L2 analyst with appropriate permissions executes them directly in Entra ID — or through a Sentinel automation playbook that triggers the action via Logic Apps.

The containment sequence matters. Revoking tokens without disabling the account allows the attacker to re-authenticate if they still have the password or a valid phishing session. Disabling the account without revoking tokens allows active sessions to continue until the token expires (up to 1 hour for access tokens). The correct sequence for confirmed credential compromise: disable account → revoke all sessions → reset password → reset MFA registrations → re-enable account only after the user verifies identity through an out-of-band channel.

Conditional Access as a detection input

Conditional Access policies in Entra ID provide detection-relevant signals that many SOCs overlook. When a sign-in bypasses a Conditional Access policy — because the policy has an exclusion, or because the authentication method satisfies the policy despite being suspicious — that bypass is logged. The ConditionalAccessPolicies field in SigninLogs shows which policies were evaluated, which were applied, and which were not applied along with the reason.

For AiTM detection specifically, the Conditional Access evaluation reveals whether the sign-in's MFA satisfaction came from an interactive prompt (the user physically completed MFA) or from a token claim (the MFA assertion was inherited from a captured session). Sentinel analytics rules can query this field to detect sign-ins where MFA was "satisfied" but the satisfaction method indicates token replay rather than interactive authentication. This is one of the cross-domain detection patterns that Modules 3-6 build.

The data flow

Understanding the data flow — where data originates, where it's stored, and which tool queries it — prevents the common confusion of querying the wrong platform for the wrong data.

Identity data originates in Entra ID (sign-in events, audit events, provisioning events) and is ingested into Sentinel via the Entra ID data connector. It's queryable in both Sentinel Logs and Defender XDR Advanced Hunting. Email data originates in Exchange Online, is processed by Defender for Office 365, and is available in EmailEvents and EmailAttachmentInfo tables in Defender XDR and Sentinel. Endpoint data originates on devices with Defender for Endpoint agent, flows to the Defender XDR cloud service, and is available in DeviceProcessEvents, DeviceNetworkEvents, and DeviceFileEvents. Cloud application data flows through Defender for Cloud Apps and appears in CloudAppEvents.

All of these tables are accessible through KQL in both Sentinel and Defender XDR Advanced Hunting. The key difference: Sentinel is where you build scheduled detection rules that generate alerts automatically. Advanced Hunting is where you run ad-hoc investigation queries interactively. Both use KQL. Both access the same tables. They serve different workflow phases — Sentinel for detection, Advanced Hunting for investigation.

The integration advantage

The Microsoft stack's integration means a single detection rule in Sentinel can join identity data with email data with endpoint data — tracing an attack from initial phishing email through credential compromise through endpoint execution in one query. This cross-domain detection is what traditional multi-vendor SOC stacks cannot do without SIEM normalization layers that often lose context in translation. The 28 detection rules this course builds in Modules 3-6 leverage this cross-domain capability extensively.