Microsoft Security Operations Analyst SC-200 (SC-200) — Questions 826–900

Playbooks are Logic Apps triggered by Microsoft Sentinel automation rules, enabling an automated response that calls firewall APIs to block the IP. This satisfies the requirement to block the unapproved external address automatically upon incident creation.

Automatic attack disruption is the Microsoft 365 Defender incident response feature that continuously monitors correlated XDR signals—endpoint, identity, email, and cloud apps—for evidence of active hands-on-keyboard attacks, ransomware, or malware campaigns. When an active attack is detected, it automatically triggers containment actions such as isolating compromised devices, disabling user accounts, and blocking malicious indicators to stop lateral movement while responders intervene. This is exactly the capability that automatically contains compromised assets during an active attack.

KAPE is specifically designed for live incident response: it collects targeted artifacts such as browser history, prefetch files, registry hives, and recently accessed documents directly from the running system while preserving their timestamps and metadata. Its output is organized and can be processed with timelines, and its operation avoids installing persistent software or altering core system files, so the evidence collection is faster and less intrusive than full disk imaging. By running KAPE during the incident, you capture volatile and semi-volatile evidence that would be lost after a reboot or shutdown, which is why it is a valid live collection method.

An automation rule with an 'Assign owner' action is correct because Sentinel automation rules run natively on incident creation or update and can evaluate conditions such as alert type, severity, or entity. The Assign owner action directly sets the incident's Owner property to a designated user or Azure AD group, enabling immediate assignment without requiring Azure Logic Apps. Unlike playbooks, this built-in action is low-latency and doesn't need an external connector.

Automation rules in Microsoft Sentinel support multiple actions, including assigning an owner and adding tags. By configuring these actions in the existing automation rule, you fulfill the requirement to automatically assign and tag incidents from Defender for Identity alerts. This is the most direct and efficient method.

Entities are the discrete actors, assets, and resources involved in an incident—such as user accounts, devices, IP addresses, and mailboxes. In the Microsoft Defender XDR incident data model, these are not just attached labels; they are contextualized and linked to alerts and evidence to establish the attack's scope and blast radius. This makes them a foundational component for threat hunting and investigation because they, unlike alerts or evidence, represent the 'who' and 'what' that are impacted.

This is the correct approach because automation rules in Microsoft Sentinel are specifically designed to run when an incident is created (or updated), and they can trigger a playbook as a remediation action. The automation rule can match incidents with the 'Phishing' tactic and logically invoke a playbook that, for example, connects to Exchange Online PowerShell to remove the suspicious forwarding rule. This separation of concerns—analytics rule detects, automation rule orchestrates, playbook executes—is exactly how automated remediation should be implemented in Microsoft Sentinel.

A Watchlist stores the external IP indicators as a reference table, letting a KQL query join them against DeviceNetworkEvents to surface devices contacting those addresses. This satisfies the requirement to hunt proactively across Defender for Endpoint telemetry without waiting for an alert.

A custom detection rule in Microsoft 365 Defender lets you run a KQL advanced hunting query on a schedule, joining DeviceFileEvents and DeviceProcessEvents to correlate file creation and process execution events across devices. This enables alerting on multi-stage attack sequences that individual alert rules might miss, with full flexibility to define thresholds, time windows, and affected device groups. Because the rule runs natively in the same environment that ingests the endpoint telemetry, it provides direct, low-latency detection without extra data transfer or licensing.

Playbooks are Logic Apps workflows that can call external REST APIs, handle API keys via secure inputs, and post results back to the incident as comments, tags, or entities. Automation rules can trigger a playbook automatically when an incident is created, matching the requirement for automatic enrichment on matching incidents. This combination provides the required no-touch, repeatable enrichment using the external threat intelligence platform.

Event 4624 with LogonType 3 and authentication package NTLM indicates a network logon using NTLM, which is exactly what a pass-the-hash attack performs. The logon process NtLmSsp and the authentication package NTLM in the event are key indicators; LogonType 3 signifies remote access to a resource. While normal network shares also create such events, filtering for unusual source workstations or privileged accounts can reveal pass-the-hash activity. This is the most direct Windows Security log source for detecting NTLM-based lateral movement.

This is the correct approach because an automation rule in Microsoft Sentinel can be configured to trigger immediately upon incident creation and invoke a playbook. The playbook, built in Azure Logic Apps, uses the Microsoft Defender for Endpoint connector's 'Isolate machine' action to send an isolation command to the device. This provides a fully integrated, automated response that directly ties Sentinel's incident detection to the prescribed containment action, without manual intervention or custom script execution.

EmailAttachmentInfo records each attachment's SHA256 hash alongside the network message ID and recipient, letting the analyst match the known hash and retrieve the corresponding message IDs. This table directly satisfies the requirement to trace delivered emails containing that exact attachment.

Sentinel natively supports incident comments and collaboration through the Comments pane on the incident details page. Analysts can append notes, tag colleagues with @mentions, and preserve a chronological audit trail of investigation decisions without leaving the portal. This capability requires no additional connectors or playbooks, because it is part of the core incident management surface.

Threat intelligence connectors are purpose-built data connectors that pull indicators from external sources—such as TAXII feeds, Microsoft Defender Threat Intelligence, or third-party platforms—directly into the normalized ThreatIntelligenceIndicator table. Once ingested, Sentinel automatically enables matching and correlation across analytics rules and detections. This is the correct mechanism for automatically importing and operationalizing TI feeds.

Reviewing the user's risk level and sign-in logs in Microsoft Entra ID Protection is the correct initial action because it provides aggregated risk detections and contextual details, such as impossible travel or unfamiliar sign-in properties, to confirm whether a compromise has actually occurred. This investigation-first approach enables you to make an informed decision about whether to require a password reset, revoke sessions, or take other containment steps.

Opening the device timeline reveals the full process tree, parent-child relationships and command lines behind the encoded PowerShell. This lets the analyst confirm whether the activity is genuinely malicious before containment, satisfying the need for immediate triage evidence.

Blocking the recipient domain on the email gateway is an appropriate containment action because it immediately halts the active data exfiltration channel by rejecting any further outbound messages destined for that domain. This measure is applied at the transport layer, so it stops the bleeding without deleting any previously sent evidence, and it preserves the ability to later analyze the full extent of the breach while preventing additional data loss.

Initiating a live response session from the Microsoft 365 Defender portal opens a secure, interactive remote shell to the device, allowing an analyst to execute built-in and custom commands to collect registry keys, running processes, network connections, and specific files into an evidence package. It is the correct choice for immediate forensic triage because it provides direct, time-sensitive access to volatile artifacts without relying on automated detection. The session is fully audited and can be used to run live response scripts or collect suspicious binaries for further analysis.

Reviewing the user's activity log in Defender for Cloud Apps is the foundational step for incident investigation. It provides forensic detail such as exact timestamps, source IP addresses, user agents, and the number of files downloaded, allowing you to compare this behavior against the user's baseline and organizational anomalies. This evidence is required to determine whether the downloads constitute a real exfiltration threat or are an outlier caused by a legitimate business task.

Assigning the incident owner via an automation rule is the correct approach because automation rules can perform built-in incident actions immediately after the incident is created. This rule can use conditions such as the alert being generated from Defender for Cloud to set the owner field to the cloud security team, ensuring proper routing without requiring a playbook. Automation rules run after the connector or analytics rule creates the incident, making them the precise mechanism for ownership assignment in the incident lifecycle.

Defender for Cloud Apps Cloud Discovery has no visibility into your network traffic unless it receives the raw logs from your proxy, firewall, or other network appliances. You must either manually upload a flat log file through the Cloud Discovery 'Upload' dialog for an ad-hoc snapshot, or deploy the log collector to automate continuous ingestion, parsing, and forwarding. The log collector runs on Windows or Linux, receives logs via FTP/Syslog/HTTP, and is the standard for ongoing discovery. Without this step, no shadow IT analysis can occur, making it a required configuration action.

Creating a playbook that invokes a firewall API (via Azure Logic Apps) to block the offending IP is a direct containment action. It severs the attacker's communication path to your environment at the network boundary, without affecting the legitimate user's ability to sign in. This is the immediate, low-disruption response that stops the ongoing brute-force attempts from that source.

_GetWatchlist('name') is the purpose-built Kusto function for retrieving Microsoft Sentinel watchlist content inside an analytics rule. The watchlist data is cached by Sentinel, and updates made through the portal, API, or PowerShell are automatically reflected without changing the rule query. This centralization enables SOC teams to maintain and version reference data independently from detection logic, while still supporting efficient joins and lookups in scheduled queries, making it the recommended pattern.

UEBA in Microsoft Sentinel relies on machine learning to learn what 'normal' behavior looks like for each user or entity. A minimum of 14 days of historical activity must be ingested into the workspace before a reliable baseline is established; without that baseline, UEBA cannot differentiate anomalous activity from ordinary variations. Even though UEBA is enabled, the lack of detections within the initial period is expected and not due to configuration errors.

The correct action is to examine the analytics rule that creates incidents from Microsoft Defender for Office 365 alerts, because Microsoft Sentinel does not automatically create incidents from every raw alert. Analytics rules use KQL queries to match incoming alerts and apply conditions, and if the rule's severity threshold (e.g., only Medium and higher) is too high, alerts with lower severity won't trigger an incident. Verifying the rule's query, alert grouping, and severity filter directly addresses the symptom of users receiving Microsoft 365 Defender alerts while Sentinel incidents are missing.

Mimikatz reads credential material directly from LSASS memory, so a process requesting PROCESS_VM_READ against lsass.exe is the strongest signal. Legitimate tools rarely open LSASS with memory-read rights, making this access mask the specific indicator Microsoft Defender for Endpoint surfaces for credential-dumping detection.

CloudAppEvents is the correct table because it specifically records activities performed in Microsoft 365 cloud services, including SharePoint Online. This schema captures rich details about file operations such as downloads, uploads, modifications, and file access by users and apps. A security analyst querying for suspicious file access in SharePoint would filter this table by Application and ActionType fields to identify the exact activity.

Running every 5 minutes with a 5-minute lookback is optimal because the lookback exactly matches the execution interval, ensuring each event is evaluated exactly once within its own time window. This configuration minimizes detection latency to at most five minutes while avoiding both data gaps and overlapping evaluations. It's the standard baseline for near-real-time security alerting in tools like Microsoft Sentinel.

Automation rules trigger on incident creation and can filter by tactics and severity, then invoke a playbook. The playbook performs the assignment and posts the Teams notification, satisfying both the triage routing and alerting requirements without manual intervention.

An automation rule with an 'Assign incident' action is the intended, built-in method for automatically setting the incident owner when an incident is created. Automation rules run immediately after an incident is created (or updated) and support a dedicated action that writes the owner property, optionally based on a condition such as the incident's severity or its associated analytics rule. This makes it the simplest and most reliable way to ensure ownership is always assigned.

EmailEvents is the central advanced hunting table in Microsoft 365 Defender for email message-level data within Exchange Online. It exposes fields such as SenderFromAddress, SenderDisplayName, RecipientEmailAddress, Subject, and EmailDirection, as well as the delivery action (e.g., Delivered, Junked, Blocked, Failed) via the DeliveryAction column. For any scenario requiring the identity of the sender, the subject, or the final disposition of an email, EmailEvents is the correct table to query first.

Configuring a data archiving policy in the Log Analytics workspace automatically moves logs from the interactive retention tier to an archive tier after a defined period, such as 90 days, while preserving the ability to search them through archived log search jobs. Archived data is retained at a lower cost and remains accessible for compliance and incident investigations, subject to a separate total retention duration and additional search costs. This is the intended native method for long-term, queryable log retention in Microsoft Sentinel.

Selective isolation limits outbound and inbound communication to the Defender for Endpoint service channel and permits live response, so you can still run commands to gather forensic artifacts while the attacker is cut off from command-and-control and lateral movement. This matches the requirement to isolate the device yet retain live response capability. You can later release the device from isolation once remediation is verified.

Joining DeviceNetworkEvents on DeviceId and filtering RemoteIP to 203.0.113.1 correlates the existing results with endpoint network telemetry, satisfying the requirement to identify which devices communicated with that IP. DeviceNetworkEvents records inbound and outbound connections per device, so the join surfaces the missing device context.

Microsoft Threat Intelligence feed is natively integrated with Microsoft Sentinel, providing curated indicators of compromise from Microsoft's global telemetry. It satisfies the stem's ingestion requirement without custom connectors, unlike external feeds needing API configuration. This built-in source enriches threat hunting queries directly.

Use the 'Isolate VM' action in the security alert is the correct immediate response because Defender for Cloud dynamically attaches a network security group to the VM's network interface that blocks all inbound and outbound traffic, while still allowing only the Defender service's management and forensic paths. This quarantines the compromised VM without deleting or detaching its disk, preserving evidence for investigation. The action is designed for exactly this kind of incident-response need: rapid, built-in network containment without disrupting connectivity to other Azure services that the investigation depends on.

Configuring Basic Logs for high-volume verbose data sources is a valid cost-reduction method because Basic Logs are billed at a lower ingestion rate and stored in a low-cost, high-volume tier compared to Analytics Logs. High-volume verbose sources (e.g., DNS query logs, firewall logs, or raw network traffic) that are useful for occasional threat hunting or compliance but not for continuous alerting can be sent to Basic Logs tables, dramatically reducing the cost of data that does not need full interactive analytics. This approach preserves detection capabilities for critical security data while offloading noisy, expensive data to a cheaper storage tier.

Disabling the user account via the Microsoft Graph API (PATCH /users/{id} with accountEnabled set to false) immediately prevents the user from authenticating and blocks new token issuance. This identity-level control stops the attacker from accessing any Microsoft 365 resources and is a strong containment measure. Because it also prevents legitimate use, it is often reserved for confirmed compromises and is followed by investigation and remediation.

Custom detection rules in Microsoft Defender XDR use KQL to query advanced hunting tables. The DeviceProcessEvents table contains process creation events, including process name and command line. Using KQL, you can filter for FileName == 'malicious.exe' and ProcessCommandLine contains '--encrypt' to trigger the alert as required.

Disabling the user account in Microsoft Entra ID is the most effective immediate containment step because it blocks all new token issuance and denies sign-in for every application that trusts Entra ID as the identity provider. This cuts off the attacker's access to Microsoft 365, Azure, and any federated SaaS apps using the account. You should also reset the user's password and revoke tokens after disabling, but the disable itself stops the attack in progress.

EmailEvents is the primary advanced hunting schema for email security in Microsoft 365 Defender. Each row represents a distinct email message and includes fields such as DeliveryAction (e.g., Delivered, Junked, Blocked), ThreatTypes (e.g., Phish, Malware), and DetectionMethods. The Phish filter in Threat Explorer relies on this table because it contains the original verdict determined at the time of delivery, making it exactly what the analyst needs.

In Sentinel, automation rules evaluate conditions in top-down order; placing more specific conditions before general ones ensures that incidents matching a narrow scenario are handled by the intended rule before a broader rule can claim them. For example, if you have a rule assigning incidents from a specific asset to a specialized analyst, it must be listed before a rule that assigns all incidents to a general queue. This ordering is critical because the first matching rule takes action; otherwise, a generic rule may consume the incident first.

A Defender for Endpoint indicator with action 'Block' blocks the malicious IP or domain on all onboarded endpoints immediately through Network Protection, regardless of where the devices connect.

The email entity page in Microsoft Defender XDR aggregates the full message body, headers, attachments and related alerts for a specific email, giving the analyst the complete content needed for phishing triage. It is reached from the incident graph or Explorer, unlike the summary views that only show metadata.

Microsoft Defender for Cloud's 'Environment settings' > 'Data collection' page is the correct central location to enable auto-provisioning of the Log Analytics agent (or Azure Monitor Agent) across all subscriptions. Toggling the agent here creates the underlying policy assignments that automatically install the agent on every VM without per-VM manual interaction, ensuring consistent security monitoring coverage.

Device isolation severs network connectivity while preserving the endpoint for investigation, immediately halting the malicious PowerShell script's payload execution and preventing lateral movement across the affected workstations. This directly contains the active threat identified during the hunt.

Incident automation rules are the central mechanism in Microsoft Sentinel for defining automated responses at the incident level. They execute when an incident is created or updated, and can trigger playbooks to perform actions such as blocking an IP address, assigning an owner, or adding tags. They support conditions, ordering, and multiple actions, making them essential for SOAR workflows.

Custom detection rules in Microsoft Defender XDR are built with KQL queries over the advanced hunting schema (such as DeviceProcessEvents or DeviceNetworkEvents) and allow you to set automatic response actions directly, including 'Isolate device' as a triggered action. When the query matches a device, the rule natively instructs the Defender for Endpoint sensor to isolate that machine immediately, which is exactly the capability the scenario requires. This is the only option that both detects a suspicious behavior and executes a device-level containment action without relying on external automation.

Investigating the alert in the Microsoft 365 Defender portal is the correct first step because it provides the full attack story, including the involved source and target entities, activity timelines, and evidence-based recommendations. The portal correlates signals from Microsoft Defender for Identity with identity and service events, letting you confirm whether the alert is a true positive and determine the scope of compromise. Only after this investigation should you choose a containment or remediation action such as resetting the password or disabling the account.

Automation rules are the native incident orchestration mechanism in Microsoft Sentinel. You can define a trigger on incident creation and add actions that assign the incident to an owner, set status/tags, and invoke a playbook—a Logic App—that posts a message to Teams. This directly meets both requirements and is the intended pattern for incident assignment and notification.

The Azure Monitor Agent uses data collection rules to gather Windows or Linux security events and performance counters from the VM, forwarding them to the Log Analytics workspace that Microsoft Sentinel ingests. This supplies the telemetry analysts need during incident response.

Microsoft Entra ID P2 licenses are a hard prerequisite for UEBA because Sentinel derives user entity behavior across the identity plane from Microsoft Entra ID Protection, which only emits risk signals and rich user context under a P2 license (e.g., risk detections, risky sign-ins, and user risk history). Without P2, the identity baseline that Sentinel's UEBA machine-learning models rely on is never populated, so user-centric anomaly detection cannot be calculated even though other data sources are connected.

Automation rules in Microsoft Sentinel are the native orchestration mechanism that can trigger on incident creation (or status change) and execute a playbook. A playbook built in Azure Logic Apps can include the 'Add tag' action from the Sentinel connector, which appends the desired tag to the incident. This directly satisfies the requirement by applying the tag automatically, and it is the documented method for enriching incidents with custom labels because analytics rules and watchlists lack this capability.

A full antivirus scan is an available device response action in Microsoft Defender for Endpoint, running alongside quick scan to detect and remediate malware on the compromised endpoint. It supports containment and eradication without isolating the device or requiring manual intervention.

Correct. DeviceNetworkEvents is Microsoft 365 Defender's advanced hunting table for actual network connection sessions, capturing fields such as Timestamp, DeviceName, RemoteIP, RemotePort, and direction. Filtering on DeviceName == 'deviceA' and Timestamp > ago(1h) isolates only that host's traffic over the last hour, and projecting then ordering by Timestamp ascending gives a precise chronological timeline of each connection for investigation.

In the context of a Sentinel incident, external sharing on SharePoint sites is a common data exfiltration vector when accounts are compromised. Removing external sharing permissions—via the SharePoint admin center or PowerShell cmdlets like Set-SPOTenant -SharingCapability—immediately revokes external users' ability to access shared links, cutting off the attacker's current path to exfiltrate data. This is a direct containment action at the data plane, and it is crucial to perform before or alongside user-level blocking to stop exfiltration that has already been enabled.

DeviceNetworkEvents lacks a RemoteIPType column, so referencing it makes the query fail silently or return nothing. The schema exposes RemoteIP, RemoteUrl and RemotePort instead; filtering public addresses requires an ipv4_is_private() or similar check on RemoteIP. This schema mismatch, not the SMB filter, explains the empty result set.

Microsoft Sentinel permits analysts to classify incidents as False Positive, meaning the alert was triggered but represents no genuine malicious activity. It is one of the platform's built-in classification values used to close incidents and tune analytics rules.

Actions in a Microsoft Sentinel automation rule are the operational steps that execute when the rule's trigger and conditions are satisfied. These include invoking playbooks, modifying incident severity, assigning ownership, adding tags, or closing the incident. Actions run sequentially in the order defined in the rule and are the only components that actually change the state of the incident or perform external responses.

Entity pages in Sentinel are the correct investigation surface because they aggregate everything known about a specific entity (user, host, IP, mailbox, etc.) into a single timeline, including related alerts, incidents, bookmarks, and anomalies. They leverage UEBA to present risk scores, behavioral insights, and peer anomaly comparisons, which are essential for understanding whether the entity is compromised or merely active. This entity-centric view directly supports the 'entity timeline' requirement that other tools lack.

IdentityLogonEvents is the advanced hunting table that stores authentication events for identities across Azure AD and on-premises Active Directory, including both cloud-based and hybrid sign-ins. It includes the user principal name, the source IP address, the application or service targeted, and the authentication result, which makes it the correct table for reviewing a suspicious cloud sign-in IP. Analysts can filter by Timestamp, AccountUpn, and IPAddress to isolate the specific login attempt.

DeviceFileEvents is the correct table because it records every file creation, modification, rename, and deletion event on endpoints via Microsoft Defender for Endpoint, including the file's SHA1/SHA256 hashes, full path, device ID, and timestamp. This makes it ideal for a query that screens all devices for a specific malware hash, since the file must exist on disk before it can be executed or otherwise cause network activity. The table is filesystem-centric, so it directly identifies affected machines regardless of whether the file has been run.

The Submissions page in Microsoft Defender XDR is the centralized, dedicated queue for user-reported messages, surfaced through the Report Message and Report Phishing add-ins in Outlook. It provides security admins with the message details, report type, and source, and allows them to triage, analyze, and take remediation actions such as release, purge, or submit to Microsoft for analysis. This page is the only location specifically designed to display what users have manually flagged, making it the correct place to find user-reported messages.

AzCopy transfers data directly into Azure Blob Storage over HTTPS, satisfying the requirement to securely upload forensic artefacts from an unmanaged Linux host. Because the server lacks Microsoft Defender for Endpoint, the built-in live response collection is unavailable, so a manual script paired with AzCopy provides the supported upload path.

The summarize operator is the core aggregation mechanism in Kusto Query Language, grouping rows by one or more key columns and applying an aggregate function such as count(), sum(), or dcount() to each group, returning a single row per unique combination of those keys. In a Microsoft Sentinel context, using summarize with count() is the direct way to produce event counts by entity, user, or time interval, especially when combined with the bin() function for time-bucketed counts. This operator is functionally equivalent to SQL's GROUP BY and is indispensable for creating security analytics that require totals, averages, or distinct counts across segmented data.

Vulnerability assessment in Microsoft Defender for Cloud uses an integrated scanner, like Microsoft Defender Vulnerability Management or Qualys, to continuously inspect VMs for known CVEs, missing OS patches, and security misconfigurations. This scanner evaluates the guest operating system state and correlates findings against vulnerability intelligence to produce actionable recommendations such as 'Machines should have vulnerability findings resolved.' Therefore, it is the only listed option that directly identifies missing security updates and is the correct control for this scenario.

Automation rules respond to incident creation by applying triage actions, and owner assignment is one of the supported operations. The rule can route an incident to a named analyst or group automatically, removing manual queue handling without invoking a logic app.

Creating automation rules to triage incidents is a core security operations management task because it directly shapes how the SOC handles alerts. Automation rules can assign incidents to analysts, apply custom tags, suppress false positives automatically, and trigger playbooks for standardized response actions. By embedding triage decisions into Sentinel, the SOC reduces response time and ensures consistent handling according to established procedures.

Analytics Rules (also called scheduled or incident creation rules) are the correct mechanism in Microsoft Sentinel for correlating alerts from multiple security products into a unified incident. These rules are built on Kusto Query Language (KQL) and can use entity mapping and alert grouping to combine multiple separate alerts—whether from Microsoft Defender, Azure, or third-party connectors—into one incident based on common entities and a defined time window. When a query returns results and incident creation is enabled, Sentinel creates an incident enriched with the matching alerts, which is exactly what a threat hunter needs for correlation.

Incident assignment to analysts is a core incident management feature that directly supports organization and triage by designating a specific owner for each incident. This establishes accountability, prevents duplicate overlapping work, and makes it clear who is responsible for investigation and resolution. Assignment is an operational state that structures workflow, unlike enrichment or reporting features.

Resetting the compromised user's password and revoking all active sessions directly invalidates the stolen credentials—making any cached NTLM hashes, Kerberos TGTs, or delegating artifacts unusable for further authentication. Revoking active sessions (e.g., forcing sign-out or invalidating refresh tokens) ensures that any already-established remote sessions are terminated immediately, rather than waiting for ticket expiry. This stops lateral movement regardless of which workstation the attacker is using or which network path they choose, because the root cause—compromised identity—has been remediated.

Collecting an investigation package from a device is a legitimate Defender for Endpoint response action that bundles the device's relevant forensic artifacts—such as the registry, running processes, network connections, and memory information—into a zip file for offline analysis. It is initiated through the device's action menu, and the package is stored in secure storage for the analyst to download. This action is complementary to isolation and is used to gather evidence without requiring a live remote-command channel to the device.