Microsoft Security Operations Analyst SC-200 (SC-200) — Questions 1126–1200

Automation rules in Sentinel are the correct choice because they let you define conditions and run actions when an incident is created or updated, including updating fields and setting tags. By configuring a rule that stamps the incident's 'Created' time and another that records when the incident transitions to 'In Progress' or is assigned, you can capture the exact response start time. This information is stored in the incident's properties and can later be queried to compute time-to-respond, directly enabling monitoring of response times.

Alert suppression is a native analytic rule setting in Microsoft Sentinel that prevents duplicate alerts by silencing the rule for a defined period after the first alert fires. When the same events or query results are processed in subsequent scheduled runs within that period, no new alert or incident is created. This is the most efficient method because it eliminates duplication at the source, reducing noise without consuming automation resources or requiring custom KQL logic.

DeviceProcessEvents is the correct table because it captures process creation events on endpoints, and its ProcessCommandLine column stores the exact command line used to launch each process. This includes the PowerShell executable path, individual arguments, flags like -EncodedCommand or -ExecutionPolicy Bypass, and any obfuscated script text. The table also provides process ID, parent process, and initiating process command line, which are crucial for gaining full context on the suspicious PowerShell invocation during a threat hunt.

The Microsoft Defender XDR portal is the central console for investigating alerts and incidents across the Microsoft 365 Defender suite. The first step in any incident response is to verify the alert's validity by examining the evidence, related entities, and the incident timeline. Classifying the alert as a true or false positive determines whether subsequent containment, eradication, or closure actions are necessary, making this the correct initial action.

Assigning a Security Baseline policy in Microsoft Intune to the device groups is the correct mechanism because security baselines are pre-defined collections of recommended security settings (e.g., from Microsoft's security baseline for Windows) that Intune applies and then evaluates against each device. The Intune console provides a 'Security Baselines' node that shows per-device compliance status, listing every setting that deviates from the baseline version you assigned. This gives you the exact report of compliance against a security baseline, including the ability to compare against different baseline versions.

Microsoft Sentinel UEBA uses proprietary machine learning to build behavioral baselines for entities such as users, and it requires at least 14 days of historical telemetry before it can produce analytical timelines. If a user is newly on-boarded or has only sporadic log activity, the available data does not meet that minimum threshold, so no anomaly or timeline appears. This is a documented prerequisite, not a configuration error or a connectivity problem.

The 'processes' command enumerates running processes on the target device, returning process names, IDs, and related details. This satisfies the forensic requirement to capture volatile evidence of active processes before the compromised Windows host is remediated or shut down.

DeviceProcessEvents is the correct table because it records every process creation event, including the process ID, parent process, command line, and execution timestamp. In a KQL hunt for RDP-initiated connections, you can join DeviceProcessEvents with DeviceNetworkEvents on ProcessId and filter for RemotePort 3389 to pinpoint the exact process that launched the RDP session. Without these process-creation details, you cannot establish the process-to-network correlation required to answer the question.

Querying SigninLogs provides critical identity context: each authentication event records timestamp, source IP, user agent, risk level, and applied conditional access policies. By filtering this table for the account around the alert timestamps, an analyst can determine whether the account actually authenticated during the alert's activity window and from which location, directly linking the alerts to a known sign-in session. This correlation is fundamental for validating whether the alerts represent genuine account compromise or a false positive triggered by a legitimate user action.

Because the user holds administrative privileges, credential reset alone is insufficient — active refresh tokens and sessions must be revoked in Microsoft Entra ID to evict the attacker immediately. This contains the compromised privileged identity before any further investigation, satisfying the stem's requirement to act first.

Advanced Hunting is the Microsoft 365 Defender tool purpose-built for proactively querying across deep time series and event tables via KQL, including DeviceProcessEvents, DeviceEvents, and associated network/file events. With schema-aware queries such as process parent-child joins, an analyst can pivot from a suspicious PowerShell process to its parent chain, command-line, file hashes, and related lateral-movement indicators. This makes it the correct surface for ad-hoc threat hunting and validating a specific suspicious process observed in the environment.

ParentProcessId is the process identifier of the process that created the current process; it directly represents the immediate parent in the process tree. By filtering on this field, an analyst can quickly isolate all child processes spawned by a suspected malware process, enabling lineage-based detection. This is the correct field for defining direct process ancestry, unlike ProcessId or LogonId.

Microsoft Defender for Endpoint's device isolation severs all network connectivity except to the MDE cloud service, instantly breaking command and control channels and laterally used protocols such as SMB and RDP. Because isolation is enforced at the operating system's network stack, it does not rely on killing a process that may simply respawn or on user compliance. This action also preserves volatile memory and active connections for subsequent forensic analysis, making it the preferred first response to a compromised, actively communicating endpoint.

This is correct because the rule groups alerts into a single incident when all entities match within the 5-hour lookback. The entitiesMatchingMethod is All, and lookbackDuration is 5 hours, so only alerts that share every entity value (such as account, host, and IP) in that window will be merged. This consolidates related alerts while minimizing the chance of grouping unrelated activity, and the same incident can be reopened or updated as more matching alerts arrive.

In Defender for Cloud, the Vulnerability assessment settings let you enable an integrated partner solution such as Qualys or Rapid7; after selecting the partner, you install the designated scanner agent on each virtual machine. The scanner transmits identified vulnerabilities to Defender for Cloud, which ingests them into the recommendation 'Vulnerabilities in your virtual machines should be remediated' and includes them in the secure score and regulatory compliance assessments. This is the only mechanism that directly integrates the existing third-party tool's findings into Defender for Cloud.

Automated investigation and response (AIR) is a core feature of Microsoft Defender XDR because it enables the platform to orchestrate playbooks across email, endpoints, identities, and cloud apps following an alert trigger. When a suspicious entity is detected, AIR automatically runs investigations, pauses or blocks malicious activities, and takes remediation actions such as quarantining files or disabling accounts — all while keeping security teams informed via the Action Center. This cross-product automation is what distinguishes XDR from individual Defender products, and it is explicitly listed as a primary capability of Defender XDR. The process uses AI-driven assessments to determine whether a threat is malicious, and it helps contain breaches before human analysts can intervene.

The Recommendations blade in Microsoft Defender for Cloud is the single, central pane that gathers every security recommendation for your organization's resources. It lists recommendations with severity, affected resources, remediation steps, security control, and impact on your secure score, enabling immediate triage and action. This is exactly the page needed to simply view security recommendations, so it is the correct answer.

DeviceNetworkEvents, ingested via Microsoft Defender for Endpoint, records inbound and outbound connection attempts with initiating process and remote IP. This connection-level telemetry exposes the internal host-to-host traffic patterns that characterise lateral movement, satisfying the stem's threat-hunting requirement.

This is the correct interpretation because the query explicitly filters for high-severity alerts within the last 24 hours using `where Severity == "High"` and `where TimeGenerated > ago(24h)`, then groups by `AlertName`. The `summarize count() by AlertName` computes the occurrence frequency for each alert name, and the subsequent `where count_ > 10` (or `having count_ > 10`) enforces the threshold. The result is exactly the set of high-severity alert names observed more than 10 times in the specified period.

The Incident graph is a dedicated visualization that maps the full attack story by showing nodes for entities such as devices, users, and alerts, and edges representing causal relationships and movement. It automatically aggregates related alerts from the merged incident and provides a timeline-based view of how the attacker entered and expanded across the environment. This allows the analyst to identify the attack path and affected scope at a glance.

Microsoft Defender XDR automatically correlates alerts into incidents when incident creation is enabled and alerts are not suppressed. Ensuring these settings are correct allows high-severity alerts from Defender for Endpoint to generate incidents, meeting the requirement.

Disabling the user account in Microsoft Entra ID is a valid containment step because it immediately prevents any further authentication attempts using that identity, cutting off the attacker's current access path to cloud applications, Microsoft 365, and other Entra ID-integrated resources. This reversible, non-destructive action preserves all user data and activity logs for forensic analysis while stopping ongoing malicious activity. It is one of the first actions an incident responder should take when a user identity is known to be compromised.

In Microsoft Sentinel, an automation rule can be triggered when an incident's status changes to Closed, and its 'Close alert' action explicitly resolves all linked alerts. This ensures that the security operations team does not have to manually close each alert and that the alert-state lifecycle matches the incident-state lifecycle. Conditions such as severity, owner, or tactic can also be applied, making this the correct, supported mechanism to accomplish the goal.

DeviceTvmSoftwareVulnerabilities is the Threat & Vulnerability Management (TVM) table containing one row for each software vulnerability detected on a device, with fields such as CveId, DeviceId, SoftwareVendor, SoftwareName, SoftwareVersion, and exploitability/severity information. Filtering on a specific CveId returns every affected device, which is exactly the required result. This makes it the canonical and correct data source for the analyst's query.

SecurityIncident is the correct table because it stores the definitive incident records that a SOC triages, and CreatedTime is the standard timestamp column indicating when an incident was generated. Filtering with ago(7d) limits results to the last seven days, while summarize count() by SubscriptionId groups the incidents by the Azure subscription containing the affected resources, directly satisfying the manager's request to see incident counts per subscription.

This query precisely identifies NTLM network logons by combining EventID 4624, LogonType 3, and LogonProcessName containing 'NTLM', which is the signature of pass-the-hash authentication. The `TargetUserName !endswith '$'` filter removes machine accounts, and the `Computer !in (list of domain controllers)` exclusion eliminates the large volume of legitimate DC-to-DC NTLM activity, leaving only suspicious user logons from non-DC hosts. By projecting TimeGenerated, Account, SourceWorkstation, and LogonProcessName, it retains the forensic context needed for incident investigation, making it the correct detection for PtH lateral movement.

Microsoft Purview data access logs are the authoritative source for item-level access events in Office 365, recording details such as the specific document downloaded, the user identity, the timestamp, and the device or client IP. These logs are generated by Purview's content discovery and classification pipeline and capture both interactive and background access by apps or users. For an attacker exfiltrating sensitive files, these logs provide the precise chain of access needed to confirm what data was compromised, so this is the correct choice for the investigation.

The activity log records every user action and sign-in event with source IP, location and timestamp, letting analysts correlate the impossible-travel sign-ins and trace subsequent suspicious activity. It directly satisfies the requirement to investigate an account authenticating from multiple geographic regions within a short window.

This is the correct approach because Microsoft Defender for Endpoint device groups support rule criteria based on device tags, and device tags can be assigned centrally via Group Policy or Intune. By tagging all Contoso devices with the same device tag and creating a device group rule that matches that tag, you automatically assign the correct devices and keep the group in sync as new devices are onboarded. This is dynamic and scalable, avoiding manual, one-off reconfiguration.

DeviceNetworkEvents with RemotePort 3389 and ActionType 'ConnectionSuccess' captures successful RDP sessions, and summarising dcount(RemoteIP) by DeviceName surfaces devices connecting to many distinct internal addresses — exactly the fan-out pattern the stem's lateral movement hunt requires.

Azure Active Directory (Microsoft Entra ID) audit logs are a first-party data source for Sentinel. The built-in Microsoft Entra ID connector ingests both sign-in logs and audit logs through the Microsoft Graph API after you enable diagnostic settings to stream them to Sentinel. This integration gives security teams identity-related telemetry such as sign-in failures, password changes, and conditional access activity without extra infrastructure.

Playbooks are Azure Logic Apps that can integrate with external systems through connectors, enabling actions like sending email, creating tickets, or posting to chat. An automation rule can be configured to run a playbook automatically when an incident is created or updated, providing a scalable and customizable response. This design correctly separates detection (analytics rule) from orchestration (automation rule + playbook) and is the standard pattern for complex actions.

Microsoft Sentinel Responder is one of the two built-in Sentinel-specific roles that can manage the day-to-day operational tasks within the product. It allows the assigned user to view and manage incidents, triage alerts, and execute playbooks when responding to threats, while intentionally omitting resource-creation permissions. This makes it the appropriate role for security operations analysts who need to act on active detections without reconfiguring the overall Sentinel environment.

Disabling compromised accounts in Microsoft Entra ID immediately revokes authentication, blocking the attacker from re-entering the environment via cloud or hybrid identity paths. This directly satisfies containment by stopping lateral movement and further compromise while investigation continues, rather than merely detecting or documenting the incident.

Deploying the Qualys agent on every Virtual Machine is mandatory because Defender for Cloud uses that agent to collect and transmit vulnerability data to the Qualys cloud service. After installation, the solution must be registered under Defender for Cloud's Vulnerability assessment settings, which patches the security policy with the associated plan. Once configured, the Qualys findings appear in the 'Vulnerabilities in your virtual machines should be remediated' recommendation, and auto-provisioning can later be enabled for new VMs.

Guest configuration (Azure Policy) is the correct mechanism because it deploys the guest configuration agent into the VM or Arc-enabled machine to audit and remediate settings inside the guest OS. It can apply policy definitions that target local accounts, including disabling unused or default accounts, using PowerShell Desired State Configuration. With the DeployIfNotExists effect, the policy can automatically apply the remediation, making it the only option that physically changes the local account state.

Microsoft Defender for Endpoint's device isolation applies an OS-level network security policy at the client that blocks all inbound and outbound traffic other than the Defender service itself, effectively severing the ransomware's command-and-control channel and preventing further server-side or lateral encryption. This is the immediately effective containment action because it does not rely on terminating the process or cleaning files first. The SOC can then inspect processes, stop the malicious binary, and later restore data from backup in a clean state.

Defender for Containers provides advanced runtime threat detection that analyzes Kubernetes audit logs and container activity using behavioral analytics. It specifically identifies container runtime threats such as privilege escalation inside a container, container breakouts, and suspicious process execution. This capability to generate actionable, security alerts is the core value of the plan and distinguishes it from static policy enforcement or raw log ingestion.

The Vulnerability Assessment findings blade in Microsoft Defender for Cloud is the dedicated destination for aggregated scan results from integrated vulnerability assessment solutions, such as Microsoft Defender Vulnerability Management or Qualys, across Azure VMs, hybrid machines, and container images. It lists each discovered CVE with its severity, affected resource, and step-by-step remediation guidance, so an analyst investigating a specific vulnerability finding would open this blade to view and act on the detailed results.

Revoking sessions in Microsoft Entra ID invalidates refresh and access tokens immediately, cutting off the compromised account's continued access. This satisfies the stem's requirement to contain a confirmed exfiltration, since password resets alone leave existing tokens valid until expiry.

Create a custom table for that source and set its retention to 2 years. This is correct because Microsoft Sentinel/Log Analytics supports per-table retention policies. By routing this source's data into its own custom table, you can configure that table's retention to 2 years without changing the workspace default. That gives you precisely the granularity needed for a single source.

Microsoft 365 Defender is a native Sentinel data connector that ingests high-fidelity alerts and incidents from the Microsoft Defender XDR suite, including Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps. This connector enables cross-domain correlation and automates incident response by bringing unified XDR telemetry directly into Sentinel, making it a core component for modern security operations.

DeviceProcessEvents is the advanced hunting table that records process creation events, and it includes the ProcessCommandLine field, which captures the full command-line string passed to the newly created process. When investigating suspicious execution, this table lets an analyst see exact arguments such as encoded PowerShell commands or unusual flags, providing direct evidence of the process's intended behavior. It is the authoritative source for command-line telemetry in Microsoft 365 Defender.

Creating an alert policy in Microsoft 365 Defender is correct because alert policies are specifically designed to monitor email activities and generate alerts when conditions are met. For instance, a policy can detect user-reported phishing, suspected malware, or unusual email forwarding patterns, producing an alert that appears in the Defender portal. These alerts can then be assigned severity, include custom notifications, and integrate with incident response queues.

Security Reader is an Entra ID role that grants read-only visibility into security settings, alerts, incidents, and threat intelligence across Microsoft 365 Defender and Microsoft Sentinel. Because Microsoft Copilot for Security only needs to retrieve and summarize security information, this read-only access is sufficient and adheres to least privilege. It is the only option from the list that correctly maps to the required permissions for a Copilot summarization task.

Adjusting the automation level in the Microsoft 365 Defender security settings is the correct action because this setting includes the confidence level required for automatic investigation closure. The automation level can be set to 'Full – Automatically remediate threats,' which allows Defender to act on alerts with a high confidence verdict, or set to 'Semi – require additional confirmation,' which raises the bar for automatic closure. Changing this setting directly controls whether the system closes an investigation without human review, thereby addressing the team's requirement to modify that confidence threshold.

The app dashboard in Defender for Cloud Apps surfaces anomaly detection alerts, such as impossible travel, mass download, or activity from a previously unseen IP. These alerts are produced by user and entity behavior analytics and serve as the initial signal that an exfiltration attempt may be in progress. Reviewing this dashboard is a valid investigative step because it helps you prioritize which users and files warrant deeper log analysis, rather than assuming any single event is malicious.

In Microsoft Sentinel, the incident's Entities tab displays the normalized entity objects—such as user accounts, hostnames, IP addresses, URLs, and file hashes—that were extracted and mapped during incident creation. These entities are directly linked to the incident and enriched with context for pivoting, allowing analysts to see and investigate all related resources from a single, authoritative view. This is the correct place to find all related entities for the incident.

The DeviceProcessEvents table records actual process creation events on the endpoint, and this query filters for any process whose file name is 'ransomware.exe' while projecting the initiating process file name and its command line. That parent relationship is the critical forensic evidence: it shows which executable (for example msiexec.exe, rundll32.exe, or a malicious PowerShell) launched the ransomware, enabling the security team to trace back to the initial access vector. Including the timestamp supports chronological reconstruction of the infection, which is the core goal of the incident response investigation.

In Microsoft Sentinel, a watchlist is a metadata-stored, queryable table that lets you upload a CSV of IP addresses and reference it in KQL via _GetWatchlist(), allowing you to match incident entities or enrich analytics rules without redeploying detections. Watchlists support aliases, search keys, validity dates, and are natively integrated into Alert Rules and hunting, making them the simplest and most appropriate mechanism for a custom IP list that must be joined against incoming events. Unlike raw data ingestion, watchlist data is retained in a structured reference table optimized for lookups.

Device isolation via Microsoft Defender for Endpoint immediately cuts the workstation's network connections while preserving the live system and its forensic artefacts, containing lateral movement and further payload downloads. Remediation and evidence collection follow safely afterwards, satisfying the 90-day preservation policy.

DeviceProcessEvents stores process creation telemetry, including the full command line and arguments for each executed process, so querying it reveals the exact PowerShell parameters used. Network connection tables record destination IPs but not the command-line arguments that launched the script.

DeviceEvents records endpoint telemetry from Defender for Endpoint, and its ActionType field captures ScheduledTaskCreated when a new scheduled task is registered. Filtering on that value surfaces persistence activity directly, which is exactly what the hunting scenario requires.

The Data Collection Rule (DCR) is the authoritative configuration that maps Syslog facility and severity filters to the Log Analytics workspace table. If the DCR's filters are too restrictive, omit the expected facility, or the DCR isn't correctly linked to the Azure Monitor Agent (AMA) and Data Collection Endpoint (DCE), events will be silently dropped. Validating the DCR is the first diagnostic step because misconfigurations here are the most common cause of missing Syslog ingestion.

The Secure Score dashboard in Microsoft Defender for Cloud is the correct place to view an aggregated security score because it consolidates the results of security recommendations and calculates a normalized score across all your subscriptions. It shows your current score, the maximum possible score, and the potential score increase if you remediate all recommended actions. This dashboard provides a single, unified metric that reflects your overall security posture, making it the ideal tool for the stated requirement.

A custom detection rule in Microsoft 365 Defender is the correct choice because it is built on the Advanced Hunting schema, where you can join DeviceProcessEvents and DeviceNetworkEvents on DeviceId and Timestamp. By filtering for the specific parent process and external IP addresses, the query captures child processes making outbound connections, and the scheduled rule can generate alerts and trigger automated response actions.

The 'Remediate' option in Microsoft Defender for Cloud recommendations is the only choice that directly applies automated corrective actions to non-compliant resources. When you trigger it, Defender for Cloud often deploys an Azure Policy assignment with the DeployIfNotExists effect, which automatically reconfigures the resource to meet the security recommendation. This one-click operation fixes the misconfiguration at scale without requiring manual edits, which is exactly what the organization needs.

The proper way to ingest Defender for Cloud Apps incidents is to ensure the Microsoft Defender XDR data connector is enabled in Sentinel and that the 'Microsoft Defender for Cloud Apps' incident table is checked in its configuration. This connector automatically synchronizes incidents from Defender XDR—which include alerts and incidents generated by Defender for Cloud Apps—into Sentinel without any additional setup. As long as the connector shows a connected status and the correct product is selected, Cloud Apps incidents will flow directly to Sentinel's 'Incidents' blade.

The Secure Score is a percentage (0-100%) that quantifies how well your subscriptions and resources have implemented Microsoft's security best practices as recommendations. Each recommendation contributes points based on its associated security control and risk weight, so the score reflects your aggregate posture and helps prioritize remediation actions across all resource types.

Sentinel workbooks are interactive reporting canvases built on Azure Monitor Workbooks, designed specifically to visualize log data with KQL-backed tiles, charts, grids, and step groups. They support parameters, custom time ranges, and automatic refresh, making them the appropriate choice for assembling a SOC dashboard from ingested signals. A workbook can even query the Sentinel Analytics, Alert, and ThreatIntelligenceIndicator tables and render them in a unified view.

EmailAttachmentInfo is correct because it stores each attachment's file name, size, and SHA256 hash, along with the parent email's NetworkMessageId in Microsoft 365 Defender's advanced hunting schema. Querying this table with a known malicious SHA256 returns all NetworkMessageIds for messages that contained that exact file, allowing you to identify every recipient in the phishing campaign. You can then join EmailEvents to gather sender, subject, and delivery status details for further analysis.

Enabling user-reported message settings in Microsoft Defender for Office 365 ingests reports from the Outlook Report button into the system. When configured with automated investigation, each reported message automatically triggers an AIR (Automated Investigation and Response) workflow that runs detonation, threat hunting, and recommended actions. This is the only option that directly connects the user report to a native investigation in Microsoft Defender XDR, matching the requirement.

Assigning incidents to analysts or teams is a core incident management capability in Microsoft Sentinel. Through the Incident blade, an analyst can set the Owner and assign the incident to a specific person or group, establishing accountability and routing for follow-up actions. Assignment does not change incident state by itself but ensures each case has a clear point of contact.

Defender for SQL is the dedicated plan that protects Azure SQL Database, SQL Managed Instance, and SQL on Azure VMs by surfacing database-level threats. It analyzes SQL audit logs and query activity to detect SQL injection attempts, anomalous access patterns, brute-force attacks, and other database-specific vulnerabilities. This plan also provides vulnerability assessment and data discovery/classification, making it the only option here that directly addresses the requirement for SQL security alerts.

The Action center is the centralized, cross-tenant hub in Microsoft 365 Defender that records every remediation action generated by automated investigations (AIR) as well as manual response activities. It shows the action's status (pending, approved, or rejected), the entity it targets (file, device, email, URL, etc.), and the investigation it belongs to, making it the definitive location to review, approve, or reject actions after an automated investigation finishes.

DNS logs, whether collected from internal DNS servers or via Azure DNS Analytics, are a top-tier C2 data source because malware frequently uses DNS to resolve the domain name of its command-and-control server. Every query name, client IP, and timestamp is captured, allowing defenders to correlate against threat intelligence feeds for known malicious domains or detect domain-generation-algorithm (DGA) patterns. This visibility into the resolution process is essential because C2 often leverages a legitimate-looking domain rather than a hard-coded IP address.

In Microsoft Defender for Cloud, the correct way to receive email notifications for high-severity alerts is to navigate to the environment settings, select the subscription's settings, and then configure the email notifications pane. There you can specify security contact email addresses and choose the severity levels (e.g., high severity) for which notifications should be sent. This native feature is purpose-built for directly alerting security teams via email when critical vulnerabilities are detected, ensuring timely awareness without relying on external workflows.

DeviceNetworkEvents records outbound connections with remote IP, port and initiating process, exposing transfers to unfamiliar destinations or large uploads. That network-layer visibility is what reveals exfiltration traffic leaving endpoints, complementing cloud-side logging rather than duplicating it.

Encoded commands, typically Base64 strings passed to PowerShell or command shells, are the signature this hunting query targets. Decoding and inspecting those command lines reveals obfuscated script execution, matching the query's focus on suspicious command-line activity.

This is correct because it introduces the missing temporal constraint: by partitioning sign-ins by user (or self-joining the sign-in table), the query can sort events by timestamp and compute the time difference between consecutive sign-ins where the country changes. A threshold, for example less than 60 minutes for countries that are thousands of miles apart, makes the rule detect actual impossible travel rather than merely multiple countries in a day. The partition operator or join with a time-diff filter enables the scheduled analytics rule to alert only on geographically inconsistent rapid transitions.

Matching known IOCs — file hashes, domains, IP addresses — against telemetry quickly flags artefacts already tied to confirmed campaigns. It is a core hunting technique because it converts threat intelligence into concrete queries across Defender XDR tables, surfacing compromised hosts without waiting for alerts.

Microsoft Defender for Cloud's Defender for Servers plan natively integrates with Azure virtual machines, offering a comprehensive suite of protections that include file integrity monitoring, just-in-time VM access, adaptive application controls, and integrated threat detection powered by Microsoft Defender for Endpoint. The plan also facilitates vulnerability assessment by continuously scanning VM operating systems for missing patches and misconfigurations, making Azure VMs a primary and fully supported workload type.

In Microsoft Defender for Cloud Apps, alerts are backed by discrete activity records captured via API connectors and conditional access app control. Opening the alert and clicking 'View activity' takes you to the Activity log with a filter pre-applied to that exact event, showing user, IP address, user agent, device, cloud app, action, and result. This is the native investigation path designed for alert triage, allowing you to pivot to adjacent activities, related alerts, or governance actions without leaving the portal. It directly answers who did what, from where, when, and with what outcome, which is exactly what an analyst needs for this alert.

Automation rules are the built-in incident orchestration mechanism in Microsoft Sentinel, and one can be configured to trigger whenever an incident is created. The rule can evaluate a condition on the incident's title, such as 'title contains phishing,' and then execute the 'Assign incident to owner' action, specifying an Azure AD user or group as the owner. This happens natively without invoking external workflows, providing instant, deterministic assignment that matches the requirement exactly.

Immediately contains the threat by isolating devices.