Cortex XDR practice questions

Alert Grouping policy

Why it fails: There is no 'Alert Grouping' policy; this is handled by the correlation engine.

Alert Suppression

Why it fails: Suppression hides alerts rather than aggregating them into an incident.

Correlation Rule Execution

Why it fails: Correlation rules trigger alerts but do not manually group arbitrary existing alerts.

Global Settings

Why it fails: Global settings do not contain granular update scheduling for agents.

Incident Management Settings

Why it fails: This is for alert handling, not agent updates.

Endpoint Policy

Why it fails: Endpoint policies control security settings, not software updates.

Alert View

Why it fails: Alert view focuses on specific triggered alerts, not full activity timelines.

Incident View

Why it fails: Incident view focuses on groups of alerts, not endpoint-specific activity history.

Dashboard View

Why it fails: Dashboards show high-level metrics, not activity logs.

Endpoint Protection Rule

Why it fails: This is a generic term, not the specific setting name.

Detection Mode

Why it fails: Detection mode sets whether it is enabled or disabled, not the post-detection action.

Scan Frequency

Why it fails: Scan frequency relates to scheduled scanning performance.

Remediation Policy

Why it fails: Remediation policy is a broader concept not tied to the specific file-move action.

The `rundll32.exe` process is quarantined and moved to a secure folder, and its hash is added to the Block List for the next 24 hours.

Why it fails: Cortex XDR does not quarantine processes by moving them to a secure folder. Quarantine typically applies to files, and it is a separate action from 'Add to Block List'. The block list entry is permanent until removed, not time-limited to 24 hours.

A new exception is created in the Behavioral Threat Protection (BTP) profile to allow `rundll32.exe` to run, but only on the affected endpoint.

Why it fails: Adding to Block List is not an exception; it is a blocking action. BTP exceptions are configured in profiles, not via right-click in the Causality View. This option confuses allow-listing with block-listing and incorrectly scopes the action to a single endpoint when it is actually tenant-wide.

The `rundll32.exe` process is terminated and its hash is added to the Block List, preventing execution of that exact file on all endpoints in the organization.

Why it fails: Cortex XDR's 'Add to Block List' action does not terminate a running process; it only adds the file hash to the block list. Termination requires a separate action such as 'Terminate Process'. This option incorrectly combines termination with blocking, which is not how the feature works in this scenario.

Set the action to 'Block' for the Portable Executable and DLL file type.

Why it fails: Setting the action to 'Block' will prevent the execution of any file matching the Portable Executable and DLL file type criteria, but it does not perform a local WildFire analysis. This would block all executables, including benign ones, which is overly restrictive and does not satisfy the requirement of scanning before execution.

Set the action to 'Quarantine' for the Portable Executable and DLL file type.

Why it fails: The 'Quarantine' action isolates the file, preventing it from running, but it does not perform a local WildFire scan to determine if the file is malicious. Quarantine is typically used after a malicious verdict, not as a proactive scan-and-decide mechanism for script execution.

Set the action to 'Report' for the Portable Executable and DLL file type.

Why it fails: The 'Report' action only generates a WildFire report for the file without blocking or allowing it based on the verdict. It does not perform a local scan that can determine whether to allow or block execution; it simply reports the file for analysis, which does not meet the need to scan before execution.

Parent process name

Why it fails: Parent process name is not a valid criterion for BTP exceptions. Exceptions are defined for the process that triggers the BTP alert, not its parent. Using parent process could exclude unrelated child processes, which is not desired. The administrator needs to target the specific tool, so parent process name is inappropriate.

Command line arguments

Why it fails: Command line arguments are not a standard criterion for BTP exceptions. While command line can be used in some detection rules, BTP exceptions are based on process identity. Relying on command line would be fragile because arguments can vary, and it might not uniquely identify the tool, potentially leading to gaps or over-exclusions.

User name

Why it fails: User name is not a supported criterion for BTP exceptions. BTP profiles focus on process behavior, and exceptions are typically defined by process attributes like name or hash, not user identity. Using user name would be too broad and could inadvertently allow malicious activity from that user, which is not the goal here.

Cortex XDR Agent

Why it fails: The Cortex XDR Agent is installed on endpoints and enforces policies, but it does not autonomously fetch updates. It relies on communication with the management server and content delivery network to receive updates. Therefore, the agent itself is not responsible for initiating updates.

Cortex XDR Management Server

Why it fails: The Cortex XDR Management Server hosts the console and manages policies, but it does not directly push updates to agents. Agents communicate with the management server to retrieve policies, but content updates are handled by a separate component. Thus, it is not the primary component for automatic updates.

Cortex XDR Data Lake

Why it fails: The Cortex XDR Data Lake stores and correlates large volumes of telemetry data for analytics and threat hunting. It does not distribute updates to endpoints. Its role is data storage and analysis, not content delivery. Hence, it is not responsible for automatic agent updates.

filter

Why it fails: The 'filter' clause is used to narrow down results based on conditions, such as matching 'powershell.exe' or 'Invoke-Expression'. However, it does not correlate events across datasets or time. While necessary for refining the query, it alone cannot achieve the required correlation between process execution and network connection.

window

Why it fails: The 'window' clause is used for aggregations over a time period, such as counting events. It does not correlate two different event types. While it can define a time frame, it does not link process execution to network connections. The analyst needs a join operation, not just a window.

union

Why it fails: The 'union' operator combines results from multiple queries into a single result set, but it does not correlate events. It would simply append network events to process events without linking them by process ID. This would not satisfy the requirement to detect the specific sequence within a time window.

Set up an IOC rule to block execution of known malicious files.

Why it fails: IOC rules can block based on indicators, but they require the endpoint to be online to receive updates or may rely on cloud lookups. They are not as robust for offline enforcement as a local Malware profile. The administrator wants offline blocking, so this is less suitable.

Configure a Behavioral Threat Protection profile with blocking enabled.

Why it fails: Behavioral Threat Protection focuses on behavioral anomalies, not known malicious files based on threat intelligence. While it can block malicious behavior, it does not specifically target known malicious files by hash. The scenario requires blocking known malicious files, so this profile type is not the best fit.

Use the Incident Response action to quarantine files on all endpoints.

Why it fails: Incident Response actions are manual and apply to specific endpoints, not automatically to all endpoints in a group. They also do not prevent future executions. The requirement is for automatic, policy-based blocking, so this approach is inefficient and not scalable.

Incident Response to isolate the server and then analyze the script offline.

Why it fails: Isolating the server would disrupt its operations, which the analyst wants to avoid. While isolation can be useful for containment, the scenario explicitly states without disrupting the server. Therefore, this approach is too heavy-handed and not suitable for a quick, non-disruptive investigation.

Use the Causality View to see the script's execution chain and then export the script from the alert details.

Why it fails: Causality View shows process relationships but does not provide the script's content or network connections directly. Exporting from alert details may not give the full script if it was not captured. This method is incomplete for the analyst's needs, as it lacks the ability to inspect the script and its network activity in depth.

Query the Data Lake for PowerShell script block logging events and use Threat Intelligence to check network connections.

Why it fails: Querying the Data Lake can retrieve script block logs if enabled, but it may not provide real-time inspection or the full script if logging is limited. Threat Intelligence checks indicators but does not show the script's actual network connections. This approach is indirect and may miss critical details, making it less efficient than using Live Terminal and Endpoint Investigation.

Add the driver hash to the BIOC rule set with an action of 'Block'.

Why it fails: BIOC rules are designed for behavioral threat detection, not for blocking known file hashes. While a BIOC rule can trigger an alert and potentially a response action, it is not the correct mechanism for static hash blocking. The Malware profile's blocklist is the appropriate feature for this requirement.

Use the Cortex XDR API to push a script that adds the hash to the Windows Defender blocklist on each endpoint.

Why it fails: While scripting via API is possible, it relies on an external mechanism and does not leverage Cortex XDR's native policy enforcement. This approach is less scalable, requires custom development, and may conflict with existing security controls. The built-in Malware profile blocklist is the direct and supported method.

Configure a Restriction rule in the endpoint policy to deny execution of the driver file name.

Why it fails: Restriction rules in Cortex XDR typically control execution based on file path, signer, or other attributes, but they are not designed for hash-based blocking. Moreover, using a file name is unreliable because malware can be renamed. The Malware profile blocklist specifically supports hash-based blocking.

Cortex Data Lake

Why it fails: Cortex Data Lake is the storage and analytics repository for telemetry already forwarded by Cortex XDR agents and brokers; it does not itself collect from network devices or firewalls. It is tempting because it holds the aggregated data, but collection from non-endpoint sources is performed by the Cortex XDR Collector, not the Data Lake.

Broker Service

Why it fails: The Broker Service mediates communication between Cortex XDR agents and the management console, not log ingestion from firewalls or network devices. The correct component is the Collector, which gathers logs from non-endpoint sources via syslog or API.

Cortex XDR Agent

Why it fails: The Cortex XDR Agent installs on endpoints such as Windows, macOS and Linux to collect process and file telemetry; it cannot ingest syslog or API data from firewalls and network devices. That role belongs to the Collector component.

file_hash

Why it fails: File hash identifies a known file by its cryptographic digest, so it cannot match a command-line argument such as an encoded PowerShell parameter. It is tempting because hashes reliably detect known malicious binaries and would be correct for blocking a specific identified tool, but encoded-command detection requires inspecting the process command line.

target_process_path

Why it fails: The encoded command appears in the process command-line arguments, so target_process_path (the executable's file location) never captures it. It is tempting because path-based matching suits rules detecting execution from unusual directories, such as PowerShell running from a temp folder, but here the encoded payload lives in the command line itself.

process_name

Why it fails: process_name only matches the executable's name, such as powershell.exe, which is identical whether or not an encoded command is supplied, so it cannot distinguish the malicious invocation. It is tempting because name-based rules work well for detecting known unwanted binaries by filename, but the encoded payload sits in the command-line arguments instead.

The agent will sandbox the process for further analysis.

Why it fails: Block mode prevents the process from executing, typically terminating or denying it, rather than submitting it to a sandbox. It is tempting because sandboxing is a genuine BTP response, and would be correct under a detect or analyse mode where the agent detonates suspicious processes for inspection.

The agent will report the event but allow the process to continue.

Why it fails: Block mode terminates the offending process and logs the event; reporting while allowing execution describes Audit mode. Audit is tempting because it enables safe tuning of a new BTP profile before enforcement, but it cannot satisfy a requirement to stop malicious behaviour.

The agent will block only known malicious file hashes.

Why it fails: Block mode acts on behavioural patterns and process trees, not file-hash matching; hash-based blocking belongs to indicator-of-compromise or antivirus controls. Hash matching is tempting because it offers deterministic, low-false-positive blocking, but it cannot stop novel behaviour that BTP targets.

Create a manual exception in the Endpoint Policy.

Why it fails: A manual exception in the Endpoint Policy permits specified files or scripts to run, so it would allow the malicious script rather than block it. It tempts because exceptions are used to handle known-good software that security tooling flags, which is the opposite requirement here.

Disable the script execution globally.

Why it fails: Cortex XDR offers no global 'disable script execution' toggle; such a setting would halt all scripting enterprise-wide, including legitimate business automation. It tempts as a blunt blanket control, but targeted blocking of the identified script is what the scenario requires.

Use the Response feature to quarantine the file on one host.

Why it fails: Quarantining a file on one host only isolates that endpoint, leaving the script free to execute elsewhere in the enterprise. Response actions are for containing confirmed incidents on specific hosts; enterprise-wide script blocking needs a prevention policy or indicator of compromise applied across all endpoints.

An alert that has been suppressed.

Why it fails: A dotted line in Causality View depicts an indirect or inferred process relationship, not suppression. It is tempting because suppression is a real alert state, but that is shown through the alert's status, not through the process-graph line style.

A direct process spawn.

Why it fails: A dotted line denotes an inferred or indirect relationship, such as a process observed launching another via a remote thread or scheduled task, not a direct parent-child spawn. It is tempting because direct spawns are the commonest causality link, but those appear as solid lines in the Causality View.

A process that has been quarantined.

Why it fails: Quarantine status is not represented in the Causality View graph at all; the dotted line encodes an indirect or inferred process relationship. It tempts analysts who conflate containment state with visual link types, yet quarantine is shown in device or file action details, not as an edge style.

Increase the log retention period in the console.

Why it fails: Log retention governs how long stored data persists, not whether the agent can reach the console, so it cannot resolve a disconnected endpoint. It tempts because retention settings appear in console administration, yet the actual fault lies in agent connectivity, service status or network path.

Reinstall the Cortex XDR agent via the portal.

Why it fails: Reinstalling the agent is destructive and premature; connectivity, service status and network reachability must be checked first, since a disconnected agent may simply be unable to reach the console. It is tempting because reinstallation often resolves corrupted agents, and would be correct after diagnostics confirm the agent itself is faulty.

Disable the firewall on the endpoint.

Why it fails: Disabling the endpoint firewall removes a security control and may not restore connectivity; the required first step is verifying whether the firewall or proxy is blocking the agent's outbound connection. It is tempting because blocked egress commonly causes disconnection, and would be correct only after confirming the firewall rule is the specific cause.

Disable the BIOC rule entirely.

Why it fails: Disabling the rule removes detection for all endpoints, including genuinely malicious activity, and directly contradicts the stated requirement to keep the rule enabled. Exclusions or allowlists scoped to the script's specific indicators suppress only the known-benign pattern. Disabling suits retiring a rule that no longer reflects any real threat.

Change the BIOC rule to 'Alert' mode.

Why it fails: Alert mode still generates the alerts the team wants stopped; it only changes whether the rule blocks or merely notifies, so the noise persists. An exclusion or allowlist for the script's specific indicators is needed. Alert mode suits tuning a rule during validation before enabling prevention.

Move the endpoint to a different policy group.

Why it fails: Policy groups determine which prevention and detection policies apply to an endpoint; moving it changes coverage rather than excluding the script from this BIOC rule, potentially weakening protection elsewhere. A scoped exclusion matching the script's indicators is required. Reassigning groups suits restructuring endpoint policy coverage, not suppressing a single false positive.

The endpoint must be running an older version of the agent.

Why it fails: Live Terminal requires the agent to be current and connected; an outdated agent version is not a prerequisite and typically blocks the session. Older agents are relevant only when troubleshooting upgrade compatibility, not for establishing a live shell.

The analyst must be logged into the endpoint via SSH first.

Why it fails: Live Terminal tunnels through the agent's outbound connection, so no inbound SSH listener or prior SSH login is required. SSH access would be the mechanism for a direct remote shell session to the endpoint, not for the console's Live Terminal capability.

The endpoint must be in the same network as the analyst.

Why it fails: Live Terminal connects through the Defender for Endpoint cloud service, so the analyst's workstation and the endpoint never require shared network adjacency. The tempting assumption treats it as a direct remote-desktop or SSH session, where same-subnet or VPN reachability would genuinely be required for the connection to succeed.