PCDRA Practice Questions

Remediation Suggestions is a feature of Cortex XDR that provides you with recommended actions to

remediate the root cause and impact of an incident. Remediation Suggestions are based on the

analysis of the causality chain, the behavior of the malicious files or processes, and the best practices

for incident response. Remediation Suggestions can help you to quickly and effectively contain and

resolve an incident, as well as prevent future recurrence.

To activate Remediation Suggestions, you need to follow these steps:

In the Cortex XDR management console, go to Incidents and select an incident that you want to

remediate.

Click Causality View to see the graphical representation of the causality chain of the incident.

Click Actions and select Remediation Suggestions. This will open a new window that shows the

suggested actions for each node in the causality chain.

Review the suggested actions and select the ones that you want to apply. You can also edit or delete

the suggested actions, or add your own custom actions.

Click Apply to execute the selected actions on the affected endpoints. You can also schedule the

actions to run at a later time or date.

Reference:

Remediate Changes from Malicious Activity: This document explains how to use Remediation

Suggestions to remediate the root cause and impact of an incident.

Causality View: This document describes how to use Causality View to investigate the causality chain

of an incident.

A supply chain attack is a type of cyberattack that targets a trusted third-party vendor who offers

services or software vital to the supply chain. Software supply chain attacks inject malicious code into

an application in order to infect all users of an app. The purpose of targeting software vendors in a

supply-chain attack is to take advantage of a trusted software delivery method, such as an update or

a download, that can reach a large number of potential victims. By compromising a software vendor,

an attacker can bypass the security measures of the downstream organizations and gain access to

their systems, data, or networks. Reference:

What Is a Supply Chain Attack? - Definition, Examples & More | Proofpoint US

What Is a Supply Chain Attack? - CrowdStrike

What Is a Supply Chain Attack? | Zscaler

What Is a Supply Chain Attack? Definition, Examples & Prevention

The output shows the top 10 hosts with the most malware in the last 30 days, based on the Cortex

XDR data. The output is sorted by the number of incidents, with the host with the most incidents at

the top. The output also shows the number of alerts, the number of endpoints, and the percentage

of endpoints for each host. The output is generated by using the ACC (Application Command Center)

feature of Cortex XDR, which provides a graphical representation of the network activity and threat

landscape. The ACC allows you to view and analyze various widgets, such as the Top 10 hosts with

the most malware, the Top 10 applications by bandwidth, the Top 10 threats by count, and more .

Reference:

Use the ACC to Analyze Network Activity

Top 10 Hosts with the Most Malware

Phishing is a technique that belongs to two MITRE ATT&CK tactics: Reconnaissance and Initial Access.

Reconnaissance is the process of gathering information about a target before launching an attack.

Phishing for information is a sub-technique of Reconnaissance that involves sending phishing

messages to elicit sensitive information that can be used during targeting. Initial Access is the

process of gaining a foothold in a network or system. Phishing is a sub-technique of Initial Access that

involves sending phishing messages to execute malicious code on victim systems. Phishing can be

used for both Reconnaissance and Initial Access depending on the objective and content of the

phishing message. Reference:

Phishing, Technique T1566 - Enterprise | MITRE ATT&CK® 1

Phishing for Information, Technique T1598 - Enterprise | MITRE ATT&CK® 2

Phishing for information, Part 2: Tactics and techniques 3

PHISHING AND THE MITREATT&CK FRAMEWORK - EnterpriseTalk 4

Initial Access, Tactic TA0001 - Enterprise | MITRE ATT&CK® 5

The File Search and Destroy feature is a capability of Cortex XDR that allows you to search for and

delete malicious or unwanted files across your endpoints. You can use this feature to quickly respond

to incidents, remediate threats, and enforce compliance policies. To use the File Search and Destroy

feature, you need to specify the file name and the file hash of the file you want to search for and

delete. The file hash is a unique identifier of the file that is generated by a cryptographic hash

function. The file hash ensures that you are targeting the exact file you want, and not a file with a

similar name or a different version. The File Search and Destroy feature supports the SHA256 hash

type, which is a secure hash algorithm that produces a 256-bit (32-byte) hash value. The SHA256

hash type is widely used for file integrity verification and digital signatures. The File Search and

Destroy feature does not support other hash types, such as AES256, MD5, or SHA1, which are either

encryption algorithms or less secure hash algorithms. Therefore, the correct answer is A, SHA256

hash of the file1234

Reference:

File Search and Destroy

What is a File Hash?

SHA-2 - Wikipedia

When using the “File Search and Destroy” feature, which of the following search hash type is

supported?

The type of BIOC rule that is currently available in Cortex XDR is Discovery. A Discovery BIOC rule is a

rule that detects suspicious or malicious behavior on endpoints based on the Cortex XDR data. A

Discovery BIOC rule can use various event types, such as file, injection, load image, network, process,

registry, or user, to define the criteria for the rule. A Discovery BIOC rule can also use operators,

functions, and variables to create complex logic and conditions for the rule. A Discovery BIOC rule

can generate alerts when the rule is triggered, and these alerts can be grouped into incidents for

further investigation and response12.

Let’s briefly discuss the other options to provide a comprehensive explanation:

A) Threat Actor: This is not the correct answer. Threat Actor is not a type of BIOC rule that is currently

available in Cortex XDR. Threat Actor is a term that refers to an individual or a group that is

responsible for a cyberattack or a threat campaign. Cortex XDR does not support creating BIOC rules

based on threat actors, but it can provide threat intelligence and context from various sources, such

as Unit 42, AutoFocus, or Cortex XSOAR3.

C) Network: This is not the correct answer. Network is not a type of BIOC rule that is currently

available in Cortex XDR. Network is an event type that can be used in a Discovery BIOC rule to define

the criteria based on network attributes, such as source IP, destination IP, source port, destination

port, protocol, or domain. Network is not a standalone type of BIOC rule, but a part of the Discovery

BIOC rule2.

D) Dropper: This is not the correct answer. Dropper is not a type of BIOC rule that is currently

available in Cortex XDR. Dropper is a term that refers to a type of malware that is designed to

download and install other malicious files or programs on a compromised system. Cortex XDR does

not support creating BIOC rules based on droppers, but it can detect and prevent droppers using

various methods, such as behavioral threat protection, exploit prevention, or WildFire analysis4.

In conclusion, the type of BIOC rule that is currently available in Cortex XDR is Discovery. By using

Discovery BIOC rules, you can create custom detection rules that match your specific use cases and

scenarios.

Reference:

Create a BIOC Rule

BIOC Rule Event Types

Threat Intelligence and Context

Malware Prevention

A BIOC rule is a custom detection rule that uses the Cortex Query Language (XQL) to define the

behavior or actions that indicate a potential threat. A BIOC rule can use the xdr_data and

cloud_audit_log datasets and presets for these datasets. A BIOC rule can also use the filter stage,

alter stage, and functions without any aggregations in the XQL query. The query must return a single

field named action_process_image, which is the process image name of the suspicious process. The

query must also include the event_type and event_sub_type fields in the filter stage to specify the

type and sub-type of the event that triggers the rule.

Option B is the correct answer because it meets all the requirements for a valid BIOC rule query. It

uses the xdr_data dataset, the filter stage, the event_type and event_sub_type fields, and the

action_process_image_name field with a regular expression to match any process image name that

ends with .pdf.exe or .docx.exe, which are common indicators of malicious files.

Option A is incorrect because it does not include the event_type field in the filter stage, which is

mandatory for a BIOC rule query.

Option C is incorrect because it does not include the event_type and event_sub_type fields in the

filter stage, and it uses the fields stage, which is not supported for a BIOC rule query. It also returns

the action_process_image field instead of the action_process_image_name field, which is the

expected output for a BIOC rule query.

Option D is incorrect because it uses the event_behavior field, which is not supported for a BIOC rule

query. It also does not include the event_type field in the filter stage, and it uses the event_sub_type

field incorrectly. The event_sub_type field should be equal to PROCESS_START, not true.

Reference:

Working with BIOCs

Cortex Query Language (XQL) Reference

To filter the display to only show incidents that were “starred”, you need to click the star in the

widget. This will apply a filter that shows only the incidents that contain a starred alert, which is an

alert that matches a specific condition that you define in the incident starring configuration. You can

use the incident starring feature to prioritize and focus on the most important or relevant incidents in

your environment1.

Let’s briefly discuss the other options to provide a comprehensive explanation:

A) Create a custom XQL widget: This is not the correct answer. Creating a custom XQL widget is not

necessary to filter the display to only show starred incidents. A custom XQL widget is a widget that

you create by using the XQL query language to define the data source and the visualization type. You

can use custom XQL widgets to create your own dashboards or reports, but they are not required for

filtering incidents by stars2.

B) This is not currently supported: This is not the correct answer. Filtering the display to only show

starred incidents is currently supported by Cortex XDR. You can use the star icon in the widget to

apply this filter, or you can use the Filter Builder to create a custom filter based on the Starred field1.

C) Create a custom report and filter on starred incidents: This is not the correct answer. Creating a

custom report and filtering on starred incidents is not the only way to filter the display to only show

starred incidents. A custom report is a report that you create by using the Report Builder to define

the data source, the layout, and the schedule. You can use custom reports to generate and share

periodic reports on your Cortex XDR data, but they are not the only option for filtering incidents by

stars3.

In conclusion, clicking the star in the widget is the simplest and easiest way to filter the display to

only show incidents that were “starred”. By using this feature, you can quickly identify and focus on

the most critical or relevant incidents in your environment.

Reference:

Filter Incidents by Stars

Create a Custom XQL Widget

Create a Custom Report

The Agent Auto Upgrade widget shows the status of the agent auto upgrade feature on the

endpoints. The widget displays the number of agents that are up to date, in progress, pending,

failed, and not configured. In this case, the widget shows that there are 450 agents that are up to

date, 78 in progress, 15 pending, 18 failed, and 128 not configured. This means that the agent auto

upgrade feature was enabled but not on all endpoints. Reference:

Cortex XDR Agent Auto Upgrade

PCDRA Study Guide

Quarantine is a feature of Cortex XDR that allows you to isolate a malicious file from its original

location and prevent it from being executed. Quarantine works by moving the file to a protected

folder on the endpoint and changing its permissions and attributes. Quarantine can be applied to

files detected by periodic scans or by behavioral threat protection (BTP) rules. Quarantine is only

supported for portable executable (PE) and dynamic link library (DLL) files. Quarantine does not

affect the network connectivity or the communication of the endpoint with Cortex XDR. Reference:

Quarantine Malicious Files

Manage Quarantined Files