Incident Handling And Response practice questions

parse lookup_table

Why it fails: Incorrect. Parse is used for extracting fields from unstructured text.

filter in_list

Why it fails: Incorrect. While filter is valid, the specific command for table enrichment is lookup.

join

Why it fails: Incorrect. Join is used to combine two datasets, whereas lookup is specifically designed for referencing lookup tables.

dataset = network_raw

Why it fails: Incorrect. network_raw is used for network traffic and firewall telemetry.

dataset = cloud_audit_raw

Why it fails: Incorrect. cloud_audit_raw contains cloud provider audit logs such as AWS CloudTrail.

dataset = xdr_data

Why it fails: Incorrect. xdr_data is generally used for parsed Cortex XDR alerts rather than raw event streams.

stream join with time_window parameter

Why it fails: Incorrect. Stream join is not the standard syntax for event sequencing in XQL.

aggregate windowed_events

Why it fails: Incorrect. Aggregate is used for grouping and summarization, not chronological sequence matching.

union match operator

Why it fails: Incorrect. Union combines datasets rather than performing sequential time-based correlation.

XQL forwarding profiles

Why it fails: Incorrect. Forwarding profiles export logs to external SIEMs.

Cortex XDR Agent policy rules

Why it fails: Incorrect. Agent policies do not handle email parsing.

Local parsing rules on endpoints

Why it fails: Incorrect. Local parsing rules apply to agent log collection, not playbook execution flows.

where frequency_limit >= 5

Why it fails: XQL filters aggregated output with the filter clause, not where, which applies before aggregation. Using where here is tempting because it is the familiar filtering keyword, and it is correct when restricting raw events prior to the aggregation stage rather than the computed results.

having count > 5

Why it fails: XQL has no having clause; aggregated results are filtered with filter, and the comparison must exclude exactly five. Having is tempting because SQL uses it for post-aggregation filtering, and count > 5 would also wrongly drop users with precisely five failures.

limit 5 records per user

Why it fails: Incorrect. Limit restricts the total number of output rows, not conditional thresholds.

Endpoint agent installation log

Why it fails: Incorrect. Installation logs only track software deployment.

Playbook execution status dashboard

Why it fails: Incorrect. This dashboard tracks automation run history.

Incident severity configuration wizard

Why it fails: Incorrect. This wizard sets incident scoring rules.

Endpoint kernel driver telemetry

Why it fails: Incorrect. Kernel driver telemetry captures local OS process and file activity on endpoints.

Network firewall packet captures

Why it fails: Incorrect. Packet captures inspect network packets, not cloud API management events.

Local DNS cache dump files

Why it fails: Incorrect. DNS cache dumps are point-in-time endpoint artifacts, not cloud audit streams.

select_database_table_drop

Why it fails: Incorrect. This is a destructive SQL command not found in XQL.

format_hard_disk

Why it fails: Incorrect. This is a destructive OS command, not an XQL clause.

XSIAM Playbook

Why it fails: Playbooks automate response actions based on triggers, but they are not used for manual, ad-hoc account disabling. They are predefined workflows. The analyst could create a playbook for this, but the question asks for a direct action from the incident view, which playbooks do not provide in real-time.

XSIAM Query Builder

Why it fails: The Query Builder is for constructing XQL queries to search data, not for performing response actions. It cannot disable accounts. While it can help identify the account details, it does not provide the capability to modify AD. Thus, it is not the right tool for this task.

Cortex XDR Live Terminal

Why it fails: Live Terminal provides command-line access to endpoints, not to Active Directory. While it could be used to run PowerShell commands to disable an account, that requires additional scripting and permissions. It is not the streamlined, integrated method for account disabling within the incident view.

Cortex XDR Analytics

Why it fails: Cortex XDR Analytics applies behavioral analytics to detect anomalies, but it does not provide raw event data with command lines and parent processes. It generates alerts based on patterns, not detailed forensic data. Therefore, it is not the source to query for specific event details.

XDR Agent Event Logs

Why it fails: XDR Agent Event Logs capture endpoint activity such as process executions and file operations, but scheduled task creation events may not include the full command line or parent process in all cases. The agent logs are valuable but may not have the specific task creation details with the required context. They are not the primary source for scheduled task telemetry.

Windows Event Logs (Security)

Why it fails: Windows Security Event Logs record events like 4698 (scheduled task created), which include task details and the user, but they do not always capture the full command line of the task action or the parent process. The command line might be in the task definition, but parent process is not recorded. Thus, it may not fully satisfy the requirement.

dataset = xdr_data | filter action_local_port = 445 or action_remote_port = 445 | dedup action_remote_ip

Why it fails: This query uses a filter with an OR condition, which would include both inbound and outbound SMB traffic, potentially mixing source and destination roles. The dedup stage then removes duplicate remote IPs, but it does not group by source host, so it would return a global list of remote IPs, not specifically those contacted by the source host of interest.

dataset = xdr_data | filter action_local_port = 445 | comp count() as conn_count by action_local_ip, action_remote_ip

Why it fails: This query filters on the local port (action_local_port) instead of the remote port. In network traffic, the destination port is typically the remote port. Using the local port would match connections where the source host was listening on port 445, which is not the same as initiating outbound SMB connections. It would miss the actual lateral movement traffic.

dataset = xdr_data | filter action_remote_port = 445 | comp count() as conn_count by action_remote_ip

Why it fails: This query filters correctly for SMB traffic but only groups by remote IP address. It does not include the local IP address in the grouping, so it would aggregate connections from all source hosts to each remote IP. The analyst needs to see which remote IPs a specific source host communicated with, so the local IP must be part of the grouping.

Use a playbook to change the severity of incidents after they are created

Why it fails: While a playbook can automate actions, using one to change severity after incident creation is reactive and may cause delays. The severity scoring configuration is the proper place to define such policies proactively. Playbooks are better suited for response actions, not for core incident scoring logic.

Create a new correlation rule that sets severity to 'Critical' when a domain controller is involved

Why it fails: Correlation rules are used to generate incidents based on log patterns, not to modify severity of existing incidents. While a correlation rule could trigger a new incident, it would not adjust the severity of the original incident. This approach would create duplicate incidents and not solve the severity policy issue.

Manually change the severity of the current incident to 'Critical'

Why it fails: Manually changing the severity only affects the current incident and does not enforce the policy for future incidents. While it addresses the immediate issue, it does not automate the process. The analyst needs a scalable solution that applies to all future incidents involving domain controllers.

Windows Event ID 5140 showing network share access to ADMIN$

Why it fails: Event ID 5140 logs network share access. PsExec often uses the ADMIN$ share to copy the service binary. While this can be an indicator, it is not as direct as process creation or network logon. Many legitimate administrative activities also access ADMIN$, so it is less specific. In this scenario, 5140 alone would not confirm PsExec without additional context.

Windows Event ID 7045 showing service installation of PSEXESVC

Why it fails: Event ID 7045 logs service installation, and PsExec does install a service named PSEXESVC. This is indeed a strong indicator. However, the question asks for TWO types of evidence, and 7045 is not among the correct options because the correct pair is 4688 and 4624 logon type 3. While 7045 is relevant, it is not one of the two most direct types in this context, as it may be less commonly logged or forwarded. Therefore, it is not selected.

Sysmon Event ID 1 showing process creation with parent process services.exe

Why it fails: Sysmon Event ID 1 logs process creation, and if PSEXESVC.exe is launched by services.exe, it could indicate PsExec. However, this is similar to 4688 and not as widely available. The question asks for two types, and the combination of 4688 and 4624 logon type 3 is more universally applicable. Sysmon may not be deployed everywhere, so it is not the most direct evidence in this context.

Block the C2 IP address at the firewall

Why it fails: While blocking the C2 IP at the firewall is a valid remediation step, it is not performed directly from the XSIAM incident view unless a firewall integration is configured and the action is available. XSIAM can orchestrate such actions via the Action Center, but it requires the integration. The question asks for actions directly from the incident view, which typically includes endpoint actions, not firewall changes without integration.

Delete the user account associated with the incident

Why it fails: Deleting a user account is an extreme action rarely performed during incident response and is not a standard direct action from the XSIAM incident view. Account disabling is more common, but deletion is not typically available as a one-click action. It would require directory services integration and is not part of the default response actions.

Quarantine the malicious file

Why it fails: Quarantining a file is a response action available in XSIAM, but it is typically performed on the endpoint where the file resides. However, the question specifies actions directly from the incident view. While file quarantine can be initiated from the incident, it often requires selecting the endpoint and file, which may be a multi-step process. The two most direct and common actions are isolation and process termination.

Initiate a 'Process Execution' action to list all running processes and their network connections.

Why it fails: A 'Process Execution' action typically runs a specified command or script on the endpoint. While it could be used to run a command like 'tasklist' or 'netstat', it is not a prebuilt evidence collection action and may not format or preserve the output as expected. XSIAM offers a more direct and automated method.

Run a live terminal session on the endpoint and execute built-in Windows commands to capture process and network data.

Why it fails: While a live terminal session allows interactive commands, it is not a dedicated evidence collection action and may not preserve data in a forensically sound manner or automatically attach results to the incident. XSIAM provides specialized response actions for this purpose, making this approach less reliable and more prone to human error.

Use the 'Retrieve File' action to pull a memory dump of the endpoint.

Why it fails: The 'Retrieve File' action is designed to fetch specific files from the endpoint, not to capture volatile system state such as running processes or network connections. It would not provide the required real-time evidence and might miss critical in-memory artifacts that are essential for ransomware analysis.

Add a common tag to all incidents and create a filtered view.

Why it fails: Tagging incidents and creating a filtered view helps organize and find related incidents, but it does not actually merge them into a single case. The incidents remain separate, requiring the analyst to switch between them. While useful for tracking, it does not provide the consolidated workflow and evidence correlation that merging offers.

Link the incidents using the 'Related Incidents' feature.

Why it fails: The 'Related Incidents' feature allows analysts to manually associate incidents, providing cross-references. However, it does not combine them into one incident; they remain distinct entities. This can be useful for context but does not streamline management as effectively as merging. The analyst would still need to handle each incident separately for response actions.

Create a new incident manually and copy all alerts into it.

Why it fails: Manually creating a new incident and copying alerts is time-consuming, error-prone, and may lose the original incident metadata and audit trail. XSIAM's merge feature is designed to preserve all data while combining incidents. Manual copying is not a supported best practice and could result in inconsistent incident handling.

Delete the user's mailbox from Exchange

Why it fails: Deleting a user's mailbox is a destructive action that is not typically available as a direct containment step in the War Room. While mailbox access can be revoked, deletion is reserved for more permanent measures and is not a standard response action. The War Room focuses on reversible containment actions.

Block the user's email address in the email gateway

Why it fails: Blocking an email address is not a standard containment action in the War Room. While it could be done via integration with an email gateway, it is not a built-in action for user account compromise. The primary containment actions for a compromised account are disabling the account and isolating affected endpoints.

Reset the user's password in Active Directory

Why it fails: Resetting a password is a remediation action that can be performed, but it is not a containment action available directly from the War Room in this context. Containment focuses on stopping the attack, while password reset is part of recovery. The War Room does not provide a one-click password reset for AD accounts.

Use the 'Action Center' to manually isolate endpoints after each alert.

Why it fails: The 'Action Center' allows manual execution of response actions, but it does not provide automation. The analyst would need to manually isolate each endpoint upon alert, which is not efficient and does not minimize manual effort as required. Automation is key here.

Modify the existing incident severity scoring to automatically isolate endpoints with high severity.

Why it fails: Severity scoring determines the priority of incidents but does not trigger response actions. Changing severity scoring would not automatically isolate endpoints; it would only affect how incidents are ranked. Isolation requires a specific response action, not just a severity adjustment.

Configure a playbook that runs on all incidents and includes a conditional isolation step.

Why it fails: While a playbook can automate responses, it would need to be triggered for each incident. Without a specific detection mechanism for SMB lateral movement, the playbook might run on irrelevant incidents, causing unnecessary isolations. A correlation rule with a targeted response is more precise and efficient.

Change the incident severity to 'Informational' and close it.

Why it fails: Changing severity and closing the incident only affects the current incident; it does not prevent future incidents from being created for the same IP. The analyst needs a persistent exclusion to avoid repeated false positives. Severity adjustment is a temporary workaround, not a solution.

Disable the correlation rule that triggered the incident.

Why it fails: Disabling the correlation rule would stop all detections from that rule, including legitimate threats. This is overly broad and could leave the organization vulnerable. The analyst should instead add a targeted exception to maintain detection for other IPs.

Add the IP address to the 'Allowed List' in the Indicators module.

Why it fails: The 'Allowed List' in the Indicators module is used to mark indicators as benign, but it does not automatically prevent future incidents from being generated for that IP. It may influence scoring, but it is not the primary mechanism for suppressing incidents. The analyst should use a more direct exclusion method.

Use the 'Action Center' to run a 'Process Execution' action on all endpoints to list running processes.

Why it fails: Running a process execution action on all endpoints would only show currently running processes, not historical executions. It is also resource-intensive and slow. The analyst needs to find past executions, which requires querying historical data, not live actions.

Use the 'Indicators' module to search for the process name as an indicator.

Why it fails: The 'Indicators' module is designed for threat intelligence indicators like IPs, domains, and file hashes. Searching for a process name there may not yield results because process names are not typically stored as indicators. It is not the right tool for real-time process hunting across endpoints.

Create a correlation rule to alert on future executions of the process name.

Why it fails: A correlation rule would detect future executions but does not help identify endpoints that have already executed the process. The analyst needs immediate retrospective search, not forward-looking alerting. This option delays response and misses existing infections.