Study Guide

All three notification types live in Settings > Microsoft Defender XDR > Email notifications, under General. Each tab has its own rules, and each rule has a name, its settings, and a list of recipients. You can send a test email before saving, and deleting a rule is permanent. Configuring notifications takes the Manage security settings permission, or Security Administrator or higher when you use basic permissions.

Incident notification rules fire for new incidents or updates to existing ones. You filter by alert severity, and the page describes choosing severities per service source or detection source (for example, only Medium and High for EDR). You can scope a rule to all device groups or selected ones, send only one email per incident, and add the organization name and a tenant-specific portal link. The email carries the incident name, severity, and categories and links straight to the incident.

Response action rules, on the Actions tab, cover manual actions, automated actions (automatic attack disruption and automated investigation and response), or both. You pick the specific actions, the device group scope, and whether to be told when an action completes, fails, or both. They don't cover custom detections that include response actions.

Threat analytics rules notify you when reports are published or updated. A rule can cover every report or only reports of a certain type or with a specific tag. Names and descriptions accept only English letters and numbers.

Alert tuning, previously called alert suppression, handles alerts caused by known, expected activity. You create a rule in Settings > Microsoft Defender XDR > Alert tuning, or from an alert with Tune alert. A rule names the service sources and conditions based on evidence such as files, processes, scheduled tasks, AMSI scripts, and WMI events, combined with AND, OR, and groups. Its action is Hide alert, which suppresses the alert and creates no incident (Defender for Endpoint alerts only), Resolve alert, which resolves the alert and its incident, or Set as behavior, which turns matching signals into behaviors that never reach the alert queue (not for Defender for Cloud or Defender for Office 365 alerts).

Tuned data isn't lost. Hidden alerts remain in the AlertInfo and AlertEvidence tables, and behaviors land in BehaviorInfo and BehaviorEntities, so hunters can still query them. Built-in tuning rules also reduce noise; they don't affect automated investigations or email notifications, and an automated investigation that finds malicious activity reactivates the alert. Alert tuning doesn't work with custom detections, so tune those in the detection itself.

Correlation puts each new alert into a new incident or an existing one, based on Defender's internal logic, and keeps comparing incidents afterward. When incidents share entities, artifacts, time frames, or a sequence of attack steps, Defender merges them: the source incident's alerts, tags, and entities move to the target, the source gets a Redirected tag and is closed, and Defender chooses the direction. Merges don't happen when an incident is closed, the incidents have different assignees or classifications, the target would exceed the entity limit, or (if enabled) the devices are in different device groups. After fixing the blocker you can merge manually (preview), up to five incidents at a time.

Two settings change correlation scope. With Microsoft Sentinel in the Defender portal, only the primary workspace's alerts correlate with Defender alerts; secondary workspaces stay separate. In Defender for Endpoint advanced features, Restrict correlation to within scoped device groups stops alerts from different device groups forming one incident, which helps a local SOC but splits incidents for the global SOC.

Turn advanced features on or off in Settings > Endpoints > Advanced features, then select Save preferences. Which ones matter depends on the other Microsoft security products you run, and the exam tends to ask which switch a scenario needs.

Protection switches: EDR in block mode blocks malicious artifacts found by endpoint detection and response even when Microsoft Defender Antivirus is in passive mode behind another antivirus product. Allow or block file lets you block a file from the Add Indicator tab on its file page, which requires Microsoft Defender Antivirus as the active antimalware solution and cloud-based protection on. Custom network indicators let IP, domain, and URL indicators allow or block connections (Windows 10 version 1709 or later, or Windows 11). Tamper protection stops apps and other methods from changing security settings. Web content filtering blocks unwanted site categories through policies.

Investigation switches: Live response, Live response for servers, and Allow unsigned script execution in live response are three separate toggles, and users still need live response permissions. Automatically resolve alerts resolves alerts where nothing was found or everything was remediated, but never overwrites a status an analyst set manually. Restrict correlation to within scoped device groups keeps incidents inside device groups. Download quarantined files is on by default.

Integration switches connect other products: the Microsoft Intune connection for device risk-based Conditional Access (it must be turned on in both Intune and Defender for Endpoint), Microsoft Defender for Cloud Apps, sharing endpoint alerts with Microsoft Purview insider risk management, and showing user details from Microsoft Entra ID.

Indicators (Settings > Endpoints > Rules > Indicators) define what to allow, audit, warn on, or block for files, IP addresses, URLs and domains, and certificates. Files support Allow, Audit, Warn, Block execution, and Block and remediate; IPs and URLs support all of those except Block and remediate; certificates support Allow and Block and remediate. Each indicator has an action, a duration, and a device group scope, and a tenant can have up to 15,000. A domain indicator also matches its subdomains. Microsoft recommends indicators only for known-bad items or things you must explicitly allow, and prefers application control over file hashes to block whole applications.

Web content filtering policies block website categories for chosen device groups; categories that aren't blocked are audited. When two policies apply, the more restrictive setting wins per category. To let one team reach a single site in a blocked category, create a domain Allow indicator scoped to that team's device group.

Automation uploads controls content analysis: which file extensions and email attachment extensions automated investigations send to the cloud for deeper inspection. Submitted files are kept for six months. Automation folder exclusions name folders (with optional extensions and file names) that automated investigation and remediation skips. They apply to every onboarded device and only to automated investigation; antivirus still scans the files, and live response collection of an excluded file fails with File is excluded.

Custom data collection rules also live in this section and are covered with the custom data collection bullet.

Defender for Endpoint collects a lot by default, but some hunting, compliance, and incident response work needs more, such as every script run on privileged workstations or every network connection from a suspect server. Custom data collection, in preview, adds that telemetry without replacing or changing the default collection. It's included with Defender for Endpoint Plan 2, but the data is ingested into Microsoft Sentinel and billed there.

Rules are created in Settings > Endpoints > Rules > Custom Data Collection. Each rule picks one table (DeviceCustomProcessEvents, DeviceCustomImageLoadEvents, DeviceCustomFileEvents, DeviceCustomNetworkEvents, or DeviceCustomScriptEvents), the actions to collect, and conditions that filter events. You must select the Sentinel workspace during setup even if one is already connected, and only one workspace per tenant is supported for this feature.

Scope is set with dynamic tags from Asset Rule Management, which must have run at least once; manual tags aren't supported. Supported devices are Windows 10 and 11 (Windows 10 needs ESU enrollment) and Windows Server 2019 or later. Rules usually deploy in 20 minutes to 1 hour.

Each rule can collect up to 75,000 events per device in a rolling 24-hour window; when a device hits the limit, that rule stops on that device until the window resets. Start with a small pilot group, watch volume, and prefer several focused rules over one broad rule.

Attack surface reduction rules target behaviors malware commonly uses: Office apps creating child processes or injecting code, obfuscated scripts, executables launched by scripts, credential theft from LSASS, and so on. They are a Microsoft Defender Antivirus feature for Windows, so Defender Antivirus must be in active mode with real-time protection on, and cloud-delivered protection matters. They aren't available on macOS or Linux.

Each rule has a mode. Audit evaluates the rule without blocking and records what would have been blocked, visible in the ASR rules report, Windows Event Viewer, and advanced hunting. Block stops the behavior. Warn blocks but lets the user bypass for 24 hours (not supported for the LSASS and Office code injection rules). Off and Not configured both leave the rule inactive, but Not configured avoids policy conflicts. Microsoft recommends Block for the standard protection rules and Audit-first testing for the rest, then per-rule exclusions rather than turning a rule off.

DeviceEvents
| where ActionType startswith "Asr"
| where ActionType endswith "Audited"

Microsoft Intune endpoint security policies are the recommended deployment method, and the Defender portal offers the same policies at Endpoints > Configuration management > Endpoint security policies. Policy types include ASR rules, antivirus, antivirus exclusions, EDR, firewall, and device control. For devices managed by Defender for Endpoint security settings management (not enrolled in Intune), assign policies to Entra device groups only. Your role must cover all devices, not a scoped device group. Policies can take up to 90 minutes to reach a device; Policy sync on the device page speeds that up.

An alert creates an incident, which can start an automated investigation. The investigation gives each piece of evidence a verdict of Malicious, Suspicious, or No threats found, and identifies remediation actions such as quarantining a file, stopping a process, isolating a device, or blocking a URL. Related alerts that arrive during the investigation are added to it, and it expands when an affected entity appears elsewhere. AIR covers devices (Defender for Endpoint), on-premises Active Directory users (Defender for Identity), and email content (Defender for Office 365).

Whether device actions run automatically depends on the device group's automation level (see device groups and automation levels); actions that need approval wait in the Action center. Configuring AIR takes Security Administrator or higher. Approving device actions takes Security Administrator or the Active remediation actions permission, and approving email actions also needs an Email & collaboration role group with the Search and Purge role.

The Action center (Actions and submissions > Action center) is the single place to manage this. The Pending tab lists actions awaiting approval or rejection; approve them quickly so investigations can finish. The History tab is an audit log of automated, approved, manual, live response, and antivirus actions, and some actions, such as isolating a device, can be undone. The Action source column shows where each action came from.

Microsoft's Defender for Endpoint pages note a change: as of September 1, 2026, AIR no longer runs as a separate investigation experience or can be triggered manually for Defender for Endpoint alerts, because its detection and response logic now runs in the default antivirus stack. Run a full antivirus scan for on-demand checks. AIR for Defender for Office 365 is unchanged.

Attack disruption correlates signals from endpoints, identities, email, and SaaS apps into a high-confidence incident, identifies assets the attacker controls, and contains them in real time. It acts at the incident level, unlike blocking a single indicator. Actions include contain device, contain IP, contain user, and isolate device (preview) through Defender for Endpoint; disable user through Defender for Identity; revoke sessions or suspend the user in Microsoft Entra ID; protective measures for a compromised OAuth app through Defender for Cloud Apps; and, in preview, Okta and AWS actions through Microsoft Sentinel. Every action can be undone.

There is no rule to write. Instead you meet prerequisites: the right licenses, deployed Defender products (each product must be deployed to run its own actions), Defender for Endpoint device discovery set to Standard for Contain device, domain controller auditing and valid action accounts for Defender for Identity, a fully configured Microsoft 365 connector in Defender for Cloud Apps, and Exchange Online mailboxes with auditing of events such as MailItemsAccessed and HardDelete for Defender for Office 365.

Device group automation levels decide whether devices can be acted on. Full is recommended; Semi still allows disruption without manual approval; No automated response excludes the group, which Microsoft advises only for a few devices.

Exclusions are in Settings > Microsoft Defender XDR > Automated response: user exclusions under Identities, device group automation levels and IP exclusions under Devices, and policy application rules for tagged devices (preview). Excluding a device group also affects automated investigation. You can't turn disruption off in the portal; opting out takes a support case, and you still receive the alerts.

Create device groups in Settings > Endpoints > Permissions > Device groups (up to 2,000 per tenant). A group has a name, a remediation level, a matching rule based on device name, domain, tags, and OS platform, and the Microsoft Entra user groups that can access it. A device that matches several groups joins only the highest-ranked one (rank 1 is highest), and devices matching none go to Ungrouped devices (default), which can't be deleted or re-ranked. A group with no user groups assigned is visible to everyone with portal access, and you can assign only Entra groups that already have RBAC roles.

Automation levels decide what happens to remediation actions. Full automation is recommended and is the default for tenants created on or after August 16, 2020. Semi-automation for all folders holds every action for approval; the core folders and non-temporary folders variants auto-remediate some locations and hold the rest. (Learn pages label these levels slightly differently, so recognize them by meaning.) Pending actions time out after seven days, which counts as a rejection. No automated response runs no automated investigation and isn't recommended.

In the Defender for Endpoint RBAC model, roles are created in Settings > Endpoints > Roles and assigned to Entra security groups. Permissions include View data, Active remediation actions (response actions, approvals, indicators), Alerts investigation (manage alerts, run scans, collect investigation packages, manage tags), Manage portal system settings, Manage security settings, and Live response Basic or Advanced (Advanced adds uploading files and running library scripts). Turning on roles removes access from read-only users until they get a role, and can't be reverted.

New Defender for Endpoint tenants since February 16, 2025 use only Microsoft Defender unified RBAC, which manages permissions for Defender for Endpoint, Identity, Office 365, Cloud Apps, Defender for Cloud, and Sentinel in one place. Device group scope is still defined on the device groups page. Existing tenants keep their roles until they activate unified RBAC, and managing it takes at least Security Administrator.

An automation rule has a trigger, conditions, and actions. Triggers are When incident is created, When incident is updated (status, owner, severity, alerts, comments, tags, or tactics change), and When alert is created (alerts from scheduled and NRT analytics rules). Incident triggers are the usual choice because an incident is the evolving case file; the alert trigger is mainly for analytics rules that don't create incidents. Conditions check incident and entity properties, the analytics rule names, and, for updates, what changed and who changed it (Updated by), so a rule can ignore changes made by other automation rules.

Actions that need no playbook are adding incident tasks, changing status (with a closing reason and comment when closing), changing severity, assigning an owner, and adding tags. Run playbook calls a playbook for anything more complex or external; only incident-trigger playbooks run from incident-trigger rules, and only alert-trigger playbooks from alert-trigger rules. Actions run in the order listed.

Rules run sequentially, never in parallel. Each trigger type has its own queue, all create-trigger rules run before update-trigger rules, and a later rule sees the incident as earlier rules left it. Rules with the same order number run in random order. An expiration date turns a rule off automatically, which suits suppression rules for a penetration test or maintenance window. Manage rules on the Automation page; you can also create them from the analytics rule wizard and, in the Azure portal only, from an incident.

After a workspace is onboarded to the Defender portal, all incident creation happens there. Alert-trigger rules act only on Sentinel alerts, so use the Enhanced Alert Trigger to include Defender XDR alerts. Rules can take up to 10 minutes to run, several changes in 5–10 minutes arrive as one update, and incident titles can change through correlation, so use analytics rule names and tags as conditions instead. Microsoft Sentinel in the Azure portal is supported only until March 31, 2027.

A playbook is a Logic Apps workflow run from Microsoft Sentinel, so Logic Apps charges can apply. Typical uses are enrichment, two-way sync with a ticketing system such as ServiceNow, posting to Teams or Slack, and response actions such as isolating a device or blocking an account. Create one from the Automation page with an incident, alert, or entity trigger on a Consumption logic app, or start from a blank Standard logic app. Standard workflows support private endpoints and virtual network integration. Managed identity is the recommended way for the playbook to authenticate to Sentinel. Playbook templates (preview) come from the Automation page, the Content hub, and GitHub.

Roles: Owner lets you grant access to playbooks in a resource group. Microsoft Sentinel Contributor attaches playbooks to rules. Microsoft Sentinel Responder opens incidents but can't run playbooks; Microsoft Sentinel Playbook Operator runs them manually. Microsoft Sentinel Automation Contributor exists only to let automation rules run playbooks. Logic App Contributor and Operator (Consumption) and the Logic Apps Standard roles control editing the workflows.

Sentinel runs incident playbooks with its own service account, which needs Microsoft Sentinel Automation Contributor on the playbook's resource group. Grant it from Manage playbook permissions (in an automation rule, or in Settings) with Owner or User Access Administrator; a playbook shown grayed out in an automation rule means the permission is missing. In multitenant setups, grant it in the tenant where the playbook lives.

Run playbooks automatically by adding a Run playbook action to an automation rule. Calling playbooks directly from analytics rules is the legacy method, deprecated as of March 2026. You can run a playbook manually on an incident, and in the Azure portal also on an alert or an entity; the Defender portal doesn't support manual runs on alerts or entities.

Microsoft Sentinel has built-in Azure roles that build on each other. Microsoft Sentinel Reader views data, incidents, workbooks, and recommendations. Microsoft Sentinel Responder adds managing incidents (assigning, changing status, closing). Microsoft Sentinel Contributor adds installing and updating solutions and creating or editing resources such as analytics rules and workbooks. Two roles serve automation: Microsoft Sentinel Playbook Operator lists and manually runs playbooks, and Microsoft Sentinel Automation Contributor lets Sentinel attach playbooks to automation rules and isn't meant for user accounts. Logic App Contributor creates and edits playbooks.

Some tasks need extra roles. Connecting a data source needs write permission on the workspace, plus whatever the connector requires. Creating or deleting workbooks needs Contributor, or a lesser Sentinel role plus Workbook Contributor. Guest users who assign incidents need the Microsoft Entra Directory Reader role plus Responder. Managing Content hub content needs Contributor at the resource group level. Broader roles such as Owner, Contributor, Reader, Log Analytics Contributor, and Log Analytics Reader also grant access, and assignments are cumulative.

Assign roles on the resource group that contains the workspace, so related resources such as playbooks are covered. A typical split is Responder plus Playbook Operator for analysts, and Contributor plus Logic App Contributor for engineers. To limit access to specific data, use resource-context or table-level RBAC.

The Sentinel data lake, which requires onboarding to the Defender portal, uses Microsoft Entra ID roles. Global Reader, Security Reader, Security Operator, Security Administrator, and Global Administrator can read across all lake workspaces. Security Operator, Security Administrator, and Global Administrator can write to lake tables with KQL jobs or notebooks and can create and manage lake jobs. Custom access for the lake uses Defender unified RBAC custom roles.

The Analytics tier holds data for real-time use: analytics rules, alerting, hunting, workbooks, and every Sentinel feature. It has two settings. Analytics retention (30 days to two years) is how long data stays hot. Total retention (up to 12 years) keeps data longer in the data lake; by default it equals analytics retention, so data is mirrored to the lake for the same period. Sentinel solution tables can keep 90 days of analytics retention at no extra retention charge, and longer periods are billed as long-term retention.

The Data lake tier stores data only in the lake, at low ingestion and storage cost, for 30 days to 12 years. It suits compliance logging, forensics, and trend analysis. Data there isn't available to real-time features such as analytics rules, hunting queries, parsers, watchlists, workbooks, and playbooks, and queries are slower; you use KQL queries and jobs, Spark jobs, notebooks, summary rules, and search jobs instead. KQL and notebook jobs can promote results into the Analytics tier.

The XDR default tier keeps Defender XDR advanced hunting data for 30 days, included in the XDR license. XDR tables such as IdentityInfo can be viewed but not managed there. When you raise a supported XDR table's retention above 30 days (up to 90), the table is created in your Sentinel workspace in the Analytics tier and mirrored to the lake; Sentinel ingestion charges apply but storage is free. Beyond 90 days, Analytics tier storage costs apply. You can instead ingest XDR data into the Data lake tier only, while advanced hunting still has 30 days.

Manage tables at Microsoft Sentinel > Configuration > Tables > Manage table (or from a connector's Table management section). Moving a table to the Data lake tier stops alerting, advanced hunting, analytics rules, and custom detections for it, and some XDR and solution tables can't change tier. Shortening total retention waits 30 days before deleting data; changing analytics retention takes effect immediately. Table insights on the same page shows ingestion volume, fluctuations, last data received, and estimated cost, but isn't an alerting tool. Viewing table settings needs security data basics (read) or Log Analytics Reader; configuring them needs data (manage) or Log Analytics Contributor.

Sentinel workbooks are built on Azure Monitor workbooks. Each saved workbook is an Azure resource in the workspace's resource group, tagged with the workspace, and it stores only the workbook JSON, never data. You need at least Workbook Reader or Workbook Contributor on that resource group, and you can restrict access with Azure RBAC on the resource.

To use a template, install the solution that contains it (or the standalone workbook) from the Content hub, open Threat management > Workbooks, check the template's Required data types, and select Save. Select View saved workbook, then Edit to customize; Save as clones it into My workbooks. To build one from scratch, select Add workbook, then add text, queries, and parameters. Set the data source to Logs and the resource type to Log Analytics, and prefer ASIM parsers over single tables so the workbook covers future data sources. Deleting a workbook is permanent, but its template stays.

Workbooks refresh manually or on Auto refresh, from 5 minutes to 1 day; auto refresh pauses while editing and turns off when the workbook is closed. Some visualizations, and printing or saving as PDF, are available only in the Azure portal, reached with Open in Azure.

SecurityEvent
| where TimeGenerated > ago(14d)
| summarize count() by bin(TimeGenerated, 1d)

SOC optimization recommendations look at your ingested data and active detections and suggest how to get more security value for the cost. They are recalculated every 24 hours. In the Defender portal (after onboarding Sentinel) open SOC optimization from the navigation; in the Azure portal it is under Threat management. It uses the normal Sentinel roles, and the Defender portal version includes coverage across Microsoft security services.

Data value recommendations look at billable tables that ingested data in the past 30 days. A table unused by any detection but used by workbooks or hunting → turn on analytics rule templates, or move it to basic logs if eligible. A table not used at all → turn on templates, or stop ingesting it or move it to long-term retention. A table used only by Azure Monitor → turn on relevant templates, or move it to a non-security workspace. Tables used by UEBA or threat intelligence matching analytics aren't flagged. Unused columns (preview) can also be flagged.

Coverage recommendations are threat-based (compare your data sources and detections with what a threat such as human-operated ransomware needs), AI MITRE ATT&CK tagging (preview), and risk-based (preview). If data exists but detections are missing, turn on templates; if templates are on but data is missing, connect sources; if both are missing, connect both or install a solution. The overview rates threat coverage High (over 75% of recommended rules active), Medium, or Low, and links to the Content hub and to the MITRE ATT&CK page.

Recommendations start as Active. Mark them in progress, Completed, or Dismissed; Sentinel completes them automatically when your environment changes make them irrelevant. Completed and dismissed items can be reactivated, which recalculates them within about an hour.

Connectors ship inside solutions. Install the solution from the Content hub, then open Microsoft Sentinel > Configuration > Data connectors, select the connector, and select Open connector page to follow its prerequisites and configuration. You need read and write permissions on the workspace. Once connected, the Data received graph shows incoming data; in the Defender portal query it in Advanced hunting. With the data lake onboarded, data goes to the Analytics tier and is mirrored to the lake by default, and data can take 90 to 120 minutes to reach the lake.

Connectors use different mechanisms. Azure Monitor Agent (AMA) connectors, such as Windows Security Events via AMA, Windows Forwarded Events, Syslog via AMA, and CEF via AMA, use data collection rules. Diagnostic settings-based connectors, such as Azure Activity, use Azure diagnostic settings, sometimes applied by Azure Policy. Service-to-service connectors, such as Microsoft Entra ID and Microsoft 365, connect directly. API-based and codeless connectors pull from external services.

For Windows, the destination table matters. Windows Security Events via AMA writes to SecurityEvent, which many built-in analytics rules (including some NRT rules) query. Windows Forwarded Events collects from a Windows Event Collector and writes to WindowsEvent, even for Security log events, so those rules won't match unless you adapt them or use ASIM parsers. A generic AMA Windows event DCR outside Sentinel writes System, Application, and Security events to the Event table. The legacy Log Analytics agent connector was deprecated August 31, 2024.

Any machine that isn't an Azure VM, including on-premises and other-cloud servers, needs Azure Arc before you can use an AMA-based connector.

Open the connector page and select Add data collection rule. On Basics, name the rule and choose a subscription and resource group; the rule can live apart from the machines as long as it's in the same tenant. On Resources, pick Azure VMs and Azure Arc-enabled servers; the Azure Monitor Agent is installed on any that don't have it. On Collect, choose the events. Existing rules, including those created with the API, appear on the connector page for editing.

Event sets: All events collects the full Security and AppLocker logs (not Application or System). Common is a reduced set that keeps a full user audit trail, such as sign-in 4624 and sign-out 4634, group changes, and Kerberos operations. Minimal covers likely breach indicators and rare important events, such as 4624 and 4625 sign-ins and 4688 process creation, but not sign-outs. Custom uses XPath queries you write.

Data collection rules filter at the source, which cuts ingestion cost, and can be reused across machines and environments. A custom filter is written LogName!XPathQuery, for example Security!*[System[(EventID=4625)]]. The agent supports XPath 1.0 only, and a box accepts up to 20 expressions (up to 100 boxes per rule). Test the query part locally with Get-WinEvent -LogName Security -FilterXPath before you add it. Analytic and Debug channels can't be collected.

Rules can also be created with a PUT request to the data collection rules API, useful for an MSSP creating many rules; the rule defines the Microsoft-SecurityEvent stream, the XPath queries, and the destination workspace.

Windows Event Forwarding reads operational or administrative events on devices and forwards the ones you choose to a Windows Event Collector (WEC) server. To bring them into Sentinel, enable and run WEC on the collector, install the Azure Monitor Agent on it, and enable the Windows Forwarded Events connector. Events land in WindowsEvent, not SecurityEvent, so install the ASIM parsers and check which table your analytics rules query.

Subscriptions are push or pull. Source-initiated (push) subscriptions are configured on clients through Group Policy and scale best; access is controlled by an ACL of machine accounts or groups on each subscription. Collector-initiated (pull) subscriptions list the clients on the WEC server, and the subscription's credentials need to read the clients' event logs, usually through the Event Log Readers group. Pull suits monitoring a specific set of machines.

Microsoft's design uses a Baseline subscription for all devices and a Suspect (targeted) subscription for devices under closer watch. WEF is passive: it can't enable audit policy, turn on disabled channels, or resize logs, so set those through Group Policy first. By default a subscription forwards only events created after the client receives it; turn on read existing events for the targeted subscription.

Delivery options are Normal (pull, batches of 5 items with a 15-minute timeout), Minimize bandwidth (push, 6-hour batches), and Minimize latency (push, 30 seconds); Custom is set with wecutil. Traffic is mutually authenticated and, in a domain, encrypted with Kerberos by default. Plan for about 3,000 events per second on average per WEC server.

Syslog is a standard logging protocol; the agent supports RFC 3164 and RFC 5424 messages. CEF extends Syslog with a standard header (vendor, product, version, event class, severity, ID) and extensions, and is used by firewalls, IDS, and other security appliances. Syslog via AMA writes to the Syslog table, and CEF via AMA writes to CommonSecurityLog.

For a Linux server, install the agent on the server itself. For appliances, set up a log forwarder: a dedicated Linux machine, in Azure, on-premises, or another cloud, running rsyslog or syslog-ng. Appliances send to the forwarder's daemon, by default on TCP or UDP port 514, and the daemon passes messages to the agent (on TCP port 28330 for AMA 1.28.11 and later). A forwarder outside Azure needs the Azure Arc Connected Machine agent; the forwarder needs Python 2.7 or 3. Use TLS in the daemon if messages travel across networks, and a round-robin load balancer for a scale set.

Setup: install the Syslog or Common Event Format solution from the Content hub, open the connector, and create a data collection rule that selects the forwarder (installing the agent) and, on the Collect tab, a minimum log level per facility. Selecting a level also collects every more severe level. Then run the installation script on the forwarder so the daemon listens for other machines and opens ports, and point the appliances at it. Creating DCRs needs Monitoring Contributor; deploying the agent needs a role such as Virtual Machine Contributor. The API lets you filter specific levels but needs the agent installed manually and a DCR association.

Sending CEF and Syslog on the same facility duplicates data in both tables. Use separate facilities per stream, or add an ingestion-time transformation to the Syslog DCR that drops messages containing CEF, checking both ProcessName and SyslogMessage.

Diagnostic settings-based connectors send Azure platform logs to the Sentinel workspace. Some are standalone: from the connector page, open the resource, select Diagnostic settings > Add diagnostic setting, name it, select Send to Log Analytics with the Sentinel workspace, and choose the log and metric types. That needs read and write permissions on the workspace.

Others are managed by Azure Policy, which applies one diagnostic settings configuration to all resources of a type in a scope. From the connector page, select Launch Azure Policy Assignment wizard, choose the subscription (and optionally resource group) as the scope, pick the Sentinel workspace and log types on Parameters, and create it. The policy covers resources created later; to include existing resources, select Create a remediation task on the Remediation tab. You need Owner on the assignment scope.

The Azure Activity connector brings in the subscription activity log: Azure Resource Manager operations, service health events, write operations on resources, and activity status. It now uses the diagnostic settings pipeline applied by Azure Policy, and subscriptions still on the legacy method must be disconnected first (Disconnect All on the connector page). Data lands in the AzureActivity table.

Policy-managed connectors show as connected only if data arrived in the past 14 days, and reconnect as soon as data flows again. Some resources need extra setup, such as selecting the parent storage account and each child storage type.

Threat indicators link artifacts such as IPs, domains, URLs, and file hashes to known threats. Sentinel stores them as STIX objects along with threat actors, attack patterns, identities, and relationships. The connectors come in the Threat Intelligence solution in the Content hub.

Import options: the Microsoft Defender Threat Intelligence data connector brings Microsoft's indicators (standard or premium versions). The Threat Intelligence - TAXII connector is a built-in TAXII client for STIX/TAXII 2.0 or 2.1 servers; you supply the API root URL, collection ID, optional credentials, which indicators to take, and a polling frequency, and some servers require Sentinel's client IPs on an allowlist. The upload API lets a threat intelligence platform or custom app send STIX objects without a connector, using a Microsoft Entra app with Microsoft Sentinel Contributor on the workspace. The older Threat Intelligence Platform connector is being deprecated. A TAXII Export connector sends intelligence out over TAXII 2.1.

Indicators are stored in the ThreatIntelIndicators table, with other STIX objects in ThreatIntelObjects; Sentinel stopped writing to the legacy ThreatIntelligenceIndicator table after July 31, 2025, so queries and rules must use the new tables. Sentinel reingests the data every 7–10 days and deduplicates by Id, keeping the newest. View intelligence in the management interface or with queries.

Curate intelligence with ingestion rules, relationships, tags, and Traffic Light Protocol markings. Ingestion rules apply only to connector feeds, not upload API or manual objects; they run in order until a Delete action skips an object, and changes take up to 15 minutes. Use threat intelligence analytics rule templates to turn indicators into alerts.

Azure tables have fixed schemas. To store data in a different shape, create a custom table and a data collection rule (DCR) that sends data to it. Custom table names end in _CL. The Azure portal adds the suffix; with the CLI, PowerShell, REST, or templates you add it yourself, and the stream name in the DCR must match. Every table needs a TimeGenerated column; if it's missing, Azure Monitor adds it to the DCR transformation. Don't put sensitive information in table names, because they appear in billing.

In the portal, go to the Log Analytics workspace > Tables > Create, name the table, choose a plan (Analytics by default, Basic, or Auxiliary / Lake), select or create a DCR and a data collection endpoint, and upload a sample JSON file to define the schema. Managing tables needs workspace write permissions, such as Log Analytics Contributor. Custom columns can be added later; update any DCRs that send to the table.

The Logs ingestion API sends custom-format logs from any source into standard or custom tables, with the DCR defining the flow and transformation. AMA connectors use DCRs associated with the agent; diagnostic settings and some service connectors use the workspace transformation DCR.

Ingestion-time transformations are KQL queries in the DCR that run on each incoming record: filter rows or columns to cut cost, normalize to ASIM, add calculated columns, or mask personal data. In a Sentinel-enabled workspace, filtering data out of Analytics tables isn't charged by Azure Monitor, but Basic tables are charged when a transformation drops more than 50% of incoming data.

Create a rule from Advanced hunting (run the query, then select Create detection rule) or from Hunting > Custom detection rules (+ Create detection rule). The wizard covers the query, alert details (name, frequency, title, severity, category, MITRE tactics and techniques, linked threat analytics report, description, recommended actions), enrichment, actions, and scope. Each run can raise up to 150 alerts, so tune the query to avoid everyday activity. Microsoft now recommends custom detections as the way to build new rules across Defender XDR and Sentinel.

DeviceEvents
| where ActionType == "AntivirusDetection"
| summarize (Timestamp, ReportId)=arg_max(Timestamp, ReportId), count() by DeviceId
| where count_ > 5

Frequencies are every 24, 12, 3, or 1 hours, Continuous (NRT), or Custom (5 minutes to 14 days, for rules on Sentinel data only). A new rule first checks the past 30 days. Continuous rules must query one supported table with supported operators and no joins, unions, externaldata, or comments. Enrichment can build dynamic titles from up to three columns, add up to 20 custom details, and map impacted assets and related evidence.

Actions need specific columns: device actions (isolate, collect investigation package, antivirus scan, initiate investigation, restrict app execution) use DeviceId; file quarantine uses SHA1 or SHA256 columns; user actions (mark compromised, disable user, reset authentication) use AccountObjectId or SIDs; email actions (move to folder, soft or hard delete) need NetworkMessageId and RecipientEmailAddress. Scope limits device rules to all devices or chosen device groups.

Hunting > Custom detection rules lists every rule with its last run, last run status, next run, and status. After Sentinel is onboarded to the Defender portal, Sentinel analytics rules appear in the same list, and you can filter by workspace. Select a rule to see its details, triggered alerts, and triggered actions.

From a rule you can Run it now (which resets the next run interval), Edit it in the wizard, Modify query in Advanced hunting, Turn on or Turn off, Delete it permanently, or include or exclude an analytics rule from correlation. From Triggered alerts you can set an alert's status and classification, link it to an incident, or rerun the query. Rules that fit Continuous (NRT) can be migrated with Migrate now.

Lookback: for rules on Defender XDR data it is fixed by frequency (24 hours → 30 days, 12 hours → 48 hours, 3 hours → 12 hours, 1 hour → 4 hours). For rules on Sentinel data only, you set it (up to 30 days for daily or slower rules). Rules evaluate ingestion time, and overlapping lookbacks are deduplicated into one alert. Frequency changes apply from the next scheduled run.

Permissions follow the data. Defender data needs Security settings (manage), Security Administrator, or Security Operator (only when Defender for Endpoint RBAC is off; otherwise add Manage security settings). Sentinel data needs Microsoft Sentinel Contributor. You also need permissions for every service a table covers and for every device in the rule's scope. Rules can also be managed as code (preview).

Rule types are scheduled, near-real-time (NRT), anomaly, and Microsoft security rules, plus single-instance templates for threat intelligence, advanced multistage attack detection (Fusion), and machine learning behavior analytics. Find active rules, templates, and anomalies on the Analytics page, and more templates in Content hub solutions. A template's required data sources must be connected before you can create a rule from it, and rules show an Update tag when their template changes. After onboarding to the Defender portal, Microsoft security rules and Fusion aren't available, because Defender XDR creates and correlates incidents; Microsoft now recommends custom detections for new rules.

Scheduled rules run a KQL query (1 to 10,000 characters, no search * or union *) on an interval and lookback, each from 5 minutes to 14 days, with the interval no longer than the lookback. They run on a five-minute delay for ingestion lag. Settings include an alert threshold, event grouping (one alert for all events, or one per event up to 150 alerts per run), suppression for up to 24 hours after an alert, entity mapping, custom details, and dynamic alert details. Incident settings create an incident per alert by default; alert grouping combines alerts (by all entities, all alerts, or selected entities and details) within a time frame of 5 minutes to 7 days (default 5 hours), up to 150 alerts per incident. Results simulation shows what the last 50 runs would have produced.

NRT rules run every minute on a two-minute delay, query by ingestion time, support most scheduled rule features, and are limited to 50 per customer and 30 single-event alerts per run. They work best for sources with ingestion delay under 12 hours.

Threat intelligence: the Microsoft Defender Threat Intelligence Analytics rule is read-only and matches Microsoft's domain and IP indicators against CEF, Syslog, Windows DNS, Microsoft 365, Azure activity, and ASIM network data, grouping matches for the same indicator within 24 hours into one incident; it doesn't need a premium license. Machine learning behavior analytics rules (preview) detect unusual SSH and RDP sign-ins and aren't customizable. Automated responses are handled by automation rules, and playbooks attached directly to rules (Alert automation (classic)) are deprecated.

MITRE ATT&CK is a public knowledge base of attacker tactics and techniques. Sentinel's MITRE ATT&CK page, in preview and aligned to ATT&CK version 18, shows your coverage. Open it at Microsoft Sentinel > Threat management > MITRE ATT&CK in the Defender portal, or MITRE ATT&CK (Preview) in the Azure portal. By default the matrix shows active scheduled and NRT rules.

Use the legend to see how many active detections cover each technique, search by technique name or ID, and select a technique to open its details and links to related content such as hunting queries. The Defender portal version adds recommended coverage (active detections and products out of those recommended) and can filter the matrix by threat scenario.

Simulated coverage, from the Simulated rules menu, shows the coverage you would have if you configured detections that are available but not active, which helps prioritize which templates to enable.

Coverage comes from MITRE tags. Set tactics and techniques on analytics rules (and filter rules by technique), and incidents created from those rules inherit them. Hunting queries and bookmarks can carry tactics and techniques too. Threat-based SOC optimization recommendations link directly to the MITRE page filtered to their scenario.

Anomaly rules observe a behavior over time to build a baseline, then flag activity outside it. Anomalies aren't necessarily malicious, so the rules don't create alerts or incidents. They write to the Anomalies table, where anomalies add signal to detections, evidence to investigations, and starting points for hunting. Some anomalies come from the User and Entity Behavior Analytics (UEBA) engine, which compares each entity with its own history, its peers, and the organization.

Anomaly rules are enabled by default. Find them on the Analytics page's Anomalies tab, filtered by status, tactics, techniques, or data sources. Each rule shows its description, MITRE mapping, parameters, threshold (how unusual an event must be), frequency, Production or Flighting status, and template version.

You can't edit or delete built-in anomaly rules; you can only switch them between Production and Flighting. To tune one, duplicate it: the copy is named with " - Customized", starts disabled, and runs in Flighting mode. Only one customized copy per rule is allowed. Change its parameters and threshold, preview results, and enable it. When you switch the copy to Production, the original moves to Flighting automatically.

Anomalies
| where AnomalyTemplateId contains "<RuleId>"

Remediation actions on email are move to junk, move to inbox, move to deleted items, soft delete (recoverable from Recoverable Items), and hard delete (purged, recoverable only through single-item recovery). Only messages in cloud mailboxes can be acted on; on-premises, external, failed, or dropped messages can't. Analysts select messages in Threat Explorer (up to 100 by hand, or a whole query up to 200,000) or act from advanced hunting. Direct approval runs at once for users with the Search and Purge role; others use two-step approval, adding messages to a remediation that another analyst approves from the Action center Pending tab. Each remediation raises an "Administrative action submitted by an Administrator" alert and appears on the History tab. Service limits include 50 concurrent remediations, and batches of 50,000 or fewer work best.

Zero-hour auto purge (ZAP) retroactively acts on malicious messages delivered in the last 48 hours, without notifying users. Malware and high confidence phishing are quarantined; for phishing and spam, the outcome follows the anti-spam policy's action for that verdict (for example, move to Junk or quarantine). ZAP also covers Teams chat messages, but not on-premises mailboxes.

Automated investigation and response (AIR) in Defender for Office 365 Plan 2 starts from alerts such as suspicious email, ZAP, user submissions, user clicks, and suspicious mailbox behavior, or when an analyst selects Take action in Threat Explorer, advanced hunting, a custom detection, or the Email entity page. It needs audit logging turned on and doesn't start if those alert policies are off or replaced. Investigations group related messages into clusters and propose actions such as soft deleting the email or cluster and blocking a URL at time of click; a volume anomaly alone produces no pending action. For malicious similarity clusters, including URL and file clusters, AIR approves its own pending actions automatically; review and approve other pending actions in the investigation, the incident, or the Action center.

Automatic attack disruption contains high-confidence attacks such as business email compromise from a compromised account. Incidents where it acted carry an Attack Disruption tag and a yellow banner, and the graph shows contained or disabled assets; every action can be undone. For email scenarios it needs mailboxes in Exchange Online with mailbox auditing of events such as MailItemsAccessed, UpdateInboxRules, and HardDelete.

DLP alerts: turn on alerts for DLP policies in the Purview portal, then in the Defender portal filter Incidents by the Service/detection sources value Microsoft Data Loss Prevention, or by policy name, user, or device. DLP alerts can share an incident with alerts from Defender for Endpoint, Defender for Office 365, or Sentinel. The alert page shows the alert story, sensitive information types detected, and (with permission) the file source; Copilot can summarize the alert. Investigation needs an E5-level license such as Microsoft 365 E5 or E5 Compliance, and roles such as Manage Alerts or Information Protection Analyst. Administrative unit restrictions carry over from DLP.

Responses on a DLP alert depend on the location. For SharePoint or OneDrive files: apply a sensitivity or retention label, unshare, delete, download (needs the content viewer role), or withdraw feedback. For email: download the message. User and device cards offer account and device actions. Advanced hunting over the CloudAppEvents table, including Go hunt queries such as File shared with and User DLP violations for last 30 days, extends the investigation.

A change to plan for: from early October 2026, a built-in alert tuning rule sets DLP signals as behaviors instead of alerts, so they don't create incidents but stay in BehaviorInfo and BehaviorEntities. To keep DLP alerts in the queue, disable the rule in Settings > Microsoft Defender XDR > Alert tuning.

Insider Risk Management alerts appear in the incident and alert queues (Service source: Microsoft Purview Insider Risk Management) once data sharing with other security solutions is on in Insider Risk Management settings. Analysts need Security Operator or Security Reader plus an Insider Risk Management role group. Status and classification sync both ways within 30 minutes: New and In progress map to Needs review; True positive maps to Confirmed; benign and false positives map to Dismissed. Hunt with AlertInfo, AlertEvidence, DataSecurityBehaviors, and DataSecurityEvents (needs an Insider Risk Management analyst or investigator role). User entity pages show the insider risk severity.

Defender for Cloud raises security alerts when its workload protection plans detect threats in Azure, hybrid, or multicloud resources, and correlates related alerts into incidents. Alerts map to MITRE ATT&CK intent and have a severity: High (probable compromise, high confidence; act now), Medium (probably suspicious, often machine learning or anomaly based), Low (possibly benign or a blocked attack), and Informational. Alerts stay visible for 90 days even if the resource is deleted, and can be exported to CSV, continuously exported, or streamed to Microsoft Sentinel.

In Defender for Cloud (Security alerts), select an alert to see its description, affected resources, and kill chain intent, then View full details. The Take action tab offers Inspect resource context (activity logs), Mitigate the threat (manual steps), Prevent future attacks (recommendations), Trigger automated response (a logic app), and Suppress similar alerts (a suppression rule). When done, set the status to Dismissed; statuses can be changed in bulk.

In the Defender portal, all Defender for Cloud incidents and alerts appear except informational alerts, with cloud resources in the attack story, asset tabs, and entity pages. Access is tenant-wide through a unified RBAC role for Defender for Cloud, or Global or Security Administrator. Defender for Cloud alert status syncs both ways, but Defender for Endpoint alerts on cloud resources don't sync. Advanced hunting adds CloudAuditEvents (Azure Resource Manager and Kubernetes control plane), CloudProcessEvents, and CloudStorageAggregatedEvents.

Sentinel customers who ingest Defender XDR incidents should use the tenant-based Microsoft Defender for Cloud connector, disconnect the subscription-based (legacy) connector, and turn off rules that create incidents from Defender for Cloud alerts, to avoid duplicates. With several workspaces, correlated Defender for Cloud incidents go to the primary workspace.

Defender for Cloud Apps alerts are organized by MITRE ATT&CK tactic: initial access, persistence, privilege escalation, credential access, collection, and exfiltration. After investigation, classify each as a true positive (confirmed malicious), benign true positive (suspicious but authorized, such as a penetration test), or false positive (not malicious). For true positives, review all of the user's activity and compare device, browser, IP, and location with known values to understand the scope.

Each detection has recommended actions. For example, activity from an anonymous or suspicious IP address that is confirmed malicious → suspend the user, mark the user as compromised, and reset the password; activity from an infrequent country (after a seven-day learning period) that is malicious → suspend the user, reset the password, and plan a safe re-enable, while frequent travelers can be excluded. Signs such as an unusual file download or suspicious inbox forwarding following the first alert suggest exfiltration.

Since June 2025 anomaly detections have been moving to a dynamic threat detection model that adapts automatically; legacy anomaly policies are disabled on the Policy management page and some detections were renamed, with no action needed. Training material that describes tuning each anomaly policy's sensitivity reflects the older model.

Governance actions for users in connected apps include Suspend user, Require user to sign in again, and Confirm user compromised, which sets the user's Entra risk to high so risk policies apply. If Entra ID syncs from on-premises Active Directory, on-premises settings can revert a suspension. File actions include labeling, removing sharing, and quarantine; file policies retire on January 6, 2027. For Google Workspace and Salesforce you can revoke an OAuth app. The Governance log (Cloud Apps > Governance log) records every manual and automatic action with its result and lets you retry or revert some.

ID Protection needs Microsoft Entra ID P2 or Entra Suite for full features. Start triage with the ID Protection dashboard, the risky users, sign-ins, and detections reports, and the sign-in logs, looking for shared characteristics such as IP or location that suggest more compromised accounts. In the Defender portal, find ID Protection alerts under Incidents & alerts > Alerts with the product name AAD Identity Protection, and follow user risk through related incidents. Global Reader is the least privileged role for risk reports.

Self-remediation comes first when possible. With risk-based Conditional Access policies, sign-in risk is remediated when the user completes MFA, and user risk when the user completes MFA and a secure password change (not an SSPR reset); the risk state becomes Remediated. Users who can't complete the step are blocked until an admin helps. ID Protection may also dismiss risk automatically when it later assesses a sign-in as safe.

Admin remediation options: generate a temporary password (User Administrator; from ID Protection also Security Operator), require a password change, dismiss risk (Security Operator; it doesn't change the password, so the identity isn't made safe), or Confirm compromised. After confirming compromise, request a password change, block the user if the attacker may control MFA or resets, revoke refresh tokens (and access tokens with continuous access evaluation), and disable compromised devices. Creating risk policies needs Security Administrator.

To unblock users: sign in from a familiar location or device, exclude them from the policy, or disable a misconfigured policy (dismissing risk if needed). Sign-ins blocked automatically for very high confidence risk return error 50053; unblock them by adding known company IPs as trusted locations or moving off legacy authentication. Microsoft may occasionally remediate actively attacked accounts itself, logged in audit logs with Microsoft as initiator.

Defender for Identity alerts appear under Incidents & alerts > Alerts, by default for the last seven days, and can be opened from incidents, identity and device pages, and advanced hunting. The alert page shows the involved accounts and hosts, an alert story (what happened, alert graph), important technical context, and activity details. Alerts can be assigned, commented on, moved to another incident, classified, and tuned with alert tuning rules.

Classify alerts as true positive (malicious), benign true positive (real but not malicious, such as a penetration test or an approved app), or false positive (the activity didn't happen). Consider how common the alert is and whether similar machines or users triggered it; an increase in alerts of the exact same type usually lowers their importance.

Alerts follow attack phases such as reconnaissance, compromised credentials, lateral movement, domain dominance, and exfiltration. A typical chain is reconnaissance by enumerating SMB sessions, then overpass-the-hash to reuse a stolen NTLM hash, then pass-the-ticket against an administrator, and finally commands on a domain controller, such as creating a new admin account.

Remediation actions from the identity page, side panel, advanced hunting, or Action center are Disable, Enable, Revoke session, Mark as compromised, and Force password change, depending on the account source (Active Directory, Entra ID, Okta, CyberArk, SailPoint, or connected SaaS apps). Active Directory actions run through the sensor on a domain controller using the DC's local system account, so select Automatically use the sensor's local system account in Manage action accounts (required for v3.x sensors); Entra ID actions run through a Microsoft-managed enterprise application. Analysts need a unified RBAC role with Response (manage), plus the matching Entra role for Entra ID accounts. Attack disruption uses the same actions automatically.

Microsoft Sentinel is generally available in the Defender portal, with or without other Defender services, and is supported in the Azure portal only until March 31, 2027. Workspaces first onboarded after July 1, 2025 by an Owner or User Access Administrator are onboarded to the Defender portal automatically. There, Sentinel incidents appear in Investigation & response > Incidents & alerts > Incidents alongside Defender XDR incidents, correlated across domains and enriched with Defender signals, and Security Copilot can summarize and respond. Without other Defender services, custom detection rules, the Action center, and Exposure Management are limited or unavailable.

Investigate with the same tools as any incident: the attack story and graph, unified entity pages for users, devices, IPs, and Azure resources that combine Sentinel and Defender data (including a Sentinel events tab), blast radius analysis, and Go hunt. For alerts created by an analytics rule, Run query shows related results, and results can be linked back to the incident. With UEBA, Go hunt also offers All User anomalies (preview) for user entities.

Teams still using the Azure portal connect the Defender XDR connector, which streams Defender XDR incidents and advanced hunting events into Sentinel and keeps status, owner, and closing reason in sync both ways, with deep links between portals. Some tables, such as Defender Vulnerability Management tables, aren't ingested, and Defender for Cloud incidents need the Defender for Cloud connector to include their alerts. In the Azure portal, closing an incident asks for a classification such as True Positive, Benign Positive, False Positive, or Undetermined.

Automation and case work: automation rules and playbooks run on Sentinel incidents in both portals, and incidents that span wider work can be linked to a case. Incident descriptions that come from the first alert are shown only in the Defender portal and aren't stored in the activity log or advanced hunting tables.

Copilot in Defender is available to users with provisioned Security Copilot access. Opening an incident generates a summary automatically (what happened, assets involved, timeline) in the Copilot pane, and the Copilot tab can also produce recommendations and a full incident report. Embedded skills include script analysis for obfuscated PowerShell and command lines, file analysis, device summaries (posture, unusual behavior, vulnerable software, Intune data), identity summaries, Email entity page summaries, a KQL query assistant in advanced hunting, and threat intelligence summaries. Defender Chat (preview) is a context-aware chat that can propose a multi-step plan you approve or reject.

Guided responses sort recommendations into Triage (classify as informational, true positive, or false positive), Containment, Investigation, and Remediation. Each card names the entity and reason and notes when attack disruption or AIR already acted; grayed-out actions reflect your permissions. Cards can offer Contact user in Teams, View similar incidents, or View similar emails, which opens a generated advanced hunting query. Admins can upload organization guidelines to shape the recommendations.

The Phishing Triage Agent autonomously classifies user-reported phishing as a real threat or false positive, explains its reasoning, and learns from analyst feedback. It needs Security Copilot capacity (SCUs), Defender for Office 365 Plan 2 with unified RBAC activated, Monitor reported messages in Outlook turned on, and the "Email reported by user as malware or phish" alert policy on. It skips alerts resolved by alert tuning, so disable the built-in Auto-Resolve rule for user-reported email. Setting up, pausing, or removing it needs the Security Administrator role.

Discover and deploy agents from Security Copilot > Security Store, then set them up from Security Copilot > Agents. Microsoft agents in Defender include the Security Alert Triage Agent (the Phishing Triage Agent extended to cloud and identity alerts, in preview), the Threat Intelligence Briefing Agent (scheduled briefings), the Threat Hunting Assistant (natural-language hunting that writes and interprets KQL), the Security Analyst Agent (analyses across Defender and Sentinel data), and the Dynamic Threat Detection Agent (an always-on service that raises dynamic alerts for missed threats). Partner agents need an Azure subscription Contributor or Owner role to purchase.

Defender correlates related alerts from endpoints, identities, email, cloud apps, cloud workloads, Purview, and Sentinel into incidents that tell the whole attack story: a timeline of alerts and raw events, the tactics used, impacted users, devices, and resources, a visual graph, automated investigation logs, evidence, and a summary. Correlation continues after creation and can merge incidents (see alert correlation in domain 1).

Start from the incident summary pane, then open the incident page. The attack story combines each alert's story (what happened, actions taken, related events) with the incident graph, which shows where the attack began and how far it spread and can play alerts and entities in time order. From graph entities you can review details, act (for example isolate a device or delete a file), highlight related alerts, and Go hunt. For very large incidents, filter the graph (preview) by severity, status, or service source, or hide entity types. The Alerts tab lists alerts chronologically with the reason each was linked.

For lateral movement, the identity page helps: Observed in organization shows the accounts, devices, locations, and groups tied to the identity, and the Attack paths tab and Identity Explorer visualize paths toward sensitive identities, privilege escalation, and credential access. Defender for Identity alerts often show the chain directly, such as SMB reconnaissance, overpass-the-hash, pass-the-ticket, then actions on a domain controller.

Blast radius analysis on incident graph nodes shows possible propagation paths to critical assets (it needs the Sentinel data lake and is covered with hunting graphs in domain 3). Go hunt options such as All Activity and Related Alerts find everything involving an entity, and results can be linked to the incident.

Case management lets a SOC manage its work natively in the Defender portal instead of a third-party tool. Typical uses are responding to events that span several incidents, managing threat hunts, tracking IoCs and threat actors, and tracking detection logic that needs tuning. It requires a Sentinel workspace connected to the Defender portal, and cases are visible only there, not in the Azure portal. Multitenant management can show cases across tenants.

Access comes from unified RBAC or Sentinel roles: viewing cases, tasks, comments, and audits needs Security data basics (read) or Microsoft Sentinel Reader; creating and managing cases and tasks, assigning, updating status, and linking incidents needs Alerts (manage) or Microsoft Sentinel Responder; customizing status options needs Core security settings (manage) or Microsoft Sentinel Contributor.

Open Cases to see the case queue. Each case has a priority (Very low to Critical), a status (default New, Open, Closed, starting at New, with custom statuses such as Research phase added by admins), one assignee, a description, and a due date. Case IDs start at 1000 and aren't purged, so archive with statuses and filters. Tasks give granular work an owner, status (New, In progress, Failed, Partially completed, Skipped, Completed), priority, and due date.

Link incidents to a case from the case or from an incident's details page, so hunters and responders share context in either direction, and link threat intelligence indicators (preview). The activity log holds rich-text comments and automatic audit events. Upload files on the Attachments tab; they are scanned for malware, and live samples belong in a password-protected ZIP. Comments accept up to 10 attachments (preview). Deleting a case (preview) requires typing delete to confirm. Automation rules can also use Case created and Case updated triggers through Simple Flows (preview).

Open a device page from the device inventory (Assets > Devices), an alert, or an incident, and select Timeline. It lists events and their alerts in chronological order, by default for the past 30 days; pick the past day, week, 30 days, or a custom range, and jump to a moment by highlighting part of the time bar, where arrows mark automated investigations. Search, filter by data type or event group, customize columns, and export up to seven days at a time. Retention is 90 days by default, unless events were kept longer in a connected Sentinel or Log Analytics workspace.

Selecting an event opens its details, a process tree, and, when available, a graph of related entities, and Hunt for related events opens advanced hunting with events from the same device around that time. Additional information explains outcomes such as Remediation successful, Warning bypassed by user, or Suspicious script detected, and names the alert category when an event led to an alert.

MITRE ATT&CK techniques appear as bold rows with a blue icon; selecting one shows the technique, tactic, and description, and Hunt for related events lists the underlying events. Flag the key events while you work, then filter to Flagged events to build a clean breach timeline and export it.

Some events need configuration: firewall events (5025 service stopped, 5031 app blocked from accepting connections, 5157 blocked connection) appear only with the Audit Filtering Platform Connection audit policy. A timeline event also marks when the EDR client (MsSense.exe) enters critical mode for low resources, during which it doesn't process new events. Users involved in events link to their user pages.

Response actions run along the top of a device page: manage tags, isolate device, restrict app execution, run antivirus scan, collect investigation package, initiate live response session, initiate automated investigation, and others. Each action is recorded in the Action center and the device timeline. They need the Active remediation actions role and access to the device's device group.

Isolate device disconnects the device while keeping its link to the Defender for Endpoint service; selective isolation (Windows 10 version 1703 or later, Windows 11, macOS) can keep Outlook and Teams working. Isolation lifts automatically after seven days, offline devices are retried for up to three days, and isolating a Hyper-V host blocks its child VMs. Use selective isolation with web proxies, and split-tunnel VPNs. Restrict app execution applies a code integrity policy so only Microsoft-signed files run (needs Microsoft Defender Antivirus). Contain device is for devices that aren't onboarded: every onboarded device blocks traffic with it, even if its IP changes; Microsoft recommends no more than 100 at a time.

An investigation package is a zip of forensic data. On Windows it includes Autoruns (auto-start registry entries), installed programs, network connections (active connections, ARP and DNS cache, IP configuration, firewall logs), prefetch files, processes, scheduled tasks, the Security event log, services, SMB sessions, system information, temp directories, users and groups, and a CollectionSummaryReport.xls. Download it from the Action center. Collection can fail on low battery or a metered connection.

Live response opens a remote shell (turned on in Advanced features, with separate switches for servers and unsigned scripts). Basic commands inspect: dir, processes, services, scheduledtasks, persistence, registry, connections, fileinfo, findfile, and getfile (up to 3 GB). Advanced commands act: run a library script, putfile, remediate and undo, isolate and release, collect, analyze, and scan. Scripts (PowerShell or Bash) must be uploaded to the library first (up to 250 MB per file); uploading from the session needs Manage Security Settings, or use the Library management page. Downloads can run in the background by adding & after a getfile command.

A file page shows details and PE metadata, prevalence (devices in the last 30 days, first and last seen, VirusTotal ratio, antivirus detection), incidents and alerts, Observed in organization (devices with up to six months of history, cloud apps with 30 days), file names used, and file content and capabilities mapped to MITRE ATT&CK if Microsoft analyzed it. Prevalence respects your RBAC device scope. Reach it from search, alert process trees, the incident graph, or the device timeline.

File actions: Stop and quarantine file stops processes, quarantines the file, and removes persistent data such as registry keys on devices that saw it in the last 30 days (up to 1,000 devices, with a 3-day timeout for offline devices; Microsoft-signed and trusted publisher files are excluded, and the file can be restored). For wider or lasting blocking, Manage indicator adds a Block indicator. Download file, Collect file, Go hunt, and Deep analysis (runs the file in a cloud sandbox and returns a behavior report) round out the page. Actions on PE files need Alerts investigation or Live response advanced; non-PE files need Live response advanced.

An IP address page shows geolocation and ISP, related alerts, devices that communicated with it (up to 100), and prevalence over a selectable period (30 days by default). Search returns only IPs observed with your devices. A URL or domain page shows the Microsoft threat intelligence verdict, related incidents and alerts over 180 days, device prevalence over 30 days, and Devices, Emails, and Clicks tabs; a domain page aggregates all URLs under that fully qualified domain name. Submit a verdict you disagree with to Microsoft.

A user account page shows related incidents and alerts, Defender for Identity alerts, SID, role, logon types, and the devices the account logged on to (Observed in organization), which helps spot lateral movement between devices. From any entity, Go hunt and the device timeline let you pivot to raw events.

A disrupted incident shows an Attack Disruption tag with the threat type (for example, ransomware), a highlighted notification under the title, and labels on suspended users and contained devices in the graph. The tags also appear in incident email notifications. A summary card on the right lists the automatic actions since the first alert, with View activities (the Activities tab) and View related assets (endpoints, accounts, mailboxes, and apps acted on).

Investigate the full attack story before undoing anything; releasing too early lets the attacker resume. To restore an asset, select it and choose release from containment (device) or enable user (account), or do it from the action details pane in the Action center, which lists disruption actions with automatic and manual ones. Undoing a Contain user action needs Global Administrator, and users contained by disruption are released automatically within five days.

The Activities tab's Policy status column (preview) shows whether each disruption or predictive shielding policy is still enforced: Active, Inactive (for example, a user was released), Not applicable, or No status. Filter Performed by to AttackDisruption and Activity status to Completed. Unlike the Action center, which logs past actions, this shows current state.

DeviceEvents
| where ActionType contains "ContainedDevice"

Audit (Standard) is on by default and records thousands of activities across Microsoft 365 services, kept for 180 days. Search it in the Purview portal (Audit), with Search-UnifiedAuditLog in Exchange Online PowerShell, the Audit Search Graph API, or the Office 365 Management Activity API, and export results to CSV. Audit (Premium) adds one-year default retention for key workloads such as Exchange, SharePoint, and Microsoft Entra ID for E5-licensed users, audit log retention policies, intelligent insight events, and about twice the Management Activity API bandwidth. Ten-year retention needs a per-user add-on and isn't retroactive. Non-user records (service principals, system events) are kept for one year.

Searching needs the Audit Logs or View-Only Audit Logs role. Core service records usually appear 60 to 90 minutes after the activity. A search job can cover up to 180 days (default seven), with filters for activities (friendly or exact operation names), record types, users, files, folders, sites, workloads, and administrative units. Each user can run 10 jobs at once (one unfiltered); jobs keep running after you close the browser, completed jobs are kept 30 days, and broad searches in large tenants can take up to 48 hours. Exports hold up to 50,000 rows (Standard) or 1,000,000 (Premium). Admins scoped to administrative units see only their units' user activity.

MailItemsAccessed (Premium) shows mailbox access: Bind records each message opened, Sync records bulk downloads such as Outlook syncing a folder. Duplicate records within an hour are filtered unless properties like client IP or session change. Logging throttles after 1,000 bind events in 24 hours; throttled records show IsThrottled and don't backfill, so use message trace or sign-in logs for gaps. Other Premium events: Send (messages sent or replied to) and SearchQueryInitiatedExchange and SearchQueryInitiatedSharePoint (search terms, not throttled). Premium events log only for licensed users from enablement onward.

Audit log retention policies (Organization Configuration role, up to 50 per organization) keep records by service, activity, or user for 7 days to 10 years; 7- and 30-day options need E5, and 3 years or longer needs the 10-year add-on. Priority 1 is highest, and custom policies override the default policy, which keeps Exchange, SharePoint, OneDrive, and Entra records for a year for E5 users.

Microsoft retired the classic eDiscovery experiences, including classic Content search, on August 31, 2025 (except for 21Vianet-hosted tenants). All Content Search functionality now lives in eDiscovery in the Microsoft Purview portal, including a system-generated Content Search case available to eDiscovery Manager and Administrator role group members. Cases are the central unit and hold searches, holds, review sets, and exports; statistics replace the old collection estimates, and searches can be edited even after results go to a review set.

Permissions: the eDiscovery Manager role group has two subgroups. eDiscovery Managers can create cases, search, preview, and export, but access only cases they create or are added to. eDiscovery Administrators can do all of that plus access every case, configure settings, and remove case members; keep that group small. Premium features such as review sets need E5 or an equivalent add-on for the users whose data is analyzed.

Create a search in a case (or the Content Search case), add data sources (mailboxes, OneDrive, SharePoint, Teams, Microsoft 365 Groups, Viva Engage, with options like a user's manager or frequent collaborators), and add conditions. KeyQL tips: searches use UTC; keywords aren't case-sensitive, but AND, OR, NOT, and NEAR must be uppercase and work only in the KeyQL condition field; a space between terms acts as OR; only prefix wildcards (reorg*) work; use -from: to exclude, kind:email or kind:microsoftteams to filter item types, and a trailing / on path: to match one site. An empty keyword condition returns everything.

Run statistics to see hits, locations (retry failed ones), top data sources, keywords, sensitive information types, item types, and communication participants, then review a sample. Statistics expire after 14 days. When the results look right, export them or add them to a review set. In an email attack, Content search also supports searching for and deleting the malicious messages.

Microsoft Graph activity logs are an audit trail of all HTTP requests Microsoft Graph receives and processes for your tenant, whether from line-of-business apps, API clients, SDKs, AI clients using the Microsoft MCP Server for Enterprise, or Microsoft apps such as Outlook and Teams. Use them to see what apps you consented to are doing, find activity by a compromised user or app, detect unusual API use, investigate unexpected permission grants, spot apps with extreme call volumes, and correlate requests with sign-ins.

Turn them on with a diagnostic setting in Azure Monitor that sends them to a Log Analytics workspace (such as your Sentinel workspace), an Azure Storage account for long-term storage, or Event Hubs for an external SIEM. You need Microsoft Entra ID P1 or P2, and Security Administrator is the least privileged role that can set it up. You can't filter the logs in the diagnostic setting; reduce cost with a workspace transformation or the Basic plan. Events usually arrive within 30 minutes, occasionally up to 2 hours, and cover only your own tenant.

In Log Analytics the data is in MicrosoftGraphActivityLogs. Key columns: AppId, ServicePrincipalId, and UserId (who called), RequestMethod and RequestUri (what was requested), ResponseStatusCode (result), IPAddress, UserAgent, Location, Scopes and Roles (token claims), and SignInActivityId (the sign-in behind the token). Custom detections in the Defender portal can run continuously on this table.

MicrosoftGraphActivityLogs
| where TimeGenerated > ago(3d)
| where ResponseStatusCode == 401 or ResponseStatusCode == 403
| where RequestUri contains "/groups"
| summarize count_distinct(RequestId) by AppId, UserId

Endpoint (Defender for Endpoint) tables: DeviceProcessEvents (process creation and command lines), DeviceNetworkEvents (network connections), DeviceFileEvents (file system), DeviceRegistryEvents (registry), DeviceLogonEvents (sign-ins on devices), DeviceImageLoadEvents (DLL loads), DeviceEvents (many event types, including antivirus and exploit protection), and DeviceInfo and DeviceNetworkInfo (device properties).

Email and collaboration (Defender for Office 365) tables: EmailEvents (delivery and blocking, with DeliveryAction, ThreatTypes, and NetworkMessageId), EmailUrlInfo (URLs in email), EmailAttachmentInfo (attachments), EmailPostDeliveryEvents (post-delivery actions such as ZAP), and UrlClickEvents (Safe Links clicks from email, Teams, and Office apps, with IsClickedThrough). Join email tables on NetworkMessageId.

Identity and cloud tables: IdentityLogonEvents (authentication on Active Directory and Microsoft online services), IdentityDirectoryEvents (domain controller events), IdentityQueryEvents (AD object queries), IdentityInfo (account information), EntraIdSignInEvents (Entra ID sign-ins), CloudAppEvents (Office 365 and cloud app activity), and GraphAPIAuditEvents (Microsoft Graph requests). Alerts: AlertInfo (one row per alert with severity, source, and techniques) and AlertEvidence (entities per alert), joined on AlertId.

Event data arrives almost as soon as sensors send it; entity tables such as IdentityInfo and DeviceInfo refresh hourly. Use the in-portal Schema reference for columns, ActionType values, and sample queries. With Sentinel onboarded, its analytics-tier tables can be queried in advanced hunting too.

A query names a table (or union of tables) and pipes it through operators. where filters rows (use ago() for time, in or in~ for lists, has for whole terms, contains for substrings), project selects or renames columns, project-away removes columns, extend adds calculated columns, top and take or limit trim results, and count returns the number of rows. let binds a name to a value, list, or subquery for reuse. Times are UTC.

SigninLogs
| where ResultDescription has "Invalid password"
| summarize applicationCount = dcount(AppDisplayName) by UserPrincipalName, IPAddress
| where applicationCount >= 3

union returns rows from several tables (wildcards like union Security* work, and withsource adds a column naming the source). join merges rows on matching columns. The default flavor, innerunique, keeps one left row per key; kind=inner returns every match; leftanti returns left rows with no match; leftouter keeps all left rows. Reference columns as $left.Column and $right.Column when names differ.

To pull values from text, parse or parse_json are preferred over regular expressions (extract, matches regex), which cost more. Common hunting patterns include counting failures per account and IP, finding the latest event per device, joining email to endpoint events within a time window, and comparing periods with let variables.

Advanced hunting (Investigation & response > Hunting > Advanced hunting) queries Defender for Endpoint, Office 365, Cloud Apps, Identity, and onboarded Sentinel data. Guided mode offers a query builder; advanced mode is for writing KQL. The same queries can become custom detection rules. Access: Security data basics (read) covers alerts and behaviors tables; Email & collaboration metadata (read), or roles such as Security Reader, covers email tables; Microsoft Entra roles such as Security Reader and Global Reader grant read to all data; endpoint data follows Defender for Endpoint RBAC.

Limits per query: 30 days of native Defender XDR data (Sentinel tables follow their analytics-tier retention; data only in the data lake isn't available), 100,000 rows, 10 minutes, and 64 MB of results. Tenants have a CPU quota measured every 15 minutes; at 100% queries are blocked until the next cycle. The query resources report (from Advanced hunting or Reports) shows the last 30 days of queries by interface, user or app, resource usage, and state. Extend retention by onboarding Sentinel or streaming data out.

Best practices: size new queries with count and use take or limit; filter time and other conditions early; use has rather than contains; scope search to named tables (search in); filter table columns rather than calculated columns; avoid terms of three characters or fewer; project needed columns; use the smaller table on the left of a join with time filters on both sides; use join and summarize shuffle hints for high-cardinality keys.

Save queries to Shared queries (whole organization) or My queries (private), share a direct link, or start from Community queries reviewed by Microsoft researchers. From results, view charts, drill into entities, and take actions: device actions (isolate, collect package, scan, initiate investigation, restrict app execution) need DeviceId; file quarantine uses SHA1 or SHA256 columns plus DeviceId; identity actions need AccountSid or AccountObjectId; email actions need the Email & collaboration advanced actions permission.

Threat analytics provides reports from Microsoft security researchers on active threat actors and campaigns, attack techniques, critical vulnerabilities, attack surfaces, and malware, plus curated open-source intelligence (OSINT). Open it from the Defender portal navigation or its dashboard card. The dashboard shows Latest threats, High-impact threats (most active and resolved alerts), and Highest exposure threats, and reports can be filtered by threat tags (Ransomware, Phishing, Activity group, Vulnerability) and categories such as Actor or OSINT.

Each report has an Overview (aliases, origin, targets, MITRE techniques, and charts of related incidents, alerts over time, impacted assets, recommended actions, and exposure), the Analyst report (attack chain, recommendations, and hunting guidance), Related incidents, Impacted assets (devices, users, mailboxes, apps, cloud resources), Endpoints exposure (vulnerable devices and security update status from Defender Vulnerability Management), Recommended actions (only mitigations tracked in Secure Score), and Indicators (preview, for verified tenants).

Exposure level combines how severe the threat's vulnerabilities and misconfigurations are with how many devices have them. Misconfigured devices and Vulnerable devices show Not available when researchers haven't linked recommendations or vulnerabilities. Resolved alerts over time show how quickly your team responds.

Access needs a license for at least one Defender product (Defender for Endpoint Plan 1 alone doesn't count). Security data basics (read) shows reports, incidents, alerts, and assets; Vulnerability management (read) and Exposure Management (read) add exposure and recommended actions; you see each product's data only with that product and role. Stay current with the Threat Intelligence Briefing Agent, email notifications for report updates, and custom detections linked to reports so their incidents appear on the Related incidents tab.

The hunting graph lives in advanced hunting (the hunting graph icon, or Create new > Hunting graph) and needs the Microsoft Sentinel data lake plus at least read access to Security Exposure Management. It shows entities such as devices, accounts, and IP addresses as nodes and their relationships as edges, helping reveal paths and choke points that tabular queries miss.

Start with a predefined scenario, which is a prebuilt advanced hunting query: for example Attack paths to critical asset, Entity relationship map (direct connections of one entity), Paths between two entities, Access to key vaults, Users with access to sensitive data, Paths to domain admins, Kerberoast paths to critical assets, and Choke points to SQL data stores. Enter the required inputs, filter by MITRE technique, apply filters (Show only the shortest paths; source node is critical, vulnerable, or exposed to the internet; target node has sensitive data; edge types such as has permissions to or can authenticate as; edge direction), then select Run scenario and explore nodes and edges.

Blast radius analysis extends the incident graph. Select a node and choose View blast radius to see the top eight attack paths from that node to predefined critical targets, with View full blast radius list for all reachable targets and each path's details. Hide blast radius returns to the incident graph. It needs Sentinel data lake onboarding and Exposure management (read) or higher, and replaces attack path analysis in incidents.

Read blast radius with care: paths are possible, not certain, and based on known attack vectors; they're bounded in hops (up to five for cloud or on-premises, three for hybrid, within a seven-hop overall bound); they show only nodes your RBAC scope allows; recent changes may not be reflected yet; and results depend on how completely critical assets are defined.

Microsoft Sentinel graph is the graph analytics layer of the Sentinel platform. It represents users, devices, cloud resources, data flows, activities, and attacker actions as nodes and edges, so defenders and AI agents can answer questions that are hard with tables, such as what an attacker could reach from a compromised account or a compromised document's blast radius, across pre-breach and post-breach stages.

Experiences built on it: blast radius in the Defender incident graph, the hunting graph in Defender advanced hunting, the data risk graph in Purview Insider Risk Management, and the data risk graph in Purview Data Security Investigations. Attack path features in Microsoft Security Exposure Management and Defender for Cloud provide related pre-breach recommendations.

To enable it for Defender, onboard to the Sentinel data lake, which enables the lake and graph; if you already have the data lake, the hunting graph and blast radius are provisioned automatically when you sign in to the Defender portal. Purview graph experiences are set up within those solutions.

Custom graphs (preview) model your own scenarios from data lake and non-Microsoft data: author the graph in a Jupyter notebook with the Sentinel extension for Visual Studio Code, publish and materialize it with a graph job, then query and visualize it with Graph Query Language (GQL) on the Graphs page in the Defender portal. On-demand graph jobs keep a graph for 30 days; scheduled jobs rebuild it on your schedule. Custom graphs are billed under the Sentinel graph meter.

Open Microsoft Sentinel > Threat management > Hunting and the Queries tab. It lists hunting queries from installed Content hub solutions and your own, grouped by MITRE ATT&CK tactic with techniques shown. Run all or selected queries, then sort or filter by Results, Results delta, or Results delta percentage (the last 24 hours versus the previous 24–48 hours) to find spikes. N/A means required data sources aren't connected. Favorite queries run each time the page opens. Microsoft suggests running hunting queries at least weekly before incidents occur.

Create a query with New query: add the KQL, entity mappings, and MITRE tactics and techniques, then Create. Clone any query to customize it; only custom-source queries can be edited, while solution queries must be edited in their content source. When a query proves valuable, select New alert rule > Create Microsoft Sentinel alert to open the analytics rule wizard with it, or build a custom detection.

Bookmarks preserve selected result rows with their query, tags, notes, entity mappings, and MITRE techniques; they're shared with teammates, can be investigated in the investigation graph (with at least one mapped entity), and can create or be added to incidents. Bookmark data is in the HuntingBookmark table. New bookmarks can be created only in the Azure portal; the Defender portal shows existing ones, and advanced hunting has no bookmarks. The Bookmarks tab shows up to 1,000 bookmarks.

Hunts (preview) organize a hypothesis-driven investigation: queries, bookmarks, UEBA entity context, comments, and the analytics rules, threat indicators, and incidents created from findings, with status and metrics. They need Microsoft Sentinel Contributor or a custom role with hunts permissions. Livestreams are no longer available; use KQL jobs, analytics rules, or playbooks to monitor and notify during an active attack.

KQL jobs are asynchronous KQL queries, run once or on a schedule, over the Sentinel data lake and federated tables (such as Microsoft Entra ID, Microsoft 365, and Microsoft Resource Graph, queried without ingestion). Uses include long investigation queries, aggregation for enrichment, historical threat intelligence matching, anomaly scans, and promoting data from the lake to the analytics tier, where advanced hunting can query it. For ad hoc queries, use Microsoft Sentinel > Data lake exploration > KQL queries.

Create a job from the KQL query editor (Create job) or Data lake exploration > Jobs, or from a template (hunting, baseline, and anomaly detection templates). Give it a unique name (up to 256 characters, no # or -), choose the destination workspace (System tables or a Sentinel workspace) and a new or existing table, write the query and select source workspaces (union across workspaces by default; workspace("name").Table for one), then choose one time or a schedule (by minute, hourly, daily, weekly, monthly), starting at least 30 minutes after creation. Editing a one-time job runs it again.

New analytics-tier tables end in _KQL_CL; new tables in System tables end in _KQL. Creating analytics-tier tables requires Log Analytics Contributor for the data lake managed identity (msg-resources-<guid>), and creating and scheduling jobs requires Microsoft Entra roles such as Security Operator. Analytics storage costs more, so project and filter before promoting. Results can't go to federated tables, and some standard columns are overwritten on export; TimeGenerated older than two days is overwritten, so keep the source time in another column.

let lookback = 15m;
let delay = 15m;
let endTime = now() - delay;
let startTime = endTime - lookback;
CommonSecurityLog
| where TimeGenerated between (startTime .. endTime)

Summary rules run a KQL aggregation in the background at a set frequency and write results to a custom log table with the Analytics plan. They make analysis and reports over large data sets fast, cut costs by keeping verbose data in a cheaper tier while analyzing only summaries, and can remove or obfuscate private details in shareable summaries. They can read Analytics or Basic tables, including data kept in lower-cost tiers.

Create them at Microsoft Sentinel > Configuration > Summary rules (Defender portal, after onboarding) with Microsoft Sentinel Contributor. Set a name, a destination table (existing, or new as <tableName>_CL), the summary query (Preview results to check it), the frequency, an optional delay, and a start time. Enable the SummaryLogs diagnostic setting to see run history and failures (it adds cost). From the rules list you can view current data, see run history, disable or enable, edit, or delete (irreversible). Templates come from the Content hub (content type Summary rules) and appear on the Templates tab.

Query design: each run processes one bin defined by the bin size, so don't add a time filter (it would intersect with the bin). Rules process recent data only, up to 24 hours per bin, not historical ranges. Aim for results that are a tiny fraction of the source, keep records under 1 MB, and use a smaller bin size if a query nears limits. Destination tables add _RuleName, _BinSize, and _BinStartTime columns. A workspace can have up to 100 active rules, and union * isn't supported.

Scenarios: to find a malicious IP across 90 days of huge network logs (even beyond workspace retention), summarize IP addresses with first- and last-seen times daily, then run fast analytics rules or searches on the summary. To match threat intelligence against noisy firewall logs, summarize key fields with a lookup against indicators into a table such as MaliciousIPDetection and alert on that table.

Data lake notebooks run in Visual Studio Code with the Microsoft Sentinel extension, using PySpark. After onboarding to the data lake, sign in through the extension, browse lake and federated tables, and create a notebook. The MicrosoftSentinelProvider class (from sentinel_lake.providers) reads tables with read_table() and writes results to the lake or analytics tier with save_as_table(). Choose a runtime pool: Small for testing and light work, Medium for joins, aggregations, and ML training, Large for deep learning and very large jobs. Sessions take 3–5 minutes to start and time out after 30 minutes by default.

Notebooks suit analyses that are hard in KQL alone: baselines of failed sign-ins, sensitive data access paths, anomaly and risk scoring, and reconstructing attack timelines, including low-and-slow attacks. Schedule notebook jobs from the extension to run on a schedule or on demand, with parameters, writing to custom tables. Job and write permissions come from Microsoft Entra roles such as Security Operator, or Azure RBAC per workspace; creating analytics tables needs Log Analytics Contributor for the data lake managed identity.

Classic Sentinel notebooks run on Azure Machine Learning (you need access to both workspaces) and use MSTICPy, the Microsoft Threat Intelligence Center library that queries multiple sources, enriches with threat intelligence and geolocation, extracts indicators and decodes data, detects anomalous sessions, and visualizes timelines and process trees.

The Microsoft Sentinel MCP server is a hosted Model Context Protocol server, using Microsoft Entra for identity, whose tool collections let AI clients explore data lake data and analyze entities in natural language, build Security Copilot agents, and triage and hunt. Collections include data exploration (https://sentinel.microsoft.com/mcp/data-exploration), Security Copilot agent creation, and triage. Add them in Visual Studio Code (the MCP host), Security Copilot, Copilot Studio, or Microsoft Foundry. Most tools need data lake onboarding, and listing and invoking tools needs the Security Reader role. Custom MCP tools can expose saved advanced hunting queries; turning off access requires support.