Pcdra Study Guide

Contents
Palo Alto Networks PCDRA Study Guide 8

Overview 8
Exam Format 8
How to Take This Exam 9
Preparation Resources 9
Domain 1 Threats and Attacks 10
1.1 Recognize the different types of attacks 10
1.1.1 Differentiate between exploits and malware 10
1.1.2 Define a fileless attack 10
1.1.3 Define a supply chain attack 11
1.1.4 Outline ransomware threats 11
1.1.5 References 12
1.1.6 Sample Questions 12
1.2 Recognize common attack tactics 12
1.2.1 List common attack tactics 12
1.2.2 Define various attack tactics 13
1.2.3 Outline MITRE framework steps 14
1.2.4 References 15
1.3 Recognize various types of threats/vulnerabilities 16
1.3.1 Differentiate between threats and attacks 16
1.3.2 Define product modules that help identify threats 17
1.3.3 Identify legitimate threats (true positives) vs. illegitimate threats (false positives) 17
1.3.4 Summarize the generally available references for vulnerabilities 17
1.3.5 References 17
Domain 2 Prevention and Detection 19

2.1 Recognize common defense systems 19
2.1.1 Identify ransomware defense systems 19
2.1.2 Summarize device management defenses 19
2.1.3 References 20
PALO ALTO NETWORKS PCDRA Study Guide 2

2.2 Identify attack vectors 21
2.2.1 Summarize how to prevent agent attacks 21
2.2.2 Describe how to use XDR to prevent supply chain attacks 22
2.2.3 Describe how to use XDR to prevent phishing attacks 23
2.2.4 Characterize the differences between malware and exploits 24
2.2.5 Categorize the types and structures of vulnerabilities 24
2.2.6 References 25
2.3 Outline malware prevention 25
2.3.1 Define behavioral threat protection 25
2.3.2 Identify the profiles that must be configured for malware prevention 26
2.3.3 Outline malware protection flow 27
2.3.4 Describe the uses of hashes in Cortex XDR 30
2.3.5 Identify the use of malware prevention modules (MPMs) 30
2.3.6 References 31
2.4 Outline exploit prevention 32
2.4.1 Identify the use of exploit prevention modules (EPMs) 32
2.4.2 Define default protected processes 33
2.4.3 Characterize the differences between application protection and kernel protection 33
2.4.4 References 34
2.5 Outline analytic detection capabilities 35
2.5.1 Define the purpose of detectors 35
2.5.2 Define machine learning in the context of analytic detection 36
2.5.3 Identify the connection of analytic detection capabilities to MITRE 36
2.5.4 References 38
Domain 3 Investigation 39
3.1 Identify the investigation capabilities of Cortex XDR 39
3.1.1 Describe how to navigate the console 39
3.1.2 Identify the remote terminal options 40

3.1.3 Characterize the differences between incidents and alerts 42
3.1.4 Characterize the differences between exclusions and exceptions 44
3.1.5 References 45
3.2 Identify the steps of an investigation 46
3.2.1 Clarify how incidents and alerts interrelate 46
3.2.2 Identify the order in which to resolve incidents 47
3.2.3 Identify which steps are valid for an investigation 49
3.2.4 List the options to highlight or suppress incidents 50
3.2.5 References 51
3.3 Identify actions to investigate incidents 52
3.3.1 Describe when to perform actions using the live terminal 52
3.3.2 Describe what actions can be performed using the live terminal 53
3.3.3 Describe when to perform actions using a script 56
3.3.4 Identify common investigation screens and processes 56
3.3.5 References 58
3.4 Outline incident collaboration and management using XDR 59
3.4.1 Outline read and write attributes 59
3.4.2 Characterize the difference between incidents and alerts 60
3.4.3 References 62
Domain 4 Remediation 64
4.1 Describe basic remediation 64
4.1.1 Describe how to navigate the remediation suggestions 64
4.1.2 Distinguish between automatic vs. manual remediations 66
4.1.3 Summarize how/when to run a script 66
4.1.4 Describe how to fix false positives 68
4.1.5 References 68
4.2 Define examples of remediation 69
4.2.1 Define ransomware 69

4.2.2 Define registry 69
4.2.3 Define file changes/deletions 71
4.2.4 References 71
4.3 Define configuration options in XDR to fix problems 72
4.3.1 Define blocklist 72
4.3.2 Define signers 72
4.3.3 Define allowlist 72
4.3.4 Define exceptions 72
4.3.5 Define quarantine/isolation 73
4.3.6 Define file search and destroy 74
4.3.7 References 76
Domain 5 Threat Hunting 77

5.1 Outline the tools for threat hunting 77
5.1.1 Explain the purpose and use of the IOC technique 77
5.1.2 Explain the purpose and use of the BIOC technique 79
5.1.3 Explain the purpose and use of the XQL technique 82
5.1.4 Explain the purpose and use of the query builder technique 84
5.1.5 References 85
5.2 Identify how to prevent the threat 86
5.2.1 Convert BIOCs into custom prevention rules 86
5.2.2 References 87
5.3 Manage threat hunting 88
5.3.1 Describe the purpose of Unit 42 88
5.3.2 References 89
Domain 6 Reporting 90
6.1 Identify the reporting capabilities of XDR 90
6.1.1 Leverage reporting tools 90
6.1.2 References 90

6.2 Outline how to build a quality report 91
6.2.1 Identify what is relevant to a report given context 91
6.2.2 Interpret meaning from a report 93
6.2.3 Identify the information needed for a given audience 93
6.2.4 Outline the capabilities of XQL to build a report 95
6.2.5 Outline distributing and scheduling capabilities of Cortex XDR 98
6.2.6 References 99
Domain 7 Architecture 101

7.1 Outline components of Cortex XDR 101
7.1.1 Define the role of Cortex XDR Data Lake 101
7.1.2 Define the role of Cortex Agent 102
7.1.3 Define the role of Cortex Console 102
7.1.4 Define the role of Cortex Broker 102
7.1.5 Distinguish between different proxies 103
7.1.6 Define the role of Directory Sync 103
7.1.7 Define the role of WildFire 104
7.1.8 References 104
7.2 Describe communication among components 105
7.2.1 Define communication of data lakes 105
7.2.2 Define communication for WildFire 106
7.2.3 Define communication options/channels to and from the client 108
7.2.4 Define communication for external dynamic list (EDL) 109
7.2.5 Define communication from the broker 113
7.3 Describe the architecture of agent related to different operating systems
115
7.3.1 Recognize different supported operating systems 115
7.3.2 Characterize the differences between functions or features on operating systems 116

7.4 Outline how Cortex XDR ingests other non-Palo Alto Networks data
sources 119
7.4.1 Outline all ingestion possibilities 119
7.4.2 Outline all ingestion possibilities 120
7.5 Overview of functions and deployment of Broker 121
7.5.1 Outline deployment of Broker 121
7.5.2 Describe how to use the Broker to ingest third party alert 127
7.5.3 Describe how to use the Broker as a proxy between the agents and XDR in the Cloud 128
7.5.4 Describe how to use the Broker to activate Pathfinder 129
Appendix A: Sample Questions with Answers 134

Palo Alto Networks PCDRA Study Guide
Welcome to the Palo Alto Networks PCDRA Study Guide. The purpose of this guide is to help you prepare
for your Palo Alto Networks® Certified Detection and Remediation Analyst (PCDRA) exam and achieve
your PCDRA credential.
Overview
The PCDRA program is a formal, third-party-proctored certification. Success on the PCDRA exam shows
that you possess the in-depth skills and knowledge to develop playbooks, manage incidents, create
automations and integrations, and demonstrate the highest standard of deployment methodology and
operational best practices associated with Palo Alto Networks Cortex® XDR™. The exam is not intended
to trick you with its questions or to test obscure detail. However, a nuanced understanding, and the
ability gained through significant experience to make subtle technical distinctions, will help you make
better answer choices.
Exam Format
The test format is 60 multiple-choice items. Candidates will have five minutes to complete the
non-disclosure agreement (NDA), 80 minutes (1 hour, 20 minutes) to complete the questions, and five
minutes to complete a survey at the end of the exam.
The approximate distribution of items by topic (Exam Domain) and topic weightings are shown in the
following table.
This exam is based on Cortex XDR.
Exam Domain Weight (%)

Threats and Attacks 10
Prevention and Detection 20
Investigation 20
Remediation 15
Threat Hunting 10
Reporting 10
Architecture 15
Total 100%

How to Take This Exam
The exam is available through the third-party Pearson VUE testing platform. To register for the exam,
please visit https://home.pearsonvue.com/paloaltonetworks.
Preparation Resources
The document is a compilation of key resources to guide exam preparation. These resources cover the
material designated by the exam objectives. To study efficiently, focus on the suggested topics listed for
each resource. Be sure that you have a clear and complete understanding of these topics before taking
the exam.

Domain 1 Threats and Attacks
1.1 Recognize the different types of attacks
1.1.1 Differentiate between exploits and malware
The terms "“malware” and “exploit” are frequently used interchangeably and can be easily confused.
They are not, however, synonymous and have several distinct differences.
Malware
Malware refers to a file, program, or string of code used for malicious activity, such as damaging devices
and stealing sensitive data.
● It is typically delivered over a network, but it can also be delivered via physical media, and it is
classified according to the payload or malicious action it performs.
● Malware is classified as worms, Trojans, botnets, spyware, and viruses. Although each malware
strain behaves differently, worms are most associated with automated spreading behavior.
● Malware can be delivered via a variety of mediums, including email, social media, and instant
messaging.

1.1.3 Define a supply chain attack
A supply-chain attack is a sort of cyberattack that focuses on weaker connections in an organization's
supply chain to target them. The supply chain is the web of people, organizations, resources, activities,
and technology involved in the production and distribution of a product.
While running programs on various sorts of computers, we choose to trust that none of the people
involved in the development, packaging, and delivery of that software have malevolent intent or have
been compromised.
We’ve seen multiple cases of compromises in the “software supply chain,” which delivers trusted
software and updates to our systems for execution; and the impact of those compromises has continued
to escalate. Rather than targeting an organization directly through phishing or exploitation of
vulnerabilities, the attackers chose to compromise software developers directly and use the trust we
place in them to access other networks.
Attacks on software supply chains remind us how critical it is to build a well-defended network with
visibility at every stage of the attack lifecycle, as well as the ability to detect and stop activity that is out
of the ordinary.
1.1.4 Outline ransomware threats
Ransomware is a criminal business model that employs malicious software to encrypt valuable files,
data, or information in exchange for a ransom. Victims of ransomware attacks may have their operations
severely harmed or completely shut down.
Attackers must execute five steps for a ransomware attack to be successful:

● Compromise and take control of a system or device: Most ransomware attacks start with social
engineering, which involves convincing consumers to open an attachment or click a malicious
link in their browser. This allows attackers to take control of a system by installing malware.
● Prevent access to the system: Once they've gained access to the system, the attackers will either
identify and encrypt specific file types or refuse access to the entire system.
● Notify the victim: Naturally, attackers and victims speak a variety of languages and have differing
levels of technical expertise. Attackers must notify victims of the breach, make a ransom
demand, and explain how to restore access.
● Accept ransom payment: Attackers demand cryptocurrency, such as bitcoin, in order to receive
payment while avoiding law enforcement.
● Return full access: The attackers must regain access to the device(s). Failure to restore access to
hacked data or systems jeopardizes the scheme because few people would pay a ransom if they
didn't think their goods would be recovered.
1.1.5 References
Malware vs Exploits:

https://www.paloaltonetworks.com/cyberpedia/malware-vs-exploits
Ransomware:
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClTLCA0
1.1.6 Sample Questions
1. Which of the following is not considered malware?
a. virus
b. worm
c. cookies
d. spyware
e. Trojan
2. How does an attacker prefer to carry out supply-chain attacks?

a. by targeting an organization directly through phishing or exploitation of vulnerabilities
b. by targeting employees (software developers) of the target organization
c. by targeting items that aren’t written to disk
d. by targeting an organization's upper management directly
1.2 Recognize common attack tactics

1.2.1 List common attack tactics
The analytics engine can alert on any of the following attack tactics as defined by the MITRE ATT&CK
knowledge base of tactics.

1.2.2 Define various attack tactics
TACTIC DESCRIPTION
After attackers gain a foothold in your network, they can use various
techniques to execute malicious code on a local or remote endpoint. The
Cortex XDR app detects malware and grayware on your network using a
Execution
combination of network activity, Pathfinder data collector for your
unmanaged endpoints, endpoint data from your Cortex XDR agents, and
evaluation of suspicious files using the WildFire® cloud service.
To carry out a malicious action, an attacker can try techniques that
maintain access in a network or on an endpoint. An attacker can initiate
Persistence configuration changes—such as a system restart or failure—that require
the endpoint to restart a remote access tool or open a backdoor that
allows the attacker to regain access on the endpoint.
After an attacker has access to a part of your network, they use
discovery techniques to explore and identify subnets and discover
servers and the services that are hosted on those endpoints. The app
Discovery
detects attacks that use this tactic by looking for symptoms in your
internal network traffic such as increased rates of connections, failed
connections, and port scans.
To expand the footprint inside your network, an attacker uses
lateral-movement techniques to obtain credentials to gain additional
access to more data in the network. The analytics engine detects attacks
Lateral Movement
during this phase by examining administrative operations, file-share
access, and user-credential usage that is beyond the norm for your
network.
The command-and-control tactic allows an attacker to remotely issue
Command and Control commands to an endpoint and receive information from it. The analytics
engine identifies intruders using this tactic by looking for anomalies in

outbound connections, DNS lookups, and endpoint processes with
bound ports. The app is looking for unexplained changes in the
periodicity of connections and failed DNS lookups, changes in random
DNS lookups, and other symptoms that suggest that an attacker has
gained initial control of a system.
Exfiltration tactics are techniques to receive data from a network, such
as valuable enterprise data. The app seeks to identify exfiltration by
Exfiltration examining outbound connections with a focus on the volume of data
being transferred. Increases in this volume are an important symptom of
data exfiltration.
1.2.3 Outline MITRE framework steps
Step 1: Identify behaviors
The MITRE ATT&CK framework outlines a variety of strategies that an attacker might employ to
accomplish a variety of objectives. When using the MITRE ATT&CK framework to detect a potential
intrusion, it's important to focus on the techniques that have the best chance of finding the attacker.
Step 2: Acquire data

Most organizations collect some level of security data as part of their regular operations. This data is fed
into security information and event management (SIEM) and other data-analytics tools. It doesn't mean
that the analyst has direct access to the data or that the right data has been collected to identify a
particular technique. At this point, steps should be taken to begin collecting any necessary data that is
not currently being collected (if possible). This may include network and endpoint data.
Step 3: Develop analytics

After an analyst has collected the required data, they need a means of processing it to extract usable
intelligence. For this, they need to develop analytics that should be run against the data.
MITRE describes four types of analytics:

● Behavioral: Behavioral analytics are designed to detect the use of a specific technique as
detailed in the MITRE ATT&CK framework.
● Situational Awareness: These analytics are designed to provide general information regarding
the state of the network. They include tracking login attempts, monitoring system health, etc.
● Anomaly/Other: Anomaly analytics are intended to identify usual – but not necessarily
malicious – events on the network, such as the execution of a program that has never been seen
before.
● Forensic: Forensic analytics are designed to support forensic investigations.
Step 4: Develop an adversary-emulation scenario
Organizations can undergo security assessments for a variety of different purposes. In most cases, it is
infeasible to test every potential attack vector, type of adversary, etc.
During this stage of the process, the rules of engagement are laid out. This includes:
● Sensor/analytic and defensive capabilities to be tested
● Common adversary behavior to be used
● Rough plan with sequences of actions suggested to verify defensive capabilities

● System, network, or other resources needed for the cyber game/test.
The goal of this scenario is to provide a framework in which the red and blue teams can operate. It
defines the overall goals and plan for the exercise but also leaves room for flexibility and adaptation if
needed.
Step 5: Emulate threat
At this point in the process, the exercise is ready to begin. Based upon the scenarios and framework laid
out in the previous step, the red team begins their assessment of the security of the system under test.
Step 6: Investigate attack

The overall objective of a cybersecurity assessment is to determine the effectiveness of an organization’s
defenses. After the red team performs the attack, the blue team attempts to determine what they are
doing. MITRE suggests the use of asynchronous operations so that the red team’s attack is not inhibited
by the defenders and to better emulate a real-world scenario.
This stage of the process uses the analytics developed earlier. Ideally, the behavioral analytics should be
capable of detecting the attacker activity and narrowing down the list of potentially compromised
machines. From there, the other analytics should enable the blue team to identify the malicious activity.
Step 7: Evaluate performance

After the exercise is complete, the red and blue teams should debrief. Based upon both teams’
experience, they can identify what did and did not work and how the network defenses can be improved
for the future.
1.2.4 References
Attack Tactics:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/analytics/analytics-concepts
1. Which MITRE ATT&CK tactic is being used if the adversary is attempting to communicate with
compromised systems to control them?
a. Exfiltration
b. Command and Control
c. Execution
d. Persistence
e. Lateral Movement
2. Which MITRE ATT&CK tactic is being used if the adversary is trying to run malicious code?
a. Exfiltration
c. Execution

d. Persistence
e. Lateral Movement
1.3 Recognize various types of threats/vulnerabilities

1.3.1 Differentiate between threats and attacks
Threat
A threat is a possible security condition/violation to exploit the vulnerability of a system/asset. A threat
can arise from any condition—for example, accident, fire incident, environmental (e.g., natural disaster),
or human negligence. The following are types of threats:
● Interruption - An asset of the system becomes lost, unavailable, or unusable.
● Interception - Some unauthorized party has gained access to an asset.
● Fabrication - An unauthorized party inserts spurious transactions into a network communication
system or add records to an existing database.
● Modification - An unauthorized party not only accesses but tampers with an asset.
Attack
An attack is an intended unauthorized action on a system/asset. An attack always has a motivation to
misuse the system and generally waits for an opportunity to occur.
The following are some key distinctions between threats and attacks.
S. No. Key Threat Attack

1 Definition A condition/circumstance that can An intended action to cause
cause damage to the system/asset damage to system/asset
2 Malicious May or may not be malicious Always malicious
3 Intentional Can be intentional like human It is a deliberate action. An
negligence/failure or attacker has a motive and plans
unintentional like natural disaster the attack accordingly
4 Chance for Chance of damage or information Chance of damage or information
Damage alteration varies from low to very alteration is very high
high
5 Detection Difficult to detect Comparatively easy to detect
6 Prevention Can be prevented by controlling Cannot be prevented by
the vulnerabilities controlling the vulnerabilities.
Other measures, such as backup
or detect and act are required to
handle a cyberattack.
1.3.2 Define product modules that help identify threats
When you identify a threat, you can define specific rules for Cortex® XDR™ to raise alerts. You can
define the following rules:

Behavioral indicators of compromise (BIOCs)
Identifying threats based on their behaviors can be a difficult task. You construct BIOCs that can alert you
when certain network, process, file, or registry activity that indicates a threat is detected.
Indicators of compromise (IOCs)

IOCs are known artifacts that are considered malicious or suspicious. Static IOCs are based on criteria
such as SHA-256 hashes, IP addresses and domains, file names, and paths. You create IOC rules based on
information gained from various threat intelligence feeds or gathered from an investigation within Cortex
XDR.
Correlations rules
Correlations rules you analyze correlations of multi-events from multiple sources by using the Cortex
XDR XQL-based engine for creating scheduled rules called Correlations Rules.
1.3.3 Identify legitimate threats (true positives) vs. illegitimate threats (false
positives)
True positives
A legitimate attack that produces an alarm. For example, you have a brute-force alert, and it triggers. You
investigate the alert and find out that somebody was indeed trying to break into one of your systems via
brute force methods.
False positives
An event that produces an alarm when no attack has taken place. For example, you investigate another
of these brute-force alerts and find out that it was just some user who mistyped their password multiple
times, not a real attack.
1.3.4 Summarize the generally available references for vulnerabilities
Cortex XDR vulnerability assessment enables you to identify and quantify the security vulnerabilities on
an endpoint in Cortex XDR. Relying on the information from Cortex XDR, you can easily mitigate and
patch these vulnerabilities on all endpoints in your organization.
To provide you with a comprehensive understanding of the vulnerability severity, Cortex XDR retrieves
the latest data for each CVE from the NIST National Vulnerability Database, including CVE severity and
metrics. You can use Cortex XDR to evaluate the extent and severity of each CVE in your network, gain
full visibility into the risks to which each endpoint is exposed, and assess the vulnerability status of an
installed application in your network.
1.3.5 References
Threats and Attacks:

https://www.tutorialspoint.com/difference-between-threat-and-attack#:~:text=Attack%20%20%20%20S
r.%20No.%20%20,information%20alte%20...%20%202%20more%20rows%20
Vulnerability:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/endpoint-security/hardened
-endpoint-security/vulnerability-management
1. Which statement does not describe an attack?
a. An attacker has a motive and plans the attack accordingly.
b. The chance of damage or information alteration varies from low to very high.
c. An attack cannot be prevented by controlling the vulnerabilities.
d. It is always malicious.
2. You notice that a hardware device is damaged and important data files have been completely
erased from the system. What kind of threat appears to be present here?
a. Interruption
b. Interception
c. Fabrication
d. Modification

Domain 2 Prevention and Detection
2.1 Recognize common defense systems
2.1.1 Identify ransomware defense systems
Ransomware is a family of malware that attempts to encrypt files on end-user computers and then
demands some form of e-payment to recover the encrypted files. Ransomware is one of the more
common threats in the modern threat landscape.
Ransomware is delivered to targets primarily through these avenues:

● Phishing emails may contain malicious attachments. These attachments are not always delivered
in executable form because security vendors and security best practices dictate that receiving
executables via email is, in general, something we want to prevent.
● Exploit kits (such as Angler or Neutrino) have been known to deliver ransomware to users by
exploiting vulnerable web servers and hosting malicious web scripts on them that exploit visitors
when certain criteria are met, and then delivering a malicious payload.
● Targeted ransomware has been noted and tracked recently, in which organizations had
external-facing web servers compromised by malicious actors, who proceeded to map the
environment out.
Prevention:
Step 1: Reduce the attack surface
● Gain full visibility and block unknown traffic.
● Enforce application- and user-based controls.
● Block all dangerous file types.
● Implement an endpoint policy aligned to risk.
Step 2: Prevent known threats

● Stop known exploits, malware, and command-and-control traffic.
● Block access to malicious and phishing URLs.
● Scan for known malware on SaaS-based applications.
● Block known malware and exploits on the endpoint.
Step 3: Identify and prevent unknown threats

● Detect and analyze unknown threats in files and URLs.
● Update protections across the organization to prevent previously unknown threats.
● Add context to threats and create proactive protections and mitigation.
● Block unknown malware and exploits on the endpoint.
2.1.2 Summarize device management defenses
By default, all external USB devices are allowed to connect to your Cortex XDR endpoints. To protect
endpoints from connecting USB-connected removable devices—such as disk drives, CD-ROM drives,
floppy disk drives, and other portable devices—that can contain malicious files, Cortex XDR provides
device control.

For example, with device control, you can:
● Block all supported USB-connected devices for an endpoint group.
● Block a USB device type but add to your allow list a specific vendor from that list that will be
accessible from the endpoint.
● Temporarily block only some USB device types on an endpoint.
Device Control Profiles:

To apply device control in your organization, you define device control profiles that determine which
device types Cortex XDR blocks and which it permits. There are two types of profiles:
PROFILE DESCRIPTION
Configuration Profile Allow or block these USB-connected device type groups:
● Disk Drives
● CD-ROM Drives
● Floppy Disk Drives
● (Windows only) Windows Portable Devices
Cortex XDR relies on the device class assigned by the

operating system.
Exceptions Profile Allow specific devices according to device types and vendor. You can
further allow a specific product and/or product serial number.
Device Configuration and Device Exceptions profiles are set for each operating system separately. After
you configure a device control profile, apply device control profiles to your endpoints.
2.1.3 References
Ransomware:
https://www.paloaltonetworks.com/cyberpedia/ransomware-prevention-what-your-security-architectur
e-must-do
Device Control:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/endpoint-security/hardened
-endpoint-security/device-control.html

1. Which two statements about ransomware are correct? (Choose two.)
a. It can encrypt files and demand money in order to restore them.
b. It focuses on weaker connections in an organization's supply chain.
c. It has the potential to harm an organization's reputation.
d. It sends fraudulent communications that appear to be from a reputable source.
2. Which two of the following are examples of ransomware? (Choose two.)

a. Malvertising

b. Trojan Horse
c. Petya
d. Locky
2.2 Identify attack vectors

2.2.1 Summarize how to prevent agent attacks
In environments where agents communicate with the Cortex XDR server through a system-wide proxy,
you can now set an application-specific proxy for the Traps and Cortex XDR agent without affecting the
communication of other applications on the endpoint. You can set the proxy in one of three ways: during
the agent installation, after installation using Cytool on the endpoint, or from endpoints management in
Cortex XDR as described in this topic. You can assign up to five different proxy servers per agent. The
proxy server that the agent uses is selected randomly and with equal probability. If the communication
between the agent and the Cortex XDR server through the app-specific proxies fails, the agent resumes
communication through the system-wide proxy defined on the endpoint. If that fails as well, the agent
resumes communication with Cortex XDR directly.
Step 1: From Cortex XDR, select Endpoints > Endpoint Management > Endpoint Administration.
Step 2: If needed, filter the list of endpoints.
Step 3: Set an agent proxy.
● Select the row of the endpoint for which you want to set a proxy.
● Right-click the endpoint and select Endpoint Control > Set Endpoint Proxy.
● You can assign up to five different proxies per agent. For each proxy, enter the IP address and
port number. For Cortex XDR agents 7.2.1 and later, you can also configure the proxy by entering
the FQDN and port number. When you enter the FQDN, you can use either all lowercase letters
or all uppercase letters. Avoid using special characters or spaces.
For example: my.network.name:808,YOUR.NETWORK.COM:888,10.196.20.244:8080.

● Set when you’re done.
● If necessary, you can later Disable Endpoint Proxy from the right-click menu.
When you disable the proxy configuration, all proxies associated with that agent are removed. The
agent resumes communication with the Cortex XDR server through the wide-system proxy if
defined, otherwise if a wide-system is not defined, the agent resumes communicating directly
with the Cortex XDR server. If neither a wide-system proxy nor direct communication exist and
you disable the proxy, the agent will disconnect from Cortex XDR.
2.2.2 Describe how to use XDR to prevent supply-chain attacks
A supply-chain attack is a sort of cyberattack that focuses on weaker connections in an organization's

supply chain to target them. The supply chain is the web of people, organizations, resources, activities,
and technology involved in the production and distribution of a product.
Rather than targeting an organization directly through phishing or exploitation of vulnerabilities, the
attackers chose to compromise software developers directly and use the trust we place in them to access
other networks.
The attackers research, identify, and select targets that will allow them to meet their objectives.
Attackers gather information through publicly available sources, such as Twitter, LinkedIn, and corporate
websites. They will also scan for vulnerabilities that can be exploited within the target network, services,
and applications, mapping out areas where they can take advantage. At this stage, attackers are looking
for weaknesses from the human and systems perspective.
Steps to be taken to prevent a supply-chain attack:

● Implement security awareness training so users are mindful about what should and should not
be posted – sensitive documents, customer lists, event attendees, job roles and responsibilities
(i.e., using specific security tools within an organization), etc.
● Perform continuous inspection of network traffic flows to detect and prevent port scans and
host sweeps.
● Provide ongoing education to users on spear-phishing links, unknown emails, risky websites, etc.
● Limit local admin access of users.
● Train users to identify the signs of a malware infection and know how to follow up if something
occurs.
Cortex XDR provides a multimethod protection solution with exploit protection modules that target
software vulnerabilities in processes that open non-executable files and malware-protection modules
that examine executable files, DLLs, and macros for malicious signatures and behavior. Using this
multimethod approach, the Cortex XDR solution can prevent all types of attacks, whether they are
known or unknown threats.

2.2.3 Describe how to use XDR to prevent phishing attacks
Phishing is the act of sending fraudulent communications that appear to be from a reputable source. It is
usually done via email. The intention is to steal sensitive data such as credit card and login information,
or to install malware on the victim's machine. Phishing is a common type of cyberattack that everyone
should be aware of in order to stay safe.
Attackers determine which methods to use to deliver malicious payloads. Some of the methods they
might utilize are automated tools, such as exploit kits, spear-phishing attacks with malicious links, or
attachments and malvertizing.
Steps to be taken to prevent a phishing attack:

● Gain full visibility into all traffic, including SSL, and block high-risk applications. Extend those
protections to remote and mobile devices.
● Protect against perimeter breaches by blocking malicious or risky websites through URL filtering.
● Block known exploits, malware, and inbound command-and-control communications using
multiple threat prevention disciplines, including IPS, anti-malware, anti-CnC, DNS monitoring and
sinkholing, and file and content blocking.
● Detect unknown malware and automatically deliver protections globally to thwart new attacks.
● Provide ongoing education to users on spear-phishing links, unknown emails, risky websites, etc.
Cortex XDR provides a multimethod protection solution with exploit protection modules that target
software vulnerabilities in processes that open non-executable files and malware protection modules
that examine executable files, DLLs, and macros for malicious signatures and behavior. Using this

multi-method approach, the Cortex XDR solution can prevent all types of attacks, whether these are
known or unknown threats.
2.2.4 Characterize the differences between malware and exploits
The terms “malware” and “exploit” are frequently used interchangeably and can be easily confused.
They are not, however, synonymous and have several distinct differences.
Malware
Malware refers to a file, program or string of code used for malicious activity, such as damaging devices
and stealing sensitive data.
● It is typically delivered over a network, but it can also be delivered via physical media, and it is
classified according to the payload or malicious action it performs.
● Malware is classified as worms, Trojans, botnets, spyware, and viruses. Although each malware
strain behaves differently, worms are most associated with automated spreading behaviour.
● Malware can be delivered via a variety of mediums, including email, social media, and instant
messaging.
Exploit
An exploit is a piece of code or program that takes advantage of a weakness in an application or system.
Exploits can lead to behavior such as arbitrary code execution, privilege escalation, denial of service, or
data exposure.
● Exploits may be categorized into known and unknown (i.e., zero-day) exploits.
● Zero-day exploits generally present a significant threat to an organization as they take advantage
of unreported vulnerabilities for which no software patch is available.
● At times, adversaries may attempt to exploit vulnerabilities via collections or kits hidden on
invisible landing pages or hosted on advertisement networks.
● If a victim lands on one of these sites, the exploit kit will automatically scan their computer to
find out the operating system the computer is using, and the kit will use the appropriate exploit
code and attempt to install and execute malware.
2.2.5 Categorize the types and structures of vulnerabilities

A vulnerability is any flaw in an organization's information systems, internal controls, or system processes
that cybercriminals can exploit. Cyber adversaries can gain access to your system and collect data
through points of vulnerability. In terms of your organization's overall security posture, cybersecurity
vulnerabilities are critical to monitor because gaps in a network can lead to a full-scale system breach.
Vulnerability Protection profiles stop attempts to exploit system flaws or gain unauthorized access to
systems. While Anti-Spyware profiles help identify infected hosts as traffic leaves the network,
Vulnerability Protection profiles protect against threats entering the network. For example, Vulnerability
Protection profiles help protect against buffer overflows, illegal code execution, and other attempts to
exploit system vulnerabilities. The default Vulnerability Protection profile protects clients and servers
from all known critical-, high-, and medium-severity threats. You can also create exceptions, which allow
you to change the response to a specific signature.

Types of vulnerabilities:
● Software vulnerabilities
● Firewall Vulnerabilities
● TCP/IP Vulnerabilities
● Wireless Network Vulnerabilities
● Operating System Vulnerabilities
● Web Server Vulnerabilities
2.2.6 References
Endpoint Protection:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/endpoint-security/endpoint-
security-concepts/about-cortex-xdr-protection
How to Break the Cyber Attack Lifecycle:

https://www.paloaltonetworks.com/cyberpedia/how-to-break-the-cyber-attack-lifecycle

1. What does the term "TCP/IP" stand for?
a. Transmission Contribution Protocol/ internet protocol
b. Transmission Control Protocol/ internet protocol
c. Transaction Control Protocol/ internet protocol
d. Transmission Control Prevention/ internet protocol
2. Which type of attack does the following statement describe?

The attacker identifies and targets software developers who are actively working on the project.
a. eavesdropping attack
b. ransomware
c. phishing attack
d. supply-chain attack
2.3 Outline malware prevention

2.3.1 Define behavioral threat protection
With behavioral threat protection, the agent continuously monitors endpoint activity to identify and
analyze chains of events—known as causality chains. This enables the agent to detect malicious activity
in the chain that could otherwise appear legitimate if inspected individually. A causality chain can include
any sequence of network, process, file, and registry activities on the endpoint. Behavioral threat
protection can also identify behavior related to vulnerable drivers on Windows endpoints. For more
information on data collection for behavioral threat protection, see Endpoint Data Collected by Cortex
XDR.

Palo Alto Networks researchers define the causality chains that are malicious and distribute those chains
as behavioral threat rules. When the Cortex XDR agent detects a match to a behavioral threat protection
rule, the Cortex XDR agent carries out the configured action (default is Block). In addition, the Cortex
XDR agent reports the behavior of the entire event chain up to the process, known as the causality group
owner (CGO), that the Cortex XDR agent identified as triggering the event sequence.
To configure behavioral threat protection:

Step 1: Define the Action mode to take when the Cortex XDR agent detects malicious causality chains:
● Block(default)—Block all processes and threads in the event chain up to the CGO.
● Report—Allow the activity but report it to Cortex XDR.
● Disabled—Disable the module and do not analyze or report the activity.
Step 2: Define whether to quarantine the CGO when the Cortex XDR agent detects a malicious event
chain.
● Enabled—Quarantine the CGO if the file is not signed by a highly trusted signer. When the CGO
is signed by a highly trusted signer or powershell.exe, wscript.exe, cscript.exe, mshta.exe,
excel.exe, word.exe or powerpoint.exe, the Cortex XDR agent parses the command-line
arguments and instead quarantines any scripts or files called by the CGO.
● Disable (default)—Do not quarantine the CGO of an event chain nor any scripts or files called by
the CGO.
Step 3: Define the Action mode for vulnerable drivers protection.

Behavioral threat protection rules can also detect attempts to load vulnerable drivers. As with other
rules, Palo Alto Networks threat researchers can deliver changes to vulnerable driver rules with content
updates.
● Block (default)—Block all attempts to run vulnerable drivers.
● Report—Allow vulnerable drivers to run but report the activity.
● Disabled—Disable the module and do not analyze or report the activity.
Step 4: (Optional) Add to your allow list any files that you do not want the Cortex XDR agent to terminate
when a malicious causality chain is detected. The allow list does not apply to vulnerable drivers.
● +Add a file path.
● Enter the file path you want to exclude from evaluation. Use ? to match a single character or * to
match any string of characters.
● Click the check mark to confirm the file path.
● Repeat the process to add any additional file paths to your allow list.
2.3.2 Identify the profiles that must be configured for malware prevention
Attackers always look for quick ways to steal data. Using readily available automated tools and advanced
techniques, they can do so with ease, leaving your traditional network defenses ineffective. Malware is
designed to spread quickly, create havoc, and affect as many machines as possible. To protect your
organization against such threats, you need a holistic, enterprise-wide malware protection strategy.
You only create the illusion of security if you only rely on perimeter security, such as firewalls,
intrusion-prevention systems, and URL filtering, or if you focus only on endpoint security, such as
antivirus, anti-spam, and malware analysis. With the ever-increasing attack surface and the growing
prevalence of automated, sophisticated, and volumetric attacks, you need a platform approach built for

automation. To stay ahead of attackers, you need a malware protection strategy that includes a global
threat intelligence community and covers the network, endpoint, and cloud.
Profiles that must be configured:

Antivirus Profiles - Antivirus profiles protect against viruses, worms, and trojans, as well as spyware
downloads.
Anti-Spyware Profiles - Anti-Spyware profiles block spyware on compromised hosts from trying to phone
home or beacon out to external command-and-control (C2) servers, allowing you to detect malicious
traffic leaving the network from infected clients.
Vulnerability Protection Profiles - Vulnerability Protection profiles stop attempts to exploit system flaws
or gain unauthorized access to systems. While Anti-Spyware profiles help identify infected hosts as traffic
leaves the network, Vulnerability Protection profiles protect against threats entering the network.
URL Filtering Profiles - URL Filtering profiles enable you to monitor and control how users access the
web over HTTP and HTTPS.
Data Filtering Profiles - Data filtering profiles prevent sensitive information such as credit card or Social
Security numbers from leaving a protected network. A Data Filtering profile also allows you to filter by
key words, such as a sensitive project name or the word confidential.
File Blocking Profiles - The firewall uses File Blocking profiles to block specified file types over specified
applications and in the specified session flow direction (inbound/outbound/both).
WildFire Analysis Profiles - Use a WildFire Analysis profile to enable the firewall to forward unknown
files or email links for WildFire analysis. Specify files to be forwarded for analysis based on application,
file type, and transmission direction (upload or download).
DoS Protection Profiles - DoS Protection profiles provide detailed control for denial of service (DoS)
protection policies. DoS policies allow you to control the number of sessions between interfaces, zones,
addresses, and countries based on aggregate sessions or source and/or destination IP addresses.
Zone Protection Profiles - Zone Protection profiles provide additional protection between specific
network zones in order to protect the zones against attack. The profile must be applied to the entire
zone, so it is important to carefully test the profiles in order to prevent issues that may arise with the
normal traffic traversing the zones.
2.3.3 Outline malware protection flow
The Cortex XDR agent provides malware protection in a series of four evaluation phases:

Phase 1: Evaluation of Child Process Protection Policy
When a user attempts to run an executable, the operating system attempts to run the executable as a
process. If the process tries to launch any child processes, the Cortex XDR agent first evaluates the Child
Process Protection policy. If the parent process is a known targeted process that attempts to launch a
restricted child process, the Cortex XDR agent blocks the child processes from running and reports the
security event to Cortex XDR. For example, if a user tries to open a Microsoft Word document (using the
winword.exe process) and that document has a macro that tries to run a blocked child process (such as
WScript), the Cortex XDR agent blocks the child process and reports the event to Cortex XDR. If the
parent process does not try to launch any child processes or tries to launch a child process that is not
restricted, the Cortex XDR agent next moves to Phase 2.
Phase 2: Evaluation of the Restriction Policy

When a user or machine attempts to open an executable file, the Cortex XDR agent first evaluates the
Child Process Protection policy, as described in Phase 1. The Cortex XDR agent next verifies that the
executable file does not violate any restriction rules. For example, you might have a restriction rule that
blocks executable files launched from network locations. If a restriction rule applies to an executable file,
the Cortex XDR agent blocks the file from executing and reports the security event to Cortex XDR.
Depending on the configuration of each restriction rule, the Cortex XDR agent can also notify the user
about the prevention event.
If no restriction rules apply to an executable file, the Cortex XDR agent next moves to Phase 3.
Phase 3: Hash Verdict Determination

The Cortex XDR agent calculates a unique hash using the SHA-256 algorithm for every file that attempts
to run on the endpoint. Depending on the features that you enable, the Cortex XDR agent performs
additional analysis to determine whether an unknown file is malicious or benign. The Cortex XDR agent
can also submit unknown files to Cortex XDR for in-depth analysis by WildFire.

To determine a verdict for a file, the Cortex XDR agent evaluates the file in the following order:
● Hash exception - A hash exception enables you to override the verdict for a specific file without
affecting the settings in your Malware Security profile. The Hash Exception policy is evaluated
first and takes precedence over all other methods to determine the hash verdict.
● Highly trusted signers (Windows and Mac) - The Cortex XDR agent distinguishes highly trusted
signers such as Microsoft from other known signers. To keep parity with the signers defined in
WildFire, Palo Alto Networks regularly reviews the list of highly trusted and known signers and
delivers any changes with content updates. The list of highly trusted signers also includes signers
that are included the allow list from Cortex XDR. When an unknown file attempts to run, the
Cortex XDR agent applies the following evaluation criteria: Files signed by highly trusted signers
are permitted to run, and files signed by prevented signers are blocked, regardless of the
WildFire verdict. When a file is not signed by a highly trusted signer or by a signer included in the
block list, the Cortex XDR agent next evaluates the WildFire verdict. For Windows endpoints,
evaluation of other known signers takes place if WildFire evaluation returns an unknown verdict
for the file.
● WildFire verdict - If a file is not signed by a highly trusted signer on Windows and Mac
endpoints, the Cortex XDR agent performs a hash verdict lookup to determine whether a verdict
already exists in its local cache.
If the executable file has a malware verdict, the Cortex XDR agent reports the security event to the
Cortex XDR and, depending on the configured behavior for malicious files, the Cortex XDR agent
then does one of the following:
o Blocks the malicious executable file
o Blocks and quarantines the malicious executable file
o Notifies the user about the file but still allows the file to execute
o Logs the issue without notifying the user and allows the file to execute.
If the verdict is benign, the Cortex XDR agent moves on to the next stage of evaluation.
If the hash does not exist in the local cache or has an unknown verdict, the Cortex XDR agent
next evaluates whether the file is signed by a known signer.
● Local analysis - When an unknown executable, DLL, or macro attempts to run on a Windows or
Mac endpoint, the Cortex XDR agent uses local analysis to determine whether it is likely to be
malware. On Windows endpoints, if the file is signed by a known signer, the Cortex XDR agent
permits the file to run and does not perform additional analysis. For files on Mac endpoints and
files that are not signed by a known signer on Windows endpoints, the Cortex XDR agent
performs local analysis to determine whether the file is malware. Local analysis uses a static set
of pattern-matching rules that inspect multiple file features and attributes, together with a
statistical model that was developed with machine learning on WildFire threat intelligence. The
model enables the Cortex XDR agent to examine hundreds of characteristics for a file and issue a
local verdict (benign or malicious) while the endpoint is offline or Cortex XDR is unreachable. The
Cortex XDR agent can rely on the local-analysis verdict until it receives an official WildFire verdict
or hash exception.
Local analysis is enabled by default in a Malware Security profile. Because local analysis always
returns a verdict for an unknown file, if you enable the Cortex XDR agent to Block files with an
unknown verdict, the agent only blocks unknown files if a local analysis error occurs or local

analysis is disabled. To change the default settings (not recommended), see Add a New Malware
Security Profile.
Phase 4: Evaluation of Malware Security Policy
If the prior evaluation phases do not identify a file as malware, the Cortex XDR agent observes the
behavior of the file and applies additional malware protection rules. If a file exhibits malicious behavior,
such as encryption-based activity common with ransomware, the Cortex XDR agent blocks the file and
reports the security event to the Cortex XDR. If no malicious behavior is detected, the Cortex XDR agent
permits the file (process) to continue running but continues to monitor the behavior for the lifetime of
the process.
2.3.4 Describe the uses of hashes in Cortex XDR
A hash exception enables you to override the verdict for a specific file without affecting the settings in
your Malware Security profile. The hash exception policy is evaluated first and takes precedence over all
other methods to determine the hash verdict.
For example, you may want to configure a hash exception for any of the following situations:
● You want to block a file that has a benign verdict.
● You want to allow a file that has a malware verdict to run. In general, Palo Alto Networks
recommends that you only override the verdict for malware after you use available threat
intelligence resources—such as WildFire and AutoFocus—to determine that the file is not
malicious.
● You want to specify a verdict for a file that has not yet received an official WildFire verdict.
After you configure a hash exception, Cortex XDR distributes it at the next heartbeat communication
with any endpoints that have previously opened the file.
When a file launches on the endpoint, the Cortex XDR agent first evaluates any relevant hash exception
for the file. The hash exception specifies whether to treat the file as malware. If the file is assigned a
benign verdict, the Cortex XDR agent permits it to open.
If a hash exception is not configured for the file, the Cortex XDR agent next evaluates the verdict to
determine the likelihood of malware.
2.3.5 Identify the use of malware prevention modules (MPMs)
A malware protection rule prevents the execution of malware, often disguised as or embedded in

nonmalicious files, by using malware modules to target process behaviors that are commonly triggered
by malware.
The following describes the malware protection modules:

Child Process Protection MPM:
The Child Process Protection MPM for Windows endpoints prevents script-based attacks used to deliver
malware such as ransomware. To prevent these attacks, the MPM is enabled by default and blocks
known targeted processes from launching child processes commonly used to bypass traditional security
approaches.
For increased flexibility, you can configure the module to operate in one of two ways:

● Use an allow list to block all child processes initiated by a process except for those specified in
the allow list.
● Use a block list to allow a process to run all child processes except for those specified in the
block list.
You can also define whether you want Traps to evaluate a list of child processes or whether to evaluate a
specific argument supplied to a child process.
To evaluate your child process protection policy, Traps merges all applicable child process protection
rules into a single policy. User-defined child process protection rules take precedence over default child
process protection rules.
Anti-Ransomware Protection MPM:

The Anti-Ransomware Protection MPM provides additional protection against ransomware. The module
targets encryption-based activity associated with ransomware with the ability to analyze and halt
ransomware activity before any data loss occurs.
In a ransomware attack, typically the attacker uses DLLs, macros, shell scripts, and other methods to
encrypt important data and holds the data hostage until the user pays a ransom to unlock the data. To
combat these attacks, Traps detects the behavior and prevents the ransomware from encrypting and
holding files hostage.
Like other MPMs, you can configure the module to operate in either notification or prevention mode.
When you configure the module to operate in prevention mode, Traps blocks the process exhibiting
ransomware behavior. When you configure this module in notification mode, Traps logs a security event
for each process once per minute. This means that if the same process exhibits ransomware behavior
within a minute of the first attempt, Traps ignores the event. This prevents the Traps agent from logging
and reporting an excessive number of events.
Gatekeeper Enhancement MPM:

The Gatekeeper Enhancement MPM is an enhancement of the macOS gatekeeper functionality that
allows apps to run based on their digital signature. The MPM provides an additional layer of protection
by extending gatekeeper functionality to child processes to enforce the signature level of your choice (for
example, by Apple System, Mac App Store, or Developers).
By enforcing the signature level, you can prevent attackers from leveraging a logical vulnerability in an
existing process to bypass the OS verification of the signature level. You can also choose to allow child
processes to run if they match (or exceed) the signature level of the parent process, or you can block all
child processes regardless of digital signature.
2.3.6 References
Behavioral Threat Protection:

https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-prevent-admin/endpoint-security/endp
oint-security-profiles/add-malware-security-profile
Malware Protection Flow:

security-concepts/analysis-and-protection-flow
Malware Protection Rules:

https://docs.paloaltonetworks.com/traps/4-2/traps-endpoint-security-manager-admin/malware-protecti
on/manage-malware-protection-rules/malware-protection-rules.html
Security Profiles:
https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-admin/policy/security-profiles

1. Which type of profile prevents attempts to exploit system flaws or obtain unauthorized access to
systems?
a. Antivirus profile
b. Anti-Spyware profile
c. Vulnerability Protection profile
d. URL Filtering profile
2. At what phase in the malware protection flow does the Cortex XDR agent observe the file's
behavior and apply additional malware protection rules?
a. Evaluation of Child Process Protection Policy
b. Evaluation of the Restriction Policy
c. Hash Verdict Determination
d. Evaluation of Malware Security Policy
2.4 Outline exploit prevention

2.4.1 Identify the use of exploit prevention modules (EPMs)
In a typical attack scenario, an attacker attempts to gain control of a system by first corrupting or
bypassing memory allocation or handlers. Using memory-corruption techniques, such as buffer
overflows and heap corruption, a hacker can trigger a bug in software or exploit a vulnerability in a
process. The attacker must then manipulate a program to run code provided or specified by the attacker
while evading detection.
If the attacker gains access to the operating system, the attacker can then upload malware, such as
Trojan horses (programs that contain malicious executable files), or can otherwise use the system to
their advantage. The Cortex XDR agent prevents such exploit attempts by employing roadblocks—or
traps—at each stage of an exploitation attempt.

When a user opens a non-executable file, such as a PDF or Word document, and the process that opened
the file is protected, the Cortex XDR agent seamlessly injects code into the software. This occurs at the
earliest possible stage before any files belonging to the process are loaded into memory. The Cortex XDR
agent then activates one or more protection modules inside the protected process. Each protection
module targets a specific exploitation technique and is designed to prevent attacks on program
vulnerabilities based on memory corruption or logic flaws.
In addition to automatically protecting processes from such attacks, the Cortex XDR agent reports any
security events to Cortex XDR and performs additional actions as defined in the Endpoint Security policy.
Common actions that the Cortex XDR agent performs include collecting forensic data and notifying the
user about the event.
The default Endpoint Security policy protects the most vulnerable and most commonly used
applications, but you can also add other third-party and proprietary applications to the list of protected
processes.
2.4.2 Define default protected processes
By default, your Exploit Security profile protects endpoints from attack techniques that target specific
processes. Each exploit protection capability protects a different set of processes that Palo Alto Networks
researchers determine are susceptible to attack.
The default Endpoint Security policy protects the most vulnerable and most commonly used
applications, but you can also add other third-party and proprietary applications to the list of protected
processes.
2.4.3 Characterize the differences between application protection and kernel
protection
Application Protection:
Application security is the process of creating, integrating, and testing security features within
applications to protect against threats such as unauthorized access and modification.

Application security is vital because today's applications are frequently available across multiple
networks and linked to the cloud, increasing vulnerabilities to security threats and breaches. There is
increasing pressure and incentive to ensure security not only at the network level, but also within
applications. One reason for this is that hackers are targeting apps with their attacks more frequently
than in the past. Application security testing can reveal application-level flaws, assisting in the prevention
of these attacks.
Kernel Protection:
Application security is typically coded in the application. In kernel security, we are investigating
mechanisms to implement application security in an operating system kernel.
The mechanisms are designed with the goal in mind of providing authorization properties, which drives
the design of permissions and protection mechanisms. The resulting system is dynamic, allowing a
program’s set of permissions to evolve during program execution. Because the protection mechanism
gives the user more freedom in how they do things, it reduces the need for users and applications to be
aware of it.
2.4.4 References
Exploit Protection:
security-concepts/analysis-and-protection-flow
Default Protected Processes:

https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-prevent-admin/endpoint-security/endp
oint-security-profiles/add-exploit-security-profile/processes-protected-by-exploit-security-policy

1. Which of the following is a piece of software or a command that takes advantage of a bug in
order to trigger undesired actions and behaviors?
a. malware
b. Trojan
c. exploit
d. worm
3. Which two types of protection are exploit protection? (Choose two.)

a. ransomware protection
b. reconnaissance protection
c. kernel protection
d. behavioral threat protection

2.5 Outline analytic detection capabilities
2.5.1 Define the purpose of detectors
The analytics engine for Cortex XDR retrieves logs from Cortex Data Lake to understand the normal
behavior (create a baseline) so that it can raise alerts when abnormal activity occurs. This analysis is
highly sophisticated and performed on more than a thousand dimensions of data. Internally, the Cortex
XDR app organizes its analytics activity into algorithms called detectors. Each detector is responsible for
raising an alert when it detects worrisome behavior.
To raise alerts, each detector compares the recent past behavior to the expected baseline by examining
the data found in your logs. A certain amount of log file time is required to establish a baseline, and then
a certain amount of recent log file time is required to identify what is currently happening in your
environment.
There are several meaningful time intervals for Cortex XDR Analytics detectors:
TIME INTERVAL DESCRIPTION

Learning Period The shortest amount of log file time before the app can raise an alert.
This is typically the time from when a detector first starts running and
when you see an alert, but in some cases, detectors pause after an
upgrade as they enter a new learning period.
Most, but not all, detectors will wait until they have a learning period
amount of time before they run. This learning period exists to give the
detector enough data to establish a baseline, which in turn helps to
avoid false positives.
The learning period is also referred to as the profiling or waiting period;
informally, it is also called soak time.
Test Period The amount of logging time that a detector uses to determine whether
unusual activity is occurring on your network. The detector compares
test period data to the baseline created during the training period and
uses that comparison to identify abnormal behavior.
Training Period The amount of logging time that the detector requires to establish a
baseline and identify the behavioral limits beyond which an alert is
raised. Because your network is not static in terms of its topology or
usage, detectors are constantly updating the baselines that they require
for their analytics. For this update process, the training period is how far
back in time the detector goes to update and tune the baseline.
This period is also referred to as the baseline period.
Deduplication Period The amount of time in which additional alerts for the same activity or
behavior are suppressed before Cortex XDR raises another Analytics
alert.
These time periods are different for every Cortex XDR Analytics detector.

2.5.2 Define machine learning in the context of analytic detection
The Cortex XDR app uses an analytics engine to examine logs and data from your sensors. The analytics
engine retrieves logs from Cortex Data Lake to understand the normal behavior (create a baseline) so
that it can raise alerts when abnormal activity occurs. The analytics engine accesses your logs as they are
streamed to Cortex Data Lake and analyzes the data as soon as it arrives. Cortex XDR raises an Analytics
alert when the analytics engine determines an anomaly.
The analytics engine is built to process—in parallel—large amounts of data stored in Cortex Data Lake.
The ultimate goal is to identify normal behavior so the Cortex apps can recognize and use alerts to notify
you of that abnormal behavior. The analytics engine can examine traffic and data from a variety of
sources such as network activity from firewall logs, VPN logs (from Prisma Access from the Panorama
plugin), endpoint activity data (on Windows endpoints), Active Directory, or a combination of those
sources, to identify endpoints and users on your network. After endpoints and users are identified, the
analytics engine collects relevant details about every asset that it sees based on the information it
obtains from the logs. The analytics engine can detect threats from only network data or only endpoint
data, but for more context when investigating an alert, a combination of data sources is recommended.
The list of what the engine looks for is large, varied, and constantly growing, but as a consequence of this
analysis, the analytics engine is able to build profiles about every endpoint and user it knows about.
Profiles allow the engine to put the activity of the endpoint or user in context by comparing it against
similar endpoints or users. The analytics engine creates and maintains a very large number of profile
types, but generally, they can all be placed into three categories:
● Peer Group Profiles—A statistical analysis of an entity or an entity relation that compares
activities from multiple entities in a peer group. For example, a domain might have a
cross-organization popularity profile or per-peer-group popularity profile.
● Temporal Profiles—A statistical analysis of an entity or an entity relation that compares the same
entity to itself over time. For example, a host might have a profile for how many ports it
accessed in the past.
● Entity classification—A model detecting the role of an entity. For example, users can be classified
as service accounts and hosts as domain controllers.
2.5.3 Identify the connection of analytic detection capabilities to MITRE
The analytics engine can alert on any of the following attack tactics as defined by the MITRE ATT&CK®
knowledge base of tactics.

TACTIC DESCRIPTION
After attackers gain a foothold in your network, they can use various
techniques to execute malicious code on a local or remote endpoint. The
Cortex XDR app detects malware and grayware on your network using a
Execution
combination of network activity, Pathfinder data collector of your
unmanaged endpoints, endpoint data from your Cortex XDR agents, and
evaluation of suspicious files using the WildFire® cloud service.
To carry out a malicious action, an attacker can try techniques that
maintain access in a network or on an endpoint. An attacker can initiate
Persistence configuration changes—such as a system restart or failure—that require
the endpoint to restart a remote access tool or open a backdoor that
allows the attacker to regain access on the endpoint.
After an attacker has access to a part of your network, discovery
techniques to explore and identify subnets, and discover servers and the
services that are hosted on those endpoints. The app detects attacks
Discovery
that use this tactic by looking for symptoms in your internal network
traffic such as increased rates of connections, failed connections, and
port scans.
To expand the footprint inside your network, and attacker uses lateral
movement techniques to obtain credentials to gain additional access to
Lateral Movement more data in the network. The analytics engine detects attacks during
this phase by examining administrative operations, file share access, and
user credential usage that is beyond the norm for your network.
The command and control tactic allows an attacker to remotely issue
commands to and endpoint and receive information from it. The
analytics engine identifies intruders using this tactic by looking for
Command and Control
anomalies in outbound connections, DNS lookups, and endpoint
processes with bound ports. The app is looking for unexplained changes
in the periodicity of connections and failed DNS lookups, changes in

random DNS lookups, and other symptoms that suggest an attacker has
gained initial control of a system.
Exfiltration tactics are techniques to receive data from a network, such
as valuable enterprise data. The app seeks to identify it by examining
Exfiltration outbound connections with a focus on the volume of data being
transferred. Increases in this volume are an important symptom of data
exfiltration.
2.5.4 References
Analytics Concepts:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/analytics/analytics-concepts
1. Which MITRE ATT&CK tactic employs techniques for obtaining data from a network, such as
valuable enterprise data?
a. Exfiltration
c. Execution
d. Persistence
2. The analytics engine creates and maintains a very large number of profile types, but they can all
be categorized into how many categories in general?
a. 4
b. 2
c. 3
d. 5

Domain 3 Investigation
3.1 Identify the investigation capabilities of Cortex XDR
3.1.1 Describe how to navigate the console
Cortex XDR uses stitching logic to gather and assign alerts to incidents based on a set of rules that take
into account different alert attributes, such as the SHA-256 of files that are involved and IP addresses.
You can prioritize the incidents displayed in the Incidents Table according to these alert attributes.
To enable you to prioritize incidents that are significant to the needs of your organization, the Incident
Scoring Rules option allows you to set custom rules that highlight the incidents based on:
● A user-defined score
● Selected Cortex XDR alert attributes and assets
When an alert is triggered, Cortex XDR matches the alert with each of the custom incident rules you
created. If the alert matches one or more of the rules, the alert is given the score defined by each rule.
An incident rule can also contain a subrule that allows you to create a rule hierarchy. Where a subrule
exists, if the same alert matches one or more of the subrules, the alert is also given the score defined by
each subrule. By default, a score is applied only to the first alert that matches the defined rule and
subrule.
Within each incident, Cortex XDR aggregates the alert scores and assigns the incident a total score. The
incident score is displayed in the Incidents Table as a filterable field, Score, allowing you to prioritize the
Incident Table according to the incident score. You can also view the score while investigating in the
Incident View.
To create an incident scoring rule:

Step 1: In the Cortex XDR Management Console, navigate to Investigation > Incident Management >
Scoring Rules. The Scoring Rules table displays the rules and, if applicable, the subrules currently in your
Cortex XDR tenant.
Step 2: Select Add Scoring Rule to define the rule criteria.

Step 3: In the Create New Scoring Rule dialog, define the following:
● Rule Name — Enter a unique name for your rule.

● Score — Set a numeric value that is applied to an alert matching the rule criteria.
● Base Rule — Select from the drop-down menu whether to create a top-level rule (Root) or a
subrule.
● Rule Name (ID:#) — By default, rules are defined at root level.
● Comment — Enter an optional comment.
● Mark whether to “Apply score only to first alert of Incident”—By selecting this option, you
choose to apply the score only to the first alert that matches the defined rule. Subsequent alerts
of the same incident will not receive a score from this rule again. By default, a score is applied
only to the first alert that matches the defined rule and subrule.
● Determine which alert attribute you want to use as the rule match criteria. Use the filter at the
top of the table to build your rule criteria.
Step 4: Review the rule criteria and Create the incident rule. You are automatically redirected to the
Scoring Rules table.
Step 5: In the Scoring Rules table, Save your scoring rule.
3.1.2 Identify the remote terminal options

Cortex XDR allows you to remotely connect to a broker VM directly from the Cortex XDR console.
Step 1: In Cortex XDR, select Settings ( ) > Configurations > Broker VM > Broker VMs table.
Step 2: Locate the broker VM you want to connect to, right-click, and select Open Remote Terminal.
Cortex XDR opens a CLI window where you can perform the following commands:
● Logs

Broker VM logs are located in /data/logs/ folder and contain the applet name in file name. For
example, folder /data/logs/<applet-name>, containing container_ctrl_<applet-name>.log
● Ubuntu Commands
Cortex XDR Broker VM supports all Ubuntu commands. For example, telnet 10.0.0.10 80 or ifconfig
-a.
● Sudo Commands
Broker VM supports the commands listed in the following table. All the commands are located in
the /home/admin/sbin folder.
Cortex XDR requires you to use the following values when running commands:
Applet Names
o Agent Proxy—tms_proxy
o Syslog Collector—anubis
o WEC—wec
o Network Mapper—network_mapper
o Pathfinder—odysseus Services
o Upgrade—zenith_upgrade
o Frontend service—webui
o Sync with Cortex XDR—cloud_sync
o Internal messaging service (RabbitMQ)— rabbitmq-server
o Uploads metrics to the Cortex XDR—metrics_uploader
o Prometheus node exporter—node_exporter
o Backend service—backend
The following table displays the available commands in alphabetical order.
COMMAND DESCRIPTION EXAMPLE
> sudo applets_restart
applets_restart Restarts one or more applets.
wec
applets_start Start one or more applets. >sudo applets_start wec
Check the status of one or more > sudo applets_status
applets_status
applets. wec
applets_stop Stop one or more applets. > sudo applets_stop wec
> sudo hostnamectl
Check and update the machine set-hostname
hostnamectl hostname on a Linux operating <new-host-name>
system. Restart machine after running
command.
kill Linux kill command. > sudo kill [some pid]
Invoke a restart of the routing > sudo restart_routes
service after updating your For restart_routes to take
static network route effect, restart the machine and
configuration file, vi broker VM.
restart_routes
/etc/network/routes.
Editing the file triggers an editor
(VI). Enter the parameters in a
new line, save, exit, and execute

the restart_routes command to
apply the updates.
route Modify your IP address routing. /sbin/route
Restarts one or more services. > sudo services_restart
services_restart
OS services are not supported. cloud_sync
> sudo services_start
services_start Start one or more services
cloud_sync
Check the status of one or more > sudo services_status
services_status
services. cloud_sync
> sudo services_restart
services_stop Stop one or more services.
cloud_sync
Changes password of the Broker > sudo
VM Web UI. set_ui_password.sh
set_ui_password.sh Run the command and enter
the new password followed by
Ctrl+D.
Display the Proxy applet Squid sudo squid_tail
squid_tail
log file in real time.
Linux capture network traffic > sudo tcpdump -i eth0
command. -w /tmp/packets.pcap
tcpdump
You must use -w flag in order to
print output to file.
3.1.3 Characterize the differences between incidents and alerts

Incidents:
An attack can affect several hosts or users and raises different alert types stemming from a single event.
All artifacts, assets, and alerts from a threat event are gathered into an incident.
The logic behind which alert the Cortex XDR app assigns to an incident is based on a set of rules that take
into account different attributes. Examples of alert attributes include alert source, type, and time period.
The app extracts a set of artifacts related to the threat event, listed in each alert, and compares them
with the artifacts appearing in existing alerts in the system. Alerts on the same causality chain are
grouped with the same incident if an open incident already exists. Otherwise, the new incoming alert
will create a new incident.
To keep incidents fresh and relevant, Cortex XDR provides thresholds after which an incident stops
adding alerts:
● 30 days after the incident was created
● 14 days since the last alert in the incident was detected (excludes backward scan alerts)
After the incident reaches either threshold, it stops accepting alerts, and Cortex XDR groups subsequent
related alerts in a new incident. You can track the grouping threshold status in the Alerts Grouping Status
field in the Incidents Table:
● Enabled—The incident is open to accepting new related alerts.

● Disabled—Grouping threshold is reached and the incident is closed to further alerts or the
incident has reached the limit of 1,000 alerts. To view the exact reason for a Disabled status,
hover over the status field.
You can select to view the Incidents page in a table format or split-pane mode. Use to toggle
between the views. By default, Cortex XDR displays the split pane mode. Any changes you make to the
incident fields, such as description, resolution status, and filters; sort selections persist when you toggle
between the modes.
The split-pane mode displays a side-by-side view of the your incidents list and the corresponding incident
details.
The table view displays only the incident fields in a table format. Right-click an incident to view the
incident details and investigate the related assets, artifacts, and alerts.
Alerts:
The Alerts page displays a table of all alerts in Cortex XDR.
The Alerts page consolidates non-informational alerts from your detection sources to enable you to
efficiently and effectively triage the events you see each day. By analyzing the alert, you can better
understand the cause of what happened and the full story with context to validate whether an alert
requires additional action. Cortex XDR supports saving 2M alerts per 4,000 agents or 20 terabytes; half of
the alerts are allocated for informational alerts, and half for severity alerts.
To view detailed information for an alert, you can also view details in the Causality View and Timeline
View. From these views, you can also view related informational alerts that are not presented on the
Alerts page.

By default, the Alerts page displays the alerts that it received over the last seven days; to modify the time
period, use the page filters. Every 12 hours, Cortex XDR enforces a cleanup policy to remove the oldest
alerts that exceed the maximum alerts limit.
Cortex XDR processes and displays the names of users in the following standardized format, also termed
“normalized user”:
<company-domain>\<username>
As a result, any alert triggered based on network, authentication, or login events displays the User Name
in the standardized format in the Alerts and Incidents pages. This impacts every alert for Cortex XDR
Analytics and Cortex XDR Analytics BIOC, including Correlation, BIOC, and IOC alerts triggered on one of
these event types.
3.1.4 Characterize the differences between exclusions and exceptions
Exclusions:
The Investigation Incident Management Exclusions page displays all alert exclusion policies in Cortex
XDR.
An alert exclusion is a policy that contains a set of alert match criteria that you want to suppress from
Cortex XDR. You can Add an Alert Exclusion Policy from scratch, or you can base the exclusion on alerts
that you investigate in an incident. After you create an exclusion policy, Cortex XDR hides any future
alerts that match the criteria from incidents and search-query results. If you choose to apply the policy
to historic results as well as future alerts, the app identifies any historic alerts as grayed out.

The following table describes both the default fields and additional optional fields that you can add to
the alert exclusions table; it lists the fields in alphabetical order.
FIELD DESCRIPTION
Check box to select one or more alert exclusions on which you want
to perform actions.
Exclusion policy status for historic data, either enabled if you want
BACKWARD SCAN STATUS to apply the policy to previous alerts or disabled if you don’t want
to apply the policy to previous alerts.
Administrator-provided comment that identifies the purpose or
COMMENT
reason for the exclusion policy.
DESCRIPTION Stop one or more applets.
MODIFICATION DATE Date and time when the exclusion policy was created or modified.
NAME Descriptive name provided to identify the exclusion policy.
POLICY ID Unique ID assigned to the exclusion policy.
STATUS Exclusion policy status, either enabled or disabled.
USER User who last modified the exclusion policy.
USER EMAIL Email associated with the administrative user.
Exceptions:
To allow full granularity, Cortex XDR enables you to create exceptions from your baseline policy. With
these exceptions, you can remove specific folders or paths from exemption or disable specific security
modules.
You can configure the following types of policy exceptions:
EXCEPTION TYPE DESCRIPTION

Process exceptions Define an exception for a specific process for one or more security
modules.
Support exceptions Import an exception from the Cortex XDR Support team.
Behavioral Threat An exception disabling a specific BTP rule across all processes.
Protection Rule Exception
Digital Signer Exception (Windows only) An exception adding a digital signer to the list of allowed
signers.
Java Deserialization (Linux only) An exception allowing a specific Java executable (jar, class).
Exception
Local File Threat (Linux only) An exception allowing specific PHP files.
Examination Exception
There are two types of exceptions you can create:

● Policy exceptions that apply to specific policies and endpoints
● Global exceptions that apply to all policies
3.1.5 References
Open remote terminal:

https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/broker-vm/manage-your-br
oker-vm/open-remote-terminal.html
Incidents:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/investigation-and-response/
investigate-incidents/cortex-xdr-incidents.html
Alerts:
investigate-endpoint-alerts/cortex-xdr-alerts.html
1. Cortex XDR supports saving how many alerts per how many agents?
a. 1M alerts per 4,000 agents
b. 2M alerts per 4,000 agents
c. 1M alerts per 3,000 agents
d. 2M alerts per 3,000 agents
4. Which policy exception is an exception disabling a specific BTP rule across all processes?
a. support exception
b. local file threat examination exception
c. behavioral threat protection rule exception
d. process exception
3.2 Identify the steps of an investigation

3.2.1 Clarify how incidents and alerts interrelate
All artifacts, assets, and alerts from a threat event are gathered into an Incident.
The logic behind which alert the Cortex XDR app assigns to an incident is based on a set of rules which
take into account different attributes. Examples of alert attributes include alert source, type, and time
period. The app extracts a set of artifacts related to the threat event, listed in each alert, and compares it
adding alerts:

After the incident reaches either threshold, it stops accepting alerts and Cortex XDR groups subsequent
related alerts in a new incident. You can track the grouping threshold status in the
Alerts Grouping Status field in the Incidents Table:

● Disabled—Grouping threshold is reached and the incident is closed to further alerts or if the
incident reached the 1,000 alert limit. To view the exact reason for a Disabled status, hover over
the status field.
3.2.2 Identify the order in which to resolve incidents
The incident header allows you to quickly review and update your incident details.
● Change the incident severity.

The default severity is based on the highest alert in the incident. To manually change the severity,
select the severity tag and choose the new severity.
● Add or edit the incident name.
Hover over “Add incident name” and select the pencil icon to add or edit the incident name.
● Update the incident score.
Select the Incident Score to investigate how the Rule based score was calculated.
In the “Manage incident score” dialog, review the Rule ID, Rule Name, Description, Alert IDs, and the
Total Added Score associated with incident. The table displays all rules that contributed to the
incident total score, including rules that have been deleted. Deleted scores appear with N/A.

Override the Rule based score by selecting Set score manually and Apply the change.
● Assign an incident.
Select the assignee (or Unassigned) and begin typing the assignee’s email address for automated
suggestions. Users must have logged in to the app to appear in the autogenerated list.
● Assign an incident status.
Select the incident status to update the status to either New, Under Investigation, or Resolved
to indicate which incidents have been reviewed and to filter by status in the Incidents Table.
When setting an incident to Resolved, select the reason the resolution was resolved.

Incidents have the status set to New when they are generated. To begin investigating an incident, set the
status to Under Investigation. The Resolved status is subdivided into resolution reasons:
● Resolved - Threat Handled
● Resolved - Known Issue
● Resolved - Duplicate Incident
● Resolved - False Positive
● Resolved - Auto Resolve - Auto-resolved by Cortex XDR when all of the alerts contained in an
incident have been excluded.
3.2.3 Identify which steps are valid for an investigation
● Investigate Incidents:
The Incidents page displays all incidents in the Cortex XDR management console to help you
prioritize, track, triage, investigate, and take remedial action.
● Investigate Alerts:
efficiently and effectively triage the events you see each day. By analyzing the alert, you can
better understand the cause of what happened and the full story with context to validate
whether an alert requires additional action. Cortex XDR supports saving 2M alerts per 4,000
agents or 20 terabytes, half of the alerts are allocated for informational alerts, and half for
severity alerts.
● Investigate Endpoints:

The Action Center provides a central location from which you can track the progress of all
investigation, response, and maintenance actions performed on your endpoints protected by
Cortex XDR. The main All Actions tab of the Action Center displays the most recent actions
initiated in your deployment. To narrow down the results, click Filter on the top right.
● Investigate Files:
You can manage file execution on your endpoints by using file hashes that are included in your allow
and block lists. If you trust a certain file and know it to be benign, you can add the file hash to
the allow list and allow it to be executed on all your endpoints regardless of the WildFire or
local-analysis verdict. Similarly, if you want to always block a file from running on any of your
endpoints, you can add the associated hash to the block list.
3.2.4 List the options to highlight or suppress incidents
To help you focus on the incidents that matter most, you can star an incident. Cortex XDR identifies
starred incidents with a purple star. You can star incidents in two ways: You can manually star an incident
after reviewing it, or you can create an incident-starring configuration that automatically categorizes and
stars incidents when a related alert contains the specific attributes that you decide are important.
After you define an incident-starring configuration, Cortex XDR adds a star indicator to any incidents that
contain alerts that match the configuration.
You can then sort or filter the Incidents Table for incidents containing starred alerts and similarly filter
the Alerts Table for starred alerts. In addition, you can also choose whether to display all incidents or
only starred incidents on the Incidents Dashboard.
Star a specific incident

Step 1: Select Investigation > Incidents.
Step 2: From the Incident List, locate the incident you want to star.
Step 3: Select the star icon.
Create a starring configuration

To proactively star alerts and incidents containing alerts, create a starring configuration.
Step 1: Select Investigation > Incident Management > Starred Alerts.
Step 2: + Add Starring Configuration.
Step 3: Enter a Configuration Name to identify your starring configuration.

Step 4: Enter a descriptive Comment that identifies the reason or purpose of the starring configuration.
Step 5: Use the alert filters to build the match criteria for the policy.
You can also right-click a specific value in the alert to add it as a match criterion. The app refreshes to
show you which alerts in the incident would be included.
Step 6: Create the policy and confirm the action.

If you later need to make changes, you can view, modify, or delete the exclusion policy from the
Investigation > Incident Management > Starred Alerts page.
3.2.5 References
Investigate Incidents:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-prevent-admin/investigation-and-respo
nse/investigate-incidents.html#idbe8c1797-22f5-4aaa-b593-f254022ff104
Scripts:
response-actions/run-python-scripts
1. The Action Center can be found on which tab?
a. Reporting
b. Investigation
c. Response
d. Endpoints

5. What threshold does Cortex XDR use to keep incidents fresh and relevant?
a. 20 days after the incident was created and 14 days since the last alert in the incident was
detected
b. 30 days after the incident was created and 10 days since the last alert in the incident was
detected
c. 20 days after the incident was created and 10 days since the last alert in the incident was
detected
d. 30 days after the incident was created and 14 days since the last alert in the incident was
detected
3.3 Identify actions to investigate incidents

3.3.1 Describe when to perform actions using the Live Terminal
To investigate and respond to security events on endpoints, you can use the Live Terminal to initiate a
remote connection to an endpoint. The Cortex XDR agent facilitates the connection using a remote
procedure call. Live Terminal enables you to manage remote endpoints. Investigative and response
actions that you can perform include navigating and managing files in the file system, managing active
processes, and running the operating system or Python commands.
If the endpoint supports the necessary requirements, you can initiate a Live Terminal session from the
Endpoints page. You can also initiate Live Terminal as a response action from a security event. If the
endpoint is inactive or does not meet the requirements, the option is disabled.
After you terminate the Live Terminal session, you also have the option to save a log of the session
activity. All logged actions from the Live Terminal session are available for download as a text file report
when you close the live terminal session.
You can fine-tune the Live Terminal session visibility on the endpoint by adjusting the User Interface
options in your Agent Settings profile.
Step 1: Start the session.

From a security event or endpoint details, select Response > Live Terminal. The Cortex XDR agent may
take a few minutes to facilitate the connection.
Step 2: Use the Live Terminal to investigate and take action on the endpoint.
● Manage processes
● Manage files
● Run operating system commands
● Run Python commands and scripts
Step 3: When you are done, Disconnect the Live Terminal session.
You can optionally save a session report containing all activity you performed during the session.
The following example displays a sample session report:

Live Terminal Session Summary
Initiated by user username@paloaltonetworks.com on target TrapsClient1 at Jun 27th 2019
14:17:45
Jun 27th 2019 13:56:13 Live Terminal session has started [success]
Jun 27th 2019 14:00:45 Kill process calc.exe (4920) [success]
Jun 27th 2019 14:11:46 Live Terminal session end request [success]
Jun 27th 2019 14:11:47 Live Terminal session has ended [success]
No artifacts marked as interesting
3.3.2 Describe what actions can be performed using the Live Terminal
Manage Processes:
From the Live Terminal, you can monitor processes running on the endpoint. The Task Manager displays
the task attributes, owner, and resources used. If you discover an anomalous process while investigating
the cause of a security event, you can take immediate action to terminate the process or the whole
process tree and block processes from running.
● Step 1: From the Live Terminal session, open the Task Manager to navigate the active processes
on the endpoint.
You can toggle between a sorted list of processes and the default process tree view ( ). You can
also export the list of processes and process details to a comma-separated values (CSV) file.
If the process is known malware, the row displays a red indicator and identifies the file using a
malware attribute.
● Step 2: To take action on a process, right-click the process and select the action:
o Terminate process—Terminate the process or entire process tree.
o Suspend process—To stop an attack while investigating the cause, you can suspend a
process or process tree without killing it entirely.
o Resume process—Resume a suspended process.
o Open in VirusTotal—VirusTotal aggregates known malware from antivirus products and
online scan engines. You can scan a file using the VirusTotal scan service to check for
false positives or verify suspected malware.
o Get WildFire verdict—WildFire evaluates the file hash signature to compare it against
known threats.
o Get file hash—Obtain the SHA-256 hash value of the process.
o Download Binary—Download the file binary to your local host for further investigation
and analysis. You can download files up to 200MB in size.
o Mark as Interesting—Add an Interesting tag to a process to easily locate the process in
the session report after you end the session.
o Remove from Interesting—If no threats are found, you can remove the Interesting tag.
o Copy Value—Copy the cell value to your clipboard.
● Step 3: Select Disconnect to end the Live Terminal session.

Choose whether to save the remote session report including files and tasks marked as interesting.
Administrator actions are not saved to the endpoint.
Manage Files:
The File Explorer enables you to navigate the file system on the remote endpoint and take remedial
action to:
● Create, manage (move or delete), and download files, folders, and drives, including connected
external drives and devices such as USB drives and CD-ROM.
● View file attributes, creation and last-modified dates, and the file owner.
● Investigate files for malicious content.
To navigate and manage files on a remote endpoint:

● Step 1: From the Live Terminal session, open the File Explorer to navigate the file system on the
endpoint.
● Step 2: Navigate the file directory on the endpoint and manage files.
To locate a specific file, you can:
o Search for any filename rows on the screen from the search bar.
o Double-click a folder to explore its contents.
● Step 3: Perform basic management actions on a file.
o View file attributes.
o Rename files and folders.
o Export the table as a CSV file.
o Move and delete files and folders.
● Step 4: Investigate files for malware.
Right-click a file to take investigative action. You can take the following actions:
o Open in VirusTotal—VirusTotal aggregates known malware from antivirus products and
online scan engines. You can scan a file using the VirusTotal scan service to check for
false positives or verify suspected malware.
o Get WildFire verdict—WildFire evaluates the file hash signature to compare it against
known threats.
o Get file hash—Obtain the SHA-256 hash value of the file.
o Download Binary—Download the file binary to your local host for further investigation
and analysis. You can download files up to 200MB in size.
o Mark as Interesting—Add an Interesting tag to any file or directory to easily locate the
file. The files you tag are recorded in the session report to help you locate them after
you end the session.
o Remove from Interesting—If no threats are found, you can remove the Interesting tag.
o Copy Value—Copies the cell value to your clipboard.
● Step 5: Select Disconnect to end the Live Terminal session.

Choose whether to save the Live Terminal session report, including files and tasks marked as
interesting. Administrator actions are not saved to the endpoint.
Run Operating-System Commands:

The Live Terminal provides a command-line interface from which you can run operating-system
commands on a remote endpoint. Each command runs independently and is not persistent. To chain

multiple commands together so as to perform them in one action, use && to join commands. For
example:
cd c:\windows\temp\ && <command1> && <command2>
● Step 1: From the Live Terminal session, select Command Line.
● Step 2: Run commands to manage the endpoint.

Examples include file management or launching batch files. You can enter or paste the commands, or
you can upload a script. After you are done, you can save the command session output to a file.
● Step 3: When you are done, Disconnect the Live Terminal session.
Run Python Commands and Scripts:

The Live Terminal provides a Python command-line interface that you can use to run Python commands
and scripts.
The Python command interpreter uses Unix command syntax and supports Python 3 with standard
Python libraries. To issue Python commands or scripts on the endpoint, follow these steps:
● Step 1: From the Live Terminal session, select Python to start the Python command interpreter
on the remote endpoint.
● Step 2: Run Python commands or scripts as desired.
You can enter or paste the commands, or you can upload a script. After you are done, you can save
the command session output to a file.

● Step 3: When you are done, Disconnect the Live Terminal session.
3.3.3 Describe when to perform actions using a script
For enhanced endpoint remediation and endpoint management, you can run Python 3.7 scripts on your
endpoints directly from Cortex XDR. For commonly used actions, Cortex XDR provides precanned scripts
you can use out of the box. You can also write and upload your own Python scripts and code snippets
into Cortex XDR for custom actions. Cortex XDR enables you to manage, run, and track the script
execution on the endpoints, as well as store and display the execution results per endpoint.
The following are prerequisites to executing scripts on your endpoints:

● Cortex XDR Pro per Endpoint license
● Endpoints running the Cortex XDR agent 7.1 or later releases. Since the agent uses its built-in
capabilities and many available Python modules to execute the scripts, no additional setup is
required on the endpoint.
● A role in the hub with the following permissions to run and configure scripts:
o Run standard scripts
o Run high-risk scripts
o Script configuration (required to upload a new script, run a snippet, and edit an existing
script)
o Scripts (required to view the Scripts Library and the script execution results)
Use the following workflow to start running scripts on your endpoints:
● manage all scripts in the scripts library

● upload your scripts
● run a script on your endpoints
● track script execution and view results
● troubleshoot script execution
● disable script execution
3.3.4 Identify common investigation screens and processes
● Investigate Incidents:
The Incidents page displays all incidents in the Cortex XDR management console to help you
prioritize, track, triage, investigate, and take remedial action.

● Investigate Alerts:
efficiently and effectively triage the events you see each day. By analyzing the alert, you can
better understand the cause of what happened and the full story with context to validate
whether an alert requires additional action. Cortex XDR supports saving 2M alerts per 4000
agents or 20 terabytes, half of the alerts are allocated for informational alerts, and half for
severity alerts.
● Investigate Endpoints:
The Action Center provides a central location from which you can track the progress of all
investigation, response, and maintenance actions performed on your endpoints protected by
Cortex XDR. The main All Actions tab of the Action Center displays the most recent actions
initiated in your deployment. To narrow down the results, click Filter on the top right.

● Investigate Files:
You can manage file execution on your endpoints by using file hashes that are included in your allow
and block lists. If you trust a certain file and know it to be benign, you can add the file hash to
the allow list and allow it to be executed on all your endpoints regardless of the WildFire or local
analysis verdict. Similarly, if you want to always block a file from running on any of your
endpoints, you can add the associated hash to the block list.
3.3.5 References
Live Terminal:
response-actions/initiate-a-live-terminal-session
Investigation:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/investigation-and-response

1. Which statement about precanned scripts is incorrect?
a. You can view the script.

b. You can download the script code and metadata.
c. You can duplicate the script.
d. You can edit the code or definitions of precanned scripts.
2. What is the path to access Live Terminal?

a. Response > Live Terminal
b. Reporting > Live Terminal
c. Investigation > Live Terminal
d. Endpoints > Live Terminal
3.4 Outline incident collaboration and management using XDR

3.4.1 Outline read and write attributes
From the Query Builder, you can investigate connections between file activity and endpoints. The Query
Builder searches your logs and endpoint data for the file activity that you specify. To search for files on
endpoints instead of file-related activity, use the XQL Search.
Some examples of file queries you can run include:

● Files modified on specific endpoints
● Files related to process activity that exist on specific endpoints
To build a file query:
Step 1: From Cortex XDR, select Investigation > Query Builder.

Step 2: Select FILE.
Step 3: Enter the search criteria for the file events query.
● File activity—Select the type or types of file activity you want to search: All, Create, Read,
Rename, Delete, or Write.
● File attributes—Define any additional process attributes for which you want to search. Use a
pipe (|) to separate multiple values (for example, notepad.exe|chrome.exe). By default, Cortex
XDR will return the events that match the attribute you specify. To exclude an attribute value,
toggle the = option to =! . Attributes are:
o NAME—File name
o PATH—Path of the file
o PREVIOUS NAME—Previous name of a file
o PREVIOUS PATH—Previous path of the file
o MD5—MD5 hash value of the file
o SHA256—SHA256 hash value of the file
o DEVICE TYPE—Type of device used to run the file: Unknown, Fixed, Removable Media,
CD-ROM
o DEVICE SERIAL NUMBER—Serial number of the device type used to run the file
To specify an additional exception (match this value except), click the + to the right of the value and
specify the exception value.
Step 4: (Optional) Limit the scope to a specific acting process:
Select and specify one or more of the attributes for the acting (parent) process.
Step 5: (Optional) Limit the scope to an endpoint or endpoint attributes:
Select and specify one or more of the attributes.
Step 6: Specify the time period for which you want to search for events.
Options are: Last 24H (hours), Last 7D (days), Last 1M (month), or a Custom time period.
Step 7: Choose when to run the query.
Select the calendar icon to schedule a query to run on or before a specific date, Run in background to
run the query as resources are available, or Run to run the query immediately and view the results in the
Query Center.

3.4.2 Characterize the difference between incidents and alerts
Incidents:
All artifacts, assets, and alerts from a threat event are gathered into an Incident.
The logic behind which alert the Cortex XDR app assigns to an incident is based on a set of rules which
take into account different attributes. Examples of alert attributes include alert source, type, and time
period. The app extracts a set of artifacts related to the threat event, listed in each alert, and compares it
adding alerts:
After the incident reaches either threshold, it stops accepting alerts and Cortex XDR groups subsequent
related alerts in a new incident. You can track the grouping threshold status in the
Alerts Grouping Status field in the Incidents Table:

● Disabled—Grouping threshold is reached and the incident is closed to further alerts or if the
incident reached the 1,000 alert limit. To view the exact reason for a Disabled status, hover over
the status field.
You can select to view the Incidents page in a table format or split pane mode. Use to toggle between
the views. By default, Cortex XDR displays the split pane mode. Any changes you make to the incident
fields, such as description, resolution status, filters, and sort selections persist when you toggle between
the modes.
The split pane mode displays a side-by-side view of the your incidents list and the corresponding incident
details.
The table view displays only the incident fields in a table format. Right-click an incident to view the
incident details, and investigate the related assets, artifacts, and alerts.

Alerts:
efficiently and effectively triage the events you see each day. By analyzing the alert, you can better
understand the cause of what happened and the full story with context to validate whether an alert
requires additional action. Cortex XDR supports saving 2M alerts per 4000 agents or 20 terabytes, half of
the alerts are allocated for informational alerts, and half for severity alerts.
To view detailed information for an alert, you can also view details in the Causality View and Timeline
View. From these views, you can also view related informational alerts that are not presented on the
Alerts page.
By default, the Alerts page displays the alerts that it received over the last seven days (to modify the
time period, use the page filters). Every 12 hours, Cortex XDR enforces a cleanup policy to remove the
oldest alerts that exceed the maximum alerts limit.
Cortex XDR processes and displays the name of users in the following standardized format, also termed
“normalized user”.
<company domain>\<username>

As a result, any alert triggered based on network, authentication, or login events, displays the User
Name in the standardized format in the Alerts and Incidents pages. This impacts every alert for Cortex
XDR Analytics and Cortex XDR Analytics BIOC, including Correlation, BIOC and IOC alerts triggered on one
of these event types.
3.4.3 References
File Query:
search-queries/query-builder/create-a-file-query.html
Incidents:
investigate-incidents/cortex-xdr-incidents.html
Alerts:
investigate-endpoint-alerts/cortex-xdr-alerts.html
1. How many Cortex XDR rules are there?
a. 3
b. 4
c. 2
d. 5
2. What is the expiration limit set by Cortex XDR by default for agent upgradation and agent
uninstall?
a. 90 days
b. 60 days
c. 40 days
d. 30 days

Domain 4 Remediation
4.1 Describe basic remediation
4.1.1 Describe how to navigate the remediation suggestions
When investigating suspicious incidents and causality chains, you often need to restore and revert
changes made to your endpoints as result of a malicious activity. To avoid manually searching for the
affected files and registry keys on your endpoints, you can ask Cortex XDR for remediation suggestions.
Cortex XDR investigates suspicious causality process chains and incidents on your endpoints and displays
a list of suggested actions to remediate processes, files, and registry keys on your endpoint.
To initiate remediation suggestions, you must meet the following requirements:

● Cortex XDR Pro per Endpoint license
● App Administrator, Privileged Responder, or Privileged Security Admin role permissions, which
include the remediation permissions
● EDR data collection enabled
● Cortex XDR agent version 7.2 or later on Windows endpoints
Steps to navigate remediation suggestions:

Step 1: Initiate a remediation analysis.
You can initiate a remediation suggestions analysis from either of the following places:
● In the Incident View, navigate to Actions > Remediation Suggestions.
● Endpoints that are part of the incident view and do not meet the required criteria are excluded
from the remediation analysis.
● In the Causality View, do one of the following:
o Right-click any process node involved in the causality chain and select Remediation
Suggestion.
o Navigate to Actions > Remediation Suggestions.
Analysis can take a few minutes. If desired, you can minimize the analysis pop-up while navigating to
other Cortex XDR pages.
Step 2: Review the remediation suggestion summary and details.
FIELD DESCRIPTION

ORIGINAL EVENT Summary of the initial event that triggered the malicious causality chain
DESCRIPTION
ORIGINAL EVENT Timestamp of the initial event that triggered the malicious causality
TIMESTAMP chain
ENDPOINT NAME Hostname of the endpoint
IP ADDRESS The IP address associated with the endpoint
ENDPOINT STATUS Connectivity status of the endpoint. Can be either:
● Connected
● Disconnected
● Uninstalled
● Connection lost
DOMAIN Domain or workgroup to which the endpoint belongs, if applicable

ENDPOINT ID Unique ID assigned by Cortex XDR that identifies the endpoint
SUGGESTED Action suggested by the Cortex XDR remediation scan to apply to
REMEDIATION causality chain process:
● Delete File
● Restore File
● Rename File
● Delete Registry Value
● Restore Registry Value
Terminate Process—Available when selecting Remediation Suggestions

for a node in the Causality View
Terminate Causality—Terminate the entire causality chain of processes
that have been executed under the process tree of the listed Causality
Group Owner (GCO) process name
Manual Remediation—Requires you to take manual action to revert or
restore
SUGGESTED Summary of the remediation suggestion to apply to the file or registry
REMEDIATION
DESCRIPTION
REMEDIATION STATUS Status of the applied remediation:
● Pending
● In Progress
● Failed
● Completed Successfully
● Partial Success
REMEDIATION DATE Displays the timestamp of when all of the endpoint artifacts were
remediated. If missing a successful remediation, field will not display
timestamp.

Step 3: Select one or more Original Event Descriptions and right-click to Remediate.
Step 4: Track your remediation process.

● Navigate to Response > Action Center > All Actions.
● In the Action Type field, locate your remediation process.
● Right-click Additional data to open the Detailed Results window.
4.1.2 Distinguish between automatic vs. manual remediations
When investigating suspicious incidents and causality chains, you often need to restore and revert
changes made to your endpoints as result of a malicious activity. To avoid manually searching for the
affected files and registry keys on your endpoints, you can request Cortex XDR for remediation
suggestions.
Automatic remediation—Cortex XDR investigates suspicious causality process chains and incidents on
your endpoints and displays a list of suggested actions to remediate processes, files, and registry keys on
your endpoint. You can request Cortex XDR for remediation suggestions.
Manual remediation—Requires you to take manual action to revert or restore.
4.1.3 Summarize how/when to run a script

Run a script on your endpoints:
Follow this high-level workflow to run scripts on your endpoints that perform actions or retrieve files and
data from the endpoint back to Cortex XDR.
Step 1: Initiate a new action to run a script.

From Action Center > +New Action, select Run Script.
Step 2: Select an existing script or add a code snippet.

● To run an existing script, start typing the script name or description in the search field, or scroll
down and select it from the list. Set the script timeout in seconds and any other script
parameters, if they exist. Click Next.
● Alternatively, you can insert a code snippet. Unlike scripts, snippets are not saved in the Cortex
XDR Scripts Library and cannot receive input or output definitions. Write your snippet in the
editor, fill in the timeout in seconds, and click Next.
Step 3: Select the target endpoints.

Select the target endpoints on which to execute the script. When you’re done, click Next.
Step 4: Review the summary and run script.
Cortex XDR displays the summary of the script execution action. If all the details are correct, Run the
script and proceed to Track Script Execution and View Results. Alternatively, to track the script-execution
progress on all endpoints and view the results in real time, Run in interactive mode.

Run scripts in interactive mode:
When you need to run several scripts on the same target scope of endpoints, or when you want to view
and inspect the results of those scripts immediately and interactively, you can run your scripts in
Interactive Mode. You can also initiate interactive mode for an endpoint directly from Endpoints
Management. In this mode, Cortex XDR enables you to track the execution progress on all endpoints in
real time, run more scripts or code snippets as you go, and view the results of these scripts all in one
place.
In Interactive Mode, Cortex XDR displays general information that includes the scope of target endpoints
and a list of all the scripts that are being executed in this session. For each script on the executed scripts
list, you can view the following:
● The script name and date, the time the script execution action was initiated, and a list of input
parameters.
● A progress bar that indicates in real time the number of endpoints for which the script execution
is In Progress, Failed, or Completed. When you hover over the progress bar, you can drill down
for more information about the different sub-statuses included in each group. Similarly, you can
also view this information on the scripts list to the left in the form of a pie chart that is
dynamically updated for each script as it is being executed.
● Dynamic script results that are continuously updated throughout the script-execution process.
Cortex XDR lists the results and, if they have a small variety of values, graphically aggregates
results. When both views are available, you can switch between them.

While in Interactive Mode, you can continuously execute more scripts and add code snippets that will be
immediately executed on the target endpoints scope. Cortex XDR logs all the scripts and code snippets
you execute in Interactive Mode, and you can later view them in the Action Center.
4.1.4 Describe how to fix false positives
False positive—An event that produces an alarm when no attack has taken place. For example, you
might investigate a brute-force alert and find out that it was just some user who mistyped their
password multiple times, not a real attack.
Prevention:
● Firstly, prevent false positives from being added to your data.
● Next, notify analysts about the likelihood of false positives.
● Report sightings, whether as observations or as an indication of a false positive.
● Inform analysts about these sightings.
● Disable the indicator from being actionable and included in your cyberthreat intel.
4.1.5 References
Remediation suggestion:
response-actions/remediate-endpoints
Run Scripts on an Endpoint:

response-actions/run-python-scripts
1. Which of the following is not a requirement for initiating remediation suggestions?
a. Cortex XDR Pro per Endpoint license
b. EDR data collection enabled
c. Cortex XDR agent version 7.0 or later on Windows endpoints
d. App Administrator, Privileged Responder, or Privileged Security Admin role permissions
2. Which of the following is a summary of the remediation suggestions to apply to the file or
registry?
a. Suggested remediation
b. Original event description
c. Suggested remediation description
d. Remediation status

4.2 Define examples of remediation
4.2.1 Define ransomware
Ransomware is a family of malware that attempts to encrypt files on end-user computers and then
demands some form of e-payment to recover the encrypted files. Ransomware is one of the more
common threats in the modern threat landscape.
Ransomware is delivered to targets primarily through these avenues:

● Phishing emails may contain malicious attachments. These attachments are not always delivered
in executable form; as security vendors and security best practices dictate that receiving
executables via email is, in general, something we want to prevent.
● Exploit kits (such as Angler, or Neutrino) have been known to deliver ransomware to users by
exploiting vulnerable web servers and hosting malicious web scripts on them which exploit
visitors when certain criteria are met, and then delivering a malicious payload.
● Targeted ransomware has been noted and tracked recently, in which organizations had external
facing web servers compromised by malicious actors to gain a foothold, who proceeded to map
the environment out.
4.2.2 Define registry
This preset offers fields related to registry write, rename, and delete.
The xdr_registry preset has the following fields:
FIELD NAME DESCRIPTION

(DATATYPE)
action_registry_data None Available
(string)
action_registry_key_name None Available
(string)
action_registry_old_key_n None Available
ame
(string)
action_registry_value_na None Available
me
(string)
actor_effective_username
Name assigned to 'actor_effective_user_sid' Win: Including domain
(string)
actor_process_command_ None Available
line
(string)
actor_process_image_md None Available
5
(string)
actor_process_image_na None Available
me

(string)
actor_process_image_pat None Available
h
(string)
actor_process_image_sha
256 None Available
(string)
actor_process_os_pid None Available
(integer)
actor_process_signature_ None Available
status
(integer)
actor_process_signature_ None Available
vendor
(string)
agent_hostname Hostname of the agent
(string)
agent_install_type None Available
(integer)
agent_ip_addresses All IPv4 interface addresses
(string)
agent_os_type None Available
(integer)
causality_actor_process_c None Available
ommand_line
(string)
causality_actor_process_i None Available
mage_md5
(string)
mage_name
(string)
mage_path
(string)
mage_sha256
(string)
causality_actor_process_o None Available
s_pid
(integer)
causality_actor_process_s None Available
ignature_status
(integer)

causality_actor_process_s None Available
ignature_vendor
(string)
causality_actor_type None Available
(integer)
mac None Available
(string)
os_actor_process_comma None Available
nd_line
(string)
os_actor_process_image_ None Available
name
(string)
os_actor_process_image_ None Available
path
(string)
os_actor_process_os_pid None Available
(integer)
os_actor_process_signatu None Available
re_status
(integer)
4.2.3 Define file changes/deletions
When you know a file is malicious, you can destroy all its instances on your endpoints directly from
Cortex XDR. You can destroy a file immediately from the file search action result or initiate a new action
from the Action Center. When you destroy a file, the Cortex XDR agent deletes all the file instances on
the endpoint.
Step 1: From the Action Center, select +New Action > Destroy File.
Step 2: To destroy by hash, provide the SHA-256 of the file. To destroy by path, specify the exact file path
and file name. Click Next.

Select the target endpoints from which you want to remove the file. Cortex XDR displays only endpoints
eligible for file destroy. When you’re done, click Next.
Step 4: Review the summary and initiate the action.

Cortex XDR displays the summary of the file destroy action. If you need to change your settings, go Back.
If all the details are correct, click Run. The file destroy action is added to the Action Center.
4.2.4 References
Registry:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-xql-schema-reference/presets/registry-
preset-reference

Ransomware:
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClTLCA0Custom
https://www.paloaltonetworks.com/cyberpedia/ransomware-prevention-what-your-security-architectur
e-must-do

1. What is ransomware?
a. computer equipment that criminals steal from you and won’t return until you pay them
b. software that infects computer networks and mobile devices to hold your data hostage until
you send the attackers money
c. software used to protect your computer or mobile device from harmful viruses
d. a form of cryptocurrency
2. What can you do to significantly decrease the chances of putting your organization at risk of a
ransomware attack?
a. Verify links in email, except know contacts.
b. Purchase only software, programs, and applications from reputable companies.
c. Implement email protection and web gateway solution.
d. All of the above
e. None of the above
4.3 Define configuration options in XDR to fix problems

4.3.1 Define block list
A block list contains view files that are permitted and blocked from running on your endpoints regardless
of file verdict.
4.3.2 Define signers
Palo Alto Networks regularly reviews and makes changes to the list of trusted signers and makes the list
available with the default Security policy. Any updates to the list of trusted signers are made available
with content updates that you can obtain from the Support portal (for more information, see Content
Updates). You can also define your own trusted signers from the ESM Console. For Windows signers,
adding a trusted signer adds the signer to the list of highly trusted signers.
4.3.3 Define allow list
An allow list contains view files that are permitted and blocked from running on your endpoints
regardless of file verdict.

4.3.4 Define exceptions
To allow full granularity, Cortex XDR enables you to create exceptions from your baseline policy. With
these exceptions, you can remove specific folders or paths from exemption or disable specific security
modules.
You can configure the following types of policy exceptions:
EXCEPTION TYPE DESCRIPTION

Process Exceptions Define an exception for a specific process for one or more security
modules.
Support Exceptions Import an exception from the Cortex XDR Support team.
Behavioral Threat An exception disabling a specific BTP rule across all processes
Protection Rule Exception
Digital Signer Exception (Windows only) An exception adding a digital signer to the list of allowed
signers
Java Deserialization (Linux only) An exception allowing specific Java executable (jar, class)
Exception
Local File Threat (Linux only) An exception allowing specific PHP files
Examination Exception
There are two types of exceptions you can create:

● Policy exceptions that apply to specific policies and endpoints
● Global exceptions that apply to all policies
4.3.5 Define quarantine/isolation
When the Cortex XDR agent detects malware on a Windows endpoint, you can take additional
precautions to quarantine the file. When the Cortex XDR agent quarantines malware, it moves the file
from the location on a local or removable drive to a local quarantine folder where it isolates the file. This
prevents the file from attempting to run again from the same path or causing any harm to your
endpoints.
To evaluate whether an executable file is malicious, the Cortex XDR agent calculates a verdict using
information from the following sources in order of priority:
● Hash exception policy
● WildFire threat intelligence
● Local analysis
Quarantining a file in Cortex XDR can be done in one of two ways:

● You can enable the Cortex XDR agent to automatically quarantine malicious executables by
configuring quarantine settings in the Malware Security profile.
● You can quarantine a specific file from the causality card.

When you isolate an endpoint, you halt all network access on the endpoint except for traffic to Cortex
XDR. This can prevent a compromised endpoint from communicating with other endpoints, thereby
reducing an attacker’s mobility on your network. After the Cortex XDR agent receives the instruction to
isolate the endpoint and carries out the action, the Cortex XDR console shows an isolated check-in
status. To ensure that an endpoint remains in isolation, agent upgrades are not available for isolated
endpoints.
4.3.6 Define file search and destroy

Search a file:
You can search for files on the endpoint by file hash or file path. The search returns all instances of this
file on the endpoint. You can then immediately proceed to destroy all the file instances on the endpoint
or upload the file to Cortex XDR for further investigation.
You can search for a file using the Query Builder or XQL Search or use the Action Center wizard as
described in the following workflow:
Step 1: From the Action Center, select +New Action > File Search.
Step 2: Configure the search method:

● To search by hash, enter the file SHA-256 value. When you search by hash, you can also search
for deleted instances of this file on the endpoint.

● To search by path, enter the specific path for the file on the endpoint, or specify the path using
wildcards. When you provide a partial path or partial file name using *, the search will return all
the results that match the partial expression. Note the following limitations:
o The file path must begin with a drive name—for example, c:\
o You must specify the exact path folder hierarchy—for example, c:\users\user\file.exe.
You must specify the exact path folder hierarchy also when you replace folder names
with wildcards, by using a wildcard for each folder in the hierarchy. For example,
c:\*\*\file.exe
● Click Next.

Select the target endpoints on which you want to search for the file. Cortex XDR displays only endpoints
eligible for file search. When you’re done, click Next.
Step 4: Review the summary and initiate the search.

Cortex XDR displays the summary of the file search action. If you need to change your settings, go Back.
If all the details are correct, click Run. The file search action is added to the Action Center.
Step 5: Review the search results.

In the Action Center, you can monitor the action progress in real time and view the search results for all
target endpoints. For a detailed view of the results, right-click the action and select Additional data.
Cortex XDR displays the search criteria, timestamp, and real-time status of the action on the target
endpoints. You can:
● View results by file (default view)
● View the results by endpoint
If not all endpoints in the query scope are connected or the search has not completed, the search action
remains in Pending status in the Action Center.
Destroy a File:
When you know a file is malicious, you can destroy all its instances on your endpoints directly from
Cortex XDR. You can destroy a file immediately from the file search action result or initiate a new action
from the Action Center. When you destroy a file, the Cortex XDR agent deletes all the file instances on
the endpoint.

Step 1: From the Action Center, select +New Action > Destroy File.
Step 2: To destroy by hash, provide the SHA25 of the file. To destroy by path, specify the exact file path
and file name. Click Next.

Select the target endpoints from which you want to remove the file. Cortex XDR displays only endpoints
eligible for file destroy. When you’re done, click Next.
Step 4: Review the summary and initiate the action.

Cortex XDR displays the summary of the file destroy action. If you need to change your settings, go Back.
If all the details are correct, click Run. The File destroy action is added to the Action Center.
4.3.7 References
Exceptions:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/endpoint-security/exception
s-security-profiles
file search and destroy:

response-actions/search-file-and-destroy

1. Which policy exception allows specific PHP files?
a. support exception
b. local file threat examination exception
c. behavioral threat protection rule exception
d. process exception
2. In Cortex XDR, how many different methods can you use to search a file?
a. 2
b. 4
c. 3
d. 5

Domain 5 Threat Hunting
5.1 Outline the tools for threat hunting
5.1.1 Explain the purpose and use of the IOC technique
Indicators of compromise (IOCs) are the artifacts that are considered malicious or suspicious. IOCs are
static and based on criteria such as:
● Full path
● File name
● Domain
● Destination IP address
● MD5 hash
● SHA-256
IOCs provide the ability to alert on known malicious objects on endpoints across the organization.
The app checks for matches in the endpoint data obtained from Cortex XDR agents when you define or
load IOCs. There are checks that are both retroactive and ongoing. The app searches all previous data for
IOC matches and continues to evaluate any new data it receives in the future.
You can view all indicators of compromise (IOCs) configured from or uploaded to the Cortex XDR app
from the Rules > IOC tab.
To filter the number of IOC rules you see, you can filter by one or more fields in the IOC Rules table. From
the IOC page, you can also manage or clone existing rules.
The following table describes the fields that are available for each IOC rule in alphabetical order.
FIELD DESCRIPTION

# OF HITS The number of hits (matches) on this indicator
CLASS The IOC's class. For example, “Malware”.
COMMENT Free-form comments specified when the IOC was created or modified
EXPIRATION DATE The date and time at which the IOC will be removed automatically.
INDICATOR The indicator value itself. For example, if the indicator type is a destination
IP address, this could be an IP address such as 1.1.1.1.
INSERTION DATE Date and time when the IOC was created
MODIFICATION DATE Date and time when the IOC was last modified
RELIABILITY Indicator's reliability level:
● A - Completely Reliable
● B - Usually Reliable
● C - Fairly Reliable
● D - Not Usually Reliable
● E - Unreliable
RELIABILITY Indicator's reputation level. One of Unknown, Good, Bad, or Suspicious.

RULE ID Unique identification number for the rule
SEVERITY IOC severity that was defined when the IOC was created
SOURCE User who created this IOC, or the file name from which it was created, or
one of the following keywords:
● Public API—The indicator was uploaded using the Insert Simple
Indicators, CSV or Insert Simple Indicators, JSON REST APIs.
● XSOAR TIM—The indicator was retrieved from XSOAR.
STATUS Rule status: Enabled or Disabled

Type of indicator: Full path, File name, Host name, Destination IP, MD5
TYPE
hash.
VENDORS A list of threat intelligence vendors from which this IOC was obtained
There are two options for creating new indicator of compromise (IOC) rules:
● Configure a single IOC.
● Upload a file, one IOC per line, that contains up to 20,000 IOCs. For example, you can upload
multiple file paths and MD5 hashes for an IOC rule. To help you format the upload file in the
syntax that Cortex XDR will accept, you can download the example file.
If you have a Cortex XDR Pro per Endpoint license, you can upload IOCs using REST APIs in
either CSV or JSON format.
To ensure that your IOC rules raise alerts efficiently and do not overcrowd your Alerts Table, Cortex XDR
automatically:
● Disables any IOC rules that reach 5,000 or more hits over a 24-hour period
● Creates a Rule Exception based on the PROCESS SHA256 field for IOC rules that hit more than
100 endpoints over a 72-hour period.
Steps to create IOC rules

Step 1: From Cortex XDR, select Rules > IOC

Step 2: Select + Add IOC
Step 3: Configure the IOC criteria.
If, after investigating a threat, you identify a malicious artifact, you can create an alert for the single IOC
right away.
If you want to match on multiple indicators, you can upload the criteria in a CSV file.
Step 4: Define any expiration criteria for your IOC rules.
5.1.2 Explain the purpose and use of the BIOC technique
Behavioral indicators of compromise (BIOCs) enable you to alert and respond to behaviors—tactics,
techniques, and procedures. Instead of hashes and other traditional indicators of compromise, BIOC
rules detect behavior related to processes, registry, files, and network activity. If you enable Cortex XDR –
Analytics enabled, Cortex XDR can also raise Analytics BIOCs (ABIOCs).
To enable you to take advantage of the latest threat research, Cortex XDR automatically receives
preconfigured rules from Palo Alto Networks. These global rules are delivered to all tenants with content
updates. In cases where you need to override a global BIOC rule, you can disable it or set a rule
exception. You can also configure additional BIOC rules as you investigate threats on your network and
endpoints. BIOC rules are highly customizable: you can create a BIOC rule that is simple or quite
complex.
As soon as you create or enable a BIOC rule, the app begins to monitor input feeds for matches. Cortex
XDR also analyzes historical data collected in the Cortex Data Lake. Whenever there is a match, or hit, on
a BIOC rule, Cortex XDR logs a Cortex XDR alert.

To further enhance the BIOC rule capabilities, you can also configure BIOC rules as custom prevention
rules and incorporate them with your Restrictions profiles. Cortex XDR can then raise behavioral threat
prevention alerts based on your custom prevention rules in addition to the BIOC detection alerts.
If you are assigned a role that enables Investigation > Rules privileges, you can view all user-defined and
preconfigured rules for behavioral indicators of compromise (BIOCs) from Rules > BIOC.
BIOC Rules Fields

By default, the BIOC Rules page displays all enabled rules. To search for a specific rule, use the filters
above the results table to narrow the results. From the BIOC Rules page, you can also manage existing
rules using the right-click pivot menu.
The following table describes the fields that are available for each BIOC rule in alphabetical order.
FIELD DESCRIPTION
# OF HITS The number of hits (matches) on this rule
Status of the Cortex XDR search for the first 10,000 matches when the
BIOC rule was created or edited. Status can be:
BACKWARDS SCAN • Done
STATUS • Failed
• Pending
• Queued
BACKWARDS SCAN Timestamp of the Cortex XDR search for the first 10,000 matches in your
TIMESTAMP Cortex XDR when the BIOC rule was created or edited
BACKWARDS SCAN Number of times Cortex XDR searched for the first 10,000 matches in your
RETRIES Cortex XDR when the BIOC rule was created or edited
BEHAVIOR A schematic of the behavior of the rule
COMMENT Free-form comments specified when the BIOC was created or modified
Exceptions to the BIOC rule. When there's a match on the exception, the
EXCEPTIONS
event will not trigger an alert.
Unique identification number assigned to rules created by Palo Alto
GLOBAL RULE ID
Networks
INSERTION DATE Date and time when the BIOC rule was created
Displays the type of MITRE ATT&CK tactic the BIOC rule is attempting to
MITRE ATT&CK TACTIC
trigger on
MITRE ATT&CK Displays the type of MITRE ATT&CK technique and subtechnique the BIOC
TECHNIQUE rule is attempting to trigger on
MODIFICATION DATE Date and time when the BIOC was last modified

Unique name that describes the rule. Global BIOC rules defined by Palo
NAME Alto Networks are indicated with a blue dot and cannot be modified or
deleted.
Type of BIOC rule:
• Collection
• Credential Access
• Dropper
• Evasion
• Execution
• Evasive
• Exfiltration
TYPE • File Privilege Manipulation
• File Type Obfuscation
• Infiltration
• Lateral Movement
• Other
• Persistence
• Privilege Escalation
• Reconnaissance
• Tampering
SEVERITY BIOC severity that was defined when the BIOC was created
User who created this BIOC, the file name from which it was created, or
SOURCE
Palo Alto Networks if delivered through content updates.
USED IN PROFILES Displays if the BIOC rule is associated with a Restriction profile
Analytics BIOC Fields

By default, the Analytics BIOC Rules page displays all enabled rules. To search for a specific rule, use the
filters above the results table to narrow the results. From the Analytics BIOC Rules page, you can also
disable and enable rules using the right-click pivot menu.
The following table describes the fields that are available for each Analytics BIOC rule in alphabetical
order.
FIELD DESCRIPTION
Description Description of the behavior that will raise the alert
# OF HITS The number of hits (matches) on this rule
Unique identification number assigned to rules created by Palo Alto
GLOBAL RULE ID
Networks
INSERTION DATE Date and time when the BIOC rule was created
MITRE ATT&CK TACTIC Displays the type of MITRE ATT&CK tactic the BIOC rule is attempting to
trigger on
MITRE ATT&CK Displays the type of MITRE ATT&CK technique and subtechnique the BIOC
TECHNIQUE rule is attempting to trigger on
MODIFICATION DATE Date and time when the BIOC was last modified

NAME Unique name that describes the rule. New rules are identified with a blue
badge icon.
Rules associated with the Identity Analytics are displayed with an Identity
Analytics tag.
SEVERITY Indicator's reputation level. One of Unknown, Good, Bad, or Suspicious.
SEVERITY BIOC severity that was defined when the BIOC rule was created. Severity
level can be Low, Medium, High, or Multiple.
Multiple-severity BIOC rules can raise alerts with different severity levels.
Hover over the flag to see the severities defined for the rule.
Steps to create IOC rules
Step 1: From Cortex XDR, select Rules > BIOC
Step 2: Select + Add Rule
Step 3: Configure the BIOC criteria.
Define any relevant activity or characteristics for the entity type. Creating a new BIOC rule is similar to
the way that you create a search with Query Builder. You use XQL to define the rule. The XQL query must
filter on an event_type in order for it to be a valid BIOC rule.
Step 4: Test your BIOC rule.
Rules that you do not refine enough can create thousands of alerts. As a result, it is highly recommended
that you test the behavior of a new or edited BIOC rule before you save it. For example, if a rule will
return thousands of hits because you negated a single parameter, it is a good idea to test the rule before
you save it and make it active.
When you test the rule, Cortex XDR immediately searches for rule matches across all your Cortex Data
Lake data. If there are surprises, now is the time to see them and adjust the rule definition.
Step 5: Save your BIOC rule.
Step 6: Define your BIOC properties.
● Enter a descriptive Name to identify the BIOC rule.
● Select a rule TYPE that describes the activity.
● Specify the SEVERITY you want to associate with the alert.
● (Optional) Select the MITRE Tactic and MITRE Technique you want to associate with the alert.
You can select up to three MITRE Tactics and MITRE Techniques/Sub-Techniques.
● Enter any additional comments such as why you created the BIOC.
● Click OK.
Step 7: Save your BIOC rule.
5.1.3 Explain the purpose and use of the XQL technique
Cortex XDR enables you to run XQL queries on your data sources using APIs. Each XQL query API
consumes compute units based on the timeframe, complexity, and number of API response results.
Cortex XDR provides a free daily quota of compute units allocated according to your license size. Queries

called without enough quota will fail. To expand your investigation capabilities, you can purchase
additional compute units by enabling the Compute Unit add-on.
The Compute Unit add-on provides an additional one compute unit per day, in addition to your free daily
quota. For example, if you have allocated five free daily compute units, then with the add-on, you will
have a total of six daily compute units. The compute units are refreshed every 24 hours according to UTC
time. You can purchase a minimum of 50 compute units.
To gauge how many compute units you require, Cortex XDR provides a 30-day free trial period with a
total of three times your allocated compute units to run XQL API queries and track the cost of each XQL
API query responses and the XQL API Usage page. In addition, Cortex XDR sends a notification when the
Compute Units add-on has reached your daily threshold.
To enable the add-on, navigate to Configurations > Cortex XDR License > Add-ons, select the Compute
Unit tile, and Enable.
To manage your XQL API queries:

Step 1: Navigate to Configurations > Data Management > XQL API Usage.
Step 2: In the Daily Usage in Compute Units section, monitor the amount of quota units used over the
past 24 hours and the amount of free daily quota allocated according to your license size. Timeframe is
calculated according to UTC time.
For Managed Security tenants, the values calculated are the total daily usage of parent and child tenants.
Step 3: In the “Compute Units over last 30 Days” section, track your quota usage over the past 30 days.
The red line represents your daily license quota. For Managed Security tenants, make sure you select
from the MSSP Tenant Selection drop-down menu the tenant for which you want to display the
information. To investigate further:

● Hover over each bar to view the total number of query units used on each day.
● Select a bar to display in the XQL Queries Using API table the list of queries executed on the
selected day.
Step 4: In the XQL Queries Using API table, investigate all the XQL API queries that were executed on
your tenant. For Managed Security tenants, make sure you select from the MSSP Tenant Selection
drop-down menu the tenant for which you want to display the information. You can filter and sort
according to the following fields:
● ID—Unique identifier representing the executed XQL API query
● Timestamp—Date and time of when the XQL API was executed
● PAPI Key ID—API Key ID used to execute the XQL API
● XQL Query—The XQL query called using an API search
● Compute Unit Usage—Displays how many query units were used to execute the API query
● Tenant—Appears only in a Managed Security tenant. Displays which tenant executed an API
query.
Step 5: Investigate the XQL API query results.
In the XQL Queries Using API table, locate an XQL API query, right-click, and select Show Results.
The query is displayed in the XQL Search page where you can view the query results.
5.1.4 Explain the purpose and use of the Query Builder technique
The Query Builder is a powerful search tool at the heart of Cortex XDR that you can use to investigate
any lead quickly, expose the root cause of an alert, perform damage assessment, and hunt for threats
from your data sources. With Query Builder, you can build complex queries for entities and entity
attributes so that you can surface and identify connections between them. The Query Builder searches
the raw data and logs stored in Cortex Data Lake and Cortex XDR for the entities and attributes you
specify and returns up to 100,000 results. From the Query Builder, you can also use the XQL Search to
create XQL queries to search for and view raw data that is stored in Cortex XDR or imported from custom
and third-party datasets.
The Query Builder provides queries for the following types of entities:
● Process—Search on process execution and injection by process name, hash, path, command-line
arguments, and more. See Create a Process Query.

● File—Search on file creation and modification activity by file name and path. See Create a File
Query.
● Network—Search network activity by IP address, port, host name, protocol, and more. See
Create a Network Query.
● Registry—Search on registry creation and modification activity by key, key value, path, and data.
See Create a Registry Query.
● Event Log—Search Windows event logs and Linux system authentication logs by username, log
event ID (Windows only), log level, and message. See Create an Event Log Query.
● Network Connections—Search security event logs by firewall logs, endpoint raw data over your
network. See Create a Network Connections Query.
● All Actions—Search across all network, registry, file, and process activity by endpoint or process.
See Query Across All Entities.
The Query Builder also provides flexibility for both on-demand query generation and scheduled queries.
5.1.5 References
IOC Technique:
cortex-xdr-indicators/working-with-iocs/ioc-rules-details.html#idb38e1dd3-cefc-4526-9c8d-016a962ca4c
2
BIOC Technique:
cortex-xdr-indicators/working-with-biocs/bioc-rules-details.html#idb29d55b8-9757-4c1e-8733-ef25f11b
428d
XQL Technique:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/data-management/manage-
xql-api.html#ida87d71c2-5e82-4f77-b8a1-3c8db6ff42c7
Query Builder:
search-queries/query-builder
1. Which technique is used to investigate any lead quickly, expose the root cause of an alert,
perform damage assessment, and hunt for threats from your data sources?
a. IOC Technique
b. Query Builder Technique
c. BIOC Technique
d. XQL Technique
2. Which technique alerts and responds to behaviors?

a. XQL Technique
b. IOC Technique
c. Query Builder Technique
d. BIOC Technique
5.2 Identify how to prevent the threat

5.2.1 Convert BIOCs into custom prevention rules
After identifying a threat and its characteristics, you can configure rules for behavioral indicators of
compromise (BIOCs). After you create a BIOC rule, Cortex XDR searches for the first 10,000 matches in
your Cortex Data Lake and raises an alert if a match is detected. Going forward, the app alerts when a
new match is detected.
Custom prevention rules are supported on Cortex XDR agent 7.2 and later versions and enable you to
configure and apply user-defined BIOC rules to Restriction profiles deployed on your Windows, Mac, and
Linux endpoints.
By using the BIOC rules, you can configure custom prevention rules to terminate the causality chain of a
malicious process according to the Action Mode defined in the associated Restrictions Security
profile and trigger Cortex XDR Agent behavioral prevention type alerts in addition to the BIOC rule
detection alerts.
For example, if you configure a custom prevention rule for a BIOC Process event and apply it to a
Restrictions profile with an action mode set to Block, the Cortex XDR agent:
● Blocks a process at the endpoint level according to the defined rule properties.
● Raises a behavioral prevention alert you can monitor and investigate in the Alerts Table.
Before you configure a BIOC rule as a custom prevention rule, create a Restriction profile for each type of
operating system (OS) that you want to deploy your prevention rules.
To configure a BIOC rule as a prevention rule:
Step 1: In the BIOC Rule table, from the Source field, filter and locate a user-defined rule you want to
apply as a custom prevention rule. You can only apply a BIOC rule that you created either from scratch or
from a Cortex XDR Global Rule template.
The user-defined BIOC rule event does not include the following field configurations:
● All Events—Host Name
● File Event—Device Type, Device Serial Number
● Process Event—Device Type, Device Serial Number
● Registry Event—Country, Raw Packet
BIOC rules with OS scope definitions must align with the Restrictions profile OS.
When defining the Process criteria for a user-defined BIOC rule event type, you can select to run only on
actor, causality, and OS actor on Windows, or you can choose to run on causality and OS actor on Linux
and Mac.
Step 2: Test your BIOC rule.

Rules that you do not refine enough can create thousands of alerts. As a result, it is highly recommended
that you test the behavior of a new or edited BIOC rule before you save it. Cortex XDR automatically
disables BIOC rules that reach 5,000 or more hits over a 24-hour period.
Step 3: Right-click and select Add to restrictions profile.
If the rule is already referenced by one or more profiles, select See profiles to view the profile names.
Step 4: In the Add to Restrictions Profile pop-up:
● Ensure that the rule you selected is compatible with the type of endpoint operating system.
● Select the Restriction profile name you want to apply the BIOC rule to for each of the operating
systems. BIOC event rules of type Event Log and Registry are only supported by Windows OS.
Step 5: Add the BIOC rule to the selected profiles.
The BIOC rule is now configured as a custom prevention rule and applied to your Restriction profiles.
After the Restriction profile is pushed to your endpoints, the custom prevention rule can start triggering
behavioral prevention type alerts.
Step 6: Review and edit your custom prevention rules.
1. Navigate to Endpoints > Policy Management > Profiles
2. Locate the Restrictions profile to which you applied the BIOC rule. In the Summary field, Custom
Prevention Rules appears as Enabled.
3. Right-click and select Edit.
4. In the Custom Prevention Rules section, you can review and modify the following:
● Action Mode—Select to Enable or Disable the BIOC prevention rules.
● Auto-disable—Select to auto-disable a BIOC prevention rule if it triggers after a defined number
of times during a defined duration.
● Prevention BIOC Rules table—Filter and maintain the BIOC rules applied to this specific
Restriction Profile. Right-click to Delete a rule or Go to BIOC Rules table.
5. Save your changes if necessary.
6. Investigate the BIOC prevention rules alerts.
● Select Settings > Investigation Incidents > Alerts Table
Filter the fields as follows:
o Alert Source: XDR Agent
o Action: Prevention (<profile action mode>)
o Alert Name: Behavioral Threat
● In the Description field, you can see the rule name that raised the prevention alert.
5.2.2 References
BIOC Rule:

cortex-xdr-indicators/working-with-biocs/create-a-bioc-rule.html
1. Cortex XDR automatically disables BIOC rules that reach how many hits over what period of
time?
a. 5,000 or more hits over a 24-hour period
b. 1,000 or more hits over a 24-hour period
c. 5,000 or more hits over a 12-hour period
d. 1,000 or more hits over a 12-hour period
2. Which three of the following field configurations are not included in user-defined BIOC rule
event? (Choose three.)
a. Host Name
b. Device Serial Number
c. IP Address
d. Device Type
5.3 Manage threat hunting

5.3.1 Describe the purpose of Unit 42
Unit 42 brings together world-renowned threat researchers from Palo Alto Networks with an elite team
of security consultants to create an intelligence-driven, response-ready organization. The Unit 42 Threat
Intelligence team provides threat research that enables security teams to understand adversary intent
and attribution while enhancing protections offered by Palo Alto Networks products and services to stop
advanced attacks. As threats escalate, Unit 42 is available to advise customers on the latest risks, assess
their readiness, and help them recover when the worst occurs. The Unit 42 Security Consulting team
serves as a trusted partner with state-of-the-art cyber-risk expertise and incident-response capabilities,
helping customers focus on their business before, during, and after a breach.
Managed Threat Hunting offers round-the-clock monitoring from Unit 42 experts to discover attacks
anywhere in your organization. Threat hunters work on your behalf to discover advanced threats, such as
state-sponsored attackers, cybercriminals, malicious insiders, and malware.
Unit 42 analysts:
● Analyze suspicious signals generated by Cortex XDR analytics, custom detection rules, and Cortex
XDR research.
● Manually seek out emerging adversaries using the powerful data-exploration capabilities of
Cortex XDR.

● Investigate threats and determine the total scope of incidents.
● Produce detailed Threat Reports that reveal the tools and steps of attacks so you can root out
adversaries quickly.
● Offer direct assistance to answer questions and provide guidance about Threat Reports and
Impact Reports.
Managed Threat Hunting augments your security by providing 24/7, year-round monitoring by Palo Alto
Networks threat researchers and Unit 42 experts. The Managed Threat Hunting teams proactively
safeguard your organization and provide threat reports for critical security incidents and impact reports
for emerging threats that provide an analysis of exposure in your organization. In addition, the Managed
Threat Hunting team can identify incidents and provide in-depth review of related threat reports.
5.3.2 References
Threat Hunting:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/managed-security/about-m
anaged-threat-hunting.html#id4e98a15b-1861-405b-9317-b62510cf515b
1. Which statement is not true for Unit 42?
a. It investigates threats and determines the total scope of incidents.
b. It offers direct assistance to answer questions and provide guidance about Threat Reports and
Impact Reports.
c. It is available to advise customers on the latest risks, assess their readiness, and help them
recover when the worst occurs .
d. It can detect a variety of threats but may miss some complex malware.

Domain 6 Reporting
6.1 Identify the reporting capabilities of XDR
6.1.1 Leverage reporting tools
Extended detection and response (XDR) is a new approach to threat detection and response that
provides holistic protection against cyberattacks, unauthorized access, and misuse.
Cortex XDR provides the following list of widgets to help you create dashboards and reports displaying
summarized information about your endpoints:
● Agent Management Widgets
● Incident Management Widgets
● Investigation Widgets
● User Defined Widgets
● Asset Widgets
● XQL Search
● Custom Widget
● System Monitoring
● Host Insights
Reporting menu:
From the Reporting menu, you can view and manage your dashboards and reports from the dashboard
and the Incidents Table and view alert exclusions.
● Dashboard—Provides dashboards that you can use to view high-level statistics about your
agents and incidents.
● Dashboards Manager—Add new dashboards with customized widgets to surface the statistics
that matter to you most.
● Reports—View all the reports that Cortex XDR administrators have run.
● Reports Templates—Build reports using predefined templates or customize a report.
6.1.2 References
Widgets:

https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/monitoring/cortex-xdr-dash
board/dashboard-widgets
Manage Dashboards:
board/manage-dashboards
1. Which option from the reporting menu will you choose if you need to add additional widgets to
the dashboard?
a. Dashboard
b. Dashboards Manager
c. Reports
d. Reports Templates
2. The Response action breakdown widget belongs to which of the following widget categories?
a. Agent Management Widgets
b. Incident Management Widgets
c. Investigation Widgets
d. User Defined Widgets
6.2 Outline how to build a quality report

6.2.1 Identify what is relevant to a report given context
Create a Report from Scratch

Step 1: Select Reporting > Report Templates > + New Template.
Step 2: Enter a unique Report Name and an optional Description of the report.
Step 3: Select the Data Timeframe for your report.
● You can choose Last 24H (day), Last 7D (week), Last 1M (month), or a custom timeframe.
Step 4: Choose the Report Type.

● You can use an existing template, or you can build a new report from scratch.
Step 5: Click Next.
Step 6: Customize your report.

● To get a feel for how the data will look, Cortex XDR provides mock data. To see how the report
would look with real data in your environment, you can use the toggle above the report to use
Real Data. Select Preview A4 to view how the report is displayed in an A4 format.
● Drag and drop widgets from the widget library to their desired position.
● If necessary, remove unwanted widgets from the template. To remove a widget, select the menu
in the top-right corner and select Remove widget.
● For incident-related widgets, you can also select the star to include only incidents that match an
incident-starring configuration in your report. A purple star indicates that the widget is displaying
only starred incidents.
Step 7: When you have finished customizing your report template, click Next.
Step 8: If you are ready to run the report, select Generate now.
Step 9: To run the report on a regular Schedule, you can specify the time and frequency that Cortex XDR
will run the report.
Step 10: (Optional) Enter an Email Distribution list or Slack workspace to send a PDF version of your
report.
● Select Add password used to access report sent by email and Slack to set a password
encryption. Password encryption is only available for PDF format.
Step 11: (Optional) Attach CSV file of your XQL query widget to a report.
● From the drop-down menu, search and select one or more of your custom widgets to attach to
the report. The XQL query widget is attached to the report as a CSV file along with the
customized PDF. Depending on how you chose to send the report, the CSV file is attached as
follows:
o Email—Sent as separate attachments for each widget. The total size of the attachment in
the email cannot exceed 20MB.
o Slack—Sent within a ZIP file that includes the PDF file.
Step 12: Save Template.
Step 13: After your report completes, you can download it from the Reporting > Reports page.
● In the Name field, reports with both PDF and CSV files are marked with a icon, while
reports with a single PDF are marked with a icon.
Run a report based on a dashboard

Step 1: Select Reporting > Dashboards Manager.
Step 2: Right-click the dashboard from which you want to generate a report and select Save as report
template.
Step 3: Enter a unique Report Name and an optional Description of the report, then Save the template.

Step 4: Select Reporting > Report Templates.
Step 5: Run the report.
● You can either Generate Report to run the report on-demand, or you can Edit the report
template to define a schedule.
6.2.2 Interpret meaning from a report
You can run and customize reports containing a snapshot of statistics about your environment over a
selected time period. You can generate reports from Cortex XDR on demand or schedule them to run
daily or weekly. You can use dashboards as the basis for a report template, or you can customize your
report with widgets from the widget library. When your report is ready, you can download it from the
Reports page. You can also email reports to an email distribution of your choice.
6.2.3 Identify the information needed for a given audience
To create purposeful dashboards, you must consider the information that you and other analysts find
important to your day-to-day operations. This consideration guides you in building a custom dashboard.
When you create a dashboard, you can select widgets from the widget library and choose their
placement on the dashboard.
Step 1: Select Reporting > Dashboards Manager > + New Dashboard.
Step 2: Enter a unique Dashboard Name and an optional Description of the dashboard.
Step 3: Choose the Dashboard Type.

● You can use an existing dashboard as a template, or you can build a new dashboard from scratch.
Step 4: Click Next.
Step 5: Customize your dashboard.

● To get a feel for how the data will look, Cortex XDR provides mock data. To see how the
dashboard would look with real data in your environment, you can use the toggle above the
dashboard to use Real Data.
● Drag and drop widgets from the widget library to their desired position.
● For agent-related widgets, apply an endpoint scope, if desired.
Applying an endpoint scope restricts the results to only the endpoints that belong to the group. To
apply the scope, select the menu in the top-right corner of the widget and then select Groups.
Search for and select one or more endpoint groups for which you want to set the widget scope.
● For incident-related widgets, select the star to display only incidents that match an
incident-starring configuration on your dashboard, if desired. A purple star indicates that the
widget is displaying only starred incidents (see Manage Incident Starring).
● Repeat the process to continue adding additional widgets to the dashboard. If necessary, you
can also remove unwanted widgets from the dashboard. To remove a widget, select the menu in
the top-right corner, and Remove widget.

Step 6: When you have finished customizing your dashboard, click Next.
Step 7: To set the custom dashboard as your default dashboard when you log in to Cortex XDR, Define as
default dashboard.
Step 8: To keep this dashboard visible only for you, select Private. Otherwise, the dashboard is public
and visible to all Cortex XDR app users with the appropriate roles to manage dashboards.
Step 9: Generate your dashboard.
From the Reporting > Dashboards Manager, you can view all custom and default dashboards. From the
Dashboards Manager, you can also delete, edit, duplicate, disable, and perform additional management
actions on your dashboards. To manage an existing dashboard, right-click the dashboard and select the
desired action.
● Delete—Permanently delete a dashboard.
● Edit—Edit an existing dashboard. You cannot edit the default dashboards provided by Palo Alto
Networks, but you can save it as a new dashboard.
● Save as new—Duplicate an existing template.
● Disable—Temporarily disable a dashboard. If the dashboard is public, this dashboard is also
removed for all users.
● Set as default—Make the dashboard the default dashboard that displays when you (and other
users if the dashboard is public) log in to Cortex XDR.
● Save as report template—Save a report as a template.

Viewer Endpoints
View the majority of the features of the Cortex Endpoint Policies
XDR app for this instance Endpoint Profiles
Endpoint Management
Endpoint Groups
Endpoint Installations
Device Control
Global Exceptions
Host Insights
Investigation
Alerts
Incidents
Rules
Investigation Query
Response
Action Center
Scripts
Configurations
General Configurations
Auditing
Pathfinder Applet
Pathfinder Data Collection
Assets
Asset Management
Dashboards
Dashboards
Reports
Reports
6.2.4 Outline the capabilities of XQL to build a report
The XDR Query Language (XQL) enables you to query data ingested into Cortex XDR for rigorous endpoint
and network-event analysis. XQL forms queries in stages. Each stage performs a specific query operation
and is delimited by a pipe (|). Queries require a dataset, or data source, to run against. Unless otherwise
specified, the query will run against the xdr_data dataset, which contains all log information that Cortex
XDR collects. However, you can also configure Cortex XDR to query additional datasets.
It is possible to create a dataset with uppercase characters in its name, but when creating a query, the
dataset name only uses lowercase characters.

To streamline your investigations, the XQL search provides the following aids to help you construct and
visualize your queries.
Create and edit custom widgets based on XQL Search queries

Step 1: In Cortex XDR, navigate to Reporting > Widget Library.
● Create and edit custom widgets based on XQL Search queries.

o In the widget menu, click Create custom XQL widget.
o Enter a widget Name and optional Description.
o Create an XQL query. Select XQL Helper to view XQL search and schema examples.
o Generate the XQL query to display the search results. XQL queries generated from the
widget library do not appear in the Query Center. The results are used only for creating
the custom widget.
o In the Widget section, define how you want to visualize the results.
o After you are happy with the query parameters and visualization definitions, Save
widget. The custom widget appears in the list of existing widgets.
● Search for custom and predefined widgets.
o Search for a widget or Show widgets according to the type of category.
o Select a widget type to display the widget graph type and parameters. By default, Cortex
XDR displays the widget with Mock Data. Toggle to display your current Real Data.
● Edit existing custom widgets.
o Locate a custom widget.
o Select Update widget ( ) to edit the widget or Delete widget from library.
Editing an existing widget affects all dashboards that include the widget and future
generated reports.
Step 2: (Optional) Include the widgets listed in the widget library in your custom dashboards and reports.
Custom XQL Widget Report Attachments

You can attach the XQL queries you saved as custom widgets to your report templates.

When editing or creating a report template, you can attach one or more of your XQL query custom
widgets to your report. The XQL query widget is added to the report as a CSV file along with the
customized PDF.
Each XQL query widget creates a separate CSV file that you can:
● Send by email as separate attachments for each widget. The total size of an attachment in the
email cannot exceed 20MB.
● Send by Slack as part of a ZIP file that includes the PDF.
● Download from the Reports page.
6.2.5 Outline distributing and scheduling capabilities of Cortex XDR
Run or schedule a Report Based on a Dashboard:

Step 1: Select Reporting > Dashboards Manager
Step 2: Right-click the dashboard from which you want to generate a report and select Save as report
template.
Step 3: Enter a unique Report Name and an optional Description of the report, then Save the template.
Step 4: Select Reporting > Report Templates.
Step 5: Run the report. You can either Generate Report to run the report on demand, or you can Edit the
report template to define a schedule.
Scheduled Queries:
From the Scheduled Queries page, you can easily view all scheduled and reoccurring queries created
from the Query Builder. The Scheduled Queries page displays information about the query including the
query parameters and allows you to adjust or modify the schedule as needed. To edit a query schedule,
right-click the query and select the desired action.

FIELD DESCRIPTION
CREATED BY User who created or scheduled the query
NEXT EXECUTION Next execution time if the query is scheduled to run at a specific
frequency. If the query was only scheduled to run at a specific time and
date, this field will show None.
QUERY DESCRIPTION The query parameters used to run the query.
QUERY ID Unique identifier of the query
QUERY NAME For saved queries, the Query Name identifies the query specified by the
administrator. For scheduled queries, the Query Name identifies the
atuogenerated name of the parent query. Scheduled queries also display
an icon to the left of the name to indicate that the query is reoccurring.
SCHEDULE TIME Frequency or time at which the query was scheduled to run
TIMESTAMP Date and time the query was created
6.2.6 References
Run or Schedule Reports:

board/run-or-schedule-reports
Custom Dashboard:
board/build-a-custom-dashboard.html
Create and edit custom widgets based on XQL Search queries:

board/widget-library
Scheduled Queries:
search-queries/scheduled-queries

1. Which of the following statements about dashboard customization is incorrect?
a. You can create and add custom widgets to the dashboard.
b. You can temporarily disable a dashboard.
c. You can edit the default dashboards provided by Palo Alto Networks.
d. For agent-related widgets, you can apply an endpoint scope.
2. Which of the following paths is required to create a report from the scratch?

a. Reporting > Report Templates
b. Reporting > Dashboard Manager
c. Reporting > Reports
d. Reporting > Dashboard

Domain 7 Architecture
7.1 Outline components of Cortex XDR
7.1.1 Define the role of Cortex XDR Data Lake
Palo Alto Networks Cortex Data Lake provides cloud-based, centralized log storage and aggregation for
your on-premises, virtual (private cloud and public cloud) firewalls, for Prisma Access, and for
cloud-delivered services such as Cortex XDR.
Cortex Data Lake is secure, resilient, and fault-tolerant, and it ensures your logging data is up to date and
available when you need it. It provides a scalable logging infrastructure that alleviates the need for you
to plan and deploy Log Collectors to meet your log retention needs. If you already have on-premises Log
Collectors, the new Cortex Data Lake can easily complement your existing setup. You can augment your
existing log-collection infrastructure with the cloud-based Cortex Data Lake to expand operational
capacity as your business grows, or to meet the capacity needs for new locations.
With this service, Palo Alto Networks takes care of the ongoing maintenance and monitoring of the
logging infrastructure so that you can focus on your business.

7.1.2 Define the role of Cortex Agent
The Cortex XDR agent protects endpoints by preventing known and unknown malware from running on
those endpoints and by halting any attempts to leverage software exploits and vulnerabilities. The agent
enforces Security policy for your organization as defined in Cortex XDR. When a security event occurs on
an endpoint, the agent collects forensic information about that event that you can use to analyze the
incident.
A Cortex XDR agent perform its own analysis locally on the endpoint but also consumes WildFire threat
intelligence. The Cortex XDR agent reports all endpoint activity to the Cortex Data Lake for analysis by
Cortex XDR apps.
7.1.3 Define the role of Cortex Console
Cortex XDR provides an easy-to-use interface that you can access from the Hub. By default, Cortex XDR
displays the Incident Management Dashboard when you log in. If desired, you can change the default
dashboard or build a custom dashboard that displays when you log in.
Depending on your license and assigned role, you can explore the areas in the app.
7.1.4 Define the role of Cortex Broker
The Palo Alto Networks Broker is a secured virtual machine (VM), integrated with Cortex XDR, that
bridges your network and Cortex XDR. By setting up the broker, you establish a secure connection in
which you can route your endpoints and collect and forward logs and files for analysis.

The Broker can be leveraged for running different services separately on the VM using the same Palo Alto
Networks authentication. Once installed, the broker automatically receives updates and enhancements
from Cortex XDR, providing you with new capabilities without having to install a new VM.
7.1.5 Distinguish between different proxies
You can configure communication through proxy servers between the Cortex XDR server and the Cortex
XDR agents running on Windows, Mac, and Linux endpoints. The Cortex XDR agent uses the proxy
settings defined as part of the Internet & Network settings or WPAD protocol on the endpoint. You can
also configure a list of proxy servers that your Cortex XDR agent will use to communicate the with the
Cortex XDR server.
Cortex XDR supports the following types of proxy configurations:

● System-wide proxy—Use system-wide proxy to send all communication on the endpoint,
including to and from the Cortex XDR agent, through a proxy server configured for the endpoint.
Cortex XDR supports proxy communication for proxy settings defined explicitly on the endpoint,
as well as proxy settings configured in a proxy autoconfig (PAC) file.
● Application-specific proxy—Available with Traps agent 5.0.9, Traps agent 6.1.2, and Cortex XDR
agent 7.0 and later releases. Configure a proxy specific to Cortex XDR that applies only to the
Cortex XDR agent and does not enforce proxy communications with other apps or services on
your endpoint. You can set up up to five proxy servers either during the Cortex XDR agent
installation process, or following agent installation, directly from the Cortex XDR management
console.

7.1.6 Define the role of Directory Sync
The Directory Sync Service enables Palo Alto Networks cloud-based applications to leverage computer,
user, and group attributes from your on-premises Active Directory for use in policy and endpoint
management. The Directory Sync Service uses an on-premises agent to collect those attributes from your
on-premises Active Directory. The Directory Sync Service agent runs in the background to collect the
Active Directory information and syncs it with the cloud-based Directory Sync Service that you configure
using the Hub.
7.1.7 Define the role of WildFire
For each file, Cortex XDR receives a file verdict and the WildFire analysis report. This report contains the
detailed sample information and behavior analysis in different sandbox environments, leading to the
WildFire verdict. You can use the report to assess whether the file poses a real threat on an endpoint.
The details in the WildFire analysis report for each event vary depending on the file type and the
behavior of the file.
7.1.8 References
Cortex XDR data lake:

https://docs.paloaltonetworks.com/cortex/cortex-data-lake/cortex-data-lake-getting-started/get-started-
with-cortex-data-lake/overview
Cortex agent:

https://docs.paloaltonetworks.com/cortex/cortex-xdr/7-5/cortex-xdr-agent-admin/cortex-xdr-agent-for-
windows.html
Cortex console:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/get-started-with-cortex-xdr-
pro/use-cortex-xdr.html
Cortex broker:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/broker-vm/broker-vm-overvi
ew.html#id55787a75-1692-4937-86e7-7237733b935b
Proxy communication:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/get-started-with-cortex-xdr-
pro/set-up-endpoint-protection/proxy-configuration
Directory sync:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-release-notes/set-up-dir-sync
WildFire:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-prevent-admin/investigation-and-respo
nse/investigate-files/review-wildfire-analysis-details

1. _____ is a secured virtual machine, integrated with Cortex XDR, that bridges your network and
Cortex XDR.
a. Cortex Console
b. Cortex Agent
c. Cortex Broker
d. WildFire
2. Which tab do you need to select to manage Cortex XDR agents?

a. Reporting
b. Investigation
c. Response
d. Endpoints

7.2 Describe communication among components
7.2.1 Define communication of data lakes
Cortex Data Lake receives logs from the industry-leading Palo Alto Networks cybersecurity portfolio.
When relevant events—based on the customer’s security policies—occur across any platform elements,
logs are generated to enable detection, investigation, and analysis.
Palo Alto Networks Next-Generation Firewalls send logs to a data center located in whichever region the
customer selects. The customer can choose any of the following types of logs to send to Cortex Data
Lake:
● Traffic logs—Information about internal and external network connections from the IP addresses
of devices and users.
● Threat logs—Information about web traffic the firewall sees.
● URL Filtering logs—Information about known and unknown threats.
● Data Filtering logs—Display entries for the security rules that help prevent sensitive information
such as credit card numbers from leaving the area that the firewall protects
● Tunnel inspection logs—Entries that track the start and end of inspected tunnel sessions. This
information is sometimes used to apply policies to tunneled traffic.
● SCTP logs—Information on a wide range of stream control transmission protocol (SCTP)
attributes, including SCTP event type, chunk type, payload protocol ID, SCTP cause code,
association ID, stream ID, and chunks, in addition to the general information that the firewall
identifies, such as source and destination address, source and destination port, and timestamp.
It also provides additional information on some applications running over SCTP, including
Diameter and SS7 protocols.
● HIP Match logs—Information about endpoints that have logged in to the GlobalProtect service.
Host Information Profile data is logged only when the connected device matches a configured
asset policy, such as when the host does not have antivirus installed.
● GlobalProtect logs—Information about the GlobalProtect auth method, LSVPN/satellite events,
portal, gateway, and clientless VPN logs.
● IP-Tag logs—Information about source IP addresses registered/unregistered on the firewall and
what tag the firewall applied to the address.
● User-ID logs—Additional user and group mappings corresponding to network and application
traffic logs.
● Authentication logs—Information about authentication events that occur when end users try to
access network resources controlled by authentication policy rules.
● Enhanced application logs—Information needed to perform analytics, such as MAC addresses,
hostnames, DNS queries/responses, and Kerberos authentication messages. MAC addresses and
hostnames are used to uniquely identify devices and their patterns on the network, while DNS
queries/responses are used to detect outbound communications caused by advanced malware.
Kerberos authentication messages log the username and can help identify unauthorized access
to services on the network.
7.2.2 Define communication for WildFire
File Forwarding

Cortex XDR sends unknown samples for in-depth analysis to WildFire. WildFire accepts up to 1,000,000
sample uploads per day and up to 1,000,000 verdict queries per day from each Cortex XDR tenant. The
daily limit resets at 23:59:00 UTC. Uploads that exceed the sample limit are queued for analysis after the
limit resets. WildFire also limits sample sizes to 100MB.
For samples that the Cortex XDR agent reports, the agent first checks its local cache of hashes to
determine whether it has an existing verdict for that sample. If the Cortex XDR agent does not have a
local verdict, the Cortex XDR agent queries Cortex XDR to determine whether WildFire has previously
analyzed the sample. If the sample is identified as malware, it is blocked. If the sample remains unknown
after comparing it against existing WildFire signatures, Cortex XDR forwards the sample for WildFire
analysis.
File Type Analysis

The Cortex XDR agent analyzes files based on the type of file, regardless of the file’s extension. For deep
inspection and analysis, you can also configure your Cortex XDR to forward samples to WildFire. A
sample can be:
● Any portable executable (PE) file, including (but not limited to):
o Executable files
o Object code
o FON (Fonts)
o Microsoft Windows screensaver (.scr) files
● Microsoft Office files containing macros opened in Microsoft Word (winword.exe) and Microsoft
Excel (excel.exe):
o Microsoft Office 2003 to Office 2016—.doc and .xls
o Microsoft Office 2010 and later releases—.docm, .docx, .xlsm, and .xlsx
● Dynamic-link library file including (but not limited to):
o .dll files
o .ocx files
● Android application package (APK) files
● Mach-o files
● DMG files
● Linux (ELF) files
Verdicts
WildFire delivers verdicts to identify samples it analyzes as safe, malicious, or unwanted (grayware is
considered obtrusive but not malicious):
● Unknown—Initial verdict for a sample that WildFire has received but has not analyzed.
● Benign—The sample is safe and does not exhibit malicious behavior. If Low Confidence is
indicated for the Benign verdict, Cortex XDR can treat this hash as if the verdict is Unknown and
further run local analysis to get a verdict with higher confidence.
● Malware—The sample is malware and poses a security threat. Malware can include viruses,
worms, Trojans, remote access tools (RATs), rootkits, botnets, and malicious macros. For files
identified as malware, WildFire generates and distributes a signature to prevent against future
exposure to the threat.

● Grayware—The sample does not pose a direct security threat, but it might display otherwise
obtrusive behavior. Grayware typically includes adware, spyware, and browser helper objects
(BHOs).
When WildFire is not available or integration is disabled, the Cortex XDR agent can also assign a local
verdict for the sample using additional methods of evaluation. When the Cortex XDR agent performs
local analysis on a file, it uses pattern-matching rules and machine learning to determine the verdict. The
Cortex XDR agent can also compare the signer of a file with a local list of trusted signers to determine
whether a file is malicious.
● Local analysis verdicts:

o Benign—Local analysis determined that the sample is safe and does not exhibit
malicious behavior.
o Malware—The sample is malware and poses a security threat. Malware can include
viruses, worms, Trojans, remote access tools (RATs), rootkits, botnets, and malicious
macros.
● Trusted signer verdicts:
o Trusted—The sample is signed by a trusted signer.
o Not Trusted—The sample is not signed by a trusted signer.
Local Verdict Cache

The Cortex XDR agent stores hashes and the corresponding verdicts for all files that attempt to run on
the endpoint in its local cache. The local cache scales in size to accommodate the number of unique
executable files opened on the endpoint. On Windows endpoints, the cache is stored in the
C:\ProgramData\Cyvera\LocalSystem folder on the endpoint. When service protection is enabled (see
Add a New Agent Settings Profile), the local cache is accessible only by the Cortex XDR agent and cannot
be changed.
Each time a file attempts to run, the Cortex XDR agent performs a lookup in its local cache to determine
whether a verdict already exists. If known, the verdict is either the official WildFire verdict or manually
set as a hash exception. Hash exceptions take precedence over any additional verdict analysis.
If the file is unknown in the local cache, the Cortex XDR agent queries Cortex XDR for the verdict. If
Cortex XDR receives a verdict request for a file that was already analyzed, Cortex XDR immediately
responds to the Cortex XDR agent with the verdict.
If Cortex XDR does not have a verdict for the file, it queries WildFire and optionally submits the file for
analysis. While the Cortex XDR agent waits for an official WildFire verdict, it can use file analysis and
protection flow to evaluate the file. After Cortex XDR receives the verdict, it responds to the Cortex XDR
agent that requested the verdict.
7.2.3 Define communication options/channels to and from the client
Palo Alto Networks Next-Generation Firewalls send logs to a data center located in whichever region the
customer selects. The customer can choose any of the following types of logs to send to Cortex Data
Lake:
● Traffic logs—information about internal and external network connections from the IP addresses
of devices and users.

● Threat logs—information about web traffic the firewall sees.
● URL Filtering logs—information about known and unknown threats.
● Data Filtering logs—display entries for the security rules that help prevent sensitive information
such as credit card numbers from leaving the area that the firewall protects
● Tunnel inspection logs—entries that track the start and end of inspected tunnel sessions. This
information is sometimes used to apply policies to tunneled traffic.
● SCTP logs—information on a wide range of SCTP attributes, including SCTP event type, chunk
type, payload protocol ID, SCTP cause code, association ID, stream ID, and chunks, in addition to
the general information that the firewall identifies, such as source and destination address,
source and destination port, and timestamp. It also provides additional information on some
applications running over SCTP including Diameter and SS7 protocols.
● HIP Match logs—information about endpoints that have logged into the Global Protect service.
Host Information Profile data is logged only when the connected device matches a configured
asset policy, such as when the host does not have antivirus installed.
● Global Protect logs—information about the Global Protect Auth Method, LSVPN/satellite events,
portal, gateway, and clientless VPN logs.
● IP-Tag logs—information about source IP addresses registered/unregistered on the firewall and
what tag the firewall applied to the address.
● User-ID logs—additional user and group mappings corresponding to network and application
traffic logs.
● Authentication logs—information about authentication events that occur when end users try to
access network resources controlled by authentication policy rules.
● Enhanced application logs—information needed to perform analytics, such as MAC addresses,
hostnames, DNS queries/responses, and Kerberos authentication messages. MAC addresses and
hostnames are used to uniquely identify devices and their patterns on the network, while DNS
queries/responses are used to detect outbound communications caused by advanced malware.
Kerberos authentication messages log the username and can help identify unauthorized access
to services on the network.
7.2.4 Define communication for external dynamic list (EDL)
An external dynamic list (EDL) is a text file hosted on an external web server that your Palo Alto
Networks firewall uses to provide control over user access to IP addresses and domains that the Cortex
XDR has found to be associated with an alert.
Cortex XDR hosts two external dynamic lists you can configure and manage from the Cortex XDR
management console:
● IP Addresses EDL
● Domain Names EDL
To maintain an EDL in Cortex XDR, you must meet the following requirements:
● Cortex XDR Pro per TB or Cortex Pro per Endpoint license
● An App Administrator, Privileged Investigator, or Privileged Security Admin role, which include
EDL permissions
● Palo Alto Networks firewall running PAN-OS 9.0 or a later release
● Access to your Palo Alto Networks firewall configuration

Step 1: Enable EDL.
● Navigate to > Configurations > Integrations > External Dynamic List.
● Enable External Dynamic List and enter the Username and Password that the Palo Alto Networks
firewall should use to access the Cortex XDR EDL.
Step 2: Record the IP Addresses EDL URL and the Domains EDL URL. You will need these URLs in the
coming steps to point the firewall to these lists.
Step 3: Save the EDL configuration.
Step 4: Enable the firewall to authenticate the Cortex XDR EDL.

● Download and save the following root certificate:
https://certs.godaddy.com/repository/gd-class2-root.crt.
● On the firewall, select Device > Certificate Management > Certificates and Import the
certificate. Make sure to give the device certificate a descriptive name and select OK to save the
certificate.

● Select Device > Certificate Management > Certificate Profile and Add a new certificate profile.
● Give the profile a descriptive name and Add the certificate to the profile.
● Select OK to save the certificate profile.
Step 5: Set the Cortex XDR EDL as the source for a firewall EDL.
For more detailed information about how Palo Alto Networks firewall EDLs work, how you can use EDLs,
and how to configure them, review how to Use an External Dynamic List in Policy.
● On the firewall, select Objects > External Dynamic Lists and Add a new list.
● Define the list Type as either IP List or Domain List.
● Enter the IP Addresses Block List URL or the Domains Block List URL that you recorded in the last
step as the list Source.
● Select the Certificate Profile that you created in the last step.

● Select Client Authentication and enter the username and password that the firewall must use to
access the Cortex XDR EDL.
● Use the Repeat drop-down menu to define how frequently the firewall retrieves the latest list
from Cortex XDR.
● Click OK to add the new EDL.
Step 6: Select Policies > Security and Add or edit a Security policy rule to add the Cortex XDR EDL as
match criteria to a security policy rule.
Review the different ways you can enforce policy on an external dynamic list; this topic describes the
complete workflow to add an EDL as match criteria to a Security policy rule.
● Select Policies > Security and Add or edit a Security policy rule.
● In the Destination tab, select Destination Zone and select the external dynamic list as the
Destination Address.
● Click OK to save the Security policy rule and Commit your changes.
You do not need to perform an additional commit or make any subsequent configuration changes for the
firewall to enforce the EDL as part of your Security policy; even as you update the Cortex XDR EDL, the
firewall will enforce the list most recently retrieved from Cortex XDR.
Step 7: Add an IP address or domain to your EDL.

You can add to your IP address or domain lists as you triage alerts from the Action Center or throughout
the Cortex XDR management console.

To add an IP address or domain from the Action Center, Initiate an Endpoint Action to Add to EDL. You
can choose to enter the IP address or domain you want to add Manually or choose to Upload File.
During investigation, you can also Add to EDL from the Actions menu that is available from investigation
pages such as the Incidents View, Causality View, IP View, or Quick Launcher.
Step 8: At any time, you can view and make changes to the IP addresses and domain names lists.
● Navigate to Response > Action Center > EDL.
● Review your IP addresses and domain names lists.

● If desired, select New Action to add additional IP addresses and domain names.
● If desired, select one or more IP addresses or domain names, right-click, and Delete any entries
that you no longer want included on the lists.
7.2.5 Define communication from the broker
The Palo Alto Networks Broker is a secured virtual machine (VM), integrated with Cortex XDR, that
bridges your network and Cortex XDR. By setting up the broker, you establish a secure connection in
which you can route your endpoints and collect and forward logs and files for analysis.
You can leverage the Broker to run different services separately on the VM using the same Palo Alto
Networks authentication. Once installed, the broker automatically receives updates and enhancements
from Cortex XDR, providing you with new capabilities without having to install a new VM.

Per your Cortex XDR license, the following figure illustrates the different Broker VM features that could
be available on your organization side.
In Cortex XDR, select Settings ( ) > Configurations > Broker VM to view detailed information regarding
your registered broker VMs.
The Broker VMs table enables you to monitor and manage your broker VM and applet connectivity
status, version management, device details, and usage metrics.

7.2.6 References
Communication for WildFire:

security-profiles/add-malware-security-profile/wildfire-analysis-concepts.html
External dynamic list (EDL):

response-actions/manage-external-dynamic-lists
Communication from the broker:

https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/broker-vm/manage-your-br
oker-vm/view-broker-vm-details.html#id5bfe5659-8ced-4bae-8991-e4c67f256456
1. Which of the following does not pose a direct security threat, but might display otherwise
obtrusive behavior?
a. virus
b. Trojans
c. malware
d. grayware
2. What does SCTP stand for?

a. Stream Control Transmission Protocol
b. Stream Control Transfer Protocol
c. System Control Transfer Protocol
d. System Control Transmission Protocol
7.3 Describe the architecture of agents related to different operating

systems
7.3.1 Recognize different supported operating systems
Cortex XDR Agent 7.2 for Windows

The Cortex XDR agent protects Windows endpoints by preventing known and unknown malware from
running on those endpoints and by halting any attempts to leverage software exploits and
vulnerabilities. The agent enforces Security policy for your organization as defined in Cortex XDR. When a

security event occurs on an endpoint, the agent collects forensic information about that event that you
can use to analyze the incident.
Cortex XDR Agent 7.2 for Mac

The Cortex XDR agent protects Mac endpoints by preventing known and unknown malware from running
and by halting attempts to leverage software exploits and vulnerabilities. The agent enforces your
organization’s Security policy as defined in Cortex XDR. When a security event occurs on an endpoint, the
agent collects forensic information about that event that you can use to analyze the incident further.
Cortex XDR Agent 7.2 for Linux

The Cortex XDR agent protects Linux servers by preventing known and unknown malware from running
by halting any attempts to leverage software exploits and vulnerabilities to compromise the server. The
agent also extends exploit and malware protection to processes that run in Linux containers. When you
install the agent on a Linux server that uses containers, it automatically protects any new and existing
containerized processes regardless of the container solution (for example, Docker). Because Cortex XDR
issues the license per Linux server, each container does not consume any additional licenses.
7.3.2 Characterize the differences between functions or features on operating

systems
Cortex XDR Agent 7.2 for Windows

The Cortex XDR agent protects Windows endpoints by preventing known and unknown malware from
running on those endpoints and by halting any attempts to leverage software exploits and
vulnerabilities. The agent enforces Security policy for your organization as defined in Cortex XDR. When a
security event occurs on an endpoint, the agent collects forensic information about that event that you
can use to analyze the incident.
The following requirements apply to standard and VDI Windows endpoints:
REQUIREMENT SPECIFICATION
● Intel Pentium 4 or later with SSE2 instruction set support
● AMD Opteron/Athlon 64 or later with SSE2 instruction set
Processor support
● Dual core processor (minimum) for Cortex XDR Agent version 7.0
and later.
RAM 2GB minimum

Hard disk space 200MB minimum; 20GB recommended
● Allow communication on the TCP port from the Cortex XDR
agent to server (the default is port 443).
● Allow the Cortex XDR management console and agent to
Networking communicate with external and internal resources required for
enforcing endpoint protection. See the Cortex XDR Administrator
Guide for your license type (Enable Access with Cortex XDR
Prevent or Enable Access with Cortex XDR Pro per Endpoint).
● Windows 7—.NET 3.5 SP1, .NET 3.5.1, or .NET 4.5

.NET
● Windows 8—.NET 4.5

● Windows 8.1—.NET 4.5.1
● Windows 10 and later releases—.NET 4.6
● Windows Server 2008 R2—.NET 3.5 SP1 or .NET 3.5.1
● Windows Server 2012—.NET 4.5
● Windows Server 2012 R2 and later supported Windows
releases—.NET 4.5.1
Applications and utilities Windows Accessories (Notepad) to view logs

To set the language (English, German, Japanese, Spanish, French,
Localization Chinese Simplified, Chinese Traditional) of the Cortex XDR agent console,
you must install the corresponding language pack.
Cortex XDR Agent 7.2 for Mac

The Cortex XDR agent protects Mac endpoints by preventing known and unknown malware from running
and halting attempts to leverage software exploits and vulnerabilities. The agent enforces your
organization’s security policy as defined in Cortex XDR. When a security event occurs on an endpoint, the
agent collects forensic information about that event which you can use to analyze the incident further.
The Cortex XDR agent for Mac has the following requirements:
REQUIREMENT SPECIFICATION
● Intel Pentium 4 or later with SSE2 instruction set support
Processor ● AMD Opteron/Athlon 64 or later with SSE2 instruction set
support
RAM 512MB minimum; 2GB recommended

Hard disk space 200MB minimum; 20GB recommended
Palo Alto Networks supports Cortex XDR agent on many operating
systems. To determine the minimum Cortex XDR agent release for a
Operating system versions
specific operating system, refer to Where can I install the Cortex XDR
Agent in the Palo Alto Networks® Compatibility Matrix.
Cortex XDR Agent 7.2 for Linux

The Cortex XDR™ agent protects Linux servers by preventing known and unknown malware from
running by halting any attempts to leverage software exploits and vulnerabilities to compromise the
server. The agent also extends exploit and malware protection to processes that run in Linux containers.
When you install the agent on a Linux server that uses containers, it automatically protects any new and
existing containerized processes regardless of the container solution (for example, docker). Because
Cortex XDR issues the license per Linux server, each container does not consume any additional licenses.

The Cortex XDR agent for Linux has the following requirements:
REQUIREMENT MINIMUM SPECIFICATION

Processor 2.3 GHz
RAM 4GB; 8GB recommended
Hard disk space 10GB
Architecture x86 64-bit
See Where can I install the Cortex XDR Agent? in the Palo Alto
Operating system versions
Networks® Compatibility Matrix.
2.6.32
To perform malware analysis of ELF files and collect data for EDR and
behavioral threat analysis, the Cortex XDR agent for Linux requires a
supported kernel version of 3.4 or later, as listed in Latest Kernel Module
Version Support.
If you deploy the Cortex XDR agent on a Linux server that is not running
one of the kernel versions required for these additional protection
capabilities, the agent will operate in asynchronous mode, where:
● Continuous event monitoring required for behavioral threat
protection is disabled.
● Sharing endpoint activity data with Cortex apps is disabled.
Kernel version ● ELF file examination and local privilege escalation (LPE)
examination occur in parallel with the file execution. If the
Cortex XDR agent obtains a malware verdict for the file, it
terminates the file execution. Security events for malware in
asynchronous mode are assigned a high severity due to the
potential for continued execution during the verdict request,
whereas security events in synchronous mode are assigned
medium severity.
● Alert indicators such as file path or hash could be missing for
processes with a very short lifespan.
● All other exploit and malware protection is enabled per your
Linux security policy.
ca-certificates
openssl 1.0.0 or a later release
Distributions with SELinux in enforcing or permissive mode:
● Red Hat Enterprise Linux 6, CentOS 6, and Oracle Linux
6—policycoreutils-python
● Red Hat Enterprise Linux 7, CentOS 7, and Oracle Linux
Software packages 7—policycoreutils-python and selinux-policy-devel
● SUSE—policycoreutils-python and selinux-policy-devel
● Debian and Ubuntu—policycoreutils and selinux-policy-dev
glibc—Required for exploit protection of containerized processes using

the ROP Mitigation and Brute Force Protection modules. If glibc is not
installed, the modules are disabled but all other exploit and malware
protection functionality works as expected.

CentOS 6.10—Enable the dynamic CA instead of the legacy CA:
● Enable the dynamic CA configuration: update-ca-trust
force-enable
● Import the certificates: cp XDR-certificate.crt
/etc/pki/ca-trust/source/anchors/.
● Rebuild the certificate database: update-ca-trust extract

7.3.3 References
Architecture of agent related to different operating systems:

https://docs.paloaltonetworks.com/cortex/cortex-xdr/7-2/cortex-xdr-agent-admin.html
1. What is the specification for hard disk space in Cortex XDR agent 7.2 for Mac?
a. 10GB
b. 512MB minimum; 2GB recommended
c. 200MB minimum; 20GB recommended
d. 12 GB
2. How much RAM is required in Cortex XDR agent 7.2 for Windows?
a. 2GB minimum
b. 4GB; 8GB recommended
c. 3GB minimum
d. 512MB minimum; 2GB recommended
7.4 Outline how Cortex XDR ingests other non-Palo Alto Networks data
sources
7.4.1 Outline all ingestion possibilities
An INGEST section is used to define the resulting Parsing Rule. The CONST and RULE sections are only
add-ons, used to help organize the INGEST sections, and are optional to configure. Yet, a Parsing Rules
file that contains no INGEST sections generates no Parsing Rules, and it is mandatory to configure.

INGEST syntax is derived from XQL with a few modifications as explained in the Parsing Rules syntax. In
addition, INGEST sections contain the following syntax add-ons.
● INGEST sections can have more than one XQLp statement, separated by a semicolon (;). Each
statement creates a different Parsing Rule.
● Another new stage is available called drop.
o Drop takes a condition similar to the XQL filter stage (same syntax), but it drops every log
entry that passes that condition. You can think of it as a negative filter, so drop
<condition> is not equivalent to filter not <condition>.
o Drop can only appear last in a statement. No other XQLp rules can follow.
● INGEST sections take parameters, and not names as RULE sections use, where some are
mandatory and others optional.
7.4.2 Outline all ingestion possibilities
In addition to native log-ingestion support, Cortex XDR also supports the following custom log-ingestion
methods:
● Ingest logs from a syslog receiver
● Ingest CSV Files as datasets
● Ingest database data as datasets
● Ingest logs in a network share as datasets
● Ingest FTP Files as Datasets
● Ingest NetFlow flow records as datasets
● Set up an HTTP Log Collector to receive logs
● Ingest logs from Elasticsearch Filebeat
● Ingest data from ServiceNow CMDB
● Ingest report data from Workday
7.4.3 References
Ingest:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/data-management/create-p
arsing-rules/parsing-rules-file-structure/ingest
Ingestion methods:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/external-data-ingestion/addi
tional-log-ingestion-methods-for-cortex-xdr.html#additional-log-ingestion-methods-for-cortex-xdr
1. What does SFTP stand for?
a. System File Transfer Protocol
b. Secure File Transfer Protocol
c. Secure File Transmission Protocol
d. System File Transmission Protocol

2. What does CMDB stand for?
a. Configuration management database
b. Configuration management data
c. Configure management database
d. Configure management data
7.5 Overview of functions and deployment of Broker

7.5.1 Outline deployment of Broker
To set up the Broker virtual machine (VM), you need to deploy an image created by Palo Alto Networks
on your network or supported cloud infrastructure and activate the available applications. You can set up
several broker VMs for the same tenant to support larger environments. Ensure that each environment
matches the necessary requirements.
Configure the broker:

Step 1: In Cortex XDR, select Settings ( ) > Configurations > Broker VM.
Step 2: Download and install the Broker VM images for your corresponding infrastructure:
● Amazon Web Services (AWS)—Use the VMDK to create a Broker VM Amazon Machine Image
(AMI).
● Google Cloud Platform—Use the VMDK image to set up the Broker VM on Google Cloud
Platform (GCP).
● Microsoft Hyper-V—Use the VHD image.
● Microsoft Azure—Use the VHD (Azure) image to create a Broker VM Azure Image.
● VMware ESXi—Use the OVA image.
Step 3: Generate Token and copy to your clipboard.

Step 4: Navigate to https://<broker-vm-ip-address>/.
Step 5: Log in with the default password !nitialPassw0rd and then define your own unique password.
Step 6: Configure your Broker VM settings:

● In the Network Interface section, review the preconfigured Name, IP address, and MAC Address,
select the Address Allocation: DHCP (default) or Static, and select to either Disable or set as
Admin the network address as the Broker VM web interface.
● If you choose Static, define the following and Save your configurations:
o Static IP address
o Netmask
o Default Gateway
o DNS Server

● (Optional) Configure a Proxy Server.
o Select the proxy Type: HTTP, SOCKS4 or SOCKS5
o Enter the proxy Address and Port and an optional User and Password. Select the pencil
icon to enter the password.
o Save your configurations.
● (Optional) (Requires Broker VM 8.0 or later) Configure your NTP servers.

Enter the required server addresses using the FQDN or IP address of the server.

● (Optional) (Requires Broker VM 8.0 or later) In the SSH Access section, Enable or Disable SSH
connections to the broker VM. SSH access is authenticated using a public key, provided by the
user. Using a public key grants remote access to colleagues and Cortex XDR support who have
the private key. You must have Instance Administrator role permissions to configure SSH access.
To enable connection, generate an RSA key pair and enter the public key in the SSH Public Key
section. Once one SSH public key is added, you can +Add Another. When you are finished, Save
your configuration.
When using PuTTYgen to create your public and private key pairs, you need to copy the public key
generated in the “Public key for pasting into OpenSSH authorized_keys file” box and paste it in the
broker VM SSH Public Key section, as explained above. This public key is only available when the
PuTTYgen console is open after the public key is generated. If you close the PuTTYgen console before
pasting the public key, you will need to generate a new public key.

● (Optional) (Requires Broker VM 10.1.9 or later) In the SSL Certificates section, upload your
signed server certificate and key to establish a validated secure SSL connection between your
endpoints and the broker VM. Cortex XDR validates that the certificate and key match, but it
does not validate the Certificate Authority (CA).

● In the Trusted CA Certificate section, upload your signed Certificate Authority (CA) certificate or
Certificate Authority chain file in a PEM format. Configuring a trusted CA certificate is useful
when the Broker VM communication with Cortex XDR is inspected by an SSL decrypting
device—for example, when configuring Palo Alto Networks NGFW to decrypt SSL using a
self-signed certificate. To ensure that the broker can validate a self-signed CA, configure
cert_ssl-decrypt.crt on the broker VM.
● (Optional) (Requires Broker VM 8.0 and later) Collect and Download Logs. Your XDR logs will
download automatically after approximately 30 seconds.
Step 7: Register and enter your unique Token, created in the Cortex XDR console.
After a successful registration, Cortex XDR displays a notification.

You are directed in Cortex XDR to Settings ( ) > Configurations > Broker VM. The Broker VMs page
displays your broker VM details and allows you to edit the defined configurations.
7.5.2 Describe how to use the Broker to ingest third-party alerts
Cortex XDR can receive logs or both logs and alerts from the source. Depending on the data source,
Cortex XDR can provide visibility into your external data in the form of:
● Log stitching with other logs such as to create network or authentication stories.
● Raw data in queries from XQL Search.
● Alerts reported by the vendor throughout Cortex XDR such as in the Alerts Table, incidents, and
views.
● Alerts raised by Cortex XDR on log data such as Analytics alerts.
To ingest data, you must set up the Syslog Collector applet on a broker VM within your network.

7.5.3 Describe how to use the Broker as a proxy between the agents and XDR in the
Cloud
To deploy Cortex XDR in restricted networks where endpoints do not have a direct connection to the
internet, set up Broker VM to act as a proxy that routes all the traffic between the Cortex XDR
management server and Cortex XDR agents via a centralized and controlled access point. This enables
your agents to receive Security policy updates and send logs and files to Cortex XDR without a direct
connection. Additionally, the Broker VM endpoints agents are able to connect to the internet.
In environments where agents communicate with the Cortex XDR server through a wide-system proxy,
you can now set an application-specific proxy for the Traps and Cortex XDR agent without affecting the
communication of other applications on the endpoint. You can set the proxy in one of three ways: during
the agent installation or after installation using Cytool on the endpoint or from Endpoints Management
in Cortex XDR as described in this topic. You can assign up to five different proxy servers per agent. The
proxy server the agent uses is selected randomly and with equal probability. If the communication
between the agent and the Cortex XDR server through the app-specific proxies fails, the agent resumes
communication through the system-wide proxy defined on the endpoint. If that fails as well, the agent
resumes communication with Cortex XDR directly.
Step 1: From Cortex XDR, select Endpoints > Endpoint Management > Endpoint Administration.
Step 2: If needed, filter the list of endpoints.
Step 3: Set an agent proxy.

● Select the row of the endpoint for which you want to set a proxy.
● Right-click the endpoint and select Endpoint Control > Set Endpoint Proxy.
● You can assign up to five different proxies per agent. For each proxy, enter the IP address and
port number. For Cortex XDR agents 7.2.1 and later, you can also configure the proxy by entering
the FQDN and port number. When you enter the FQDN, you can use either all lowercase letters
or all uppercase letters. Avoid using special characters or spaces.
● For example: my.network.name:808,YOUR.NETWORK.COM:888,10.196.20.244:8080.
● Set when you’re done.

● If necessary, you can later Disable Endpoint Proxy from the right-click menu.
When you disable the proxy configuration, all proxies associated with that agent are removed. The
agent resumes communication with the Cortex XDR server through the wide-system proxy if
defined; otherwise, if a wide-system is not defined, the agent resumes communicating directly
with the Cortex XDR server. If neither a wide-system proxy nor direct communication exist and
you disable the proxy, the agent will disconnect from Cortex XDR.
7.5.4 Describe how to use the Broker to activate Pathfinder
Pathfinder™ is a highly recommended, but optional, component integrated with the Broker VM that
deploys a nonpersistent data collector on network hosts, servers, and workstations that are not
managed by a Cortex XDR agent. The collector is automatically triggered by Analytics type alerts with a
severity of High and Medium as described in the Cortex XDR Analytics Alert Reference, providing insights
into assets that you previously would have been unable to scan.
When an alert is triggered, the data collector can run for up to two weeks gathering EDR data from
unmanaged hosts. You can track and manage the collector directly from the Cortex XDR console and
investigate the EDR data by running a query from the Query Center.
Activate the Pathfinder app to deploy and query the data collector.
Step 1: In Cortex XDR, select Settings > Configurations > Broker VM and locate your broker VM.
Step 2: Right-click and select Pathfinder > Activate.
Step 3: In the Pathfinder Activation wizard, complete the following steps:

● Define the Pathfinder Credentials used by the applet to access and deploy the data collector. The
Data Collector is deployed only within the ranges your defined IP address ranges. You can either
select to define the domain access credentials, or alternatively, in Broker VM 9.0 and later, you
can define Pathfinder to access target hosts using credentials stored in your CyberArk vault.

● Define the data collector settings.
● Select the IP Address Ranges to scan from the your defined Network Configurations and deploy
the data collector. You can add IP address ranges if you don’t see a range in the populated list.
By default, every IP address range will use the Pathfinder credentials and settings you defined in the
Credentials section, and each range is labeled as an Applet Configuration.

If you want to configure other credentials for a specific range, use the right pane to override the
settings. IP address ranges you edit are labeled as a Custom Configuration. Make sure to Test the
credentials for this specific range.
● Activate your Pathfinder. After a successful activation, the Apps field displays the Pathfinder -
Active, Connected.
Step 4: In the App field, select Pathfinder to view the following applet metrics:
● Connectivity Status—Whether the applet is connected to Cortex XDR
● Handled Tasks—How many collectors are in progress, pending, or successfully running out of the
number of collectors that need to be set up
● Failed Tasks—How many collectors have failed
● Resources—Displays the amount of CPU, Memory, and Disk space the applet is using.

Step 5: Manage the Pathfinder.
Right-click your broker VM and select:
● Pathfinder > Edit Configuration to redefine your pathfinder configurations.
● Pathfinder > Edit Credentials to redefine the username and password.
You can select to edit credentials for multiple Pathfinder applets. However, only IP address ranges
that are using the default defined credentials, labeled as Applet Configuration, will adopt your
changes.
● Pathfinder > Deactivate to remove pathfinder.
Step 6: Track the Pathfinder Data Collector.

After the Pathfinder collector has been triggered, when an Analytics type alert is triggered on an
unmanaged host, the data collector is deployed to unmanaged assets within the defined IP address
ranges and domain names.
To track the data collector:

● In Cortex XDR, select Settings > Configurations > Broker VM > Pathfinder Collection Center.
● Manage the collector.

o Set the number of collectors you want deployed. Set Collectors Number to limit the
number of collectors you want to deploy in your environment.
o Locate the collector, right-click and select:
▪ Remove Collector - Uninstall the collector from the host.

▪ View Initiating alert - Pivot to the Alerts Table filtered according to the initiating
alert.
▪ Retrieve Logs - Upload logs from the collector
▪ Download Logs - Download the collector logs to your local machine.
When you select and right-click the Target IP field, you can choose to view the IP address in the IP
View or Open in Quick Launcher.
Step 7: Query the collector data. Data gathered by the data collector can be queried and investigated
from the Query Center. To run a query on the EDR data from an unmanaged host:
● Navigate to Investigation > Query Center.
● Select the type of query you want to run and enter the search criteria.
When defining the Host attributes, for INSTALLATION TYPE, make sure to select Data Collector.
7.5.5 References
Broker:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/broker-vm/set-up-broker-v
m.html
Pathfinder:
https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/broker-vm/set-up-broker-v
m/activate-pathfinder
1. What does DHCP (dynamic host configuration protocol) provide to the client?
a. MAC address
b. IP address
c. URL
d. None of the mentioned
2. Which version of Broker VM is required for Configuring NTP servers?

a. Broker VM 10.1.9
b. Broker VM 10.1 or later
c. Broker VM 8.0 or later
d. Broker VM 9.0 or later

Appendix A: Sample Questions with Answers
Domain 1.1.6
1. Which of the following is not considered malware?

a. Virus
b. Worms
c. Cookies
d. Spyware
e. Trojans
2. How does an attacker prefer to carry out supply chain attacks?

a. By targeting an organization directly through phishing or exploitation of vulnerabilities.
b. By targeting employees (software developers) of the target organization.
c. By targeting items that aren’t written to disk.
d. By targeting organization's upper management directly.
Domain 1.2.5
1. Which MITRE ATT&CK tactic is being used if the adversary is attempting to communicate with
compromised systems to control them?
a. Exfiltration
c. Execution
d. Persistence
e. Lateral Movement
2. Which MITRE ATT&CK tactic is being used if the adversary is trying to run malicious code?
a. Exfiltration
c. Execution
d. Persistence
e. Lateral Movement
Domain 1.3.5

1. Which of the following statements does not describe an attack?
a. An attacker has a motive and plans the attack accordingly.
b. Chance to damage or information alteration varies from low to very high.
c. Cannot be prevented by controlling the vulnerabilities.
d. It is always malicious.
2. You notice that a hardware device is damaged and important data files have been completely
erased from the system. What kind of threat appears to be present here?
a. Interruption
b. Interception
c. Fabrication
d. Modification
Domain 2.1.4
1. Which of the following statements about ransomware is correct? (Choose two.)

a. Can encrypt files and demand money in order to restore them.
b. Focuses on weaker connections in an organization's supply chain.
c. Has the potential to harm an organization's reputation.
d. Act of sending fraudulent communications that appear to be from a reputable source.
2. Which of the following is a ransomware example? (Choose two.)

a. Malvertising
b. Trojan Horse
c. Petya
d. Locky
Domain 2.2.7
1. The term "TCP/IP" stands for_____?

a. Transmission Contribution protocol/ internet protocol
b. Transmission Control Protocol/ internet protocol
c. Transaction Control protocol/ internet protocol
d. Transmission Control Prevention/ internet protocol
2. In the following statement, which of the following attacks is associated?

‘The attacker identifies and targets software developers who are actively working on the project.’
a. Eavesdropping attack
b. Ransomware
c. Phishing attack
d. Supply chain attack
Domain 2.3.7
1. Which profiles prevents attempts to exploit system flaws or obtain unauthorized access to
systems?
a. Antivirus profiles
b. Anti-Spyware profiles
c. Vulnerability protection profiles
d. URL filtering profiles
2. At what phase in the malware protection flow does the Cortex XDR agent observe the file's
behavior and apply additional malware protection rules?
a. Evaluation of Child Process Protection Policy
b. Evaluation of the Restriction Policy
c. Hash Verdict Determination
d. Evaluation of Malware Security Policy
Domain 2.4.5
1. Which of the following is a piece of software or a command that takes advantage of a bug in
order to trigger undesired actions and behaviors?
a. Malware
b. Trojan
c. Exploit
d. Worms
6. Which of the following comes under exploit protection? (Choose two.)

a. Ransomware protection
b. Reconnaissance protection
c. Kernel protection
d. Behavioral Threat Protection

Domain 2.5.5
1. Which MITRE ATT&CK tactic employs techniques for obtaining data from a network, such as
valuable enterprise data?
a. Exfiltration
c. Execution
d. Persistence
2. The analytics engine creates and maintains a very large number of profile types, but they can all
be categorized into how many categories in general?
a. 4
b. 2
c. 3
d. 5
Domain 3.1.6
1. Cortex XDR supports saving____ alerts per____ agents?

a. 1M alerts per 4000 agents
b. 2M alerts per 4000 agents
c. 1M alerts per 3000 agents
d. 2M alerts per 3000 agents
7. Which of the following policy exceptions applies to the following description?

‘An exception disabling a specific BTP rule across all processes.’
a. Support exception
b. Local file threat examination exception
c. Behavioral threat protection rule exception
d. Process exception
Domain 3.2.6
1. The Action Center can be found at which of the following tabs?

a. Reporting
b. Investigation

c. Response
d. Endpoints
8. What threshold does cortex xdr provides to keep incidents fresh and relevant?
a. 20 days after the incident was created and 14 days since the last alert in the incident was
detected
b. 30 days after the incident was created and 10 days since the last alert in the incident was
detected
c. 20 days after the incident was created and 10 days since the last alert in the incident was
detected
d. 30 days after the incident was created and 14 days since the last alert in the incident was
detected
Domain 3.3.6
1. By default, Palo Alto Networks provides you with a variety of pre-canned scripts that you can use
out-of-the-box. Which of the following statement about scripts is incorrect?
a. You can view the script.
b. You can download the script code and meta-data.
c. You can duplicate the script.
d. You can edit the code or definitions of pre-canned scripts.
2. Which of the following is the path to access Live Terminal?

a. Response > Live Terminal
b. Reporting > Live Terminal
c. Investigation > Live Terminal
d. Endpoints > Live Terminal
Domain 3.4.4
1. How many cortex XDR rules are there??

a. 3
b. 4
c. 2
d. 5

2. What is the expiration limit set by Cortex XDR by default for agent upgradation and agent
uninstall?
a. 90 days
b. 60 days
c. 40 days
d. 30 days
Domain 4.1.6
1. Which of the following requirement for initiating remediation suggestions is incorrect?

a. Cortex XDR Pro per Endpoint license
b. EDR data collection enabled
c. Cortex XDR agent version 7.0 and above on Windows endpoints
d. An App Administrator, Privileged Responder, or Privileged Security Admin role permissions
which include the remediation permissions
2. Which of the following refers to the ‘summary of the remediation suggestion to apply to the file
or registry’?
a. Suggested remediation
b. Original event description
c. Suggested remediation description
d. Remediation status
Domain 4.2.5
1. What is ransomware?
a. Computer equipment that criminals steal from you and won’t return until you pay them.
b. Software that infects computer networks and mobile devices to hold your data hostage until
you send the attackers money.
c. Software used to protect your computer or mobile device from harmful viruses.
d. A form of cryptocurrency.
2. Which of the following can be done to significantly decrease the chances of putting your
organization at risk for a Ransomware attack?
a. Verify links in email, except know contacts
b. Purchase only software, programs and applications from reputable companies

c. Implement email protection and web gateway solution
d. All of the above
e. None of the above
Domain 4.3.8
1. Which of the following policy exceptions applies to the following description?

‘An exception allowing specific PHP files’
a. Support exception
b. Local file threat examination exception
c. Behavioral threat protection rule exception
d. Process exception
2. In xdr, how many different methods can you use to search a file?
a. 2
b. 4
c. 3
d. 5
Domain 5.1.6
1. Which of the following technique is used to investigate any lead quickly, expose the root cause of
an alert, perform damage assessment, and hunt for threats from your data sources?
a. IOC Technique
b. Query Builder Technique
c. BIOC Technique
d. XQL Technique
2. Which of the following technique alert and responds to behaviors- tactics, techniques, and
procedures?
a. XQL Technique
b. IOC Technique
c. Query Builder Technique
d. BIOC Technique
Domain 5.2.3

1. Cortex XDR automatically disables BIOC rules that reach______.
a. 5000 or more hits over a 24 hour period
b. 1000 or more hits over a 24 hour period
c. 5000 or more hits over a 12 hour period
d. 1000 or more hits over a 12 hour period
2. Which of the following field configurations are not included in user-defined BIOC rule event?
(Choose three.)
a. Host Name
b. Device Serial Number
c. IP Address
d. Device Type
Domain 5.3.3
1. Which of the following is considered “not true” for Unit 42?

a. Investigate threats and determine the total scope of incidents.
b. Offer direct assistance to answer questions and provide guidance about Threat Reports and
Impact Reports
c. Is available to advise customers on the latest risks, assess their readiness, and help them
recover when the worst occurs
d. Can detect a variety of threats but may miss some complex malware.
Domain 6.1.3
1. Which option from the reporting menu will you choose if you need to add additional widgets to
the dashboard?
a. Dashboard
b. Dashboards Manager
c. Reports
d. Reports Templates
2. Response action breakdown widget belongs to which of the following widget categories?
(Response action breakdown - Displays the top response actions taken in the Action Center over
the last 24 hours, 7 days, or 30 Days)
a. Agent Management Widgets
b. Incident Management Widgets

c. Investigation Widgets
d. User Defined Widgets
Domain 6.2.7
1. Which of the following statements about dashboard customization is incorrect?

a. You can create and add custom widgets to the dashboard.
b. You can temporarily disable a dashboard.
c. You can edit the default dashboards provided by Palo Alto Networks.
d. For agent-related widgets, you can apply an endpoint scope.
2. Which of the following paths is required to create a report from the scratch?
a. Reporting > Report Templates
b. Reporting > Dashboard Manager
c. Reporting > Reports
d. Reporting > Dashboard
Domain 7.1.9
1. _____ is a secured virtual machine, integrated with Cortex XDR, that bridges your network and
Cortex XDR.
a. Cortex Console
b. Cortex Agent
c. Cortex Broker
d. WildFire
2. Which of the following tab needs to be selected for managing cortex XDR agents?
a. Reporting
b. Investigation
c. Response
d. Endpoints
Domain 7.2.7
1. Which of the following does not pose a direct security threat, but might display otherwise
obtrusive behavior?
a. Virus

b. Trojans
c. Malware
d. Grayware
2. What does SCTP stands for?

a. Stream Control Transmission Protocol
b. Stream Control Transfer Protocol
c. System Control Transfer Protocol
d. System Control Transmission Protocol
Domain 7.3.4
1. What is the specification for hard disk space in cortex XDR agent 7.2 for mac?
a. 10GB
b. 512MB minimum; 2GB recommended
c. 200MB minimum; 20GB recommended
d. 12 GB
2. How much RAM is required in cortex XDR agent 7.2 for Windows?
a. 2GB minimum
b. 4GB; 8GB recommended
c. 3GB minimum
d. 512MB minimum; 2GB recommended
Domain 7.4.4
1. SFTP stands for?

a. System File Transfer Protocol
b. Secure File Transfer Protocol
c. Secure File Transmission Protocol
d. System File Transmission Protocol
2. CMDB stands for?

a. Configuration management database
b. Configuration management data
c. Configure management database

d. Configure management data
Domain 7.5.6
1. DHCP (dynamic host configuration protocol) provides __________ to the client.

a. MAC address
b. IP address
c. URL
d. None of the mentioned
2. Which version of broker VM is requires for Configuring NTP servers?

a. Broker VM 10.1.9
b. Broker VM 10.1 and later
c. Broker VM 8.0 and later
d. Broker VM 9.0 and later

Pcdra Study Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pcdra Study Guide

Uploaded by

Copyright:

Available Formats

Contents

Palo Alto Networks PCDRA Study Guide 8

Domain 2 Prevention and Detection 19

PALO ALTO NETWORKS PCDRA Study Guide 2

PALO ALTO NETWORKS PCDRA Study Guide 3

PALO ALTO NETWORKS PCDRA Study Guide 4

Domain 5 Threat Hunting 77

PALO ALTO NETWORKS PCDRA Study Guide 5

Domain 7 Architecture 101

PALO ALTO NETWORKS PCDRA Study Guide 6

Appendix A: Sample Questions with Answers 134

PALO ALTO NETWORKS PCDRA Study Guide 7

This exam is based on Cortex XDR.

Exam Domain Weight (%)

PALO ALTO NETWORKS PCDRA Study Guide 9

PALO ALTO NETWORKS PCDRA Study Guide 10

PALO ALTO NETWORKS PCDRA Study Guide 11

Attackers must execute five steps for a ransomware attack to be successful:

PALO ALTO NETWORKS PCDRA Study Guide 12

2. How does an attacker prefer to carry out supply-chain attacks?

1.2 Recognize common attack tactics

PALO ALTO NETWORKS PCDRA Study Guide 13

PALO ALTO NETWORKS PCDRA Study Guide 14

Step 2: Acquire data

Step 3: Develop analytics

MITRE describes four types of analytics:

PALO ALTO NETWORKS PCDRA Study Guide 15

Step 6: Investigate attack

Step 7: Evaluate performance

PALO ALTO NETWORKS PCDRA Study Guide 16

1.3 Recognize various types of threats/vulnerabilities

S. No. Key Threat Attack

PALO ALTO NETWORKS PCDRA Study Guide 17

Indicators of compromise (IOCs)

1.3.4 Summarize the generally available references for vulnerabilities

Threats and Attacks:

PALO ALTO NETWORKS PCDRA Study Guide 18

PALO ALTO NETWORKS PCDRA Study Guide 19

Ransomware is delivered to targets primarily through these avenues:

Step 2: Prevent known threats

Step 3: Identify and prevent unknown threats

PALO ALTO NETWORKS PCDRA Study Guide 20

Device Control Profiles:

Cortex XDR relies on the device class assigned by the

2.1.4 Sample Questions

2. Which two of the following are examples of ransomware? (Choose two.)

PALO ALTO NETWORKS PCDRA Study Guide 21

2.2 Identify attack vectors

Step 2: If needed, filter the list of endpoints.

Step 3: Set an agent proxy.

PALO ALTO NETWORKS PCDRA Study Guide 22

2.2.2 Describe how to use XDR to prevent supply-chain attacks

A supply-chain attack is a sort of cyberattack that focuses on weaker connections in an organization's

Steps to be taken to prevent a supply-chain attack:

PALO ALTO NETWORKS PCDRA Study Guide 23

Steps to be taken to prevent a phishing attack:

PALO ALTO NETWORKS PCDRA Study Guide 24

2.2.4 Characterize the differences between malware and exploits

2.2.5 Categorize the types and structures of vulnerabilities

PALO ALTO NETWORKS PCDRA Study Guide 25

How to Break the Cyber Attack Lifecycle:

2.2.7 Sample Questions

2. Which type of attack does the following statement describe?

2.3 Outline malware prevention