CCNA Respond Security Incidents Questions

Creating a custom indicator of compromise (IoC) for the specific file hash, with the action set to Block and remediate, is the precise and recommended response. This indicator is propagated to all devices through Microsoft Defender XDR, preventing the file from executing and automatically triggering remediation of existing copies on any onboarded endpoint. Because the block is scoped solely to that file hash, legitimate applications are preserved, avoiding false positives, and the defense persists for future attempts to execute or download the file.

Microsoft Defender for Endpoint's live response feature provides a remote shell to the non-domain-joined Windows 10 device, where the memory dump can be captured using its built-in commands. This satisfies the remote acquisition constraint without physical access or domain membership.

Isolating affected devices using Microsoft Defender for Endpoint is the correct first step because it immediately blocks all incoming and outgoing communication to and from the compromised host, cutting off the ransomware's ability to spread laterally and communicate with command-and-control servers. This action preserves forensic evidence while containing the attack, and it can be initiated remotely from the MDE console without requiring physical access or disrupting the rest of the network. Full isolation still allows the Defender service to communicate, so security teams can continue to investigate and remediate the endpoint.

Viewing related entities such as IP addresses is a core Sentinel investigation action, letting analysts pivot from an incident to the associated hosts, accounts and addresses on the entity graph. This satisfies the stem's requirement for valid investigation actions, since entity exploration is built into the incident investigation experience.

Microsoft Defender for Cloud Apps governance actions apply remediation directly to connected apps, letting the analyst disable the offending Power Automate flow from within the alert. This stops the exfiltration immediately without leaving the portal, matching the requirement to disable the flow at once.

In Microsoft Sentinel, incident ownership is controlled by the Owner field in the incident details pane; setting it to the senior analyst formally assigns the incident to them, making it appear in their 'My incidents' view and routing any notifications according to the workspace's settings. Updating the owner preserves the incident's original ID, entity links, evidence, and full audit history, which is critical for accurate incident response documentation. This action is the recommended way to escalate an incident for additional review.

Isolating the affected device from the network breaks the attacker's ability to use the compromised host to authenticate to other systems via pass-the-hash, effectively containing the lateral movement at the source. This is an immediate containment action that limits the blast radius while preserving process memory and network evidence for forensic analysis. In Microsoft Defender for Endpoint, 'Isolate device' blocks all inbound/outbound traffic except to the Defender service.

The 'Isolate device' action in Microsoft Defender for Endpoint disconnects the device from the network except for the Defender for Endpoint service, allowing you to remotely investigate and remediate. This meets the requirement of isolating the device while maintaining a management channel. It is the correct containment action for a compromised device.

Isolating the device with Microsoft Defender for Endpoint's device isolation feature is the correct initial response because it severs all inbound and outbound communication except to the Defender service, immediately containing the threat while keeping the device powered on. When forensic preservation mode is enabled, the device remains in a state that preserves volatile evidence and prevents file system changes, allowing security analysts to investigate the compromise, collect artifacts, and remediate without losing critical data—all through a centrally managed, reversible action.

Automation rules in Microsoft Sentinel trigger on incident creation and can set owner, status or severity. Configuring one with a severity condition of High or above automatically assigns matching incidents to the senior analyst tier, removing manual triage effort.

Disabling the account in Active Directory immediately blocks further authentication, stopping the unauthorised access while the account and its activity remain intact for forensic review. Containment first prevents additional damage before broader investigation or remediation.

An automation rule triggers on incident creation and launches a playbook, which executes the Logic Apps workflow calling Microsoft Entra ID to disable the compromised account. This satisfies the requirement for automatic response without manual analyst intervention.

Disabling the account in Microsoft Entra ID and revoking all sessions immediately cuts off the attacker's access, containing the incident before scope investigation. This neutralises the compromised identity across SharePoint, Defender XDR workloads and conditional access, which is the priority containment step.

Devices are a primary managed entity in Microsoft Defender XDR. In Defender for Endpoint, every onboarded workstation, server, and mobile device is represented in the Device inventory and can be isolated, scanned, excluded from automated investigation, or added to a device group. Because device context drives alert correlation across identity, email, and data protection, the device is a core entity for XDR incident management.

The Incident timeline is the correct feature because it provides a chronological, visual view of all alerts, bookmarks, and related activities associated with a specific incident. This timeline lets analysts quickly reconstruct the attack sequence, correlate events, and understand the full scope of the incident in one place. It is the primary view used during incident triage and investigation in Microsoft Sentinel.

Suspending the account prevents further access immediately.

Blocking known malicious IP addresses at the firewall is a direct and immediate containment action that severs the network communication path between the compromised environment and the attacker's command-and-control (C2) infrastructure. By applying egress and ingress rules to deny traffic to these IPs, you cut off remote commands, data exfiltration, and potential malware downloads, thereby limiting the adversary's operational control without disrupting normal business traffic.

AzureActivity data is regional; the West Europe VM's activity logs are only written to a workspace in that region unless explicitly streamed. Routing them into the East US workspace ensures the analytics rule can correlate all evidence for the incident.

An automation rule in Microsoft Sentinel is the correct mechanism for incident-driven response: it evaluates incidents the moment they are created, matches configured conditions (e.g., severity, entity, tactic), and immediately executes a playbook. This is event-driven, consistent, and removes the need for analyst intervention, aligning with the scenario's requirement to automate incident-created actions.

Just-in-Time VM access in Microsoft Defender for Cloud allows you to control inbound traffic to management ports (RDP/SSH) by enforcing approved source IPs and time windows. When an incident occurs, you can configure JIT to deny all inbound traffic to the VM, effectively isolating it from the network while the VM remains powered on for forensic collection. This non-destructive containment preserves the VM's memory, disk, and logs for investigation, unlike deletion or shutdown.

Automation rules in Microsoft Sentinel respond to incident creation events, and can filter on the alert's product source being Microsoft Defender for Endpoint. Triggering the playbook this way runs the MDE API memory dump collection automatically, satisfying the requirement without manual intervention.

Running a playbook that invokes the Microsoft Defender for Endpoint 'Isolate device' action is the correct containment response because it actively disconnects the endpoint from the corporate network while preserving a connection to the MDE cloud service for management and forensics. This action terminates all network traffic to and from the device (except low-level MDE communication), immediately stopping data exfiltration and command-and-control traffic. In Sentinel, this playbook can be triggered automatically or manually and is the only listed option that provides a network-level isolation layer.

A session policy in Microsoft Defender for Cloud Apps operates via reverse-proxy conditional access app control, giving you real-time, action-level visibility and enforcement. By setting the 'block download' action alongside other file-related controls, the policy inspects every HTTP transaction and can block a download request while still allowing viewing or other cloud-app activities. This is the only option here that directly targets downloads as a discrete action rather than toggling all-or-nothing access to the application.

Resetting the account's password invalidates the compromised credentials that an attacker may be using, and enabling MFA adds a second authentication layer that blocks unauthorized re-entry. This is the required remediation step before restoring the account because it directly addresses the known compromise of the identity itself. Without this step, any restoration action would leave the account vulnerable to immediate re-compromise, as existing tokens or cached credentials could still be leveraged.

The correct first step is to open the incident in Microsoft Sentinel and review its details to verify the alert is a true positive. This means checking the incident's severity, status, entities, MITRE ATT&CK tactics, and the raw data or logs that triggered the analytics rule, then correlating it with other alerts on the same resource to confirm the activity is genuinely malicious. Only after this validation should you decide whether to contain, investigate, or escalate, because taking response actions on an unverified false positive can cause unnecessary damage.

A playbook is an Azure Logic Apps workflow and can include the Microsoft Teams connector, which enables sending an adaptive card to a designated Teams channel and using the approval action to wait for a Yes/No response from a user. This directly delivers a human-in-the-loop checkpoint that blocks subsequent steps until the approver decides, satisfying the need for approval in the incident response process. Once the response is collected, the playbook can branch to different actions based on the outcome, making it the correct mechanism for this requirement.

Threat intelligence can indicate if the IP is known malicious.

Validating the alert by checking the user's recent activity is the correct first step because it confirms whether the alert corresponds to a genuine security event, such as anomalous sign-ins, impossible travel, or suspicious mailbox activity in Microsoft Defender. By reviewing the user's sign-in logs and other evidence, you can determine the alert's true positive or false positive status, which guides all subsequent containment and remediation decisions. This triage approach aligns with incident response best practices, ensuring you act based on evidence rather than assumptions and avoiding unnecessary disruption to the user.

The incident page is the central investigation surface in Microsoft Defender XDR. It automatically aggregates all alerts related to a single attack campaign from across the Microsoft 365 security stack—Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps—into a unified view. Along with alerts, it surfaces the full attack story, affected assets, and evidence, making it the correct place to investigate the full scope of an incident. This page directly answers the need to see all related alerts in one place.

Creating a custom threat intelligence indicator for the malicious URL in Microsoft Defender for Endpoint triggers an immediate Alert/Block enforcement action on all onboarded endpoints via the built-in Network Protection component. When any user clicks the link, the endpoint blocks outbound connectivity to that URL before the content loads, regardless of the fact that the phishing email is already sitting in their mailbox. This is the fastest operational control because it addresses the actual click vector across all affected devices, not just the email envelope, and can also generate an alert for incident investigation.

Threat Explorer (part of Microsoft Defender for Office 365) provides a deep, filterable view of email activity, including sender, recipient, subject, and threat signals. You can locate the specific email(s) that match the attack, select them, and use the 'Take action' drop-down to choose 'Delete' (or 'Soft delete/Delete'), which performs a bulk removal of the message from all affected mailboxes and can optionally trigger a remediation action. This is the appropriate tool because it combines search, investigation, and remediation for already-delivered threats.

Disabling the account is the correct immediate containment action because DCSync attacks (like Golden Ticket or DCshadow pre-staging) rely on the compromised identity having directory replication permissions, and disabling it blocks that account from authenticating or invoking DRS replication any further. This directly severs the attacker's current access path and halts the unauthorized replication request without requiring a full DC restart or broad network disruption. After disabling, the SID of the account can be added to a honeytoken or monitored for any further attempts during incident response. It is the fastest, least-destructive way to stop the bleeding.

Network micro-segmentation enforces granular access control at the workload level, so even if a host is compromised, it cannot reach file servers or other critical systems, halting lateral movement and additional encryption. Taking memory snapshots contemporaneously preserves volatile forensic evidence such as encryption keys and process artifacts, which are vital for identifying the ransomware variant and potentially recovering data without paying the ransom. This approach provides both containment and evidence preservation.

When suppression is disabled, the scheduled rule has no mechanism to pause or stop additional runs after an alert is created, so it executes every hour exactly as scheduled. Because each hourly run uses a 1-day query period, the same events fall into multiple overlapping lookback windows, causing the rule to generate a new alert each time the query returns results that meet the threshold. Enabling suppression would suspend the rule for a defined period after an alert is generated, preventing overlapping and duplicate alerts from the same activity.

An automation rule is the correct choice because it executes natively and immediately when an incident is created, and it directly supports simple actions such as 'Assign owner' and 'Set severity' through conditions that evaluate incident properties at that moment. Unlike a playbook, it requires no Logic App or separate trigger, so it provides the fastest, most reliable method to impose mandatory ownership and severity settings during initial incident generation, exactly matching the requirement.

Automation rules in Microsoft Sentinel are the native, lightweight mechanism for automating incident management tasks, including assigning an owner, changing status, or applying tags, without requiring a Logic Apps connector or additional code. You can create a rule with a condition like 'When incident is created' and an action 'Assign owner' to set the incident owner to a specific user or group. This is simpler, more performant, and directly integrated into the incident pipeline compared to custom code or playbooks.

Full isolation in Microsoft Defender for Endpoint disconnects the device from all network traffic except for the Defender for Endpoint cloud service, allowing you to contain the threat while maintaining communication for investigation. It preserves forensic evidence on the device because it does not wipe or modify files. This action is appropriate for a compromised device requiring containment and evidence preservation.

Microsoft Defender for Office 365 exposes email entity actions in the incident that include soft delete, hard delete, and move to junk, letting you purge the message across all mailboxes. Submitting the sender and URL through the same workflow lets the service add them to tenant-level block entries. This directly removes the active threat and prevents recurrence, matching both requirements in the scenario.

This is the recommended remediation because Defender for Cloud Apps provides a built-in governance action that disables the OAuth app directly from the alert. Disabling the app denies the app's service principal from acquiring new tokens and revokes existing grants, effectively cutting off access to Microsoft 365 resources. This action is integrated with the investigation workflow, ensuring immediate and consistent enforcement across the organization.

Microsoft Intune device inventory and compliance reports give a centralized view of every enrolled device, including its operation system, ownership type, enrollment date, and compliance status against assigned policies. These reports also surface recent device activity, such as check-ins and policy evaluation results, which allows an analyst to pinpoint non-compliant or unmanaged devices that might be involved in data exfiltration. This is the correct tool because it directly supports identifying which devices lack the required security controls.

The query filters on ExtendedProperties parsing a key named IPAddress. If the alerts store the address under a different key or format, the dynamic field access returns null and every row is filtered out, so no results appear despite matching data existing in the table.

The attack story timeline automatically aggregates all alerts, entities, and events related to the incident into a single visual timeline. It shows the full chain of events, including process execution, network connections, and user actions, enabling rapid correlation without manual effort. This is the primary investigation view for incidents in Microsoft Defender XDR.

Isolating affected devices from the network is the correct containment measure because it immediately severs the ransomware's ability to propagate laterally via SMB, RDP, or other network protocols. This should be performed at the endpoint level (disconnecting the NIC or blocking in the switch/firewall) and ideally include domain controllers and backup servers to prevent mass encryption and credential theft. The goal is to preserve evidence and stop the incident from becoming a full-domain compromise while allowing responders to analyze the threat safely.

Running a full antivirus scan is a critical eradication step that identifies and removes malware from the affected system, including worms, trojans, and ransomware. The scan should be performed after the device is isolated to prevent the infection from spreading while the scan is in progress. It also provides valuable indicators of compromise (IOCs) that can be used for further threat hunting and to ensure the system is clean before recovery.

An analytics rule is the foundational component that uses a KQL query to detect a specific security pattern and, when matched, creates an incident in Microsoft Sentinel. Because automated responses (such as playbooks or automation rules) only operate on incidents, an analytics rule is strictly required to generate the incident in the first place. Without this rule, there is no incident object to act upon, regardless of any downstream automation.

The SigninLogs table in Microsoft Sentinel stores authentication events from Microsoft Entra ID, including interactive and non-interactive sign-ins. Querying this table within the alert time range for the affected user reveals the login success/failure status, source IP, location, MFA result, and conditional access policies applied. This is the authoritative source for validating whether the suspicious sign-in succeeded and assessing the blast radius.

Device isolation in Defender for Endpoint places the machine in a state where all inbound and outbound network traffic is blocked, except for traffic to the Defender for Endpoint cloud service. This preserves the management channel, allowing security operations to issue further commands, receive telemetry, and complete remediation while the host is quarantined from the network. It directly prevents the attacker from continuing their C2 and lateral movement, making it the correct containment action.

Playbooks are cloud workflows built on Azure Logic Apps that you can invoke from Microsoft Sentinel to automate a security response. They can be triggered by an analytics rule (automatically on alert creation) or by an automation rule on an incident, and they support actions such as isolating a compromised host, resetting credentials, opening a ticket, or sending a Teams notification. Because they run with the Sentinel connector's context, playbooks are the native mechanism for incident-triggered orchestration and satisfy the requirement for automated responses.

This is the correct behavior for the rule's grouping settings. Microsoft Sentinel uses the entity matching method of 'All' to require that alerts share the exact same set of entities for grouping into one incident. When the rule fires, the incident creation engine evaluates each alert against the defined entities and groups those with matching values, providing a unified incident for triage and investigation.

Modifying the analytics rule query to exclude sign-ins from the specific location is the precise fix because it filters out false positives at the source while preserving detection for all other events. In KQL, you would add a clause such as `| where Location != 'Country'` or filter by IP address, ensuring the rule's logic specifically ignores the unwanted sign-in origin. This keeps the rule active and focused on real anomalies, reducing alert noise without losing coverage for other suspicious activities.

OfficeActivity represents the unified audit log for Microsoft 365, pulling records from Exchange, SharePoint, OneDrive, Teams, and other workloads. It captures user-level events such as email actions, file accesses, and messages sent after authentication, making it the appropriate table to investigate a user's activities in M365. This table is the primary source for reconstructing user behavior in the M365 environment.

The investigation graph visualises related entities, alerts and activities on a timeline, letting you trace the lateral movement path across accounts and hosts. It surfaces the attack chronology that a raw incident list or hunting query alone would not present as clearly.

The Microsoft 365 Defender user investigation page (now within the unified Microsoft Defender XDR) provides a single, entity-centric view of a user's alerts, incidents, sign-ins, and related activities across identities, endpoints, email, and cloud apps. It automatically correlates evidence and provides a timeline that allows an incident responder to quickly detect the scope and blast radius of a compromised account. This is the correct investigation surface because it is specifically designed for user entity investigation, and Sentinel can ingest these detections through the Microsoft 365 Defender connector.

ThreatIntelligenceIndicator tables store ingested threat indicators, including malicious IP addresses, matched against your environment. Querying it lets you confirm whether the sign-in's source IP appears in known threat intelligence, directly satisfying the requirement to identify a known malicious IP address rather than relying on sign-in logs alone.

Controlled folder access (CFA) in Microsoft Defender for Endpoint is the correct proactive control because it uses a Windows kernel mini-filter to intercept file-write and delete operations, blocking any process that is not on an approved allowlist from modifying files inside protected directories. This directly stops ransomware from encrypting user data in real time, even if the malware has already executed. CFA can be configured via Intune or group policy and provides a targeted, low-disruption defense that preserves forensic data and remote remediation capabilities.

Before containing or remediating, you must establish scope and impact. Reviewing the device timeline and alert details reveals the affected processes, files and network connections, ensuring subsequent response actions target the actual threat rather than disrupting legitimate activity.

Microsoft Defender for Endpoint is the correct source because it is an endpoint detection and response (EDR) solution that installs a sensor on the device, continuously monitoring processes, file executions, registry changes, and behaviors. Its real-time protection and behavioral analytics would detect the malicious file directly on the endpoint, and this detection would surface as an alert in Microsoft Sentinel. As the only option with a local agent capable of seeing file execution, it is the definitive source for this incident.

Threat Explorer (Investigation) is the correct choice because it is a purpose-built email security search tool that lets the analyst search all mail across the organization using filters like sender, recipient, subject, message ID, and delivery status. It provides a comprehensive, KQL-free view of every instance of the email, including delivery actions and threat detections, and supports direct remediation. This makes it the natural first tool for locating and analyzing a specific reported email.

The KQL `union` operator is the correct choice because it appends rows from two or more tables vertically into a single result set. If the tables have different columns, `union` returns all distinct columns and fills missing values with nulls, which is exactly what is needed to consolidate security data from various sources like SigninLogs, SecurityEvent, and AzureActivity. In Sentinel hunting queries, `union` allows an analyst to stack data sources with different schemas without losing any columns and is standard for cross-source investigation.

Checking the connector health page in Microsoft Sentinel is the correct first step because it provides a centralized view of each data connector's status, including whether it's connected, when the last event was received, and any ingestion errors. This page also shows the connector type, relevant log tables, and version information. If the connector is healthy, the issue likely lies in the source device or forwarder; if unhealthy, you can see specific error messages and take targeted corrective action.

Revoking sessions in Microsoft Entra ID invalidates all refresh tokens and active sessions for the compromised account, immediately cutting off the attacker's access while the password is reset. This directly satisfies the requirement to revoke all active sessions.

The 'Require re-authentication' action is a session-level conditional access app control in Microsoft Defender for Cloud Apps that terminates only the specific anomalous session, leaving the user's other active sessions unaffected. It forces both the user and the attacker to re-authenticate, effectively invalidating the stolen access token for that session and any associated refresh token for that session context. Because it is applied solely to the identified risky session, it minimizes user productivity loss while successfully revoking the attacker's unauthorized access, making it the most targeted and proportionate response.

Microsoft 365 Defender is a valid data source because its built-in connector streams unified alerts and incidents from Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps into Microsoft Sentinel. These security signals include attacker activities, malware events, and phishing detections, which are mapped directly to Sentinel's incident schema for correlation and investigation.

Creating a snapshot of the OS disk from the Azure portal is the correct first step because it produces a read-only, point-in-time copy of the entire virtual disk without powering on the VM, ensuring no writes alter the original evidence. The snapshot captures the raw disk structure including deleted data and file slack, and you can later attach it to a secure analysis VM or use it to instantiate a new disk for offline forensic examination, while storing the snapshot in a separate, access-controlled resource group to maintain chain of custody.

Using Sentinel automation to block outbound traffic to mining pools via NSG rules contains the threat without affecting legitimate traffic; Live Response collects evidence for investigation; Azure Policy to enforce Defender for Endpoint deployment prevents future occurrences by ensuring all VMs have EDR coverage.

Selective isolation is the preferred containment action in Microsoft Defender for Endpoint because it blocks all network traffic except communication with the Defender for Endpoint cloud service. This preserves the sensor's ability to send telemetry and receive automated or manual remediation commands, so the security team retains visibility and control during the incident. It effectively halts lateral movement and command-and-control while keeping the device within the security management plane, making it the only option that both contains the threat and maintains operational monitoring.

Live Response in Microsoft Defender XDR supports running the `Get-File` and memory-dump collection commands directly on a compromised Windows endpoint, satisfying the requirement to gather volatile forensic evidence without disrupting the device. This preserves RAM contents that would otherwise be lost on shutdown, which is essential for incident response.

Initiating user risk remediation in Microsoft Entra ID Protection is the correct, containment-focused response because it lets you confirm the sign-in as compromised, immediately revoke all refresh tokens and session cookies, and force the user to reauthenticate with a new password. This directly neutralizes the attacker's token-based access while preserving the legitimate user's ability to regain access after verification. It combines detection with automated, policy-driven response and is the documented best practice for handling confirmed user risk in Entra ID.

Threat Explorer in the Microsoft 365 Defender portal is the actual investigation-and-remediation surface for email threats; it combines a robust queryable event store with built-in actions. You can filter by threat type, sender, subject, or detection technology, select one or multiple messages, and directly delete (soft or hard) them from user mailboxes. For a suspicious email already delivered, this is the only option that both finds and removes it. Also supports in-place review of the payload and email summary.

Disabling the associated accounts in Microsoft Entra ID revokes authentication tokens and prevents the attacker reusing compromised credentials to re-encrypt or pivot. This satisfies containment by cutting the identity path, since ransomware operators routinely retain valid accounts to re-establish access after device-level cleanup.

Reviewing Microsoft Entra ID audit logs exposes the specific directory operations AzureHound performs, such as role assignments and service principal enumeration, letting you confirm whether the flagged activity is genuine privilege-escalation reconnaissance rather than benign administrative behaviour. This directly satisfies the stem's requirement to validate the alert before escalating.

In Microsoft Sentinel, an automation rule is the correct mechanism to trigger a playbook when an incident is created. Since the UEBA analytics rule generates incidents for suspicious behavior, you attach an automation rule to that rule that invokes a playbook. The playbook can then call Microsoft Entra ID to disable a user account, providing immediate, coordinated incident response.

Revoking Entra ID sessions invalidates refresh tokens immediately, while resetting the password in both directories removes the attacker's on-premises and cloud credentials. This dual reset contains the compromised admin account before further security group modifications occur.

Sign-in logs record token issuance details, including the token's unique identifier and authentication context, letting you correlate the alert with the specific session and confirm whether a stolen or replayed token was used rather than legitimate credentials.

True positive is one of the two valid incident classification categories in Microsoft Sentinel. You select this classification when investigation confirms the alert correctly identified a real security threat. Applying True positive is important because it enables accurate reporting on detection effectiveness and helps tune analytics rules for future incidents. It must be paired with the incident status 'Closed' (or 'Resolved') in the classification workflow.