CCNA Respond to security incidents Questions

Microsoft Entra ID sign-in logs record authentication events, including the originating IP, device and conditional access outcome. They satisfy the lateral movement requirement by exposing credential reuse or anomalous sign-ins from compromised accounts moving between Azure resources.

A SharePoint app connector enables Defender for Cloud Apps to proxy sessions, and a session policy scoped to jdoe, the ExecConfidential site and the Unmanaged device tag applies Block download in real time, satisfying the requirement to prevent sensitive file downloads from unmanaged devices.

The device timeline, also known as the process timeline, is the correct answer because it provides a chronological view of events and a visual representation of the process tree, including parent-child relationships. This allows an analyst to trace an attack chain from initial access to execution, observing how each process was spawned and what actions it performed. It is a core DFIR tool in Microsoft Defender for Endpoint for investigating a single device's historical activity.

Suspending the user account in Microsoft Entra ID immediately disables the account, preventing the user from authenticating and blocking issuance of new access tokens across all Entra ID-integrated cloud applications, including Exchange Online, SharePoint, and Teams. This is the most direct and comprehensive identity-centric containment action because it removes the attacker's ability to log in regardless of endpoint, IP, or session state. It also stops password-based and token-based access at the source, making it the preferred first step in responding to a compromised identity.

The Investigation graph is the correct tool for incident investigation because it presents an interactive, visual map of entities (such as hosts, IPs, and accounts) and their connections to alerts and activities. It allows analysts to expand nodes to explore related entities, assess blast radius, and pivot directly into other data sources, making it purpose-built for correlating and understanding a specific incident's scope.

Disabling accounts stops further misuse.

Revoking all current sessions immediately invalidates the access tokens, refresh tokens, and session cookies that have already been issued to the user, terminating any active attacker foothold in real time. This is a containment-first action because it stops ongoing malicious activity without waiting for password changes or conditional access checks. However, it only disrupts existing authentications; it does not prevent future sign-ins, so it must be paired with disabling the account to block new authentication attempts.

DeviceNetworkEvents supplies the outbound connection telemetry — remote IP, port, and URL — that mshta.exe generated when fetching the remote script. This directly confirms the LotL attack by correlating the process execution already surfaced in the hunting query with the actual command-and-control or payload download destination, satisfying the requirement to verify external network contact.

Querying EmailEvents in Microsoft Sentinel's advanced hunting tables returns the specific email, recipient, delivery action and verdict, tying the phishing message to the affected user. This satisfies the stem's triage requirement by scoping the incident to concrete evidence before remediation.

Automation rules are the native Sentinel mechanism that runs on incident creation or alert creation and can perform actions like assigning ownership, changing status, or invoking a playbook (Logic App) via a trigger. When an automation rule is configured to run a playbook, it uses the alert trigger or incident trigger in the Logic App, passing the alert payload. This is the direct answer to the question because automation rules bridge detection to response. They are the correct trigger mechanism.

The Investigation graph maps the incident's entities—accounts, hosts, IPs—and their linked events, letting the analyst pivot across the failed-then-successful logon sequence and unusual location in one view, satisfying the need to rapidly gather context before deciding whether the activity is malicious.

This option is correct because the query explicitly examines command-line arguments for the '-EncodedCommand' parameter, which is a well-known PowerShell feature that attackers abuse to obfuscate malicious scripts. When an encoded command is present, the actual script is a Base64-encoded string, making static detection more difficult and justifying a suspicion review. Security analysts use such queries in advanced hunting to surface potentially hidden or obfuscated PowerShell activity.

Collecting investigation packages from affected devices is appropriate because it captures volatile forensic artifacts—such as running processes, active network connections, registry keys, and loaded drivers—in their current live state. This package enables analysts to identify Indicators of Compromise (IOCs), the initial access vector, and the full lateral movement scope without altering or destroying evidence. It is a non-disruptive collection action that complements containment, ensuring the investigation has the data needed to understand the outbreak before any cleanup begins.

Adding a condition to the rule query to filter out known legitimate user agents is the targeted fix because it directly removes the benign UserAgent strings from the anomaly-detection scope. In KQL, you can implement this with a `where UserAgent notin (~['LegitAgent1', 'LegitAgent2'])` clause or a regex pattern like `where UserAgent !matches regex @"(Chrome/120\.0|Edge/120\.0)"`, preserving the rule's ability to detect truly anomalous strings. This approach reduces false positives while maintaining full detection fidelity for other anomalous sign-in attributes such as geographic location, device compliance, or risk score, aligning with Sentinel best practices for rule tuning.

Custom network indicators in Microsoft Defender for Endpoint let you block outbound traffic to a specified IP across all onboarded devices, using the existing agent rather than adding network appliances, satisfying both the immediate block and organisation-wide enforcement.

Device isolation should be initiated from the Microsoft 365 Defender portal on each affected endpoint. This action immediately blocks all inbound and outbound network communications, except traffic to the Defender service, so the attacker loses the ability to move laterally, communicate with command-and-control servers, or exfiltrate data while the investigation continues. It is the first-line containment control when an active infection is confirmed.

Suspicious domains and URLs are network-based IOCs that Microsoft Sentinel matches against DNS, proxy, and firewall logs to surface command-and-control beaconing and phishing infrastructure. They satisfy the APT detection requirement because advanced persistent threats routinely rely on domain generation algorithms and compromised legitimate sites, making domain and URL indicators high-fidelity detection signals.

Disabling the account in Microsoft Entra ID blocks cloud sign-in, while a playbook running PowerShell disables the on-premises Active Directory account, containing the Kerberos-based compromise across both environments. Disabling rather than deleting preserves the account for forensic analysis.

Isolating the device via Microsoft Defender for Endpoint severs network communication while retaining the machine's live state, memory and forensic artefacts. This contains the ransomware's spread and preserves evidence, satisfying the requirement to contain the threat without destroying data needed for investigation.

Applying the vendor workaround mitigates the CVSS 9.8 exposure immediately without downtime, since no patch exists, and the custom remediation task tracks the risk until a permanent fix arrives. This satisfies the stem's requirement to remediate quickly while minimising downtime.

The query first filters to only alerts where the title equals 'Suspicious process injection', then uses `summarize count() by CompromisedEntity, Severity` to compute how many alerts fall into each entity/severity bucket. Finally, it orders the aggregated results by the count in descending order, so the highest-frequency entity/severity combinations appear first. This exactly matches the stated purpose.

Disabling the user account in Microsoft Entra ID is the most effective first containment step because it immediately blocks all authentication attempts, including the attacker's stolen credentials, and prevents access to all Microsoft 365 and cloud resources that depend on Entra ID. Even if the attacker holds a valid session token, disabling the account stops new sign-ins and is a strong, reversible measure that preserves the user profile and forensic data for investigation. In Microsoft Defender XDR incident response, this is the recommended manual action to halt attacker activity without deleting any evidence.

The OfficeActivity table in Microsoft Sentinel contains audit logs from Microsoft 365, including SharePoint Online and OneDrive for Business. It records events such as FileDownloaded, FileAccessed, and FileUploaded, along with user and file details. Querying this table allows you to analyze the user's file download activities and assess the volume and sensitivity of the files involved.

Automation rules are Sentinel's native, rule-based engine for incident lifecycle automation, evaluated when an incident is created or updated. They support one or more conditions (e.g., severity, title, entity) and multiple actions, including setting the incident status to 'Resolved/Closed' and specifying a closure classification and comment. Because they are first-class components that directly execute incident-state changes without external dependencies, they are the definitive mechanism for automatically closing incidents.

Reviewing the alert details in Microsoft Defender for Cloud confirms the specific vulnerability and affected resource, then applying the documented remediation steps contains the threat. This validates before acting, satisfying the requirement for the best immediate action rather than unverified escalation or disabling the virtual machine.

Suspending the user in Defender for Cloud Apps is the correct immediate governance action because it directly targets the user account, revoking active sessions, invalidating access tokens, and blocking future sign-ins to connected cloud apps. This identity-level action is precise, affecting only the suspicious account without impacting other users who might share an IP address, and it stops the ongoing activity in real time. Defender for Cloud Apps can apply this action via the underlying app's API, ensuring that the suspension propagates across all managed cloud services as a consistent and immediate containment measure.

Disabling the account in Microsoft Entra ID (for cloud-only accounts) or Active Directory (for on-premises or hybrid accounts) is the definitive containment step. For a hybrid environment, you should disable the account on-premises first, as Azure AD Connect will synchronize the disabled state to Entra ID; for a cloud-only account, you can disable sign-in in Entra ID. This immediately prevents any new authentication attempts, including Kerberos, NTLM, or interactive logon, and blocks DCSync because the account can no longer request a TGT or authorize replication. This is the only option that fully neutralizes the compromised account.

Disabling the account in Microsoft Entra ID immediately blocks further authentication and token issuance for the compromised identity, containing the incident while investigation continues. This directly satisfies the stem's requirement to contain a suspicious sign-in from an unusual location.

Encoded PowerShell is a legitimate administrative technique, so a detection rule flagging encoded commands matches benign activity and inflates false positives. The query's logic keys on encoding itself, which is not inherently malicious, satisfying the stem's constraint that the rule triggers on common legitimate behaviour.

Attackers persist by creating hidden inbox forwarding rules and granting delegated mailbox access, so removing these first severs the attacker's ongoing access to the compromised mailbox. Containment precedes broader remediation such as password resets or investigation, satisfying the requirement to remove access immediately.

The rule's condition filters on High severity, so a Low-severity incident falls outside its trigger scope entirely. Microsoft Sentinel evaluates automation rule conditions against incident properties at creation; severity mismatch prevents any playbook run, regardless of the alert title. Raising the incident's severity or broadening the rule condition would allow execution.

The Microsoft Defender for Cloud connector is the data ingestion pipeline that brings security alerts from Defender for Cloud into Microsoft Sentinel. If this connector is disabled, not connected to the correct subscription, or has misconfigured diagnostic settings, no Defender for Cloud alerts reach the Sentinel workspace, so no incidents can be generated from them. Without this connector enabled, all other components—analytics rules, automation, and playbooks—have no alert data to act upon.

Automatic attack disruption in Microsoft Defender XDR executes active containment responses—such as isolating devices or blocking indicators—based on real-time endpoint signals. These signals only exist when devices are onboarded to Microsoft Defender for Endpoint, which deploys the sensor and enables EDR in active mode. Without onboarded endpoints, the service has no telemetry to trigger or apply disruption actions.

Fusion correlation in Microsoft Sentinel links low-fidelity alerts and anomalies across multiple products into a single incident, identifying multi-stage attack progressions that individual detections miss. This directly satisfies the stem's fusion alert scenario, where the SOC receives one consolidated incident rather than separate, unrelated alerts.

Disabling the account in Microsoft Entra ID immediately blocks further sign-ins and revokes the compromised privileged identity's access, containing the incident before deeper investigation. It directly addresses the need to contain a suspicious privileged sign-in fastest.

This query aggregates SQL injection alerts by source IP and ranks them by count, so the primary purpose is to surface the IP addresses that trigger the most alert activity. High counts over the selected time range are a strong indicator of an ongoing or repeated attack campaign, and this output directly supports triage, investigation, and potential blocking. The query does not need additional context to fulfill this goal because the aggregation itself is the intended result.

Modifying the analytics rule is the correct action because it directly addresses the root cause of the false positives by adjusting the rule's query logic, threshold, or entity-specific filters. For example, you can add exclusions for known benign IP addresses, increase the aggregation window count, or refine the KQL query to be more context-aware. This persistent tuning prevents recurrence, reduces alert noise, and maintains security coverage for real threats.

The Microsoft 365 Defender action center aggregates manual and automated remediation actions across Defender for Office 365 and other workloads, and in multi-tenant environments it allows a global operation such as blocking a sender’s email address to be applied to all affected tenants simultaneously. This action is enforced at the transport layer, ensuring malicious mail is intercepted before delivery. It is the designed workspace for centralized threat containment, unlike per-tenant management portals.

When suppression is enabled, after the rule successfully generates an alert, Sentinel will not create any new alerts for the configured duration, even if subsequent query executions return matching results. This is a post-detection quiet period designed to avoid alert fatigue from repeated identical findings. The suppression timer resets only when a new alert is actually created, and the rule continues to run queries but suppresses their alerts until the duration lapses.

Advanced hunting in Microsoft Defender XDR lets you query raw telemetry across the entire Microsoft ecosystem—endpoints, emails, cloud apps, identities, and more—using Kusto Query Language (KQL). You can perform multi-table joins to correlate low-level events, like a suspicious PowerShell process on one device that contacted a malicious URL previously phished in an email. This unified schema is built specifically for proactive and reactive incident hunting and is the correct native tool for a cross-domain Defender XDR incident.

Reporting submits the email to Microsoft for analysis, which updates the threat intelligence and improves automated detection for the whole organization. In MDO, this can be done via the User-reported messages report or the built-in Report Message add-in. This action also allows the security team to investigate the incident and potentially automate remediation policies.

This is correct because the trigger explicitly references an incident creation event and includes a condition that checks the incident's severity equals High. Only new incidents that meet this severity requirement will activate the playbook; all other incidents will be ignored by this trigger. The condition is evaluated as part of the incident creation flow, so the playbook runs immediately when a High-severity incident is born.

Initiating a live response session and running the 'isolate device' command is the correct action because live response gives the analyst a remote shell on the endpoint, enabling collection of volatile evidence (processes, network connections, persistence artifacts) before the environment changes. The 'isolate device' command disconnects the device from the network and blocks inbound and outbound communication except for the connection to the Microsoft Defender for Endpoint service, which keeps management and forensic collection channels open. This combination contains the immediate threat by cutting off the attacker's network access while preserving forensically sound data needed for deeper investigation.

The rule's match condition uses RemoteAddr as the source operand, IPMatch as the operator, and the literal value '10.0.0.1', meaning it matches requests whose client IP is exactly 10.0.0.1. The action specified is 'Block', so any request from that source IP is denied. Consequently, it correctly blocks traffic originating from that single IP address.

In Microsoft Defender for Cloud Apps, the correct approach is to create an IP address group that represents the country in question, using Defender for Cloud Apps' built-in country-based IP classification or by uploading custom ranges. Then, you configure a session policy with an access-control action set to 'Block' and a filter that matches the 'IP group' to the newly created group. When a session policy is active, Defender for Cloud Apps intercepts the session in real time and denies access from that country, providing granular, app-specific enforcement.

UEBA (User and Entity Behavior Analytics) in Microsoft Sentinel builds individual baselines from historical sign-in patterns, role assignments, and user activities, then applies machine learning to detect anomalies such as unusual privilege escalation or impossible travel. Because it focuses on behavioral deviations rather than static rules, UEBA is specifically designed to surface the kind of account misuse associated with compromised credentials.

Device isolation severs network connectivity while preserving Microsoft Defender XDR communication, immediately halting lateral spread and further encryption across affected endpoints. This containment satisfies the requirement to stop the threat first, before investigation or remediation, and is executed directly from the incident view.

Placing the mailbox and OneDrive on litigation hold preserves all existing and future content immutably, preventing deletion or alteration during investigation, which satisfies the evidence-preservation requirement. This retention mechanism operates independently of the user, unlike simple export or backup copies.

Disabling the user account in Microsoft Entra ID is the correct immediate containment action because it sets AccountEnabled to false, blocking the compromised identity from authenticating to Microsoft 365 and Defender services that host the data. This action directly interrupts the active download session and prevents the entity from initiating new requests, regardless of whether the device itself is managed, and it does so quickly enough to limit data loss. As a side benefit, it preserves the unmanaged device's source IP and activity logs for later forensic analysis without giving the attacker a warning.

This is the correct conclusion because the Get-MpThreat output shows both DidThreatExecute is False and IsActive is False. DidThreatExecute=False confirms that the threat did not run, while IsActive=False confirms it is not currently present or running, which aligns with a blocked state. In Microsoft Defender, a threat that was blocked before execution typically has these exact field values, indicating the attack was prevented.

The rule does not have incident grouping enabled, which means each time the scheduled query fires and creates an alert, Sentinel provisions a brand-new incident instead of attaching the alert to an already open incident. In the analytics rule's Incident settings, the 'Group related alerts into a single incident' option is either unchecked or set to 'do not group,' resulting in a one-to-one alert-to-incident relationship. Consequently, the second brute-force attempt generates a new incident rather than updating the existing one, exactly as described in the exhibit. Enabling grouping with an appropriate entity (e.g., target username) and time window would cause subsequent alerts to update the original incident.

A time-based condition inside the playbook logic evaluates the current time before triggering isolation, satisfying the business-hours constraint. However, Microsoft Sentinel playbooks are Logic Apps, so this check must use a built-in date/time expression or condition action, and the recurrence trigger still fires around the clock.

From an incident, expanding the user entity in Microsoft Sentinel exposes entity actions, and Disable user account performs the Microsoft Entra ID account disablement in place. This satisfies the runbook requirement to stop the attacker from authenticating while keeping the object recoverable, because disabling blocks sign-in but does not delete or alter the account's data, so access can be restored after remediation completes.

Alert grouping is a built-in setting in Sentinel analytics rules that determines when a new incident should be created versus when an alert should be added to an existing incident. You can group by entity, by alert attributes, or within a specified time window, and you can also set the incident title. This directly reduces alert fatigue by consolidating related alerts, making it the correct answer.

Reviewing the alert details in the Microsoft Defender for Identity portal is the correct first step because the portal aggregates the pertinent events, users, devices, and related alerts into an investigation experience. From the alert page, you can access the full timeline, examine the underlying activities, and pivot to entity profiles, which lets you validate whether the alert is a true positive and understand the attack chain. This analysis provides the context needed to decide on any subsequent containment or remediation.

SecurityEvent is the correct table because it contains Windows Security event logs, including Event ID 4624 (successful logon) and 4625 (failed logon), which are essential for RDP investigations. When an RDP session is established on a Windows VM, the local Security channel generates a 4624 with LogonType 10 (RemoteInteractive), and this data is sent to Sentinel via the Windows Security Events data connector (using either the legacy Log Analytics agent or the Azure Monitor Agent). From this table you can query the source IP, source port, and account that performed the RDP logon to identify indicators of compromise. Thus, SecurityEvent is the authoritative and most direct source for RDP logon activity in Microsoft Sentinel.

The 'MicrosoftThreatProtection' connector (also known as the Microsoft 365 Defender connector) exclusively ingests incident and alert data from Microsoft Defender XDR components such as Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps. Defender for Cloud alerts are delivered via the 'AzureSecurityCenter' (now 'Microsoft Defender for Cloud') connector, which is a separate data source with its own connector type. Because the ARM template only includes the MicrosoftThreatProtection connector, Defender for Cloud alerts would never appear in Sentinel, making this the correct explanation for the issue.

Initiating a live response session on the endpoint and executing a PowerShell script is the correct action because it provides a remote, audited shell that can directly interrogate the system's persistence mechanisms. The script can enumerate Services, Run keys, scheduled tasks, WMI event subscriptions, and other autostart locations to determine whether the attacker left behind a way to re-enter. This aligns with MDE's incident response workflow, allowing you to collect evidence and remediate instantly without taking the device offline.

Automation rules are Sentinel's native orchestration mechanism that can trigger on alert creation and perform actions such as creating an incident, assigning an owner, changing severity, and running playbooks. By configuring a rule that runs when the alert is generated, you ensure the incident is created with the security team as the owner in one atomic step. This approach centralizes lifecycle management and is recommended over manual playbook or analytics-rule-only configurations for consistent ownership.

Threat Explorer permits soft-deleting the delivered phishing message from the mailbox, removing the threat, while a Safe Links policy rewrites and blocks the malicious URL at click time for all users, addressing the recurring external-vendor vector. Together they remediate the current incident and prevent recurrence.

Threat Explorer in Microsoft Defender for Office 365 provides real-time, detailed reporting on email threats, letting analysts filter by URL clicks and identify exactly which recipients interacted with the malicious link during the phishing campaign investigation.

The Incident details pane includes an Entities tab where the entity timeline displays a chronological sequence of activities associated with entities such as IP addresses, hosts, and accounts. This view aggregates data from multiple sources—including alerts, events, and logs—allowing the analyst to see what an IP did before, during, and after the incident. It requires no additional configuration and directly supports the investigation by revealing behavioral patterns and attack paths.

App governance policies in Defender for Cloud Apps are specifically designed to govern OAuth apps and can perform automated actions such as disabling or blocking an app when suspicious behavior is detected. When a policy triggers, it can block the app from accessing resources and send notification emails to the configured recipients, including the user or admin. This directly matches the stated requirement, making it the correct choice.

Live response in Microsoft Defender for Endpoint is the correct forensic data collection method because it provides an interactive, audited remote shell on the device. Once the device is online, you can run built-in commands such as 'collect' to capture evidence like running processes, registry data, event logs, and sensitive files in a structured package. Unlike manual methods, this session uses Microsoft's authorized API and records all commands for chain of custody, making it the preferred incident-response approach.

Opening the incident details and examining the timeline and entity mapping is the correct first step because it shows the sequential events of the attack and the relationships between involved entities such as users, hosts, and IP addresses. Sentinel's fusion engine generates this correlation by combining multiple low-fidelity alerts across the attack chain, and the timeline helps you see if the alerts are sequentially connected. The entity mapping directly reveals shared indicators that might otherwise look disconnected when reading alert titles alone.

The incident timeline aggregates alerts, bookmarks and entities from every connected data source into a single chronological view, satisfying the requirement to correlate related activities across sources during an investigation. Unlike hunting queries, which return raw results per query, it presents the whole incident's progression in one pane.

Contain device isolates the server from the network via Microsoft Defender XDR while preserving the live session for investigation, immediately halting encryption and lateral spread. This satisfies the stem's requirement for the most immediate containment action against active ransomware.

Submitting the suspicious email via the Submissions page sends the original message and attachments to Microsoft for detonation and signature analysis, satisfying the need to report and analyse the threat. This enables Microsoft to tune detection and block similar messages across the tenant.

In Microsoft Defender XDR, you can assign an incident to a specific user directly from the incident page, and you can add comments to the incident timeline. This action notifies the assignee and records your findings for collaboration. It is the standard way to hand off an incident while preserving context.

The eDiscovery Manager role group has a sub-role for Legal Hold that specifically allows managing holds on mailboxes and sites. This is the required identity to place a mailbox on hold in the Microsoft Purview compliance portal. Without this sub-role, even other eDiscovery roles cannot place holds.

Collecting the investigation package gathers volatile forensic artefacts — running processes, scheduled tasks, network connections and autorun entries — from the compromised device before remediation alters them. This satisfies the stem's requirement to preserve evidence first, whereas isolating or remediating the device would destroy the volatile data needed for later analysis.

Safe Links policies are specifically designed to protect users from malicious hyperlinks by rewriting URLs and checking them against Microsoft's threat intelligence plus your custom block list. Adding the malicious domain to the blocked URLs list causes any link containing that domain to be blocked or to trigger a warning when clicked, even if the email's sender appears benign. This directly addresses the attack vector—the embedded URL—rather than the email's origin, making it the correct control.

The Microsoft Entra ID connector's 'Update user' action writes directly to the directory object, letting the playbook set accountEnabled to false and immediately block sign-in. This satisfies the requirement to suspend the user automatically upon the Defender for Cloud Apps incident trigger.

Assigning an incident to a user is a valid incident management action that designates an owner responsible for investigation and resolution. It establishes accountability, enables tracking of workload, and allows metrics to be based on individual or team performance, all within the Microsoft Sentinel incident workspace.

The incident timeline in Microsoft Defender XDR aggregates alerts and activities chronologically, helping you pinpoint the initial alert and affected entities. This provides the entry point and scope, enabling efficient triage. Other options may be useful later but do not directly answer the immediate need.