Microsoft Security Operations Analyst SC-200 (SC-200) — Questions 1051–1125

DNS tunneling commonly encodes data in the subdomain portion of a query name, so attackers craft unusually long subdomains (often 50+ characters) and generate a high query volume to a single authoritative domain. By analyzing DNS query logs for these patterns—such as label length, entropy, and query frequency per domain—you can directly detect the covert channel. This technique is effective because DNS traffic is frequently allowed through firewalls without deep inspection, making the logs the primary evidence of the exfiltration.

Livestream streams events in real time as they are ingested, letting hunters watch activity unfold without waiting for scheduled analytics rules to fire. This satisfies the scenario's requirement for a hunting feature, since interactive, near-instant event visibility directly supports proactive investigation rather than automated detection alone.

Closing an incident while child alerts remain active leaves orphaned detections that can regenerate the incident or skew metrics. Confirming every linked alert is resolved or closed ensures the remediation is genuinely complete before the incident itself is finalised.

Enabling the 'User reported messages' feature in Defender for Office 365 ensures that user-reported emails are automatically submitted for analysis by Microsoft's threat intelligence systems, including detonation and reputation checks. When the Microsoft Defender XDR connector is enabled in Microsoft Sentinel, the resulting alerts and incidents—such as high-confidence phishing verdicts—are streamed into Sentinel automatically, creating security incidents without manual intervention. This native integration is the correct method to meet the requirement for automated analysis and incident creation.

Microsoft Copilot for Security is the only licensing option that actually grants access to the embedded AI features in Microsoft security products, whether you purchase it as a standalone capacity-based SKU with Security Compute Units or as an add-on to an eligible plan such as Microsoft 365 E5. This license provides the entitlement for Copilot experiences across Defender, Sentinel, and Entra, which is why it is the required license for the organization's goal.

EmailEvents is the correct Advanced Hunting table because it contains the action types for user interactions with email attachments. Specifically, it includes columns like ActionType with values such as EmailAttachmentOpened or EmailAttachmentDownloaded, and it records the email metadata (sender, recipient, subject, and timestamp) associated with those actions. This table directly ties the attachment open event to the email message, making it ideal for investigating potential data exfiltration or phishing attachment engagement.

The correct approach is to enable Alert suppression in the analytics rule's 'Set rule logic' settings. When the rule fires, you can configure it to stop running the query for a specified duration (e.g., 1, 6, or 12 hours), so the same matching condition does not immediately generate multiple duplicate alerts. This suppresses additional alerts from that rule during the suppression window while preserving the rule for future detections.

The join condition in the KQL query is incorrect, which means the query syntactically runs but produces no matching rows. For example, joining on fields with different names, data types, or case values (since KQL joins are case-sensitive) prevents any records from pairing. As a result, the rule's query returns an empty result set each time it executes, so no alerts are created even though both tables contain relevant data.

A central Microsoft Sentinel workspace with cross-workspace analytics rules is the correct approach because it lets you define detection rules that query multiple workspaces (e.g., via the workspace() expression or union operator) and route resulting alerts into a single incident queue. This consolidates detection and incident management so security teams can investigate correlated events across all environments without manually stitching incidents together. It also aligns with Sentinel's native support for centralized SOC operations, where one workspace serves as the primary monitoring and response hub.

Isolating affected devices through Microsoft Defender for Endpoint halts lateral spread and further encryption while keeping the machine powered on, so volatile memory, running processes and network connections remain intact for forensic capture. This directly satisfies the stem's dual constraint: contain the ransomware outbreak yet preserve evidential artefacts.

The file entity page is the designated central repository for file intelligence in Microsoft Defender XDR, consolidating the file name, SHA-1 and SHA-256 hashes, file size, publisher/signing information, global and organization prevalence, observed devices, and current verdict. It aggregates detonation outcomes from deep analysis, related alerts, and the complete set of machines where the file was seen, enabling an analyst to determine both maliciousness and organizational exposure in one place. This is why it is the correct starting point for investigating a detected file.

This is the dedicated Microsoft Sentinel data connector for ingesting alerts and anomalies from Microsoft Defender for Cloud Apps, including policy violations, activity anomalies, and threat detection from cloud applications. It uses the Defender for Cloud Apps API to pull alerts into Log Analytics when enabled. Choosing this connector ensures that all cloud app security alerts are available for investigation and for use in analytics rules.

Alert suppression rules in Microsoft Defender XDR and Sentinel allow you to build conditions directly around entity attributes such as IP address, hostname, or user account. When an alert is generated that matches the specified entity, the rule automatically hides it from the queue, preventing it from consuming analyst time. This is a true suppression mechanism because it acts at the detection level, reducing alert volume before triage.

Security Administrator is one of the two Microsoft Entra ID roles that can manage Microsoft Defender. It has broad permissions to read, configure, and manage security settings across the organization, including threat protection policies, security alerts, and Defender for Endpoint and Defender for Office 365 configurations. This role is designed for day-to-day security operations.

Threat analytics is the correct choice because it is Microsoft's dedicated threat intelligence experience within Microsoft Defender XDR (formerly Microsoft 365 Defender). Each threat analytics report provides detailed analysis of an ongoing or impactful threat, including its attack methods (TTPs), associated indicators of compromise (IoCs), affected platforms, relevant CVE vulnerabilities, and concrete mitigation steps. The reports are curated by Microsoft researchers and are tied to the latest global threat activity, making them the authoritative source for understanding and responding to a broad threat campaign beyond just your own alerts.

The Microsoft Sentinel Incident trigger with the action 'Collect evidence' is the correct choice because it fires when an incident is created, providing a single orchestration point for gathering evidence across multiple sources. This trigger can invoke a playbook automatically via an automation rule or manually, and the playbook can connect to various connectors to collect related evidence and append it to the incident. This aligns with best practice for incident-centric automation.

The Hunting blade provides built-in, pre-built queries that run directly against your Log Analytics workspace, letting analysts pivot on entities and surface suspicious activity without authoring KQL from scratch. This satisfies the stem's requirement for a valid threat-hunting method in Microsoft Sentinel, complementing custom query development.

SecurityIncident is the canonical Microsoft Sentinel table for incident records, generated by the incident management service. Each row represents a single incident and includes authoritative fields such as IncidentNumber, Title, Status, Owner, CreatedTimeUTC, FirstActivityTimeUTC, LastActivityTimeUTC, and TriageTimeUTC. Querying this table directly lets a workbook aggregate incidents by time or status without joins or approximations, making it the correct source for incident lifecycle metrics like created and triaged times.

The automation rule in the exhibit includes a 'Run playbook' action that explicitly references the playbook named 'BlockIPPlaybook'. When the rule's trigger conditions are met, Microsoft Sentinel invokes the associated Logic App, which likely performs a connection- or firewall-blocking action against the offending IP. This is a standard way to automate response actions directly from an incident, and it is the sole effect defined in the automation rule's configured actions.

summarize groups rows by chosen keys and computes aggregates such as count or make_set, letting you collapse many similar PowerShell command lines into per-host or per-command patterns. That aggregation exposes commands recurring across workstations, which raw row-by-row output obscures.

Microsoft Defender for Cloud Apps functions as a cloud access security broker (CASB) with API connectors to SharePoint Online and other SaaS apps. It aggregates file access and sharing events, applies user and entity behavior analytics (UEBA) to detect impossible travel, mass downloads, and abnormal external sharing, and can generate the exact type of suspicious file access alert an analyst would investigate in this scenario.

Automation rules run on incidents after creation and can assign an owner, change severity, add tags, or run a playbook. Assigning an incident to a specific owner is a supported action, letting triage routing happen automatically without manual analyst intervention.

The SecurityIncident table in Microsoft Sentinel stores incident records generated by the analytics and correlation engine. By filtering on TimeGenerated > ago(7d), this KQL query limits results to incidents that were created in the past week, and the summarize count() by Severity then aggregates those incidents into buckets of Informational, Low, Medium, and High. Because the analyst specifically asked for the number of incidents, this is the correct table and aggregation.

Microsoft Entra ID audit logs are the correct primary source for UEBA because they contain identity-centric actions such as user sign-ins, conditional access evaluations, and directory modifications (e.g., password changes, role assignments). UEBA uses these logs to construct user profiles and establish behavioral baselines, enabling detection of anomalous activity like impossible travel or unusual authentication patterns. Since UEBA is fundamentally about user entity behavior, Entra ID logs provide the identity context that other logs lack.

AuditLogs records Microsoft Entra ID directory activity, including role membership and role definition changes, so it directly satisfies the requirement to hunt privileged account abuse through directory role modifications. SigninLogs covers authentication events instead, not administrative role changes.

Isolating the device from the network is the immediate containment action because it severs the ransomware's C2 channel, preventing key exchange, additional payload downloads, and SMB-based worm-like propagation to adjacent systems. Physically disconnecting the network cable, disabling the Wi-Fi adapter, or applying a host-based firewall rule to block all inbound and outbound traffic ensures the encryption process cannot phone home or spread. This preserves evidence while stopping the attack in place, making it the first priority in any ransomware containment playbook.

Adaptive Application Controls must first run in audit-only mode for at least two weeks so Defender for Cloud can observe normal application usage and build a baseline of known-good executables, including file paths, publishers, and hashes. This audit-derived baseline is the specific prerequisite for switching a policy to enforce mode; without it, the allowlist would be incomplete and would cause legitimate applications to be blocked. Therefore, having a baseline generated from at least two weeks of audit data is the required condition before enforcement can be safely enabled.

Disabling the account in Microsoft Entra ID immediately blocks authentication, satisfying the requirement to contain the compromised identity. For a hybrid user, however, this alone may not stop on-premises Kerberos activity, since the domain controller still validates tickets until directory sync propagates the change.

Enabling the 'Capture NTLM hashes' setting in the Microsoft Defender for Identity sensor configuration instructs the sensor to intercept NTLM authentication traffic on the network and extract the NTLM hashes used during the handshake. This is the foundational telemetry for pass-the-hash detection because the sensor can then correlate these captured hashes against account logon events to identify when a hash is reused from a different source. Without this setting, the sensor lacks the specific data needed to trigger pass-the-hash alerts, making it the correct configuration for this scenario.

The built-in Azure Policy initiative 'Enable Microsoft Defender for Cloud on all subscriptions' is a policy set designed to apply the Defender plans (including Servers, SQL, and Storage) to every subscription within the assigned scope. When assigned at the management group level, Azure Policy automatically deploys the necessary plan enablement and pricing tier configuration to both existing and future subscriptions, removing the need for manual per-subscription setup. This is the intended native mechanism for centralizing the enablement of Defender plans across an enterprise.

DeviceFileEvents records file creation, modification and rename activity, including the FileName, FolderPath, InitiatingProcessFileName and Timestamp columns. Filtering with `where` on DeviceName and a Timestamp range narrows results to the five-minute window, satisfying the requirement to enumerate files written before the ransomware process started.

Searching for known indicators of compromise lets hunters match observed artefacts — file hashes, IP addresses, domains — against threat intelligence. This reactive technique rapidly confirms whether known malicious infrastructure or payloads are present in the environment, satisfying one recognised threat hunting methodology.

Azure Firewall is a supported Microsoft Sentinel data connector, streaming firewall network and application rule logs into the workspace via Azure Monitor diagnostic settings. This satisfies the question's requirement to identify valid connectors, alongside Microsoft Entra ID.

AuditLogs (Microsoft Entra ID) is the authoritative log for directory administrative changes, capturing activities such as 'Add member to role,' 'Remove member from role,' and 'Activate role' in the RoleManagement category. Each log entry includes the actor, target user, role name, and timestamp, enabling full visibility into who was granted elevated permissions and when. In Log Analytics or Microsoft 365 Defender, this appears as the AuditLogs table in the EntraID sign-in/logs connector. Therefore, it is the correct data source for verifying whether any user has been added to a privileged role.

This table in Microsoft 365 Defender (Advanced Hunting) captures network connections initiated by devices, including DNS queries when ActionType is DnsQuery. For exfiltration suspicion, DNS queries to known malicious domains or unusual patterns (e.g., high volume, TXT record payloads) can be detected. Also includes other network actions like ConnectionSuccess, so it's the primary table for network egress.

This is the correct approach because Microsoft Sentinel automation rules are the native, first-class mechanism for responding to incidents. By triggering on 'When incident is created' and setting conditions that check for severity equals High and tag contains 'malware', the rule will evaluate every new incident and conditionally run the chosen playbook. This keeps response logic centralized in Sentinel, is easy to audit via the automation rule list, and does not require custom code or external integrations.

DeviceLogonEvents records successful interactive logons with AccountUpn and DeviceName. Filtering by that account and LogonType, then summarising distinct devices per 10-minute bin, surfaces any window where one account touched more than five workstations, matching the lateral-movement hypothesis.

The Microsoft Defender XDR incident queue is the correct location because it consolidates alerts from Defender for Endpoint, Defender for Identity, Defender for Office 365, Defender for Cloud Apps, and other Microsoft 365 security signals into a single correlated incident. This gives the SOC analyst the full attack story, affected assets, and evidence, along with integrated investigation and response actions. High-severity alerts originating from Microsoft Defender workloads are automatically aggregated here, making it the primary triage and investigation surface.

In Microsoft Sentinel, enriching an alert with threat intelligence is a standard investigative step: you pivot on entities such as IPs, domains, or hashes to query TI feeds and identify known malicious context, which helps validate the alert's severity and false-positive risk. This enrichment often leverages the built-in Threat Intelligence workbook or the hunting queries, enabling the analyst to correlate the current alert with historical compromise activity. It directly supports the 'Investigate' phase of the incident response lifecycle, making it a correct step.

Resetting the password invalidates the attacker's knowledge of the compromised secret, while explicitly revoking the user's active sessions and refresh tokens terminates the attacker's existing authenticated access to Microsoft 365/Entra ID apps. This should be done before any other investigation step because it limits dwell time and prevents further lateral movement or data exfiltration as long as the attacker is not already using alternate backdoors. The 'Revoke user sessions' action in the Entra ID admin center (or Microsoft Graph `revokeSignInSessions`) closes current bearer/refresh tokens, not just the password-based login path.

Allowlisting known administrative tools removes legitimate remote-management activity from the result set, cutting false positives without narrowing the query's scope. Detection coverage for genuine lateral movement persists, since only trusted binaries are excluded rather than whole event categories.

The analytics rule in Microsoft Sentinel includes a configuration pane where you can select one or more MITRE ATT&CK tactics and techniques (such as Initial Access, Execution, or Command and Control) that the rule is designed to detect. When the rule fires and creates an incident, the selected tactics are automatically applied to the incident's MITRE ATT&CK fields, enabling immediate categorization and correlation with other threat intelligence. This is the intended, first-party mechanism for tagging incidents with tactics, and it requires no additional overhead or post-processing, making it the correct and most reliable approach for automatic categorization.

The Investigation graph is Microsoft Sentinel's entity-centric exploration tool, modeling relationships between IPs, hosts, accounts, and alerts as a visual map. From a suspicious IP entity you can double-click or expand to immediately surface all connected alerts, related incidents, and adjacent entities, making it the correct pivot path for threat hunting. It leverages the entity schema and graph data to show both direct and indirect connections.

Suspending the user account in Microsoft Entra ID immediately disables the user object, preventing any fresh authentication and token issuance for all applications, including the sanctioned app protected by Defender for Cloud Apps. This is the most direct and effective containment action because it blocks all sign-in attempts regardless of device, network, or app, and takes effect nearly immediately across Microsoft's identity plane.

The Microsoft Entra ID connector pulls sign-in and audit logs through the Microsoft Entra ID diagnostic settings pipeline into the workspace. It is the supported data connector for these identity event tables, matching the stem's collection requirement.

Microsoft Defender for Endpoint Live Response is the correct choice because it provides a remote, real-time shell for a compromised device. You can initiate a session from the MDE portal, run PowerShell commands, execute a script from the library, collect forensic artifacts, and retrieve the malicious script file for analysis. This interactive capability allows you to inspect the exact script content, confirm its behavior, and gather evidence directly from the endpoint.

Disabling the public IP and applying an NSG rule that blocks all inbound and outbound traffic at the server's subnet effectively isolates the VM from both external attackers and internal lateral movement while leaving the machine powered on for evidence preservation. Because NSGs are stateful and evaluated for every flow, this drops current network conversations and prevents new ones, cutting off command-and-control or data exfiltration. This is the proper immediate containment action in an incident response playbook, as it contains the threat without destroying forensic artifacts.

Configuring Syslog using Azure Monitor Agent (AMA) is a fully supported ingestion path in Microsoft Sentinel. AMA runs on Linux virtual machines and uses Data Collection Rules (DCRs) to define which facilities and severities to forward to the Log Analytics workspace that Sentinel monitors. This method replaces the legacy Log Analytics agent, allowing you to collect syslog events from on-premises and cloud Linux servers, and it is a first-party, no-code option in the data connectors gallery.

Creating an alert suppression rule scoped to the test VM and the specific alert type is the correct noise-control method in Defender for Cloud. You define conditions such as the VM resource and alert name, so truly benign alerts from this known test asset are hidden or muted without disabling any threat detection. Other VMs remain fully monitored, and if the alert pattern changes, you can edit or disable the rule.

The Microsoft Defender XDR data connector is the supported, out-of-the-box integration that automatically imports incidents and alerts generated by Defender for Endpoint, Defender for Identity, Defender for Office 365, and Defender for Cloud Apps into Microsoft Sentinel. It leverages the Microsoft Graph security API, preserves the full incident schema, and provides bidirectional synchronization of incident status and comments between Sentinel and the Microsoft 365 Defender portal, requiring no custom code and minimal configuration.

Automation rules can directly change an incident's severity by specifying a new severity value (e.g., Low, Medium, High, or Critical) as part of the rule's action set. This is a built-in action that does not require a playbook and is commonly used to reclassify incidents based on custom logic, such as elevating severe events for priority response.

Automation rules in Microsoft Sentinel are the correct mechanism because they are designed to trigger automatically when an incident is created. They can perform actions such as assigning the incident to a specific owner or group, modifying severity, adding tags, or invoking a playbook, all without manual intervention. These rules provide consistent, policy-based incident assignment directly within the Sentinel incident lifecycle.

Event ID 4688 records process creation with command-line auditing enabled, capturing Mimikatz execution and its suspicious arguments. This contrasts with 4624 logons or 4672 privilege assignment, which show access but not the credential-dumping tool itself.

OAuth app granting permissions directly records consent events, capturing the scopes granted to each application. This satisfies the hunter's requirement to identify suspicious OAuth permissions, as the activity log exposes the specific delegated or application permissions assigned, enabling detection of illicit access or over-privileged third-party apps.

The IP address is the shared entity linking every suspicious sign-in, letting you pivot to enumerate all related authentication events, affected accounts and associated alerts. Pivoting on the IP exposes the full scope of the threat actor's activity.

Automation rules in Microsoft Sentinel evaluate incident conditions and can invoke playbooks automatically when their trigger conditions match, such as on incident creation with a specific severity or title. This satisfies the runbook requirement that no analyst clicks anything. The playbook then performs the Teams posting and task creation through its connectors, so the response is fully automated and repeatable for every matching incident.

Incident management is a core SOAR component in Microsoft Sentinel because incidents serve as the central case-management entity for investigation and response. Sentinel's SOAR capabilities are centered on the full incident lifecycle—creation, assignment, triage, investigation, and resolution—enabling consistent handling. Incident management integrates with automation rules and playbooks to drive orchestrated response, making it essential to the SOAR framework.

Using KQL to query logs in Microsoft Sentinel allows you to search across connected data sources, such as AzureActivity and OfficeActivity, for actions performed by the service account. This provides a detailed and customizable view of all activities, enabling thorough investigation.

In Microsoft Sentinel, UEBA is disabled by default; you must open Settings > UEBA, toggle it on, and select the relevant data sources such as Azure AD sign-in logs, Azure AD audit logs, and Microsoft Defender for Identity data. Once enabled, Sentinel creates entity profiles, establishes behavioral baselines over time, and uses built-in ML to detect anomalies including impossible travel and sign-in from unusual locations. This is the definitive prerequisite step; without it, no entity behavior analytics or anomaly scoring runs in Sentinel.

STIX/TAXII threat intelligence feeds are legitimate because STIX (Structured Threat Information eXpression) standardizes how threat indicators and malicious behaviors are described, while TAXII (Trusted Automated eXchange of Indicator Information) provides the standardized transport protocol for sharing those feeds. Microsoft Sentinel natively supports ingestion from TAXII servers via the Threat Intelligence TAXII data connector, allowing organizations to pull in indicators of compromise and campaign context from public or commercial providers. This standards-based interoperability is exactly why these feeds are a recognized, first-class source of threat intelligence in a SIEM.

Querying SecurityAlert for alert names containing 'Golden Ticket' or 'Suspicious Kerberos' is correct because Microsoft Defender for Identity, which is integrated into Microsoft 365 Defender and surfaces alerts in the SecurityAlert table, provides high-fidelity detections specifically for forged TGT activity. MDI signals such as anomalous ticket granting service requests, unusual TGT size, or encryption downgrade attacks are aggregated here, making it the direct, authoritative source for identifying golden ticket usage without needing to reconstruct indicators from raw logs.

Automation rules in Microsoft Sentinel invoke playbooks by using either a managed identity or an OAuth connection to authenticate against the Logic App resource. If the managed identity lacks the required RBAC role on the Logic App (for example, Logic App Operator), or if the connection used by the rule has been removed, expired, or lacks the necessary permissions, the automation rule cannot trigger the playbook. This is the most direct and common cause of playbook execution failure, making it the correct answer.

The correct approach is to create an automation rule in Microsoft Sentinel that triggers when the specific alert from Microsoft 365 Defender is generated. In the automation rule, you associate a playbook that uses the Microsoft 365 Defender connector to quarantine the email. This enables an automated, immediate response without human intervention, leveraging the built-in alert as the trigger and the Logic Apps playbook to execute the quarantine action.

Automation rules in Microsoft Sentinel run immediately when an incident is created (or updated) and can modify incident properties, including the severity field. By creating an automation rule that triggers on the 'Incident created' condition and sets the severity to 'High', you ensure that all incidents generated from Defender XDR alerts are classified consistently without manual intervention or duplicate incident creation. This is the correct approach because automation rules are designed for such property-level adjustments and do not interfere with the existing connector workflow.

Continuous export is a native feature that automatically copies ingested log data from a Log Analytics workspace to an Azure Data Lake Storage Gen2 account in near real time, storing each table as a set of Parquet files. This provides long-term retention and cost-effective archival because you can delete the data from the workspace after export or keep it only for the required interactive period. It supports filtering per table and is fully managed, so it is a valid archival method, especially for compliance or big-data analytics scenarios.

Separate Sentinel workspaces placed in the US, EU, and Asia keep each region's log data stored within its corresponding geopolitical boundary, satisfying data-residency requirements. Cross-workspace queries use the workspace() KQL operator to query all three workspaces in one investigation, while Azure Lighthouse grants the central SOC delegated RBAC permissions across subscriptions or tenants without duplicating data. This architecture combines regional compliance with a single-pane-of-glass management experience.

Windows Security Events, collected via Windows Event Forwarding (WEF), are the authoritative source for on-premises failed-logon hunting because domain controllers log Event ID 4625 for every failed NTLM/Kerberos logon attempt. WEF uses HTTP/HTTPS (WinRM) and a collector-initiated subscription, preserving the full payload: source IP address, workstation name, logon type, and authentication package. This enables centralized correlation across all DCs in the domain and direct ingestion into a SIEM such as Sentinel.

Role assignments in Microsoft Entra ID, including additions to privileged roles such as Global Administrator, are recorded in the AuditLogs table. Querying AuditLogs with the Add member to role operation captures the directory change, which SigninLogs and SecurityEvent do not record.

In Microsoft Sentinel UEBA, the user account is the primary entity type for detecting credential compromise because authentication and authorization are fundamentally tied to accounts. Attacks such as password spray, brute force, impossible travel, and anomalous sign-in all manifest as unusual activity on a user account, and UEBA builds a behavioral baseline per user to score these deviations. The investigation timeline aggregates sign-in events, machine activity, and assigned alerts around the account, enabling analysts to trace the full scope of a compromise. Therefore, User account is the correct answer.

Running a live response session on the device establishes an interactive, remote shell through the Microsoft Defender for Endpoint management plane. It enables the incident responder to execute PowerShell scripts, collect forensic artifacts such as memory, registry, and files, and apply remediation actions directly on the endpoint. Crucially, this can be done even while the device remains isolated, because the live response channel uses an outbound HTTPS connection to the cloud service.

Joining EmailEvents to EmailAttachmentInfo on NetworkMessageId is correct because NetworkMessageId uniquely identifies a single email message in both tables, and this preserves the relationship between the recipient (in EmailEvents) and each attached file (in EmailAttachmentInfo). This join lets you count emails by RecipientEmailAddress and FileName within a specified time bucket, which is exactly what a detection rule for attachment-based threats requires. Because EmailAttachmentInfo contains one row per attachment, you can aggregate with summarize count() and optionally bin the Timestamp to detect spikes in attachments per user.

Running a full antivirus scan on affected devices is a primary eradication step because it identifies known ransomware signatures, quarantines the malicious binary, and cleans any dropped files or artifacts. In the context of Microsoft Defender for Endpoint, the scan leverages cloud-delivered protection and tamper protection to remove the threat from all local drives. This action is most effective after isolating the device, because the scan itself does not prevent lateral movement while it is running.

Joining SigninLogs and AuditLogs on user principal name, constrained to a short time window, correlates an anomalous sign-in with a subsequent password reset. This temporal correlation across both tables surfaces the credential-theft sequence, which neither log alone reveals.

The DNS (Preview) via AMA connector ingests DNS query events from devices, which is the only telemetry that records domain resolution. Enabling it satisfies the requirement to trigger when any device resolves the C2 domain, since network connectors alone would not capture resolution.